516170 - [faceted search] need better understandability of the faceting controls

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Thomas D. (:thomas8)]

First of all, congrats on gloda faceted search and "search everywhere" bar. This looks really promising!!!

It took me a while to figure out what actually happens when in a faceted search result, I click on one of the people involved. Part of the confusion is that the hover-image is exactly the wrong way round at the moment:

Current behaviour / steps:
- initial hover over one person of multiple involved list shows "exclude"-Icon, which looks like the traffic sign for "no parking here" (/). but if you click on that person it is actually filtered FOR (singled out) and remains INcluded as the only involved person.
- hover over one of those "other participants" (which might be more clearly labelled "excluding:"?): again, you get "exclude this"-Icon (/). But what actually happens when clicking is that you INclude the person in the involving-list (although you are removing it from the "other participants"-list).
- hover over one out of several(!) involved people (after excluding "other participants(!)): you get normal hover (highlighted background only), but what happens is that you will EXclude that person on click.

In other words: all of these hover-effects are exactly the wrong way round. Or maybe I am missing something...

Of course another question which needs to be decided in this context is the behaviour when clicking one person out of the original search result list of "involving any of": Either
- FILTER FOR (SINGLE OUT) that person, i. e. make it the only one "involved" (current behaviour) OR
- EXCLUDE that person from the "involved" list and move it to the "other participants" list.
Honestly, I don't know which behaviour I'd prefer.

Expected behaviour:
- whenever I exlude a person from my matches, show exclude icon (/) on hover
- whenever I (re-)include a person from the "other" participants list, do NOT show an exlude-icon
- decide for one behaviour when clicking on person of initial list of involved people, and choose hover-effect/icon accordingly

P.S. what component is faceted search?

Comment 1

[Thomas D. (:thomas8)]

That was reported against
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090911 Shredder/3.1a1pre

Comment 2

[Thomas D. (:thomas8)]

Without deeper thoughts, I assume what we want for reasons of consistency is "always (re)move clicked person to the other part of the list".
- initial list of "involving any of..."-people: click will remove that person from matches=involving-list (this would be different from current behaviour, but more consistent)
- list of "other participants": click will remove that person from "other participants", i. e. move it back into "involving..."
- list of "involving": again, click will remove that person from matches=involving-list

Comment 3

[Thomas D. (:thomas8)]

Nominating blocker. Regardless of the details, some aspects of this are so wrong that people won't know what they are doing when they see the wrong icon on hover. Especially for initial situation: With multiple involved persons list, we can't show an "exclude this person from search results" hover icon when the action on click is "exclude *all other* persons from search result". It's a bit like putting a delete icon on a save button.

We'll also need tooltips for this, but that's a different issue for another bug.

Comment 4

[Thomas D. (:thomas8)]

There's is an inherent ambiguity in the current "exclude this" icon:
a) with respect to a list of currently included (e. g. "involving...") facets, "exclude this" icon means --> show less results
b) with respect to a list of already excluded ("other") facets, it's unclear what "exclude this" icon means: does it mean
"exclude/remove this facet from *this list*" --> that will show MORE results
but it could also mean the same as in a) (user expects consistency in the icon meaning)
"exclude this facet from the search result" --> that would show LESS results which is part of the contradition this bug tries to uncover.

One possible way of solving this logical problem would be to use a different set of icons on hover, e.g. a magnifier icon (symbolising search) with a small + or - in bottom-right corner

-O     magnifier: filter for this (single out)
-O (+)   magnifier with + in the corner: add this facet to current filter
-O (-)   magnifier with - in the corner: remove this facet from current filter

Comment 5

[Thomas D. (:thomas8)]

This applies to any facet that works like "People" facet, e.g. "Folders" facet.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Depending on the solution chosen, this may have l10n impact, so it makes sense to assume that it does until we know otherwise.  I've adjust the status whiteboard according.

Comment 7

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm going to look into some changes we can make here before the freeze

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

Thanks for the comments Thomas.  I'll try to explain the design of the include /  exclude facets so that we're on the same page because I'm not really sure what you're proposing.

The default option for clicking on a person's name includes them.  Including means you want search results that have this person.

However it's also possible to exclude someone from the search results list.  This option is less used than the inclusion because it's often a larger operation for people to process.  Essentially people are looking for a set of knowns and unless it's immediately obvious that something should be excluded people stick to including the knowns.

