Locking behavior

#1

Hi friends,

@ryan and I are working on some new direct manipulation features, and while we’re designing those behaviors we ran into some unresolved questions about “locking”.

So we thought we’d ask ya’ll for your considered, experienced digital designer thoughts = )

In particular:

  • Should locking prevent you from editing an element entirely?

    • or just certain attributes (e.g., you can change styles but not layout)?
    • or just certain editing mechanics (e.g., you cannot select or direct manipulate the element directly, but you can still select and edit via the tree, sidebar, and keyboard commands)?

  • If a parent is locked, are all of the children implicitly locked as well, or can they still be edited?

  • Can you delete a locked element, or do you have to unlock it first?

  • Can you drag other elements into a locked one?

  • Can you select locked elements? If not, then it seems like elements should be unselected as soon as you lock them? (Which means there can never be a keyboard shortcut for “unlock”.)

#2

Hi,

To answer your questions we should establish the reason for the need to lock a layer. In the design process, I usually lock a layer for two reasons:

  1. To prevent any changes from being made to that layer
  2. To get it out of the way when selecting and making changes to other layers near that locked layer

To answer your questions, I think:

  • Locking a layer should prevent you from editing an element entirely
  • Locking a parent should automatically lock the children too but probably allow you to unlock the individual children via the tree by toggling on/off some sort of a lock icon. Locking the parent in this case would behave like a “lock/unlock all elements” (I’m not entirely sold in this “lock/unlock all” functionality yet but just throwing it out there as a possible use case).
  • You should be able to delete an element only if it is unlocked
  • Because one of the needs for locking an element is to prevent editing it, you should probably not be able to add or remove elements into or out of it
  • You should not be able to select a locked element at all (not even in the tree). To select a locked element you must first unlock it by clicking on the lock icon next to it in the tree. I would suggest adding a sort of filter at the top of the tree (i.e. a lock icon) that can be toggled on/off so that we could show all the locked layers in the tree for quicker access to them.
#3

Thanks for the reply!

Does Sketch’s behavior (disallowing direct graphical selection/manipulation, but allowing it in the tree) bother you, then? Can you elaborate more about why you want to prevent changes via locking? Are you trying to prevent yourself from making accidental changes? Or are you communicating to other team members who use the same file that that layer is “done”?

Ryan and I first went down this path — actually showing lock icons for all the children — but then realized that, if the children are all locked, what’s the point of even seeing them?
That’s how we got to the current behavior of rolling up parents in the tree view when they’re locked.

What if a child is locked, but its parent/ancestor is unlocked and you try to delete the latter?
Should that throw an error: “Cannot delete because this contains a locked element”?

This is a cool idea, I wonder if we should put some other filter stuff in the tree (or command bar) to also search via name, visibility status, etc.

#4

I agree with Benzo in that we should first understand users’ goals in wanting to lock layers in popular design applications available today. If users want to prevent specific changes to a layer and/or its children, is there a more intuitive way to enable this behavior without all the baggage (i.e. cognitive load) that comes with ‘locking’ layers?

My general thoughts on the matter are:

  • Avoid ‘throwing an error’ at all costs: instead seek to enable or disable specific sections or input fields whenever a locked layer is among the current selection of layers. In other words, “Don’t tell me I did something wrong. Instead, help me avoid ever doing the wrong thing.”
  • No one will nor should have to remember every behavior of a locked layer: let’s try to follow the core heuristic of ‘recognition rather than recall’
  • Perhaps rather than ‘locking’ layers we need a different mental model about the types of interactions that users will perform on objects in Subform.
  • I think we discovered a more compelling feature via the filtering of layers in the tree based on specific properties
#5

I agree w/ both ya’ll, hence this thread = )
@Benzo’s explanation of “because I want to prevent any changes” makes sense, but it makes me wonder why Sketch’s locks don’t work that way — you can still change things via the tree and toolbar.
So I’m trying to dig deeper into this story.

I should have been more specific — by this I meant show a message in the new status bar at the bottom of the screen.
It wouldn’t be a pop up that interrupts your flow, but rather background feedback to help you understand why, e.g., their delete command had no effect.
This is a concrete realization of the “recognition vs recall” guideline you mentioned.
Do you think there may be a more effective way to provide this feedback?

#6

Sorry for the delayed response.

The reason why I lock objects when designing is specifically to prevent accidental direct manipulation of those objects while selecting/moving/editing groups of objects. I haven’t found Sketch’s approach of letting you manipulate locked objects in the tree problematic, so I don’t have any strong opposition to the concept.

The question to ask here is wether there would be a case where a user might want to unlock a child to make a change to it after having locked a parent with lots of child components in it. So, it would be a quick way to only select on child component from many for manipulation without having to lock all of the other child components individually. This would translate to the following quick steps:

  1. Lock parent component (with 25 child components) in tree
  2. Unlock 2 of those child components for manipulation

I think that if a user is deleting a parent component, they probably want to delete it’s child components too, however if they only want to delete the parent they would have to separate it from the child components. The conventional approach to creating parent/child hierarchy is by using “grouping” but Subform does not allow grouping/ungrouping, so quickly separating a parent and it’s child components is not as straightforward.

#7

Thanks for the detailed reply @Benzo!

It sounds like your motivating use case for locking is to prevent accidental direct manipulation, which is the real problem to solve.

Subform’s still pretty early in terms of direct manipulation — there is no lasso or real multiselect, keyboard nudging, or other features.

Ryan and I have some new stuff planned in that space, so it might be best to revisit the question of “preventing accidental manipulation” once we have some of that stuff shipped and ya’ll can talk about specific cases where accidental manipulations come up.

(Of course, if other people have different use cases for locking, please chime in!)