The default chrome of Firefox has not been altered since the launch of
Firefox 1.0. It would be presumptuous to assume that the way in which
users interact with their browsers has gone unchanged between that time
and our planned 3Q2006 release date for Fx2, and even more presumptuous
for us to assume that we got things 100% right with Firefox 1.0. Ben's
been thinking about this for a while, and he and Joe and I got together
today to take a good hard look at the browser window with the following
goals:

  - remove UI elements that aren't useful to majority of users
  - increase usability of elements that are useful
  - increase focus on web content

This is our first pass at the redesign, as an ASCII mockup. Some design
points have been called out and I'll go into detail about those below:

           (1) -.          .- (2)                               (5) -.
                |          |          .- (3)             (4) -.      |
                v          v          v                       v      v
.----------------------------------------------------------------------.
| File   Edit   View   History   Bookmarks   Help             [_][=][x]|
|----------------------------------------------------------------------|
|.--. .--.  ,.--.-------------------.--,,--,.   ,----------.---,,  .i. |
||<-| |->| ( |^v| {} www.foo.com  v |.)||=>| ) (  google G |.O |)  -O- |
|'--' '--'  `'--'-------------------'--''--''   '----------'--v''  'i' |
|----------------------------------------------------------------------|
|(.O) (&) (BBC News v) (Mozilla)                                       |
|.-----------,.-----------,.-----------,-------------------------------|
||{} Bar     || {} Foo (x)|| {} Baz    |                               |
|-------------'           '--------------------------------------------|
|                                                                    |^|
|                                                                    |H|
:                             (page content)                         : :
.                                                                    . .
:                                                                    : :
|                                                                    |V|
|                                                                    //|
'----------------------------------------------------------------------'
   ^     ^               ^       ^                                    ^

   '     |               |       |                                    |
  (6)    '- (7)     (8) -'       '- (9)                         (10) -'

(1) The reload button [^v] moves to be inside the URL bar so that it is
     directly related with page which will be affected by it

(2) The "Go" menu is renamed "History" as per the Places UI Design, and
     the contents will focus on navigating a user's session history

(3) The RSS [.)] and Go [=>] buttons move inside the URL bar, again to
     emphasize their direct relationship with the page. The Go button
     becomes a stateful button that is either "Go" or "Stop"; if a page
     is not loading, or if a user is typing in a URL, the button is "Go".
     If a page is loading and a user is not typing in a URL, the button
     is "Stop". The lock icon (not shown) and URL drop-down control (v)
     would continue to be rendered as they currently exist.

(4) The search engine selection drop-down button [.O] moves to the
     right and takes on a more button-like appearance with a general
     "search" icon (like a magnifying glass). The search plugin icon
     will appear in the search text field alongside text provided by
     the plugin (ie: [G] Search with Google); this text & icon may be
     rendered semi-transparent to make it lighter.

(5) The throbber will become the progress indicator as well as the
     progress meter, with a pie chart in the center filling up to
     indicate overall page load progress

(6) The bookmark search button (.o) is on the personal bookmark toolbar

(7) The Home button (&) moves to the personal bookmark toolbar

(8) Closebuttons appear on the active tab only in order to achieve the
     best combination of having closebuttons appear where users expect &
     preserving as much area as possible on background tabs for selection
     and display of tab names.

(9) Tabs are a fixed width

(10) The status bar is hidden by default, and the page resizer is in the
      bottom right corner underneath the scrollbar.

This is a lot to take in, and change is always jarring, and ASCII is
really ugly, so I'd ask that you take a few minutes before responding,
and then perhaps write about both your visceral and reflective reactions
and thoughts.

There were also a few open questions that we'd like to get some
discussion started on:

(A) We suggested reducing the amount of real estate dedicated to the
     home button, and also tried to draw attention to the "personal"
     nature of the personal bookmarks toolbar (PBT). Do we need the home
     button shown by default at all? Is it time to get rid of this?

(B) Discussion of the Places UI led to a thoughtful point by mconnor,
     which was that small visual changes to always-on buttons aren't good
     ways of indicating the presence or absence of an item for a page.
     So instead of a "star" button in the toolbar, we decided to just
     leave tagging off the default chrome and letting users discover it
     just as they discovered tabbed browsing. Alternatives include the
     state-displaying "star" button, a normal toolbar button for "add
     tag", putting a translucent "post-it note" overlay on top of the URL
     bar favicon to indicate the presence of tags on a page, or some
     combination of these ideas.

(C) As discussed in this group, we're hoping to provide functionality on
     the context menu to let a user change the PBT to display any of the
     root entries from the Places organization UI's left hand side. By
     default this would be the PBT folder, but it could be a saved
     search, or even a folder provided by an extension for del.icio.us or
     some similar bookmark sharing service. Do we want to provide UI on
     the toolbar for switching between these items, like a [+][-] button
     that scrolls up/down the list? Or a [...] button that lets a user
     choose? Essentially, do we see the need for top-level chrome as
     opposed to keeping it as a context-menu item?

(D) Hiding the status bar by default means that a user will no longer be
     able to hover over a link and see where it goes. Do we want to show
     target URLs on hover if no other title attribute is set?

(E) Do we want to change the appearance of the mouse cursor on hovering
     over links in order to indicate whether the link will open a new
     window or not?

(Also note that we explicitly decided not to focus on visual style and
design issues, and instead focused on the UI as a wireframe onto which
we can later paint. I'll be starting that discussion soon, actually,
although perhaps in dev.apps.firefox.fx2theme or some such similar group)

cheers,
mike (& ben & joe)

--
mike beltzner, user experience lead, mozilla corporation

28 feb 2006 kl. 12.29 skrev Mike Beltzner:

First of all, I think many of the changes look great, and are a step  
in the right direction. Here are some thoughts.

I was actually thinking this before I came to this paragraph. I have  
rarely seen the Home button used, neither by novice users such as my  
parents, nor by any other people I know.  If they have a favorite  
page, they either keep a bookmark to it in the toolbar, or (quite  
common in fact) they do not know how to use the PBT at all so they  
just manually re-write their URLs every time.

So one question is: How are newbie users supposed to understand how/
when to use the PBT?

Every time you use a new computer, or open the browser at work, or in  
school, the personal toolbar has these default bookmarks of CNN,  
Times, Windows Media Player, and what-not.

The fact that you get used to seeing these same (ad-like) links on  
every new browser window, on all new/uncustomized computers, does not  
make the impression of that space being particularly personal.  
Indeed, it doesn't feel very personal at all, and I think users thus  
tend to ignore/miss that space completely.

It's important, almost for security reasons, that we show somewhere  
(where-ever that may be) where a link to points to.

I remember the "good" old days when you could fool people into going  
to bad places (because they didn't pay attention to where a link  
pointed before clicking).   I don't want this to come back. ;-)

Sounds like a good idea.

/Håkan

Hey,

these are quite some interesting thoughts.

On 02/28/06 12:29, Mike Beltzner wrote:

That's nice eye candy, but I have the impression that it's just another
place for the progress bar now that the status bar ist hidden by
default. I wouldn't mind a progress-indicating throbber, though.

The close tab button was on the right hand side before, and I find it
very useful that there is such a button on every tab now, so that i can
easily and fast close tabs in the background without right-clicking them
first. This would be lost. Also, some people might be confused because
sometimes it's there, sometimes it isn't.

What happens if there are too many tabs for the window width?

So people won't see where a link is pointing to... But, on the other
hand, only few people actually look at it, and those can enable the
status bar manually. Showing the address on hover hides parts of the page.

I haven't ever seen anyone use it.

Yes! That would finally be a good idea to see where it will open! I've
waited for this for years!

Ok, I consider myself a power user with a high grade of customization,
but I have in fact seen that some people don't even notice things I find
highly useful. So the direction is correct imho.

-Benedikt

This scheme shows up below again, I'd need to see that in artwork to
find out if I like it. Just to put a scheme in contrast, having reload
next to back and forth is something like "load previous page, load next
page, load this page". Given that bfcache is not always right, having
the "load this page" next to back and forth might be nice, too.
I'm more worried about having differently sized buttons in my toolbar
though, and having to find out how to aim and hit small buttons inside
the urlbar.

Do we still want to have a go button? It's always the first thing I
remove from the toolbar, and I find the state dependence of the button a
bit confusing.

I'd rather keep the status bar and kill the throbber.

That means what for lots of tabs?

I frequently use it to get back to the startpage without having to close
the tab, open a new tab, and place it in the tab order.

I'd like to add that Luke provided data that the search bar and the home
page have very different acceptance rates depending on locale.
We're not really sure why that is, so I don't think that we should make
the search page less accessible.

I don't want that. This would seriously impact the gut-feeling I have
while being online. I want the information on where I'm going in trusted
chrome.

That'd be nice.

Axel

Some initial reactions:

Sounds good.

I was under the impression that such a setup was bad because a user
could decide "oh I can't wait for this page to load any longer", click
the "stop" button, only to find it had changed to a "go" button in the
intervening time (perhaps only a few ms), so causing the page to reload
again.

Sounds good.

Can it be moved away again? It might be a reasonable default location,
but personal toolbar space is precious.

Eep! ;) As in "you will be able to fit exactly n tabs in the window
before overflow occurs whether you like it or not"? That certainly would
match the way that _I_ use the browser where having many tabs per window
and tabs are mainly distinguished by icon (and memory, of course).
What's the advantage of this setup? There must be some cost in the tab
overflow solution so this seems to penalise people who actually use tabs...

Having the status bar hidden by default seems like a poor idea from the
point of view of security. Will there be some other way to tell where a
link goes before clicking it?

I think it could probably die, but maybe it's too familiar to people?

The problem is in the "if no other title attribute is set". Ideally
there would be a way to show, unambiguously, the destination of a link.
Currently the status bar almost does this - the only exception I can
think of is when someone rewrites the link destination in its click
event. We want to make it harder for people to obscure link destinations
not easier.

On 2/28/06, Mike Beltzner <beltz...@mozilla.com> wrote:

I have no problem with any of these changes from an accessibility
perspective.  (Note: icons inside the URL bar are not accessible, but
this is a current problem, not a regression.)

However, from a usability perspective, I strongly object to two
points: combining the stop/refresh buttons, and hiding the status bar
by default.  As others have noted, combining the stop and refresh
buttons means that people who get frustrated by a slow-loading page
and click "stop" may find that it has magically turned into "refresh"
between the time they decided to click it and the time they actually
clicked it.  A quick web search for "stop reload button" finds a
Firefox extension to enable this, a userChrome hack to enable this,
and many many blogs and forums with people complaining about the
combined button in Safari and Opera.

As for hiding the status bar, it obscures a very important piece of
information -- the link target.  Yes, I know there are ways to
override it if JavaScript is on, but I will also note that the
NoScript extension -- which disables JavaScript except on whitelisted
sites -- has been downloaded over 5 million times from AMO.  Moving
this information to a tooltip is a poor replacement, first because it
can be overridden by the link's title attribute, and second because
the tooltip displays on a delay while the status bar displays
immediately.

--
Cheers,
-Mark

There may be ways to finesse this--for instance, we could figure out the
number of milliseconds that it takes for a typical user to decide to
click and actually complete the click, and discard that click if the
page stops loading within that time period.  (I realize that it doesn't
take into account accessibility scenarios when that decision-to-click
time is longer, but I know there's been talk of an "accessible
configuration", and maybe we can make the buttons separate in that case.)

Sure, it should remain configurable through the toolbar setup.

You can always turn the status bar back on (this is Safari's solution).
  We've also tossed around the idea of the destination location for a
link appearing near (but not over) the location bar, rather than in a
dedicated place in the status bar.

.joe.

I think home button should be off by default. Very few people use it.
They can turn it on or use the history menu if they want it.

I thought the point of the new bookmarking system was to (1) make more
people aware of and able to use bookmarks and to (2) make it more useful
to people that already do. Making it non-default basically makes (1) go
away. If we decide that our system isn't useful enough for people that
currently don't use bookmarks, this is a fine decision. Otherwise, we
should realize that average users will not notice any
difference/improvements in bookmark behaviors in FF2.

A warning: making the contents of the personal toolbar folder a generic
query will be REALLY slow. The current system is designed assuming that
queries will be short-lived (i.e. in a menu) or very simple (i.e.
queries over a langth of time in the places page). If you make a
complicated query long-lived, it will re-query the database whenever
things happen to keep it up-to-date. (Note: "my 5 favorite pages" is
considered a complex query.) In these cases, every time a frame in a
page is loaded, we will reconstruct the toolbar. There are ways to make
this more efficient, but there's no time budgeted for it and it's a lot
of work.

That should read "That certainly _wouldn't_ match the way...".

Regarding combined stop/reload: I used to be for it but now I'm against it.

I think IE tried this in the previous preview release, and they put it
back in response to extreme user uproar. We should expect something similar.

Hixie convinced me it is a bad idea. AJAX pages to requests in the
background all the time and there's no right thing to do. What is the
status of the button? If I see "reload" I can't cancel the status of an
XML request. If I see "cancel" I can't reload the page.

Brett

Le 28/02/2006 12:29, Mike Beltzner a ecrit :

This was the way it was in Netscape 6/7 and Mozilla Suite, there is a
bug about it and it created an endless dispute about wether the home
button is part of the navigational system or not (and the Mozilla Suite
Home Button extension had it's time of glory because of it). This
decision was reverted whith Firefox which had the home button back.

Personnally I think it wouldn't be a good idea, but I could live with it
if users can put it back in the navigation bar.

I just would like to remind you that :

- lots of people have a homepage set that they constantly use, it is my
case with our company's intranet page (and all the companies I know have
an intranet page employees use permanently), it is also the case of joe
user for who we have a specially crafted "firefox google home page"
- if you put it in the personal bookmark toolbar, the home button will
disappear in fullscreen mode, which means that you will have to enable
the personal bookmarks toolbar in FS mode ?
- the personal bookmark bar is... personal for the bookmarks I choose to
put there, not for default UI buttons, having a 16px wide home button
there won't be very useful for people who use it because it's just too small

I switched to Firebird when the mozilla suite home button extension
stopped working with the new releases of Mozilla Suite 2 years ago and
the possibility to have a home button on the main bar was put as a
"wontfix" by AOL/Netscape. The existence of a home button on the main
toolbar was used by the anti home button advocates in that time with a
discourse which basically said "if you want a browser with a big home
button, use phoenix and not mozilla suite".

I am really really not sure that it is a good idea, actually, I think it
is a bad idea ;).

pascal

On 2/28/06, Brett Wilson <bre...@gmail.com> wrote:

Not stop/reload; stop/go. I think everyone here is in agreement that
stop/reload are not only problems for the reasons you, James and Hixie
realize, but also because they aren't symmetrical concepts.

Just wanted to thank everyone for the comments so far - please keep
going, it's really quite helpful. I've got a bunch of meetings today
but hope to squeeze out some comebacks for you in a bit ...

cheers,
mike

--
-------
mike beltzner, user experience lead, mozilla corporation

On 2/28/06, Benedikt Kantus <bugzi...@bkantus.de> wrote:

I'll put in a vote for keeping the close buttons on every tab, too.  As a
heavy user of tabs (something we're hoping more people will become, no?) and
a recent convert from Safari (something else we're hoping more people will
become, right? :), I really appreciate again being able to close tabs I no
longer need without having to switch to each one first.  (Right-clicking
might as well not exist on the Mac as far as discoverability goes.  Not even
power users ever think to right-click on something to see what it might do.
I only just this moment tried right-clicking on a tab, and only because of
Benedikt's comment.)

I think I understand the rationale, but I'm having a hard time coming up
with "the one right width," which says to me that having variable widths is
better after all.  Looking at my screen right now, I have 8 tabs open, and
the tabs are a bit smaller than I'd like for ideal icon+name(+closebox)
display.  But I definitely wouldn't want any fewer tabs visible, either; I
regularly have a dozen open.  With a favicon plus a close box I can identify
the tab (reasonably well) and do everything I need with it.  That's a good
minimum tab width, but not a good maximum.  Is there really a perfect middle
ground, or a more compelling argument for fixed widths?

- Pam

It seems much simpler and more consistent to keep the buttons separate.
Plus, as has been pointed out, XMLHttpRequest, timed redirects and
anything else which can cause data to suddenly start loading should be
handled gracefully. What was the rationale behind this proposed change?

This goes against the principle of having sensible defaults though. The
ability to see where links are (likely) to go is important to *all*
users. It's easy to tell someone "look in the status bar before you
click a link". It's much harder to tell them "Go to tools - options -
advanced - general - display status bar and tick the box, then look in
the status bar before you click a link".

Well if it appears somewhere else, that would be fine.

I understand now, that's much better. I tenatively support that change.

I also support getting rid of the status bar as long as we can find some
good way to show link destinations. Safari shows it in the URL bar,
which I found kind of weird.

I'm still not sure I understand. What happens in the following situations:

A page finishes loading. Does "Stop" change to "Go"? If so, what happens
when I click "Go"?
A page starts a background XMLHttpRequest operation. Does "Go" change to
"Stop"? Does this depend on whether the user was entering text in the
URL bar at the time?
Assuming "Go" changes to "Stop" in the example above, what happens when
"Stop" is clicked? I assume the XMLHttpRequest operation is abandoned,
the button changes back to "Go" and "Go" acts on the URL bar contents?

I'm not sure I really see the difference between "Stop" and "Reload"
unless you're already typing in the URL bar which, in most of the
problematic situations, isn't a factor.

I would assume that when you are typing in the URL bar, you have the
"Go" button. The rest of the time you would see the "Stop" button just
like you do now. If there isn't anything loading, you would probably see
a disabled stop button as now. There will still be a separate "Reload"
button as always.

I like the idea, but I have a few concerns: can these buttons inside the URL bar
be brought outside of it? I imagine a lot of users would want to put it back
wherever they had it before. Secondly, will these buttons be getting smaller, or
will the URL bar be getting bigger? I'm not sure I like either option...

Undecided. I guess this one's something you have to see before thinking about
it. It will be strange not having a progress bar, although I think most people
take it with a pinch of salt already, as it's often a poor indicator of a page's
progress.

Can it be moved back again (by the user)?

At which width? :) At the original width (i.e. the width of a lonely tab in a
window) will mean that only 5 tabs can fit in for me. I guess it depends how the
overflow solution goes.

Worst suggestion of the lot :) I'm strongly against this, mainly for comfort
reasons. I think I look at the destination of nearly every link in the status
bar. I think Gerv and Jesse should be pinged on this decision, although I'm sure
I can predict their feelings...

Well I'll raise my hand to say that I use it :) I don't use the bookmarks
toolbar though. What would be the suggested method of going to the homepage if
this is removed?

I don't think this is too necessary personally. Extensions can do this and I
think that's enough.

Good work, it's all in the right direction IMO, except the status bar plan. Is
there a wiki page or bug dedicated to these new ideas?

Dan Cater.

Why do we have a resizer at all on win/linux? It's not a standard part of
Windows or Gnome UI, where the standard affordance is to drag the edges of
the window.

--BDS

I've been on a crusade to get a resizer on all windows in Gnome for a
while (yes, this is the lamest crusade ever).

I just like the larger clickable area, and I think it's a bit more
discoverable.

Cheers,
Steven Garrity

+1

I think that making the tab width fixed from the beginning would be an
overkill. Let's see how it would affect usability for different numbers
of tabs (on 1280x1024 with no close button on every tab, as planned):

1) Tabs can fit into the window while keeping their current maximum
width, n < 5
No changes here.

2) Tabs can reasonably fit into the window with a fair part of the title
visible, 5 < n < ~13
No big impact on usability, this amount of tabs can be comfortably dealt
with currently, so the the overflow seems unnecessary. In fact, it makes
the experience worse.

3) n > ~13
Tabs are getting too small, overflow is obviously much better here.

I think most would agree that more users tend to fall into the second
category than the third. I believe that it would be a fair compromise to
resize the tabs until the smallest size that doesn't impact usability is
reached and introduce overflow from there.

Cheers,
Adam

I believe the argument is that it gives a bigger area to hit.

Of course this argument is undermined by the fact that the resizer on Linux
doesn't work correctly and never actually has.  Which means that it's just
wasted screen real estate that makes your window do weird things if you _do_
accidentally click on it.

-Boris

Does that mean that the scrollbar should be displayed at all times? I
recall that that has been discussed before, backed up by some
guidelines. I don't think that those guidelines don't necessarily make
the best sense in a browser application, though (I do understand that
rationale for editors).

Axel

No. If there's no need for the scrollbar, it wouldn't be shown. I'm not
exactly sure why last night at 4am I thought mentioning its location
beneath the scrollbar was so important.

The ultra-astute will also note that I accidentally left out the "Tools"
menu as well. Oops.

cheers,
mike

--
mike beltzner, user experience lead, mozilla corporation

You're using a bit of a straw man argument in describing the barriers to
getting at this information. There's no reason why we wouldn't just
create a "Show Status Bar" item in the View menu :)

I would suggest that most users aren't fascinated by URL destinations,
and/or don't realize that this information is shown down in the status
bar, and/or don't know how to meaningfully interpret this information.
After all, the purpose of a hyperlink is to hide the implementation
detail (the URL) behind meaningful text (the anchor).

Let's start thinking about the reasons why someone *wants* to see the
URL for a given anchor:

  - they are curious to know where an uninformative (ie: click _here_)
    URL is going to take them

  - they are suspicious of the validity of an anchor (ie: _sign_in_)

  - they are information-hounds

The first case is the most interesting/likely IMO, but there's no
guarantee that the URL itself will be any more informative than the link
to the common user, or that the user would know that hovering over that
link would show them the actual destination. Maybe instead what we want
to do is show a "what this button will do" indication when a user hovers
over a link.

Currently hover does this:

    blah blah _link_ blah blah
                ...................................
                | contents of the title attribute |
                '''''''''''''''''''''''''''''''''''

Several people have accurately pointed out that we shouldn't just use
that mechanism for showing information about the link destination
because it would both require overriding that title and would also be
easy to spoof. But how about ..:

    blah blah _link_ blah blah
                ...................................
                | contents of the title attribute |
                '''''''''''''''''''''''''''''''''''
                   |[->] opens http://www.link.com in this page|

By using an icon, and maybe a light-grey text rendering on some
semi-transparent layer which is visually different from the tooltip
presentation, we get a non-spoofable in-place display. We could also
take the opportunity to provide richer messages, like:

  -> opens http://www.link.com in this page
  -> opens http://www.link.com in a new page
  oO runs a script
  >| submits a form

Joe's idea of putting it in the URL bar is interesting, but I think it
would end up being very distracting.

My solution might actually be overkill. Showing the status bar isn't
that hard to do, and I'm not completely convinced that we *need* to show
this information without a direct user request (ie: View > Show Status
Bar) to see it.

cheers,
mike

--
mike beltzner, user experience lead, mozilla corporation