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 <[email protected]> wrote: > On 11/27/12, Gary Martin <[email protected]> wrote: > > On 27/11/12 16:00, Olemis Lang wrote: > >> On 11/23/12, Gary Martin <[email protected]> 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: >
