Hiding command buttons by default

[Brian Grinstead]

I have been working on Bug 974947, which allows people to hide toolbox
buttons (aka command buttons) in order to free up some space in their
tab bar. You hide them from the options panel, kind of like how you can
currently remove some of the toolbox tabs.

Anyway, we will need to decide which tools should be on and off by
default. Hiding things by default makes the things that are visible
easier to find and use. This is why I am suggesting that some start off
hidden instead of just leaving them all visible, and is the whole point
of this message.

In the current patch, here is the configuration:

On by default:
* pick an element from the page
* toggle split console
* responsive design mode

Off by default:
* paint flashing
* tilt
* scratchpad

Jeff has been looking at some data about the frequency with which
certain tools are opened
(http://canuckistani.github.io/devtools-dashboard/). But from what I
understand we don't have a bigger picture about usage from that data
right now, so those graphs are not enough alone to justify the default
state of any of these buttons.

Screenshot with the patch applied:
https://bug974947.bugzilla.mozilla.org/attachment.cgi?id=8383678, and
link to bug: https://bugzilla.mozilla.org/show_bug.cgi?id=974947

Brian

[Fred Wenzel]

How do you ensure discoverability? For a lot of tools, devs don't know that they want them until they stumble upon them for the first time and have their mind blown.

Fred

>_______________________________________________
>dev-developer-tools mailing list
>dev-devel...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-developer-tools

--
Sent from my phone. Please excuse my brevity.

[Brian Grinstead]

> ------------------------------------------------------------------------

>
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>
>
> --
> Sent from my phone. Please excuse my brevity.

We have a similar issue with discoverability on tabs or other features
that are not enabled by default. In this case we rely on
documentation, blog posts, etc. to get the word out about features.
Having a UI like Darrin's mockup could also make it easier to find the
non-default buttons.

Brian

[Anthony Ricaud]

On 01/03/14 01:09, Brian Grinstead wrote:
> We have a similar issue with discoverability on tabs or other features
> that are not enabled by default. In this case we rely on documentation,
> blog posts, etc. to get the word out about features. Having a UI like
> Darrin's mockup could also make it easier to find the non-default buttons.

Which mockup are you referring to?

Of the three going:
- Sad to see paint flashing "disappear" but it makes sense and I hope it
will come back in a performance-like tab.
- Happy to see scratchpad off by default, multi-line console would
remove the need for a specific toolbox-level button.
- Maybe Tilt could leave in the Inspector tab? Not sure there's space
but I think it makes sense in there.

[Brian Grinstead]

On Mon Mar 3 06:42:14 2014, Anthony Ricaud wrote:
> On 01/03/14 01:09, Brian Grinstead wrote:

>> We have a similar issue with discoverability on tabs or other features
>> that are not enabled by default. In this case we rely on documentation,
>> blog posts, etc. to get the word out about features. Having a UI like
>> Darrin's mockup could also make it easier to find the non-default
>> buttons.

> Which mockup are you referring to?

There was a reply from Darrin on this thread, but it looks like it
didn't make it in the archives. Here is the text:


I was thinking about this problem too, and maybe not for a first
iteration, but rather than hiding tools entirely we could feasibly
present them in an overflow/dropdown (or drop up) so that they are
still discoverable and reachable. This would be handy for tools that
need to be used occasionally but not as often as the ones you want
permanently in the toolbar. Turning them on/off (maybe with star/fav vs
on/off?) in the options panel would determine if they show in the
toolbar or the drop down. What this solves is the challenge that some
tools will be frequently used (inspector, etc) while some may only need
to be used occasionally (eyedropper, paint flashing, etc). It would be
a pain to have to turn these infrequent tools on/off each time you
wanted to use them. Quick mockup below:

[Brian Grinstead]

On Mon Mar 3 07:16:55 2014, Brian Grinstead wrote:
> On Mon Mar 3 06:42:14 2014, Anthony Ricaud wrote:
>> On 01/03/14 01:09, Brian Grinstead wrote:

>>> We have a similar issue with discoverability on tabs or other features
>>> that are not enabled by default. In this case we rely on
>>> documentation,
>>> blog posts, etc. to get the word out about features. Having a UI like
>>> Darrin's mockup could also make it easier to find the non-default
>>> buttons.

>> Which mockup are you referring to?
>
> There was a reply from Darrin on this thread, but it looks like it
> didn't make it in the archives. Here is the text:
>
>
> I was thinking about this problem too, and maybe not for a first
> iteration, but rather than hiding tools entirely we could feasibly
> present them in an overflow/dropdown (or drop up) so that they are
> still discoverable and reachable. This would be handy for tools that
> need to be used occasionally but not as often as the ones you want
> permanently in the toolbar. Turning them on/off (maybe with star/fav
> vs on/off?) in the options panel would determine if they show in the
> toolbar or the drop down. What this solves is the challenge that some
> tools will be frequently used (inspector, etc) while some may only
> need to be used occasionally (eyedropper, paint flashing, etc). It
> would be a pain to have to turn these infrequent tools on/off each
> time you wanted to use them. Quick mockup below:

And here is a copy of the attached mockup:
https://www.dropbox.com/s/iobut9sgbahuo19/command-dropdown.png

[stripTM]

2014-03-03 14:18 GMT+01:00 Brian Grinstead <bgrin...@mozilla.com>:

> On Mon Mar 3 07:16:55 2014, Brian Grinstead wrote:
>
>> On Mon Mar 3 06:42:14 2014, Anthony Ricaud wrote:
>>
>>> On 01/03/14 01:09, Brian Grinstead wrote:
>>>

>>>> We have a similar issue with discoverability on tabs or other features
>>>> that are not enabled by default. In this case we rely on
>>>> documentation,
>>>> blog posts, etc. to get the word out about features. Having a UI like
>>>> Darrin's mockup could also make it easier to find the non-default
>>>> buttons.
>>>>

>>> Which mockup are you referring to?
>>>
>>
>> There was a reply from Darrin on this thread, but it looks like it
>> didn't make it in the archives. Here is the text:
>>
>>
>> I was thinking about this problem too, and maybe not for a first
>> iteration, but rather than hiding tools entirely we could feasibly
>> present them in an overflow/dropdown (or drop up) so that they are
>> still discoverable and reachable. This would be handy for tools that
>> need to be used occasionally but not as often as the ones you want
>> permanently in the toolbar. Turning them on/off (maybe with star/fav
>> vs on/off?) in the options panel would determine if they show in the
>> toolbar or the drop down. What this solves is the challenge that some
>> tools will be frequently used (inspector, etc) while some may only
>> need to be used occasionally (eyedropper, paint flashing, etc). It
>> would be a pain to have to turn these infrequent tools on/off each
>> time you wanted to use them. Quick mockup below:
>>
>
> And here is a copy of the attached mockup: https://www.dropbox.com/s/
> iobut9sgbahuo19/command-dropdown.png
>
>

+1
It's a very clever solution, it takes up very little space and is only a
click away



--
-=stripTM=-
http://mozilla-hispano.org
http://twitter.com/striptm

[Mihai Sucan]

Le 03/03/2014 15:18, Brian Grinstead a écrit :
> And here is a copy of the attached mockup:
> https://www.dropbox.com/s/iobut9sgbahuo19/command-dropdown.png

That looks good. Can you please add labels to the left for those icons
in the drop-down? It would make a lot of sense, for me.

[Fitzgerald, Nick]

+1

This is much better than completely removing discovery except through
the options panel.

[Jeff Griffiths]

Brian Grinstead wrote:
...

> And here is a copy of the attached mockup:
> https://www.dropbox.com/s/iobut9sgbahuo19/command-dropdown.png

I like it and I think it would be very simple to expose this area to
add-ons to place a simple command-button there. Given that, having the
overflow is critical, and as well have visibility controlled by the user.

One thing users might intuitively want to do is enter a 'customisation
mode' for the toolbox similar to the Australis toolbar in order to
control the order of the buttons etc. Not sure if we want to pursue that
or not but it feels like it is too complicated to deal with now. If we
get lots of buttons in there from add-ons, it will be more critical though.

Jeff

[Brian Grinstead]

For now a customization mode seems like overkill since AFAIK we don't
provide an official way to add these buttons for addons. For toolbox
tabs, gDevTools.registerTool is provided but I don't know of anything
comparable for the buttons. The couple of addons I've seen that add
buttons to this row are just modifying the DOM directly - I don't think
anything we build would support this.

But if we were to provide a way to add these buttons through an
extension API then we would want to look at how this UI would handle
many buttons.

My intent is to ship this in 30 without the UI in this mockup, just
providing a way to pref on and off the buttons through the options
panel.

Brian

[Girish Sharma]

On Tue, Mar 4, 2014 at 12:46 AM, Brian Grinstead <bgrin...@mozilla.com>wrote:

> On Mon Mar 3 12:47:05 2014, Jeff Griffiths wrote:
>
>>
>>
>> Brian Grinstead wrote:
>> ...
>>
>>> And here is a copy of the attached mockup:
>>> https://www.dropbox.com/s/iobut9sgbahuo19/command-dropdown.png
>>>
>>
>> I like it and I think it would be very simple to expose this area to
>> add-ons to place a simple command-button there. Given that, having the
>> overflow is critical, and as well have visibility controlled by the user.
>>
>> One thing users might intuitively want to do is enter a 'customisation
>> mode' for the toolbox similar to the Australis toolbar in order to
>> control the order of the buttons etc. Not sure if we want to pursue
>> that or not but it feels like it is too complicated to deal with now.
>> If we get lots of buttons in there from add-ons, it will be more
>> critical though.
>>
>> Jeff
>>
>
> For now a customization mode seems like overkill since AFAIK we don't
> provide an official way to add these buttons for addons. For toolbox tabs,
> gDevTools.registerTool is provided but I don't know of anything comparable
> for the buttons. The couple of addons I've seen that add buttons to this
> row are just modifying the DOM directly - I don't think anything we build
> would support this.
>
> But if we were to provide a way to add these buttons through an extension
> API then we would want to look at how this UI would handle many buttons.
>
>

These buttons are simply gcli commands under the hood with some extra
properties like for paint flashing [0]. So anyone can add more gcli
commands and thus more toolbox buttons.


[0]
http://dxr.mozilla.org/mozilla-central/source/browser/devtools/commandline/BuiltinCommands.jsm#1989

> My intent is to ship this in 30 without the UI in this mockup, just
> providing a way to pref on and off the buttons through the options panel.
>
> Brian
>
>

> _______________________________________________

> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>



--

Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur

[Brian Grinstead]

On Mon Mar 3 13:20:36 2014, Girish Sharma wrote:
>
>
>
> On Tue, Mar 4, 2014 at 12:46 AM, Brian Grinstead
> <bgrin...@mozilla.com <mailto:bgrin...@mozilla.com>> wrote:
>
> On Mon Mar 3 12:47:05 2014, Jeff Griffiths wrote:
>
>
>
> Brian Grinstead wrote:
> ...
>
> And here is a copy of the attached mockup:

> https://www.dropbox.com/s/__iobut9sgbahuo19/command-__dropdown.png

Yes, but buildButtons only grabs buttons from the
"devtools.toolbox.toolbarSpec" preference:
https://mxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.js#529
and
https://mxr.mozilla.org/mozilla-central/source/browser/devtools/shared/DeveloperToolbar.jsm#66.
So even if a command with a buttonId was added, it would not show up
on the tabbar unless if the preference was modified to add this button
to the list.

[Jeff Griffiths]

Brian Grinstead wrote:
...

> Yes, but buildButtons only grabs buttons from the
> "devtools.toolbox.toolbarSpec" preference:
> https://mxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox.js#529
> and
> https://mxr.mozilla.org/mozilla-central/source/browser/devtools/shared/DeveloperToolbar.jsm#66.
> So even if a command with a buttonId was added, it would not show up on
> the tabbar unless if the preference was modified to add this button to
> the list.

Irakli already has code that allows add-ons to add gcli commands, it
feels like a natural extension to allow these commands to provide a logo
and appear as a button. The add-on would register the command and we
could modify buildButtons to look in the right place.

Jeff

[Girish Sharma]

> Yes, but buildButtons only grabs buttons from the
> "devtools.toolbox.toolbarSpec" preference: https://mxr.mozilla.org/
> mozilla-central/source/browser/devtools/framework/toolbox.js#529 and
> https://mxr.mozilla.org/mozilla-central/source/browser/devtools/shared/
> DeveloperToolbar.jsm#66. So even if a command with a buttonId was added,
> it would not show up on the tabbar unless if the preference was modified to
> add this button to the list.
>
>

If addons can add gcli commands, they can very easily modify a simple (read
complex) pref too. I don't know if any addon does this yet, but Open With
addon adds some toolbox buttons (though not via the gcli command route)

[Heather Arthur]

Have we considered a separate API for adding buttons? I imagine most addons
just know that they want to add a button to the UI, and calling
'gcli.addCommand' isn't very self-descriptive. 'gDevTools.addButton'?
addCommand is doing two things (sometimes). Passing arguments to buttons
doesn't make sense. That would remove the need for the toolbarSpec as well.

> _______________________________________________

[Heather Arthur]

Aha, I did file a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=910146. Anyways, I think we
should consider this. I would like this as an addon developer.

[Jeff Griffiths]

Brian Grinstead wrote:
...

> For now a customization mode seems like overkill since AFAIK we don't
> provide an official way to add these buttons for addons. For toolbox
> tabs, gDevTools.registerTool is provided but I don't know of anything
> comparable for the buttons. The couple of addons I've seen that add
> buttons to this row are just modifying the DOM directly - I don't think
> anything we build would support this.

Irakli has created the devtools pane api as a first stop, but we'll be
increasing the surface of thing speople can integrate with in the tools
all year. Adding buttons to this area seems like an obvious thing to do,
as you say people are already hacking things in there and I'd rather
they used a nice api that works with others.

> But if we were to provide a way to add these buttons through an
> extension API then we would want to look at how this UI would handle
> many buttons.
>

> My intent is to ship this in 30 without the UI in this mockup, just
> providing a way to pref on and off the buttons through the options panel.

I think that's the logical first step.