1262843 - Evaluate allowing users/addons to define a custom awesomebar results layout

Status: RESOLVED DUPLICATE of bug 1361327

(Firefox :: Address Bar, defect, P3)

Description

[Luís Miguel [:quicksaver] (not reading bugmail)]

Continuing the discussion from bug 1262777 in a more appropriate place.

(In reply to Marco Bonardo [::mak] from bug 1262777 comment #6)
> I don't think it's a new problem.
> Before we had all information packed to the left, while now it flows on a
> single line, taking on avg double the space. By enlarging the panel to the
> whole window on avg we enlarged it less than double. So potentially, we may
> now have less empty space.
> If I take into account a modern 21:9 screen, I'd say the empty space
> situation was not really better before.

Even though aspect ratio seems to trend to increase, it's the overall size pizel-wise that worries me. Even though screens are larger, they don't necessarily hold up more information if they don't have the pixels for it. As far as I know, 1366x766 is still one of the most common resolutions for laptops; and larger resolution screens typically have a zoom factor enabled, so the difference there is minimized as well.

From my personal experience with almost everyone I've seen using chrome (which let's face it is almost everyone), they don't really use its location bar other than to type an address directly or to search for exactly what they type, because the information in its suggestions is not easy to follow. Firefox's has been the exact opposite, because all the info in an item (title and url) was just there in almost the same place.

I see the new suggestions as (possibly!) going in an unfavorable trajectory. I personally dislike a one-line style and preferred the previous two-line style because now I have to physically move my eyes and look for the url (it never starts in the same place, since it depends on the title), and it's easy to lose track of where you are like that: "that's not it, go back to title. Wait, what line was I on?".; <-- huge break in workflow!

Even though I can understand the intention of "cramming up" more information in there, it's just not as easily accessible and will thus IMO be less useful.

Although I can't argue with Marco's words in bug 1262777 comment 4, it's a big change and a small test run to see how it does "out there" can't hurt.

(That's the only detail I disagree with, the rest of the style revamp seems to fall in line with the objectives IMHO.)

Comment 1

[Luís Miguel [:quicksaver] (not reading bugmail)]

Stephen, I assume this has been considered when coming up with the new design (it's probably too big of a point not to have been considered before). Can I ask you for the cliffnotes on it?

Comment 2

[Marco Bonardo [:mak]]

FWIW, this should have been posted to firefox-dev since bugzilla is not a discussion forum. Don't get me wrong, I'm not trying to stop the discussion and I have a great respect for you. Just I don't think it's the right place.

Comment 3

[Luís Miguel [:quicksaver] (not reading bugmail)]

Good point. ;)

Comment 4

[Albert Scheiner [:alberts]]

+1 while it's still around.
Having the URLs not aligned anymore is highly irritating for any front end dev work where I have to check the same page on different environments. Same title -> different URLs, therefore I am only scanning the URLs

Comment 5

[blauggaumme]

An option to configure this like it was before would be very useful. including more information isn't useful if it's less accessible

Comment 6

[Marco Bonardo [:mak]]

I think in general it would be great if the results layout would be customizable, somehow (either add-ons or a pref, or such).

Fwiw, for now it may be possible to do through css, that I guess may be what Classic Theme Restorer does.

Comment 7

[blauggaumme]

How about an about:config entry (browser.urlbar.resultsFormat), defaulting to:
{star}|{icon}|@{title}( — {action})

This is just an example syntax; explanation:
 - bracketed items (e.g. "{title}") are references
 - pipe character ("|") is a column separator
 - "at" character ("@") indicates the start of what's supposed to align with the location bar
 - parenthesis ("()") indicate that what's contained within should be conditionally displayed (based upon whether the bracketed reference within has a value (because search suggestions do not have an action))
 - newline ("\n") indicates the start of a new line / row for the result
 - everything else (e.g. " — ") is a literal string
 - to specify e.g. literal parenthesis ("()"), user would escape as "\(\)"

Using this syntax, a user would be able to reproduce the "classic" format as follows:
{icon}|@{title}|{star}(\n|{action}|)

Comment 8

[blauggaumme]

Alternatively, instead of treating "\n" as a marker for a new row, it could be treated as a line break within a column. The "classic" format would then be set as follows:
{icon}|@{title}(\n{action})|{star}