So the UI as you see tries to offer these options with those goals in mind.  When you hover over a person we show the (/) exclude icon as gray / inactive to indicate that you could exclude that person.  This exclude icon only becomes active when you hover over it.  However what I understand you're seeing (and likely others will as well) is that it looks like we're suggesting that clicking will exclude the person because you can clearly see the icon on hover.

I had planned to use a different icon on hover instead of a version of the exclude icon.  Something that just indicates "-> look over here" like an empty ( ) circle that when hovered shows the (/) exclude.

I'm not sure if I understand your proposal correctly but the plus / minus gave me this idea to try.  Show a (+) icon that when hovered over the whole item but when hovered over the icon itself it becomes a (-) icon instead.

e.g.
------------------------
Person                  
------------------------

on mouse hover 
------------------------
Person /\            (+)
--------\---------------

on mouse hover of (+)
------------------------
Person               (-)
----------------------/\-
                       \

Does that make sense?

Comment 9

[Thomas D. (:thomas8)]

Bryan, thanks for coming back to this. WOW, THANKS, I don't believe this: To this very minute I wasn't aware AT ALL that the "exclude" (/) icon is actually a separate spot to click on. I am totally amazed, as for the first time I now see how this has been designed to work, and for the first time I actually see how an exluded person looks. To this minute, as I had not discovered the tiny exclude spot was actually something to click on, I had not seen striked-through persons, ever, nor had I ever realized that this (/) icon changes color on hover. IOW, even though the behaviour that I see now seems technically correct, I suppose we DO have severe usability issues here. If this isn't clear for advanced users, then what for the average user?
I'll let that sink in... You should re-read my comments here based on the fact that I had no awareness at all of the separate exclude-icon functionality. Put yourself into that position (i. e. only hover over middle of a person's name), then you'll understand all the seemingly weird comments that I left above.

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

Here's another alternative approach that has both the plus and minus on different sides.  This one causes a left indent that I'm going to have to work out visually but I think that could be possible.

Normal person view
------------------------
    Person                  
------------------------

on mouse hover - the plus appears lit up, the minus appears as a faint circle
------------------------
(+) Person /\        ( )
--------\---------------

on mouse hover of right ( ) - the plus changes to the faint circle and the minus lights up.  We also create a strike through on the text to further indicate what is going to happen.
------------------------
( ) -Person-          (-)
----------------------/\-
                       \

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

Will try something out over the weekend, need to have a clear concept and then still some time to make it happen.

Comment 12

[Simon Paquet [:sipaq]]

What is the status here? We need to gt to this ASAP because of the upcoming string freeze for TB3 tomorrow night.

Comment 13

[Thomas D. (:thomas8)]

Bryan, for the string freeze what's most needed will be tooltips for filtering for / including / excluding a facet.

Most basic tooltips that could be used for different sorts of facets (people, folders, etc.) would be:
1) "Filter for this facet"
(for the action that singles out one facet as "involving", while all others go to "other" facets)

2) "Include this facet"
(for the action that moves a facet from "others" to "involving", or from "excluded" to "involving" which doesn't work, bug 519215)

3) "Exclude this facet"
(for the action that makes a facet "not involving")

Even if you're not ready yet with the coding, I propose just getting these 3 strings in just in case.

Comment 14

[David Ascher (:davida)]

We've regretted pushing strings in in advance of code in the past, so I think we want to try and get as much of this done in the next 36hrs as possible.

Note that we will need some smarts to do tooltips, as for reasons which will always escape me, HTML tooltips aren't readily applicable to all elements. 

I'll coordinate w/ bryan today.

Comment 15

[Thomas D. (:thomas8)]

Bryan, I am not yet totally grasping the concept, as there's two much unexpected behaviour. E.g. I still fail to understand why clicking on the only remaining "included" facet will bring all "other" or "not involving" facets back into "included". Since I don't fully understand the behaviour, I cannot really judge if your improvements of comment #10 will help. I guess it's the right direction. It may still be difficult for people to realize that clicking on that faint icon on the right will actually DO something /different/ from clicking in the middle. Maybe it would help to show the facet with something like a split-button effect on hover:

Normal person view
------------------------
    Person                  
------------------------

> on mouse hover - the plus appears lit up, the minus appears as a faint circle
plus add a visual indication that this acts like a split button: 
--------------------+---
(+) Person /\       |( )
--------\-----------+---

> on mouse hover of right ( ) - the plus changes to the faint circle and the
> minus lights up.  We also create a strike through on the text to further
> indicate what is going to happen.
probably on hovering the "exclude this" icon, like with other split buttons the split should disappear
-------------------------
( ) -Person-          (-)
----------------------/\-
                       \

