Closed Bug 1022228 Opened 11 years ago Closed 5 years ago

"Open email as list" on facet search should be more discoverable, wording more understandable/descriptive

Categories

(Thunderbird :: Search, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 74.0

People

(Reporter: Yoric, Assigned: aleca)

References

()

Details

(Keywords: ux-discovery, ux-efficiency)

Attachments

(3 files, 2 obsolete files)

STR: 1. A (power) user asks if there is a way to just get e-mail titles, without summaries; 2. Inform him that we have a button "Open email as list"; 3. Realize that it took them 10+ minutes to find the button once they heard about its existence. Also, does label "Open email as list" really make sense?
Indeed. This may be the best, or most obvious example of what needs improving in faceted search. The "more discoverable" bit, is bug 545949
Depends on: 545949
Summary: "Open email as list" should be more discoverable + understandable → "Open email as list" on facet search should be more discoverable, wording more understandable/descriptive
Yeah, "Open email as list" is unfortunate in many ways, but also intrinsically/historically tricky. The "email" got in as a matter of precision because global search also finds chat messages, but the list view can't show these (yet). So "email" was probably shortened to avoid clumsier "Open email messages as list". Why we have "open" and not just "view", I don't know. We could also use "results" but it suffers the same problem to suggest "all results", whereas chat results will be excluded from list view. Perhaps that's negligible, or could go into tooltip. Related Bug 580252 still looks promising to me, to have a toggle button / view picker in upper left corner which toggles between faceted and list results. But details of UI/behaviour still needed.
I think we also had "Show..." at some point, wording of this thing is going through iterations... And yes, it's not discoverable (distinct) enough and the position might not be ideal either.
David, any suggestions for improvement from your side?
If we rethink this as a dropdown (in the sense of view modes), might also make things easier, can somebody try that?
Designing it as a dropdown sounds like a good idea. Regarding wording, why not use word "results" instead of "email"?
"Results" is a good suggestion. And "Open" is inaccurate, in a fundamental sense. Open almost implies "message", and we are not opening messages, but rather we are opening a different "View". How about "View Results as List"? A drop down gets us toward Bug 580252, which has interest, but gets us into entirely different design decisions, and requires two clicks which would be bad, no?

https://www.reddit.com/r/Thunderbird/comments/dtx6zb/can_i_get_search_results_in_a_simple_list/ I think has some aspects of this bug - the user is not utilizing "open email as list" as an alternative to clicking on a message in the facet list.

Definitely a UX bug - if nothing else because "open email as list" is in such a small font. It's also not centered in the shaded bar.

Flags: needinfo?(alessandro)

I forgot I had created bug 545949 10 years ago :)

See Also: → 580252
See Also: → 537856, 509422, 929845
Attached image search-results.png

Wow, before reading this bug I didn't even know of the existence of that link.

That whole top area with the results count, link, and sorting option should be redesigned as it's not intuitive at all and the style is inconsistent with anything else we have.

Here's a quick proposal to improve the discoverability of the available options, and keep the style more consistent.

Asking for a feedback to Richard to see if he thinks this might be a good direction to go.

Assignee: nobody → alessandro
Flags: needinfo?(alessandro)
Attachment #9107917 - Flags: feedback?(richard.marti)
Comment on attachment 9107917 [details] search-results.png I agree with changing the header. The "Show results as list" is also clearer than the actual wording.
Attachment #9107917 - Flags: feedback?(richard.marti) → feedback+

I like it too :)

Status: NEW → ASSIGNED
Priority: -- → P2

This section is more messy than I expected.
The UI is pretty old, with elements relying on table styiling and some convoluted JS methods I don't really understand.

This update takes care of refreshing the header in order to make those buttons and options more discoverable and accessible, and also adds a quick polish to the overall style of the page.

So much more should be done here as many things could be optimized and fixed.
If this one lands, I'll create some follow up bugs to continue the work on this section, which is in need of some serious love.

Attachment #9124643 - Flags: ui-review?(richard.marti)
Attachment #9124643 - Flags: review?(mkmelin+mozilla)
Attachment #9124643 - Flags: feedback?(vseerror)
Comment on attachment 9124643 [details] [diff] [review] 1022228-search-results-header.diff Review of attachment 9124643 [details] [diff] [review]: ----------------------------------------------------------------- ::: mail/base/content/glodaFacetView.css @@ +393,3 @@ > cursor: pointer; > + padding: 4px; > + border-radius: 2px; You no more want to use the variable var(--borderRadius) ? ::: mail/themes/linux/mail/glodaFacetView.css @@ -25,5 @@ > > -#table { > - background-color: -moz-Field; > - color: -moz-FieldText; > -} This should be also removed in the Mac and Windows files.
Comment on attachment 9124643 [details] [diff] [review] 1022228-search-results-header.diff Review of attachment 9124643 [details] [diff] [review]: ----------------------------------------------------------------- ::: mail/base/content/glodaFacetView.js @@ +1073,5 @@ > * is odd considering it works for the XUL case, but I could see how that might > * differ. Anywho, this works for now and is a delightful reference to boot. > */ > function reachOutAndTouchFrame() { > + let showAll = document.createXULElement("toolbarbutton"); Contrary to other places the gloda stuff is pure html. We might not want to put any xul here to confuse matters ::: mail/base/content/glodaFacetView.xhtml @@ +68,2 @@ > </div> > + <div class="empty" id="showEmpty"> odd spacing, and put id first
Attachment #9124643 - Flags: review?(mkmelin+mozilla)

(In reply to Alessandro Castellani (:aleca) from comment #14)

...
This update takes care of refreshing the header in order to make those buttons and options more discoverable and accessible, and also adds a quick polish to the overall style of the page.

Can someone post a screen shot of the patch results?

So much more should be done here as many things could be optimized and fixed.
If this one lands, I'll create some follow up bugs to continue the work on this section, which is in need of some serious love.

That's part of what bug 929845 is about.

See Also: → 516797
Comment on attachment 9124643 [details] [diff] [review] 1022228-search-results-header.diff Looks better than actual. Maybe we need to style the buttons ourself when we decide to make this page dark theme compliant on Mac and Windows. On Linux it's already.
Attachment #9124643 - Flags: ui-review?(richard.marti) → ui-review+
Attached image gloda-search.jpg

Here's a screenshot with the applied patch.

Attachment #9124883 - Flags: feedback?(vseerror)
Comment on attachment 9124883 [details] gloda-search.jpg Awesome! So much better! For "Show results as list" I liked the little icon with arrow better than the one with the plus (+).
Attachment #9124883 - Flags: feedback+
Attachment #9124643 - Flags: feedback?(vseerror)
Comment on attachment 9124883 [details] gloda-search.jpg Definitely an improvement over the current state. But for icon, I'd rather see something more akin to a list, a box with lines, rather than a box with arrow or plus.
Attachment #9124883 - Flags: feedback?(vseerror) → feedback+

For "Show results as list" I liked the little icon with arrow better than the one with the plus (+).

But for icon, I'd rather see something more akin to a list, a box with lines, rather than a box with arrow or plus.

That icon is not there to represent "the list" but rather to let the user know that clicking on that link/button will open a new window/tab.
I'm using that icon since it's part of our Photon Icon Library.

Patch updated to use only pure HTML elements.

Attachment #9124643 - Attachment is obsolete: true
Attachment #9124932 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9124932 [details] [diff] [review] 1022228-search-results-header.diff Review of attachment 9124932 [details] [diff] [review]: ----------------------------------------------------------------- r=mkmelin with the below addressed ::: mail/base/content/glodaFacet.js @@ +98,2 @@ > > + const timelineImage = document.createElement("image"); huh? Something's wrong here. xul has image, but html has img, but they work differently. But this would create a html:image, which is not a real thing, just an element with no functionality ::: mail/base/content/glodaFacetView.js @@ +784,5 @@ > facetDate.removeAttribute("style"); > }; > facetDate.addEventListener("transitionend", listener, { once: true }); > facetDate.removeAttribute("hide"); > + document.getElementById("date-toggle").setAttribute("checked", true); should be "true". But let's just use document.getElementById("date-toggle").checked = true; ::: mail/base/content/glodaFacetView.xhtml @@ +75,5 @@ > </div> > + <div id="showEmpty" class="empty"> > + <span class="empty"> > + <img class="empty" > + src="chrome://messenger/skin/icons/empty-search-results.png"/><br/> indention off
Attachment #9124932 - Flags: review?(mkmelin+mozilla) → review+

But let's just use document.getElementById("date-toggle").checked = true;

I have to use setAttribute("checked", "true") because this element is a label styled as a button, and checked = true doesn't seem to work.

indention off

Argh, almost every attribute in that file are not properly indented. I'm fixing it.

Attachment #9124932 - Attachment is obsolete: true
Attachment #9125124 - Flags: review+
Target Milestone: --- → Thunderbird 74.0

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/7dc97f6d28a3
Improve the UI of the search result tab and improve links discoverability. r=mkmelin,ui-r=paenglab

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Blocks: 545949
No longer depends on: 545949
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: