Tree navigation features

#1

Hi! :slight_smile:

In futureland, I’d like to be able to reveal the selected element in the structure tree. Sometimes the selected element is a scroll away or it’s in a collapsed parent so that little blue selected indicator isn’t visible (btw it’s a little hard to see because its so small).

The problem I’m trying to solve is that when I want to rearrange elements in computed mode, I need to drag them around in the tree structure. So once I have the element I want to move selected, then I have to hunt it down in the structure tree.

I know I suggested a solution at the beginning but I’m open to other solutions. I’m not sure where I would like the selected element to appear in the structure tree.

  • It could go to the top of the structure panel but what if it’s at the end of the structure and the panel isn’t long enough for it to be at the top?
  • Same problem with having it move to a position just above the History panel.
  • Then maybe we get into conditions about where to display it based on its position or the length of the panel.

Just wanted to put this on the list for later.
Thanks!

#2

I'd love this feature too.

#3

This is on our roadmap, but TBD because of fiddly details. In particular:

  • should the tree be scrolling around to make sure your selected element is always visible?

  • what about when you deliberately close things so that you have a tidy high-level tree view --- then any clicks on collapsed elements or their descendants will mess that up by uncollapsing the parent.

    • unless they automatically collapse again when you select something else?

  • should collapsed elements expand when you drag over them during structural rearrangements or dropping images into Subform? Should there be a few second delay, like how OS X finder will open up folders during drag/drop?

Feature request/improvements – Release 3338
#4

These are all great usability solutions Kevin. My thoughts on your suggestions/questions:

Yes to:

Yes to:

I would add that just clicking off of the selected element should trigger the auto-collapse of the parent if that was what the user set initially (apologies if that is what you meant)

Yes to:

#5

A couple other ideas from my personal notes on this topic:

Collapse/expand all descendants. This would be an operation on an individual tree node, essentially a "bulk operation" of the collapse/expand arrow. This could help with visual management of the tree:

  • You might want to see just the immediate children of a parent, but no further down the hierarchy
  • You might want to collapse all the tree nodes on an artboard
  • You might want to expand all the descendants of a node

This is somewhat similar in function to "collapse all groups" from Photoshop.

Hover identification. It can be useful to know where an element lives in the tree without having to click it on the artboard, or vice-versa.

We could outline both the tree node and element on the artboard when they are hovered. (This is similar to how reordering elements in the tree works right now.)

This does raise a few questions:

  • Should the tree view change if you hover an element on a non-active artboard?
  • Should the tree scroll if you hover an element on the artboard that's scrolled off the tree view?

My initial take is that for simplicity's sake, the answer is probably "no" to both of the above questions.

#6

This is something I've struggled with as well. I remember thinking that one way to address this might be to "highlight" all the elements of the path-tree that the node you've clicked on is inside of, and not to expand / collapse anything so that it respects what the user has closed. With the highlight, it allows the user to quickly know which tree to expand if they need to dig into it to get to that child. It would be an improvement because right now you don't really have any context of which tree you're in if you have clicked on a collapsed node.

#7

A variant of this would be to have this behavior, but offer a "show this element in the tree" context menu item that would explicitly expand the tree such that the element's node can be highlighted.

This would preserve the "tidiness" of collapsed trees by default, but give you the option to override when you need to operate on the tree node.

#8

@ryan, I'm a fan of that idea --- it'd be straightforward to implement, may solve the need, and doesn't keep us from adding at some point in the future anything discussed earlier in this thread.

#9

Highlight parent when collapsed
I agree with @ldubya. This idea appeals most to me and has been in the back of my mind while using Subform recently.

I scroll through the tree trying to see which box corresponds to the one I have selected on my artboard. I do this often because I want to select its parent -- especially when the children fit snuggly inside their parent or otherwise have trouble clicking on invisible boxes. I find myself looking for an indicator that would tell me which node I need to expand to find my selected box. I'm happy to manually expand nodes down the tree to reach my selected box.

What should be highlighted? Should it have the same or different highlight from the selected box? If the selected box is 4 levels deep and you expand the first node, does that first node need to stay highlighted? I think it should no longer be highlighted. I also think that the highlight/indicator for the node that contains the selection must look different than the highlight for the selection. There should only be one of each highlight/indicator type.

