Closed Bug 1389484 Opened 7 years ago Closed 7 years ago

Issue wrt use of space around the location and search bars

Categories

(Firefox :: Toolbars and Customization, defect)

57 Branch
defect
Not set
major

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 - affected

People

(Reporter: RyanVM, Unassigned)

References

Details

(4 keywords)

Attachments

(3 files)

Attached image screenshot
[Tracking Requested - why for this release]: Visible UI regression

See attachment. Regression from bug 1383009.
Flags: needinfo?(gijskruitbosch+bugs)
And yes, I can customize and drag it off. But still, that's a *lot* of dead space.
You can also right click and remove the space, you don't need to go into customize mode.

The size of the spacing is, as far as I can tell, correct according to the design. I have no strong opinions on whether this is a good idea, maybe Stephen and Bryan can clarify.
Flags: needinfo?(shorlander)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(bbell)
FWIW my initial reaction was to assume that something was broken in nightly because it looked so odd. But maybe that isn't how people getting a stable upgrade will react.
(In reply to James Graham [:jgraham] from comment #3)
> FWIW my initial reaction was to assume that something was broken in nightly
> because it looked so odd.

Yeah, I thought it was a visual regression, and filed a dupe of this.

On a 15" machine there's enough room on either side for the entire set of toolbar buttons to appear twice over, while the contents of the location bar are truncated.

This is particularly problematic when you consider how much stuff we're cramming inside the location bar:

- The info button
- A padlock
- The signature authority
- The URL
- Page action menu (…)
- Bookmark star
- Pocket icon
- Container name
- Container icon

(And see Bug 1389563 for another spacing issue which, when fixed, will cramp the contents of the location bar still further.)

For illustration, if I size this window down to 1024x768, I can see "htt" in the URL bar.

It also feels a bit weird that the left offset of the location bar varies with window size.
Attached image 1024
See Also: → 1389505
The spacers are working as intended. The right thing to do with Spacers on smaller windows is to minimize their width to almost nothing as the window reduces in size.  Bug 1389505 mainly covers this.
Flags: needinfo?(shorlander)
Flags: needinfo?(bbell)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Attached image lots of space
I got some redundant space between tab and close button, it can't remove by custom mode.
(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #11)
> Created attachment 8896893 [details]
> lots of space
> 
> I got some redundant space between tab and close button, it can't remove by
> custom mode.

That is bug 1389104.
This shouldn't be a WONTFIX... It's certainly unsightly and cause the user to question on why that looks that way.

Having to make the user go into custom and adjust things that looked just fine before, is IMHO not an appropriate solution.

Even with a rather large window (on a 27" inch) there's a 4cm gap on both left and right of the URL bar.

Why are those spacers there to start with?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Jean-Yves Avenard [:jya] from comment #14)
> This shouldn't be a WONTFIX... It's certainly unsightly and cause the user
> to question on why that looks that way.

UX explicitly confirmed (comment #7) that it looks the way it's intended to look. Just saying [you think] it's "unsightly" isn't a good reason to reopen a bug. The bug gets reopened if the people who own this decision (which is ultimately the UI/UX folks who design Firefox) agree we should revisit it, and so far that is clearly not the case.

> Having to make the user go into custom and adjust things that looked just
> fine before, is IMHO not an appropriate solution.
> 
> Even with a rather large window (on a 27" inch) there's a 4cm gap on both
> left and right of the URL bar.

We're still tweaking the size of the spacers, see bug 1389505 and deps.

> Why are those spacers there to start with?

Just like with any other design decision, bugzilla is really not a good place to have these discussions. Use a mailing list or slack if you continue to have concerns.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WONTFIX
(In reply to :Gijs from comment #15)
> (In reply to Jean-Yves Avenard [:jya] from comment #14)

> Just like with any other design decision, bugzilla is really not a good
> place to have these discussions. Use a mailing list or slack if you continue
> to have concerns.

I disagree.
Bugzilla is the most convenient place to have a complete picture of the design process and how a change came upon.
In a year time, no one will now where to look in a mailing list, but bugzilla will always be there, quickly available.
(I won't talk about Slack as it may comes the way of Yammer)

When you see how many bugs have been opened in this exact topic, by people extremely familiar with Firefox, it's not hard to imagine the reaction of a plain user when this change comes to release.

If you think that 4cm gaps on either side of the URL bar (regardless of the size of the window) is okay by design.... well, I guess things stop here.
Based on the reaction from these bug reports, is it worth to create a A/B test or telemetry to see how many people removed the spacer with customization?
(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #17)
> Based on the reaction from these bug reports, is it worth to create a A/B
> test or telemetry to see how many people removed the spacer with
> customization?

By removing the search field it looks better to me, and it seems that's also photon's plan. So if we're going to collect user feedbacks, I think it would be better when after all photon stuffs are done. Minor look & feel difference may change people's mind.
Is there any sort of rationale why we would waste a bunch of space like this? It just seems pointless to me. It also wasn't clear at all to me how to get rid of this space until I read through this bug. I kept trying to drag around the ends of the location and search bars (similar to how you can adjust the division between these bars), but that doesn't work.
Severity: normal → major
Has Regression Range: --- → yes
Has STR: --- → yes
OS: Unspecified → All
Hardware: Unspecified → All
Summary: Tons of dead space around the location and search bars → Tons of useless dead space around the location and search bars
Version: Trunk → 57 Branch
I'm glad you're all invested in the resolution of this bug, but I'm very confident that if a new contributor filed a bug demanding the rationale for all the wasted useless dead space involved in a UX change, I'd be getting asked to reel that contributor in directly.
Summary: Tons of useless dead space around the location and search bars → Issue wrt use of space around the location and search bars
(In reply to Mike Hoye [:mhoye] from comment #21)
> I'm glad you're all invested in the resolution of this bug, but I'm very
> confident that if a new contributor filed a bug demanding the rationale for
> all the wasted useless dead space involved in a UX change, I'd be getting
> asked to reel that contributor in directly.

Is there any recourse here, Mike? I'd be happy to start a mailing list thread, but I'm pretty sure that will turn into a disaster pretty quickly.

I think this goes beyond an appearance issue. It looks broken. I think that's why there have been so many dupes here, especially from people who don't normally file bugs about appearance issues.
FWIW Safari also has huge spacers (larger than Nightly) and they've been shipping that for years without anybody thinking it's broken. It just takes some getting used to.
> Is there any recourse here, Mike?

File the bugs, trust your colleagues. That's it.

Look, there's no part of this project that's easier to "why don't you just", but UX design as a field is not form-element lego for failed graphic artists. It's a real, high-stakes discipline with its own set of principles and practices, its own history and its own set of subtle and pernicious design and implementation problems that aren't easy to understand or simple to solve. 

We have an entire team of people here working on it, smart people with extensive domain expertise and a deep understanding of the problem space they're working in, who've been in those trenches for a long time, and who I promise are as good at their jobs and as invested in the success of the project as you or anyone else here is at theirs. 

File the bugs, trust your colleagues. We're pretty much out of time for anything else.
(In reply to Samael Wang [:freesamael] from comment #18)
> By removing the search field it looks better to me, and it seems that's also
> photon's plan. 

That's going to get some "interesting" feedback as well, I bet. In the context of Mike's response, the presence of a separate search box is more than just an UX issue. It has significant in product differentiation on the privacy level, which is why...

>Safari also has

...honestly isn't a very good argument ;-)
How we handle search is a product and ideological differentiator, it has a set of complicated, subtle impacts on real and user-perceived user-safety and user-privacy, it even has a direct impact on Mozilla's revenue, and there are exactly zero people on the UX team who aren't aware of all of this. None. File the bugs, trust your colleagues.
Comments in this bug are now restricted to editbugs-group only. This issue has been resolved, and Bugzilla is not the right forum for post-facto disagrements.
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: