1239859 - Make it easier to discover tools in the toolbar tabbar

Status: NEW

(DevTools :: Framework, defect, P3)

Description

[Brian Grinstead [:bgrins]]

We've discussed having an easy way to add panels that aren't in the default set by using an icon after the last panel that opens a popup where you can select them.

Comment 1

[Brian Grinstead [:bgrins]]

Latest mockup of this that I know of for this: https://projects.invisionapp.com/share/GN527IGMZ#/screens/117937549.  Helen, is this far enough along to start implementation or does it need more design work?

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Roc also suggested an alternative (although not necessarily mutually exclusive) approach on dev.platform:

> Why not make them context-sensitive? Show the Web Audio tool if the page uses
> Web Audio, Shader Editor if the page uses WebGL, Canvas if the page has a 2D
> canvas, Storage if the page uses IndexedDB, Memory if the page uses memory :-).
> Well, for memory, use some heuristic like if the page spends more than 16ms in
> a single GC.

Comment 3

[Anthony Ricaud (:rik)]

Safari 9 is using real tabs (can be moved, closed, created) with a kind of about:newtab listing all available tools. That makes it very easy to choose your every day workflow while also catering for that one time you need another panel.

Comment 4

[Sebastian Zartner [:sebo]]

(In reply to Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] from comment #2)
> Roc also suggested an alternative (although not necessarily mutually
> exclusive) approach on dev.platform:
> 
> > Why not make them context-sensitive? Show the Web Audio tool if the page uses
> > Web Audio, Shader Editor if the page uses WebGL, Canvas if the page has a 2D
> > canvas, Storage if the page uses IndexedDB, Memory if the page uses memory :-).
> > Well, for memory, use some heuristic like if the page spends more than 16ms in
> > a single GC.

I really like that idea. It's a good way to let people know about those tools.
I'd say, along with that there should be an option to "pin" the tools, so people can adjust the displayed tools to their needs and have less frequent toggling of tabs.

Sebastian

Comment 5

[Anthony Ricaud (:rik)]

Attachment: Exemple of Safari 9 UI

Comment 6

[Helen V. Holmes (:helenvholmes) (:✨)]

So I'm not personally a big fan of it being contextual (at least in this instance). While in a lot of places this feels like a rad idea, for something that's used as often as the toolbar I think it would be better UX if it didn't change without the user changing it themselves.

I wouldn't mind the carat in my mockups glowing or something the first time you land on a page with say, web audio, just to give you the nudge you need to know it exists. That could be pretty rad.

"We notice this page as web audio! We have a tab just for inspecting and working with web audio. Enable it here."-sort of thing.

Comment 7

[Helen V. Holmes (:helenvholmes) (:✨)]

I'm sorry, I didn't mean to clear out the depends on field for 893583. 

Brian, would you consider bug 1238982 and this one to be duplicates?

Comment 8

[Brian Grinstead [:bgrins]]

