Open Bug 1407972 Opened 7 years ago Updated 8 months ago

[ux] Improve customization experience by allowing URL bar items (page actions and others) to be managed from within customize mode

Categories

(Firefox :: Toolbars and Customization, defect, P3)

57 Branch
defect

Tracking

()

Tracking Status
firefox57 --- wontfix

People

(Reporter: martijn, Unassigned)

References

Details

(Keywords: blocked-ux, Whiteboard: [reserve-photon-structure] [ux])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

I tried customise, and there are some buttons in the address, so I thought these buttons are customisable as well.


Actual results:

I cannot use Customise to customise the buttons *inside* the address bar. I can remove them outside of Customise, but I cannot drag buttons into it.


Expected results:

I would expect Customise to allow more customisations, including the buttons *inside* the address bar. I would like the Reload button to sit there, for example. And also the Pinboard extension that currently adds a button *next to* the address bar, I would like to move that to inside the address bar.

I don't see what that specific part of the UI needs a different UX to be customised :(
Component: Untriaged → Toolbars and Customization
Aaron, Bryan, I expect that this will be a WONTFIX, but I'm not able to provide the complete rationale as to why the urlbar won't be a full-blown customization area/ target.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bbell)
Flags: needinfo?(abenson)
Summary: Place buttons inside address bar → Allow placing any widget inside address bar
Whiteboard: [photon-structure][triage]
The address bar button area is basically a button bar just like the areas left and right of the address bar.

In a different ticket (1407973) I read something about consistent UI. But this is not consistent.
We intend to make the customization experience better and have discussed having the ability to manage URL bar tools from within customize mode but we don't have any specs for that yet. The title of the bug is a little misleading because I don't know that we'll allow folks to add *any* tool to the URL bar because items that go in the URL bar should provide utility for that page. For example, it wouldn't make sense to put the Home button in the URL bar. The suggestions mentioned in the description are definitely worth considering, though. 

I'll retitle this to something more appropriate and tag it with UX like we did at the beginning of Photon for Bryan and I to track.
Flags: needinfo?(bbell)
Flags: needinfo?(abenson)
Summary: Allow placing any widget inside address bar → [ux] Improve customization experience by allowing URL bar items to be managed from within customize mode
Hey Aaron, can you set a priority on this bug (using the Priority dropdown)?
Flags: needinfo?(abenson)
"because items that go in the URL bar should provide utility for that page"

That would be up to the user to decide.
Flags: qe-verify-
Priority: -- → P3
Whiteboard: [photon-structure][triage] → [reserve-photon-structure] [ux]
Added as high priority reserve work.
Flags: needinfo?(abenson)
And the wontfix is... why exactly?
(In reply to Martijn from comment #8)
> And the wontfix is... why exactly?

Wontfix *for 57* because the last beta is today, and there's no design, never mind an implementation, plus we might need additional strings (which we don't add in beta, only on nightly). I'm marking that explicitly to get it off triage radars for late-breaking critical issues for 57 like crashes, data loss, significantly broken core functionality, etc.
Bryan, is there a design for how this "should" work?
Flags: needinfo?(bbell)
No, I'm actually working on this and hope to have some things to review by the all-hands.
Flags: needinfo?(bbell)
Since I wound up posting it in a duplicate of this bug (this didn't turn up because I was searching for "page actions" rather than "URL bar items"), here's a slightly more considered form of the idea I posted there, to spark discussion and brainstorming:

1. When in Customize mode, have all of the URL bar items visible as if "Add to Address Bar" had been chosen for all of them. They can then be drag-and-drop reordered and that will change the order of the things visible in both the address bar and the overflow menu without affecting which subset of them is pinned to the address bar.

(This avoids the need to find space to show an expanded overflow menu in the customize view and would be consistent with the current browser action UX of "you can have only one copy of each" behaviour that would otherwise be violated by the current page action UX of duplicating all pinned page actions in the overflow menu.)

2. Since it's acceptable for the downloads button to have an "Auto Hide" option hidden in a right-click popup, extend this design so each page action has a right-click menu that allows users to choose between "Pin to Address Bar", "Overflow Only", or "Hidden" for each page action... thus allowing things like "Email Link" to be hidden from the overflow menu if the end-user has no use for them. (Or if an addon author neglects to provide an option to hide the ones they provide after providing a more desirable alternative form of interaction.)

(Or just allow users to freely overrule the page/browser action distinction and I won't need to use extensions just to put the RSS and Reload icons back in the address bar which I firmly believe to be the correct semantic context for them.)

(In reply to Martijn from comment #5)
> "because items that go in the URL bar should provide utility for that page"
> 
> That would be up to the user to decide.

Not quite.

While an argument can certainly be made that it's a user's right to overrule UI designers in a controlled manner (see my comment about the RSS and Reload icons), the distinction between page and browser actions is conceptual first and then visual as a side-effect.

Page actions can be thought of as verbs which complete the sentence "______ this page". (Bookmark, Share, Screenshot, Copy the link for, Report an issue with, Get RSS feed(s) for, Reload, etc.)

That's part of why they're hidden by default. It's assumed that, more often than not, the applicability will depend on the contents of the page.

Putting them inside the address bar is justifiable under the same "cues based on hierarchical semantic groupings" rationale that was used as part of the justification for moving the tab bar above the address bar.

Conversely, browser actions are things which relate to the greater browser scope. (eg. The downloads pane, which is not tied to any specific tab, or things like uBlock Origin and uMatrix, which use browser actions to configure persistent, browser-wide policies.)

They're enabled by default because, when used properly, at least some of the functionality they expose is expected to apply universally. (eg. Browser-wide policy configuration, navigating from any starting point to a specific page with inclusion of selected text being optional, etc.) 

Back/Forward are also semantically browser actions rather than page actions because they're "Go to" actions operating on history data that's outside the scope of the current page. (Essentially, they're special-case, dynamic versions of bookmarks toolbar entries.)
Summary: [ux] Improve customization experience by allowing URL bar items to be managed from within customize mode → [ux] Improve customization experience by allowing URL bar items (page actions and others) to be managed from within customize mode
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(gijskruitbosch+bugs)
Duplicate of this bug: 1811221

I maybe know how you implement it, let me explain:

Back in the Firefox pre-57 there existed an uc.js script which adds the ability to add items to the address bar.

Here is link to that script created by ardiman https://github.com/ardiman/userChrome.js/tree/master/addtoolbarinsidelocationbar

This script is about adding any items to the address bar (or location bar).

As you notice, that it is in German language, but it can be translated, so it would not be problem.

The real problem is, that this script was written for Firefox before Quantum (FX pre-57), so it is obsolete.

If you think, that my opinion is outdated, then mark my comment as off-topic, but I want to help with implementing this feature, so this script would be helpful with implementing.

Whiteboard: [reserve-photon-structure] [ux] → [reserve-photon-structure] [ux][blocked-ux]
Duplicate of this bug: 1843751

What exactly means “blocked-ux”?

(In reply to Patrik Krajcovic [:patricek] (she/her) from comment #23)

What exactly means “blocked-ux”?

It means someone on the UX team has to design how the feature should work, before it can be implemented.

Keywords: blocked-ux
Whiteboard: [reserve-photon-structure] [ux][blocked-ux] → [reserve-photon-structure] [ux]

I think, that the title of this issue seems a little bit obsolete & confusing, because page actions menu was removed in Firefox v89.0.

You need to log in before you can comment on or make changes to this bug.