452954 - combine status and resolution selects into one

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement, P4)

Description

[Tuukka Tolvanen (sp3000)]

(spun off bug 452806 comment 3)

With the separate selects for status and resolution in bugzilla 3.2, it takes four clicks to, say, set "new" to "resolved invalid" as opposed to the previous two clicks with radio+single select (presumably three without script as you'd have to select the radio manually). I also see an apologetic link to "Mark as Duplicate" which tells me this isn't news.

Why not combine these into a single status+resolution select? This would get back to two clicks, and also avoid the nonsensical combinations that are possible without js enabled such as "assigned worksforme" at bmo.

Comment 1

[Max Kanat-Alexander]

We considered that. I personally think the current system is a bit more discoverable for people who aren't extremely familiar with Bugzilla. Also, with all the possible resolutions for all the possible closed states, the select would be very very long.

Comment 2

[Frédéric Buclin]

I agree with mkanat. I'm strongly in favour of WONTFIX'ing this bug. Note that the current UI is only a two-clicks step, not four, as you don't need to release the mouse button when selecting the status or resolution. ;)

Comment 3

[Justin Dolske [:Dolske]]

I don't understand what 2 fields has to do with discoverability. If anything, having 2 controls which alter each other is more confusing than just a single control.

The single control wouldn't be very long. A bug in a normal state, like this would, would have 9 entries. That's less than the number of selects in many other Bugzilla controls, and the state names / ordering helps too (generally transitions are +/- 1 step).

It may only be 2 clicks vs 1, but the last BMO UI cleanup took a lot of care to optimize click counts. In a heavily used UI, needless extra clicks gets old really fast.

Comment 4

[Justin Dolske [:Dolske]]

(haha, oops, forgot I was playing with the state controls! :-).

Comment 5

[Frédéric Buclin]

number of closed states x number of resolution >> 9. And that's assuming we don't add more resolutions or states in the future.

Comment 6

[Tuukka Tolvanen (sp3000)]

Another point, the two selects fail pretty badly noscripted; this bug is currently "UNCONFIRMED resolved as FIXED duplicate of [    ]". The 'duplicate' part I can live with, but the FIXED is pretty darn distracting. Other solutions to that come to mind (not necessarily good ones), but combining status+resolution would certainly do fine in that regard.

(In reply to comment #1)
> We considered that. I personally think the current system is a bit more
> discoverable for people who aren't extremely familiar with Bugzilla. Also, 

More discoverable than what? Say, if I want to simulate noobness and try to follow an instruction to "mark that bug invalid" I might say "uh, there's no 'invalid' in any list, just one with unconfirmed new assigned resolved". Someone might need to feed me the combined term as "resolved invalid" or "resolve it invalid" so the separate fields would seem to present things less discoverably than the suggested combined select. In both the old ui and the suggested ui, unlike the two-select ui, in an open bug the resolutions are available in an element that is not initially hidden.

(In reply to comment #2)
> the current UI is only a two-clicks step, not four, as you don't need to
> release the mouse button when selecting the status or resolution. ;)

If you're just having fun with this bit, then fine ;) but two drags is a signifigantly greater effort than two clicks so that would not be an honest comparison. I'm an escalator, not a doctor (...or something), but personal experience suggests that four clicks is healthier than two drags, repeated over time.

(In reply to comment #5)
> number of closed states x number of resolution >> 9. And that's assuming we
> don't add more resolutions or states in the future.

OK, so a resolved incomplete bug has 13 available combinations here, which falls into > 9 but hardly >> 9; also hardly into the ballpark of dauntingness. I have seen instances with more closed states and resolutions, but I'd argue users of such systems lose more to overengineered process bondage than potential list overload here. I have to agree it'd look very silly though :\ 

Maybe there's room for some sort of ui variation based on current state being closed or not? IOW, one combined select when the current state is an open state to make the resolutions discoverable and to avoid the ungraceful noscript degradation; two selects when the current state is a closed state to contain the transition explosion. Slightly more interesting from the POST perspective but that's not something users have to deal with :)

Comment 7

[Guy Pyrzak]

ok, first off, if we're going to play the "how many clicks" game (which i agree is fun), I will first off say change all drop downs into auto completes. Typing is much faster than clicking (yay Fitts Law & KLM). 

If we want to say which is better a list of 9+ elements vs 2 lists of elements, we can make some cognitive models or we can say... typing is still faster. 

But then the question is, which is more discoverable? 2 Drop downs or 1? Again, shrug. So I propose a thumb war!

As far as the noscript folks. The heuristic (as i understand it) for noscript is that it must function, not that it be very usable or nice looking. And well it still functions fine.

Comment 8

[Tony Mechelynck [:tonymec]]

Most statuses never have a resolution. Resolution are normally set when changing the status to RESOLVED, then they may later become VERIFIED. CLOSED or EXPIRED are usually not set from the bug-handling page. So I propose one combined rolldown:

[UNCONFIRMED|V]
 NEW
 ASSIGNED
 FIXED
 INVALID
 WORKSFORME
 INCOMPLETE
 DUPLICATE............ of [           ]
 REOPENED

with an additional button [ Verify this bug ] when appropriate.

Not all states would ever be present together: once EverConfirmed has been set, the bug can never again be UNCONFIRMED, and once a bug ha

Comment 9

[Tony Mechelynck [:tonymec]]

...hit something by mistake which submitted the bug too fast...

...UNCONFIRMED, and IIUC, NEW and REOPENED never appear together.

Comment 10

[Wayne Mery (:wsmwk)]

A peripheral accessibility perspective and irksome workflow bug (which deserves a separate bug - didn't find one and didn't create it yet) ...

at least in the current bmo instance, when one keyboards via Tab from comment to status and picks resolved, then a) next Tab should hit the Resolution select and b) Tab from resolution should hit the Commit button. But this doesn't happen. 

