Tags are hard to see when the bug description is very long

Bug #249151 reported by Jamu Kakar on 2008-07-16
8
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

See bug #246768 for an example (sorry it's a private one). The bug
description is a somewhat long copy-and-paste from an IRC
conversation about the issue. It's a bit awkward to see which tags
affect the bug because you have to scroll down the page.

I think moving the list of tags above the description would solve
this issue. Putting them in a somewhat fixed position will make it
easier for the eye to quickly jump to the right part of the page to
get the details.

Martin Pool (mbp) wrote :

This bit me too in <https://bugs.edge.launchpad.net/bzr/+bug/346540>.

Any controls located in between the description and the first comment are essentially invisible, for two reasons: they're below the fold for many bugs, and as you page through the bug they're located between blocks of black text and hard to see. Could you just move them up under "Also affects project" etc?

Karl Fogel (kfogel) wrote :

FWIW, +1 on what Jamu and Martin said.

Further justification, if needed:

The reader's eye will naturally search for the first block of
looks-like-human-written text when reader ready. People know how to
skip over things like status lines, tag lists, etc -- all that stuff
goes in the category of "automatically generated information that I
can consult later, after I understand what this bug is about".

So we don't have to worry about the reader finding the description;
they know how to do that.

But the reader will not expect meaningful-but-autogenerated
information between the description and the first comment. After all,
the comments are almost always responses to the description, as with
an email or forum thread. And thread-reading interfaces don't
normally have gunk between the messages; instead, they put all the
gunk at the top or the bottom of the thread as a whole, or in the
differently-colored separator rectangles between messages. We're
violating that principle with the stuff we put between the description
and the first comment, and thus we make it hard to see.

Matthew Paul Thomas (mpt) wrote :

There will always be cases where you think "I wish element X was higher up on the page", where X is something that is not currently at the top.

There are multiple factors in deciding whether one element should be positioned higher than another, and they apply in conflicting ways to description vs. tags.

* Which do people need to read or change more often?
   - People need to read bug descriptions more often than tags.

* Do people need to read or change X more quickly than Y?
   - Doesn't really apply to Launchpad.

* Is one of them small, so that putting it above the other won't increase scrolling much?
   - Tags are usually small, so wouldn't displace the description much.

* Is one of them logically related to something that is already high on the page?
   - The description is logically related to the summary, but already separated from it by the Affects table.

Karl Fogel (kfogel) wrote :

I agree with everything you said. Was merely pointing out that the type of a page element affects how much attention it draws: the positioning of tags vs description is important, but also important is the fact that the description "looks like" dense, high-information content, whereas tags look like the sort of thing one can ignore at first. The skipover cost of tags is low, because it's fixed-size and looks like meta-information; the skipover cost of description is high, because it's variable size and looks like human-generated first-class content.

The worry expressed by Jamu, Martin, and me is that with description first, a reader might not even know that tags exist; whereas with tags first, readers are unlikely to mistakenly think that the description doesn't exist.

tags: added: bugtag
Curtis Hovey (sinzui) on 2010-01-23
Changed in malone:
status: New → Triaged
importance: Undecided → Low
tags: added: ui
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers