incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matevž Bradač <mate...@gmail.com>
Subject Re: User comments on ticket modification UI
Date Tue, 29 Jan 2013 20:48:40 GMT

On 29. Jan, 2013, at 21:25, Peter Koželj wrote:

> On 29 January 2013 19:00, Gary Martin <gary.martin@wandisco.com> wrote:
> 
>> Hi,
>> 
>> Sorry to go back to the details!
>> 
>> 
>> On 26 January 2013 12:13, Andrej Golcov <andrej@digiverse.si <mailto:
>> andrej@digiverse.si>> wrote:
>> 
>>   Just want to somehow summarise issues we discussed about and initiate
>>   further discussion.
>> 
>>     - After update, result page scroll is confusing. At the time of
>>   being, it is scrolled to the result #comment.
>>   I guess, we have consensus that result page should be scrolled to the
>>   top? Link to the comment can be shown in popup.
>> 
>> 
>> Without a means to add comments from the top of the page, I would not
>> advocate this approach yet. The activity feed does give us some
>> justification in going this direction on the basis that we can still see
>> what we have just added which is a good confirmation of what is changed. On
>> the other hand, an eventual change to submitting with AJAX should make this
>> redundant.
>> 
>> 
>>     - Modify button in navigation bar acts odd. There is suggestion to
>>   move it out of nav bar.
>> 
>> 
>> Another question is whether we will actually have enough items to bother
>> with the scrollspy at all. Does anyone actually make use of this at the
>> moment?
>> 
>> 
> I would hope that there is not enough items to warent the scroll spy. The
> thing feels like a fix for a problem that should not be there in the first
> place,
> but that is highly subjective viewpoint :)
> 
> 
>> 
>>     - "Update (leave)" caption of update button confuses user.
>>   There is aslo a suggestion to move workflow actions out of Modify
>>   functionality as separate action. We need more feedback and mockups on
>>   this.
>> 
>>     - "Submit changes" button duplicates "Update (leave)" button.
>> 
>> 
>> It probably makes sense always to have a submit button visible so that
>> users always know where to find it. My only worry is that users will find
>> it more natural for a submit button to be with the comment.
>> 
>> 
> If I take a step back, writing a comment with each ticket edit sounds like
> a good practice similar to commit messages.
> No need for "Add comment" buttons in edit mode then, display the comment
> text box as part of the edit form.
> 
> 
>> 
>> 
>>     - If Change history is long, "Add comment" field may not be visible
>>   to user. There is suggestion to collapse Change History in Modify
>>   mode. Or may be put Add comment before Change History in read-only and
>>   modify modes?
>> 
>> 
>> Collapsing the change history feels a little bit unnecessary to me and
>> could be annoying if you had to make sure you knew everything you needed
>> before entering the modify mode or be forced to find your place in the
>> comments again. An add comment button always being visible seems to be the
>> best option to me at the moment.
>> 
>> 
>>   Did I forget something?
>>   Please add your experience feedback.
>> 
>>   Regards, Andrej
>> 
>> 
>> Another question is where the comment textarea should be located. I have
>> toyed with the idea of moving it to the top of the activity area into what
>> will eventually be part of the sticky region but I feel that it would not
>> really be big enough. The edit ticket and comment buttons could be there of
>> course. Another alternative might be that we just have some kind of pop-up
>> comment editor but we would still have to make sense of how this interacted
>> with the modify mode - I don't particularly want to stop people writing a
>> comment and then doing other ticket edit events.
>> 
>> I have also found myself questioning the requirement for an edit mode at
>> all. What were the reasons for this again?
>> 
> 
> I have been asking myself similar question as well multiple times (not just
> on Bloodhound). I guess it does offer some kind of protection agains
> unwanted ticket changes (...did I just do copy or paste on that field, #$@!
> maybe I should refresh the page just in case…)

Perhaps we could introduce some (subtle) indicator for modified fields in that case?
Although in general I think there should be a mechanism for users to revert the changes,
either through prevention (edit mode), or through some sort of a undo mechanism.
Even if the user actions aren't really destructive, they may sometimes be inadvertent (e.g.
wheel scroll on a dropdown).

On another note, some fields (such as Reporter for example) shouldn't be editable IMO,
as this modifies the ticket history. I suppose this is not something desirable.

> 
> 
>> 
>> Cheers,
>>    Gary
>> 


Mime
View raw message