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