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)
Tracking
(firefox45 affected)
RESOLVED
DUPLICATE
of bug 1022464
Tracking | Status | |
---|---|---|
firefox45 | --- | affected |
People
(Reporter: liuche, Unassigned)
References
Details
Attachments
(1 file)
178.87 KB,
image/png
|
Details |
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
Comment 2•9 years ago
|
||
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)
Comment 3•9 years ago
|
||
This sounds like a dupe of bug 1022464.
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Looks like liuche is working on this in bug 1022464.
Flags: needinfo?(michael.l.comella)
Assignee | ||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•