Comment 52 for bug 691380

(In reply to comment #44)
> Comment on attachment 459049 [details]
> Screenshot 2: Proposed UI of optional simple quick filter widget on main
> toolbar
>
> Nice mockup Thomas! Having a visual representation makes it much easier to
> understand what's being discussed. I think these questions are for everyone.

Bryan, thanks for paying us a visit! :)))

> I like that you've included the filter modes on focus of the entry. This is
> something we were very interested in changing from the old system.

Not sure I understand, but there has been no plan so far to show the filter modes dropdown automatically when user clicks into simple quick filter widget. But it's inspiration, maybe we can try something like that.

> Many people would forget what mode they were in and become very frustrated
> that they weren't finding the messages they were expecting to find.
> I'm not sure I have a suggestion but I wonder if there is another way of
> showing the filter options other than using the pop up menu.

For just showing them, a tooltip would suffice (as in my interactive mockup to come, see next comment). For changing them, we need a bit more. Charles proposes putting the controls on a tooltip-like floating pane, and show that interactive tooltip *on top* of our proposed simple quick filter widget which would usually sit on the right of main toolbar. So in fact there's empty space above that (the right of menu bar, and the window's caption bar (at least here on XP). Charles, that sounds like an interesting idea to explore visually... (or possibly just tweaking my upcoming xul mockup).

> Are you planning on handling the quick filter buttons: unread, attachments,
> tags, etc? Not that you have to but I'm just wondering.

Yes, that's the plan. I'd still want to keep it as compact as possible.

> The show/hide system is an attempt to make sure that people understood when a
> filter was being applied.

FTR: I am sure that the new Quick Filter Bar of TB 3.1 meets a lot, if not all goals of good and modern UI design (and they have a lot of goals, if we are to believe bmo's keyword reference, as I was recently informed when I was daring enough to propose a new keyword, "customizability"...):

> ux-affordance, ux-consistency, ux-control, ux-discovery, ux-efficiency,
> ux-error-prevention, ux-error-recovery, ux-feedback, ux-implementation-level,
> ux-interruption, ux-jargon, ux-minimalism, ux-mode-error, ux-natural-mapping,
> ux-tone, ux-undo, ux-visual-hierarchy
(From https://bugzilla.mozilla.org/describekeywords.cgi#ux-affordance)

Seriously, quick filter bar is an excellent tool that has been carefully crafted to successfully avoid many usability problems of the past while adding valuable functionality at your fingertips. As such, it's great.

However, some personal observations:
- in 98% of all searches, I am not using advanced filter criteria (buttons on the left side of qfb, like attachment etc.)
- in 98% of all searches, I am not changing the fields when I search for some text. Subject, Sender, and Recipient is an excellent default. (Btw, we should look into comment 25's remark about the regression concerning Sent-box intelligent search fields behaviour).

Iow, in 98% of all searches, I'd be happy with something like the good old quick search box, where you can just "find as you type". Which means all the rest of the great UI is practically just taking up valuable space from my message list and distracting (this bug). So far, I didn't think much about this. But it really came to me when I tried IagoSRL's addon 'Unified search' (comment 2; https://addons.mozilla.org/es-ES/thunderbird/addon/187593/). Wow, what am amazing feeling of SPACE and natural simplicity in the message list! Just great.

It's hard to tell how many people would feel the same, but let's not forget that TB3 introduced the new mail header which also eats up a lot of space, and the amount of interest in compact header. Bottom line of these wonderful stories is that I think it might be in our best interest to safeguard against a possible scenario where a potentially big number of users might be unhappy about the space aspects of our otherwise excellent design choices. This bug, if done well, could provide a highly usefull fallback option for people with a preference or need for a more compact UI. Just as Charles and others here, I'd love to see this bug gain momentum. I'll contribute to that end in my next comment with another mockup.

> Combined Search had issues that people couldn't find the old quick search
> system they wanted. It suffered from similar 'hidden drop down mode' problems
> as the quick search did; people who switch to quick search of senders and not
> know how to get back to the gloda search. We would need to examine those and
> other issues before going down that road again.

Bryan, trying to find a UI solution for this problem has made me (pain)fully aware of all the design benefits of the current implementation and the numerous problems it solves. In fact, I feel a bit like reverse-engineering... But maybe we (as users and contributors) have to go down that road ourselves before coming to accept the costs because of the benefit. Or maybe, creative collaboration will come up with something new :)) Probably (hopefully), it will be a bit of both! Let the bird fly!!!