On 18/01/13 00:10, Olemis Lang wrote:
On 1/17/13, Andrej Golcov <[email protected]> wrote:
Modify Ticket section was removed so there's nothing anymore in the
page to highlight it . It used to be active , but now it's just a
command button .

Maybe we should pull it out of scroll spy nav and use Bootstrap btn-*
classes to make it more prominent ?
I would suggest the following changes in order to make ticket editing
more clear:
  -  Move workflow actions out of Modify scope - why user should modify
ticket in order to resolve it?

Because changes of ticket status (e.g. close ticket) is actually a
modification . Notice that , in general , actions may apply side
effects affecting the ticket . Besides a ticket is closed for a reason
and therefore an informative message might be useful 80% of the time .
So it all come in the «same package»
;)

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.


When in Modify mode:
    - Change description from "Update (leave)" (IMHO, leave word is
confusing in this context) to something like Update/Save/Submit
This is potentially dangerous . The way I see it 'leave' word is less
confusing than having an 'Update' button and not to know what is
actually happening with the ticket from a workflow perspective .

Well, here I agree that the 'leave' text is a bit too confusing. It might be nice if we could increase the length of the text to (leave as <current state>) but I suspect that would be too long unless the combined control is given more space.
Based
on i.a.o , would you be closing it , proposing for review , requesting
info , ... ? Like I just mentioned while building the current solution
we could just assume that Update button will always trigger 'leave'
action and figure out an alternate way to invoke workflow actions , or
just extract 'leave' word and put it outside of button text ,
somewhere else . More space needed though ...

... but the important things is that workflow action has to be visible
and close enough to Update button so that users will always know of
the implications . From a UX perspective IMO we should design to
actively work towards a total understanding of the fact that a given
action will happen if Update / Submit button is clicked (even if our
proposal is close to the subliminal threshold ;)

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.


    - Remove/hide bar with Overview | Attachements | Comments | Add
comments. - as mainly not applicable to Modify mode
IMO they are ... Once we have in-place file uploads ( #195 ) users
might want to attach new files on the go in a way similar to what
GMail users do today in compose mail web form ...

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.


    - 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.


    - Rename "Add a comment" label to something like "Update comment" -
to make it clear that comment is applied to update action
IMO «update comment» suggest that you are updating a comment i.e.
something like what current «Edit» command button can do right now .

Yeah, I am not sure that specifically helps as it is a navigation item - this is the place you go when you to add a comment, right?

    - Remove/hide "Submit changes" button - the same button is used to
add comments that is confusing in this context and we already have the
Update button with the same functionality on the top
I removed both buttons (i.e. «Preview» and «Submit changes» ) while
building the patch for #146 (... or subsequent enhancement tickets
...) and I recall to hear from Gary that we should keep it in order to
add new comments without modifying the ticket . I agree that this is
useful . So I guess hiding it in edit mode might be a feasible
enhancement .

Any objections ?

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.


    - After ticket update, scroll page to the top. Currently, it is
scrolled to botton, to #trac-add-comment anchor.

+1
This is easy , just change anchor id in form's action attribute and /
or anchor href . So I guess a starter ticket will be suitable for this
enhancement .
;)


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.

Cheers,
    Gary

Reply via email to