When making first round mockups I see myself using free form tool to get a quick idea of how things will layout - then going back and starting to properly nest and change objects to computed. Right now free form is not the default which makes this difficult. I would get a huge productivity boost by being able to click f (something on left side of keyboard). this would activate the freeform tool - I could then draw it where I like (don't auto insert it and require click and drag)
Thanks
I have the same issue. For the tool to be easily usable for me I need some basic keyboard shortcuts to work:
This is the bare minimum I use most frequently in photoshop.
Hi @gejoreni,
You can add “freeform” or self-directed boxes by clicking the “add box mode” button and then clicking-and-dragging out a box. Here’s a video for what that looks like:
Is that the behavior you’re looking for?
You’re right that we’re missing a keyboard shortcut for the add box mode, it’s assigned to shift-enter, but it looks like it’s not working properly in the current build. We’ll get that fixed up.
We’re working on standardizing the keyboard shortcuts. In general, our goal is to keep them aligned to Photoshop and Sketch shortcuts where possible.
There are a few things that take keyboard shortcuts from let’s-fix-these-real-quick to this-is-more-complex-than-it-appears:
Cross-platform: Windows and MacOS have different patterns (e.g. ctrl-vs-command) and system-reserved keystrokes, so not everything can be exactly the same between these versions of Subform.
Internationalization: Different keyboard layouts can cause problems. We’ve already run into this a couple times.
Places where Subform conceptually differs: The shift+arrow nudge by 10px example is a great one. That’s pretty straightforward in a standard drawing app and we can do it for self-directed elements. But what happens for parent-directed elements? What if you have both a self-directed and parent-directed element selected? We have to design all this behavior as part of implementing the keyboard shortcut.
Modes: Similar to the above, depending on what mode you’re in, keyboard shortcuts might need to be disabled or change in their behavior. We have to think through all the states, document them, implement the logic, and then write tests so we don’t accidentally break things in the future.
Long story short, I agree that the keyboard shortcuts need work and will go a long way towards usability and speed in Subform. We’re actively working on it. 
Any chance you could open up the keyboard shortcuts as options? Let the user define the keystrokes?
For ex, tabbing is reserved for the HUD. But I want to move through layers a lot more than I need to glance at the HUD. Yet to move through layers is 2 keys. cmd+arrow. These are spaced too far apart and requires me to take my hand off the mouse each time. I would like to define my own shortcuts for my own workflow. It’s currently not very efficient.
Also, is there a shortcut for renaming layers?
Basically, shortcuts need some love
Hey @rorysmyth, moving this over to an existing topic.
We’re in the process of improving/standardizing the shortcuts and building out proper application menus right now. Where it’s possible, we’re putting the shortcuts next to the menu item, and actually in the context menus as well. (A lot of apps don’t do this, which is annoying)
There’s a little complexity with this (see my post above), but I think we’ll have a good baseline here shortly.
Custom shortcuts aren’t on our near-term roadmap at the moment.
Nope, but I think we can get that in with the other changes. Do you have a preference on what keystroke combination you’d like for this? Sketch uses ⌘R, I don’t think Photoshop has a default shortcut for this.
Tab actually is reserved for shifting focus between inputs now, alt triggers the HUD?
Yeah, can see that having to take your hand off the mouse to select different elements isn’t ideal. Do you have a sense of what keys you’d prefer here? I think we started with the arrow keys because they make it relatively straightforward to navigate the hierarchy (e.g. up to parent, over to sibling)
Ah wondered where that went.
The canvas is my focus when designing. The layers. What layer am I on. How do i get to the one I want. How can I change what I see. Off the top of my head, 3 products I use weekly. Sketch and Principle and sometimes Figma. They all have tabbing for tree traversal. Just makes sense. Shift tabbing for going the opposite direction (some are enter for going into the children). But I tab through everything I use. Browser, finder, whatever.
What’s jarring for me is that the focus is on the properties bar when I’m focused on the canvas. Right now If I select a layer and want to change the height, I select it and press tab 7 times. That doesn’t seem right. I’m going to move the mouse every time. Over to the field and click. Way quicker. So maybe free up that tab for something that will be used more often? That being said, once I focus on an input by clicking, tab focus should be given to the properties pane.
The properties are secondary in my decision making process. My thought process is usually:
If the layer has lots of stuff around it, or is not easily clickable (pretty common), I’ll start tabbing around to get to it. That 8x8px icon is in the same group as the text layer. I’ll just select that and tab to it. If I’m really having issues, I’ll start to look at the tree and find it manually (last resort)
cmd+r seems universal at this point. That would be great.
That will be awesome. If I can map my own via the system, that’s just as good.
Should also mention. it’s a question of hand placement. The tab key sits in a quiet area to the left of my hand. Very easy to get to. Close to where it’s resting naturally on the keyboard. I can use that and the right hand (on the mouse) at the same time in a really efficient way to move through the canvas. Combine that with esc and it becomes even quicker.
I have never examined how my hands work when designing, but I do notice when it’s not easy. I don’t notice them with other apps. I hope this helps.
There are some semantic differences in Subform that make tab tree-traversal a little different, primarily that Subform has a true tree topology. Elements in Subform have parents, siblings, children, etc, while layers in Sketch/Figma/Photoshop have a flat hierarchy.
The closest equivalent is probably “groups” in those tools. Is there a way to navigate down into a group / up out of a group (or nested set of groups) via keyboard in those tools that you like?
Sure. Right now, tabbing between inputs in Subform—when an input has been given focus—is equivalent to the Sketch’s behavior: tab moves through the available inputs in the sidebar. (There’s one difference in that Sketch will loop through the inputs indefinitely, while Subform returns to an unfocused state after the last available input)
Just to make sure I understand correctly, we’re talking about a separate behavior for tab/shift-tab when an input is not focused, correct?
Yep, think that’s a super important use case. We have initially tackled it with the tree traversal shortcuts (command/ctrl-arrow keys). I know these aren’t working for you because of their location on the right side of the keyboard / requiring right handed people to move off the mouse.
An additional way to come at it could also be to reveal all elements under the mouse in the command menu. This is how Photoshop handles selecting things that aren’t easily clickable via the canvas.
Cool, that was our hope—a lot easier than implementing custom shortcut mapping functionality.
Yes. You can press ‘esc’ and you’ll move back up the tree. Say you’re creating some blocks in subform. You click 3 times to create the items, but you need to select the parent to adjust the layout. How i imagine it working (and how it does in Sketch and Principle) is that you create the items (3 clicks), press esc, then the property panel is active and you can adjust the padding/margin/stacking
To clear up. The jarring aspect to me is that when i select a layer on the cavas, and I tab, it takes me through the properties. Sketch doesn’t do that. It tabs you through the siblings of the layer you just picked. It’s only when you focus on the property panel that tabbing through the inputs happens.
I wouldn’t look to Photoshop for inspiration. Its a photo editing tool. If Im editing a photo I might have 30 adjustment layers that all feed into a single image. I might need to select the layer that deals with some adjustment on the hand. With UI I can see very clearly the part I want to select. It would definitely be useful, but maybe not as a primary solution to the issue. Sketch has this right click feature and I haven’t used it once. I know it exists, but it’s next to useless to me.
Have you thought about setting up remote sessions with designers? Observing how they work? Could be insightful.
OK, so the mapping would look like this:
| Shortcut | Command |
|---|---|
| Tab | Select next sibling |
| Shift-tab | Select previous sibling |
| Esc | Select parent |
| ??? | Select child |
We’d still need to figure out a shortcut for moving down a level / selecting a child.
Escape is also doing double duty here, it moves up a layer until it can’t anymore (the artboard is selected) and then the next hit of esc functions as “deselect.” Would it make more sense to have a separate shortcut for deselect?
Right now, add box mode supports adding boxes into any element on the artboard, not just the one you’ve selected. Pressing esc exits add box mode and the selection stays on the element you had selected before entering the mode.
We don’t really have a way to interpret the designer’s selection intent after exiting box mode. We could bring focus to the layout panel for the (previously) selected element, but I’m not sure that’s your intent as per above.
We’ve done quite a bit of this. We haven’t specifically tested input speed / keyboard shortcut preferences yet, because we haven’t had those pieces in place. With the next release having proper application menus and a reworked set of keyboard shortcuts, this is something we’ll be able to test going forward.
Layers
| Shortcut | Action | Condition |
|---|---|---|
| Enter | Select child | |
| Enter | Highlight text in edit mode | current layer is text (text layers in subform can’t have children so why not use this?) |
| Esc | Select parent | |
| Esc | Select no layer | current layer is last item in hierarchy |
| Tab | Next sibling | |
| Tab | Previous sibling | |
| Cmd+R | Rename |
The left mouse key is used to deselect at any point. Clicking anywhere on the canvas would take focus off the element and allow you to start the process over. I think most Sketch users work like this from what I’ve seen. Don’t think another key is needed. This way feels more natural.
Another useful key in Sketch is when you edit a property. Pressing enter twice on an input removes focus from it
https://gfycat.com/gifs/detail/UnnaturalParallelCaribou
Allows you to move through layers and edit properties. See how I can keep my mouse and focus on the properties panel and tab through the layers at the same time.
Isn’t enter for child selection a little awkward, given that you prefer not to take your hand off the mouse to move through the topology?
One possible alternative would be to use control-tab. This is MacOS’ default system behavior for "moving focus to the next grouping of controls in a dialog or the next table (when Tab moves to the next cell).”
Selecting down into the child level is fairly close in spirit to that—and it can triggered without moving your right hand off the mouse.
We’re working this into the new shortcuts, should (hopefully) be in the next release.
It’s never annoyed me and I’ve never noticed it.
Ctrl+tab? Feels very awkward on a MBP. You have the fn key to contend with. Even just using the machine in front of me without a mouse. I can move around on the trackpad with my right index and thumb. Then shoot the right ring finger over to enter. If i’m in traversal mode that sets up the two hands nicely. Right to go to a child and left to move up and around.
Have you thought about just trying them out? Take Sketch, Framer, Figma, Principle etc. The tools we all use and mirror the controls. We can discuss it all day, but it’s about feeling what’s right. Totally happy to mess around with a dev build. I’m sure others would too. It’s your product, but as someone who uses these tools daily, this stuff was figured out a long time ago.
I asked because it’s antithetical to your original requirement of not having to take your hand off the mouse to move through the tree. Moving down is going to be much more common in Subform than in Sketch, because Sketch doesn’t have a formal topology. Preserving the enter key for this will necessitate two-handed operation to step down to a child.
It sounds like familiarity is the primary design requirement for you here, with left-handed keyboard operation being a secondary factor.
Is this true, though? Just a quick look at Figma shows that esc actually doesn’t work the same way as Sketch, it always deselects instead of moving up to the parent group. And enter selects all the children in a group, rather than the first one, like Sketch. That’s different behavior.
I’m not trying to be pedantic—I think this is great feedback and we’re generally in favor of keeping consistency with patterns from existing tools where we can. I just want to make sure we fully understand the assumptions and reasoning behind making this change and how to handle the potential edge cases / side effects.
Implementing this affects existing functionality (enter key is already mapped, for example) and introduces a new mode (tab behaves differently when an input is focused versus when the tree/universe is focused). That means a new state for the application, new tests, etc. There’s a heavy cost to implementation for a small team like us, so we like to make sure we’ve got a solid spec before moving to code.
Yeah maybe there needs to be a deeper look at what mapping works best. I use Sketch but maybe someone who uses Figma can perform the task a lot quicker. I don’t know. It’s a huge change. Wouldn’t consider making it lightly if it was my own product either. I’d take some common workflows. Set up the mapping. See how people respond to that mapping. I’m totally biased to Sketch and Principle. They’re my go to tools. You probably need to do a lot of prototyping on something like that?
The hand moves from the mouse all the time. There’s probably all sorts of cases I could outline if I started to observe how i use it (I don’t know what they are. I’m not thinking about it as i’m doing it). It’s probably something that needs to be observed in person to find out what those nuances are. Is moving down going to be more common? Not sure what you mean. I’d expect to interact with a UI i’m creating pretty much the same as any other tool. See an element, click it.
I’m not saying Sketch or Principle have it nailed perfectly. Maybe there’s a superior way of working. Just felt that in trying to work in a certain way in Subform, it felt slower.
Appreciate all the feedback, Rory. We’ve got a few things we need to get to first, but you’ve raised some great questions. I’ll get the ideas written up into an RFC for us and we’ll take a deeper look at it for a future release.