Closed Bug 1107194 Opened 5 years ago Closed 5 years ago

[UX] Improve searching through the context menu

Categories

(Firefox :: Search, defect)

36 Branch
x86
All
defect
Not set
Points:
5

Tracking

()

RESOLVED FIXED
Iteration:
38.3 - 23 Feb

People

(Reporter: phlsa, Assigned: agrigas)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ux])

Attachments

(2 files, 1 obsolete file)

The current experience of looking things up using the context menu is rather inflexible since one can't search with anything but the default search engine.
I'm not sure why we removed a search feature that has been in place for, I believe, Firefox's entire existence. I select text in pages after changing search providers using cmd/ctrl-k and cmd/ctrl-up or down arrow to do searches with alternate providers (such as bugzilla) every day. With the new UI, I have to select the text on the page, copy it to clipboard, go to the search box, choose an alternative search provider, and then search *every* time since changes to the search provider in the search box aren't sticky (they go back to your Firefox default one after each search) and don't persist between tabs. 

In the old system, I could change my provider to Bugzilla (or Amazon) and then select and context search with my selected search engine until such point as I was done using just two mouse clicks (select and right click) for each subsequent search.
(In reply to Elbart from comment #1)
> https://addons.mozilla.org/en-US/firefox/addon/smartsearch/

This seems to only recognize 1 search engine out of the 6 I have installed.
This add-on has a very good model to work after (and it did recognize all the engines I have installed): 
https://addons.mozilla.org/en-US/firefox/addon/context-search
This one uses a one-off-buttons-like UI (but predates the actual one-off-buttons implementation in Firefox):
https://addons.mozilla.org/addon/quickcontextsearch/
I threw together a quick mockup, based on the previously mentioned add-on and the current search UI.
(In reply to Johan C from comment #6)
> Created attachment 8558862 [details]
> Mockup based on the addon "quickcontextsearch" and the current search UI.
> 
> I threw together a quick mockup, based on the previously mentioned add-on
> and the current search UI.

Please consider when there are more search engines. I have 33 at home and 28 at work.

I think the padding of the icon containers in the mockup should be reduced; maybe not as much as with Quick Context Search.
Flags: qe-verify-
Flags: firefox-backlog+
Assignee: nobody → agrigas
Status: NEW → ASSIGNED
Iteration: --- → 38.3 - 23 Feb
Points: --- → 5
Attached image context menu.png (obsolete) —
Attachment #8567905 - Flags: ui-review?(philipp)
Attachment #8567905 - Flags: ui-review?(shorlander)
Comment on attachment 8567905 [details]
context menu.png

Another UI approach to accommodate more search providers in context menu that follows sub-menu fly out pattern used by other services like Evernote. Flagged for UI review.
Updated using list view.
Attachment #8567905 - Attachment is obsolete: true
Attachment #8567905 - Flags: ui-review?(shorlander)
Attachment #8567905 - Flags: ui-review?(philipp)
Attachment #8568096 - Flags: ui-review?(shorlander)
Attachment #8568096 - Flags: ui-review?(philipp)
Attachment #8568096 - Attachment description: context menu.png → List of providers is accessible through sub-menu. Providers should be listed by frequency of use.
Comment on attachment 8568096 [details]
List of providers is accessible through sub-menu.

I like just using a regular sub-menu list here.

Instead of trying to make it too smart about when to show more providers I think we should just let it grow naturally and use the native menu overflow. For example on OS X that is just up/down arrows http://cl.ly/image/341K1p3V3t2y
Attachment #8568096 - Flags: ui-review?(shorlander) → ui-review-
Comment on attachment 8568096 [details]
List of providers is accessible through sub-menu.

Yeah, sticking to the list paradigm makes sense. Especially since that list will be medium to short for most users.

I agree with Stephen on using the platform-native scrolling mechanisms, because of the context of this UI.

Ordering by frequency would probably cause issues if it were also reflected in the search dropdown. Then it would make building spacial intuition and muscle memory about the UI quite hard.
Attachment #8568096 - Flags: ui-review?(philipp) → ui-review-
(In reply to Philipp Sackl [:phlsa] unavailable until Feb. 23 from comment #12)
> Comment on attachment 8568096 [details]
> List of providers is accessible through sub-menu. Providers should be listed
> by frequency of use.
> 
> Yeah, sticking to the list paradigm makes sense. Especially since that list
> will be medium to short for most users.
> 
> I agree with Stephen on using the platform-native scrolling mechanisms,
> because of the context of this UI.
> 
> Ordering by frequency would probably cause issues if it were also reflected
> in the search dropdown. Then it would make building spacial intuition and
> muscle memory about the UI quite hard.

The ordering would be specific to this use case not in the top level search UI as that is a grid and agree would be weird to dynamically change placement of items based on frequency. We can build it without that piece for now and see how it feels.
Blocks: 1136131
Attachment #8568096 - Attachment description: List of providers is accessible through sub-menu. Providers should be listed by frequency of use. → List of providers is accessible through sub-menu.
Created implementation ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1136131
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.