bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <>
Subject Re: User comments on ticket modification UI
Date Fri, 18 Jan 2013 13:02:05 GMT
> 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.

> 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

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

>>>     - 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
change history or move it to the activity panel.

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

> 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.
In any case, change between view and modify mode must be clear for
user. That is not the case in current implementation when ticket has
some change history.
As Olemis suggests, we can provide quick fix in order to remove
confusing. And improve it later with AJAX.

Regards, Andrej

View raw message