Closed Bug 1230587 Opened 9 years ago Closed 9 years ago

Show awesomescreen search results if there is a saved search query

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox45 affected)

RESOLVED DUPLICATE of bug 1022464
Tracking Status
firefox45 --- affected

People

(Reporter: liuche, Unassigned)

References

Details

Attachments

(1 file)

Use case would be: 1. Type something and hit enter to search for it. 2. Decide you wanted to use a different search engine, tap on urlbar again. 3. search query is present in the urlbar, but you need to enter some kind of additional text to make the quicksearch bar pop up. The tradeoff is that when you are going to the search screen with a url in the urlbar instead of a search query, the quick-search icons aren't useful because you'd never want to quick-search a url with any of the engines. But it's possible that people would also be more likely to see the quick-search icons when they're not focused in the middle of a task, like typing.
Changing title to match my interpretation. I've experienced this too and it makes it hard to use the saved search query feature (e.g. where you make a search, click the url bar because you want to change the engine, and then have to add and remove a letter to get the query and the quick search bar). Perhaps users don't care for their home panels when there is a saved query, but it'd also be inconsistent. Perhaps we can fix this with the home panel mocks? e.g. if the home panels don't appear when you hit the url bar and we glorify search results instead, we can be more dynamic with the content. Anthony, what do you think?
Flags: needinfo?(alam)
Summary: Show quicksearch bar if urlbar has text → Show awesomescreen search results if there is a saved search query
Hm, this might not have as simple a solution as I thought. There's multiple layers of user expectation here that we must balance. Between Home panels and Search, there's already two "modes" that diverge the user experience a bit. To me, it sounds like this bug is about resurfacing the Awesomescreen for a user that is "searching for something" when they tap the URL bar. Much like how we show search terms in the URL bar instead - rather than the search results page URL. The actions break down like so: 1) User types "baby fox" into URL bar 2) See's search suggestions crumbs, frecency results, and quick search bar 3) *press enter* 4) See's search results page 5) *press URL/awesomebar* 6) See's Home panels with "baby fox" in URL bar In step 6, we could resurface what the user saw in step 2. Purely from a "searching" perspective, that would make sense. After all, we do already take this UX into consideration by showing the user's search terms automatically instead of the results page URL. Currently, we show Home Panels (in step 6) since this happens every time the user hits the URL bar. So, this would be creating a special case. But it could work. Mike, I think the best way to see this model in action would be to get a build that resurfaces the Awesomescreen (step 2) in step 6 like I described above. Then, we can compare with the current experience. Attaching "awesomescreen" that I'm referring to.
Flags: needinfo?(alam) → needinfo?(michael.l.comella)
This sounds like a dupe of bug 1022464.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Looks like liuche is working on this in bug 1022464.
Flags: needinfo?(michael.l.comella)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: