1107194 - [UX] Improve searching through the context menu

Status: RESOLVED FIXED

(Firefox :: Search, defect)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

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.

Comment 1

[Elbart]

https://addons.mozilla.org/en-US/firefox/addon/smartsearch/

Comment 2

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

(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.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

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

Comment 5

[Philip Chee]

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/

Comment 6

[Johan C]

Attachment: 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.

Comment 7

[Blutin]

(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.

Comment 8

[Ash Grigas]

Attachment: context menu.png

Comment 9

[Ash Grigas]

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.

Comment 10

[Ash Grigas]

Attachment: List of providers is accessible through sub-menu.

Updated using list view.

Comment 11

[Stephen Horlander [:shorlander]]

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

Comment 12

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

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.

Comment 13

[Ash Grigas]

(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.

Comment 14

[Ash Grigas]

Created implementation ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1136131