Comment 16

[David Ascher (:davida)]

Attachment: WIP v1

This is one possible model, which uses a menu to go from "unselected" to included or excluded, with included favored, so that click/click gets you what click does today.

TBD:  figure out an a11y strategy (i'm thinking space or enter to show the menu, tab or arrows to move between the entries) and figure out when to hide the menus.

Comment 17

[David Ascher (:davida)]

Attachment: patch v1

Turns out getting XUL menus to work in html is a black art, so I'm going with a fairly trivial implementation of an HTML menu.  Long term we'll probably want to build a library of controls for HTML chrome.  The styling on this is likely not final, but we need to get the strings in.

Starting w/ ui-review, and then we'll find a code reviewer.

Comment 18

[David Ascher (:davida)]

found one bug: the hide method for the popup menu should guard against this.node not existing.

Comment 19

[David :Bienvenu]

Comment on attachment 403557 [details] [diff] [review]
patch v1

since I forgot to take a step back when volunteers were requested :-)

Comment 20

[David Ascher (:davida)]

Attachment: patch v2

after conversations on IRC w/ bienvenu and clarkbw, we came up with this much better model for the labels, IMO.  I've also done some tweaking of the menu positioning so that they're always legible on click.

Comment 21

[David Ascher (:davida)]

Attachment: patch v3

This deals with the complication of the "None" values -- e.g., in the tag faceting, None -> "Must not be tagged" or "Must be tagged". I think it makes the UI much more understandable, but it sure requires more strings.

Also fix goofy position of menu when window is scrolled.

Comment 22

[David :Bienvenu]

Comment on attachment 403687 [details] [diff] [review]
patch v3

This works better now, cool. A few nits:

this shoudl typo occurs twice:

+#  to indicate that the results shoudl be restricted to messages which match

add a newline to the end of glodaFacetBindings.css

this indentation looks wrong - stuff inside try should be indented:

+        try {
+        let node = event.originalTarget;
+        let nodeClasses = node.getAttribute("class");
+        if (!nodeClasses)
+          return;
 
-      let nodeClass = nodeClasses.split(" ")[0];
-      if (nodeClass == "bar-exclude")
-        this.barClicked(event.originalTarget.parentNode, "exclude");
-      else if (nodeClass == "bar-link") {
-        let barNode = event.originalTarget.parentNode;
-        this.barClicked(barNode,
-                        (barNode.getAttribute("variety") == "remainder") ?
-                          "include" : "remainder");
-      }
-      else if (nodeClass == "facet-more") {
-        this.changeMode("all");
-      }
-    ]]></handler>
+        let nodeClass = nodeClasses.split(" ")[0];
+        if (nodeClass == "bar-exclude" || nodeClass == "bar-link")
+          document.getElementById("popup-menu").show(event, this.facetDef, this, node.parentNode.groupValue);
+        else if (nodeClass == "facet-more") {
+          this.changeMode("all");
+        }
+        } catch (e) {

CSS. */

i.e., period and space here:

+             excluded.  The variety attribute handles that through CSS*/

Comment 23

[David Ascher (:davida)]

Attachment: patch v4

Addressed bienvenu's nits, added some missing localization notes, and fixed a positioning issue w/ the menu for the "remove constraint" mode that clarkbw noted out-of-band.

Comment 24

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 403695 [details] [diff] [review]
patch v4

it seems you've already addressed my comments on the earlier patch.  This looks good, thanks. :)

Comment 25

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/6840af3f4ff9

Comment 26

[David Ascher (:davida)]

i think we can close this.  new bugs for new issues.

Comment 27

[Thomas Stache]

Is the menu the final solution, or a string-freeze quickie? I would hope the icons would return, the menu solution - while discoverable - feels clumsy! It now always takes two clicks to add a "people" constraint, and that bothers me after tasting the initial solution ;)

Comment 28

[David Ascher (:davida)]

The menu is the best solution we could come up with so far. Given the string freeze, any further improvement has to work w/ no new strings.   I'm ok w/ exploring further refinements.

I kinda like where we ended up, because I think it ends up much more discoverable, especially in terms of explaining the exclude and "None" behaviors.  Note that the menu is carefully positioned so that the first choice (include) doesn't require a mouse movement -- click-click will do.

Let's play with it for a few days, and if we come up with alternative designs, we can definitely consider them.