403159 - Switch location bar auto-complete to a two line view

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P4)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Now that the results in location bar auto-complete are displayed in a richlist view, we should try switching to the UI planned in bug# 393508, with the title on the first line of the result item, and the URL on the second line.  Both items should be black, and the title should be in a slightly larger font.

Comment 1

[(not reading, please use [e-mail] instead)]

taking

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: screen shot

Comment 3

[Jesse Ruderman]

I think this is a bad idea.  It totally breaks scanning the list for either titles or URLs and causes fewer items to be shown.

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: updated screen shot

faaborg wrote:  "Right now the display is visually kind of heavy, I wonder if we tried lightening the shade of the lines separating the entries, and maybe using grey text on the URLs."

Comment 5

[Reed Loden [:reed]]

I agree with Jesse. I really don't like this, as it hurts my ability to find sites easily and quickly, especially if they are closer down to the end of the list.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Color as a selective visual variable

>It totally breaks scanning the list for either
>titles or URLs and causes fewer items to be shown

Indeed.  Here is a visual design solution that maintains scalability based on perceptual cogsci.

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

sorry s/scalability/scanability 

Comment 8

[Jesse Ruderman]

Scanning lists of similar URLs is much easier when they're adjacent.  With the current UI, I can see at a glance whether all of the results are from the same domain, and that saves me a lot of time.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

>With the current UI, I can see at a glance whether all of the results are from >the same domain, and that saves me a lot of time.

I agree that you can only see differences between different URLs well with the current UI, and I also agree that this saves you a lot of time.

However, I don't think URLs comparisons are at all a common activity of our users, and I believe this is one of those situations where the product will suffer if we design for our personal needs instead of needs of mainstream end users.

Comment 10

[Jesse Ruderman]

I'm not comparing URLs for the sake of comparing URLs.  I'm scanning a list and skipping a block of similar URLs because they're not what I'm looking for.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

I totally understand your use case, and why this change makes that task considerably more difficult.  However, I'm pushing for this change based on the notion that all of the various people who have told me that Firefox is their favorite search engine don't scan a list of URLs, nor do they make a navigation decision based on the URL itself.

Essentially what we are debating here is a fundamental change in what the location bar is for, from purely a widget for directly entering URLs, to being a local search engine for content you have seen on the Web (which happens to also display URLs).  If Firefox 4 has full text indexing, the difference will be even more pronounced.  I believe this is a great opportunity for us to jump ahead of IE and Safari in usability, and create a UI for information retrieval that is even faster than searching Google.

Comment 12

[Marco Bonardo [:mak]]

if the purpose of this is to concentrate user attenction on title instead of url, why not simply swap title and url in location bar.
the current tabular view is really fast to search, i know that title or url contains something and i visually scan the corresponding column, discarding 50% of useless data. With the purposed view i have to visually skip a lot of data to search only in titles or only in urls, if it would be better, than tables had not been ever created...
About colour distinction, what about colour-blind people? 
different OS and OS themes will also need different colours... 

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

>if the purpose of this is to concentrate user attenction on title instead of
>url, why not simply swap title and url in location bar.

We want to get the UI ready for integrating matches against the page text in future releases.  Also, placing the URL off to the right will result in increased eye movement when the user is entering a url into the location bar and looking for a match.  If the user is entering a title, and they never view the URL, we may have phishing implications.

>About colour distinction, what about colour-blind people? 

If we use green, URLs will appear darkish yellow to users with protanopia and deuteranopia, and blue to user's with tritanopia.  The perceived color will not impact the user's ability to visually select and scan URLs.

The visual effect will impact user's with rod monochromancy, who constitute 0.00001% of our user base.  However the overall effect is that they will have to read the titles and URLs in alternating sequence, instead of visually selecting one or the other to scan.

Comment 14

[Wesley Johnston (:wesj)]

Attachment: Alternate Styling?

Here's a screen shot of how I have this implemented on my machine (via a hackjob extension). I styled the title bold and the URL... normal. I like it this way. Highlighting is done with a color background, which might give problems to users with color issues. Then again, it could be inherited from some system value that they could easily change too.

Comment 15

[Majken Connor [:Kensie]]

