Make it easier to discover tools in the toolbar tabbar

NEW
Unassigned

Status

()

Firefox
Developer Tools: Framework
P3
normal
2 years ago
3 months ago

People

(Reporter: bgrins, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [devtools-ux][devtools-toolbar], URL)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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?
Flags: needinfo?(hholmes)
(Reporter)

Updated

2 years ago
Whiteboard: [devtools-ux] → [devtools-ux][devtools-toolbar]
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.
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.
(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
Created attachment 8708298 [details]
Exemple of Safari 9 UI
Depends on: 893583, 1238982
Flags: needinfo?(hholmes)
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.
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?
Flags: needinfo?(bgrinstead)
No longer depends on: 1238982
(Reporter)

Comment 8

2 years ago
(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.
Flags: needinfo?(bgrinstead)
See Also: → bug 1238982
(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
(Reporter)

Updated

2 years ago
See Also: → bug 1241298
(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.
(Reporter)

Updated

a year ago
See Also: → bug 1282027
See Also: → bug 1226272
Assignee: nobody → mratcliffe
@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.
Flags: needinfo?(hholmes)
(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.
Flags: needinfo?(hholmes)
(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.
@gasolin: is this something you are planning to work on?
Flags: needinfo?(gasolin)
@bgrins: Do you know which devtools.html work is blocking this?
Flags: needinfo?(bgrinstead)
Depends on: 1245921
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
Depends on: 1178254
Bug 1178254 is about converting the toolbox to HTML.
(Reporter)

Comment 18

a year ago
Changing dependency to match the engineering bug for the HTML conversion
Depends on: 1251394
No longer depends on: 1178254
(Reporter)

Comment 19

a year ago
(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).
Flags: needinfo?(bgrinstead)
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)
Flags: needinfo?(gasolin)
That UI mockup is not changing the way non-default panels are added. Is that the correct mockup?
Summary: Make it easier to select a non-default panel → Have better panel management
See Also: → bug 1335608
Comment hidden (obsolete)
Assignee: mratcliffe → nobody
Flags: needinfo?(mratcliffe)
You need to log in before you can comment on or make changes to this bug.