1041740 - Document how to create buttons that are hidden by default

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

See this comment:

https://blog.mozilla.org/addons/2014/03/13/new-add-on-sdk-australis-ui-features-in-firefox-29/comment-page-1/#comment-200936

I suspect there is a way this can be done currently by creating a button and then removing it from the toolbar, but it isn't documented.

Comment 1

[Matteo Ferretti [:zer0] [:matteo]]

No, there isn't a way. We inherit the same behavior that we had with Widget, where the mere action of create a Button makes them attached to the navbar.

Where make it "visible / invisible" was explicitly avoided by UX – in order to do not have "jumping UI" –  is it true that we could maybe provide a property to decide if the button should be automatically attached or not – so that the user can costumize later, and the navbar is not pollute by unnecessary buttons.

However, doing that would violate another user experience aspect, that was that the user will see immediately that the add-on is installed 'cause the button is immediately visible in the navbar – if it's "hidden" (in the palette) we lacks such feedback.
Said that, I think shouldn't be a problem, for two reason: first of all, the CustomizableUI itself provides such functionality, so I think is legit do the same. Second, the benefits are greater than the "cons".

So, I would rephrase the subject of this bug – hidden is misleading – and then I would implement a property to define the area of the button (e.g. "none" for palette, "panel" for the new menu panel, "toolbar" for the current behavior, that would be the default value); asking for UX's feedback.

Comment 2

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #1)
...
> However, doing that would violate another user experience aspect, that was
> that the user will see immediately that the add-on is installed 'cause the
> button is immediately visible in the navbar – if it's "hidden" (in the
> palette) we lacks such feedback.

...this is I think the biggest problem with it.

> So, I would rephrase the subject of this bug – hidden is misleading – and
> then I would implement a property to define the area of the button (e.g.
> "none" for palette, "panel" for the new menu panel, "toolbar" for the
> current behavior, that would be the default value); asking for UX's feedback.

I'd be curious about the UX feedback as well. I think once we have people using jpm / npm someone will create a button using the customizable UI apis that deso this for them, and it will be interesting to see how much it is used.

Comment 3

[Matteo Ferretti [:zer0] [:matteo]]

Hey Stephen, could you give your feedback on this matter? What do you think about that feature?

Comment 4

[Stephen Horlander [:shorlander]]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #1)
> So, I would rephrase the subject of this bug – hidden is misleading – and
> then I would implement a property to define the area of the button (e.g.
> "none" for palette, "panel" for the new menu panel, "toolbar" for the
> current behavior, that would be the default value); asking for UX's feedback.

Yeah, that seems more accurate than hide. It's basically a way to place the button/icon in one of three places with decreasing visibility/discoverability.

The original rationale for this was, as Matteo said, that we want a clear indication of the result of the user action. If you install an add-on that has a button and then that button is nowhere to be found, that can be confusing.

If we had a better way to illustrate where something ended up this could work. But since we don't, I don't think we should allow things to be "hidden" on install.