(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #7)
> I'm sorry, I didn't mean to clear out the depends on field for 893583. 
> 
> Brian, would you consider bug 1238982 and this one to be duplicates?

I think they can stay separate.  We could use Bug 1238982 for the UI to manage command buttons and this one for the UI to manage toobox tabs.

Comment 9

[Sebastian Zartner [:sebo]]

(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #6)
> "We notice this page as web audio! We have a tab just for inspecting and
> working with web audio. Enable it here."-sort of thing.

That's basically the same idea with the difference that the tab would be shown without the user explicitly adding it. But yeah, I can understand that it may be too obtrusive for some users.

Sebastian

Comment 10

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Sebastian Zartner [:sebo] from comment #9)
> (In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #6)
> > "We notice this page as web audio! We have a tab just for inspecting and
> > working with web audio. Enable it here."-sort of thing.
> 
> That's basically the same idea with the difference that the tab would be
> shown without the user explicitly adding it. But yeah, I can understand that
> it may be too obtrusive for some users.
> 
> Sebastian

Yeah, I think it could be obtrusive. We should maybe all pay attention to other web apps more, see if we can't find a really nice pattern for this.

Comment 11

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

@Helen: Do you have any more recent ideas about how you want this to work? My first instinct is to show a small [+] tab on the right and have a simple dropdown showing active and inactive tools with a tick next to the active ones. To hide a tool click on a close button on the tab.

Not sure how this should interact on overflow though... I suggest that overflow has another tab [>>] and clicking a tool replaces the rightmost tab. Would that mean that tabs also need to be draggable so that they can be re-ordered? This is the model that Chrome uses.

I am not sure that both these models are compatible with one another.

I'll see what other UX models make sense.

Comment 12

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #11)
> @Helen: Do you have any more recent ideas about how you want this to work?
> My first instinct is to show a small [+] tab on the right and have a simple
> dropdown showing active and inactive tools with a tick next to the active
> ones. To hide a tool click on a close button on the tab.
> 
> Not sure how this should interact on overflow though... I suggest that
> overflow has another tab [>>] and clicking a tool replaces the rightmost
> tab. Would that mean that tabs also need to be draggable so that they can be
> re-ordered? This is the model that Chrome uses.
> 
> I am not sure that both these models are compatible with one another.
> 
> I'll see what other UX models make sense.

Hey Mike,

I'm working on some more current mockups as gasolin starts to pick up this work. I believe this work is blocked by devtools.html work, although Brian probably has better specifics on that.

Comment 13

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #11)
> @Helen: Do you have any more recent ideas about how you want this to work?
> My first instinct is to show a small [+] tab on the right and have a simple
> dropdown showing active and inactive tools with a tick next to the active
> ones. To hide a tool click on a close button on the tab.

Bug 1238982 has some mockups; I notice this bug has no designs attached to it.

Comment 14

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

@gasolin: is this something you are planning to work on?

Comment 15

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

@bgrins: Do you know which devtools.html work is blocking this?

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

There is a comment at the end of bug 1245921:

"I had discussed this with bgrins, and the plan was to do the whole toolbox in one go because of a XUL layout issue that affected the HTML tabs."

Which also makes this bug depend on bug 1178254

Comment 17

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Bug 1178254 is about converting the toolbox to HTML.

Comment 18

[Brian Grinstead [:bgrins]]

Changing dependency to match the engineering bug for the HTML conversion

Comment 19

[Brian Grinstead [:bgrins]]

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #15)
> @bgrins: Do you know which devtools.html work is blocking this?

Lots of moving parts here as you pointed out.  The main things are bug 1245921 and bug 1178254, which then depend on the splitter conversion bug (bug 1260552).

Comment 20

[[e-mail]]

As I know we have to convert the toolbox to HTML (bug 1251394) than we can work on the dependent bugs in main panel. 

Though if we want make a safari like UI in this bug, it might be a related independent work. (If we can load html page in toolbox panel)

Comment 21

[Anthony Ricaud (:rik)]

That UI mockup is not changing the way non-default panels are added. Is that the correct mockup?

Comment 22

[Patrick Brosset <:pbro>]

Mike, this is a thing we've discussed many times over the past, I would really love to have that. Having said this, it's not been a priority for us recently unfortunately, and I know you are working on other bugs at the moment. So maybe un-assign yourself?

Comment 23

[Brian Birtles (:birtles, Feb 26~ parental leave)]

This might be a separate bug but we should also consider how to guide users to install other DevTools add-ons (e.g. React, Redux etc.). Perhaps we can guide them to the AMO DevTools category with a "More..." type link, or even bring up the AMO content in-panel?

The add-ons team is pushing discoverability this year and there is an opportunity here for that.

Comment 24

[Patrick Brosset <:pbro>]

(In reply to Brian Birtles (:birtles) from comment #23)
> Perhaps we can guide them to the AMO DevTools category with a "More..." 
For info, currently Honza and I are the maintainers of this category. If people find other DevTools-related addons that should be added there, they should let us know.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 6 See Also bugs.
:ochameau, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 26

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.