incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Wed, 28 Nov 2012 10:47:14 GMT
After 40+ mails on this topic where other things (quick create ticket, app
links, js fallbacks) in the mix  I have lost track of what everybody on
here visualizes the new "inline" edit ticket should look like.

Maybe we should reset this with a mock or wire diagram for new edit ticket
and discuss other things like create ticket button in new thread?

Peter

On 28 November 2012 07:59, Olemis Lang <olemis@gmail.com> wrote:

> On 11/27/12, Gary Martin <gary.martin@wandisco.com> wrote:
> > On 27/11/12 16:00, Olemis Lang wrote:
> >> On 11/23/12, Gary Martin <gary.martin@wandisco.com> wrote:
> >> [...]
> >>> Or something like that. So, apart from a clear idea of how we clearly
> >>> mark fields as edited, are there any other holes in this? It is also
> >>> worth considering if this fits with the current mechanisms for guarding
> >>> against conflicts dues to concurrent edits.
> >>
> >> Yes. I notice a gap here (unless I'm missing something ...) , and it
> >> is related to ticket workflow . Inline edits have to pass through
> >> workflow . Ideally we could always force `leave` action on in place
> >> edits but if Modify Ticket section won't be there then what shall we
> >> do ?
> >>
> >
> > I wouldn't say that changes to the ticket details imply a change of
> > ticket status within the workflow so I was hoping to leave this as a
> > separate proposal.
> >
>
> A change of ticket status ? Well , no . You are right . That's what
> built-in leave action is for . However IMO edits must always pass
> through workflow . If action=leave nothing remarkable happens though .
>
> > However, it does seem worthy of comment as there are a few
> > inconsistencies.
>
> yes
>
> > For example, it would be nice to be able to change the
> > "assigned to" user but the ability to do that is dependent on workflow
> > too. Meanwhile "reported by" could be considered an in-place edit. A
> > similar thing happens with the status and ticket type fields that are
> > close together. The attempts to change the workflow related items would
> > probably have to either send you to the "Action" control or present you
> > with the control somehow.
> >
>
> I'd rather prefer to see workflow actions when editing other fields as
> well .
>
> OTOH , editing «owner» leads to the ambiguous situation when there are
> many choices to assign a ticket to somebody (e.g. info request ,
> review , assign to , test , ...) . Not to mention and custom workflow
> actions / controllers and related side-effects happening at once .
> This makes me wander whether it's better (correct ?) to focus on
> workflow actions rather than fields when analyzing this particular
> subject from a user experience perspective .
>
> > At this point I really have to see what those with more knowledge of ui
> > design will come up with though.
> >
>
> beyond UI , or UX ... it may also be about domain / business logic ,
> and workflow semantics
> ;)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message