Keyboard shortcuts and freeform


#1

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


Shortcuts & preferences?
#2

I have the same issue. For the tool to be easily usable for me I need some basic keyboard shortcuts to work:

  1. Ctrl + C, Ctrl + X, Ctrl + V (Copy, Cut, Paste)
  2. Alt + Drag (Duplicate somewhere)
  3. Arrows (Move by 1 pixel in self directed mode)
  4. Shift + Arrows (Move by 10 pixels in self directed mode)

This is the bare minimum I use most frequently in photoshop.


#3

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.


#4

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. :slight_smile:


#5

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


#6

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)


#7

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:

  1. See the layer that needs change
  2. Select the layer or traverse to it
  3. Look at the properties
  4. Adjust the property

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.


#8

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.


#9

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.


#10

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.


#11

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.


2017.10.09 Subform release 3837
#12

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.


#13

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.


#14

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.


#15

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.


#16

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.