<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=683809#user_story_header">https://bugzilla.mozilla.org/show_bug.cgi?id=683809#user_story_header</a><br>
<br>
<p>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.<br>
</p>
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).<br>
<br>
It gets worse when the alternatives put to vote are not clearly and
sufficiently or even wrongly described, which unfortunately applies
for this vote.<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=683809#user_story_header">https://bugzilla.mozilla.org/show_bug.cgi?id=683809#user_story_header</a><br>
<blockquote type="cite">
<pre class="bz_comment_text">[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) </pre>
</blockquote>
<br>
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.<br>
I'll comment more below.<br>
<br>
<div class="moz-cite-prefix">On 11/09/2016 22:57, Jörg Knobloch
wrote:<br>
</div>
<blockquote
cite="mid:0e670f6d-0d81-ccb1-ff5d-134f8040ce66@jorgk.com"
type="cite">
<div dir="ltr">
<div>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: <a moz-do-not-send="true"
href="http://goo.gl/PfLQWL">http://goo.gl/PfLQWL</a><br>
<br>
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".<br>
</div>
</div>
</blockquote>
The picture does not and cannot adequately show the resulting use
patterns / click patterns for a number of scenarios without further
explanation.<br>
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.<br>
<br>
Given that we have proposed [Untagged] and [Tagged] buttons in
various combinations or not, we need to clarify the iconified button
label:<br>
Mark 1 implements an "Untagged" button with active/inactive state.<br>
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)".<br>
Mark 2 implements separate "Untagged" and "All tagged" buttons, each
with active/inactive state.<br>
I'm also missing (dynamic) tooltip definition, which does matter a
lot when it comes to understanding and disambiguating the UI and
behaviour.<br>
<br>
<blockquote
cite="mid:0e670f6d-0d81-ccb1-ff5d-134f8040ce66@jorgk.com"
type="cite">
<div dir="ltr">
<div> <br>
You need to take a good look at what the options do. I'll
describe them below in more detail:<br>
<ul>
<li>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. <i>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.</i><br>
</li>
</ul>
</div>
</div>
</blockquote>
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):<br>
- 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.<br>
- 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".<br>
<blockquote
cite="mid:0e670f6d-0d81-ccb1-ff5d-134f8040ce66@jorgk.com"
type="cite">
<div dir="ltr">
<div><br>
<ul>
<li>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.<br>
</li>
</ul>
</div>
</div>
</blockquote>
Mark 1A, errata: Shift-Selection was never proposed. That's
*right-click*-selection to negate "Has Tag" into "Untagged (does not
have tag)".<br>
<br>
I have already commented on the bug that you have to mention from
what status you start out, and how that status is affected.<br>
I think the behaviour we defined for Mark 1A is this:<br>
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.<br>
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?<br>
<blockquote
cite="mid:0e670f6d-0d81-ccb1-ff5d-134f8040ce66@jorgk.com"
type="cite">
<div dir="ltr">
<div><br>
<ul>
<li>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.<br>
</li>
</ul>
</div>
</div>
</blockquote>
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).<br>
<br>
I think Jörgs proposal Mark 2 (with inspiration by me ;)) provides a
much superior UX:<br>
- provide full tag filter functionality inline (from the tag filter
bar, without requiring to toggle the tag filter bar itself)<br>
- simple show/hide logic without using button morphing or negations<br>
- convenient one-click showing/hiding of untagged messages in
addition to specific tag filters (Kent's scenario)<br>
- preserves existing tag filters unless explicitly cleared<br>
- clear state indicator for both "Untagged" and "All tagged"
(shown/hidden(or not all shown))<br>
- convenient one-click "clear tag filters" functionality by
activating "All tagged"<br>
- 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)<br>
- 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).<br>
<br>
As an example, here's a workflow along Kent's scenario, using "Mark
2" two-button UI:<br>
<br>
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).<br>
Now want to see only messages that are "important" or "urgent"
(click, click), hide "Untagged" (click).<br>
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).<br>
So I'm now seeing "Important", "Urgent", and "Untagged" (including
more candidates for "Important" and/or "Urgent").<br>
Tagging session: Let's tag everything "Important" or "Urgent".
(click, click, click...)<br>
When done, let's get the remaining (unimportant) untagged out of the
way: Hide "untagged" (click). Now showing ALL important and urgent
messages.<br>
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".<br>
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!<br>
<br>
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.<br>
<br>
Thomas<br>
<br>
<blockquote
cite="mid:0e670f6d-0d81-ccb1-ff5d-134f8040ce66@jorgk.com"
type="cite">
<div dir="ltr">
<div> </div>
Jörg.<br>
<div><br>
[1] <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=683809">https://bugzilla.mozilla.org/show_bug.cgi?id=683809</a><br>
[2] <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/attachment.cgi?id=8784342">https://bugzilla.mozilla.org/attachment.cgi?id=8784342</a><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>