1292351 - Contrasting awesomebar alignment, huge white spaces, duplicated features

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

Attachment: notawesomealign.png

For context, see attached screenshot.

1) The awesomebar covers the entire screen width, yet the content is aligned with the edit box. This causes a huge screen wastage/whitespace area on the left. This is a longstanding bug that doesn't seem to get attention.

2) In addition to that, the new search engine selection *IS* aligned to the left, making it both look very awkward with the above, and causing huge whitespace to the right.

3) The functionality to select a search engine on the fly is already present in the search box, which is what I use when I want to use a search engine. Duplicating this functionality is into the awesomebar, used to search bookmarks and history *locally* is pointless and just makes the awesomebar look more cluttered for zero benefit. Would the UX team please consider removing this useless clutter when the user has a search box enabled?

Comment 1

[Marco Bonardo [:mak]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #0)
> 1) The awesomebar covers the entire screen width, yet the content is aligned
> with the edit box. This causes a huge screen wastage/whitespace area on the
> left. This is a longstanding bug that doesn't seem to get attention.

Why do you think it's a bug?
It's actually done on purpose, so even if the user has a lots of icons on the toolbar, a very small window, or a small screen device, entries are still usable.
The fact is expands on the left is just cause it would look very bad to only expand to the right.
Other browsers are doing similar things for likely similar reasons.

> 2) In addition to that, the new search engine selection *IS* aligned to the
> left, making it both look very awkward with the above, and causing huge
> whitespace to the right.

It's the same as in the searchbar, you may have a lot of engines too.

> 3) The functionality to select a search engine on the fly is already present
> in the search box, which is what I use when I want to use a search engine.

We are indeed trying to make all the search points consistent, where by search points as of now we mean awesomebar/searchbar/newtab/abouthome.

> Duplicating this functionality is into the awesomebar, used to search
> bookmarks and history *locally* is pointless and just makes the awesomebar
> look more cluttered for zero benefit.

Why do you say zero benefits? It allows the user to use the awesomebar to search in a more complete way. it allows (if wanted) to customize away the search bar, it makes all search points consistent.
While I can figure you may not like it, I'm not sure why you think it will bring zero benefits to the other users. (Personally I just removed the search bar, thanks to this).

Comment 2

[Marco Bonardo [:mak]]

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #1)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #0)
> > 1) The awesomebar covers the entire screen width, yet the content is aligned
> > with the edit box. This causes a huge screen wastage/whitespace area on the
> > left. This is a longstanding bug that doesn't seem to get attention.

Also, the customizations where there are buttons on the left of the urlbar are less common.
In the normal case only the back/forward buttons are there.
But not aligning if you have one or 2 toolbarbuttons there, would make things worse than some empty space

Comment 3

[Marco Bonardo [:mak]]

As Florian just pointed out, If you untick all search engines in search preferences, we hide the one-click engines area.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #1)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #0)
> > 1) The awesomebar covers the entire screen width, yet the content is aligned
> > with the edit box. This causes a huge screen wastage/whitespace area on the
> > left. This is a longstanding bug that doesn't seem to get attention.
> 
> Why do you think it's a bug?

Because it looks terrible due to broken alignments (see screenshot), and is functionally bad because it obscures a part of the webpage for no reason whatsoever.

> It's actually done on purpose, so even if the user has a lots of icons on
> the toolbar, a very small window, or a small screen device, entries are
> still usable.

If there are icons on the left, it has the opposite effect. Expanding to the right sounds fine, this is not an unusual paradigm for text that is left-aligned. Think about using a spreadsheet and entering a long text in a cell.

> The fact is expands on the left is just cause it would look very bad to only
> expand to the right.

I'm not convinced at all here. Is that a conclusion from trying this out, or are you guessing?

> Other browsers are doing similar things for likely similar reasons.

Yes, Chrome has the same bug, but there one cares less because the local history search is very limited in functionality anyway. You also cannot change the layout of that navigational area, unlike Firefox. 

It's not good to draw analogies to it, because this is a poor area of Chrome, so parity would be an extremely bad outcome for Firefox.

> > 2) In addition to that, the new search engine selection *IS* aligned to the
> > left, making it both look very awkward with the above, and causing huge
> > whitespace to the right.
> 
> It's the same as in the searchbar, you may have a lot of engines too.

The difference is that the alignment difference in the Search Bar is at most a single icon, and in fact the spacing on the search engine icons is big enough so that they end up slightly to the right of that.

So it's not the same at all, it's the complete opposite.

> > 3) The functionality to select a search engine on the fly is already present
> > in the search box, which is what I use when I want to use a search engine.
> 
> We are indeed trying to make all the search points consistent, where by
> search points as of now we mean awesomebar/searchbar/newtab/abouthome.

So what's the point of having the search bar then? You'll end up with two UI parts next to each other that are functionally almost equivalent.

> > Duplicating this functionality is into the awesomebar, used to search
> > bookmarks and history *locally* is pointless and just makes the awesomebar
> > look more cluttered for zero benefit.
> 
> Why do you say zero benefits? It allows the user to use the awesomebar to
> search in a more complete way. 

But that functionality *already is* in the SearchBar so it's just adding clutter to the Awesombar.

>(Personally I just removed the search bar, thanks to this).

That's a large point of my complaint: you are duplicating the functionality of two distinct UI items, thereby making one obsolete. This is slightly helpful if you don't care for the distinction between local search and sending a query to the search provider, but it's becoming quite cumbersome if you do.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #2)
> Also, the customizations where there are buttons on the left of the urlbar
> are less common.
> In the normal case only the back/forward buttons are there.

That's probably because of long-standing Australis bugs like 974389.

> But not aligning if you have one or 2 toolbarbuttons there, would make
> things worse than some empty space

You should align, I never argued the opposite.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #3)
> As Florian just pointed out, If you untick all search engines in search
> preferences, we hide the one-click engines area.

This also hides them from the Search Bar, so it doesn't help.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

>Personally I just removed the search bar, thanks to this.

Would it make sense to file a separate bug to discuss removing/uncluttering search functionality in the Awesomebar if the Search Bar is still present?

Or is the Search Bar (and hence the separation of local and remote search) effectively dead?

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

gcp, we are experimenting in this area and proceeding with caution and after collecting user data, but unifying the behavior of all of our search entry points is the direction we are heading towards. That means that the way you search in the search bar should be the same as in the way you search in the about:home search box, the about:newtab search box and the awesomebar. 

I am going to wontfix this bug as it just argues against our intended design without any new data that haven't already been considered. I think we already have a bug on file to improve the information density for the small minority of users with many icons on the left of the awesomebar, but I can't find it at the moment.