407204 - adjust the title and url text sizes

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

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

make the title and url text in autocomplete result the same size

in d.a.f, Benjamin writes:  "It's large... it feels large and clunky for some
reason".

from bug #406259, benjamin writes:  "FWIW, I think that clunky feeling is primarily because the title and URL have different font sizes. It looks very busy that way."

gavin writes:  "I still find myself looking for URLs at least half of
the time, so having them be smaller than the title bothers me."

robert writes:  "...the large font isn't particularly good looking--wondering why we have it."

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Also, robert writes: "The vertical placement is odd, so the URL is closer to the border than the title text. This makes it look like the results are sitting low in the rows ... When you open a new window, the green triangle flashes before being replaced by the star."

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

See also bug 406215

Comment 3

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

Here is my rationale for the larger font size for titles:

-Makes the titles easier to read
-External consistency with search engine interfaces
-Visually differentiates titles and URLs (in addition to the use of color)
-Allows us to integrate in full page text results in the next release without changing the UI again
-Titles are human readable, URLs are not, by making the titles larger the interface as a whole presents itself as being designed for humans (30% robo-bullshit as opposed to 50% robo-bullshit).  Specially I want mainstream users who explore this interface to realize that it actually has value, instead of deciding to never touch the thing again because all they see is "ref=topnav_gw_cm_gft/002-0471523-658042"

I agree that the underlying problems (clunky, visually busy) should be addressed in future designs and implementations (faster, better use of whitespace).  But I'm still in favor of using a larger font size for titles for the list of reasons mentioned above.

Comment 4

[Colin Barrett [:cbarrett]]

