Closed Bug 430627 Opened 12 years ago Closed 10 years ago

Remove open search notification in primary UI

Categories

(Firefox :: Search, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- final+

People

(Reporter: faaborg, Assigned: dao)

References

Details

(Whiteboard: [parity-IE])

Attachments

(1 file, 2 obsolete files)

I've been thinking about open search discovery, and I'm pretty sure I think it is simply a bad idea to begin with.  If the user wants to add a search engine, they might go to the menu to check if it is available, or they might go to a list of all available engines, but I don't think we should improve the discoverability of the possibility, because odds are the user won't care to begin with and the notification is just capturing their attention needlessly the vast majority of the time.  I think we should remove the visual cue on the search button on all platforms.  Right now the user might notice the cue reasonably often, but only actually act on the cue three or four times during the entire life cycle of using the browser.

People will likely criticize this change saying "it is important that I am able to see that that a search engine is available, in case I want to add it." I believe that notifications have a cost of momentarily wasting the user's time, and it is only worth going through with the notification if there is a reasonable chance that the user is going to act on it.  In my opinion, adding a search engine doesn't pass the bar of reasonable chance of action.

This very likely won't get addressed for Firefox 3, but I wanted to get the bug filed in case we consider it for the next release.
Do you have actual eye-tracking results showing people being distracted by it? My casual observation of my test user group (who think they are coworkers) shows that if we had an image of a naked person waving a $100 bill in the search box, they wouldn't notice it. Not only is it a big blank area, it's a big blank area that's totally, absolutely uninteresting while the page they want to see is loading, which is when the potentially-distracting change in appearance happens.
It depends on the implementation, I think the changes on linux are much more noticeable (which was the point of the changes), but I don't think people are necessarily noticing the glowing blue down arrow on OS X or Windows every time it shows up.  My overall point though is not based on empirical data but rather a proposed design principle for notifications.
Summary: Remove open search notification in primary UI? → Remove open search notification in primary UI
Blocks: 588481
See parent bug 588481 for a more detailed discussion of why certain notifications don't pass the test of reasonable probably of user action, and end up hurting the relative discoverability of other more important controls.
Stephen: track on the timeline and nominate?
Requesting blocking on getting this cleaned up, a number of indicators are moving to secondary UI, and this one should as well.  Patch could be as simple as an icon drop to remove the blue smudge.
blocking2.0: --- → ?
I agree with Faaborg; we're the only browser to make a visible indication here, and it's sadly present even when through inaction users have indicated they either don't want the search or haven't really understood what it's for.

We shouldn't ship another release with it. I'm also removing the dependency on always being able to add a search; it would be nice, but I no longer believe it should block the removal.
blocking2.0: ? → final+
No longer depends on: 482229
Only browser out of what set? I've long since forgotten who we stole the blue glow from, but my guess was IE, and when I go to amazon.com in whatever this version of IE that shipped with Win7 is (can't find the UI to find out what it is, but I'd guess IE8), the dropmarker arrow in the search box gets an orange background.
Yeah, the "nobody else has it" argument doesn't fly. To me the convincing part of this bug is that people don't even recognize this thing as a notification, it's just noise.
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #474415 - Flags: review?(gavin.sharp)
Attached patch patchSplinter Review
updated to tip
Attachment #474415 - Attachment is obsolete: true
Attachment #474496 - Flags: review?(gavin.sharp)
Attachment #474415 - Flags: review?(gavin.sharp)
Blocks: 415958
Attached patch alternative patch (obsolete) — Splinter Review
This removes the styling but keeps the addengines attribute for now.
Attachment #475449 - Flags: review?(gavin.sharp)
Attachment #475449 - Flags: review?(gavin.sharp) → review+
Comment on attachment 474496 [details] [diff] [review]
patch

Actually I think this is probably fine too. I don't think there's much benefit to keeping the attribute for third party themes... I dunno, up to you.
Attachment #474496 - Flags: review?(gavin.sharp) → review+
Picked the first patch.

http://hg.mozilla.org/mozilla-central/rev/7fe80c3c0f1c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [parity-IE]
Target Milestone: --- → Firefox 4.0b7
Attachment #475449 - Attachment is obsolete: true
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100921 Firefox/4.0b7pre

Our Mozmill tests have also been updated. Only Litmus tests are missing updates.
Status: RESOLVED → VERIFIED
Flags: in-litmus?(hskupin)
Updated the Litmus test:
https://litmus.mozilla.org/show_test.cgi?id=10225
Flags: in-litmus?(hskupin) → in-litmus+
See Also: → 1106432
You need to log in before you can comment on or make changes to this bug.