Search suggest needs a rethink
loco_roco
is very bad because the suggestions provided by google suggest are not
relevant at all compared to a list of search terms that i have
previously entered into the search box as in firefox 1.0/1.5. So now
when i want to do a search i did previously, i get a list of unrelated
entries in the drop down.
Also, sometimes when i want to search with another search engine, I'd
type a search term into the box then switch to another search engine.
As i understand it, with the suggest feature, the search term would be
sent as i type it. I'm not too hot no that.
Solutions,
1. Disable suggest by default. Allow those who want it to enable it
through manage search engines. At the very least allow users to disable
it.
2. Put search history entries at the top of the drop down and
differentiate them from the suggest ones.
Thomas Stache
> 2. Put search history entries at the top of the drop down and
> differentiate them from the suggest ones.
>
That's a good suggestion. The dropdown can be beefed up a bit with
grouping headers and several lists of results. Have a look at the
current Flock builds, I think including live results from the bookmarks
are a good idea. Instead of just searching via an engine on the web, the
user would be reminded that he had bookmarked matching pages.
Thomas
beltzner
> Currently google suggest will replace my search history. I think this
> is very bad because the suggestions provided by google suggest are not
> relevant at all compared to a list of search terms that i have
Well, I agree with your conclusion, but not your premise! Suggest
results are indeed relevant (and are less likely to contain spelling
mistakes!), although not necessarily moreso than one's search history.
The suggestions, sourced from the search provider or the user's search
history, should be provided in a way that helps the user find the most
relevant results as matched against the information they've typed.
I'll discuss this more in a bit, below.
> Also, sometimes when i want to search with another search engine, I'd
> type a search term into the box then switch to another search engine.
> As i understand it, with the suggest feature, the search term would be
> sent as i type it. I'm not too hot no that.
Not sure what you mean here ... the suggests code will only send the
search term if you re-engage autocomplete (by cursor movement, by
editing the string) but not until that time. The term itself isn't
sent to the search engine until you hit enter or click the search
button.
> Solutions,
>
> 1. Disable suggest by default. Allow those who want it to enable it
> through manage search engines. At the very least allow users to disable
> it.
For the majority of our users, the suggests functionality will assist
with composing better search terms, ensuring search terms are spelled
correctly, and predicting what the user wants to search for. It's a
no-brainer that this should be enabled by default.
It is also, however, a no brainer that we should provide a mechanism
for people like yourself to disable it.
The UI for this leads to some interesting questions. Should it be
enabled/disabled for the search box, or for the search provider? How
much management UI should we be displaying? Should there be a visual
indicator of the current state? Some ideas here:
- a context-menu toggle for "enable/disable" should act on the searchbox,
- in the Manage Engines... UI, a user can turn it off permanently for
a specific engine
- when it's enabled, we add a glyph to the search engine icon
(those are listed in declining order of my personal preference, fwiw,
but I'd love to hear some feedback on these ideas)
> 2. Put search history entries at the top of the drop down and
> differentiate them from the suggest ones.
I ended up talking about this with jhughes, brettw, and vlad on IRC
yesterday, and with shaver and mconnor in a separate conversation. The
issues here seem to be:
- don't want to confuse a suggest result with a history result
- case 1: user looking for engadget types "enga" and sees a
suggested result "engagement rings" and thinks its
a search history result and we ruin another relationship.
- case 2: user looking for "hot dogs" types in "hot" and sees
a history result "hot girls" and thinks it's a suggested
result and thinks less of the search provider.
- don't want to add useless pixels to what is currently a very
llightweight and fast piece of UI
- adds visual noise
- makes it harder to parse the results
- want to keep the number of keypresses between what the user has
typed and the "correct" suggestion/history result to a minimum
Current implementations of suggests-in-search-boxes (Google Toolbar,
Spotlight, the spotlight-like-plugin for Safari) display categories to
split out the results by type, but I would suggest that for our
purposes, this UI is too heavy, adds useless pixels (the category
headers which aren't selectable and don't really do anything) and
means that unless the right category is put on top, the user might
have to cursor-down a long way to get to the result that they wanted.
Instead, I'd propose that we interleave the results. Obviously this
creates problems in terms of determining which are suggestions vs.
history results. I'm less convinced that we *need* to make this
distinction (and would posit that when most engines offer
suggests-like functionality, a lot of the time the sets will intersect
pretty closely!) but should we wish to, there are lightweight ways to
do it:
- add a small glyph beside the search results, or,
- add the "last searched for date" next to history results, or,
- use a different colour or text style for one of the types.
Interleaving gets us a lot of goodness in that we can always be sure
that we've got the autocompletion that most closely matches what the
user has already specified as close to the user's input focus as
possible. I think the question of whether that result is a search
history result or a suggestion result will be fundamentally
uninteresting to most users, who are just looking for something, and
only care about finding it. :)
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
beltzner
> That's a good suggestion. The dropdown can be beefed up a bit with
> grouping headers and several lists of results. Have a look at the
> current Flock builds, I think including live results from the bookmarks
> are a good idea. Instead of just searching via an engine on the web, the
> user would be reminded that he had bookmarked matching pages.
Some words of caution here:
So now some results go to search pages, some results go to bookmark
results, and some results are actually headers and don't go anywhere.
I'd rather not do that, actually, as I think it's more confusing.
Searching through one's bookmarks is a different task than searching
the web. In one case, the user knows that there is a specific page
they are looking for. In another, they might know that there is
specific content out there, but they are willing to discover that the
content might have changed location, or new and associated content is
out there, etc. The Places design tries to address the "searching my
local web" and maybe that should get integrated into a single search
box, but I'm less sure that those tasks are as closely associated as
you might think.
Also, Spotlight isn't as fantastic as you might think. In a lot of
cases, the user *knows* that something they're looking for is an email
vs. a file vs. a bookmark, and so seeing the other results (which
reduces the amount of space for the type of result they're interested
in) is less efficient and useful than a UI designer might imagine.
Definitely worth thinking about, but remember that more search results
!= better search results.
loco_roco
> - in the Manage Engines... UI, a user can turn it off permanently for
> a specific engine
> - when it's enabled, we add a glyph to the search engine icon
>
> (those are listed in declining order of my personal preference, fwiw,
> but I'd love to hear some feedback on these ideas)
I was thinking a checkbox in manage search engines to turn it off for
all the search plugins but I like your first idea too. It just occurred
to me suggest will be really useful for dictionary search plugins.
> Instead, I'd propose that we interleave the results. Obviously this
> creates problems in terms of determining which are suggestions vs.
> history results. I'm less convinced that we *need* to make this
> distinction (and would posit that when most engines offer
> suggests-like functionality, a lot of the time the sets will intersect
> pretty closely!) but should we wish to, there are lightweight ways to
> do it:
>
> - add a small glyph beside the search results, or,
> - add the "last searched for date" next to history results, or,
> - use a different colour or text style for one of the types.
>
> Interleaving gets us a lot of goodness in that we can always be sure
> that we've got the autocompletion that most closely matches what the
> user has already specified as close to the user's input focus as
> possible. I think the question of whether that result is a search
> history result or a suggestion result will be fundamentally
> uninteresting to most users, who are just looking for something, and
> only care about finding it. :)
I still think the user's search history should be placed on top for
autocomplete even if you don't make a distinction between them because
this list will contain keywords/topics that the user is sure to be
interested in. I don't think a search provider would be able to provide
more relevant suggestions unless they give you suggestions based on
your search history with them (say through google's personalised
search).
One unrelated question, will we be able to spell check in searchbar
soon?
Gavin Sharp
> Not sure what you mean here ... the suggests code will only send the
> search term if you re-engage autocomplete (by cursor movement, by
> editing the string) but not until that time. The term itself isn't
> sent to the search engine until you hit enter or click the search
> button.
The way you phrased this sounds like you're contradicting yourself :). I
guess "[The search term is sent only] if you re-engage autocomplete" and
"the term itself isn't sent [...] until you press enter" both have
different meanings of "sent": the currently loaded page doesn't change
until you press enter, but the search term *is* sent to the search
engine each time a change is made to the field, to get the
suggestions... which I guess may be a concern for some. Saying "the term
itself isn't sent to the search engine until you hit enter" is
potentially misleading.
Gavin
Robert Marshall
> I still think the user's search history should be placed on top for
> autocomplete even if you don't make a distinction between them because
> this list will contain keywords/topics that the user is sure to be
> interested in. I don't think a search provider would be able to provide
> more relevant suggestions unless they give you suggestions based on
> your search history with them (say through google's personalised
> search).
I agree with this. There are three main situations I can see:
- User has only typed a few letters - in this case, neither the 1.5
behaviour or the 2.0a2 behaviour are particularly useful, so I don't
think it matters much what happens. The only weak argument I have is
that a user typing "p" and seeing a list with "paris hilton" at the top
is going to be surprised no matter what other UI is added.
- User has typed more, and is searching for a specific topic they have
performed many searches on in the past - in this case, search history is
more likely to be useful, and it's unlikely the suggestions will provide
any new ground.
- User is searching for a new topic - in this case, search history will
give few, if any, results, and the suggestions (which will be at or very
near the top) are likely to help.
As for distinction, "These terms are suggestions from Google and not
what your husband/girlfriend/son/dog has been searching for" is quite a
lot to express in a change of colour or an icon, so I think some text is
needed. Maybe simply a disabled item labelled "Google's suggestions"
would do?
Peter Kasting
> The UI for this leads to some interesting questions. Should it be
> enabled/disabled for the search box, or for the search provider? How
> much management UI should we be displaying? Should there be a visual
> indicator of the current state? Some ideas here:
>
> - in the Manage Engines... UI, a user can turn it off permanently for
> a specific engine
> - when it's enabled, we add a glyph to the search engine icon
>
> (those are listed in declining order of my personal preference, fwiw,
> but I'd love to hear some feedback on these ideas)
I think as an end-user, I either want suggest or I don't. Controlling
things on a per-search-engine basis seems too fine-grained. Are
suggestions really going to be so varied between engines that they'll be
really useful with one and so annoying I have to turn them off with another?
So, whether it's context menu on the search box, or in some prefs pane
somewhere, I think a simple option to enable/disable is good enough.
The hope is that most people won't have a reason to turn it off at all.
I think if we do a good enough job in presentation of the suggest
results, there's no need for a glyph.
> 2. Put search history entries at the top of the drop down and
>
> - don't want to confuse a suggest result with a history result
The cases you mentioned here are good, and may be a source of irritation
with suggest, but I'm not sure they're the primary issue.
> - don't want to add useless pixels to what is currently a very
> llightweight and fast piece of UI
Or, if we do add "useless" pixels, ensure the impact is as low as
possible both in terms of space and keystrokes. If we added pixels, I'd
probably suggest a single dotted line between history and autocomplete
results, or perhaps (if it weren't too big) such a line with small,
light text like "--Suggestions--". But no categorization, big gaps, etc.
> - want to keep the number of keypresses between what the user has
> typed and the "correct" suggestion/history result to a minimum
Another way to say this is that we want the results to be "useful" and
the user to feel like the browser is helping, rather than hurting him.
Autocomplete results where a useful result is first feel helpful.
Autocomplete where the first results aren't helpful seems to irritate
users, even though the results showing up aren't hurting them.
Of course, if we ever do inline autocomplete of search results, then we
really would want to make the first result as useful as possible.
> Instead, I'd propose that we interleave the results. Obviously this
> creates problems in terms of determining which are suggestions vs.
> history results. I'm less convinced that we *need* to make this
> distinction (and would posit that when most engines offer
> suggests-like functionality, a lot of the time the sets will intersect
> pretty closely!) but should we wish to, there are lightweight ways to
> do it:
>
> - add a small glyph beside the search results, or,
> - add the "last searched for date" next to history results, or,
> - use a different colour or text style for one of the types.
--or my proposal above
> Interleaving gets us a lot of goodness in that we can always be sure
> that we've got the autocompletion that most closely matches what the
> user has already specified as close to the user's input focus as
> possible. I think the question of whether that result is a search
> history result or a suggestion result will be fundamentally
> uninteresting to most users, who are just looking for something, and
> only care about finding it. :)
I agree that probably users don't really care about this (hence my
comment that your very first issue, about confusing the two, was
probably not the primary problem).
Thus a union of the lists seems good to me too.
FWIW, I have bug 338061 tracking this issue at
https://bugzilla.mozilla.org/show_bug.cgi?id=338061 .
My personal opinion is that the best interleave method (or at least a
very good one) is likely to be the simplest: as others have suggested,
place history results first, then suggest results. I'd be interested to
hear heuristics that enable us to guess that a suggested result is
actually more likely for this user to want than a matching result from
his history. This gives us good behavior in both cases where the user
has searched for a term before and ones where he hasn't.
On the technical implementation side, I'd imagine we'd want to hold the
autocomplete results until the suggests come back and then display them
all at once, but just go with the history results if the suggestions
aren't back in, say, 100 ms. However, I suppose that putting the
suggestions at the end would also give us the option of dynamically
adding to the list as results come back, if we thought that was good
(which I don't).
PK
Brett Wilson
I think we need to have headings like the Google toolbar & everybody else.
First, I disagree with interleaving them in the first place. If I've
previously searched for something, I think it's much more likely that
I'm interested in my previous search. Plus, I don't even see how we
would interleave them. Google and Yahoo both do careful ordering of the
suggestions based on popularity or some other metric. How do we insert
your history into that list?
I don't see how using different text stylings or small glyphs solves the
problems you mention with confusion. To solve the confusion problems, it
has to be immediately obvious to anybody, even a new user, where these
items are coming from. Glyphs and fonts don't solve these problems.
"History" and "Suggestions" does.
I also don't agree with your argument about visual clutter. Google
Toolbar 4 that I'm looking at has a light green History and Suggestions
heading. It looks great; it's very clear. The headings are right aligned
so I don't even see them when I'm scanning the list. I think the popup
looks very clean and simple, and I think having glyphs for every/some
line(s) would have more clutter and confusion.
Brett
Pam Greene
>
> Instead, I'd propose that we interleave the results. Obviously this
> creates problems in terms of determining which are suggestions vs.
> history results. I'm less convinced that we *need* to make this
> distinction (and would posit that when most engines offer
> suggests-like functionality, a lot of the time the sets will intersect
> pretty closely!) but should we wish to, there are lightweight ways to
> do it:
>
> - add a small glyph beside the search results, or,
> - add the "last searched for date" next to history results, or,
> - use a different colour or text style for one of the types.
>
> that we've got the autocompletion that most closely matches what the
> user has already specified as close to the user's input focus as
> possible. I think the question of whether that result is a search
> history result or a suggestion result will be fundamentally
> uninteresting to most users, who are just looking for something, and
> only care about finding it. :)
I have to disagree with this premise. It's important not only that users
find what they're looking for, but also that they understand some measure of
what the software is doing and how they got where they are. Interleaving
will lead to much more confusion and a feeling of lack of control, and I'm
not convinced that a typeface or icon is enough to cure it.
I'd vote for two sections: results from search history with no heading, a
single minimal separator, then results from suggest. The separator could be
a thin line, or it could be grey text ("Did you mean...", "Search
Suggestions", etc.).
- Pam
Fergy
for the search engine, all you need is an searchhistory-icon.
Joe Hughes
> It is also, however, a no brainer that we should provide a mechanism
> for people like yourself to disable it.
>
> The UI for this leads to some interesting questions. Should it be
> enabled/disabled for the search box, or for the search provider? How
> much management UI should we be displaying? Should there be a visual
> indicator of the current state? Some ideas here:
I vote for one option to disable the suggestions for all engines at
once, for simplicity's sake. If finicky people want to adjust them on a
per-engine basis, they can always install versions of certain engine
plugins that don't contain the suggestion spec.
> Instead, I'd propose that we interleave the results. Obviously this
> creates problems in terms of determining which are suggestions vs.
> history results. I'm less convinced that we *need* to make this
> distinction (and would posit that when most engines offer
> suggests-like functionality, a lot of the time the sets will intersect
> pretty closely!) but should we wish to, there are lightweight ways to
> do it:
How do we know how to interleave them? As far as what we get back from
the engines, I think we mostly just get the order in which the engine
ranked the suggestions, but not the data used to generate that ranking.
It'll be more straightforward (both visually and code-wise) to just put
the history items first.
Note: in my first-pass patch for this, I also remove any suggestions
that appear in the history.
.joe.
Bram van Leur
space we have as we probably want to keep the list compact.
A "Keyword suggestions" heading sounds fine to me. We might even give
the heading a tooltip to explain where these suggestions are coming
from. It could even be made to fold on click to allow the user to hide
the drop-down section(s).
Making it extensible such that new (foldable) sections like "Bookmarks"
can be added to would be nice to make sure new extensions will all
integrate neatly into the search box.
maj...@gmail.com
their own based on cookies.