Changes to Fx2 Chrome
Mike Beltzner
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
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
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
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
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
> (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
> 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
> 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
>> (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
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
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
> 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
> (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
- Pam
James Graham
> 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
> 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
> 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
> 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
> (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
> (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
> 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)
> > (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
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
> 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
> 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
>>> 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
>> (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
> 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
> 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
> 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
> 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
> 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
> 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
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
> 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
> (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
> 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
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
[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
> 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
> 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
> (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
> On 03/01/06 13:17, Peter Lairo wrote:
>
>
> 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
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 s