Help decide the UI for showing untagged messages in the Quick Filter - Errata and shortcomings of current vote, and why "Mark 2" makes better UX

Thomas D thomasd.bugzilla at gmail.com
Thu Sep 15 20:10:06 UTC 2016


https://bugzilla.mozilla.org/show_bug.cgi?id=683809#user_story_header

I'd like to thank Jörg who is always trying to move us into conclusive 
decisions to speed up progress in development, and fearlessly playing 
with ideas.

However, voting on UX design, as has been mentioned for the last vote on 
"Correspondent" column, is a very arguable strategy with a significant 
risk of NOT getting the best possible UX. Voting assumes that all 
eligible voters are sufficiently familiar with the basic principles of 
UX design, and the full complexity of the particular pros and cons of 
the UX in question, which is not necessarily the case (and some comments 
clearly testify to that).

It gets worse when the alternatives put to vote are not clearly and 
sufficiently or even wrongly described, which unfortunately applies for 
this vote.
I also second Kent's sentiments that we need to start out from clearly 
defined workflows and scenarios for the targeted types of users and then 
build our UX make those workflows work for the intended users in a 
principled and best possible way. Before Kent's comment here, I had 
already added some sample user stories und UX intentions to the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=683809#user_story_header
> [User stories - snip]
> So technically, to cater for those users, ideally this is what we're trying to implement here:
> 1) Filter for "Untagged" messages only
> 2) Filter for "Untagged" OR (Any/All of [tag-x][tag-y])
> 3) Allow switching to "All messages" view without exiting/hiding tag filter bar
> 4) Optionally provide simple way of unselecting/clearing all specific tag filters without exiting/hiding tag filter bar, i.e. single-click return to "All tagged messages" view
> 5) Provide simple and intuitive UI for 1) to 4)

So building good UX is ultimately not a majority decision, but a matter 
of trying to reach best compliance with as many ux-principles as 
possible, also considering their ranked importance, with regards to 
scenarios and their ranking (frequency, importance), and the intended 
users. So variables are plenty... too many as to shrink them into a 
simple vote of two-liners.
I'll comment more below.

On 11/09/2016 22:57, Jörg Knobloch wrote:
> In bug 683809[1], we've had a hard time agreeing on the best UI for 
> showing untagged messages in the Quick Filter. As such, we're putting 
> it to a vote. If you're reading this, please take the poll (it's only 
> one question!) and give us your feedback: http://goo.gl/PfLQWL
>
> The picture is rather detailed, it can be viewed in its original size 
> here [2]. The picture shows how a user would have to use the proposed 
> new button/buttons to see the following sets of messages: "All 
> messages", "All tagged", "Some tagged", "Untagged only" and "Untagged 
> + some tagged".
The picture does not and cannot adequately show the resulting use 
patterns / click patterns for a number of scenarios without further 
explanation.
Depending on scenario, it matters a lot how those buttons behave and 
interact, and how many clicks are needed to get from any given status 
into any other status, and how intuitive those clicks are or not. This 
has not been correctly and sufficiently explored. The full behaviour 
definition and systematic click-pattern evaluation is still outstanding, 
and I will NOT offer that here, but instead focus on some of the most 
obvious points.

Given that we have proposed [Untagged] and [Tagged] buttons in various 
combinations or not, we need to clarify the iconified button label:
Mark 1 implements an "Untagged" button with active/inactive state.
Mark 1A implements a "Tagged/Has Tag" button with active/inactive state, 
plus negated state which changes the button to "Untagged (does NOT have 
tag)".
Mark 2 implements separate "Untagged" and "All tagged" buttons, each 
with active/inactive state.
I'm also missing (dynamic) tooltip definition, which does matter a lot 
when it comes to understanding and disambiguating the UI and behaviour.

>
> You need to take a good look at what the options do. I'll describe 
> them below in more detail:
>
>   * Mark 1: One additional button with two states: When selected,
>     untagged messages are shown in the view, tagged messages are not
>     shown, unless a specific filter is defined. /The downside of this
>     design is that it carries the hidden assumption that selecting
>     untagged messages will hide tagged messages unless they are
>     selected by a specific filter./
>
Mark 1, behaviour as described by Jörg (I translate; maybe Jörg wanted 
to say something else but this is what it currently says):
- If specific tag filters are set, clicking [Untagged] button into 
active state will NOT clear the specific filters: Now showing "Untagged 
+ some tagged", which is (untagged) OR (tagged x) AND/OR (tagged y). 
I'll skip negation for simplicity. Which means you have to manually 
de-activate each and every active tag filter to get "Untagged only". 
That's a potentially unlimited number of clicks to move from "Some tags 
filter" to one of the main scenarios requested by this bug, "Untagged 
only". Similarly, to get "All messages" from within the tag filter bar 
(without hiding the entire bar which is undesired for this type of 
user), you'd have to manually activate each and every single tag because 
by default they'll be hidden when you click "Untagged". The users 
targeted by this feature are somewhat advanced users who a) have tags 
and b) want to FILTER on tags. For such users, anything beyond 2 
(maximally 3) clicks to get from one state to another is inefficient. 
Imo, this violation of ux-efficiency alone disqualifies the proposal 
"Mark 1" in its current design.
- If no specific tag filters are set, clicking [Untagged] button into 
active state will show "Untagged only". Subsequently clicking tags will 
show "Untagged + some tagged".
>
>   * Mark 1A: One additional button with three states. When selected,
>     all tagged messages are shown or an individual filter is active,
>     when shift-selected, untagged messages are shown. Deselecting the
>     button will show all messages.
>
Mark 1A, errata: Shift-Selection was never proposed. That's 
*right-click*-selection to negate "Has Tag" into "Untagged (does not 
have tag)".

