Remove the add-on bar

[ZER0]

Hi there,

I'm working in the jetpack team, and I was asking to clarify some points
about the add-on bar and specifically about Widget (SDK Widget), that
are automatically added on the add-on bar.

Some premises before entering in the discussions:

1. As jetpack team, we're going to implement new UI components for
Australis, to eventually replace the SDK Widget. You can have a look to
the mockups here:

<http://people.mozilla.com/~shorlander/files/addons-in-toolbar-i01/addons-in-toolbar.html>

And for anyone that is interested in the API proposal:

<https://github.com/mozilla/addon-sdk/wiki/JEP-Add-on-UI-Integration>

2. As jetpack team, we have a process to deprecate "stable" APIs. You
can have a look here:

<https://blog.mozilla.org/addons/2012/10/01/a-lifecycle-for-the-add-on-sdks-apis/>

In short, we keep deprecated APIs for at least 18 weeks.

Notice that because Widget is an High Level API and is one of the most
used APIs in jetpack add-ons, the period will keep them around for much
longer.

3. SDK Widget cannot really be placed directly in nav-bar by default,
without affecting the user experience. That's because the Widgets can
have any width (300px, 500px…) and contains any kind of HTML document
(they're content iframe wrapped in toolbaritem). An example of long
Widget could be memchaser:

<https://addons.mozilla.org/En-us/firefox/addon/memchaser/>

Put a couple of add-on like that directly in the nav-bar will makes the
Australis UI less than usable. As far as I know, UX doesn't want
anything like that, that's why in the new UI components we have as
constraint to accept only button with image in and with specific width
(16, 32, 64).

4. Most of us wants to get rid of add-on bar.

Hope I made all the premise clear for anyone that wasn't aware of
previous discussions.

That said, if we want to remove the add-on bar we need a place were put
the SDK Widget in Australis, because we don't have time to do the
deprecation process properly, so we – jetpack – need a period of time
where both new UI Components and Widget coexist; but nav-bar is not a
suitable place according to UX – and personally I agreed.

My proposal is move the add-on bar to the top, above the content, making
the add-on bar like any other toolbar in Australis Mockup. I made a
simple mockup for that, based on the ones made by Stephen:

<http://people.mozilla.com/~mferretti/files/addons-in-toolbar/addon-bar-mockup.png>

As you can see, there is a button with a generic add-on icon pressed, in
the nav-bar, exactly like any other add-on that can creates a toolbar
(see the mockup by shorlander).

Have a solution like that should be consistent with the Australis UI,
and in my opinion will also help the migration process of the SDK Widget
to our new UI components: developers will start to wonder "Why I have to
be in a generic toolbar with an anonymous button, when my add-on can
have its own toolbar?"

Hope that this approach will makes everyone happy, if you have
questions, doubts, concerns, other solutions or I missed / misunderstood
something, please let me know!

Cheers,

Matteo
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Gijs Kruitbosch]

Hi Matteo,

Thanks for figuring this out!

On 13/05/13 22:11 , ZER0 wrote:
> <snip>

> My proposal is move the add-on bar to the top, above the content, making
> the add-on bar like any other toolbar in Australis Mockup. I made a
> simple mockup for that, based on the ones made by Stephen:
>
> <http://people.mozilla.com/~mferretti/files/addons-in-toolbar/addon-bar-mockup.png>
>
> As you can see, there is a button with a generic add-on icon pressed, in
> the nav-bar, exactly like any other add-on that can creates a toolbar
> (see the mockup by shorlander).

Do we want to actually move the existing add-on bar to the top, or do we
want to remove the add-on bar and have a specific toolbar used by the
SDK where it can put widgets? I'm guessing the former makes the most
sense, but there *are* downsides (eg. we need to do some good outreach
to themes because we're moving something that they expected to be at the
bottom to the top, and keeping the id; it wouldn't discourage use of the
extra bar as much as migrating non-SDK add-ons to the nav-bar outright;
the toolbars at the top tend to use more vertical space so in those
terms it's a net loss of space for content).
Cheers,
Gijs

[Brunoais]

Can we put the addon bar back down if we want to by customizing the UI
using the "customize..." menu option?

[Jared Wein]

Maybe it makes sense to just leave the add-on bar untouched.

We have a carrot or a stick here that we can use. The carrot here is the new API that puts the button in the navbar, the stick is removing the addon bar. If add-on developers like the new API, they can update their addon to move their content from the add-on bar to the nav-bar. It's not going to get everyone to move away from the add-on bar, but supporting the add-on bar isn't the biggest of our problems.

Given the time schedule that we'd like to have for Australis (and the API change leadtime promised by the Add-on SDK), it probably makes more sense to leave the add-on bar untouched and keep pushing forward on new APIs for add-on developers to use that will let them put standard buttons in the nav-bar toolbar.

- Jared

[Alex Limi]

+1 for not making this a requirement for Australis. Active add-on developers will probably want the added visibility and "nativeness" of being in the main toolbar, so this will hopefully resolve itself over time.

(Note that I speak for myself, not on behalf of the UX team on this :)

— Alex Limi · Product Design Strategy, Mozilla · http://twitter.com/limi · http://limi.net

> > > firef...@mozilla.org (mailto:firef...@mozilla.org)

> > > https://mail.mozilla.org/listinfo/firefox-dev
> >
> >
> >
> > _______________________________________________
> > firefox-dev mailing list

> > firef...@mozilla.org (mailto:firef...@mozilla.org)

> > https://mail.mozilla.org/listinfo/firefox-dev
>
>
> _______________________________________________
> firefox-dev mailing list

> firef...@mozilla.org (mailto:firef...@mozilla.org)

[Roland Haslinger]

That is the first good possible plan i hear from the Australis Developement Department :)

