incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: User comments on ticket modification UI
Date Fri, 18 Jan 2013 18:33:18 GMT
On 1/18/13, Andrej Golcov <andrej@digiverse.si> 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 .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message