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 Thu, 17 Jan 2013 16:00:01 GMT
On 17/01/13 14:02, Andrej Golcov wrote:
> I showed BH 0.4 UI to a friend of mine in order to get kind of user
> feedback.  My friend is familiar with other issue trackers and uses a
> few of them (mainly JIRA and Techexcel) on a daily basis.
> He was mainly confused with current Modify Ticket UI. Please find
> below a few his comments on this subject from a user prospective:
>   - "Submit changes" button is located under "Add a comment button"
> while user would expect this button at least before " Change History".
> -  If ticket has a few history records user scrolls down to "Submit
> changes" button and can't see edit fields, clicking on "Submit
> changes" saves ticket in background but user can't see that UI is
> switched to read-only mode and sees "Submit changes" button again.
> User is confused that nothing was happened and press "Submit changes"
> button again and again.
> -  "Add comment" and Workflow are expected to be separate action and
> not part of Modify Ticket flow.  Especially simultaneous ticket
> editing and adding a comment was confusing, given that adding a
> comment is separate action in read-only mode.
> -  User would expect Cancel of "Modify ticket" mode next by Submit
> button. It was hard to find Cancel on the top of page near workflow
> button. It looks like Cancel action cancel workflow action.
> -  Scroll spy bar acts confusing in "Modify Ticket" mode:
>    - After user clicks "Modify ticket", Overview is active
>    - When user scrolls down to find "Submit" button all other options
> are active except "Modify ticket"
> -  Find summary edit field was not easy. User would expect that all
> edit fields would be located below spy scroll bar.
> His suggestions for Modify Ticket mode:
>   - Move Submit/Save button on top of page, where Cancel is located
>   - Remove comments related staff.
> It is clear that ticket modification UI is in process of improvement.
> But I think that it is worth sharing these comments with community.
> Regards, Andrej

Yeah, these things definitely need to be shared and, as you say, it is 
clearly work in progress.

So, if I interpret that right, I take it that it has been missed that 
the "Update (<workflow action>)" button also submits comments as well. 
In fact, it is currently duplicated behaviour as the "Submit changes" 
button does both too but doesn't provide the workflow tool.

The fact that the 'Modify Ticket' item is with the other scrollspy items 
suggests to me that it should exhibit the same behaviour as the rest of 
scrollspy items. If we can at least get some logical separation if it is 
not going to be representative of an anchor in the ticket then this may 
be helpful. We might also ask whether there is a point in being able to 
click it multiple times when we are already in edit mode. Can we:

  * Move the modify button above the scrollspy
  * Replace that button with the cancel button in edit mode - or
    something.. I don't think a toggle button is quite right at the moment.

Next, for change/comment submission there are a lot of options to choose 
from and I do not want to claim that I know the best one. One of the 
things that we want to avoid discouraging is submitting comments with 
any changes to the ticket. I have been wondering if there is a way to 
make the comment movable but I have not really come up with anything 
obvious yet.

I'm not convinced that of the current duplication of functionality of 
the Submit changes button and the Update (<workflow action>) control but 
at the moment the latter submit button is only available in edit mode 
anyway. I am also vaguely expecting users to expect the method of 
submitting a comment to be close to the comment. I would quite like to 
see the ability to apply different workflow actions on commenting 
without having to go into the full edit mode though.

Anyway, I'll continue to give this more thought and any additional ideas 
would be great.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message