Do we have too many ways to search?

Bryan Clark clarkbw at gmail.com
Tue Aug 12 02:02:48 UTC 2014


I know @mpt was poking fun but (as you mention) practically speaking he
could have made that tweet years ago about with the about:home page showing
3 search inputs.

I agree that the redundancy isn't good, especially when combined with
varying degrees of functionality for each input.  I don't think the
redundancy argument alone is reason enough to stop doing something but I
certainly agree that it could be the symptom of a deeper issue.  As Madhava
pointed out one of the first efforts earlier in the year was to level up
the search inputs to the same functionality, this was a strategy piece and
a fairly straightforward usability win.

When the new tab page search input was first landed in Nightly and Aurora,
the FHR numbers I saw described people using the new input but perhaps to
the detriment of the search input box.  Meaning we possibly didn't gain
search activity but spread it out across a new area.  And the total numbers
looked something like the activity of the context menu search, so small
potatoes.  There's no reason to jump for joy with stats like those but also
it doesn't mean that it's a failure worth ripping out.  As the change rolls
out further we'll get better numbers.

As mentioned in the bug this new tab search input is mostly about
visibility of search.  The default engine is much more visible and the
search engine chooser has become more visible as well; many people don't
look at the chrome.  If you notice in Chrome they are actually not
implementing search in the content pages but bouncing a users focus up to
the omnibar, I suspect that is part user training and part reusing an
implementation.  We could certainly try something like that if we felt the
awesomebar had the best search behavior, but currently it's not quite
there; I think we can get it there but it will take some work.

And I buy into the Madhava vision, though I'm not sure it's the awesomebar
that is the final answer.  I think we need a new search interface that
rethinks how people are using search inputs and what they expect.  Many
people go straight to the google homepage because of the instant search and
all the extras it provides.  Research in search has shown that many, almost
half, of searches are actually for factual information, things Wikipedia
could answer.

Given all the new findings/behaviours and new APIs that are available since
the awesomebar was first created I've been inclined to think that a new
approach might be better.  Not sure what that looks like just yet.

~ Bryan




On Mon, Aug 11, 2014 at 10:18 AM, Mike Conley <mconley at mozilla.com> wrote:

> I saw somebody tweet this a few days ago:
>
> https://bug1050596.bugzilla.mozilla.org/attachment.cgi?id=8469707
>
> and it did strike me that there might indeed be a redundancy problem
> here. When a user first opens Firefox, by default, they're going to
> have 3 inputs for searching (AwesomeBar, search bar, about:home search
> input). Same goes for new tabs now.
>
> That's quite a lot of redundancy, and I wonder if it's perhaps too
> much. I know there's been a bit of work lately experimenting with
> search, and I just wanted to raise this redundancy as a little flag in
> case it has somehow slipped past the radar.
>
> Not that redundancy is intrinsically bad, but it is sometimes the
> symptom of a deeper problem.
>
> I originally opened this as a bug[1], where there's already been a
> little bit of discussion, but after reflection, it was clear that
> there wasn't anything immediately actionable in the bug report, so
> I've closed the bug and moved the discussion here to expose it to a
> wider audience. Perhaps read the bug comments to bring yourself up to
> speed on the current state of the discussion.
>
> Are there any additional thoughts on this?
>
> -Mike
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1050596
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20140811/8c200365/attachment.html>


More information about the firefox-dev mailing list