We are currently using some sort of autocomplete or search suggest in the following places: - Search box - about:home - about:newtab (tbd) - form fields (history autocomplete only) They all currently have slightly different styles and structures. We need to come up with a design that fits all of them. Requirements: - Visual continuity across all use cases - Differentiate between autocomplete from history and search suggestions from the search provider

Philipp, could you estimate this?

In bug 612453 comment 86, Matt and I noted some specific differences between the about:home and newtab autocomplete vs. the others.

Note that this should probably be changed for Aurora so we should keep the changes straightforward to reduce risk.

Design Review: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown.png

Ah, very nice :) Could you also include a mockup for form suggestions so that it is clear that this is also part of the work? I don't have a strong opinion on using all-caps or title case. If we use all-caps, I'd suggest slightly reducing the font size and increasing the letter spacing. What's your take on this?

It would be nice to have the mockups also show hover and active states.

Could I suggest using a different word from "Suggestions" to label suggestions from the search provider? Suggestions from form history are suggestions, too. This actually always confused me, as a user, until I started working on autocomplete bugs as a developer. How about labeling the search provider's suggestions with the provider's name? [Moz ] +---------------------------+ |Mozilla History| |Mozilla Firefox | +---------------------------+ |Mozilla Foundation Google| |Mozart | +---------------------------+

Updated. Autocomplete/suggestions dropdown: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown.png Dropdown spec: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown-spec.png

(In reply to Drew Willcoxon :adw from comment #7) > Could I suggest using a different word from "Suggestions" to label > suggestions from the search provider? Suggestions from form history are > suggestions, too. This actually always confused me, as a user, until I > started working on autocomplete bugs as a developer. > > How about labeling the search provider's suggestions with the provider's > name? > > [Moz ] > +---------------------------+ > |Mozilla History| > |Mozilla Firefox | > +---------------------------+ > |Mozilla Foundation Google| > |Mozart | > +---------------------------+ Hm, I'm hesitant to do this since this would tell the user where those entries are coming from, but not what they are. Also, choosing *any* of the results from the list leads you to Google, so that could be confusing as well. Michael, form elements don't get suggestions (only results from History), so it would be great if you could remove them from there. Otherwise, this looks very good!

Thanks for the feedback, Philipp. Updated Mock and Specs: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown.png http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown-spec.png

Excellent, thanks!

I'm curious, is there a reason we didn't go with some sort of visual distinction between typed and suggested text? Given how widespread that practice is, I suspect there's a good reason behind it.

(In reply to Mike Connor [:mconnor] from comment #12) > I'm curious, is there a reason we didn't go with some sort of visual > distinction between typed and suggested text? Given how widespread that > practice is, I suspect there's a good reason behind it. That's a good point. I don't see a reason not to do it. Michael, what do you think?

I agree, it's a very useful convention. We use a highlight in the Awesomebar, but in this case, I would suggest using a bold weight to distinguish the typed versus the suggested. Going to think about this a bit more...

Bold is pretty common, and done right it can provide a11y hinting (I think). The #1 issue I'd predict being problematic is the current search bar dropdown is very narrow. That said, it's already very poor for multi-word searches, which are increasingly common, so we might want to explore some sort of dynamic sizing anyway.

Couple options here: http://cl.ly/image/2e1s1Z0e3j0x Version 1: Bold Version 2: Highlights (same one we use in the updated Awesome Bar Dropdown design) Version 3: Color I like options 1 and 2 the most, slightly leaning toward the prior because of the clear contrast between the bold and regular type weights.

So, my take is that the bold should be inverted. What's important in this use-case is not what's matching, but what's being suggested. We don't want the user's eye drawn to a bunch of Mozilla entries, we want them drawn to the options they're choosing between. I'll note that Google/Bing/Yahoo all do this already, so I'd like to see us follow their lead. Color feels like a non-starter given a11y concerns as well as compatibility with various themes (where we use native/system colours).

Right, because the user already knows what they typed, it's the remaining content that we want their eyes on. Thanks for the feedback, Mike, See the revised below: http://cl.ly/image/32231R1K1y3n

I agree with Mikes reasoning and the latest v1 looks the clearest to me. I'm a little confused about what a user would have typed in order to get the result in your mockup. If he only typed »moz«, only the »moz«-parts of the suggestions should be printed in regular case, right? And if he typed »Mozilla«, there shouldn't be a suggestion for »Mozart« Or is there something I'm missing?

There is an inconsistency between the search bar dropdown and the new tab/home page dropdowns here. The text in the search bar box always stays the same but the text in the other two dropdowns changes when hovering suggestion items. It's a bit weird and those two behavior should be unified.

Yup, I was basically duplicating the Google in-page UX more or less wholesale, rather than aiming for consistency. We should figure out what's "right" there. I agree with Philipp on v1 looking great. In terms of what's showing, I'll admit it's a bit contrived, but search engines frequently offer spelling corrections or alternate words, and those should be highlighted as different from what the user typed. I'll also note that we shouldn't duplicate what's already typed. Overall, my main concern here is how this scales on small text fields. Most of the search studies I've seen us run suggest that multi-word searches are a majority, so adding another inline indicator (that cuts off text on those lines) seems like a step in the wrong direction. Did we consider somethign a little more visual, leaving more room for text, especially critical for the top result. Something like this: ( (^) is a lazy attempt at a history icon in ASCII) [(G) Moz ] +---+---------------------------+ |(^)|Mozilla | | |Mozilla Firefox | +---+---------------------------+ |(G)|Mozilla Foundation | | |Mozart | +---+---------------------------+

Couple of options below: http://cl.ly/image/3o2P0Z1b2J3Q V1: Utilizes labels instead of icons to avoid icon redundancy V2: Utilizes "All Cap" labels, avoiding the need to indent the history and suggestions V3: Utilizes solely iconography for all labeling Personally, I'm stuck in the middle regarding our labeling options. The all iconography version is clear, but seams a bit redundant. The aligning labeling avoids this redundancy and noise, but may seem out of place when there is only one or two results.

After talking with Philipp, we have decided to move forward with the all iconography version 3. Mock: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown.png Spec: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown-spec.png

Do we really need to label all entries if we're visibly dividing the list? The redundancy seems unnecessary in that context. And I assume the text for OS X in the mock is just an error?

(In reply to Mike Connor [:mconnor] from comment #24) > Do we really need to label all entries if we're visibly dividing the list? > The redundancy seems unnecessary in that context. And I assume the text for > OS X in the mock is just an error?

(In reply to Drew Willcoxon :adw from comment #25) > (In reply to Mike Connor [:mconnor] from comment #24) > > Do we really need to label all entries if we're visibly dividing the list? > > The redundancy seems unnecessary in that context. And I assume the text for > > OS X in the mock is just an error? Only having one icon would lead to a few visual inconsistencies. For example if the first row were highlighted, the icon would be highlighted as well, otherwise it wouldn't. Also, having icons in front of all entries is more consistent with the awesomebar (which we'd ultimately like to integrate better with the other various search fields) and the search fields on most web pages. And yes, the additional text in the OS X mock is an error :)