Switch location bar auto-complete to a two line view

VERIFIED FIXED in Firefox 3 beta2

Status

()

Firefox
Location Bar
P4
normal
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: faaborg, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
Firefox 3 beta2
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
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.
Flags: blocking-firefox3?

Updated

10 years ago
Component: Places → Location Bar and Autocomplete
OS: Windows Vista → All
QA Contact: places → location.bar
Hardware: PC → All

Updated

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P4
Target Milestone: --- → Firefox 3 M10
taking
Assignee: nobody → sspitzer
Depends on: 399664
Created attachment 288961 [details]
screen shot

Comment 3

10 years ago
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.
Created attachment 288972 [details]
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."
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.
(Reporter)

Comment 6

10 years ago
Created attachment 289065 [details]
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.
(Reporter)

Comment 7

10 years ago
sorry s/scalability/scanability 

Comment 8

10 years ago
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.
(Reporter)

Comment 9

10 years ago
>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

10 years ago
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.
(Reporter)

Comment 11

10 years ago
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.

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... 
(Reporter)

Comment 13

10 years ago
>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.
Created attachment 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.
(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.
note, beltzner and mconnor (and others) think that underlying is better than highlighting.

screen shot of latest version coming...
Status: NEW → ASSIGNED
Created attachment 290361 [details]
screen shot from the mac
Attachment #288961 - Attachment is obsolete: true
Attachment #288972 - Attachment is obsolete: true
(Reporter)

Comment 18

10 years ago
> --> (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). 
> I think we should seriously consider using this type of styling on OS X

including the alternating grey / white background colors?
(Reporter)

Comment 20

10 years ago
>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.
Blocks: 405745

Comment 21

10 years ago
Created attachment 290562 [details]
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.
(Reporter)

Comment 22

10 years ago
>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.
(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.
(Reporter)

Comment 24

10 years ago
>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

10 years ago
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 :)
fixed as part of bug #399664.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: polish
Resolution: --- → FIXED
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

10 years ago
Filed Bug #406215 [New Autocomplete/Location Bar needs some CSS love] for improving the look and feel of the new location-bar autocomplete.
> the Star and Tag icons are about a mile away from the actual titles and urls.

see bug #406240
Depends on: 407429

Comment 30

10 years ago
(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.
(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

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.
Status: RESOLVED → VERIFIED

Comment 33

10 years ago
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?
(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

10 years ago
(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

10 years ago
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.

Updated

9 years ago
Depends on: 434172

Comment 37

9 years ago
"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

9 years ago
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.
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.
You need to log in before you can comment on or make changes to this bug.