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.