Thanks for considering that option.

Also do imagine if addon Developers would have to create for every Custom Bar depending addon a new single replacement bar.

If there is no Official Addon available which would be accepted as official solution every addon creator would be forced to code custom bars for his/her addons if there is a need for that.

And what happens if you have more addons installed which do add multiple bars? The mess that is being created is not worth the trouble in my opinion.

I hope therefor you let the addon bar survive. Would you please? A Decision like that would let me again use Firefox - including the Australis Versions!

--
---------- Wikus Van De Merwe was right - Fookin' Planet!!! ----------

[Madhava Enros]

Hi all -

I think I lean in the direction of more carrot, less stick, for a release or two.

One reason is that, as Limi and Jared have mentioned, it will give add-on authors time to migrate. Another is that I suspect many people have add-on UI lurking in the add-on bar at the bottom of their screens, mostly out of sight and mind, and moving them into a toolbar at the top will make updating to Australis feel _more_ cluttered rather than less, which is not the update experience we want people to have. Yes, they can customize them to other parts of the UI, but they should feel like customization is a necessary and burdensome step.

If we're keeping the add-on bar, should we be including it in the customization mode?

Madhava

-- 

Madhava Enros

Firefox User Experience

mozilla.org/firefox

[Gijs Kruitbosch]

I believe the answer to "should we include it in customization mode" should be 'yes, but...'. From what I've heard from various folks, many add-ons currently hard-code initialization into the status-bar element, which we've included into the add-on bar when we removed the 'real' status bar. I'm not sure how that'll play with customization mode (but I guess that the answer is "badly"). I think we should probably either ditch that or accept that only the status-bar-shim-thingummywhatsit as a whole can be moved...

~ Gijs

[Jared Wein]

----- Original Message -----
> From: "Madhava Enros" <mad...@mozilla.com>
>
> If we're keeping the add-on bar, should we be including it in the
> customization mode?
>

Yes, if the add-on bar is kept it should remain as a customization target.

- Jared

[Gijs Kruitbosch]

