Mozilla UI team mockup of simpler Bugzilla interface

[Mike Connor]

Gerv pinged me via email:

> Can you take a couple of minutes to say what you think of the mockup? In mozilla.dev.apps.bugzilla would be best, but if that's too much hassle then I'll pass your comments on.

* I support 100% the principle of focusing on the most important
details, with progressive disclosure burying the bigger details most
people don't care about, but I think there's a couple things that
aren't in the initial UI that probably need to be.
* Even on scan #5 of that mockup, I keep forgetting where status is,
because I start reading with the summary.
* Target Milestone is something I'd like to see reflected into primary
UI, maybe with the status.
* Keywords/Whiteboard feel like they should have the text as text
(like depends/blocks), with the (edit) option popping out to a
textarea (cleaner to read, and doesn't fail on overflow like the
<input> does)
* I think given the relative infrequency of editing blocks/depends, we
can collapse that field by default and have an edit link.  (With this
and the bullet above, we've eliminated all of the textfields from the
initial view, which would be awesome for readability)
* Can we show flags with values in primary UI?  Ideally just ?/+, and
not minused bugs.  (Knowing something is nominated or blocking feels
like a key piece of data for users.)
* I think I tried Product::Component in b.m.o., but some of the really
long component names made that less than awesome.  If we can kill the
headers, I think it'd work.  Maybe just: | Area: [Server Operations \/]
[Bugzilla Other Issues \/] or something?

> Can you remember what it was about the 3.0 UI you disliked?

>From looking again:

* Related fields were not grouped sanely (i.e. product and component
were in a separate place from the version and platform affected), the
scan pattern was like a Tetris block.
* Scanning was harder, because it was a mix of 3 columns and 2
columns.
* Assignee was over with Reporter/CC list, instead of with TM/
severity, out of a misguided desire to follow a taxonomy (people vs.
details)
* Bug#/Summary wasn't prominent, and useful metadata (status/keywords/
whiteboard) was kept separate from that info

In short, the information grouping was not optimal, and it was hard to
process the data rapidly.

-- MIke
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla