[meta] Unify one-off and search shortcuts to provide a more streamlined search experience
Categories
(Firefox :: Address Bar, enhancement, P3)
Tracking
()
People
(Reporter: mak, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: feature-testing-meta, meta)
User Story
Firefox’s one-off search feature is difficult to discover and understand. We can add a “tab-to-search” function to put feature discoverability in the user’s path the moment it may be useful. We can also make the interaction better (you’ll now be able to see search suggestions from the provider), more understandable and make it work in both directions (before typing a query or after typing a query) if we make them work more like search shortcuts.
Details are being finalized and will follow, we'll start with the breakdown to understand technical requirements in the meanwhile.
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Comment 1•4 years ago
|
||
I'm adding a WIP spec from UX. More sections will be added over the coming days. There will also be a separate design document for tab-to-complete (bug 1647921).
|
|
||
Comment 2•4 years ago
|
||
Here's the latest design spec at a public link. It's a WIP just like the previous one. Future updates should be at the same link.
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
Reporter | |
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 3•4 years ago
|
||
I'm resolving this bug since the feature has been released, the only thing it's tracking yet is the holdback experiment in bug 1674187, that has its own life-cycle. Follow-up bugs, improvements and regressions should block Bug 1669525.
Just a couple of questions:
- who asked about unifying "one-off and search shortcuts to provide a more streamlined search experience"
- what does a "more streamlined search experience" exactly mean?
- when was that discussion held?
- where? I cannot find a record of it.
- why does this streamlining imply forcing the presence of search controls where the user had explicitly requested none? (bug 1628926)
I am just trying to understand what drives things like this that cause us users and support people to treat Firefox updates with considerable apprehension, as you never know just what is going to break this time. Please give thought to the need to treat (the dwindling number of) existing users with respect and consideration when making changes.
|
|
Reporter | |
Comment 5•3 years ago
|
||
Just an heads-up that, while we always appreciate feedback, advocacy posts are usually not tolerated in this technical bug tracker.
(In reply to E.N. from comment #4)
- who asked about unifying "one-off and search shortcuts to provide a more streamlined search experience"
Product managers and designers, starting from an identified problem, using their years of experience, after appropriate experimentation in product and user studies with randomly selected group of users.
- what does a "more streamlined search experience" exactly mean?
It makes the experience more coherent across similar features that were different by small details. Unifying users expectation is in general a good thing. It also helps users getting rid of the separate search bar, providing a Search Mode experience to the urlbar, and allowing for a proper privacy separation of search and non-search behaviors. With appropariate and supported configuration, you can both navigate and search from the urlbar without affecting privacy at all. It also made discoverable features like searching bookmarks, history or tabs. There's obviously a long term plan that may not be visible from a single part of a change, and not all of it made to the product yet.
- when was that discussion held?
A year ago, when this bug was filed.
- where? I cannot find a record of it.
Have you seen the tens of dependencies of this bug? There's a process to design and develop features, like in any healthy company, parts of it reach users, parts not, you wouldn't want to see tens of discarded prototypes and participate to tens of meetings, before one is picked. That is our job, not yours.
And this has been enabled in Nightly and then Beta for quite some time, and we have a Nightly blog where teams report what they are working on. I agree that we could be more proactive into communicating incoming changes, and I already reported this feedback to my managers.
- why does this streamlining imply forcing the presence of search controls where the user had explicitly requested none? (bug 1628926)
Because those users used a non supported option to do so, and a supported alternative was provided by just unchecking engines that they don't use. The same result can now be achieved with a supported option.
I am just trying to understand what drives things like this that cause us users and support people to treat Firefox updates with considerable apprehension, as you never know just what is going to break this time. Please give thought to the need to treat (the dwindling number of) existing users with respect and consideration when making changes.
It's disingenuous to think we don't take into consideration existing users, when they are our only path to success. All the changes are made to benefit users, but it's not trivial, or almost impossible, to satisfy every single person. You'll always find someone who doesn't like a change, even if it's a border becoming 1 px instead of 2. Having some faith into the project goals would probably help with the apprehension, Mozilla has no one to satisfy apart from users, there's no shareholders or people profiting from our business, all revenue goes straight to the project.
Description
•