bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: User comments on ticket modification UI
Date Fri, 18 Jan 2013 00:10:37 GMT
On 1/17/13, Andrej Golcov <> 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»

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

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

>    - Remove "Change history" section


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 .

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

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

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

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 .



Blog ES:
Blog EN:

Featured article:

View raw message