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 18:33:18 GMT
On 1/18/13, Andrej Golcov <> 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 .



Blog ES:
Blog EN:

Featured article:

View raw message