(In reply to comment #14)
> Created an attachment (id=290219) [details]
> Alternate Styling?
> 
> Here's a screen shot of how I have this implemented on my machine (via a
> hackjob extension). I styled the title bold and the URL... normal. I like it
> this way. Highlighting is done with a color background, which might give
> problems to users with color issues. Then again, it could be inherited from
> some system value that they could easily change too.
> 

I'm not a fan of the bubbles, but the bold on the titles actually makes this usable for me. Much easier to scan the list just for urls, even though they're not bold, because I can easily ignore the lines that are bold.  Hopefully something like this isn't impossible due to issues with l10n fonts or something.

Comment 16

[(not reading, please use [e-mail] instead)]

note, beltzner and mconnor (and others) think that underlying is better than highlighting.

screen shot of latest version coming...

Comment 17

[(not reading, please use [e-mail] instead)]

Attachment: screen shot from the mac

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

> --> (https://bugzilla.mozilla.org/attachment.cgi?id=290219)
>Alternate Styling?

I think we should seriously consider using this type of styling on OS X, probably matching the shade of blue used in their tag editor widget (like the address field of mail.app). 

Comment 19

[(not reading, please use [e-mail] instead)]

> I think we should seriously consider using this type of styling on OS X

including the alternating grey / white background colors?

Comment 20

[Alex Faaborg [:faaborg] (Firefox UX)]

>including the alternating grey / white background colors?

maybe, I'm less sure on the alternating lines, still trying to decide.  Either way, I think the blue rounded box on the match will fit in well since it is a common piece of visual feedback for recognized text.  I would also use it to match text in the title, like we are currently doing with underlining and bold.

Comment 21

[ronin.achilles]

Attachment: Cleaner & Sober Autocomplete

(In reply to comment #19)
> > I think we should seriously consider using this type of styling on OS X
> 
> including the alternating grey / white background colors?
> 

I seriously hope we are not planning the alternating background for windows atleast. Even in the current version, I think there are too many elements which are trying to grab attention (including the borders under each item). I think there is some scope to clean it up a little. Have userChromed the current version a bit and cleaned it up in a way that:

- My first glance is on the word being searched for + the Titles which show up
- Second glance (if needed) is on the URL

...without borders and with a more Vista-ish highlighting.

My hacked version is definitely no where near perfect, but you get the idea.

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

>I seriously hope we are not planning the alternating background for windows
>atleast

No, there is no precedent for alternating rows on windows.  I agree with you about removing the lines, but I think we might want to add a few pixels of whitespace to help separate the items.

>with a more Vista-ish highlighting.

yes, we really need to get gradient highlighting working on all of our rich list views, not just location bar auto-complete, but also the download manager, the add-ons manager, and in content handling dialog boxes.

Comment 23

[Dão Gottwald [:dao]]

(In reply to comment #22)
> No, there is no precedent for alternating rows on windows.

I don't really think that matters. Thunderbird 2 uses alternating rows for the mail trees, which I believe was a usability win regardless of the platform. Our Downloads window has alternating rows, too.

That's not to say that the option to use neither an alternating background nor borders shouldn't be explored. But if we had to decide between them, the background solution should probably win.

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

>Our Downloads window has alternating rows, too.

which I personally don't like that much, I tend to push towards platform consistency in terms of visual design unless there is a really massive usability win.  In this case I think a small amount of added white space and alternating rows are functionally the same in terms of being able to easily scan the entries in the list.  If Linux, XP and Vista use whitespace, and OS X uses alternating rows, I think we should adapt the themes to fit in.

Comment 25

[AndrewM]

Just to be clear, there is going to be a pref (browser.urlbar.richResults I believe) to disable two-line autocomplete and return to the current view, right?

I very much like the new two-line view (especially the 'Cleaner & Sober Autocomplete', attachment 290562 [details]) but there are times when being able to switch to the current view would be very useful :)

Comment 26

[(not reading, please use [e-mail] instead)]

fixed as part of bug #399664.

Comment 27

[Wesley Johnston (:wesj)]

I alternated the rows in my mockup because I have a widescreen display. With the urlbar fairly long, and the window at fullscreen the Star and Tag icons are about a mile away from the actual titles and urls. The banding helped tie them together visually for me. I actually tried putting the star and tag icons as a badge on the favicon for a bit, but it didn't look very good.

The lines should do the same, but to me they make things look more cluttered and thus make scanning harder. But hey, that's what extensions and userChrome are there to fix, eh?

Comment 28

[ronin.achilles]

Filed Bug #406215 [New Autocomplete/Location Bar needs some CSS love] for improving the look and feel of the new location-bar autocomplete.

Comment 29

[(not reading, please use [e-mail] instead)]

> the Star and Tag icons are about a mile away from the actual titles and urls.

see bug #406240

Comment 30

[Tim De Pauw]

(In reply to comment #0)
> the title should be in a slightly larger font.

Just my two cents, but why does the current implementation increase the title's font size rather than decreasing the URL's? The default font size should already be legible, otherwise it wouldn't be the default, so I'd argue that the title should be bold at most. Currently, it's a bit "in your face" compared to the rest of the UI.

Aesthetically speaking, attachment 290219 [details] makes a lot more sense to me. Personally, though, I'd even prefer keeping the default font size for URLs as well, compensated for by some lower contrast. I know it's been argued against, but it just seems logical.

Comment 31

[Marco Bonardo [:mak]]

(In reply to comment #30)
> Just my two cents, but why does the current implementation increase the title's
> font size rather than decreasing the URL's? 

about that, see Bug 407204

Comment 32

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using the following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007120704 Minefield/3.0b2pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre

-and-

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120704 Minefield/3.0b2pre

Note that I'm verifying basic functionality/appearance only; spin-off bugs are already filed, and there will likely be more refinements.

Comment 33

[Simon Strandman]

With the new autocomplete I can no longer hold down shift + backspace (mac) or shift + del (PC) to delete multiple entries in the list, like in the old autocomplete. Now I have to select them one by one. Should I file another bug about that?

Comment 34

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #33)
> With the new autocomplete I can no longer hold down shift + backspace (mac) or
> shift + del (PC) to delete multiple entries in the list, like in the old
> autocomplete. Now I have to select them one by one. Should I file another bug
> about that?

Yes, please! And CC me.

Comment 35

[Jo Hermans]

(In reply to comment #33)
> With the new autocomplete I can no longer hold down shift + backspace (mac) or
> shift + del (PC) to delete multiple entries in the list, like in the old
> autocomplete. Now I have to select them one by one. Should I file another bug
> about that?
> 

That's bug 406179.

Comment 36

[Mikel Ward]

I like the way it matches page titles now, but the new dropdown shows too much information.  I want to see the titles prominently but the URLs only if I really care.  I also don't like the green horizontal lines at all.  If color is supposed to be a guide, then the lines and the URLs should be different colors (or just get rid of the lines).

For me, either ronin's "cleaner & sober" mock-up or a single line autocomplete would be much better.

Comment 37

[Brian Moeskau]

"Just to be clear, there is going to be a pref (browser.urlbar.richResults I
believe) to disable two-line autocomplete and return to the current view,
right?"

Please, please tell me this is the case?  Oversized page titles are less than useless to me and just add visual noise.  Overall a great release, but this feature really annoys me.

Comment 38

[Larry Steeger]

I came looking for options to fix FF 3's location bar format and content, when I spotted this entry.  

I agree: the behavior of the new location bar is extremely annoying.

"browser.urlbar.richResults" controls how many (none when set to 0), but doesn't control the format (cluttered and wastes user time with this "visual noise"). This is definitely a search productivity killer.

Is there an option to make the location bar only show url's in one line - no images, no favicons, no title, just a simple, clean url from a user's history.

When I search I want to find new material, new sources. If I want something I already found, and thought important enough to keep in my bookmarks, I go to my bookmarks.

Comment 39

[Majken Connor [:Kensie]]

The location bar autocomplete has *always* been places you've already been, and has never been new search results.

There's also a fair bit of evidence that the new changes do in fact increase productivity - favicons make a site easier to identify, the larger area makes it faster to click the selection. The page title is also easier to process than the url.

Bugzilla, however isn't the place to get help with tweaks. It's to request changes to the core code eg bug fixes, or new features. There are extensions that can do what you'd like https://addons.mozilla.org . There are also lots of google results for customizing the location bar if you give a search.