xref bug 282612  add accesskeys for changing bug status, resolution, duplicate #, assignment target or commit button.

Comment 11

[Wayne Mery (:wsmwk)]

Yesterday I didn't feel like I had an opinion on the substance of this bug. Today, it being the early hours and I'm still in an irritable state, I'm thinking, YES, why not!  

For someone who closes a lot of bugs and thus touches resolution, combining into one action would be a nice time saver (maybe even save someone from RSS? :) ).  Currently using it's at least 4 actions plus commit - not just two clicks plus click as suggested above.  It would also mitigate a little the issues of comment 10. 

However, one's perspective on this bug is, or should be, related to how one uses bugzilla.  I'm not sure yet about how to address the concerns of new users. But for sure, having resolution default to FIXED is a non-starter. Perhaps having WORKSFORME (or simply WORKS) higher in the food change would help.  (OTOH, if this bug doesn't pass muster, perhaps resolution should be either context sensitive or have configurable default. For example it's unlikely a bug would go from unconfirmed to FIXED, or that a user without privileges would be changing a bug to FIXED ... WORKSFORME is far more common. Don't beat me - it's early, and I haven't entirely thought this through.)

Comment 12

[Tony Mechelynck [:tonymec]]

In reply to comment #11
I agree: An unprivileged user modifying a bug would have to be the reporter, and in most (though not all) cases someone with no Mozilla programming abilities: so IIUC such a user would, if setting a bug to RESOLVED, either set the resolution to WORKSFORME ("the bug has spontaneously disappeared") or, maybe less often, to DUPLICATE ("I have belatedly found another bug for the same problem").

Someone with canconfirm privs modifying an UNCONFIRMED bug might set it to NEW ("I confirm this bug")

Someone with canconfirm+changebugs might also set it to NEW, but also (as a triager) to INVALID, INCOMPLETE, WORKSFORME (again), DUPLICATE (again), or even (as an owner or peer, which is less frequent) WONTFIX. So in all the above use-cases, going straight to FIXED is possible but unlikely.

OTOH, once the bug is ASSIGNED, the assignee would probably someday change it to FIXED.

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to comment #11)
> Yesterday I didn't feel like I had an opinion on the substance of this bug.
> For someone who closes a lot of bugs and thus touches resolution, combining
> into one action would be a nice time saver (maybe even save someone from RSS?
> :) ).  Currently using it's at least 4 actions plus commit - not just two
> clicks plus click as suggested above.  

[correction] two clicks plus commit

> However, one's perspective on this bug is, or should be, related to how one
> uses bugzilla.  I'm not sure yet about how to address the concerns of new
> users. But for sure, having resolution default to FIXED is a non-starter.
> Perhaps having WORKSFORME (or simply WORKS) higher in the food change would

[correction] food chain

Comment 14

[u430950]

I can see how this option may benefit those without complex resolution values. Confirming bug.