On 1/18/13, Andrej Golcov <[email protected]> wrote: >> I completely agree with Andrej here. Despite the fact that a change >> status >> is effectively a modification of sorts, I don't think it helps to >> distinguish it on that basis. The modify or edit mode is to allow >> in-place >> edit which, with the creation of the workflow action control, should no >> longer be required for workflow actions. > > In JIRa, user gets a popup where hi/she can enter a comment when > triggering workflow action. > Similar, BH can provide comment edit box in existing workflow popup. >
So , do you mean to always show the drop down while clicking on Update button and to have yet another submit button inside the drop down ? or something else ? >> Well, I look forward to more suggestions and mockups of what can be done >> for >> this. I don't know how much importance I would put on this issue though - >> we >> do want users to understand the meaning of such buttons quickly. Just >> because we know what leave means doesn't mean that a new user will. It is >> not even clear to me that a new user would know that this was the control >> to >> use in order to change the ticket state, ownership, etc. > > That is very correlated with feedback I've got from the user: What > "leave" means and will I update or leave changes when click the > button? > I understand . It might get worst if we consider that workflow is extensible , configurable , and other actions may be defined . Trust me , I just included the label in there because , when I tried it in dev mode I noticed that workflow ambiguity was unacceptable . So I look forward to further suggestions ... >> I see no strict problem with leaving the nav bar as long as the edit >> button >> does not look like it is part of it. > That can work. > BTW, there is one naming inconsistency between "Comments" link on > scroll bar and correlated "Change history" section. > User is not supposed to know that "Change history" and Comments mean the > same. > Comments is shorter and plays which makes it more suitable for e.g. responsive layout . Nevertheless , I'd be ok with these kinds of enhancements as long as the result leads to a consistent interpretation of the web UI . >>>> - Remove "Change history" section >>> >>> -1 >>> >>> Comment feed is very useful , especially while writing a new comment >>> in the same or another related ticket . I even edit comments I wrote >>> before ( e.g. update patch order ... ) and all that happens in comment >>> feed . >> >> >> Yes, I am not convinced by the need to removing the comment section for >> this. > I see here one UX problem: change history section can take a lot of > horisontal space and user cannot even know that there is a comment > edit box at the botton of the page. As alternative, we can collapse yes, one option I'd rather prefer ... > change history or move it to the activity panel. > That also means remove (i.e. replace) activity widget btw ... >> I would be willing to consider dropping the button but I would probably >> prefer it to be consistent between edit and view states so that you go to >> the same place to submit the change - that would suggest the Submit + >> workflow button at the top is always visible, which also happens to be >> consistent with allowing workflow actions outside of edit state. > I think here we are mixing two different actions that is potentially > confusing: updating a ticket with a comment and adding a comment to a > ticket. You are right . > In the first case, when in modify mode, it is part of Update > transaction and should be triggered by update button > In the second cese, when in view mode, it is separate action and > should be triggered by "Submit changes" (Submit comment?) button. > In principle I agree . The challenge is to make that fit in current web UI . >> Actually, I was wondering if we could do something different here. What >> if >> we change this to an ajax request so that the position of the view >> doesn't >> change when the page is updated. Adding a notification about the comment >> being added could then link to the comment location in case the user >> wants >> to go to view it. > The idea is very good ... [...] > > As Olemis suggests, we can provide quick fix in order to remove > confusing. And improve it later with AJAX. > ... but IMO AJAX should be added later . It poses a number of technical challenges that we've not been able to figure out since long time ago . -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