(In reply to comment #3)
> Here is my rationale for the larger font size for titles:
> 
> -Makes the titles easier to read
> -External consistency with search engine interfaces
> -Visually differentiates titles and URLs (in addition to the use of color)
> -Allows us to integrate in full page text results in the next release without
> changing the UI again
> -Titles are human readable, URLs are not, by making the titles larger the
> interface as a whole presents itself as being designed for humans (30%
> robo-bullshit as opposed to 50% robo-bullshit).  Specially I want mainstream
> users who explore this interface to realize that it actually has value, instead
> of deciding to never touch the thing again because all they see is
> "ref=topnav_gw_cm_gft/002-0471523-658042"
> 
> I agree that the underlying problems (clunky, visually busy) should be
> addressed in future designs and implementations (faster, better use of
> whitespace).  But I'm still in favor of using a larger font size for titles for
> the list of reasons mentioned above.

I really disagree with your emphasis on titles. This would be one thing if we were doing more full text indexing and the titles of our pages were more accurate (they are often very wrong for Bugzilla and other places that have changing titles, though I don't have a solution on how to fix it).

However we are also matching on the URL. It's hard to see the URL because the title of the page is so much larger, it seems difficult to find the URL and examine it. The title is more important, almost always, but does it need to be *so* much bigger?

Comment 5

[Robert Sayre]

(In reply to comment #3)
>
> -Makes the titles easier to read

There's not necessarily a correlation, as long as the text is within a reasonable range. Right now, it's almost too big to be useful in tight rows.

> -External consistency with search engine interfaces
> -Visually differentiates titles and URLs (in addition to the use of color)

It is very inconsistent with the rest of the chrome UI, which could be the reason for the strong negative reactions. For example, it is much larger than the title bar text, the search suggestions, or the spotlight search menu.

> -Allows us to integrate in full page text results in the next release without
> changing the UI again

Sounds like an antipattern to me. We should plan the best UI for the features we have now.

> -Titles are human readable, URLs are not, by making the titles larger the
> interface as a whole presents itself as being designed for humans

There are many ways to emphasize titles in the UI, a goal I don't disagree with. I think the text size is way too big for its location, and I'm relatively sure the that opinion doesn't stem from a stereotypical inability to empathasize with users.

Comment 6

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

>It's hard to see the URL because the title of the page is so much larger

Unlike the color distinction I don't have any specific data, but the size
difference should create increased contrast, making it easier to scan just
URLs.  It seems like making everything the same size would decrease the
visibility of URLs, because they would start to blend in with the titles. 

>but does it need to be *so* much bigger?

We could continue to play around with different sizes, just wanted to lay out
my thought process for making titles larger.

Comment 7

[Al Billings [:abillings - ex-MoCo]]

I find it hard to read anything but the titles. I've noticed this on my own before finding this discussion.

Comment 8

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

I'll work on some mockups showing a variety of different design ideas over the weekend, and post them here and to the autocomplete mockup tracking bug (bug 393508).  We can use those as a specific discussion piece for what we think is too large, too small, etc.

Comment 9

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

Replying to Marco's comment over in bug 403159:

>Just my two cents, but why does the current implementation increase the title's
>font size rather than decreasing the URL's? 

I did considering this, but based on previous threads about the location bar, I felt that anything we did to visually de-emphasize URLs (smaller font, grey, etc) would very likely be rejected by the community.  Due to this, the only way to make the interface title-centric was to give titles a larger font size.

I don't want the titles to be larger, as much as I want the interface to be about titles (and bookmark names) more than it is about URLs.  Making it about both equally will increase the overall complexity of the UI, and it won't give users a solid indication of how to efficiently interact with the new interface.

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

note: that is not my comment, but a quote from another comment :)

my thought is that title should be little smaller than now, while url is ok, don't know if reducing a bit title size will make it immediately the same size as url, but i'd like to see results from this test before commenting

Comment 11

[Majken Connor [:Kensie]]

I think I could live with the page titles being larger, for the reasons faaborg gives, but they're currently just too big. Besides looking entirely wrong IMO, it makes the autocomplete dropdown quite long.  Almost the full height of the browser.  Not so helpful when I'm copying a url off a page where it's not linkified, or I can't copy it (it's in an image, for instance).  Besides being in the way it's too long to scan easily, especially as you're typing to refine results.

Comment 12

[Tim De Pauw]

(In reply to comment #9)
> Replying to Marco's comment over in bug 403159:

It was my comment, actually, but okay. :-)

> >Just my two cents, but why does the current implementation increase the title's
> >font size rather than decreasing the URL's? 
> 
> I did considering this, but based on previous threads about the location bar, I
> felt that anything we did to visually de-emphasize URLs (smaller font, grey,
> etc) would very likely be rejected by the community.  Due to this, the only way
> to make the interface title-centric was to give titles a larger font size.

Has the community ever welcomed change? I'm guilty of this myself, but I'm sure we'd get used to it and see the benefit eventually.

> I don't want the titles to be larger, as much as I want the interface to be
> about titles (and bookmark names) more than it is about URLs.  Making it about
> both equally will increase the overall complexity of the UI, and it won't give
> users a solid indication of how to efficiently interact with the new interface.

I agree with the fact that titles are more important. However, like I said in bug 403159, autocomplete is a bit "in your face" because of the large fonts. To be consistent, the rest of the UI would have to get larger font sizes all over the place, and that's not a change I'd welcome either. Defaults are there for a reason.

Comment 13

[Mike Connor [:mconnor]]

We need to do something here, not sure what exactly is correct, I don't think the same size will be a win, myself, but its pretty huge as-is.  Tweaking summary, blocking.

Comment 14

[Majken Connor [:Kensie]]

if we wanted to test it out as the same size, what would be the best way to do that, a userchrome hack?

Comment 15

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

[e-mail], try this in your userChrome.css

.ac-comment {
 font-size: 100% ! important;
}

Comment 16

[Dão Gottwald [:dao]]

Attachment: another design draft

This would fix bug 409974, too.

Comment 17

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

To reduce the number of different bugs where we are discussing the UI design of location bar autocomplete, I'm marking them as dupes of the mockup tracking bug.  This way we can have a central place for discussion.

Comment 18

[Dão Gottwald [:dao]]

Need this for tracking at least. Bug 393508 isn't blocking.

Comment 19

[Dão Gottwald [:dao]]

(In reply to comment #18)
> Bug 393508 isn't blocking.

Well, forget that. The important thing is: Bug 393508 doesn't describe this bug explicitly. So as a P1 blocker, this should stay open until it has a real resolution -- preferably FIXED, but WONTFIX seems possible too, given that you prefer to keep the title larger.

Comment 20

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

Sorry about that, didn't realize this was blocking.

Comment 21

[Ivan Ičin]

IMHO, real problem is visual clutter, and it comes from the fact that URLs clutter drop down, and not the titles! URLs are just too long.

I can't say that I was thinking exactly about this, but if you look at my mockups of how I thought autocomplete should look like (and as far as I know, it is first mockup with two lines autocomplete), you will see that there were just domain names in URLs: http://features20.blogspot.com/2007/07/natural-languange-navigation-finally.html

I can't say that it resolves all cases, but it would be much cleaner. If you really need to show more of URL, possibly you could use just domain name and last 10 characters with "..." between them.

And somehow I think that green color adds to the feeling, don't have any idea why.

Comment 22

[Ed Lee :Mardak]

Attachment: screenshot of trunk (410px tall)

Comment 23

[Ed Lee :Mardak]

Attachment: screenshot of 8 rows (328px tall)

Saves 82pixels by dropping 2 rows

Comment 24

[Ed Lee :Mardak]

Attachment: screenshot of 8 rows, 1.15em (312px tall)

Saves an additional 16px (2px per row)

Total difference from trunk: 98px

Comment 25

[Ed Lee :Mardak]

Attachment: screenshot of 1.15em (390px tall)

Saves on 2 px per line compared to the "font-size: larger"

Comment 26

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

When the user is interacting with the autocomplete drop down, their task is to select the correct item as quickly as possible.  They aren't likely to care about the content area at all during the interaction.  So I don't think minimizing vertical height of the drop down is the correct metric for deciding if we are making this interface better (as opposed to trying to minimize the height of the navigation toolbar, for instance.)  What I do think is the correct metric, is making sure that people can read and select the first result incredibly quickly.  Walking around the office I am observing people select results out of the location bar drop down so quickly that I'm pretty sure a smaller font size would actually slow people down slightly.

As for the number of results, I'm in favor of reducing it by two since I don't think people are going to read down that far very often.

Comment 27

[Majken Connor [:Kensie]]

The problem is, if you're not working with the autocomplete, it still drops down as you type anyway.  There have been a few times when I've been trying to copy something from a website that isn't linkified and I've been foiled by the dropdown.

I also use a touchpad and the larger the menu is, the longer it takes me to get to something further down the list.  The targets are so large, people are used to hitting text links, so how would a smaller font size slow people down? harder to read?

Of course I'm commenting now and haven't applied the userchrome hack seth supplied me with, to back myself up.

Comment 28

[Robert Sayre]

(In reply to comment #26)
> 
> As for the number of results, I'm in favor of reducing it by two since I don't
> think people are going to read down that far very often.

FWIW, I think the layout of the dropdown is like reading multiple newspaper headlines stacked. It is not easy to scan. Reducing the number of results presented could change that, though.

Comment 29

[Tim De Pauw]

> FWIW, I think the layout of the dropdown is like reading multiple newspaper
> headlines stacked. It is not easy to scan. Reducing the number of results
> presented could change that, though.

I agree. In fact, the scrollbar just adds clutter. Rather than scrolling through the results, you're just going to type more characters 99% of the time. There could be some sort of arrow at the bottom of the dropdown to expand it though, or maybe to simply add a scrollbar when requested.

Comment 30

[Tony Mechelynck [:tonymec]]

(In reply to comment #29)
[...]
> There could be some sort of arrow at the bottom of the dropdown to expand it
> though, or maybe to simply add a scrollbar when requested.
> 

Let me cast a vote here in favour of the scrollbar: in my experience, arrow buttons (as in menus when they overflow the screen) often trigger unwantedly, so I had to replace them by scrollbars in long menus using userChrome.css.

Comment 31

[Tim De Pauw]

(In reply to comment #30)
> Let me cast a vote here in favour of the scrollbar: in my experience, arrow
> buttons (as in menus when they overflow the screen) often trigger unwantedly,
> so I had to replace them by scrollbars in long menus using userChrome.css.

How about a simple "More Results ..." text link then?

Comment 32

[Dão Gottwald [:dao]]

Comment on attachment 294887 [details]
another design draft

see attachment 304080 [details]

Comment 33

[Ed Lee :Mardak]

Here's a build for people to play with that has 6 rows and smaller title font size (1.15em).

https://build.mozilla.org/tryserver-builds/2008-02-18_14:[e-mail]/

The build also has adaptive learning, so going from 10 to 6 rows doesn't feel like I'm missing out on results. Also, there's multi-word matching and highlighting to help filter and find results so 6 rows is acceptable.

Personally, the smaller than "larger" but bigger than url text size feels friendlier.. at least less "shouting-like" than before.

FYI, list of patches:
Bug 401660 - when showing autocomplete result, show tags that partially match
Bug 407946 - emphasize all matching text in title and url, not just the first match in title and url
Bug 415403 - Show matches for all search words for location bar autocomplete
Bug 395735 - Instrument the location bar auto-complete to report accuracy
Bug 395739 - adaptive learning (match entered text to selected item) in url bar autocomplete
Bug 392143 - show keywords as url bar autocomplete choices
Bug 416211 - Tagged results don't show bookmark title when matching the tag
Bug 407204 - adjust the title and url text sizes
Bug 406257 - reduce the number of rows in url bar autocomplete from 10 to 6

Comment 34

[Mike Connor [:mconnor]]

Need to make a call on this today, end of story.

-> Alex to drive to resolution, the fix is easy, but we need to decide what we're doing here.

Comment 35

[Ed Lee :Mardak]

Attachment: 1.15em

Comment 38

[Ryan A. C.]

Attachment: Bolded Name with smaller URL text

Created by User GN85 on mozillazine forums: http://forums.mozillazine.org/viewtopic.php?p=3294043#3294043

The only concern here is the found string highlighting, though the resolution to Bug 407861 might solve that one for us, or perhaps the other way around.

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

Ryan, do we have any CSS for that? I don't actually think there's a box that we can style with the background like that screenshot shows. :(

Right now I'm thinking what we need to do is:

.autocomplete-richlistitem[selected=true] {
 background-image: url(chrome://mozapps/skin/extensions/itemEnabledFader.png) ! important;
 background-color: highlight ! important; 
}

(we might want to copy that itemEnabledFader.png over to a different chrome location, since I think I'm stealing it out of xpinstall atm)

.ac-comment {
 font-size: 1.15em ! important;
} 

as per Mardak's patch

Colour changes to come, we're trying to get system-specific colours where possible.

Comment 40

[Kris Silver]

The last attachment is definitely the most manageable and readable. 

Colour wise, where do users see green urls, this doesn't help differentiate.
Either a shade of black, the colour users see when they type urls thus
enhancing association and recognition, or grey.

Comment 41

[Ed Lee :Mardak]

(In reply to comment #39)
> .autocomplete-richlistitem[selected=true] {
>  background-image: url(chrome://mozapps/skin/extensions/itemEnabledFader.png) !
> important;
Would we do this on all platforms or only windows and linux? I originally put the fader background for the download manager selected item for all platforms, but it was decided to be removed for os x.

Comment 42

[Mike Beltzner [:beltzner, not reading bugmail]]

Hm, the blue kinda clashes with the blue star on OSX, but not in any way that's worse than what we do now. I'll submit patch after I'm done with triage.

Comment 43

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

Attachment: Spotlight idea

What about a small nod to spotlight, use white for behind the favicons, and #fafafa for the results.  We wouldn't want the line in between results to go into the favicon area though.

Comment 44

[Mike Beltzner [:beltzner, not reading bugmail]]

This doesn't need to block the beta, though I'm hoping to get it done by then anyway.

Comment 45

[Dão Gottwald [:dao]]

(In reply to comment #43)
> Created an attachment (id=310669) [details]
> Spotlight idea
> 
> What about a small nod to spotlight, use white for behind the favicons, and
> #fafafa for the results.

I don't want to argue for or against that, but isn't it quite unrelated to the text sizes?

Comment 46

[Ed Lee :Mardak]

Attachment: trunk (larger+2px), 1.15em+2px, 1.15em+1px, 1.15em+0

Comment 47

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 310782 [details]
trunk (larger+2px), 1.15em+2px, 1.15em+1px, 1.15em+0

2nd from the left looks best to me (1.15em+2px)

Comment 48

[Ed Lee :Mardak]

stephend: Open url bar auto complete.. make sure it looks more like the list 2nd from left of attachment 310782 [details] and not like 1st on left :) 

Comment 49

[Ed Lee :Mardak]

Attachment: v1

1.15em + 2px

Comment 50

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 310793 [details] [diff] [review]
v1

r+a=beltzner, to be tested through litmus

Comment 51

[Ed Lee :Mardak]

Checking in browser/themes/gnomestripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v  <--  browser.css
new revision: 1.201; previous revision: 1.200
done
Checking in browser/themes/pinstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/browser.css,v  <--  browser.css
new revision: 1.137; previous revision: 1.136
done
Checking in browser/themes/winstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v  <--  browser.css
new revision: 1.188; previous revision: 1.187
done

Comment 52

[Kris Silver]

Reductions in title size, and bar height are very minor.  I still think the one in comment #38 is easiest to read and manage, with more items, less scrolling, and a centralised favicon.  Just needs the titles to be less thick a font so bold still looks noticeable.

Comment 53

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

>I don't want to argue for or against that, but isn't it quite unrelated to the
>text sizes?

Sorry about that, using the bug to send mardak a file while we were discussing visual changes on irc.  If we want to look into that type of change we will use a separate bug.

Comment 54

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

in-litmus+:

https://litmus.mozilla.org/show_test.cgi?id=5214, and--while I'm here--Verified FIXED using:

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

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

-and-

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