Comment 101 for bug 691380

Revision history for this message
In , Bugzilla2007 (bugzilla2007) wrote :

Some further advanced comments on the proposed behaviour:

(In reply to comment #37)
> Properties of Simple Quick Filter Widget with sticky pin
> a) can be added to main toolbar using toolbar customization
> b) is a separate widget independent of Gloda global search widget
> c) is optional; does not replace/alter/interfere with existing quick filter
> bar (?) (although we'd have to clarify the behaviour when both are shown;
> where does Ctrl+F focus go to etc.)

g) when only the simple quick filter widget is shown, and the classic filter bar is hidden:
g1) Ctrl+F sets focus into the widget's search box; does NOT show classic filter bar (this is obvious, otherwise the whole space-saving idea wouldn't work)

h) when both the simple quick filter widget and the classic filter bar are shown:
h1) Ctrl+F sets focus to the classic filter bar's search box (not into the simple quick filter widget). Reason: When user has deliberately chosen to show the classic filter bar, he does so for a reason and we should use that as it's the primary interface with best UI integration.

Resulting intuitive behaviour of g1 and h1 combined is that
- when quickfilter bar is hidden, Ctrl+F will use simple quick filter widget
- when quickfilter bar is shown, Ctrl+F will use that instead.

h2) always ensure that criteria for quick filter widget and classic filter bar are identical (both the search string and the advanced criteria)
- while typing into the widget, search string simultaneously appears in the filter bar (if it's shown)
- when setting advanced criteria in the widget, same criteria are simultaneously set in the filter bar
- when user changes the visibility of either the widget (toolbar customize) or the filter bar (View > toolbars > filter bar, or the filter tab toggle), ensure criteria from "the other" filter UI, if any, are duplicated immediately

Another behaviour that needs clarification:
What happens UI-wise when user toggles "has tags" filter on?

1) just filter on messages that "have tags", but do NOT offer secondary tags filter refinement based on individual tags (less functionality than filter bar)
2) filter on messages that "have tags", and DO offer secondary tags filter refinement on individual tags (same functionality as filter bar)
2a) show a secondary bar with individual tags right above (i.e. inside) the message list (basically the same UI that we show now when tags is toggled on the filter bar, but stripped of any other UI elements on that bar; and obviously not showing the primary filter bar, so we still save the vertical space of one bar, plus we can show more tags horizontally on our bar).
2b) find some other place/UI element/behaviour to fine-tune the tags

To retain full functionality, and for simplicity's sake, I am very much in favor of 2a), on-demand secondary tags bar inside the message list pane, on top of results list.