Closed Bug 1644572 (urlbar-searchshortcuts) Opened 4 years ago Closed 4 years ago

[meta] Unify one-off and search shortcuts to provide a more streamlined search experience

Categories

(Firefox :: Address Bar, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
83 Branch

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.

Keywords: meta
User Story: (updated)
Severity: -- → S3
Priority: -- → P3
Depends on: 1647885
Depends on: 1647886
Depends on: 1647887
Depends on: 1647888
Depends on: 1647889
Depends on: 1647890
Depends on: 1647891
Depends on: 1647893
Depends on: 1647899
Depends on: 1647900
Depends on: 1647901
Depends on: 1647915
Depends on: 1647921
No longer depends on: 1647887
Depends on: 1647930
Alias: urlbar-searchshortcuts
Type: task → enhancement
Priority: P3 → P2

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

Blocks: 1650581
Depends on: 1654862
Depends on: 1632318

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.

Depends on: 1656005
Depends on: 1657414
No longer depends on: 1647901
Depends on: 1657648
Depends on: 1657676
Depends on: 1657672
Depends on: 1657801
Depends on: 1657918
Depends on: 1658330
Depends on: 1658605
Depends on: 1658620
Depends on: 1658624
Depends on: 1658326
Depends on: 1658629
Depends on: 1658646
Depends on: 1658964
Depends on: 1658968
Depends on: 1658993
Depends on: 1658994
Depends on: 1659027
Depends on: 1659126
Depends on: 1659128
Depends on: 1659131
Depends on: 1659032
Depends on: 1659203
Depends on: 1659204
Depends on: 1659205
No longer depends on: 1658994
Depends on: 1659309
Depends on: 1659748
Depends on: 1659714
Depends on: 1659738
Depends on: 1659745
Depends on: 1659752
Depends on: 1659811
Depends on: 1660204
Depends on: 1660778
Blocks: 1662169
Depends on: 1662509
Depends on: 1663686
Depends on: 1664252
Depends on: 1664320
Depends on: 1664527
Depends on: 1663960
Depends on: 1663984
Depends on: 1663961
Depends on: 1663949
Depends on: 1665048
Depends on: 1665076
Depends on: 1665036
Depends on: 1665123
Depends on: 1665094
No longer depends on: 1665094
Depends on: 1665663
Depends on: 1665934
No longer depends on: 1665934
No longer depends on: 782557
Depends on: 1666927
Depends on: 1666333
Depends on: 1668340
Depends on: 1668370
Depends on: 1668430
Depends on: 1668389
Depends on: 1668873
Depends on: 1668889
Depends on: 1668939
Depends on: 1669271
Depends on: 1670932
Depends on: 1670944
Depends on: 1670958
Depends on: 1671218
No longer depends on: 1659811
No longer depends on: 1658620
Depends on: 1671816
Depends on: 1671815
Depends on: 1671803
Whiteboard: [feature-testing-meta]
Depends on: 1672218
Severity: S3 → N/A
Priority: P2 → P3
Depends on: 1672643
Depends on: 1673011
Depends on: 1674000
Depends on: 1674469
Depends on: 1674187
No longer depends on: 1668889
Blocks: 541891
Blocks: 724896
Blocks: 1069796
Whiteboard: [feature-testing-meta]
Depends on: 1678647
No longer depends on: 1678647
No longer depends on: 1677102

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.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Just a couple of questions:

  1. who asked about unifying "one-off and search shortcuts to provide a more streamlined search experience"
  2. what does a "more streamlined search experience" exactly mean?
  3. when was that discussion held?
  4. where? I cannot find a record of it.
  5. 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.

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)

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

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

  1. when was that discussion held?

A year ago, when this bug was filed.

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

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

You need to log in before you can comment on or make changes to this bug.