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.
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. > - 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. 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. > > 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. > 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 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. > > 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 :-) Cheers, Joe > > > 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> >
