move star button to the left end (ltr) of the location bar

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
9 years ago
8 years ago

People

(Reporter: fryn, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
See bug 578025 for mockup.
from bug 578929:

> Note that Chrome, which likely inspired us here, recently moved the star to
> right for consistency:
> 
> "The bookmark star icon has joined the other “page actions” at the right-hand
> side of the Omnibox",
> http://blog.chromium.org/2010/06/fresh-coat-of-chrome.html

Comment 2

9 years ago
Is there a detailed reasoning for the move? (I can't find one, though there's a lot of discussions) If we're going to have the big domain button I'd personally rather keep the star where it is so it stands out more.

Also, moving it to the left and also removing the favicon sorta makes the star look like the favicon, at least at first glance and probably to many who would be used to the old setup. (i.e. we'll definitely get some users filing bugs and support reports about having a star icon of some kind for every site)
(In reply to comment #1)
> > Note that Chrome, which likely inspired us here, recently moved the star to
> > right for consistency

Yes, they are also trying to balance out the URL bar with one icon on each end, but have chosen a different approach and show the globe or search icon on the left to indicate how the input is interpreted. We don't see that Firefox needs an icon like that, and the two operations that relate to the URL (reload and bookmark) are placed inside the URL container.

(In reply to comment #2)
> Is there a detailed reasoning for the move?

The short version is that putting the star and the reload button right next to each other makes it easy to click the wrong button. Ideally, we'd like to get rid of the pulldown on the right side too, but as this is not actually doing an action that can't be easily reverted, we're keeping it for now, pending more data from Test Pilot on how (or if) it's actually being used.

The other option would be to put the star on the right and reload on the left, but we chose to have reload at the end of the URL bar instead. There's no right or wrong in this particular case (both are equally useful, and indeed Chrome does the opposite in their dev channel in the article Dão linked, although they keep reload on the main toolbar).

> Also, moving it to the left and also removing the favicon sorta makes the star
> look like the favicon, at least at first glance and probably to many who would
> be used to the old setup. (i.e. we'll definitely get some users filing bugs and
> support reports about having a star icon of some kind for every site)

We're trying to reduce redundancy in the UI, and having the favicon in two locations definitely contributes noise and redundancy. We chose to have the favicon on the tabs, since it's a strong indicator in navigating sites and tabs — so in many ways the opposite of what Safari does here (it's hard for them to consolidate the close button on the left with a favicon, so they leave it out altogether — making it very hard to identify tabs).

Comment 4

9 years ago
(In reply to comment #3)
> The short version is that putting the star and the reload button right next to
> each other makes it easy to click the wrong button.

I understand the point, but this is essentially a reason to not have any two buttons next to eachother. Is this a particularly highly reported/measured problem? (more so than any other two buttons?)

> Ideally, we'd like to get
> rid of the pulldown on the right side too, but as this is not actually doing an
> action that can't be easily reverted, we're keeping it for now, pending more
> data from Test Pilot on how (or if) it's actually being used.

If the dropdown arrow stays (and it does get used, at least to some degree), then the star is not directly next to the reload button and the above argument doesn't apply. I should also point out that the staring can be easily reverted with two clicks.

> The other option would be to put the star on the right and reload on the left,
> but we chose to have reload at the end of the URL bar instead.

The right side makes the most sense as a replacement for the go arrow.

> > Also, moving it to the left and also removing the favicon sorta makes the star
> > look like the favicon, at least at first glance and probably to many who would
> > be used to the old setup. (i.e. we'll definitely get some users filing bugs and
> > support reports about having a star icon of some kind for every site)
> 
> We're trying to reduce redundancy in the UI, and having the favicon in two
> locations definitely contributes noise and redundancy.

I agree with the favicon removal. I'm just saying that doing this with that has a potential site effect.

Users are used to the current star placement and assuming the feed button isn't (oddly) removed then it makes sense to keep the two together as they're both used to remember the location. I guess it could be moved to the left too, but it's not always shown so you'd have to grey it out or something to maintain spacing with the domain button. The right side makes the most sense now and as of yet I'm just saying that I don't see much of a reason to move it.
(In reply to comment #4)
> The right side makes the most sense now and as
> of yet I'm just saying that I don't see much of a reason to move it.

Since the feed button is going away, it makes sense to have the buttons on opposing sides of the URL bar. It's fine for you to disagree with this, but I can't see any other compelling argument (except for "don't change it"), so I guess we'll have to agree to disagree. :)

Comment 6

9 years ago
(In reply to comment #5)
> I can't see any other compelling argument (except for "don't change it")

"don't change it" is always the default position in any argument, otherwise logically everything everywhere would be subject to arbitrary change. ;)

If both the feed button and dropdown arrow are removed then I'd begin agree with your argument about potential accidental clicks. (one is in the mockups and the other is not)

I think the complaint of having the star cramped by the domain button could be mitigated if the styling of the domain button was less bold. The mockups have a big dark button that really draws your focus and dominates the GUI. Yes, to some degree that's the point, but the little bit of light background with the star on its left feels off. (if that made any sense)
The feed button is just the built-in example; extensions commonly add bookmark-y items next to the star.
Depends on: 578967

Comment 8

9 years ago
By the way, the title notes LTR. Was the plan to have it on the right in RTL? The address bar is not flipped in RTL because addresses are themselves LTR so I would think that any placement would be the same for both directions.
(Reporter)

Comment 9

9 years ago
I have a patch that does this, but we may decide not to do this, so I'm holding off on posting it.

Meanwhile, unassigning myself.
Assignee: fyan → nobody
Status: ASSIGNED → NEW
(Reporter)

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
So, normally we want to have reasoning for WONTFIXing something when we WONTFIX it...

Comment 11

9 years ago
And this wontfix why?
(Reporter)

Comment 12

9 years ago
(In reply to comment #10)
> So, normally we want to have reasoning for WONTFIXing something when we WONTFIX it...

Our current plan is to expand the site identity box to include the protocol (at least when not http) and host (and EV when applicable) and to add multiple icon indicators for account manager, authentication, and geolocation to the left of the site identity box, so it makes more sense to leave the star button on the right to avoid more clutter.
Another mockup feature falled. I wonder how many time I will see this before FX4 hits RC...

Comment 14

9 years ago
(In reply to comment #13)
> Another mockup feature falled. I wonder how many time I will see this before
> FX4 hits RC...

Well, there have been a lot of ideas thrown around, with a lot of varying mockups to go with them. Necessarily, some are going to be not used and some new ones will also come up along the way. ;)
(Reporter)

Updated

9 years ago
No longer blocks: 578025
No longer depends on: 578967

Comment 15

8 years ago
Instead of removing the Feed button from the location bar (bug 578967), we can do this:

By locating the Feed button to the right of the location bar the Feed button 
will result itself inside the location bar? (similarly to the Reload/Stop buttons)

Realization:
(1) Customize Toolbar mode (both of the images are the same)
http://c25.img-up.net/?up=FF_RSS_01zwysu.png
http://x66.img-up.net/?up=FF_RSS_024yqta.png

(2) Result: http://q37.img-up.net/?up=FF_RSS_03zjh0q.png


See: https://bugzilla.mozilla.org/show_bug.cgi?id=578929#c21

Comment 16

8 years ago
(In reply to Khazar from comment #15)
The feed button has /long/ since been removed from the location bar. We lost that debate, though I'm not really to broken up about it. This proposal not only has nothing to do with that, but it was also turned down a while ago. If you're proposing a method to allow customizing the location bar to put the plain feed toolbar button in it, that would be another bug entirely, though I don't suggest you file one for it as it's almost certainly not going to be implemented. For those who want this there are addons.

Comment 17

8 years ago
(In reply to Dave Garrett from comment #16)
> (In reply to Khazar from comment #15)

> but it was also turned down a while ago.
When and where? (any link?)

> We lost that debate
A. I thought that the Mozilla staff were smart enough to realize that when they released FF5 (so I let up), but, as it turns out, they were not.
B. We have not lost yet.
C. Lost = Mozilla will not get anything from me:
C (1) Not my voice. I'm on the verge of ditching Firefox (I have made almost 20 alternatives (mostly with Privoxy) to Extensions and Scripts that I used to use and now only one is left, which is CWWB Cookie Manager)
C (2) Not my money, and I have donated money and time at the early past of Firebird/Mozilla. And I know that they have more than enough funds, but my voice is still matter, as every voice is.
C (3) I have erased every of the default search engines - no benefits from this aspect.

Comment 18

8 years ago
realize that = to do the suggestion written comment #15

And I'm also still reviewing bug 578967, I have plenty to write in this issue ;-)

Comment 19

8 years ago
(In reply to Khazar from comment #17)
> (In reply to Dave Garrett from comment #16)
> > but it was also turned down a while ago.
> When and where? (any link?)

Um, please read this report and all its comments. It was marked WONTFIX on 2010-08-06 and the rationale is listed in comment 12. This report here has nothing to do with what you're talking about (bug 578967).

Khazar, this is not a forum. Please don't post comments in long since obsolete bugs like this one, or even bug 578967. Please also understand that you're well over a year late to even discuss this long since settled topic, regardless if you like the outcome.

Comment 20

8 years ago
I disagree with you. Do you recall: Outlook’s broken—Let’s fix it <http://fixoutlook.org/>?
It might be happening with the Feed removal issue.

I'm keeping on reading the bug 578967 thread over and over.
I'm very impressed from you outstandingly excellent comments. Well done!
I'm outraged.
You need to log in before you can comment on or make changes to this bug.