Consider pre-search engine selection workflow

RESOLVED DUPLICATE of bug 1110820

Status

()

Firefox
Search
--
enhancement
RESOLVED DUPLICATE of bug 1110820
2 years ago
2 years ago

People

(Reporter: mconley, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

The new search input seems optimized for selecting a search engine _after_ having typed in a search query.

I wonder if we might try to also optimize another case - the case where the user knows which engine they want to use before they know what the query they want to type is.

Perhaps what we might consider is making it so that if the search input is empty when clicking on one of the one-off buttons, then we do the following:

1) Focus the search input, and perhaps decorate it to indicate that the clicked search provider has been selected
2) If the user types a query and presses enter, it will go to the search provider that the user had originally selected
3) If the user blurs away from the search input, the decoration is removed, and the search provider resets back to the default

Originally filed based on feedback I saw in https://bugzilla.mozilla.org/show_bug.cgi?id=1228685#c3.
These are my very humble conclusions after coding a new feature - show search engines (SE) in the location bar - into my add-on. Even though they're mostly about the location bar, I'm positive most of it still applies to the search bar.

First off, the one-off searches are great. Everyone can use them, everyone can learn them, couldn't be simpler.

IMO persisting a SE temporarily is very tricky to get right. I wouldn't do it based on being in a search results page at all. The limit there is too fluid to avoid any "Wait, wasn't it...? But didn't I..." moments by any user regardless of their habits. I don't believe persisting according to page is worth the trade-off with those "huh" cases.

You could also persist for as long as the suggestions panel is open. But everyone has those "What was that word again?..." moments, or some notification pops up, or whatever. The panel closes and the process starts over. A good compromise here could be to persist until either a search is run or the panel closes with an empty search bar. It's not perfect, but I see it as a good trade-off.

There's also the question of how to actually persist it; anything more than a single click is probably too much.

An easy one for me was to eliminate every "solution" that was time-based. They're just too arbitrary for my taste.

I also disagree with your suggestion. Sometimes I do want/need to go to the SE's homepage; clicking it while the search bar is empty is a good way to do this.

Eventually I settled on making a change to the current/default SE more easily, by single-right-clicking the engine button, for only one reason: simplicity. You either do a one-off search or you change your current SE for all future searches until you change again.

The drawback here is of course you can forget you changed it. But I feel I made the discoverability of the current SE a tad better in the location bar, so I'm betting on those cases being reduced.

You can try a beta version of my add-on with this [1] if you'd like to see how it feels to have some more direct SE persistence. Even though it's in the location bar, maybe it will give you some ideas.

[1] https://github.com/Quicksaver/The-Fox--Only-Better/releases/tag/v1.4b1
This is a duplicate of bug 1110820, that UX wontfixed. Note that my proposal in bug 1110820 comment 1 is almost identical to Mike's proposal here. I liked that idea and was disappointed to see it wontfixed (especially as at the time it was kinda wontfixed to give more attention to bug 1109851 -- the other unfixed significant frustration reported by users after the switch to the new UI -- which I think is unlikely to see progress at this point). If you want to reopen and convince UX we do want this, go for it :).
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1110820
You need to log in before you can comment on or make changes to this bug.