Closed Bug 695913 Opened 13 years ago Closed 10 years ago

Addon buttons in navigation toolbar - UX implementation tracking bug

Categories

(Add-on SDK Graveyard :: General, enhancement, P1)

Product:
Add-on SDK Graveyard
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: myk, Unassigned)

References

(
URL
)

Details

(Keywords: meta)

Attachments

(2 files)

My current Firefox UI
30.15 KB, image/png
Details
UI with Australis
30.54 KB, image/png
Details 
Addon authors want their widgets to appear in the navigation bar, and users expect to find them there, so we should convert the addon bar to an addon section within the navigation bar at the top of the browser window.

We've talked about doing this for a long time, and there's never been any dispute about it being the right thing to do, but we've previously gated the change on merging the location and search boxes.

However, I talked to limi about it yesterday, and he now thinks we shouldn't gate the one change on the other, and we do this one as soon as possible.  I agree.

limi says to place the addon section to the right of the location/search boxes but to the left of any other default chrome that appears to the right of those boxes in the navigation bar.

I'm filing this as an Add-on SDK bug, but it might be more appropriate in the Firefox product (or dependent on a bug in that product), depending on where the changes to implement it end up being made.
(In reply to Myk Melez [:myk] from comment #0)
> limi says to place the addon section to the right of the location/search
> boxes but to the left of any other default chrome that appears to the right
> of those boxes in the navigation bar.

Some initial UX ponderings:

By "special section" do you mean that it should be styled differently? Or would placing widgets between the location bar and search box be sufficient?

How should we deal with customized navigation bars? Some users might have customized away the search box manually, or via an add-on.

How should we deal with overflow? IOW, say there's a bunch of widgets, currently the location bar will get smaller and smaller, and eventually the search bar will go off-screen, etc. Is there a way to do this better? Should we increase the minimum width of the location bar?
WRT Jetpack's API: Should we provide a mechanism for add-on devs to specify where they'd like their widget to default? Some really do make more sense in the add-on bar, and might like to stay there.
WRT overflow: chrome keeps pushing the locaton bar to the left. We should maybe do this as well and keep the search bar fixed width. The search bar *should not* go off  screen. 

I like Deitrich's suggestion of allowing a *default* location for this button in the UI which gets deprecated in favour of a local pref. 

There are *also* some add-ons ( like F1 ) that place buttons inside the location bar widget:

https://img.skitch.com/20111020-ed74cd9myeu8mu4aicfm1quere.jpg

I am of two minds about this:

1. this is a great place to add UI, we shouldn't discount allowing add-ons to place buttons here, but

2. there is no way to drag the F1 button out of the location bar area currently via the 'Customize UI' mode, which is not acceptable. Obviously, if we allow add-on authors to put gadgetry inside the location bar, users should be able to remove said gadgetry easily.
(In reply to Dietrich Ayala (:dietrich) from comment #1)
> By "special section" do you mean that it should be styled differently? Or
> would placing widgets between the location bar and search box be sufficient?

No, it would not be styled differently.

Placing widgets between the two boxes isn't sufficient, as limi wants them to appear to the right of the two boxes, but placing widgets to the right of the search box, between that box and any default items to the right of it, should be sufficient.

But it might be necessary for implementation purposes to contain those items within a container inside the navigation bar.  Otherwise how does the Widget API determine where to put them relative to the other items on the toolbar?  I suppose we could put a marker in the appropriate position and place them next to the marker instead of inside a container.


> How should we deal with customized navigation bars? Some users might have
> customized away the search box manually, or via an add-on.

If a user has removed the search box, the widgets should appear to the right of the location box. Basically, the idea is that there should be a place in the navigation bar where the items appear by default (although, as is currently the case, they can be moved around via toolbar customization).


> How should we deal with overflow? IOW, say there's a bunch of widgets,
> currently the location bar will get smaller and smaller, and eventually the
> search bar will go off-screen, etc. Is there a way to do this better? Should
> we increase the minimum width of the location bar?

I'm not sure about increasing the minimum width of the location bar, and UX should make the call on questions like these, but my first thought would be to not try to solve the overflow problem in the first iteration.

In the common case, a user will have only a few addons with widgets, and overflow won't be a problem.  And users who do have many addons with widgets can currently use toolbar customization to move those widgets to a different bar (or remove them, in the case of addons whose widgets are not essential to the functionality of the addon).

So I would test the sufficiency of the existing functionality for dealing with navigation toolbar crowding before trying to add new functionality to deal with it.


(In reply to Dietrich Ayala (:dietrich) from comment #2)
> WRT Jetpack's API: Should we provide a mechanism for add-on devs to specify
> where they'd like their widget to default? Some really do make more sense in
> the add-on bar, and might like to stay there.

Per the discussion in bug 586029, we should not do this, and this change paves the way for removing the addon bar entirely (and adding widgets to the mobile browser's interface), as seen in UX mockups of Firefox's future interface.
Assignee: nobody → poirot.alex
Priority: -- → P1
How can I move this forward? I'd like to convert a big extension (both in functionality and userbase) to jetpack, but we absolutely need normal toolbar buttons at the top, not the bottom.

I'm available to contribute, too. poirot.alex: Are you OK with me taking this bug?
It doesn't look like a bug that may be done by a contributor. It will require various discussion between jetpack and UX team in order to figure out what to do.
I'm assigned to this as I mentioned multiple times how important this bug is.
But I'm waiting for the opportunity to have a large chunk of time dedicated to this, before digging into implementation details.
So I think that the best way to get this done is to promote this feature into our 2012 roadmap:
https://wiki.mozilla.org/Jetpack/Goals/2012-Goals
And if I understand this page correctly, this bug is mentioned as "like to have for Q1" that seems to mean "if not Q1, Q2".

dcm: Am I correct?
That's correct Alex - as we looked at the goals for the quarter we realized that there might be more than our limited resources could get through. This one is one that we might want to make sure is in Q2 if it doesn't get done in Q1 though as we need to get to it relatively soon.

In the meantime, I (plus anyone else interested) can have some conversations with the UX team to map out as much as possible before implementation. If that's done, I don't see why a contributor couldn't take it up - not to mention that a contributor can certainly join in the talks with the UX team as well!
> can have some conversations with the UX team

How would I do that? (With the goal of get concrete results and decisions, not just ideas.)
(In reply to Ben Bucksch (:BenB) from comment #5)

BenB: In the meantime I think you should consider using Erik Vold's existing toolbar module. If you run into limitations with it I think Erik would be happy to take suggestions or ( ideally ) pull requests:

https://github.com/erikvold/toolbarbutton-jplib/
OK
I was finally able to write down a summary about the "widget story",
that, I hope, is going to help drive this work forward:

  https://jetpack.etherpad.mozilla.org/widget-in-navigation-bar

Next step, plan a meeting with UX folks to get some concrete feedback.
One thing we should think about is (I wanted to raise it at the meeting, but maybe you want to ponder over it a bit): what happens when there are 10 addons with such buttons. Or maybe one addon with 10 buttons (think classical Google/Yahoo toolbar).

One possibility would be to place 1-3 buttons in the nav toolbar, and if there are more than 3, create a new toolbar.
Please no "chevron", that's a horrible UI and means the buttons are basically gone for normal users.
As I raised during the meeting, I really think we should split this issue in several issues.
The etherpad's document Alex wrote, include basically all these issues. As – I thought – we agreed at the end of the meeting, the main issue we're focusing now is removing the addon bar from the bottom, and find a better place where put it, like the UX mocks show, at the side of the navigation bar.

To me, this is the main issue, that has to be solved. We have to take in account not only add-ons that have icons, but add-ons that can draw graph and other things. It's an *improvement*, and UX is working on it, after the meeting we had Stephen collected our needs and input.

For this specific issue, the high level APIs for Widget should be works as always. They don't have to be changed, the Developers doesn't have to specify any "position" where they can add the widget.

Then, we have *new* *features*. They should be threat separately from the improvement issue.

The new features are:

1. Transient Widget
2. Widget (icon) *inside* location bar (e.g. F1)
3. Modify Firefox UI deeply 

I think they are all related but different issue from the addon bar ones. Especially the last one, to me is more low level – and maybe could be solved using "Chrome-Mod" or how we want call these APIs.

I'd love adding also the "page-mod detector" as I described during the meeting. I think it will bring a great experience to the users, and it could remove all these add-on's icons that doesn't actually need to be in the addon-bar, but they're needed because the on/off functionality.
I'd like to work on that functionality, see if and how it is possible to implement, and work with UX to provide a proposal. The good thing is, the high level APIs for page-mod will be kept as is, and it will work for all page-mods written until now.

I will suggest - but again, I'd like to discuss with UX about it – that the "page-mod detector" will be a "Transient Widget" (it will appear only when at least one page-mode is matching the actual page) "inside location bar" (is deeply connected to the URL). So this new features probably depends by point 1 and 2.
Going to turn this into a meta-bug for the UX implementation work, we should get multiple bugs on file for pieces of it.
URL: https://wiki.mozilla.org/Features/Jet...
Keywords: meta
Summary: make widgets appear in navigation bar → Add-ons in toolbar implementation
Ok - we should then have a few more dependant bugs:

* on Firefox itself that tracks landing changes to the navigation bar
* additional bugs for the implementation of each SDK module
As I've said before, I strongly disagree with the chevron. Most common users will not find an icon that is hidden in this way. For them, the icon doesn't exist.

That makes this whole feature entirely useless for us. Icons must never be hidden.

We've had cases where users had *manually* hidden things, then complained to our hotline that the icons are not there and said the extension is broken. This wasn't a one-off stupid user, this happened considerable times.

One solution is to create a second toolbar, if the user opted to install so many extensions that they don't fit. Maybe there are other solutions, you're welcome to find other ideas. But the chevron is user hostile.
Summary: Add-ons in toolbar implementation → Add-ons in toolbar - implementation
Assignee: poirot.alex → zer0
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #16)
> Here the mockups from UX:
> http://people.mozilla.com/~shorlander/files/addons-in-toolbar-i01/addons-in-
> toolbar.html

I personally think this looks good except for one nit.  It appears that the
activated icons always look "pressed."  For addons that are most likely going to
be always on (like that ad blocker plus shown), this would feel annoying to me.

Would it be possible to instead have INactive icons greyed out instead?  This
wouldn't draw so much attention towards activated icons. 

(Sorry, I don’t know if this is the proper place to comment with personal options.
Please let me know if there is a better location.)
+1 Sounds like a good idea. I'd add a (/) strike-through icon overlay for disabled ones.
James, that's the right place no worries. I think it's a great suggestion!

Also because the new type of Widgets, the "Toolbar" ones, use the pressed state. That could bring confusion between the Toggle ones, so I totally agree with you, the Toggle's widgets should have a different way to indicate their status. I will check with our UX department and see what they're thinking about it. Greyed out seems a reasonable approach, however we have to be sure that they don't looks "disabled" but just "inactive".

Ben, although I think would be nice have a strike-through icon overlay, I can see three major problem with that: icons that maybe have already a "strike-through" could be misunderstood (e.g. NoScript); and having multiple disabled icons with strike-through could make them more difficult do recognize because the overlay. In addition, if we allowed also for Toggle's widget to have multiple sizes (see https://bugzilla.mozilla.org/show_bug.cgi?id=645506#c20) we should apply different strike-through graphics as well, and makes them less standard to recognize.

I personally think that have an approach that doesn't cover the original icon suits better. Take as example the "active" light spot on Mac OS X, when an application is running; or the grayed out approach suggested by James.
Copied the conversation on bug 787392 ("Add Toggle's widgets type").
Can we rename this bug? it's very confusing.

Maybe 'Add-on UI updates 2013'?
Summary: Add-ons in toolbar - implementation → UX implementation tracking bug
Now I find the topic confusingly generic.

The purpose of this ticket is to allow Jetpacks addons to add buttons to the main Firefox navigation toolbar.
Summary: UX implementation tracking bug → Addon buttons in navigation toolbar - UX implementation tracking bug
(In reply to Ben Bucksch (:BenB) from comment #26)
> Now I find the topic confusingly generic.
> 
> The purpose of this ticket is to allow Jetpacks addons to add buttons to the
> main Firefox navigation toolbar.

That's just part of this bug (bug 787392 is most of that). This also covers the implementation of toolbar and sidebar modules
Depends on: australis
(In reply to Myk Melez [:myk] [@mykmelez] from comment #0)
> Addon authors want their widgets to appear in the navigation bar, and users
> expect to find them there

No. I expect to find addon icons in the addon bar, that's what the addon bar is there for.

I was shocked today to find that the addon bar has been removed from the UX branch, and that all my addon icons were placed in the navigation bar, totally polluting it. This is not an improvement, this makes user experience much worse.

You don't have to copy everything from Google Chrome. Chrome is a bad example in terms of user experience, and the more you copy from Chrome, the worse you make Firefox.

Opera is currently committing suicide by their Chromium based new version, don't do the same. With Opera's suicide mission, Firefox would have a good chance to become the clearly most customizable browser, but rather than taking this chance it looks like you follow suit in their suicide mission, because the entire WWW seems to have to be like Chrome these days.

It does not!

Please add the addon bar back, and don't make Firefox worse in terms of customizability.
Markus, thanks for your comment. Could you send me a screenshot of your navigation bar (with add on icons)? How many add-ons do you have?
Attached image My current Firefox UI — 
(In reply to Jinghua zhang from comment #29)
> Markus, thanks for your comment. Could you send me a screenshot of your
> navigation bar (with add on icons)? How many add-ons do you have?

Here is about what my Firefox UI looks like now.
Attached image UI with Australis — 
(In reply to Jinghua zhang from comment #29)
> Markus, thanks for your comment. Could you send me a screenshot of your
> navigation bar (with add on icons)? How many add-ons do you have?

Here is what my UI looks like after switching to the UX channel. Navigation bar is crowded with (too large) icons, some of which are even blurry & ugly. This is already reported as bug 885065 though.

Also note that 2 of my icons (Bookmarks & History for the sidebar) are missing on the left. This I reported as bug 879388.

The 3rd thing which annoys me is that the traditional menu is no longer easily accessible. Pressing the Alt key doesn't work to get the main menu on top, and the other menu which used to be in the left top corner is also no longer available. So the only way to get to the full menu is to temporarily turn the menu bar back on (which is annoyingly cumbersome if I don't want it permanently). The menu replacement in Australis isn't really a full replacement for the menu which I used to have with the old UI. This I reported as bug 879396.
I like the look of the new UI, esp. the rounded tabs.
However, I concur with Markus. The large icons are ugly. We had just switched from large (default) to small in 3.6->4.0, please stick with the choice.
Same with the menu. Keep the menu, it's central to the app. Do not move it, because that means people need to re-train where to find things, and that's highly annoying. Also, all documentation has to be changed. Do not change basic UI every few releases. It's these things why many people and companies stay on very old releases, and that's a security problem for everybody.
Another problem with the addon icons in the navigation bar: I don't seem to be able to arrange them in any order I want. They jump around arbitrarily, don't stick at the location where I drop them.

Maybe this is worth a separate bug report, however I still hope that the addon bar remains (I see no benefit in removing it; the choice where to place the icons should be with the users).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: