Feature: Design Tab (WIP)

[argyleink]

preview of current status

Design Tab

• can show layer tree for selected elements with visbug
• right click inspect that launches visbug and jumps to style inspect tool

Custom Panels

• ability to extend elements panel
• first features are about meaningful style rollups, high level data, (wip)
• hope is to help folks move into richer parts of the devtools

[argyleink]

comp of an early idea i'd like to show

[thundernixon]

Ideas here that I love:

• Calling this a Design tab.
• Exposing the DOM tree view along with the tool, to better show the document structure and more easily. If I think about this from a Sketch / Photoshop mindset, the DOM view is a lot like a "Layers" palette. I think you're already somewhat treating it like this visually, which is really nice. It might be possible to push on this, even more.

Things to possibly explore:

• Potentially, this Design tab could be a bit more like the current Elements tab, and this might also make it more like familiar design tools. That is, instead of showing just the tree view and leaving the toolbar in the main/live webpage area, the tools could be moved into the devtools drawer, perhaps in some kind of expanded form. This would leave the webpage area as the "canvas" for selection, pixel-pushing, and visual output, while the "inspector" or "toolbar" value inputs and tool selections are in the devtools drawer – mimicking the current interaction models of both design tools and browser devtools.
  • You're pretty much already showing this idea with the mockup directly above, but that specific example is pretty confusing for me, as it is right now. I think the main problem is that it appears that the canvas is suddenly in two places at once. This gives the appearance that there are suddenly two webpages/canvasses and two (or more) toolbar areas.

Here's my first pass at this might look like.

Hotkeys and tooltips would be accessible behind the ℹ️icon. Mode could be activated by hotkeys, or by a user's manual input in one of the fields.

Notably, I think that the tool palette should not be present on the webpage/canvas area while the devtools drawer is open.

---

Alternatively, it could be that I'm just not quite grasping your idea, and that it might make sense with an animation or a few images to show the workflow. Questions I have are:

• What is the colorful area above the webpage?
• What value is offered by the mini-canvas within the devtools drawer? Is that just the tooltip animation, or something more interactive?

[argyleink]

Cool comp! I see "multiple" in there ;)

real quick answers

• the colorful area above the webpage are the responsive tools the devtools provide today. really slick way of resizing the webpage and testing various sizes https://developers.google.com/web/tools/chrome-devtools/device-mode/
• the mini-canvas is like isolation mode in illustrator or sketches like instance/symbol mode, it's not very valuable in that comp shown, but in a large page it could be really nice. i'm also not sure how it would work with multi select.. but the effect was going to be the same as a "double click" does in a design tool, but on the web. it was also intended to help pave a bit of a design path for "component tinkering," like framerX tinkering but with the web components on the page 🤷‍♂️

i like that you took at stab at representing each tool in a panel, i've never seen that yet, just been thinking about it. it's a cool take, very thoughtful, very good companion to the current experience! there's a lot of work to get to that comp, but i think it's very much towards what's needed for this to kinda "grow up." we should riff on it more, wait for piping to get setup to support it.

as a growth path towards that, we could make an iteration that's part of the way, and starts training folks about the ux pattern. think about the tooltip panels that fly out on hover, we could use their position and cards to be contextual panels. example ux being, while using the margin tool, i see the margin panel. so instead of keeping a whole sidebar in the devtools extension stateful, we keep 1 panel at a time for now, let certain tool opt into the feature and maybe try it out slow. like i think i could pop a prototype branch out pretty quick that had 1 panel, for let's say margin, that could offer a decent start to the features shown in your comp and margin panel.

this is cool, very thought provoking, and thanks again for the thoughtful design

[thundernixon]

the colorful area above the webpage are the responsive tools the devtools provide today

Ahhh thanks! I use the device mode all the time, but I wasn't aware of the "Show Media Queries" feature. Very cool!

the mini-canvas is like isolation mode in illustrator or sketches like instance/symbol mode

Very interesting. I could definitely see that being useful in various ways. For one, it would be great to keep the animated tooltips somewhere. But especially if it offered a way to tinker with components, that would be cool. I suppose your example was a bit confusing to me in part because the component area completely reflects the webpage area.

each tool in a panel ... there's a lot of work to get to that comp ... we should riff on it more, wait for piping to get setup to support it.

Definitely! I know this kind of thing is far out in the future. I wanted to get down some version of what I had in my head when I heard "this will eventually be in the devtools area." I know it's not the version, and I know it would take a lot of steps to get there. As you say, it would be good to start by showing one tool at a time. For me, the single most important thing is giving immediate visual feedback to a user that their inputs are being registered – for instance, as I showed in this mockup of issue #246.

Just now, I was playing with VisBug on a site, enjoying the way that Hue Shift allows me to experiment with colors for many objects at once ... but also finding it hard to be sure when my key inputs were and were not being registered. So, I was really wishing for some visual feedback beyond just the elements gradually updating. I'm not super particular about the exact form that feedback takes, but I'm just trying to toss some extra possibilities into the stew.

If there's a branch for this at some point, I'd love to test it out!

[tadeuszwojcik]

@argyleink, @thundernixon all of this looks awesome, but is that possible to build as devtools extension (given extensions constrains)?

[LouisStAmour]

Huh, I’m actually quite excited by all this UI. Looks like it would be a great way to help train people on keyboard shortcuts also. I’m reminded of how the MacOS menu naturally lets you know what keyboard shortcut you can use as you go, or how Photoshop, slightly opaquely, shows you some shortcuts in tooltips. It’s possible the first iteration of the UI is more of an interactive, responsive set of keyboard shortcut documentation that suggests what you can do within that tool or mode and highlight current status or any warnings for unexpected behaviour? It might be easier to mock that up via codegen, if it doesn’t exist already?

Oh but I started my reply to ask if anyone’s actively working on this, I’d be happy to contribute some time towards creating some code for this in the next couple weeks, if there’s room for it.

[LouisStAmour]

Perhaps a history panel of what actions were taken would be a nice feature, particularly if you wanted to share a before and after, or step-by-step, and undo/redo part of your actions, or re-apply an action to other items? Hover and suggest other selections or suggest manipulations with a selection, might also be an interesting UI concept.

[argyleink]

what @thundernixon created is def doable, some of the piping has been setup in #205 👍

@LouisStAmour happy to help you get started if you want to hack on it! ping me on gitter for realtime chat. also, your idea about change history, lay down some of your thoughts here #168!

love the chatter!