462488 - Re-order the UI of show_bug.cgi

Status: RESOLVED INCOMPLETE

(Bugzilla :: User Interface, enhancement, P2)

Description

[Max Kanat-Alexander]

Ideally, the description of a bug should be above the fold, and the basic information about a bug should be displayed in some way that's easily readable by the average Bugzilla user. Then we should put the edit form at the bottom, with the comment box positioned in such a way that it's easy to make any important edit and then comment on it.

Comment 1

[Max Kanat-Alexander]

Attachment: v1

Here's the patch that I had posted last on bug 452888 (which is the bug that originally spawned this bug).

Comment 2

[Max Kanat-Alexander]

Attachment: v2

OK, I talked a bit with mconnor and he had a really good idea about what to do with the table at the top, so I've changed things now.

Comment 3

[Max Kanat-Alexander]

There's an install with the latest patch applied at http://landfill.bugzilla.org/mkanat3/show_bug.cgi?id=2323 (also linked in the URL field).

Comment 4

[bigstijn]

Hm, this is a indeed a huge change in UI .
But after a while, I had to agree that this has idea has a future.

But I would'nt use the "sentence layout":
Reported against WorldControl  1.0  (Component: WeatherControl) by Max Kanat-Alexander [:mkanat]  on 2005-01-08

In table form, your eyes are trained to catch the information.  In such a sentence, this is much more difficult.

Why not taking the table of "Format for printing" (with the new labels/order of field) with these remarks:
- remove the bold for field labels
- use the same relative position to each other for fields : 
(summary is above)
product : ..            reporter : ..
component: ..           assignee : ..
status : ..             qa-contact: ..
importance : ..         
flags

Besides: I do agree with bug 452888 comment 32 about "another layout schema to learn".  I would try to keep the "format for printing", the upper box and the details below quite similar (same relative position of fields) (eg. importance on format for printing, but that would be a different bug).

Comment 5

[Max Kanat-Alexander]

I had them in a table originally, don't know if you saw v1 above. The change from v1 to v2 was actually to the sentence layout, which mconnor suggested.

Comment 6

[Max Kanat-Alexander]

Attachment: v3

I solved the summary edit box problem! I created a magical textarea that behaves line a multi-line text-input, using JavaScript. The non-JS case still works--people will just have their newlines and extra characters stripped from the field.

Comment 7

[Frédéric Buclin]