I have already commented on the bug that you have to mention from what 
status you start out, and how that status is affected.
I think the behaviour we defined for Mark 1A is this:
If specific tag filters are set, with "Has Tag" also in active state, if 
you then negate "Has Tag" into "Untagged" by right-clicking, all 
specific tag filters will be cleared, to initially show "Untagged" only. 
That's needed because otherwise we'd have the same ux-efficiency problem 
as above, having to manually de-activate each and every tag filter to 
get "Untagged", which doesn't fly.
That's also unexpted and destructive behaviour because there's no reason 
why adding "Untagged" to "Some tagged" should clear/lose the "Some 
tagged" filter. It's implicit "Untagged" OR "Some tagged" so they are 
not mutually exclusive, so why mess with clearing tag filters, only to 
force user to re-build exactly the same filter again if he needs that?
>
>   * Mark 2: Two additional buttons, each with two states. The first
>     button has the function to show all tagged messages, it will be
>     automatically deselected if a more specific filter is set. The
>     second button will show all untagged messages.
>
Mark 2, errata: Button order. First button is [show/hide *Untagged*]. 
Second button is [show/hide *All Tagged*] (upon activation, showing "all 
tagged", hence acting as a convenient "clear filter" button for all 
specific tag filters and reliable indicator for "All tagged" state; upon 
deactivation, hiding "all tagged", hence allowing for "Untagged only" view).

I think Jörgs proposal Mark 2 (with inspiration by me ;)) provides a 
much superior UX:
- provide full tag filter functionality inline (from the tag filter bar, 
without requiring to toggle the tag filter bar itself)
- simple show/hide logic without using button morphing or negations
- convenient one-click showing/hiding of untagged messages in addition 
to specific tag filters (Kent's scenario)
- preserves existing tag filters unless explicitly cleared
- clear state indicator for both "Untagged" and "All tagged" 
(shown/hidden(or not all shown))
- convenient one-click "clear tag filters" functionality by activating 
"All tagged"
- after "hide all tagged", purely incremental tag filtering possible 
(starting from no messages instead of all tagged messages, where first 
click reduces and subsequent clicks expand results)
- efficient and intuitive click patterns for changing from any state 
into any other state; many state changes require only a single click; 
state changes never require more than 2 clicks (with negation), or 3 
clicks (without negation).

As an example, here's a workflow along Kent's scenario, using "Mark 2" 
two-button UI:

Start out from "All messages": Show "Untagged" (click), if necessary 
show "All Tagged" (click). UI indicates that status reliably and 
compactly on the two leading iconic buttons, without having to scroll 
the whole tag filter bar for hidden filters (remember if there are more 
tags than fit on the bar, they'll be hidden, but might have active filters).
Now want to see only messages that are "important" or "urgent" (click, 
click), hide "Untagged" (click).
But wait a minute, today's messages haven't been tagged yet (or that 
particular important message I was looking for doesn't show), so there 
might be other important or urgent messages that just haven't been 
tagged yet. Let's add those untagged thingies: Show "untagged" (click), 
in addition to the tagged subset already chosen (which conveniently 
stays around).
So I'm now seeing "Important", "Urgent", and "Untagged" (including more 
candidates for "Important" and/or "Urgent").
Tagging session: Let's tag everything "Important" or "Urgent". (click, 
click, click...)
When done, let's get the remaining (unimportant) untagged out of the 
way: Hide "untagged" (click). Now showing ALL important and urgent messages.
Charmingly, we also allow negative tag filters, so to get everything 
"potentially relevant" including "important" and "urgent", I could also 
negate "--Later--" (right-click) "--Next week--" (right-click) 
"--Smalltalk--" (right-click), then additionally show "Untagged" 
(click), and have a full view of everything "tagged relevant" and 
"potentially relevant, but not yet tagged".
To get rid of my tag filters and back to "All messages", simply show 
"All tagged" (single click to clear all tag filters!) (in addition to 
"Untagged" which is still active) - done!

Having said which, I'd really want to test this "live" before final 
conclusions, because it's pretty hard to just imagine all the status 
transitions, and it's easy to overlook something.

Thomas

> Jörg.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=683809
> [2] https://bugzilla.mozilla.org/attachment.cgi?id=8784342
>
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20160915/d3ee7c83/attachment-0003.html>


More information about the tb-planning mailing list