On 29. Jan, 2013, at 21:25, Peter Koželj wrote: > On 29 January 2013 19:00, Gary Martin <[email protected]> wrote: > >> Hi, >> >> Sorry to go back to the details! >> >> >> On 26 January 2013 12:13, Andrej Golcov <[email protected] <mailto: >> [email protected]>> 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 >>
smime.p7s
Description: S/MIME cryptographic signature
