adjust the title and url text sizes

VERIFIED FIXED in Firefox 3 beta5

Status

()

P2
normal
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: moco, Assigned: Mardak)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 3 beta5
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments, 1 obsolete attachment)

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."
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."
Keywords: uiwanted
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.
(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

11 years ago
(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.
>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.
I find it hard to read anything but the titles. I've noticed this on my own before finding this discussion.
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.
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.
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
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

11 years ago
(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.
Flags: blocking-firefox3?
Component: Places → Location Bar and Autocomplete
QA Contact: places → location.bar
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.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Summary: make the title and url text in autocomplete result the same size → adjust the title and url text sizes
Target Milestone: --- → Firefox 3 M11
if we wanted to test it out as the same size, what would be the best way to do that, a userchrome hack?
makjen@gmail.com, try this in your userChrome.css

.ac-comment {
 font-size: 100% ! important;
}
Priority: P2 → P1
Posted image another design draft (obsolete) —
This would fix bug 409974, too.
Attachment #294887 - Flags: ui-review?(beltzner)
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: uiwanted
Resolution: --- → DUPLICATE
Duplicate of bug: 393508
Need this for tracking at least. Bug 393508 isn't blocking.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Depends on: 393508
(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.
Sorry about that, didn't realize this was blocking.

Comment 21

11 years ago
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.
Target Milestone: Firefox 3 beta3 → Firefox 3 beta4
(Assignee)

Comment 22

11 years ago
(Assignee)

Comment 23

11 years ago
Saves 82pixels by dropping 2 rows
(Assignee)

Comment 24

11 years ago
Saves an additional 16px (2px per row)

Total difference from trunk: 98px
(Assignee)

Comment 25

11 years ago
Saves on 2 px per line compared to the "font-size: larger"
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.
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

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

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

11 years ago
(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 on attachment 294887 [details]
another design draft

see attachment 304080 [details]
Attachment #294887 - Attachment is obsolete: true
Attachment #294887 - Flags: ui-review?(beltzner)
(Assignee)

Comment 33

11 years ago
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:34-edward.lee@engineering.uiuc.edu-showall.adaptive.keyword.compact/

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
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.
Assignee: nobody → faaborg
Status: REOPENED → NEW
Keywords: uiwanted
Whiteboard: [needs final decision]
Assignee: faaborg → beltzner
Target Milestone: Firefox 3 beta4 → Firefox 3
(Assignee)

Comment 35

11 years ago
Posted patch 1.15emSplinter Review
Duplicate of this bug: 420565
Duplicate of this bug: 422096

Comment 38

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

11 years ago
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.
(Assignee)

Comment 41

11 years ago
(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.
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.
Posted image 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.
This doesn't need to block the beta, though I'm hoping to get it done by then anyway.
Priority: P1 → P2
(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 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)
Attachment #310782 - Flags: ui-review+
Keywords: uiwanted
Whiteboard: [needs final decision]
(Assignee)

Comment 48

11 years ago
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 :) 
Flags: in-litmus?
(Assignee)

Comment 49

11 years ago
Posted patch v1Splinter Review
1.15em + 2px
Assignee: beltzner → edilee
Status: NEW → ASSIGNED
Attachment #310793 - Flags: review?(beltzner)
Comment on attachment 310793 [details] [diff] [review]
v1

r+a=beltzner, to be tested through litmus
Attachment #310793 - Flags: review?(beltzner)
Attachment #310793 - Flags: review+
Attachment #310793 - Flags: approval1.9b5+
Attachment #310793 - Flags: approval1.9+
(Assignee)

Comment 51

11 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3 → Firefox 3 beta5

Comment 52

11 years ago
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.
>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.
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
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
(Assignee)

Updated

11 years ago
Blocks: 424619
You need to log in before you can comment on or make changes to this bug.