It seems like most people were in favour of this approach, so I've gone
ahead and filed a new bug for enabling the new-style customization for
the add-on bar ( https://bugzilla.mozilla.org/show_bug.cgi?id=872209 )
and I've wontfixed the migration bug in which we were dealing with
removing it and migrating to the nav-bar (
https://bugzilla.mozilla.org/show_bug.cgi?id=869939 ).

Thanks everyone! :-)
Gijs

[Asa Dotzler]

On 5/14/2013 1:41 PM, Gijs Kruitbosch wrote:
> It seems like most people were in favour of this approach, so I've
> gone ahead and filed a new bug for enabling the new-style
> customization for the add-on bar (
> https://bugzilla.mozilla.org/show_bug.cgi?id=872209 ) and I've
> wontfixed the migration bug in which we were dealing with removing it
> and migrating to the nav-bar (
> https://bugzilla.mozilla.org/show_bug.cgi?id=869939 ).
>
> Thanks everyone! :-)
> Gijs

I am opposed to making the add-on bar a customization target in
Australis and I don't think our UX team is "mostly in favor of this
approach". One UX person asked the question and two developers
answered. That is not the same thing as "most people are in favor."

To move things in the right direction, we should freeze the addon bar,
adjust the SDK to put things in the right place, evangelise to Adblock
Plus and the few other popular add-ons forcing a mostly empty add-on bar
on users and let the thing die. If we leave it customizable, people
will move more items into it over time and it will be harder for us to
get rid of in the future. If we're going to leave it for legacy, that's
one thing, but supporting it as a customization target is bad news.

- A

[Gijs Kruitbosch]

On 15/05/13 23:13 , Asa Dotzler wrote:
> I am opposed to making the add-on bar a customization target in
> Australis and I don't think our UX team is "mostly in favor of this
> approach". One UX person asked the question and two developers
> answered. That is not the same thing as "most people are in favor."

I consider(ed) making it a customization target in Australis part and
parcel of not removing it, and literally everyone in this thread
(including you) seems to think we shouldn't remove it for both technical
and UX reasons. Hence "most people". I thought Madhava was asking an
essentially factual question (in the sense of "does this work need to be
done for this approach to work as I think it would"). More on that after
your next paragraph.

> To move things in the right direction, we should freeze the addon bar,
> adjust the SDK to put things in the right place, evangelise to Adblock
> Plus and the few other popular add-ons forcing a mostly empty add-on
> bar on users and let the thing die. If we leave it customizable,
> people will move more items into it over time and it will be harder
> for us to get rid of in the future. If we're going to leave it for
> legacy, that's one thing, but supporting it as a customization target
> is bad news.

I disagree:
- the new toolbars and the "old" one have a different API for dealing
with their content. You would effectively get two little silos; "new
buttons" in the nav/tab/bookmarks/menubar, old ones in the add-on bar.
Add-on authors would need to write extra code to have buttons in the new
palette/toolbox (because whatever they have now that's in the add-on bar
won't be movable), rather than being able to just use whatever they were
using before and have users decide for themselves.
- You would not be able to order items inside the add-on bar at all, as
we're getting rid of the old customization code which wouldn't work
correctly with the new toolbar customization. The order would just be
random; that's a net loss for users.
- Current Firefox supports moving items between the add-on bar and the
toolbox; it would be a regression if we broke that.
- If we don't make the add-on bar customizable, users won't be able to
move things *out* of the add-on bar; you're assuming they'll move more
things into it and that will make it harder to get rid of. If we
genuinely believe users will opt to use the toolbox rather than the
add-on bar, given the choice, we should give them that choice, not take
it away from them and force add-on authors to follow our line of thought
by means of technical limitations.
- Having two different APIs involved will make it harder for the SDK
folks to deprecate and/or update/migrate their APIs to support whatever
we're doing. It will be a lot less painful for them if we move to a new
API wholesale, they update their code that takes care of SDK widgets
"behind the scenes" to use the new API, and when the add-on bar does go
away completely, we don't break SDK consumers. Otherwise, they have to
both support the old API and add support for the new one "for when the
add-on bar goes away". I can attest to the mixing of these APIs being
painful already from trying to fix the SDK tests (which are currently
broken on UX). Let's not make it worse.

~ Gijs

[Jared Wein]

----- Original Message -----
> From: "Asa Dotzler" <a...@mozilla.com>
>
> If we leave it customizable, people will move more items into it over time
> and it will be harder for us to get rid of in the future. If we're going to
> leave it for legacy, that's one thing, but supporting it as a customization
> target is bad news.
>
> - A

The likelihood of users moving items into the add-on bar as a customization target are greatly reduced with Australis.

In what we currently ship, the add-on bar appears when in customization mode. This provides users with a "target" and knowledge of another place for their toolbar items. The visibility state of the add-on bar is restored upon exiting customization (re-hiding if it was hidden previously). This is a problem for a number of reasons, the biggest one being that users can *think* that their toolbar item will be visible when exiting customization but they will in fact still need to do more work to make the add-on bar visible. A lesser (but still problematic) issue is the fact that we promote the add-on bar as a destination for customization to those who haven't already opted-in to it.

With Australis, the add-on bar will only be shown in customization mode if the user has already enabled its visibility. This means that prior to entering customization, the user would have had to either right-click their toolbar and select Add-on Bar or choose View -> Toolbars -> Add-on Bar from the menu. This slight of hand will remove the majority of the promotion of the add-on bar to those who aren't already using it. Add-ons may continue to enable the visibility when placing their toolbaritems there. As mentioned earlier in this thread, if we can provide a better user experience in the navigation toolbar, then popular add-ons like AdBlock Plus will be incentivized to use the new APIs.

I hope that clears things up a little,

[Mike Connor]

On 2013-05-16 4:59 AM, Jared Wein wrote:
> With Australis, the add-on bar will only be shown in customization mode if the user has already enabled its visibility. This means that prior to entering customization, the user would have had to either right-click their toolbar and select Add-on Bar or choose View -> Toolbars -> Add-on Bar from the menu. This slight of hand will remove the majority of the promotion of the add-on bar to those who aren't already using it. Add-ons may continue to enable the visibility when placing their toolbaritems there. As mentioned earlier in this thread, if we can provide a better user experience in the navigation toolbar, then popular add-ons like AdBlock Plus will be incentivized to use the new APIs.

To play the cynic here, I don't actually believe we'll succeed in moving
any significant number of users if we rely solely on carrots. The
reality is that most developers will choose the path of least change and
least effort if we make it possible, so you're effectively arguing for
the status quo. How many authors still target the old statusbar
element? How many more explicitly target the add-on bar and enable it?
If those options continue to work, those add-ons will most likely
continue on unchanged.

In the last decade (as of today), every time we leave a
backwards-compatible path, at best the shift takes months or years. If
we actually believe the add-on bar is the wrong UX, I think we need to
be bolder and bite the bullet now, rather than hope authors will spend
the time to change out of general desire to do good.

-- Mike

[Stephen Cohen]

To input a user's perspective and maybe back up further what the other developers are saying:

Does not the acknowledged desire of users to place more buttons on the Add-On Bar also imply that it has relevant uses? I find it an unusual assumption that users would /arbitrarily/ place buttons in a mostly empty target away from everything else. If a user places something there of their own accord, I would think it's most likely because they find it useful, whether that be for housing wide widgets, as mentioned earlier, or simply for mental organization/convenience. And, as someone else has said, the new customization scheme greatly reduces the chances of having something put there by accident.

> Date: Wed, 15 May 2013 14:13:09 -0700
> From: a...@mozilla.com
> To: firef...@mozilla.org

> Subject: Re: Remove the add-on bar
>

[Gavin Sharp]

On Thu, May 16, 2013 at 9:44 AM, Mike Connor <mco...@mozilla.com> wrote:
> To play the cynic here, I don't actually believe we'll succeed in moving any
> significant number of users if we rely solely on carrots. The reality is
> that most developers will choose the path of least change and least effort
> if we make it possible, so you're effectively arguing for the status quo.
> How many authors still target the old statusbar element? How many more
> explicitly target the add-on bar and enable it? If those options continue
> to work, those add-ons will most likely continue on unchanged.

> In the last decade (as of today), every time we leave a backwards-compatible
> path, at best the shift takes months or years. If we actually believe the
> add-on bar is the wrong UX, I think we need to be bolder and bite the bullet
> now, rather than hope authors will spend the time to change out of general
> desire to do good.

There is no absolute "right UX"/"wrong UX" dichotomy here, and "moving
users" (to some new interaction model) is not the underlying goal.

The primary reasons that we should drop features are a)
maintenance/opportunity costs b) ensuring that we maintain a
simple/elegant/functional design, overall. If maintaining a feature
doesn't significantly cost us in either a) or b), there's no reason
for us to try to "force" users over. My understanding is that
maintaining the add-on bar as a customizable target may be one of
those cases (Jared makes a good case for why there will continue to be
an incentive for users to move away from using it regardless).

Gavin

[Mark Finkle]

There is no absolute "right UX"/"wrong UX" dichotomy here, and "moving
users" (to some new interaction model) is not the underlying goal.

If UX is saying they want to remove the feature, I think the UX team sees a "right" and "wrong" approach.

[Gavin Sharp]

My point is that "the Australis design has no add-on bar" -> "we must
remove the add-on bar immediately and without consideration for
current users/migration/add-on SDK concerns" does not follow. There's
a difference between our ultimate goal and our strategy for getting
there. Simplifying the problem to "UX says X" isn't really useful in
determining our strategy.

Gavin

[Jared Wein]

----- Original Message -----
> From: "Andrew Joakimsen" <joak...@gmail.com>
> Subject: Re: Remove the add-on bar
>

> Why can't Firefox keep the API and let the user put their addons icon
> wherever they please? Personally I find the addons bar to be ugly
> and obtrusive and would prefer to see the exact same icons next/near
> the address bar. This is made worse by no about:config to hide it
> and the need for a nasty CSS hack that totally hides the addon bar
> instead. So from that aspect I'm totally for removing it.
>
> Compare installing AdBlock Plus in Opera vs Firefox.
>

Why is a nasty CSS hack needed? Does unchecking View -> Toolbars -> Add-on Bar not work for you? If so, please file a bug with steps to reproduce.

Thanks,
Jared

[Mike Connor]

On 2013-05-16 2:08 PM, Gavin Sharp wrote:
> My point is that "the Australis design has no add-on bar" -> "we must
> remove the add-on bar immediately and without consideration for
> current users/migration/add-on SDK concerns" does not follow. There's
> a difference between our ultimate goal and our strategy for getting
> there.

If you're saying we don't have time to make the needed Add-on SDK
changes in time, or we don't feel like we have an adequate story for
migration, then I agree we should delay the removal of the add-on bar
until we can handle that properly. My post was simply meant to argue
that soft deprecations have been historically unsuccessful at driving
change, so if we believe that our ultimate goal is to get users and
add-ons off that UI, we will have to take a harder line than what is
being proposed here.

I think Asa's take is the least aggressive approach we should take if
it's indeed our ultimate goal.

-- Mike