Open Bug 1239859 Opened 9 years ago Updated 2 years ago

Make it easier to discover tools in the toolbar tabbar

Categories

(DevTools :: Framework, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: bgrins, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs, )

Details

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

Attachments

(1 file)

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.
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)
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
Attached image Exemple of Safari 9 UI (deleted) —
Depends on: 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
(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)
(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
(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.
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)
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
Bug 1178254 is about converting the toolbox to HTML.
Changing dependency to match the engineering bug for the HTML conversion
Depends on: 1251394
No longer depends on: 1178254
(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
Assignee: mratcliffe → nobody
Flags: needinfo?(mratcliffe)
Blocks: 1444299
Blocks: 1444311
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.
(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.
Product: Firefox → DevTools
Severity: normal → S3

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.

Flags: needinfo?(poirot.alex)

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.

Flags: needinfo?(poirot.alex)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: