Changes to Fx2 Chrome

28 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