On 30. May, 2013, at 12:36, Joachim Dreimann wrote: > I've made an effort to make more of my reasoning behind the initial design > explicit below. I hope it comes across as constructive, otherwise please > excuse the rant.
Any input is very much appreciated, I don't see it as a rant. =) > > On 30 May 2013, at 09:18, Matevž Bradač <[email protected]> wrote: > >> Hi Joe, >> >> I apologize for not communicating this more clearly. >> >> The main reason for the changes was to make it more usable across all > devices, >> not just desktops. To make that work, the following "goals" should be met >> (in my opinion, that is): >> - All, or at least most of the change information should be directly > visible, without >> any need for user interaction (e.g. hovering over changes to display the > date >> information is not a viable option for tablet/phone users) > > I believe the elements that were hidden on desktops and required hover > actions to be seen were always shown on mobile devices for this very reason. Okay, then just the mobile part should be tweaked somewhat. > >> - The user should be able to quickly tell for each change what exactly > was changed, >> who made the change and when - the visual clues hopefully achieve that > goal. > > I think it's unlikely that users regularly look for this information for > every change. They may occasionally look for a specific change event > however. > > The previous design catered for the latter case by showing less > information. I would argue that is was quicker to identify e.g. when a > specific ticket field was last changed. It also showed what something was > changed to, omitting what it was changed from - because this information > just repeats the previous change event for that field. Good point. I assumed that "when" had to have more weight, but that's probably just my perspective. > > I believe "who made a change and when" are not the criteria by which people > scan for changes in the list in most cases. That's what they care about > once they have found a change, which is subtly different. They search by > the field that they're interested in, for example: > - Why was the *milestone* changed? > - Who changed the *Summary*? > - When did the *status* change to Review? > > Currently the noise of visual cues (ie the styling around every change > event) obscures the signals (field names) of what should be a scannable > list. Top -> bottom scanning is interrupted by borders, spacing and > usernames. > >> - The information should be presented in compact form, but not to the > point of losing >> readability across different devices. > > Yes. On mobile devices vertical height is a readability (and > usability) issue. The current implementation uses a guesstimated 3-4 times > more vertical height than the previous one for a given change event. Ok, I'll recheck the old version on the tablet/phone again. There were a couple of things that bothered me initially, I'll focus on that first. > >> >> As for the comments, I do understand they should be made more visually > distinct >> and I'm still working on that. > > I appreciate it is a work in progress, but so far you have introduced > additional visual cues (pen and speech bubble icons), which to me seem to > add noise to highlight signals. Agreed, that's what has been bothering me as well. > >> Additionally, there are ticket changes which include >> both property and comment changes, and those should be addressed as well. > > They were addresses in the original proposal (changes > submitted simultaneously highlighted in yellow on interaction): > https://issues.apache.org/bloodhound/attachment/ticket/471/bh%20comments%20ticket%20with%20overlays.png Ok. As for the phones/tablets, should there also be a visual clue (in place of hovering)? > > I think there's also an assumption that events need to be visually grouped > that were submitted together, but here are some examples for common > submissions: > 1. Field changes and comment explaining them > > "I changed the milestone because this ticket will not be ready" > > 2. Field changes and unrelated comment > > (milestone changed) "I've attached a patch.." > > 3. Field changes, followed by a comment submitted separately > > (milestone changed), then followed by "I changed the milestone because > [...]" > > 4. A comment announcing the intent to make field changes, with field > changes submitted (immediately?) afterwards > > "I will change the milestone because [...]", then followed by (milestone > changed) > > > Only in the first case does visual grouping by submission add value, in all > other cases the relative separation of technically 'unrelated' submissions > confuses matters that are clear from their content. > > You could argue that some of those examples are poor practices, but I > believe they're only considered so poor because the design makes their > impact worse. In a well designed system it should make little difference > whether you submit five individual changes or one large change. > > The design I proposed dealt with this by making proximity the cue to > related changes, not how they were submitted. Changes that happen between > two comments are likely to be explained by either the comment above or > below (or even discussed much later). The very distinct style of changes vs > comments again helped here. Again the grouping of related modifications is probably just my perspective (i.e. how I was used to use defect trackers in the past). Point taken. > >> >> All the recent commits I've made wrt. the ticket page are marked with > #533. >> If you feel the changes are too intrusive and/or do not function as they > should, >> please let me know and I'll revert them back to the previous layout. >> And apologies again for not discussing this first on the devlist. >> >> Cheers, >> matevz > > I leave that up to you based on whether you agree with my reasoning. Let's > discuss it here either way :-) I think it's best to revert back to the original, then fix whatever issues are present (especially wrt. mobile layout). > > Cheers, > Joe Thanks for the exhaustive input! =) Cheers, matevz > >> >> >> On 29. May, 2013, at 19:08, Joachim Dreimann wrote: >> >>> Thanks for fixing the placement of the ticket details and some of the > other >>> stuff Matevz. >>> >>> In the change history comments left by users were visually distinct from >>> other ticket changes, such as ticket detail field changes. That's > because I >>> reasoned that comments would be more important to users than field > changes, >>> making the latter less prominent. >>> >>> There appear to have been some major changes recently to the way the > change >>> history looks on ticket pages. They seem like a regression to me. I > didn't >>> find them mentioned in the commit messages or this ticket (#533) either, >>> but I may have missed something of course. >>> >>> What was the reason for this change? >>> >>> I'm not certain at which revision this change was made, but here is a >>> comparison: >>> >>> Trunk: >>> > https://issues.apache.org/bloodhound/attachment/ticket/533/NewTimelineScreenshot.png >>> >>> r1485261: >>> > https://issues.apache.org/bloodhound/attachment/ticket/533/OldTimelineScreenshot.png >>> >>> Cheers, >>> Joe >>> >>> >>> On 24 May 2013 12:33, Apache Bloodhound <[email protected]> > wrote: >>> >>>> #533: Ticket page cleanup >>>> ----------------------------------------------+----------------------- >>>> Reporter: matevzb | Owner: matevzb >>>> Type: defect | Status: new >>>> Priority: major | Milestone: Release 6 >>>> Component: dashboard | Version: 0.5.3 >>>> Keywords: ticket page, properties, details | >>>> ----------------------------------------------+----------------------- >>>> This ticket is closely related to #520, with further small improvements: >>>> - Move the ticket details back to the top, add a heading. The reason for >>>> this is that the ticket description can be very long in some cases, >>>> obscuring the detail fields from view (e.g. https://bh- >>>> demo1.apache.org/products/%40/ticket/513). >>>> - Ticket Details modifications: lighter, left-aligned field labels seem > to >>>> make the details more readable. >>>> - Separate the Details and Description sections from Attachments, >>>> Relations etc., using a smaller heading (h4). The former are ticket >>>> properties, the latter are not and are also managed/edited separately. >>>> >>>> There are other areas in need of improvement, such as: >>>> - Intuitiveness of the "Modify ticket" action: the "Submit changes" and >>>> "Cancel" button are placed on the top of the form, which feels awkward > to >>>> use. Additionally the semantics of "Submit changes" and the "Submit" >>>> button in the comments is not clear in the ticket editing mode (i.e. > which >>>> button does what?) >>>> - Create ticket (full form) now has the "Create ticket" button and the > "I >>>> have files to attach" checkbox positioned on the top-right side of the >>>> page, instead of the end of the form. >>>> - etc. >>>> >>>> -- >>>> Ticket URL: <https://issues.apache.org/bloodhound/ticket/533> >>>> Apache Bloodhound <https://issues.apache.org/bloodhound/> >>>> The Apache Bloodhound issue tracker >>> >>> >>> >>> -- >>> Joe Dreimann | *User Experience Designer* | WANdisco< > http://www.wandisco.com/> >>> >>> @jdreimann <https://twitter.com/jdreimann> >>
