bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: User comments on ticket modification UI
Date Fri, 18 Jan 2013 09:55:54 GMT
On 18/01/13 00:10, Olemis Lang wrote:
> 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»
> ;)

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 

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


View raw message