However! Perhaps there is a keyboard command I haven't learned that would be a better solution to my problem: click the child and navigate up or down the tree with a key.

Reveal element in tree
This seems like a good idea to me but slightly less appealing than the highlighted/indicated parent.

Hover Identification
I'm neutral about this idea.

Collapse/expand all descendents
I don't think I'd use this much.

Auto-scrolling tree to selected box
Despite suggesting this myself, I now believe I'd dislike this feature. I prefer having control over the view of the tree, even if I have to manually adjust it.

Auto-expand/collapse tree based on artboard selection
Again, I prefer having control of the tree view. To be clear, the auto-expand would happen when you select a box that is inside a collapsed node and auto-collapse would only happen when you select elsewhere AND the node had been auto-expanded, it wasn't manually expanded. I can imagine auto-expand/collapse being equally nice and annoying, depending on what you're trying to do. Nice when you want to keep the tree tidy, annoying when you were expecting to see a node open and it isn't anymore -- thwarting your brain's attempts to be efficient thru pattern recognition.

Auto-expand for drag'n'drop structural rearrangements
That might be nice. The delay is important. Does the node collapse after you move your cursor away? Is there anything that would cause the tree to jump around based on this behavior? It can be hard to get this interaction right. If you don't have a delay, then a node expands and you have to scroll down to get to your target. If you scroll past an expanded node, does the next node suddenly jump up above your cursor because its sibling closed?

#10

Just as an FYI if you click on a box, pressing Command + Up selects its immediate parent. (could be control or option instead of command, it's been a while since I used it)

I really think you need to highlight the entire parent tree, down to the selected node. And the highlighted parent tree would look different from the selected element. for example: when you select a box right now and it's visible in the tree, it already indicates which box you have selected. So the highlighted parent-tree would be in addition to that.

I think an auto-scrolling tree would be frustrating. If I wanted to scroll to a box, maybe I'd try to right-click the box and look for a "reveal in tree" option.

#11

Awesome! Thanks for the tip @ldubya!

#12

As of release 3520, you can reveal an element in the tree by right-clicking on the element and selecting "Reveal in tree."

Additionally, when the selected element is below a collapsed node in the tree, the visible ancestor of the selection is now indicated.

#13

Been dipping in and out of using Subform since the Kickstarter. Recently though, it’s gotten really nice. Performance is a lot better and the layout tool is amazing.

I took a design I was doing in Sketch and ported it over the Subform. My biggest gripe was in the selection and traversal of layers and groups.

Selecting an element doesn’t reveal it in the tree. The new shortcut is good, but still far too slow. Sketch have gotten the layer selection, group thing down to a tee.

You can select an object, tab to its siblings, esc to its parent and enter to its children. Subform seems aimed at the power user who doesn’t want to waste time. I’d consider myself one. I am wasting a lot of time selecting layers.

I understand Subform isn’t Sketch, but being able to quickly traverse layers and groups is crucial to a speedy workflow.

Thoughts?

#14

Hey @rorysmyth, I merged this with the existing tree navigation discussion so we don’t have two topics discussing some of the same ideas.

Thanks! @kevin has been working really hard on benchmarking and improving performance, so glad it’s showing up for you.

So this sort of tree traversal is possible right now in Subform:

Move between sibilings is ⌘← and ⌘→.
Moving up to the parent is ⌘↑ and down to a child is ⌘↓.

(If you’re on Windows, substitute ctrl for ⌘.)

Speed of work is a long-term priority for us, definitely. If there are other shortcuts like this that would help with the tree, we’d love to hear your ideas.

#15

Top stuff! Didn’t know about this. What ties it really nicely together in other products is that the layer panel would scroll the selected layer into position and basically do a ‘reveal in finder’. Makes the traversal a lot easier when you know what’s around that layer.

#16

We’ve talked about scrolling the selected tree node into position, but preference for that seems doesn’t seem to be unanimous. (@nicki and @ldubya above mentioned that they aren’t in favor of that behavior)

We could make it an option, but I think Kevin and I would prefer to settle on a default behavior that works for most folks.

I think the tension here is between always having the selected item visible in the tree panel—versus the designer having full control of the tree view.

One potential way to split the difference would be to scroll to the selected element into view when using “reveal in tree,” but not otherwise.