FX2 Chrome Changes: Round up and decisions
Mike Beltzner
Last week I went through the "Changes to Fx2 Chrome" thread and
consolidated all of the feedback. Based on the excellent comments and
suggestions in there, I've put together a new mockup. Pay close
attention to items 1, 3 and 9 when reviewing this.
I've also updated the wiki at
http://wiki.mozilla.org/FX2_Visual_Update/User_Interface_Design
(note: The target for these changes will be **Bon Echo Alpha 2**)
New Mockup:
(2) (5) -.
(1) | (3)-.----. (4) -. |
| v v v v v
.----------------------------------------------------------------------.
| File Edit View History Bookmarks Tools Help [_][=][x]|
|----------------------------------------------------------------------|
|.--. .--. .--. ,-------------------..--,,-, ,----------.---,, .i. |
||<-| |->| |[]| ( {} www.foo.com v ||.)||=>) ( google G |.O |) -O- |
|'--' '--' '--' `-------------------''--''-' '----------'--v'' 'i' |
|----------------------------------------------------------------------|
|(.O) (&) (BBC News v) (Mozilla) |
|.-----------,.-----------,.-----------,-------------------------------|
||{} Bar || {} Foo (x)|| {} Baz | |
|-------------' '--------------------------------------------|
| |^|
| |H|
: (page content) : :
. . .
: : :
| |V|
| //|
'----------------------------------------------------------------------'
| New tab: http://www.foobarbaz.com |
'----------------------------------------------------------------------'
^ ^ ^ ^ ^
' | | | |
(6) '- (7) (8) -' '- (9) (10) -'
Summary of feedback and decisions:
(1) It was noted that "Stop" needs to be a large, easy to find button
that people can quickly click in order to stop page loading, and that
often the button is used to stop AJAX and script-y things that keep
loading resources even after the page is loaded. Also, see (3) for
discussion on the stateful Stop/Go button.
(2) Renaming "Go" menu to "History" was seen as a good idea.
(3) Putting buttons inside the URL bar led to interesting questions
about how they could be taken out again. Any such system would require a
lot of work and make the UI more complex. Instead, it will be
safer/easier to allow buttons to be "docked" to the edge toolbar, and
keep the space inside the URL bar for indicators (which will still be
made to look like buttons to lend a button-like affordance)
Combining the Go/Stop button was seen as interesting, but potentially
dangerous and confusing. It occurred to some that a more natural
optimization would be to combine the Go and Reload functions, since when
a page is loading or loaded, the functions are equivalent. The behaviour
would be:
When URL field is being modified == button is "Go"
Page is loading == button is "Go"
Page has loaded == button is "Refresh"
(4) Putting the search engine selector at the right (left for Mac) and
using grey text in the background was seen as a good idea.
(5) Using the throbber as a progress indicator was seen as a good idea,
and should be enabled both in the upper-right corner and on tabs.
(6) Putting the "Search Bookmarks" button on the Bookmark Toolbar was
seen as a good idea, as long as it could be moved back to the Toolbar.
(7) Moving the "Home" button to the Bookmark Toolbar was contentious,
and users should be allowed to move it back to the main toolbar.
(8) Close buttons on the active tab only was seen as the best strategy
to improve the usability of a "close single tab" task while also
preserving tab strip real estate. Exposing background close of tabs
wasn't seen as an important enough case to show them on all tabs. A
"Close Tab" button should also be added to the "Customize" palette.
(9) Optimizing tab width to support a consistent (X) location for
quickly closing multiple tabs wasn't seen as being worth the cost of
reducing the space available for having multiple tabs open before
hitting tab overflow solutions. Some good alternatives were proposed the
best being that tabs shrink as they are opened, and stay at the same
width when closed with the mouse *until* the user moves the cursor away
from the tabstrip, at which point they subtly stretch to fit the
available space.
(10) Hiding the status bar by default was very contentious. People
expressed concern at not being to see the link destinations, as well
as the browser "feeling" slower when the user can't see the messages
about contacting the remote server, etc. It should be left on. The text
in the statusbar should indicate if a link will be opened in a new
window (Opens new window: ...), a new tab (Opens new tab: ...), or
replace content (Go to: ...)
Discussion question consensuses ..:
(A) Keep the Bookmark Toolbar
(B) Use the post-it note metaphor for indicating that a page has tags
(C) (This functionality will be part of Places anyway)
(D) (We're keeping the status bar, this discussion is moot)
(E) Changing the mouse cursor was seen as a good idea
cheers,
mike
--
mike beltzner, user experience lead, mozilla corporation
Adam Kowalczyk
the major ideas and criticism seems to be taken into consideration, the
most controversial issues are addressed and a good balance has been
created based on the feedback. Congratulations on a great job.
Mike Beltzner wrote:
> (9) Optimizing tab width to support a consistent (X) location for
> quickly closing multiple tabs wasn't seen as being worth the cost of
> reducing the space available for having multiple tabs open before
> hitting tab overflow solutions. Some good alternatives were proposed the
> best being that tabs shrink as they are opened, and stay at the same
> width when closed with the mouse *until* the user moves the cursor away
> from the tabstrip, at which point they subtly stretch to fit the
> available space.
This seems like a decent workaround, however I am afraid it may be a
little confusing. If I saw this behavior without previously knowing the
purpose of it I'd think of it as an unnecessary, fancy animation.
Also, consider the following situation. After closing a tab you quite
probably want to chose another tab. But the cursor is still over the
tabstrip and the tabs have not yet stretched. If you move the cursor
towards the tab you want to select next and it leaves the tabstrip by so
much as a pixel (and it surely will), the tabs will get resized and will
change their positions which is totally confusing. The alternate way is
to leave the tabstrip and wait for the stretching to finish which is
hardly good either. I am just not sure this solution is neutral for
those who don't need it.
And who needs it? I think that mass-closing in specific to power users.
I think they may well find alternate ways to perform this: the Close Tab
button that will be available from the palette, gestures, extensions
restoring the Close Tab in the right corner of the strip etc. It'd be
great to serve this use case by default but it shouldn't be at expanse
of the rest of usability.
- Adam
Simon Bünzli
http://wiki.mozilla.org/Talk:FX2_Visual_Update/User_Interface_Design#Link_Target_Indicator
Mike Beltzner schrieb am 21.03.06 13:31:
> (10) Hiding the status bar by default was very contentious. People
> expressed concern at not being to see the link destinations, as well
> as the browser "feeling" slower when the user can't see the messages
> about contacting the remote server, etc. It should be left on. The text
> in the statusbar should indicate if a link will be opened in a new
> window (Opens new window: ...), a new tab (Opens new tab: ...), or
> replace content (Go to: ...)
Adding text in front of the URL in the status bar is IMHO not optimal:
* It makes it more difficult to quickly read the link URL, because you
always have to first read over that text.
* You can see less of the URL, especially on a short status bar (be it
because it's crowded with extension related indicators, or simply
because the window isn't maximized).
Both points also apply if the text would be appended instead of
prepended. My alternative would be to add a link target indication icon
in front of the link and use the text only as tooltip. This icon would
not only use much less space but would also be of a fixed width, having
the URL start thus always at the same place.
A further benefit would be that the icon could be hidden through CSS
whereas depending on the implementation this wouldn't be possible for
the text (if no separate label is used).
> (E) Changing the mouse cursor was seen as a good idea
Was it? Wouldn't this rather confuse people instead of help them? Why is
the status bar indicator not enough? I suppose, most people don't care
where their links will open - as long as they just open.
A further - unrelated - idea for a change would be to (allow to) tie the
Back and Forward buttons together so that they provide only one
drop-down menu with all history entries - as it's already planned for
the History menu and as IE7 beta 2 also does it. This might allow users
to better grasp where they are and what they've visited in the current
tab (and they wouldn't have to worry anymore whether /that other site/
they just visited was "back" or "forward").
A prototype of an extension which does this is available from
http://forums.mozillazine.org/viewtopic.php?t=389946
It would even be possible to automatically unify both buttons when
they're right next to one another and keep them separated when that's
not the case (as seen in Flock, although their buttons just look
differently when next to each other), so as not to lose functionality.
Cheers,
Simon
urbanhaas
Any thought given to the PBT switching between different places roots and
auto-populating? I know there were some interesting ideas in the discussion.
Urban
"Mike Beltzner" <mbel...@gmail.com> wrote in message
news:nqqdnd7Xev2Db4LZ...@mozilla.org...
scratch
>
> Combining the Go/Stop button was seen as interesting, but potentially
> dangerous and confusing. It occurred to some that a more natural
> optimization would be to combine the Go and Reload functions, since when
> a page is loading or loaded, the functions are equivalent. The behaviour
> would be:
>
> When URL field is being modified == button is "Go"
> Page is loading == button is "Go"
> Page has loaded == button is "Refresh"
this is indeed more natural than the combined go/stop button, but i
don't see what it buys us other than change for the sake of change.
perhaps a few pixels for those who currently have a go button displayed,
but is that really worth it? if you plan to go ahead with it, how about
maintaining the separate reload button (just having it not on the
toolbar by default), and simply changing the go button text? you could
even go as far as only changing the go button text if the reload button
isn't also visible, which would enable people who use the go button to
maintain current appearance/behavior as well.
another thing to consider is that, unless both are exactly the same
size, the toolbar contents will shift around distractingly after a change.
-scratch
Axel Hecht
With my l10n hat on, we need to watch RTL here even more carefully than
we already do.
Axel
Simon Bünzli
> in the statusbar should indicate if a link will be opened in a new
> window (Opens new window: ...), a new tab (Opens new tab: ...), or
> replace content (Go to: ...)
> (E) Changing the mouse cursor was seen as a good idea
I've already had my say on the UI part of this. Furthermore I see one
more implementation specific issue:
* Firefox has to be psychic to get this feature right.
There are several aspects influencing the target of a link:
0. the link itself (new popup-window, current tab)
1. the pressed modifier keys (new window, new tab, current tab)
2. the target attribute (new window or existing window)
3. the pref where to open such links (new window, new tab, current tab)
4. the onclick attribute (new popup-window, current tab)
5. any mouse and keyboard related event handler attached by a script
(new popup-window, current tab)
6. the pref where to open links opened by javascript (same as the other
pref, with the difference that sized popups are treated differently)
Not sure whether I've forgotten anything (except of extension related
effects which should be taken care of by the extensions themselves).
Getting point 1 right is already non-trivial and could AFAIK not be done
by an extension with no platform-dependent code (since you have to check
the modifier states when setting the link-hover cursor, and you have to
explicitely re-set the cursor when a modifier state changes).
Point 2 should be trivial (unless you want to make a difference between
the two cases). Point 3 should be trivial.
Point 4 (and point 0 for javascript: links) is the first causing me a
real head-ache, since parsing the onclick attribute for "window.open"
isn't enough - you not only have to know whether the popup will be sized
or unsized, but also whether you can actually reach that statement:
<a onclick="if (openPopups) { window.open('new_page.html', ...); return
false; }" href="new_page.html" >
Maybe we could err here on the side of what you usually see:
<a onclick="window.open('new_page.html', ...); return false;"
href="new_page.html">
So just see whether the onclick attribute starts with "window.open" and
pray that the user doesn't care if we get this case wrong.
Point 5 is where the fun lies. I don't know how often you see such code
in real life, but there won't be anything you can do about it, except
maybe simulate a click and see what would've happened (supposing that
the click doesn't have any other side-effects).
And point 6 is a more complicated variation of point 4 which could be
taken care of at least partially with a well-placed regexp.
In the end, we'll either have to live with a half-backen implementation
(hoping that it serves more than it just causes confusion) - or leave
that feature to extensions (which will exist if the feature is really
requested - maybe there are already - I don't know).
I'd vote for the second.
Cheers,
Simon
P.S.: A further request was to also indicate whether a link opens in an
external application. That would make matters only slightly more
complicated - a HEAD request for getting the mime-type should provide
the required information - supposing that you have the correct URL in
the first place.
Wladimir Palant
> I've already had my say on the UI part of this. Furthermore I see one
> more implementation specific issue:
>
> * Firefox has to be psychic to get this feature right.
I don't see the problem.
> There are several aspects influencing the target of a link:
>
> 0. the link itself (new popup-window, current tab)
Ok.
> 1. the pressed modifier keys (new window, new tab, current tab)
No. Pressing modifier keys is user's decision, it has nothing to do with
the link itself. The user presses modifier keys based on what he sees in
the status bar.
> 2. the target attribute (new window or existing window)
It probably is interesting to know whether the link will open in a frame
or in a different window. That's simply a call of
nsIDocShellTreeItem.findItemWithName().
> 3. the pref where to open such links (new window, new tab, current tab)
As you already said, this is trivial.
> 4. the onclick attribute (new popup-window, current tab)
No, that's not the point of this feature. The status bar shows where the
link itself is pointing. You can always write:
<a href="http://mozilla.org/"
onclick="location.href='http://bugzilla.org/'; return false">
bugzilla.org won't and can't show up in the status bar, that's the way
it is. Same thing with the link target.
> 5. any mouse and keyboard related event handler attached by a script
> (new popup-window, current tab)
Same as 4, see above.
> 6. the pref where to open links opened by javascript (same as the other
> pref, with the difference that sized popups are treated differently)
Again, that's not what this is about.
Wladimir
Axel Hecht
Why is that? I don't care about the href, I care about where I go when I
click the link.
>> 5. any mouse and keyboard related event handler attached by a script
>> (new popup-window, current tab)
>
> Same as 4, see above.
>
>> 6. the pref where to open links opened by javascript (same as the other
>> pref, with the difference that sized popups are treated differently)
>
> Again, that's not what this is about.
>
> Wladimir
Axel
Wladimir Palant
>> bugzilla.org won't and can't show up in the status bar, that's the way
>> it is. Same thing with the link target.
>
> Why is that? I don't care about the href, I care about where I go when I
> click the link.
Because trying to analyze JavaScript to find out what it will do is a
waste of time. If the page plays nice, the status bar will display
correct information. If it doesn't - the status bar will show trash and
there is nothing we can do about it. Other than suggesting to disable
JavaScript of course :)
Wladimir
Simon Bünzli
> Because trying to analyze JavaScript to find out what it will do is a
> waste of time. If the page plays nice, the status bar will display
> correct information. If it doesn't - the status bar will show trash and
> there is nothing we can do about it. Other than suggesting to disable
> JavaScript of course :)
Simon Bünzli schrieb am 22.03.06 03:20:
> In the end, we'll either have to live with a half-backen implementation
> (hoping that it serves more than it just causes confusion) - or leave
> that feature to extensions (which will exist if the feature is really
> requested - maybe there are already - I don't know).
>
> I'd vote for the second.
Just to reiterate the point:
/hoping that it serves more than it just causes confusion/.
Any opinion or even data on this?
Cheers,
Simon
Axel Hecht
We don't necessarily have to find out what the javascript evaluates to,
we could just display a javascript:foo url instead. As most of the time
this is phishing or spoofing, I think it is important to not take this
lightly.
Axel
Nickolay Ponomarev
> Mike Beltzner wrote:
>>
>> Combining the Go/Stop button was seen as interesting, but potentially
>> dangerous and confusing. It occurred to some that a more natural
>> optimization would be to combine the Go and Reload functions, since
>> when a page is loading or loaded, the functions are equivalent. The
>> behaviour would be:
>>
>> When URL field is being modified == button is "Go"
>> Page is loading == button is "Go"
>> Page has loaded == button is "Refresh"
>
> this is indeed more natural than the combined go/stop button, but i
> don't see what it buys us other than change for the sake of change.
I was wondering about it too.
I would also like to note that the presumption that the two buttons have the
same function when the page is loaded is wrong. The two counter-examples that
come to mind are:
1) a URL with anchor <http://example.com/a/b/c#anchor>. "Go" doesn't reload the
page in that case.
2) a page that was generated with the use of post data
I actually use the "Go" button in these two case, although of course I'm not
your average user. One could even argue that these differences are rather
unintuitive.
Nickolay
scratch
i've long thought that a good idea. however there is the problem where
the onclick handler spawns a new window and then the href modifies the
current window.
-scratch
Ben Goodger
> Summary of feedback and decisions:
>
> (1) It was noted that "Stop" needs to be a large, easy to find button
> that people can quickly click in order to stop page loading, and that
> often the button is used to stop AJAX and script-y things that keep
> loading resources even after the page is loaded. Also, see (3) for
> discussion on the stateful Stop/Go button.
I don't buy that "Stop" needs to be as big or easy to hit as "Reload".
I'm sorry if I didn't make this clearer before.
There are very many usages of reload for a wide range of web applications.
Because of the relatively higher usage of "reload", changing the
location of Reload, and perhaps combining reload with another button
seems like a bad idea.
IMO, stop exists mostly to satisfy OCD. Given that the "Go" button would
show "Stop" most of the time, except when the user is typing a new URI,
I don't see the problem.
(The flip side is that in general, the go button is a waste of space,
since it's redundant with Reload, which is I guess why you sought to
combine them)
-Ben
Wladimir Palant
> We don't necessarily have to find out what the javascript evaluates to,
> we could just display a javascript:foo url instead.
What should be foo in this case? Value of the onclick attribute?
Combination of all listeners for the "click" event? How about
"mousedown"? What about listeners using capture installed on a higher
level in DOM? And what if we have onclick="return true"?
Wladimir
scratch
good point. perhaps we should simply indicate that there is in fact a
javascript event handler for the link.
-scratch
Mossop
thread so thanks for positing this round up Mike. Just a couple of quick
points, please feel free to tell me to shut up if they've already been made:
Mike Beltzner wrote:
> All,
>
> .----------------------------------------------------------------------.
> | File Edit View History Bookmarks Tools Help [_][=][x]|
> |----------------------------------------------------------------------|
> |.--. .--. .--. ,-------------------..--,,-, ,----------.---,, .i. |
> ||<-| |->| |[]| ( {} www.foo.com v ||.)||=>) ( google G |.O |) -O- |
This makes it look like there is no longer a title bar on the window, is
that going to be the case?
> (4) Putting the search engine selector at the right (left for Mac) and
> using grey text in the background was seen as a good idea.
>
This seems very strange. How often do you see the icon relating to
something on it's right? Look at the bookmark toolbar. Look at the icons
for menus. The start menu. All of them have icons on the left and I
think the search bar should as well.
Mossop
Adam Kowalczyk
> This seems very strange. How often do you see the icon relating to
> something on it's right? Look at the bookmark toolbar. Look at the icons
> for menus. The start menu. All of them have icons on the left and I
> think the search bar should as well.
>
> Mossop
I *think* the idea is to make it look more like a button, analogous to
Go button. In such case placing it on the right makes a lot of sense.
- Adam
Daniel Schierbeck
> Combining the Go/Stop button was seen as interesting, but potentially
> dangerous and confusing. It occurred to some that a more natural
> optimization would be to combine the Go and Reload functions, since when
> a page is loading or loaded, the functions are equivalent. The behaviour
> would be:
>
> When URL field is being modified == button is "Go"
> Page is loading == button is "Go"
> Page has loaded == button is "Refresh"
A question to all of you: have any of you actually tried coupling the
stop and reload buttons in Firefox? I've used a CSS hack to show only
the stop button when loading and the reload button when not. I've
(power)used it for several weeks, and I never bumped into a problem. I
don't think you have to be an advanced user to use such a
context-specific button, after all, the icons are very clear.
Cheers,
Daniel
Ian Pottinger
> I *think* the idea is to make it look more like a button, analogous to
> Go button. In such case placing it on the right makes a lot of sense.
Makes a lot of sense? Please elaborate, because I never understood the
why by default the Go button is placed on the right.
Wladimir Palant
>> What should be foo in this case? Value of the onclick attribute?
>> Combination of all listeners for the "click" event? How about
>> "mousedown"? What about listeners using capture installed on a higher
>> level in DOM? And what if we have onclick="return true"?
>
> good point. perhaps we should simply indicate that there is in fact a
> javascript event handler for the link.
But you do realize that there is a huge number of different event
handler types/locations that could interfere? Even finding out that
there is some JavaScript that might change the link before you click it
is non-trivial.
Wladimir
Gervase Markham
> We don't necessarily have to find out what the javascript evaluates to,
> we could just display a javascript:foo url instead. As most of the time
> this is phishing or spoofing, I think it is important to not take this
> lightly.
The status bar display of URLs is not going to be a significant tool in
protecting users from phishing. 99.9% of users don't look at it, and of
those that do, most probably don't carefully parse the URL (as would be
necessary for a look-alike phishing URL).
Let's not decide this behaviour based on phishing concerns. We need to
handle those another way.
Gerv
Mossop
But the go button submits the contents of the URL bar. That makes sense.
The search icon doesn't, it changes the options of the search bar. If
anything is on the right that appears to drop down it should show the
search history.
Mossop
Ian Pottinger
> But the go button submits the contents of the URL bar. That makes sense.
> The search icon doesn't, it changes the options of the search bar. If
> anything is on the right that appears to drop down it should show the
> search history.
Thanks Mossop. That was both enlightening and convincing. I have to
admit that the form-submit metaphor escaped me till you mentioned it. I
wonder how many of my users also miss it and if they would better
perceive the function of the URL or Search bar Go buttons if they looked
more like their form-submit cousins - via colouring and/or button shape
perhaps. Hmmm.
Adam Kowalczyk
> But the go button submits the contents of the URL bar.
And so will the search icon, I think. It didn't make sense that the
Address Bar had a submitting button while the Search Bar didn't. Both of
them should either have it or not as they work in the same way.
However, if the search icon is not going to be a submitting button, then
I also don't see why it was moved to the right.
- Adam
Ian Hickson
>
> IMO, stop exists mostly to satisfy OCD. Given that the "Go" button would show
> "Stop" most of the time, except when the user is typing a new URI, I don't see
As a general UI design guideline -- don't make widgets change identity. A
button that's a "go" button should always be a "go" button, it shouldn't
change clothes and become a "reload" button just because it would
otherwise be disabled. I've seen multiple usability studies where that
kind of UI has confused users.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
scratch
I realize that, but it should certainly be possible, as well as useful.
-scratch
Mike Beltzner
>> .----------------------------------------------------------------------.
>> | File Edit View History Bookmarks Tools Help [_][=][x]|
>> |----------------------------------------------------------------------|
>> |.--. .--. .--. ,-------------------..--,,-, ,----------.---,, .i. |
>> ||<-| |->| |[]| ( {} www.foo.com v ||.)||=>) ( google G |.O |) -O- |
>
> This makes it look like there is no longer a title bar on the window, is
> that going to be the case?
No, the title bar will remain as per the target OS windowing standard. I
just forgot to draw that part of the ASCII art (I could lie and say that
since we don't draw it as part of chrome, I didn't mock it up, but I wont ;)
>> (4) Putting the search engine selector at the right (left for Mac) and
>> using grey text in the background was seen as a good idea.
>>
>
> This seems very strange. How often do you see the icon relating to
> something on it's right? Look at the bookmark toolbar. Look at the icons
> for menus. The start menu. All of them have icons on the left and I
> think the search bar should as well.
Again, I was being a little unclear here. The idea is to move the
drop-down button to the standard side for drop-down fields. The search
icon can still appear at the left.
Mike Beltzner
> As a general UI design guideline -- don't make widgets change identity. A
Indeed, nor should widgets be stateful. However, it occurs to me that
when the page is idle, "Go" is identical to "Reload" if the URL bar
hasn't been altered. In this case, the function is identical, but the
name of the function is being altered to better reflect the concept.
Mike Beltzner
> A question to all of you: have any of you actually tried coupling the
> stop and reload buttons in Firefox? I've used a CSS hack to show only
> the stop button when loading and the reload button when not. I've
> (power)used it for several weeks, and I never bumped into a problem. I
> don't think you have to be an advanced user to use such a
> context-specific button, after all, the icons are very clear.
The issue is that the function of the button is dependent on the state
of the page load, which means that there are very real states where a
user means to stop the loading of a page and actually triggers a reload,
which is the exact opposite of what they were trying to do. It's this
conflict between expected result and actual result that leads to the
poor usability reports that Ian was referring to.
(Also, fwiw, when I was using a WinCE device to browse the web, Mobile
IE used this paradigm and I found it extremely frustrating.)
Mossop
> Mossop wrote:
>>> .----------------------------------------------------------------------.
>>> | File Edit View History Bookmarks Tools Help [_][=][x]|
>>> |----------------------------------------------------------------------|
>>> |.--. .--. .--. ,-------------------..--,,-, ,----------.---,, .i. |
>>> ||<-| |->| |[]| ( {} www.foo.com v ||.)||=>) ( google G |.O |) -O- |
>>
>> This makes it look like there is no longer a title bar on the window,
>> is that going to be the case?
>
> No, the title bar will remain as per the target OS windowing standard. I
> just forgot to draw that part of the ASCII art (I could lie and say that
> since we don't draw it as part of chrome, I didn't mock it up, but I
> wont ;)
Yeah then I'd just counter with asking why you drew the maximise,
minimise and close buttons ;)
>>> (4) Putting the search engine selector at the right (left for Mac)
>>> and using grey text in the background was seen as a good idea.
How come Mac's are getting a difference here. All the screenshots I've
seen seem to suggest that drop down widgets on the Mac have their
buttons on the right the same as Windows and Linux.
>> This seems very strange. How often do you see the icon relating to
>> something on it's right? Look at the bookmark toolbar. Look at the
>> icons for menus. The start menu. All of them have icons on the left
>> and I think the search bar should as well.
>
> Again, I was being a little unclear here. The idea is to move the
> drop-down button to the standard side for drop-down fields. The search
> icon can still appear at the left.
So let me get this straight. Search engine icon on the left. Drop down
arrow on the right. The drop down arrow selects the search engine
(changing the icon on the left), totally opposed to the drop down on the
url bar which shows recently typed items? Also that reduces the amount
of space for text in the search bar.
Me no likey.
Mossop
Adam Kowalczyk
>>> (4) Putting the search engine selector at the right (left for Mac)
>>> and using grey text in the background was seen as a good idea.
>>>
>>
>> This seems very strange. How often do you see the icon relating to
>> something on it's right? Look at the bookmark toolbar. Look at the
>> icons for menus. The start menu. All of them have icons on the left
>> and I think the search bar should as well.
>
> Again, I was being a little unclear here. The idea is to move the
> drop-down button to the standard side for drop-down fields. The search
> icon can still appear at the left.
This preserves an inconsistency that I never understood. Why does the
Address Bar have a Go button to submit its contents and the Search Bar
does not? They work in the same way and it seems either both of them
should have a button or neither. Is there any particular reason for this
difference that I am missing?
Look at how IE7 does it - a button on the right with an attached
dropdown. If this button had a search engine icon (which it hasn't in
IE7) it would really work quite intuitively: click on the Google icon to
search using Google. If user picks a search engine from a dropdown, it
is more natural for it to be attached to the engine icon rather than to
be on the opposite side of the input field.
- Adam
fantasai
>
> (7) Moving the "Home" button to the Bookmark Toolbar was contentious,
> and users should be allowed to move it back to the main toolbar.
I remember mpt constantly arguing that the Home button should be moved to
the Navigation Toolbar back when NS had it in the Bookmark Toolbar. I think
Pascal's points about the advantages of keeping it there are quite practical.
Are there other arguments for moving it again, other than the extra 40px of
space in the Navigation Toolbar?
~fantasai
Mike Beltzner
That feeling might be wrong, but that's what alphas and betas are for. If it turns out to be a bad idea, we'll back it out. Regardless, the ability to move it to the bookmark toolbar seems like an easy win, so let's give it a shot!
cheers,
mike
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
barti...@gmail.com
I see a very major problem with this. "Go" and "Refresh" are not the
same thing. Very often I will modify a URL and change my mind and
decide to refresh the current page instead. With your suggestion, if I
so much as touch the URL field, I will no longer be able to reload the
page I'm currently on and I won't be able to refresh to see the current
page's URL again.
> Page is loading == button is "Go"
This is also confusing. If the page is still loading, "Go" doesn't make
sense because I'm already on the page, so why would I click "Go" to go
to something I'm already on? Instead I want to "Refresh" what's already
there, and have it restart the loading process.
I agree with someone else that this change is simply change for the
sake of change. Refresh is an important part of the user experience and
in my opinion, it's not a function that should be messed with.
Furthermore, most people I know simply press Enter to go to a URL, so
the Go button itself is really useless (I always remove it the first
change I get). Combining a useless button with any of the useful
buttons in the UI will not automagically make it more useful and it'll
just decrease the utility of the other button (as would be the case
with Go/Refresh).
- Bart
ehume
contents and the Search Bar does not? They work in the same way and it
seems either both of them should have a button or neither."
A personal UI note:
I use the Search Button extension to give me a Search Button. I keep it
to the right of the searchbar, as God intended ;-). As a side benefit,
when you right-click on the button, you can select your search engine;
but I use the left-sided search engine button's dropdown instead. It
makes sense: moving from left to right: select engine, enter text to be
the object of the search, then Go.
Although Customize Toolbar gives me the option of removing the Go
button, I leave it at the right of the URL bar.
These placements seem intuitively right to me. They track my reading
direction, so with a RTL language, we might wish to consider opposite
placements. YMMV, of course.
I agree with Hickson on separate buttons that maintain their identity,
regardless of state. I recall my father -- a brilliant engineer --
having enormous difficulty years ago with VCR buttons that changed
function depending on what mode the machine was in.
For users who really want to conserve space, there are extensions that
can allow them to merge the functions of whatever buttons they choose,
which would let them all have their layouts exactly as they like them
to be.
ehume
you are using a theme that allows it to expand.
ehume
AiO properly tweaked, so you can browse without having to lean forward
and get to the keyboard. In such a circumstance, you need that button.
Chris Ilias
> The useless Go button is useful when you are leaned back in your chair,
> AiO properly tweaked, so you can browse without having to lean forward
> and get to the keyboard. In such a circumstance, you need that button.
Then get rid of the toolbar button, and implement "Paste and Go" in the
location bar context menu.
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)
Chris Ilias
> Then get rid of the toolbar button, and implement "Paste and Go" in the
> location bar context menu.
On second thought, that's a bad idea. Sometimes people receive broken
URLs, and need to paste it in the location bar, piece by piece.
How about adding 'Go' to the location bar context menu?
sebasti...@gmail.com
i think NOT hiding the status bar is the best decision during the
design process. it's absolutely necessary for knowing which link i'm
going to click on.
I also think that incorporating an indicator, if it's opened in a new
tab or window. but, making this a text indicator means that I always
have to find where the url starts. something that is always the same,
would be better. how about an icon, similar to the
new-tab/new-window-icons for the toolbar?
also, the tab bar should always be visible, and a new-tab-button should
be there somewhere. i know of many people, that use firefox for months
but don't realize that it has tab-support. something like the
ie7-new-tab-button woul be great, i think.
I hope that my comments can change something :)
(and sorry for my bad english :))
Sebastian
Wolfgang Rosenauer
maybe I missed some post but I want to suggest one more UI feature for FF2:
I miss the possibilty to purge the contents of the url-bar, search-bar
and "google-bar".
At least for cut and paste actions it would be nice to have that.
Thunderbird has it for the integrated search bar (more for another
reason but still).
The problem is that you have sometimes something in your x-selection
(clipboard?) and you can't easily remove the content from where you want
to put it.
Any chance for a purge button inside those fields?
Wolfgang
ge.d...@gmail.com
first of all, i have to say that i joined just today in this
newsgroup... I think Mike's job has been pretty amazing. Congrats!
I hope it is not too late for some comments on the FX2 UI, i have put
them all together on my wiki user page:
http://wiki.mozilla.org/User:Ge.diego
Thanks!
Ge.diego