Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Changes to Fx2 Chrome

70 views
Skip to first unread message

Mike Beltzner

unread,
Feb 28, 2006, 6:29:21 AM2/28/06
to
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

HÃ¥kan Waara

unread,
Feb 28, 2006, 7:16:38 AM2/28/06
to Mike Beltzner, dev-apps...@lists.mozilla.org
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.

> (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?

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.

> (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?

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. ;-)

> (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?

Sounds like a good idea.

/HÃ¥kan

Benedikt Kantus

unread,
Feb 28, 2006, 10:37:19 AM2/28/06
to
Hey,

these are quite some interesting thoughts.

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

> (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

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.

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

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.

> (9) Tabs are a fixed width

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

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

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.

> (A) Do we need the home


> button shown by default at all? Is it time to get rid of this?

I haven't ever seen anyone use it.

> (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?

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

Axel Hecht

unread,
Feb 28, 2006, 10:43:07 AM2/28/06
to

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.

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

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.

> (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

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

> (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

That means what for lots of tabs?

> (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?

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.

> (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?

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.

> (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?

That'd be nice.

Axel

James Graham

unread,
Feb 28, 2006, 10:44:42 AM2/28/06
to Mike Beltzner
Some initial reactions:

Mike Beltzner wrote:
>
> (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

Sounds good.

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

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.

> (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

Sounds good.

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

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

> (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

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...

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

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?

> 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?

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

> (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?

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.

Mark Pilgrim

unread,
Feb 28, 2006, 11:28:02 AM2/28/06
to Mike Beltzner, dev-apps...@lists.mozilla.org
On 2/28/06, Mike Beltzner <belt...@mozilla.com> wrote:
> (10) The status bar is hidden by default, and the page resizer is in the
> bottom right corner underneath the scrollbar.

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

Joe Hughes

unread,
Feb 28, 2006, 12:19:06 PM2/28/06
to
James Graham wrote:

> 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.

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

>> (7) The Home button (&) moves to the personal bookmark toolbar
>
> Can it be moved away again? It might be a reasonable default location,
> but personal toolbar space is precious.

Sure, it should remain configurable through the toolbar setup.

>> (10) The status bar is hidden by default, and the page resizer is in the
>> bottom right corner underneath the scrollbar.
>
> 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?

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.

Brett Wilson

unread,
Feb 28, 2006, 12:27:05 PM2/28/06
to
> (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?

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.


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

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.


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

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.

James Graham

unread,
Feb 28, 2006, 12:29:00 PM2/28/06
to
James Graham wrote:

>> (9) Tabs are a fixed width
>
> 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

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

Brett Wilson

unread,
Feb 28, 2006, 12:43:25 PM2/28/06
to
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

pascal chevrel

unread,
Feb 28, 2006, 12:53:08 PM2/28/06
to

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

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

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

Mike Beltzner

unread,
Feb 28, 2006, 12:55:30 PM2/28/06
to Brett Wilson, dev-apps...@lists.mozilla.org
On 2/28/06, Brett Wilson <bre...@gmail.com> wrote:
> Regarding combined stop/reload: I used to be for it but now I'm against it.

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

--
-------

Pam Greene

unread,
Feb 28, 2006, 12:59:32 PM2/28/06
to dev-apps...@lists.mozilla.org

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

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

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.

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

> (9) Tabs are a fixed width

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

James Graham

unread,
Feb 28, 2006, 1:01:32 PM2/28/06
to Joe Hughes
Joe Hughes wrote:
> James Graham wrote:
>
>> 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.
>
> 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.)
>

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?

>> 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?
>
> You can always turn the status bar back on (this is Safari's solution).

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".

> 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.

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

Brett Wilson

unread,
Feb 28, 2006, 1:02:25 PM2/28/06
to
Mike Beltzner wrote:
> On 2/28/06, Brett Wilson <bre...@gmail.com> wrote:
>>Regarding combined stop/reload: I used to be for it but now I'm against it.
> 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.

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.

James Graham

unread,
Feb 28, 2006, 1:21:21 PM2/28/06
to Mike Beltzner, Brett Wilson, dev-apps...@lists.mozilla.org
Mike Beltzner wrote:
> On 2/28/06, Brett Wilson <bre...@gmail.com> wrote:
>> Regarding combined stop/reload: I used to be for it but now I'm against it.
>
> 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.

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.

Brett Wilson

unread,
Feb 28, 2006, 1:31:47 PM2/28/06
to
James Graham wrote:
> 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.

Daniel Cater

unread,
Feb 28, 2006, 2:57:02 PM2/28/06
to
Mike Beltzner wrote:
> (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

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...

> (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

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.

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

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

> (9) Tabs are a fixed width

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.

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

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...

> (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?

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?

> (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?

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

> cheers,
> mike (& ben & joe)

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.

Benjamin Smedberg

unread,
Feb 28, 2006, 3:10:08 PM2/28/06
to
Mike Beltzner wrote:

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

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

Steven Garrity

unread,
Feb 28, 2006, 3:12:39 PM2/28/06
to Benjamin Smedberg, dev-apps...@lists.mozilla.org
Benjamin Smedberg wrote:
> 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.

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

Adam Kowalczyk (Ancestor)

unread,
Feb 28, 2006, 8:00:34 PM2/28/06
to
Pam Greene wrote:
> > (9) Tabs are a fixed width
>
>
> 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.

+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

Boris Zbarsky

unread,
Feb 28, 2006, 11:03:18 PM2/28/06
to

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

Axel Hecht

unread,
Mar 1, 2006, 4:09:29 AM3/1/06
to
Boris Zbarsky wrote:
> Benjamin Smedberg wrote:
>> Mike Beltzner wrote:
>>
>>> (10) The status bar is hidden by default, and the page resizer is in the
>>> bottom right corner underneath the scrollbar.
>>

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

Mike Beltzner

unread,
Mar 1, 2006, 4:34:57 AM3/1/06
to Axel Hecht
Axel Hecht wrote:
> Does that mean that the scrollbar should be displayed at all times? I

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

unread,
Mar 1, 2006, 4:48:16 AM3/1/06
to James Graham, Joe Hughes
James Graham wrote:
>>> 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?
>>
>> You can always turn the status bar back on (this is Safari's solution).
>
> 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".

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

unread,
Mar 1, 2006, 4:54:36 AM3/1/06
to Benedikt Kantus
Benedikt Kantus wrote:
>> (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.
>
> 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.

Having the closebuttons on non-focused tabs causes one of two problems:
either you've got a high potential of accidental data loss, as selecting
a tab makes it extremely possible to accidentally hit the close button,
OR if you disable the inactive tab closebuttons but still render them,
you've got dead-ui.

Having a closebutton on the active tab does a couple of positive things
for usability: first, it makes it easy to see which is the active tab.
Second, it prevents accidental dataloss. Third, it makes it easier to
find the close-tab button since there's only one of them across the
entire tab strip.

There are some disadvantages as you and other have pointed out, but I'd
be interested to see your thoughts of those disadvantages as compared to
the disadvantages of having them *on* each tab. I'm not sure how strong
an argument "it makes closing background tabs less discoverable" is,
seeing as closing background tabs seems like a very advanced
tab-behaviour to be supporting with primary-level UI.

(sidenote: I'll probably mention this again as I go through this
feedback, but one reason why we're proposing fixed-tab widths is that it
means that if a user selects a tab, they can hover over the (x) button
and click-click-click-click to close a series of tabs to the right since
the active close button will always end up in the same location)

>> (9) Tabs are a fixed width
>
> What happens if there are too many tabs for the window width?

Mike Connor is working on solutions for handling-tab overflow that will
ensure we don't shoot ourselves in the foot, here.

cheers,
mike

Mike Beltzner

unread,
Mar 1, 2006, 5:08:33 AM3/1/06
to Adam Kowalczyk (Ancestor)
Adam Kowalczyk (Ancestor) wrote:
> Pam Greene wrote:
>> > (9) Tabs are a fixed width
>>
>> 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.

The rationale is predictable location for the closebutton. I'm not 100%
sure that this is going to be a strong enough reason, but was close
enough to sure to feel comfortable proposing it ;) I just noticed that
closebuttons-on-tabs doesn't seem to be on the 1_8_BRANCH though, so I
can't really test for this. Or is there something wrong with my build?
Did we, uh, forget to land that on branch?

I do share your concern about coming up with the right width, although I
think it would have to be expressed as a %age of the overall window
width with some sensible minimum and maximums. If a user changes the
size of their window, of course the tabs should gracefully expand/collapse.

> 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.

Thanks for this analysis, Adam. I'm not sure that "most" of our users
browse with > 5 tabs, although I'm sure that the majority of our most
passionate users do. What was your criteria for "tabs are too small", by
the way?

Thomas Stache

unread,
Mar 1, 2006, 5:10:51 AM3/1/06
to
Benjamin Smedberg schrieb:

> Mike Beltzner wrote:
>
>> (10) The status bar is hidden by default, and the page resizer is in the
>> bottom right corner underneath the scrollbar.
>
> Why do we have a resizer at all on win

I'd say because every non-maximized window of a native Windows
application has it, e.g. Windows Explorer, no?

Mike Beltzner

unread,
Mar 1, 2006, 5:15:57 AM3/1/06
to Axel Hecht
Axel Hecht wrote:

> 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.

Sadly (since I hate it) we've got some pretty good indications that the
Go button is needed and used by a lot of our more novice user audience
who are dependent on it from their IE holdover days, as well as from a
"I've typed this in, now what?" perspective. Interestingly, from what
I've noticed, the user might actually HIT enter, but they know what it
will do because of the presence of the "Go" button.

>> (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
>
> I'd rather keep the status bar and kill the throbber.

Honestly, the throbber is a more honest indication of page load
progress. I have a personal hate on for *any* sort of progress indicator
that makes bold assertions of overall progress without having any way of
ever knowing when the end will actually come, since basically they
become a "zeno's paradox" indicator. But I digress.

>> (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?
>
> 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.

Mm, that's a very good point.

>> (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?
>
> 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.

There's a couple of issues here. The first is actually a security
concern (which Mark Pilgrim also brought up) which is that when windows
are opened without chrome using JS, we want to make sure that they're
not mistaken for OS windows or don't spoof chrome. I should have
mentioned that we planned on handling that by re-enabling existing code
that shows a read-only URL bar for non-chromed JS windows.

The second issue (spoofing this indication by a tooltip, having the
indication in "trusted chrome") I covered in a recent post (look about
20 minutes into the past).

Mike Beltzner

unread,
Mar 1, 2006, 5:20:12 AM3/1/06
to Mark Pilgrim, dev-apps...@lists.mozilla.org
Mark Pilgrim wrote:
> On 2/28/06, Mike Beltzner <belt...@mozilla.com> wrote:
>> (10) The status bar is hidden by default, and the page resizer is in the
>> bottom right corner underneath the scrollbar.
>
> I have no problem with any of these changes from an accessibility
> perspective. (Note: icons inside the URL bar are not accessible, but

yay \o/

> However, from a usability perspective, I strongly object to two
> points: combining the stop/refresh buttons, and hiding the status bar

As myself and others have noted, it's not stop/refresh that we're
suggesting on combining, but stop/go. And the model would be that only
when you're typing in the URL bar does the button appear as "Go". At all
other times it would be stop or "disabled stop".

> 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.

I think mine might even be in there. I've always hated that about
Safari. And progress bars in the background. And snapback, which never
works like I expect it will. And the bookmarks-replacing-all-of-the-ui
thing, and ... um ... I should stop. :)

> can be overridden by the link's title attribute, and second because
> the tooltip displays on a delay while the status bar displays
> immediately.

And if you need that information immediately, then feel free to turn
your status bar on. I don't think that the majority of our users spend a
lot of time looking down there, which makes them useless pixels in my view.

Mike Beltzner

unread,
Mar 1, 2006, 5:23:21 AM3/1/06
to pascal chevrel
pascal chevrel wrote:
> Le 28/02/2006 12:29, Mike Beltzner a ecrit :
>
>> (7) The Home button (&) moves to the personal bookmark toolbar
[...]

> 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.

You would be able to. So ... can you live with it? :)

Mike Beltzner

unread,
Mar 1, 2006, 5:31:29 AM3/1/06
to Daniel Cater
Daniel Cater wrote:
> Mike Beltzner wrote:
>> (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
>
> 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...

Great question. I don't know if we'd thought about that a lot. My gut
feeling is that yes, they should be able to be brought outside the URL
bar. This might require creating a new class of toolbar button, which is
for "inside the URL bar" version of the button.

As for sizing, I think it would be a combination of making the button
slightly smaller and the URL field bigger.

> 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?

Some form of keyboard shortcut, I had been assuming. Although I note
that none exists today. Hrm.

> 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?

Not yet. The closest thing is http://wiki.mozilla.org/Location_Bar.
There will be soon, though, and I'll post a link to this thread when
it's there. I wanted to get some feedback and thoughts before I put
things onto the wiki.

pascal chevrel

unread,
Mar 1, 2006, 5:36:54 AM3/1/06
to Mike Beltzner

Le 01/03/2006 11:23, Mike Beltzner a ecrit :


> pascal chevrel wrote:
>> Le 28/02/2006 12:29, Mike Beltzner a ecrit :
>>
>>> (7) The Home button (&) moves to the personal bookmark toolbar
> [...]
>> 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.
>
> You would be able to. So ... can you live with it? :)
>
> cheers,
> mike
>

Sure :) My main concern is that most of the regular Firefox people I
know don't even know that they can move their toolbar icons so I don't
see them customize it to put the home button back.

Pascal

Thomas Stache

unread,
Mar 1, 2006, 6:14:51 AM3/1/06
to
Mike Beltzner schrieb:

> Daniel Cater wrote:
>> 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?
>
> Some form of keyboard shortcut, I had been assuming. Although I note
> that none exists today. Hrm.
>

Huh? Here for me "Go->Home Page" has clearly written "Alt+Pos1" next to it.

Thomas

Thomas Stache

unread,
Mar 1, 2006, 6:26:15 AM3/1/06
to
Mike Beltzner schrieb:

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

I tried the "close button only on tabs" way for a while with the
TabMixPlus extension on Firefox 1.5.

My problem was that previously I knew I could close the page I'm viewing
with a button in the upper right corner of the window. With close
buttons on the tabs I have to scan the tab bar to find the tab (and the
close button) for the current page. That forces an additional effort of me.

I'm not convinced that removing the fixed close button on the tab bar is
the right thing to do, after years of using Firefox it feels totally
uncomfortable.

Thomas

Peter Lairo

unread,
Mar 1, 2006, 6:56:00 AM3/1/06
to
Steven Garrity wrote on 28.02.2006 21:12:
> 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).

LOL :-D

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

+1

It's often very hard to find the too-small area where the moue cursor
goes from diagonal arrow to double-arrow, especially in the window's
corners.

--
Regards,

Peter Lairo

Lame attempt to get rich: http://www.lairo.com/donations.html

Peter Lairo

unread,
Mar 1, 2006, 7:17:49 AM3/1/06
to
Some good ideas. Here are a few thoughts:

Mike Beltzner wrote on 28.02.2006 12:29:
> (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) -'


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

This caused a lot of debate in the Mozilla Suite days. One could argue
that the Home button is "personal", but it just seems less than optimal
to have a fixed UI element in the "personal" tool bar.

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

For users who don't know about closing tabs via middle-click or
context-menu (which are the vast majority) this would make it cumbersome
to close (several) background tabs (bring background tab to foreground,
click close button - repeat). When there are only a few (2-4) tabs,
which should cover the majority of cases, there is plenty of space on
the tab for the relevant portion of the page's title and the close button.

> (9) Tabs are a fixed width

I think having a bigger *minimum width* would be the better way to go.
That way the UI wouldn't start hiding tabs too soon (after 3-5 tabs).

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

I agree with Bendikt that hovered links should always be visible in a
consistent location.

> (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?

Considering that most people don't seem to ever use the personal tool
bar (and thus disable it), it might be a good idea to keep it as a way
of getting back to familiar/useful terrain (the current Firefox-Google
page seems a good default).

BTW: Perhaps there could be a "Drag frequently used Links here" text on
the PTB (on first launch).

> (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?

The URL should definitely be shown somewhere. If as title (which is not
as good as the status bar, IMO) then it should be in *addition* to the
title attribute (e.g., on a second line) and not replace the title
attribute.

> (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?

Good idea. Can this be done without interfering with the OS's mouse
cursor setting? Like overlaying a small rectangle (for new window/tab)
and/or an arrow (45° angle) (for external link) onto the OS's "hand".

It would also be useful to indicate if a link went to an external site.

Michael Lefevre

unread,
Mar 1, 2006, 8:24:38 AM3/1/06
to
On 2006-02-28, Mike Beltzner <belt...@mozilla.com> wrote:
[snip]
> (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".

I think in later discussion this has already moved on to being "stop" all
the time except if the user is typing. But what happens if a user starts
typing, and then wants to stop something that the page has started doing?
Bit of an edge case, but it just feels to me (this isn't a great
argument!) like having two buttons switching around in one place is a
recipe for confusion and/or new and interesting bugs. I can't think of
another app that has buttons that switch purposes which isn't annoying...

[snip]


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

If there's a way to move it back, that wouldn't bother me personally. But
it may be worth reviewing some of the argument in
https://bugzilla.mozilla.org/show_bug.cgi?id=89350 - there will be lots of
people complaining about this change. But I guess they would also be
appeased if it can be moved back... I'm not sure if the "average" user
that wouldn't know how to move it would be bothered by the change.

It may not be the intended usage, but I tend to use the home button as a
"panic" button, rather than stop or closing the tab/window. If I'm at work
and a page has some really annoying sound or something, or if I've opened
a new tab from some search results and it's taking forever to load, or
things are going really wrong and the browser is thrashing and looking
like it might fall over, etc, then I use the home button (partly because
the stop button, although overloaded, doesn't actually stop everything).

[snip]


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

The usage of the status bar to see where a URL goes to has been well
discussed in other followups, but I remember there was a whole discussion
in a bug somewhere about how to display hostnames of secure sites
and the solution we ended up with was to display the name next to the
padlock in the status bar. If that goes away, then presumably that
discussion will have to be reopened - otherwise you are back to a
situation where the user knows they have an encrypted connection to
somewhere, but have no way of knowing if they have a secure connection to
www.evilphishers.net rather than www.mybank.com (the URL bar can't
actually be trusted for that for reasons that others can explain better
than me, and making the URL trustable means changing some URLs around in
ways that are weird and unexpected)

In terms of the seeing the URL, for power users that's not a problem if
they can just turn the status bar back on. But the fact that most users
are clueless about security UI isn't a good reason for disabling it - then
you're just accepting that people are always going to be clueless and
there's no point in trying to educate them so that they can avoid being
exploited.

But if there's new anti-phishing stuff happening, I guess that may all be
revisited anyway...

--
Michael

Benedikt Kantus

unread,
Mar 1, 2006, 9:26:23 AM3/1/06
to
On 03/01/06 13:17, Peter Lairo wrote:

> I agree with Bendikt that hovered links should always be visible in a
> consistent location.

Benedikt. I'm called Benedikt, like the Pope *g*

> The URL should definitely be shown somewhere. If as title (which is not
> as good as the status bar, IMO) then it should be in *addition* to the
> title attribute (e.g., on a second line) and not replace the title
> attribute.

Right. In fact, I don't care much about the title attribute, nor do I
think many others do. But i _do_ care about where a links takes me. So
we should under all circumstances show the URL.
But, as I said, image you hover over a link and a two-line-hovering
popup appears above the page. That's too much of the webpage not being seen.

-Benedikt

Benedikt Kantus

unread,
Mar 1, 2006, 9:45:30 AM3/1/06
to
> Having the closebuttons on non-focused tabs causes one of two problems:
> either you've got a high potential of accidental data loss, as selecting
> a tab makes it extremely possible to accidentally hit the close button,

Well, that never happened to me... and I keep judging others' behaviour
like mine. But if a tab is really really small so you could click
accidentally on the close button, it will not be shown anyway. I bet
that if people can keep their hand still enough to click on a text link,
they can also avoid clicking on the close button accidentally.
No seriously, there's some truth in what you said as well. I wouldn't
say there is a _high_ potential of data loss, but it exists at least.

> OR if you disable the inactive tab closebuttons but still render them,
> you've got dead-ui.

True.

> Having a closebutton on the active tab does a couple of positive things
> for usability: first, it makes it easy to see which is the active tab.
> Second, it prevents accidental dataloss. Third, it makes it easier to
> find the close-tab button since there's only one of them across the
> entire tab strip.

That's all true... actually both designs have advantages. My professor
used to say: "People face trade-offs."
I hopefully have made my point clear enough, but I understand you
arguments as well. I don't want to judge about them ;-)

>> What happens if there are too many tabs for the window width?
>
> Mike Connor is working on solutions for handling-tab overflow that will
> ensure we don't shoot ourselves in the foot, here.

Will he post it here when it's been finished?


-Benedikt

Tuukka Tolvanen

unread,
Mar 1, 2006, 11:22:52 AM3/1/06
to
Mike Beltzner kirjoitti:

> (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

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

Hmm, while we're statefully combining buttons, why a Reload button
separate from Stop/Go? Is the case of editing the location text and then
reloading the current document so common that it needs its own button?

't.

Peter Lairo

unread,
Mar 1, 2006, 11:38:50 AM3/1/06
to
Benedikt Kantus wrote on 01.03.2006 15:26:
> On 03/01/06 13:17, Peter Lairo wrote:
>
>> I agree with Bendikt ...

>
> Benedikt. I'm called Benedikt, like the Pope *g*

Sorry, I was focussing on the "kt" part. :-[

Who is the "Pope"??? :-\ ;-)

>> The URL should definitely be shown somewhere. If as title (which is not
>> as good as the status bar, IMO) then it should be in *addition* to the
>> title attribute (e.g., on a second line) and not replace the title
>> attribute.
>
> Right. In fact, I don't care much about the title attribute, nor do I
> think many others do. But i _do_ care about where a links takes me. So
> we should under all circumstances show the URL.
> But, as I said, image you hover over a link and a two-line-hovering
> popup appears above the page. That's too much of the webpage not being seen.

If the URL "tool tip" shows-up (near)instantaneously, it's going to be a
nightmare on pages with many links. It'll be like those annoying ads
(e.g.,
http://www.gamestar.de/magazin/previews/angeschaut/strategie/31476/ -
hover over double-underlined links).

Robert Accettura

unread,
Mar 1, 2006, 11:43:09 AM3/1/06
to
I'm writing this pretty much off the cuff, so pardon if it's a bit
fragmented. I wanted to get a few comments in here, but am extremely
busy, so it's the best I can manage ATM....

Mike Beltzner wrote:
<snip/>


>
> (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

ok... more later

>
> (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

Sounds reasonable.


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

I've got some beef here for a few reason that it seems to me we loose a
lot of the customization capacity. If everything moves inside the url
bar, then presumably either the url bar expands in size, or less of the
url becomes visible (IMHO a _very_ bad thing). I personally don't like.

Will there be a capacity to move buttons in/out of the URL bar? I'd
much rather that. It, in addition to a non stateful stop/go buttons
would allow for the user to customize to a more traditional ("classic"
in Theme lingo) layout. This may also be more desirable for corporate
deployment, where they may want to minimize the impact of switching
browsers to ease the learning curb for users who are very set in their
ways and uncomfortable with change.

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

I like this a lot. I'd also like it if it would pre-populate with the
search query if I go to google's website and manually and perform a
search. This keeps my search history in sync between the two, and
allows me to quickly recall a search.

Bonus points if holding down control when pressing enter to perform a
query made it open in a new tab.

>
> (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

Cool

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

Makes sense.

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

I'd rather that be the default, and have the option to put close buttons
on all tabs. I can see the reason for this decision, but I think many
like myself would prefer close buttons on all tabs until there are too
many for it to reasonably work.

>
> (9) Tabs are a fixed width

Again, makes sense.

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

You left this last because it's the bottom of the window? Or because
this is the most sinister ;-)?

I'm going to bark about this one. Mainly because I think it belongs.
The status bar is just about as important as the Title bar. It's a
standard place to look for quick info about the window.

It's also a primary place for extensions which have an icon/notification
or any UI to go. If it's removed, there's going to be a wave of
extensions cluttering the top of the window, and IMHO that degrades user
experience much more for those who use extensions.

Personally I think it's also important to know WHAT is loading, in
addition to how far along it is. I'd rather make the status bar more
useful, such as borrowing IE's idea of showing how many items remain,
and take it a step further by showing the hostname of the item currently
being loaded.

The ultimate win would be if you can customize the toolbar, and put
objects in the status bar. By making toolbar and status bar items
interchangeable (the difference being behavior and default location),
you could then get quite a bit of flexibility, and control your UI more,
this becomes especially critical with extensions. You could move the
RSS icon back to the status bar for example.

The biggest complaint is the inability to hover over a link and know
where it goes. IMHO this is a security issue. Just about everyone I
talk to who asks about ways to protect yourself... the first thing I
recommend is never click a link without looking at where it goes
first... few things to be aware of:

- .exe in the link
- some unexpected domain

If you see something you don't expect, be extra careful, or perhaps
second guess the quality of the website. A link to google shouldn't
contain a .exe download.

I know many were taught that years ago when learning how to use the
internet. I think it's pretty standard practice, most don't even think
about it.

>
> 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.

Agreed. Feel like painting a picture? ;-)
>
> 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?

I don't think it's widely used, but do believe some use it. Perhaps
when opening for the first time in 2.0, have an 'upgrade wizard' which
asks if you want to make some changes as part of the 2.0 UI refresh.
Default it to make the changes.

This way nobody gets hurt.

It could also be a vehicle to show a few quick tips on new features
(such as places).

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

I like the translucent post it note personally, with a matching icon for
the toolbar.

>
> (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?

No comment.

>
> (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?

I mentioned this above. IMHO the status bar should stay.

If you insist on removing it, how about borrowing a page from Paint.NET
and consider transparency as a compromise? On mouse over become opaque.
I guess this would likely mean moving this particular part of the UI
overhaul out to 3.0 though. This is useful in Paint.NET to solve the
problem Adobe Photoshop has of tools getting in the way of the canvas.

>
> (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?

I'd personally like this. Though only if it can be done cross platform
and handle custom cursors on the platform. I personally use a black
"Mac Style" cursor on Windows, because White ticks me off (harder to
track IMHO). I hate when apps have their own cursor that overrides my own.

- R

Message has been deleted

Peter Lairo

unread,
Mar 1, 2006, 11:57:16 AM3/1/06
to
Mike Beltzner wrote on 28.02.2006 12:29:
> (10) The status bar is hidden by default

Another disadvantage of a hidden status bar is for users who don't have
their Firefox window maximized, and they have a maximized window with
black text on white background (e.g., word processor) behind it (likely
a common scenario in offices). Then the only visual separation between
the bottom of a web page and the text document would be the (too) thin
Firefox window border.

This problem would be multiplied if the text you are reading online is
related or even similar/identical to the text in your other document.

| | The brown cow jumps over the red fence. | |
| | The brown cow jumps over the red fence. | |
| | The brown cow jumps over the red fence. | | <- Firefox
| +=========================================+ |
| The brown cow jumps over the red fence. | <- WordPerfect
| The brown cow jumps over the red fence. |
+----------------------------------------------+
| ####### status bar of word processor ####### |
+==============================================+
--
Regards,

Peter Lairo

Lame attempt to get rich: http://www.lairo.com/donations.html

Adam Kowalczyk (Ancestor)

unread,
Mar 1, 2006, 12:05:15 PM3/1/06
to
Benedikt Kantus wrote:
> Right. In fact, I don't care much about the title attribute, nor do I
> think many others do. But i _do_ care about where a links takes me. So
> we should under all circumstances show the URL.
> But, as I said, image you hover over a link and a two-line-hovering
> popup appears above the page. That's too much of the webpage not being seen.

If you're focusing on a link and reading the tooltip then you're not
reading the page at the same time. What situation do you have in mind?

I think that hiding the Status Bar by default is a good idea as long as
a good alternative for displaying the URL is found. Everyone can easily
find out how the tooltip solution feels as Opera uses it. Here are my
thoughts.

Firstly, the important issue is that you have to wait a while for the
tooltip to appear. This time can't be reduced, because the tooltip would
pop-up accidentally while moving the mouse around. This hiatus is long
enough to be noticeable and a little annoying.
Secondly, although I don't know how common it is among average users to
check the address before following a link, I suppose that some of them
acquire this good habit thanks to the Status Bar. I'm on the fence
whether the tooltip solution serves this educational purpose better or
worse. It depends how long do users usually point the links before clicking.

I am quite positive that the tooltip solution isn't as quick as a peak
on Status Bar and that the advanced users who usually check the URL may
prefer the latter. It's not a big problem as they're probably enough
savvy to turn the Status Bar back on. Therefore, I think that even
considering these drawbacks we could hide Status Bar by default.
However, the big challenge is to find a solution that would be just as
good as the Status Bar for the URL-philes.

BTW, should showing the Status Bar turn the tooltips off? I'd say yes.

Cheers,
Adam

Adam Kowalczyk (Ancestor)

unread,
Mar 1, 2006, 12:36:35 PM3/1/06
to
Brett Wilson wrote:
> A warning: making the contents of the personal toolbar folder a generic
> query will be REALLY slow.

In such case, should this be disabled?

Cheers,
Adam

Justin Kerk

unread,
Mar 1, 2006, 12:39:04 PM3/1/06
to
Mike Beltzner <belt...@mozilla.com> wrote in
news:RpydnZlccrK...@mozilla.org:

>
> (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

This is good.

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

Not sure about this. It's important IMO that the stop button be as big
and easy to hit as possible, to borrow a phrase from someone else here
it's the "panic button" when the browser is doing something you don't
like, you want it to be big and obvious. Of course, you can hit the
Escape key but many people don't know that.

> (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

This sounds neat, but keep in mind that a) I think most people have
learned to basically ignore the throbber so they might not notice, but
you don't want to make it intrusive to draw their attention, and b)
progress bars are generally full of lies so it may not be too useful
without a lot of work put into making it accurate.

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

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

This seems reasonable since the home page is a "personal" page like the
others (although I don't personally use the Home button), although it
would be good to make it removable for the crazy power users who have
every pixel of the PBT filled with favicon links.

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

This is less important if the tabs are a fixed width but I guess it does
save some real estate for tab names.

> (9) Tabs are a fixed width

I like this for the "close button stays in the same place" reason you
elaborate later, although it'll still take some convincing for me to move
from close-button-at-right.

> (10) The status bar is hidden by default

I hate this. :)

Presumably the View->Status Bar menu option would stay so it would be
easy and obvious to turn it back on, but I think this is so much an
integral part of using the Web these days that it's not a good idea to
turn it off. If people don't know about it, the solution is to educate
them, not take it away.

It's not just a matter of "security" like spoofing people's banks, but
just in general having control over where you go (we're all about giving
the user control, right?). People know what URLs are, it's important to
know what URL actually corresponds to that hyperlink saying "click here"
or "check out this new website" without actually having to go there.

I'm thinking especially about Web forums where it's important to know if
someone is trying to trick you with a goatse.cx link or a log-out link,
or if they're just giving you a joke URL like www.gotohell.com that
you're not supposed to really click on.

Granted you could think up some other scheme like a tooltip for
indicating the URL to the user, but the status bar is already there and
has been since the dawn of time, people are used to it, people who are
obsessive about screen real estate can already turn it off, I don't see
the need for replacing it with something new and different just because
(although adding the tooltip too would be nice for the screen real-estate
folks).

As someone else suggested though, displaying more information in the
status bar to make it justify its existence more is certainly worth
pursuing, I remember Opera used to show all kinds of information there
about how many images it was downloading, etc. (although it was a bit
distracting). Maybe a memory meter divided into memory cache etc. for the
leak whiners :)

> (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?

I basically never use the Home button because my usual modus operandi now
is to leave Firefox open all the time with a slew of "home" tabs
mantained via SessionSaver, and since Fx2 will have built-in session
saving and more integrated/discoverable tab browsing, this will probably
become more common. There are a lot of people who are used to the Home
idea from Netscape and IE though.

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

On the one hand, "letting users discover it" is code for "no one will
ever see this unless someone tells them about it", but on the other hand,
tagging strikes me as the kind of thing that only power users and
novelty-seekers are going to have the time and interest to make use of
anyway.

> (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?

This sounds like a good idea, I would suggest a [v] button on the far
left or right that drops down a list of the folders, it doesn't take up
much space but makes it a lot more discoverable.

I also like the idea someone else mentioned of having text in the PBT
saying "Drag links here to add your own buttons" or some such to make the
whole thing more discoverable, but I would have it any time the bar is
empty, not just on first start.

> (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?

This is a bad idea because then you're back to URL spoofing or hiding
(intentional or not), just with title instead of onmouseover (either that
or have a new obscure option for disabling title like there is now for
the status bar).

> (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?

I can see this being useful but it seems unlikely that people will be
able to figure out what it means given that any icon small enough for the
purpose will have to be fairly abstract. My suggestion would be to keep
the status bar and indicate that information there using words, so for
example have the status bar show "http://www.google.com/ (new window)" or
even have "new window" inside another partition like the security
indicator and the progress bar, with nothing displayed for regular links.
(You'd also have to keep track of whether the user's options would make
it a new window or a new tab.)

-Justin

--
__ ____ ___ __ __
| | | \| | | Cast in the name of God...ye not guilty!
| | __| | | _| ICQ: 76824935
__| |__ | | | /_ Dopefis...@MailandNews.com is spambait
| | | | | | | dopefish justin at gmail dot com
|______________/___|__| http://interbutt.com/

Mike Connor

unread,
Mar 1, 2006, 11:08:43 AM3/1/06
to dev-apps...@lists.mozilla.org

On 28-Feb-06, at 8:00 PM, Adam Kowalczyk (Ancestor) wrote:

> Pam Greene wrote:
>> > (9) Tabs are a fixed width 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.
>

> +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.

The problem with non-fixed width tabs is that you can't keep the
mouse in one place and quickly close tabs, because they're getting
wider as you close tabs. With the change to closebutton on tab,
instead of closebutton on tabstrip, this is a problem for a lot of
users.

I'm trying to get the implementation done this week, and I can easily
play with the values to see if a small amount of flex pays off, but
I'm not hopeful.

-- Mike


Mike Connor

unread,
Mar 1, 2006, 11:12:33 AM3/1/06
to dev-apps...@lists.mozilla.org
On 28-Feb-06, at 3:10 PM, Benjamin Smedberg wrote:

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

> 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.

Apps with status bars always seem to have resizers in the apps I use
on Windows and GNOME, at least if they're native widgets. It isn't
strictly necessary, but does tend to differentiate "this window can
be resized" fairly well.

-- Mike


Mike Connor

unread,
Mar 1, 2006, 12:42:35 PM3/1/06
to dev-apps...@lists.mozilla.org
I'll be honest and say that my immediate gut reaction (repeated every
time I've looked at this in the last 24 hours) is that this seems
like overthinking and change for change's sake, but I believe the
exercise is at least worth it as an evaluation, so I'll play along,
because I'm just that kind of guy!

> (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

I'm pretty concerned with turning a 32x32 button (at least on Mac)
into a 16px button inside of a textbox. This also implies that the
URL is what is being reloaded, which may not really be "the page" at
all.

This also seems to massively overload the URL bar:

[ [a] [b[ http://foo.com [c] [d] [e] [f] ]

a) refresh
b) favicon
c) lock icon
d) rss icon
e) go button
f) history dropdown

Visual connection I'll buy, but five icons inside of a textbox and a
dropmarker, that's killing me. I have some ideas in my head around
visual connection without sticking things in the textbox (i.e. the go
button and the history dropmarker could be combined in a similar
fashion as what we're discussing with the searchbox).

> (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?

I'd just as soon remove it, and see how that works out. As an aside,
if it goes on the PTB, we're looking at making it smaller than on the
main toolbar, and that's just another implementation detail we don't
need to solve.

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

Off the top of my head, we could show the post-it note behind the
favicon and make it look like the favicon is on the sticky note,
instead of a 6x6 blob. This might be slightly inaccurate to the
metaphor, but should work visually. Then, to tie things neatly
together, we could co-opt clicking on the favicon (which currently
selects the url bar contents) for access to the tagging UI. It's
light, subtle, and doesn't add anything to the UI in terms of clutter
or new ideas to understand.

> (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?

I doubt this would get changed frequently enough to be useful for
toplevel chrome. Random thought of the minute: this might turn out
to be annoying, but we could make the most commonly-accessed live
bookmarks, bookmarks, and/or folders be the default toolbar contents
for users, so their toolbar always includes the things they access
the most. A lot of users I've observed tend to bookmark something,
and leave it in the root, no matter how often they access it, because
moving things around to be more efficient doesn't become apparent to
them. If a user bookmarks their banking site, ESPN, and CNN into the
root, and they keep going back to those three sites, putting them up
front without having to be told is a big win.

Would need a fair bit of tuning, I suspect, but could be a killer
feature.

> (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?

I think we have to at a minimum. We've been training users for so
long to check the statusbar, I'm not sure how we retrain them to
hover long enough to get the tooltip.

> (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?

Big win there. Low on my radar was fixing statusbar text to indicate
this, a la Safari, this works too.

-- Mike

Mike Connor

unread,
Mar 1, 2006, 12:46:46 PM3/1/06
to dev-apps...@lists.mozilla.org
Mike Beltzner wrote:
> Did we, uh, forget to land that on branch?
It would appear that, yes, in fact, we did fail there. On my list of
things to address by week's end.

- Mike

Pam Greene

unread,
Mar 1, 2006, 1:06:12 PM3/1/06
to dev-apps...@lists.mozilla.org
On 3/1/06, Mike Beltzner <belt...@mozilla.com> wrote:
Having the closebuttons on non-focused tabs causes one of two problems:
either you've got a high potential of accidental data loss, as selecting
a tab makes it extremely possible to accidentally hit the close button,

Is that "high potential" from user testing, or prediction?  If tabs are fixed-width, presumably they'll be large enough to show the icon and a reasonable portion of the title, as well as a hypothetical close button.  If they're variable-width, then at some small width we can stop showing the buttons (or choose a miniumum width that allows them reasonably).  If the button doesn't occupy too much of the tab, I would think the risk of accidentally hitting it would be small.  My own, admittedly anecdotal, experience supports that.  Do we have any better data?

- Pam

Ben Goodger

unread,
Mar 1, 2006, 1:07:08 PM3/1/06
to Mike Beltzner, James Graham, Joe Hughes
Mike Beltzner wrote:
> ...................................
> | 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.

This is still spoofable. Someone can create a div with the right
transparency settings, copy our icon from our chrome jar files, and make
a web page that does this still.

Joe's idea of placing below the location bar seems one of the
non-spoofable options... do you think it'd be annoying underneath the
current URL, as a tooltip like entity?

-Ben

Ben Goodger

unread,
Mar 1, 2006, 1:15:10 PM3/1/06
to
Peter Lairo wrote:
>> (7) The Home button (&) moves to the personal bookmark toolbar
>
> This caused a lot of debate in the Mozilla Suite days. One could argue
> that the Home button is "personal", but it just seems less than optimal
> to have a fixed UI element in the "personal" tool bar.

Those who appreciate this fine point will also appreciate that Firefox's
entire toolbar stack is "personal" (I have my bookmarks bar on the same
row as my menubar) - and that the Bookmarks Toolbar is now populated by
the Bookmarks Toolbar Folder, not the Personal Toolbar Folder ;-)

-Ben

Adam Kowalczyk (Ancestor)

unread,
Mar 1, 2006, 1:31:54 PM3/1/06
to
Mike Beltzner wrote:
> Thanks for this analysis, Adam. I'm not sure that "most" of our users
> browse with > 5 tabs, although I'm sure that the majority of our most
> passionate users do.

I didn't mean that most users browse with > 5 tabs, I'm pretty sure they
don't. I meant that it is more common for users to browse with the
medium number of tabs than with the large number.

>What was your criteria for "tabs are too small", by
> the way?

Maybe I'd better describe my criteria for the acceptable size of the
tabs. User has to be able to easily identify tabs i.e. there must be a
sufficient portion of the title visible. Secondly, the size cannot make
it significantly harder to quickly switch tabs (in other words point
them with mouse :) For me the limit is around 100px, that is 2/5 of the
standard width but that's totally debatable.


Mike Connor wrote:
> The problem with non-fixed width tabs is that you can't keep the mouse
> in one place and quickly close tabs, because they're getting wider as
> you close tabs. With the change to closebutton on tab, instead of
> closebutton on tabstrip, this is a problem for a lot of users.

Yep, I know, there seems to be a quite strong lobby. :) It's a question
of wins and losses, though. I think that the losses are greater as you
switch tabs and want to have an overview of them all the time. Mass
closing is a one-time job.

There were some other solutions discussed that, if introduced, could
compensate this disadvantage. One is a context-menu option for something
like "Close all tabs to the right". The other is allowing to select
multiple tabs with Ctrl.

BTW, I really wish there was a way to advertise middle-clicking as it is
by far the quickest way and it doesn't share any of the disadvantages of
other methods. I don't know how it could be made more discoverable, though.

> I'm trying to get the implementation done this week, and I can easily
> play with the values to see if a small amount of flex pays off, but I'm
> not hopeful.

At the least, could you implement it so that it could be modified with
min-width via userChrome.css?

There'll be a lot of time to get feedback from the testing community and
I'm sure we'll find the best solution possible.

Cheers,
Adam

Brett Wilson

unread,
Mar 1, 2006, 1:58:18 PM3/1/06
to
> (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.

I used to be slightly against this. But I was just using a trunk build
and switched tabs without thinking about it. But I missed and closed the
tab. %#@($^%@#$!!! I can see if I used this build for a while I would
probably go insane, so I think this is exactly the right approach.

Brett

scratch

unread,
Mar 1, 2006, 2:04:50 PM3/1/06
to
Pam Greene wrote:
>
> Is that "high potential" from user testing, or prediction? If tabs are
> fixed-width, presumably they'll be large enough to show the icon and a
> reasonable portion of the title, as well as a hypothetical close button. If
> they're variable-width, then at some small width we can stop showing the
> buttons (or choose a miniumum width that allows them reasonably). If the
> button doesn't occupy too much of the tab, I would think the risk of
> accidentally hitting it would be small. My own, admittedly anecdotal,
> experience supports that. Do we have any better data?

if we hide the close button on inactive tabs that are too small... then
tabs are going to change size and shift around when i change which tab
is selected? that sounds really bad.

-scratch

scratch

unread,
Mar 1, 2006, 2:11:06 PM3/1/06
to

well, we'd need to add a space for it to show up in, in that case. how
is this any better than simply leaving the status bar, which is the
place users are already accustomed to finding this information?

-scratch

scratch

unread,
Mar 1, 2006, 2:16:33 PM3/1/06
to
pascal chevrel wrote:
>
> - 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

the homepage is just a glorified personal bookmark.

-scratch

scratch

unread,
Mar 1, 2006, 2:20:31 PM3/1/06
to
Benjamin Smedberg wrote:
> Mike Beltzner wrote:
>
>> (10) The status bar is hidden by default, and the page resizer is in the
>> bottom right corner underneath the scrollbar.
>
> 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.

it's there on windows when you have a status bar. ...oh wait.

-scratch

scratch

unread,
Mar 1, 2006, 2:22:14 PM3/1/06
to
Thomas Stache wrote:
> Benjamin Smedberg schrieb:

>> Mike Beltzner wrote:
>>
>>> (10) The status bar is hidden by default, and the page resizer is in the
>>> bottom right corner underneath the scrollbar.
>> Why do we have a resizer at all on win
>
> I'd say because every non-maximized window of a native Windows
> application has it, e.g. Windows Explorer, no?

only non-maximized windows that have status bars have it.

-scratch

Eva Poen

unread,
Mar 1, 2006, 2:51:09 PM3/1/06
to dev-apps...@lists.mozilla.org
I would like to second what Robert Accettura said:

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

> I'd rather that be the default, and have the option to put close buttons
> on all tabs.  I can see the reason for this decision, but I think many
> like myself would prefer close buttons on all tabs until there are too
> many for it to reasonably work.

I agree. Plus, I vote for an option "Close tab on double click" (laptops don't have middle click ability).

Eva

[Apologies if this post does not appear where it's supposed to - I'm using the mailing list]

Peter Lairo

unread,
Mar 1, 2006, 2:58:01 PM3/1/06
to
Mike Connor wrote on 01.03.2006 18:42:
>> (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. <snip>

>
> I doubt this would get changed frequently enough to be useful for
> toplevel chrome. Random thought of the minute: this might turn out to
> be annoying, but we could make the most commonly-accessed live
> bookmarks, bookmarks, and/or folders be the default toolbar contents for
> users, so their toolbar always includes the things they access the
> most. A lot of users I've observed tend to bookmark something, and
> leave it in the root, no matter how often they access it, because moving
> things around to be more efficient doesn't become apparent to them. If
> a user bookmarks their banking site, ESPN, and CNN into the root, and
> they keep going back to those three sites, putting them up front without
> having to be told is a big win.

That's an excellent idea! Auto-populating the "Personal" Tool Bar (PTB)
based on usage would help novice users make use of of the PTB (which
they currently don't do, at all).

However, there should (must) be a way to "lock" bookmarks that the user
placed there manually (perhaps: manually placed bookmarks are always
"locked", and auto-populated bookmarks are placed to the right of the
"locked" bookmarks). This would make the auto-population of the Personal
Tool Bar stay useful to the more experienced users (who want to maintain
(some) control of the PTB (and still benefit from the auto-populated
bookmarks).

(BM-L = Locked bookmark, BM-A = Auto-populated bookmark)

PTB: [BM-L BM-L BM-L BM-L BM-A BM-A BM-A BM-A BM-A ]
^
A right-click menu-item to turn a BM-A into a BM-L (and vise-versa)
would be useful (e.g., to "lock" BM-As that might otherwise disappear
without notice).

</dreaming>

--
Regards,

Peter Lairo

Lame attempt to get rich: http://www.lairo.com/donations.html

Mike Beltzner

unread,
Mar 1, 2006, 3:10:33 PM3/1/06
to dev-apps...@lists.mozilla.org
On 3/1/06, Eva Poen <eva....@gmail.com> wrote:
> [Apologies if this post does not appear where it's supposed to - I'm using
> the mailing list]

No worries - but I'd appreciate it if people tacked on their replies,
even to this message, in the original thread so that we don't get
uber-fragmented. Thanks!

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

Ben Goodger

unread,
Mar 1, 2006, 3:34:06 PM3/1/06
to Pam Greene
Pam Greene wrote:
> If the button doesn't occupy too much of the tab, I would think the risk
> of accidentally hitting it would be small. My own, admittedly
> anecdotal, experience supports that. Do we have any better data?

Several of us have accidentally "lost" tabs due to the background close
buttons (Darin and myself at least, I think Mike Connor reported this
too) that it made us think that this experiment was useful, but it was a
little dangerous. Windows has the same problem with its close buttons,
except desktop apps usually get the chance to ask the user if they
really want to quit without saving - a grace which we don't currently
afford web apps.

I don't want to get too much into monkeying with close box size on bg
tabs, closing a background tab is an infrequent enough action that the
other methods of doing it (middle/accel+click) should suffice for now.

-Ben

Adam Kowalczyk (Ancestor)

unread,
Mar 1, 2006, 5:02:55 PM3/1/06
to
Mike Beltzner wrote:

> | 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|

Note, that you cannot right-click on disabled back/forward buttons. If
the Home, Reload and Stop buttons are moved there will hardly be any
space on the Navigation Toolbar where you could right-click to
customize. I guess this it would be necessary to reopen 170501 -
"Context menu doesn't appear when right clicking on disabled forward or
back" which is WONTFIXed right now.
https://bugzilla.mozilla.org/show_bug.cgi?id=170501

Cheers,
Adam

Pam Greene

unread,
Mar 1, 2006, 5:11:40 PM3/1/06
to dev-apps...@lists.mozilla.org


On 3/1/06, scratch <scr...@the-pentagon.com > wrote:
Pam Greene wrote:
> If
> they're variable-width, then at some small width we can stop showing the
> buttons (or choose a miniumum width that allows them reasonably).

if we hide the close button on inactive tabs that are too small... then
tabs are going to change size and shift around when i change which tab
is selected?  that sounds really bad.

Good point.  That suggests keeping a larger minimum width (if the width changes at all).

- Pam

Brian Rakowski

unread,
Mar 1, 2006, 5:20:31 PM3/1/06
to
> 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.

I think these changes are great, and essential for attracting new users to
Firefox. I like the focus on simplification.

> (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?

I think the home button belongs on the personal toolbar--it may help users
realize that this is a place for bookmarks. I also like mconnor's idea of
helping users make better use of the PBT by automatically adding things. My
sense is this is something that would be enabled by the Places work but
probably beyond the scope of what we can do for this release.

There is also an opportunity to allow users to create richer bookmarks.
We've seen that the "custom toolbar" buttons of the Google Toolbar for IE
have been pretty popular with end users. These "buttons" are little more
than PBT livemarks with the capability of displaying a different favicon
depending on contents of their RSS feed. Adding this capability to livemarks
and making it easier to create these bookmarks could be very cool.

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

I don't understand the argument against state-changing buttons. Is there any
data to back this up? My only data point is that users have responded
extremely well to the version of this feature we have in the Google Toolbar
for IE. People like the fact that it's very lightweight to add a bookmark.
Combined with tagging and (eventually) full-text search over bookmarks and
history, this would be a powerful way to re-access information.
On tagging, I don't see the need to display the tags a user has added to the
current page in the chrome. From the discussions I've had, tags are seen as
a way to organize personal information. People use there tags to access
information in a similar way to using folders. I'd suggest leaving the
social tagging to a del.icio.us extension but keeping the personal
organization tagging as an enhancement to folders.

> (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?

I'm very nervous about this. I like the idea of hiding the status bar but I
think we must provide some way for users to preview the URL of the page they
are about to visit. I'd be up for hiding the status bar and experimenting
with some other URL placement but my intuition is that we can't discard the
URL preview outright.

> (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?

Sweet lord, I've been trying to get someone to implement this for several
months. The Content Alert extension is the closest thing around but the UI
isn't quite right. I'd like to see the cursor change to indicate links that
will open in a new window/tab, and links that open an external application
(mailto, acrobat, etc).


Daniel Schierbeck

unread,
Mar 1, 2006, 5:45:50 PM3/1/06
to Mike Beltzner
This is very interesting!

I'd like if the location bar would be used for status indication icons
only, such as "the connection is encrypted", "popup windows have been
blocked" and "this site sets cookies", and not "click here to save a
live bookmark", "click here to refresh", etc. I think there should be a
designated place for such action-oriented icons, but it should be
separated from the status indication icons.


Cheers,
Daniel

Simon Bünzli

unread,
Mar 1, 2006, 6:08:17 PM3/1/06
to
Mike Beltzner schrieb am 28.02.06 12:29:

> (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

The icons currently inside the address bar are rather status indicators
(secure site, feed available, icon for better recognizability) than
function providers. Sure the first two are clickable and the third one
draggable, but except from the hand cursor over the icon and the subtle
tooltip of the feed icon, there's no way of telling that they are
clickable. I'd rather move the feed icon outside of the address bar than
more "pseudo-buttons" inside 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

If I understand it correctly, the History menu will display only the
current tab's history (while highlighting the current page). Why not
completely remove this menu and unify it with the Back/Forward buttons.
Users might get confused about a menu with changing content - and the
Back/Forward buttons should already be closely associated with the
current tab.

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

As for the buttons moving, see above. As for the buttons merging: Go and
Stop are not completely orthogonal (neither are the mentioned Stop and
Reload, nor IE7's Go and Reload). Might users not be confused if there
suddenly is no Go button (since they could mean that they can't always
go where they want to)? If you can't describe in one short sentence when
one or the other option is displayed, this is too complicated IMHO (and
will make users feel limitated in their actions rather than liberated
from cruft).

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

Cool. And while we're at it: what about auto-discovering of search
engines offered by the current page and offering to install it (making
it even easier to get the engine of your preferred site installed - well
supposing that it's about as easy to uninstall it again ;-)).

> (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

Nice idea!

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

As already mentioned: under Windows there is no window resizer if there
is no status bar.

> (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?

+1 for keeping the "Home" button (even if it goes to the PBT), since
it's also a fast way of getting rid of the current page without closing
the tab/window. And users might feel attached to their one and only
starting point (even if it is Google).

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

The feed icon is doing a marvellous job at that (yellow might just be
too close to white).

> (C) [...] 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?

+1 for a context-menu item plus some non-intrusive addition to the
currently selected folder for making this somewhat more discoverable
(i.e. adding " (Toolbar Folder)" to the name or display it in italics).

> (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?

I'd vote for not showing the URL at all. As Jesse pointed out several
times, the link's target URL doesn't have to be the URL loaded when the
link is clicked, at all - thus only giving a false sense of security on
a Really Evil Site(TM). As for those users used to peeking at the
presumed target, they should be able to do View -> Status Bar. Further
on, the unexpected tooltip might rather confuse (and irritate) users
than help them (because why should they suddenly care about the link
target if they never did so before?).

> (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?

I'd rather vote for not opening the links in a new window in the first
place, leaving the choice completely to the user. Should that be out of
the question (since in some places it really does make sense - e.g. for
PDF documents), I'm not sure we can do much to communicate this fact to
the user - or better: I'm wondering about how you plan to achieve this.

Cheers,
Simon

Kevin Hamilton

unread,
Mar 1, 2006, 6:43:46 PM3/1/06
to
--Regarding the Go Button, and the search box--
It is my understanding that many users need the reassurance of a button
associated with a text-field to take action on that text field. Isn't there
a discongruence in the UI by providing that for the url, but not for the
search-box? Isn't that likely to confuse users? I'd say either there
should be a go button for both, or for neither.

--An idea regarding the search box + thoughts on the bookmark search--
I don't know if you planned to address the discoverability of the multiple
search-plugins, but if so, have a look at copernic desktop search for
windows. I really like what they do with their deskbar (
http://download3.copernic.com/images/mediakit/screenshots/desktop-search/16/en/deskbar.jpg )
. It pops up the list of search options when you focus it, and
remembers+highlights the last-used one. By doing this, couldn't the
bookmarks/places/whatever search be integrated into the same search box? We
already have a place in the UI set aside for search, it seems appropriate to
add the bookmarks/places search to it.

--Thoughts on the Home button--
I rather like the thought of the home button on the PBT, but I think it
should become a fullclass citizen of the PBT, then. Meaning that changing
from normal to small toolbar icons shouldn't affect it, choosing icons only
vs icons and text should not affect it, and by default it should have the
favicon matching the old home button, and the text "Home" or something
similar. The user should be able to move the "Home" Personal Bookmark
around, duplicate it, and/or delete it. My only concern is that if it is
deleted and then the user desires to re-add it later, how would the home
icon get associated with it? Is it possible to provide a "change icon"
button in the bookmarks properties sheet? That would be handy.

--An idea regarding showing where a link will take you (assuming no
statusbar)--
I'm not yet decided if I would find this overly annoying, but I thought
I'd mention the idea anyways...What about a popup ABOVE the tabbar. This
would take the notification outside the webpage's purview, which prevents
tricksters from, e.g. using javascript to "fake" the information about where
the link will go. Also, by placing it above the tabbar, it would be
possible to show an arrow pointing from the popup to where the link is going
to load. (e.g. point at the current tab for a normal link, point at the end
of the tabs for a link which will open in a new tab)

--Regarding fixed-width tabs--
> one reason why we're proposing fixed-tab widths is that it
> means that if a user selects a tab, they can hover over the (x) button
> and click-click-click-click to close a series of tabs to the right since
> the active close button will always end up in the same location
This explanation makes a lof of sense, but how about this idea: While the
mouse is in the vicinity of the tabbar, the tabs stay the same size. So
with 7 tabs open, you could click-click-click and close three tabs, which
would free up space at the end. Then, when you move away from the tabbar,
(after a short delay) the tabs would grow to fill the newly available space.
You would still have a minimum tab-size ( so still need to deal with
overflow when number of tabs gets very high ), and still have a maximum tab
size as it is now. But there would be flexibility in between to make more
productive use of the available space.

--Regarding buttons inside the URLbar--
I think it is intriguing that you are considering changing the white-box's
meaning from "this is a text-box, you type in here" to "this is a collection
of associated things. See? They are all in the same white box.". Is there
really no other way you could show that certain icons, buttons, and text are
grouped together?

--Regarding the close-tab button--
Would it be feasible to have a "close the current tab" icon available in
the "Customize Toolbar" dialog, that could be dragged to the location where
the close-tab button currently is, or would we need an extension to provide
this functionality?

I would assume you've thought about this, but just in case...It is my
experience that some (many) novice users over-use "double-click" where a
single click is appropriate. If there isn't a close button visible on the
background tabs until you click on them, watch out for dataloss from a user
double-clicking (first click brings tab to focus, second click hits the
close button that magically appeared there)

Brett Wilson

unread,
Mar 1, 2006, 8:50:38 PM3/1/06
to
Peter Lairo wrote:
> However, there should (must) be a way to "lock" bookmarks that the
> user placed there manually

The Mac OS X dock might be a good starting point for thinking about this
kind of thing.

I was also thinking a lot about auto populating the empty right hand
side of the toolbar based on where we think you're going to go next. If
you had no toolbar bookmarks, it would use the whole toolbar, and if you
had a lot it would only use a bit or none. But I think this is the kind
of thing that has to be done really well for it to be at all tolerable.
People get positional memory and would be really confused and annoyed if
we move something that they are used to.

> </dreaming>

No kidding. This is so not on the roadmap. Probably we should do the
gray text thing for FF2, which is easy and should give us a lot of
mileage. Somebody should volunteer to do autopopulation for FF3!

Brett

Gavin Sharp

unread,
Mar 1, 2006, 9:44:31 PM3/1/06
to Simon Bünzli, dev-apps...@lists.mozilla.org
Simon Bünzli wrote:
|| (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.
|
| Cool. And while we're at it: what about auto-discovering of search
| engines offered by the current page and offering to install it (making
| it even easier to get the engine of your preferred site installed - well
| supposing that it's about as easy to uninstall it again ;-)).

See
http://wiki.mozilla.org/Search_Service:User_Interface_Design#Automatic_Detection
for one of the planned features of the new search service. Those
proposals need fleshing out, but this type of auto-detection is planned.

Nunya Bidness

unread,
Mar 1, 2006, 11:16:17 PM3/1/06
to
Mike Beltzner wrote:
> Having a closebutton on the active tab ... prevents accidental dataloss.

Say what, now?

--
R

Nunya Bidness

unread,
Mar 1, 2006, 11:29:36 PM3/1/06
to
Mike Beltzner wrote:
> 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
>

They want to see if they need to disable NoScript (which someone already
mentioned, and unverified by me, has been downloaded FIVE MILLION times)
because it's a JavaScript link and isn't working. Granted, advanced
user scenario.

<snip>

> 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.

You're kidding right? More distracting than a giant, wordy, image-laden
tooltip? The leader in the "least distracting" department seems
(obviously to me) to be the status bar.

Mike Beltzner

unread,
Mar 2, 2006, 3:55:28 AM3/2/06
to
Ben Goodger wrote:
> Mike Beltzner wrote:
>> ...................................
>> | 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.
>
> This is still spoofable. Someone can create a div with the right

Mm. Good point. Proposal withdrawn!

> Joe's idea of placing below the location bar seems one of the
> non-spoofable options... do you think it'd be annoying underneath the
> current URL, as a tooltip like entity?

Annoying and confusing, actually. :) Users will expect a tooltip to be
directly related to the part of the UI that it's hovering on.

If we feel that it's essential that hrefs are previewed onHover in the
default chrome, then we should probably keep the status bar. It's the
best solution we've got for that purpose in terms of not being able to
be spoofed and not being in the user's direct line of sight.

However, I still think that initial premise -- that href needs to be
previewed in the default chrome -- is flawed. :) But we've all
registered our thoughts here, so let's hope that someone comes along
with compelling arguments for one way vs. another ...

cheers,
mike

--

Mike Beltzner

unread,
Mar 2, 2006, 4:02:05 AM3/2/06
to
Peter Lairo wrote:
> context-menu (which are the vast majority) this would make it cumbersome
> to close (several) background tabs (bring background tab to foreground,

I'm not worried about this, since we'd be maintaining status quo on
background tab closing, which, to be honest, feels very much like the
sort of thing that's better handled by accelerators and middle click.

Thomas Stache

unread,
Mar 2, 2006, 4:08:37 AM3/2/06
to
Peter Lairo schrieb:

> However, there should (must) be a way to "lock" bookmarks that the user
> placed there manually (perhaps: manually placed bookmarks are always
> "locked", and auto-populated bookmarks are placed to the right of the
> "locked" bookmarks).

How should Firefox know how many "BM-A"s should be added?
- how would it react to different window sizes (e.g. when switching
between maximized and normal, or between the laptop screen and an
external LCD)
- would the toolbar use a overflow chevron,
- how many items would flow into the chevron?

It's the tiny details that matter, and this seems just too tricky given
the Ff2a1 progress...

Thomas

Mike Beltzner

unread,
Mar 2, 2006, 4:28:16 AM3/2/06
to
Robert Accettura wrote:
> I've got some beef here for a few reason that it seems to me we loose a
> lot of the customization capacity. If everything moves inside the url
> bar, then presumably either the url bar expands in size, or less of the
> url becomes visible (IMHO a _very_ bad thing). I personally don't like.

They needn't be *inside* the URL bar, I suppose, as long as they can be
tightly associated with them. You're raising very good points here. Ben
and I talked about this today, as well as systems that would let us drag
buttons into/out of the URL bar. The net of those discussions was that
we could enable this, but it might require far more work than we have
time for. The options as we saw them, in order of increasing amounts of
work required:

- just make it possible to place normal sized toolbar buttons right
up against the URL bar

- allow users to turn the buttons-in-URL-bars on/off through the
customize menu, and package normal toolbar buttons that can be
optionally dragged onto the toolbar as well

- change the toolbar button system so that each button is packaged with
up to 3 sizes: standard toolbar, bookmark toolbar, and in-url bar.
If a size is packaged for that button, it can be dragged into that
location.

No value judgements were made, although the last one seems like too much
work to fit within our schedule at this point in time, especially since
the benefit isn't well known.

> I like this a lot. I'd also like it if it would pre-populate with the
> search query if I go to google's website and manually and perform a
> search. This keeps my search history in sync between the two, and
> allows me to quickly recall a search.

Hot. Great idea. Gavin, would this be tricky to do given our planned
search infrastructure?

> Bonus points if holding down control when pressing enter to perform a
> query made it open in a new tab.

Well, whatever shortcut we use in the URL bar, anyway, yes. (Right now
that's alt-enter due to historic shortcut use of the accel-enter, aiui.
Personally I think that's a bullshit reason, and since we use
accel-click in the UI, we should use accel-click everywhere ...)

> I'd rather that be the default, and have the option to put close buttons
> on all tabs. I can see the reason for this decision, but I think many
> like myself would prefer close buttons on all tabs until there are too
> many for it to reasonably work.

I'll leave this to Ben, as he's very anti-pref these days. The pref will
be in there for alpha/beta so we can play, but I'd hope we can come up
with a best answer and just lock it to that by the time of release.

> You left this last because it's the bottom of the window? Or because
> this is the most sinister ;-)?

Bottom of the window, but it's turned out to be both reasons!

> It's also a primary place for extensions which have an icon/notification
> or any UI to go. If it's removed, there's going to be a wave of
> extensions cluttering the top of the window, and IMHO that degrades user
> experience much more for those who use extensions.

If we hid this by default, it would have to be engineered to show as
soon as extensions which used that space were installed. That's an
optimization based on an explicit user request to see that UI.

> addition to how far along it is. I'd rather make the status bar more
> useful, such as borrowing IE's idea of showing how many items remain,
> and take it a step further by showing the hostname of the item currently
> being loaded.

I understand why this information is useful, if the user understands
that a web page is made up of many images which might be located in 1..n
locations, etc. I'm just not convinced that the information is always
useful enough to show all the time.

> The biggest complaint is the inability to hover over a link and know
> where it goes. IMHO this is a security issue. Just about everyone I

This has been discussed elsewhere in the thread. The concerns about
removing the status bar seem to net out to:

- not being able to preview the href
- not being able to see status information about the files downloading
- not having a border at the bottom of the screen

My feeling is that the first two issues are not actually relevant to the
general browsing case, and really only apply to users who have an
interest in seeing that information, and those users can easily switch
the status bar on. The third issue is an OS windowing issue, and in our
efforts to look and feel native, we should probably try to stick with
what the OS does.

Now, Ben brought up an interesting point today, which was that the churn
of text messages when a page starts loading gives the user a feeling
that "something is happening", and without the status bar, his browser
felt slower.

In the interests of stopping this circular debate, I'd like for everyone
to try browsing without the status bar, maybe for a day or two. Long
enough that you forget that I've asked you to turn it off, and long
enough to not be paying attention to it. Heck, maybe do it over the
weekend. Then let's talk about our experience with it off. There's gonna
be a lot of skew here, but I think it might still be more informative.

> Agreed. Feel like painting a picture? ;-)

Yeah, I will soon, but I'd like to keep discussing things at a rough
conceptual level before running the risk of getting into graphical nits ;)

Tero Tamminen

unread,
Mar 2, 2006, 4:39:43 AM3/2/06
to
Ben Goodger wrote:
> This is still spoofable. Someone can create a div with the right
> transparency settings, copy our icon from our chrome jar files, and make
> a web page that does this still.
>
If your box is always the topmost one, how can someone create a div to
do this? Your box would always go above that div (and also show that
someone is trying to spoof the real location of that link, which kind of
brings extra security). Of course this has a problem that someone might
think it is a bug in the software to show two boxes.

Mike Beltzner

unread,
Mar 2, 2006, 4:39:56 AM3/2/06
to Mike Connor, dev-apps...@lists.mozilla.org
Mike Connor wrote:
> a 16px button inside of a textbox. This also implies that the URL is
> what is being reloaded, which may not really be "the page" at all.

I'm not sure that I understand what you're saying here. The reload
button reloads the address specified in the URL bar, doesn't it? If
anything, this should *help* the user understand that a reload action
might not reset their form/script/app in the content area.

> Visual connection I'll buy, but five icons inside of a textbox and a
> dropmarker, that's killing me. I have some ideas in my head around
> visual connection without sticking things in the textbox (i.e. the go
> button and the history dropmarker could be combined in a similar fashion
> as what we're discussing with the searchbox).

These sound like good optimization ideas. FWIW, you got the ordering
wrong, and not all of those indicators would be there all the time, but
it's something to be concerned about. When I paint the picture I
promised Robert, I'll look into some of them.

> Off the top of my head, we could show the post-it note behind the
> favicon and make it look like the favicon is on the sticky note, instead

We should try both treatments. Good call.

> should work visually. Then, to tie things neatly together, we could
> co-opt clicking on the favicon (which currently selects the url bar
> contents) for access to the tagging UI. It's light, subtle, and doesn't
> add anything to the UI in terms of clutter or new ideas to understand.

Did I, uh, not mention that option in the original post? Huh. Way to
fail, me! This was one of the options for this UI. Less discoverable,
but very slick.

> toplevel chrome. Random thought of the minute: this might turn out to
> be annoying, but we could make the most commonly-accessed live
> bookmarks, bookmarks, and/or folders be the default toolbar contents for

You were right: that *will* turn out to be annoying. :) The follow-ons
to this point illustrated how this functionality will immediately lead
to requests for management UI around locking the entries, etc, etc.

> Would need a fair bit of tuning, I suspect, but could be a killer feature.

I'd support a requested optimization feature, but we shouldn't be doing
this by default. Microsoft Office's "adaptive menus" were a disastrous
story in usability, and we should learn from their experience.

> Big win there. Low on my radar was fixing statusbar text to indicate
> this, a la Safari, this works too.

We should also fix the status bar text, though. Even if we do end up
hiding it by default, when a user shows it, it should be saying the
right things. :)

Mike Beltzner

unread,
Mar 2, 2006, 4:49:36 AM3/2/06
to Brian Rakowski
Brian Rakowski wrote:
> have been pretty popular with end users. These "buttons" are little more
> than PBT livemarks with the capability of displaying a different favicon
> depending on contents of their RSS feed. Adding this capability to livemarks
> and making it easier to create these bookmarks could be very cool.

I'm having trouble interpreting this request: are you saying that
livemark buttons should indicate when there's new content in the
livemark? That seems quite reasonable, yes. :)

> I don't understand the argument against state-changing buttons. Is there any
> data to back this up? My only data point is that users have responded

The argument is that they're harder to notice, since they're always
there in one state, meaning that the user needs to both notice and
interpret the change in the button appearance to decode state.

> information in a similar way to using folders. I'd suggest leaving the
> social tagging to a del.icio.us extension but keeping the personal
> organization tagging as an enhancement to folders.

Please refer this discussion to the Places UI spec thread, since it
really goes to the heart of how we're expressing tagging more than the
display in the UI.

Tero Tamminen

unread,
Mar 2, 2006, 4:52:28 AM3/2/06
to
Thomas Stache wrote:
> Mike Beltzner schrieb:
>> Daniel Cater wrote:
>>> 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?
>> Some form of keyboard shortcut, I had been assuming. Although I note
>> that none exists today. Hrm.
>>
>
> Huh? Here for me "Go->Home Page" has clearly written "Alt+Pos1" next to it.
>
> Thomas

The shortcut is pretty annoying, because at least in my keyboard layout
(and all others I have used) pos1 is home button (which is on the right
side of the keyboard) and alt is on the left side (altgr which is on the
right side doesn't work).

I use keyboard with one hand usually when I am browsing the Net and with
this shortcut I can't go to home page (one handed and if I don't change
it). And yes, I use home page.

Tero Tamminen

Tero Tamminen

unread,
Mar 2, 2006, 4:59:23 AM3/2/06
to
Mike Connor wrote:
>
> Apps with status bars always seem to have resizers in the apps I use on
> Windows and GNOME, at least if they're native widgets. It isn't
> strictly necessary, but does tend to differentiate "this window can be
> resized" fairly well.
>
> -- Mike
>
>

And if you remove status bar, it shouldn't be shown. If you show it,
then scrollbar doesn't go to the bottom of the page but page area goes
there, and this looks really horrible in my opinion. Resizer could be
shown when horizontal scrollbar is shown.

Tero Tamminen

Simon Paquet

unread,
Mar 2, 2006, 5:42:38 AM3/2/06
to
Brett Wilson wrote on 28. Feb 2006:

>> (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?
>

> 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.

Do you have any metrics to support that? Because from my own usage
and by looking at the usage of most of the people I'm working with
(mostly non-technical IE users) I would totally disagree.

--
Simon Paquet
Sunbird/Calendar website maintainer
http://www.mozilla.org/projects/calendar

Simon Paquet

unread,
Mar 2, 2006, 5:48:13 AM3/2/06
to
Mike Beltzner wrote on 28. Feb 2006:

To keep this post short, I'll only comment on the stuff that I totally
disagree with.

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

Don't! Seamonkey and the Suite have done that and most people consider
this one of their worst UI mistakes and the cause of a lot of flamewars
in the community.

At least for me, having the home button back in the navigation bar as
in NS 2/3/4 and IE 4/5/6 was the main reason for me to switch from the
suite to Phoenix 0.1 back in the good old days, way before most the
current team took over Firefox development.

I would also support Pike's argument, that the usage of the home button
seems to depend a lot on the country that you're in. I'm from Germany,
but often work in the UK and while most of my German colleagues use the
Home button extensively, most UK colleagues totally ignore it.

Peter Lairo

unread,
Mar 2, 2006, 5:51:37 AM3/2/06
to
Thomas Stache wrote on 02.03.2006 10:08:
> How should Firefox know how many "BM-A"s should be added?

These are good questions. Read on...

> - how would it react to different window sizes (e.g. when switching
> between maximized and normal, or between the laptop screen and an
> external LCD)

Novice users virtually never do this, but...

> - would the toolbar use a overflow chevron,

No, those should be removed, and re-added if the window-size is
increased later. Rule: Never overflow with BM-As.

> - how many items would flow into the chevron?

None.

> It's the tiny details that matter, and this seems just too tricky given
> the Ff2a1 progress...

Seems like a pretty simple rule to me (Never overflow with BM-As.).

Anyhow, it's an outer-edge case.

BTW: Funny, I was just thinking about "BM-A overflow" just 10 minutes
before I read your post. :-)

Axel Hecht

unread,
Mar 2, 2006, 6:57:59 AM3/2/06
to
If quick actions to multiple tabs is the argument for fixed size, could
we, just stabbing in the dark, do something like dynamically increasing
the size on delete?
Something like wait half a sec or a sec, and then grow the tab size from
current opt to new opt width?

We may want to do the same thing for shrinking, though I'm not sure if
that's as common and good.

Axel

Adam Kowalczyk (Ancestor) wrote:
> Mike Beltzner wrote:
> > Thanks for this analysis, Adam. I'm not sure that "most" of our users
> > browse with > 5 tabs, although I'm sure that the majority of our most
> > passionate users do.
>
> I didn't mean that most users browse with > 5 tabs, I'm pretty sure they
> don't. I meant that it is more common for users to browse with the
> medium number of tabs than with the large number.
>
> >What was your criteria for "tabs are too small", by
> > the way?
>
> Maybe I'd better describe my criteria for the acceptable size of the
> tabs. User has to be able to easily identify tabs i.e. there must be a
> sufficient portion of the title visible. Secondly, the size cannot make
> it significantly harder to quickly switch tabs (in other words point
> them with mouse :) For me the limit is around 100px, that is 2/5 of the
> standard width but that's totally debatable.
>
>
> Mike Connor wrote:
>> The problem with non-fixed width tabs is that you can't keep the mouse
>> in one place and quickly close tabs, because they're getting wider as
>> you close tabs. With the change to closebutton on tab, instead of
>> closebutton on tabstrip, this is a problem for a lot of users.
>
> Yep, I know, there seems to be a quite strong lobby. :) It's a question
> of wins and losses, though. I think that the losses are greater as you
> switch tabs and want to have an overview of them all the time. Mass
> closing is a one-time job.
>
> There were some other solutions discussed that, if introduced, could
> compensate this disadvantage. One is a context-menu option for something
> like "Close all tabs to the right". The other is allowing to select
> multiple tabs with Ctrl.
>
> BTW, I really wish there was a way to advertise middle-clicking as it is
> by far the quickest way and it doesn't share any of the disadvantages of
> other methods. I don't know how it could be made more discoverable, though.
>
>> I'm trying to get the implementation done this week, and I can easily
>> play with the values to see if a small amount of flex pays off, but
>> I'm not hopeful.
>
> At the least, could you implement it so that it could be modified with
> min-width via userChrome.css?
>
> There'll be a lot of time to get feedback from the testing community and
> I'm sure we'll find the best solution possible.
>
> Cheers,
> Adam

Axel Hecht

unread,
Mar 2, 2006, 7:02:39 AM3/2/06
to
Mike Beltzner wrote:
> Benedikt Kantus wrote:
>>> (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.
>>
>> 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.
>
> Having the closebuttons on non-focused tabs causes one of two problems:
> either you've got a high potential of accidental data loss, as selecting
> a tab makes it extremely possible to accidentally hit the close button,
> OR if you disable the inactive tab closebuttons but still render them,
> you've got dead-ui.
>
> Having a closebutton on the active tab does a couple of positive things
> for usability: first, it makes it easy to see which is the active tab.
> Second, it prevents accidental dataloss. Third, it makes it easier to
> find the close-tab button since there's only one of them across the
> entire tab strip.
>

If I close a tab, will there be a grace period before I can close the
next one? Do we have something like that right now? Of course, that
ain't new compared to the single close button we have now.

I'm thinking of the "click" bouncing (bad english word, maybe, multiple
clicks instead of one) here.

Axel

Axel Hecht

unread,
Mar 2, 2006, 7:21:41 AM3/2/06
to

Count me in as information hound. :-)

One argument that I picked up in the german forum is, quite a few
extensions hook up in the status bar. I myself use the FoxClocks
extension, I think some weather extensions do that, too.

Axel

James Slaughter

unread,
Mar 2, 2006, 7:28:04 AM3/2/06
to
Mike Beltzner wrote:
> (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
> (3) The RSS [.)] and Go [=>] buttons move inside the URL bar, again to
> emphasize their direct relationship with the page. The Go button

I'd like to emphasize a conceptual difference here: the feed icon, the
lock and the favicon are conveying information /about/ the page (that it
has a feed, that it's secure or partially secure, etc). A button, on the
other hand, /performs actions/ on a tab.

If buttons like Reload and Go are moved inside, you must be careful to
make it obvious that they are still buttons, and are not simply
representing the state of the URL typed. Will they highlight on
mouse-over like other clickable elements?

As an aside, I'd also like to mention that I had the Go button visible
for a long time. This was purely so that I could paste/drag URLs with
the mouse and then navigate to them, without switching to the keyboard.
I use the Paste'n'Go extension for that now, but please don't think that
the Go button is only for people who don't know to press enter.

If the Go button was purely for novices, I'd suggest that 'File|New
Location...' should always raise the dialogue that's shown when the URL
bar is hidden. If I were a novice, I'm not sure that the current
behaviour would help me much.

> (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

Do you mean that it will indicate progress in addition to the progress
meter, or that it will become the the indicator and meter?

If it's in addition to the progress meter, is that because the progress
meter is on the status bar? Have you considered using the background of
the address bar as a progress bar?

My concern here is that the throbber is the indicator that the browser
is 'still doing something' when the progress meter may have appeared to
stall. One could argue that the fact that the progress meter is
displayed or the stop button is enabled (if it's not hidden) indicates
that the browser is still going (the throbber certainly doesn't convey
/more/ information), but my suggestion is that a static screen is less
evocative of progress.

Personally, I think this has the feel of an idea that's cute, but not
necessarily better, especially if another UI element is also measuring
progress.

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

Personally, I think this makes a lot of sense as a default: the homepage
is the ultimate personal bookmark.

There have been a number of comments suggesting that the home button be
removed altogether; that it's somehow an unused feature. In fact, a
significant percentage of people have a search page as their
homepage[*]. For them, clicking 'Home' (or pressing Alt-Home) is as easy
as clicking in the search bar (or pressing Alt, no, Ctrl... K??). This
may be a deep-rooted practice that they developed in other browsers.

I've worked with a number of people who use the Firefox search bar for
something like dictionary lookup and continue to use their homepage for
most of their searching. Personally, I use the Home button as my 'go to
search' button and my 'open new tab' button (by middle clicking). I hide
the search bar and new-tab buttons to give me more horizontal real estate.

[*] A mozillazine survey showed that this is true, even among Firefox users.

> (8) Closebuttons appear on the active tab only in order to achieve the

> (9) Tabs are a fixed width

This is an important combination. The builds I've seen before don't keep
the tab size fixed, and so the close button "jumps around".

I read a number of sites with short articles that I open in tabs (news,
blogs, etc). I often leave the mouse over the close box on the far
right, and I enjoy the fact that it never moves. If you can combine the
non-moving close button with the more obvious interface (let's not say
intuitive -- the close button is always in the top right below the main
close button for MDI documents), I'll be very happy.

I agree with not putting close buttons on background tabs. There's never
been visible UI for that before, and it's not a source of frustration.

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

Presumably, you mean for this to only be the case if a horizontal scroll
bar is visible? On Windows, only windows with a status bar or both
horizontal and vertical scroll bars have sizing grips.

I have very mixed feelings about the decision to hide the status bar. I
remember using the browser when it was called Phoenix without the status
bar visible. I am sure of this, because I was always annoyed by a bug
that stopped the area between two scroll bars from repainting :)

On the other hand, these days I really like the status bar visible: I
think the switch occurred after I found dom.disable_window_status change
(thus recovering the status bar for a useful purpose), and because I
have a number of extensions that make good use of it: I can tell whether
a website's tried to set a cookie, control Greasemonkey, etc.

I quite like the idea of displaying the target URL in the address bar,
perhaps in italic text or with other embellishments when hovering over
the link. Without a mechanism to indicate at least that, I'll certainly
re-enable the status bar in order to get it back, get a size-grip on all
pages, and preserve the current indicators. The amount of screen estate
it takes isn't really enough to make those sacrifices.

Regards,
James.

Axel Hecht

unread,
Mar 2, 2006, 8:01:02 AM3/2/06
to
Mike Beltzner wrote:
>
> My feeling is that the first two issues are not actually relevant to the
> general browsing case, and really only apply to users who have an
> interest in seeing that information, and those users can easily switch
> the status bar on. The third issue is an OS windowing issue, and in our
> efforts to look and feel native, we should probably try to stick with
> what the OS does.
>

Just adding one more item here. If we don't display the status bar, then
how do people find out that it had information that could tell them
about where they may go next?

I can imagine that users-at-the-edge-to-power or growing of age to
become power users may actually discover the usefulness of the status
bar information themselves.

So I do think there's an educational value in the status bar that can
hardly be replaced.

Axel

PS: I know my surfing habits well enough to say

I'll switch statusbar on first thing on install. Or maybe second, I may
remove the go button first. Whichever is exposed better.

Axel Hecht

unread,
Mar 2, 2006, 8:09:39 AM3/2/06
to
Mike Connor wrote:
> Random thought of the minute: this might turn out to
> be annoying, but we could make the most commonly-accessed live
> bookmarks, bookmarks, and/or folders be the default toolbar contents for
> users, so their toolbar always includes the things they access the
> most.

Just to second beltzner, I *hate* software that claims to know better
what I want than I.
And not that I'd recommend anyone to show the browsing habits of their
last 5 minutes to anyone who's looking over their shoulder.

Predictability in UI is key, IMHO.

Axel

scratch

unread,
Mar 2, 2006, 8:07:23 AM3/2/06
to

so then you (when trying to spoof) don't use a link, you use a div with
link styling and an onclick handler. it's effectively a link, even
looks like a link with a (fake) onhover div...

-scratch

scratch

unread,
Mar 2, 2006, 8:08:49 AM3/2/06
to
Simon Paquet wrote:
> Brett Wilson wrote on 28. Feb 2006:
>
>>> (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?
>> 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.
>
> Do you have any metrics to support that? Because from my own usage
> and by looking at the usage of most of the people I'm working with
> (mostly non-technical IE users) I would totally disagree.

indeed. every time my uncle uses my computer, i get the following
questions: "you don't have a home button?" "so then, how do you go home?"

-scratch

Axel Hecht

unread,
Mar 2, 2006, 8:19:35 AM3/2/06
to
Mike Beltzner wrote:

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

One question on customization, in particular and in general:

Right now, it's trivial to get rid of the Go button, at least when you
know how to change the toolbar.
If we merge the go button into the stop button, how would one get rid of
the go-part of that button?
In general, how does one customize multiple-purpose buttons, and how is
that multipurpose indicated during toolbar customization. Ie, if I drag
out the stop button and want to add back the go button, how would a user
do that? (Say a user did that in 1.5 and wants that behaviour back in 2.0)

Axel

Gavin Sharp

unread,
Mar 2, 2006, 9:28:43 AM3/2/06
to Mike Beltzner, dev-apps...@lists.mozilla.org
Mike Beltzner wrote:

> Robert Accettura wrote:
>> I like this a lot. I'd also like it if it would pre-populate with
>> the search query if I go to google's website and manually and perform
>> a search. This keeps my search history in sync between the two, and
>> allows me to quickly recall a search.
> Hot. Great idea. Gavin, would this be tricky to do given our planned
> search infrastructure?
Being able to detect that the user's made a search at Google just by
observing page loads and sniffing URLs seems pretty fragile - there'd
need to be a solid way to know that the user just performed a search,
and what those search terms are. It might be possible to hook into
autocomplete and have it sync search histories between the search bar
and search engines on the web, but I'm not sure this is something that
can happen in the Firefox 2 time frame. It's not really something that
the new search service makes any easier. It'd be a good idea to file a
bug on this so that implementation details can be sorted out, though.

--
Gavin

Axel Hecht

unread,
Mar 2, 2006, 10:39:01 AM3/2/06
to
Mike Beltzner wrote:

> Axel Hecht wrote:
>
>>> (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
>>
>> I'd rather keep the status bar and kill the throbber.
>
> Honestly, the throbber is a more honest indication of page load
> progress. I have a personal hate on for *any* sort of progress indicator
> that makes bold assertions of overall progress without having any way of
> ever knowing when the end will actually come, since basically they
> become a "zeno's paradox" indicator. But I digress.

If we need to keep the throbber, do we still need to make it link
anywhere? I think we just moved the link the throbber points to from one
useless place to the other, and ever since the throbber isn't a company
logo anymore, I don't see a whole lot of reason to make it do anything
on click. At least not head over to a webpage.

And I'd celebrate another died link in trademarks policies.

Axel

Adam Kowalczyk (Ancestor)

unread,
Mar 2, 2006, 11:31:13 AM3/2/06
to
James Slaughter wrote:
> Mike Beltzner wrote:
>> (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
>> (3) The RSS [.)] and Go [=>] buttons move inside the URL bar, again to
>> emphasize their direct relationship with the page. The Go button
>
> I'd like to emphasize a conceptual difference here: the feed icon, the
> lock and the favicon are conveying information /about/ the page (that it
> has a feed, that it's secure or partially secure, etc). A button, on the
> other hand, /performs actions/ on a tab.

I agree. This, along with size and over-population issues, is why I'm
not in favor of placing buttons inside the Location Bar. Some other
clear indication that they belong together would be nice. However, this
solution is too controversial to be worth going for only for the sake of
indication. Unless there are others reasons I'm missing here.

Also, for the reasons already mentioned by others, I think that a
Go/Reload button is much better idea than Go/Stop.

> Mike Beltzner wrote:
>> (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

It would be a great advantage of this solution if throbbers on tabs also
worked this way. It would allow tracking the page load progress of
background tabs.

Cheers,
Adam

It is loading more messages.
0 new messages