(In reply to comment #5)
> I had them in a table originally, don't know if you saw v1 above. The change
> from v1 to v2 was actually to the sentence layout, which mconnor suggested.

I think mconnor is wrong. This is in no way an improvement. You seem to focus on newbies while Bugzilla is designed for "intermediate" users, i.e. users with some experience, even without being experts. Bugzilla must be designed for those who use it and need to work with it on a regular and frequent basis. A sentence is in no way a good UI design to display information. And it also makes localization even harder.

I agree with bigstijn, a table is much more readable than a sentence (for both humans and computers. /me has Selenium in mind.). I strongly opposed to patches v2 and v3.

Comment 8

[Marc Schumann [:Wurblzap]]

Here's my vote for a table. Please don't use a sentence layout. It's a nightmare in UI, edge case, localization and readability terms.

Comment 9

[Frédéric Buclin]

Comment on attachment 345688 [details] [diff] [review]
v3

As I said above, using sentences to display information is the wrong way to go. This wrong direction is also confirmed by comments from wurblzap and bigstijn.

Comment 10

[Reed Loden [:reed]]

Attachment: screenshot of v3 on 1024x768 screen

Depressing.

Comment 11

[Mike Connor [:mconnor]]

You're saying that people understand and parse tabular data faster than sentences?  Awesome, I can't wait to stop speaking in complete sentences and just express everything in table form!

Comment 12

[Marc Schumann [:Wurblzap]]

That's not what I'm (we're?) saying. Tables make it easier to find the information I want, at a glance. Sentences convey the whole bundle, provided I take the time to parse it all.

Comment 13

[Frédéric Buclin]

(In reply to comment #11)
> You're saying that people understand and parse tabular data faster than
> sentences?

Absolutely! When talking about displaying data, there is no doubt about that. Just read a scientific report, any analysis of any kind, data are always displayed in tables or in graphs. When you do a presentation using Powerpoint, you enumerate things in a list, one item per list, i.e. one item per line, etc... Making a sentence or two with all the data in it is no sense.

Comment 14

[Mike Connor [:mconnor]]

As a note, the sentences I proposed were much more human-readable than what's up there, and the alignment is weird.  What I proposed is something like:

Reported in: World Control > Weather Control by Some Guy
Status:      ASSIGNED to Some Other Guy as a P1 blocker for Bugzilla 4.0

The second line combines five individual fields (status/assignee/priority/severity/target milestone) into one line.  You read one sentence and you know the current status.  The idea that information density and natural language is a UI nightmare is rather disturbing to me... what are you basing that on?

Comment 15

[Mike Connor [:mconnor]]

(In reply to comment #12)
> That's not what I'm (we're?) saying. Tables make it easier to find the
> information I want, at a glance. Sentences convey the whole bundle, provided I
> take the time to parse it all.

The question is whether the component pieces have value without the rest of the context.  In most cases, they don't.  I won't disagree that for finding one out of five datapoints, a tabular layout is better.  Is your argument that you are most frequently looking for partial context, not all of the context? 

(In reply to comment #13)
> (In reply to comment #11)
> > You're saying that people understand and parse tabular data faster than
> > sentences?
> 
> Absolutely! When talking about displaying data, there is no doubt about that.
> Just read a scientific report, any analysis of any kind, data are always
> displayed in tables or in graphs.

I don't see a lot of tables with a single row of data.  Graphs and tables are useful for comparative analysis, but are not as useful for displaying a single set of data with no comparison.  There's cognitive overhead involved in comprehending the structure of the table, which works for multiple sets of values because that gets spread across multiple rows, and the table layout lets you scan and compare data.  No one creates a spreadsheet to show a single row of data.

> When you do a presentation using Powerpoint,
> you enumerate things in a list, one item per list, i.e. one item per line,
> etc... Making a sentence or two with all the data in it is no sense.

This is not enumerating things in a list, its not a list.  Its a set of distinct values which combine to form a picture.  And if you're arguing for Powerpoint as the basis for your design reasoning, its obvious you haven't read enough Tufte, and don't understand why information density is critical in design.

Comment 16

[Marc Schumann [:Wurblzap]]

I attached a mockup of what I'm thinking to Max' mockup bug. It works upon the good ideas of v3.

Comment 17

[Frédéric Buclin]

(In reply to comment #14)
> Reported in: World Control > Weather Control by Some Guy
> Status:      ASSIGNED to Some Other Guy as a P1 blocker for Bugzilla 4.0

You take the example which is the most human-readable. What about:

  Status:   RESOLVED INVALID to Nobody OK to take it as a -- normal for ---

Don't tell me that's readable.


> what are you basing that on?

I'm basing this on the tens or hundreds scientific articles and reports I read on a regular basis. The data I can easily find and read/parse is the one being in tables (or graphs). Sentences are a support to explain and analyse data (for Bugzilla, those are comments), but the data itself is always displayed in tables/graphs first. When talking about bug reports, this schema remains valid.

Comment 18

[Mike Connor [:mconnor]]

To be clear, I am trying to find an alternative to a heading-heavy layout because it wastes space and requires ignoring a lot of labels.  I'm throwing out a solution, but if someone has another solution that solves the problem, that's great.

To be even more clear: if 50% of your text is stuff users have to mostly ignore to read quickly, its not really a good UI.  For editing, labels are good, especially if there's helpful explanatory links, but for pure information display, only label what has to be labeled.

Comment 19

[Mike Connor [:mconnor]]

(In reply to comment #17)
> (In reply to comment #14)
> > Reported in: World Control > Weather Control by Some Guy
> > Status:      ASSIGNED to Some Other Guy as a P1 blocker for Bugzilla 4.0
> 
> You take the example which is the most human-readable. What about:
> 
>   Status:   RESOLVED INVALID to Nobody OK to take it as a -- normal for ---
> 
> Don't tell me that's readable.

Its not.  You're munging the sentence, and assuming that the resolved status would use the same structure.  Priority and severity don't matter when resolved, for one.  Something like:

Status:  RESOLVED INVALID by Some Guy on 2008-10-30

or for FIXED

(if TM is set)
Status:  RESOLVED FIXED by Some Guy for Bugzilla 4.0
(otherwise)
Status:  RESOLVED FIXED by Some Guy on 2008-10-30

> > what are you basing that on?
> 
> I'm basing this on the tens or hundreds scientific articles and reports I read
> on a regular basis. The data I can easily find and read/parse is the one being
> in tables (or graphs). Sentences are a support to explain and analyse data (for
> Bugzilla, those are comments), but the data itself is always displayed in
> tables/graphs first. When talking about bug reports, this schema remains valid.

That's a weak argument.  Are you really reading articles that have a single row of data in a table?  Fail.

Comment 20

[Frédéric Buclin]

(In reply to comment #15)
> The question is whether the component pieces have value without the rest of the
> context.  In most cases, they don't.

They do. Data you are looking for depend on the context.


> of five datapoints, a tabular layout is better.  Is your argument that you are
> most frequently looking for partial context, not all of the context? 

It depends what you try to do. When doing triage, I want to have a global overview. For projects I'm heavily involved with, I most of the time want to know every details of a bug, but in this case sentences are not suitable.


> I don't see a lot of tables with a single row of data.

I never said that. You are extrapolating what I'm saying.


> you scan and compare data.  No one creates a spreadsheet to show a single row
> of data.

Again, I never said that.


> This is not enumerating things in a list, its not a list.  Its a set of
> distinct values which combine to form a picture.

I don't see why this distinction is important; really. You like playing with words.


> Powerpoint as the basis for your design reasoning, its obvious you haven't read
> enough Tufte, and don't understand why information density is critical in
> design.

Again, you choose parts of what I'm saying to distor my purposes. Where did I say PowerPoint is the basis of my design reasoning?

Comment 21

[Frédéric Buclin]

(In reply to comment #19)

> Its not.  You're munging the sentence, and assuming that the resolved status
> would use the same structure.

OK, tell me where in the patch is the bug status/resolution used to display context-dependent data?


> That's a weak argument.

Really? Interesting! You are just ignoring how real scientific articles are written.

Comment 22

[Marc Schumann [:Wurblzap]]

Attachment: Mockup

This screenshot is an idea of what I'd like. Each row corresponds to a sentence, but is built up (mostly) statically.

Comment 23

[Guy Pyrzak]

(In reply to comment #22)
> Created an attachment (id=345731) [details]
> Mockup
> 
> This screenshot is an idea of what I'd like. Each row corresponds to a
> sentence, but is built up (mostly) statically.

I think I'd like to see use of various typography to better illustrate the information, notice in your mock the things that pop out are the assignee, the reporter and the qa (because they have different font). I think we need to be careful with this technique that the right information pops out and the reader's eye is drawn in the right direction.

Comment 24

[Guy Pyrzak]

Attachment: How we use sentences with our flags

So here is an example of how we represent flags to make it easier for folks at NASA to understand them. Things to note, different fontweight and colors for different types of information as well as use of spacing to guide the user through the sentence. Realize on some records we have a dozen or more of these flags so having information laid out like this is helpful.

Comment 25

[Max Kanat-Alexander]

(In reply to comment #10)
> Created an attachment (id=345714) [details]
> screenshot of v3 on 1024x768 screen

  That's no different from how the normal UI looks in Dusk at 1024x768.

  In terms of everybody else's comments:

  First, let's assume that pyrzak and mconnor, as HCI & UI experts, have a better theoretical background to make these decisions than we do.

  Overall, the guiding principle here should be:

  1) Data is always better than opinion. Informed opinion is better than uninformed opinion. The more informed your opinion is, the better.

  In that sense, mconnor has the most experience delivering broadly-used user-facing UIs, in this discussion. So he has an informed opinion on that subject. Both pyrzak and mconnor have an excellent theoretical grounding in HCI. So they both have informed opinions on that subject. I have worked with more Bugzillas than anybody involved in this discussion (including many closed corporate Bugzillas, which few other people have extensive experience across organizations with), so I have an informed opinion on that subject.

  I'm sure that others have informed opinions on other areas that would be valuable.

  However, almost any valid research data would trump *any* of our opinions. I heard that pyrzak was going to be doing some research, and Boriss offered to possibly interview and study some at MoCo (which would probably not be a suitably broad audience, but would be WAY better than no data).

  2) It's more important to be usable than to be pretty.

  I would rather waste space and be easier to use than to cram a lot of information on to one screen. The basic problem of all historical Bugzilla UIs is that they cram too much information into too small a space.

  I would rather be ugly as sin and be extremely readable than be beautiful and unusable. Ideally we'd have both (accomplished through simplicity like a lot of Google UIs), but if we can't have both, all I care about is the overall actual usability.

  3) This is a bug-tracker, not a forum.

  Please don't make snippy comments at each other, no matter who you are. If you are attacked with a snippy comment, don't respond. If you feel the urge to write a snippy comment, walk away from the computer or go do something else for a while.

  I understand that the UI of show_bug is kind of a sensitive subject--it matters a lot to all of us. Some of us probably spend more time looking at show_bug.cgi than we do with our loved ones. :-) But we'll come out with the best result by cooperating and finding what's best about each person's suggestions, not by baiting others or just criticizing faults. Let's focus on what we can get that's positive out of each suggestion, and ideally, let's get some real data to back it all up.

Comment 26

[Max Kanat-Alexander]

By the way, Wurblzap--thanks for the mockup, it's a definite possibility. Any reason that you favor it over the table from v1 (if you saw that)?

Comment 27

[Guy Pyrzak]

There is a group of HCI students at CMU studying and doing various HCI methods on Bugzilla. I'll have the data for everyone around the beginning of December. I plan on posting it to the bugzilla wiki as soon as I've got the data from them.

Comment 28

[Jennifer Morrow [:Boriss] (UX)]

Re Comment 27 - That's awesome Guy, can't wait to see what they come up with.

Comment 29

[Vitaly Fedrushkov]

[after reading IRC on a topic]

On usability: bmo already has two bug entry forms, for newbies and advanced users.  If we distinguish readers (random, often anonymous) from serial bug killers, different requirements can be addressed with different rendering.

Space waste: "forms" approach dictates that "some value is always in left lower corner".  IHMO it is valuable for heavy workloads like help desk operators.  Also "forms" imply all data are editable.  "Natural language" approach seems useful for search-and-read "knowledge base" users, with no need to edit attributes.

Can this "View/Edit" difference be addressed like other "Collapse/Expand" cases?

Sentence vs. fixed attribute set (in reply to comment #20):
> > The question is whether the component pieces have value without the rest of the
> > context.  In most cases, they don't.

> They do. Data you are looking for depend on the context.

Let's consider 'units of sense': Status/Resolution is a single unit, however one or two or five database attributes.  Flag is another single unit, as shown in attachment 345735 [details].  Many things will always be separate units: try to compose a sentence from keywords and URL :-)

Number of fields contributing to single unit may change along workflow path.  Notion of FIXED eliminates need for RESOLVED for example, and target milestone may indeed lose its value for a closed case.  The only workflow with constant set of attributes is a vote.

Units should retain their relative positions, here I agree with table layout advocates.  But single unit may be rendered as sentence of more or less complexity.  BTW this has been used in Bugzilla for ages, look at DUPLICATE.

P.S. pyrzak: sorry for not using 'perception' instead of 'sense' ;-)

Comment 30

[Vitaly Fedrushkov]

A message for UE from l10n:

(In reply to comment #7)
> And it also makes localization even harder.

Having sentences composed from words doesn't make localization any harder by itself.  It is 'assembly language' approach which does.

Bad: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fwebtools%2Fbugzilla%2Ftemplate%2Fen%2Fdefault%2Fglobal%2Fuser-error.html.tmpl&rev=&cvsroot=%2Fcvsroot#1217

Good (not actual code):
  [% if bug.status == "ASSIGNED" %]
    Assigned to [% bug.assignee %] with priority [%...], etc 
  [% ELSIF bug.status == "RESOLVED" & bug.resolution == "FIXED" %]
    Fixed by [% bug.assignee %] on [% date %], etc.
  [% END %]

Also in table rendering one can't rely on any visible texts, static or cooked as above, being compact.  See bug 434701, bug 463965, bug 465041.  Expect any cell to be wrapped.

And of course you can ask l10n people to test prospective changes, as they are deployed on landfill.

Comment 31

[Guy Pyrzak]

So this bug hasn't had any activity on it since 2008. I'd like to pop it back up on the stack. 

Based on TidyBug and some other stuff I've been looking at I'm going to see what i can do to help make the UI more compact. 

I'll leave this bug assigned to mkanat. The goals of this new UI would be:

- Get 1st comment above the fold.
- Increase the information density
- Make it so the page can be changed via skin to be more or less compact.

Unfortunately the student project didn't have any feedback/research on this but they were not really focusing on the edit bug page. Once we complete the other research we might want to have a project that focuses on search/triange/edit.

Comment 32

[Max Kanat-Alexander]

Attachment: Screenshot of v3 (Sentences)

Here's a screenshot of a full page under Patch v3.

Comment 33

[Max Kanat-Alexander]

Attachment: Screenshot of v1 (Table)

Here's a screenshot of Patch v1 (with a table instead of sentences). I actually somewhat prefer this version (because it's more adaptable to various uses, and clearly labels fields), although I think the CSS formatting that I used for sentences is better.

Comment 34

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 35

[Kohei Yoshino [:kohei]]

Bugzilla 6.0 will ship with the new modal UI created for BMO, so this is no longer the case.