Interaction Design Pattern - Selection Trail
The purpose of this article is to introduce an object selection interaction design pattern to accompany the Bounding Box Selection Pattern. In comparison, it enables users to have more precision with less input for certain object selection and deselection scenarios. It leans as a power-user feature but could become as commonplace as bounding box selection.
I’ve dubbed this pattern Selection Trail. Here it is in action:
Bounding Box Rigidity
As you can see, this pattern replaces a bounding box selection with a free-form selection. The main use cases for it are when a bounding box is too rigid. Rigidity comes in the form of:
- Over selection - too many objects were included in the group selection
- Under selection - too many objects were excluded in the group deselection
In both cases this happens by the nature of a bounding box being a rectangle shape. Selection Trail on the other hand frees up the user to be much more precise. It doesn't replace bounding box selection, but instead accompanies it as a more flexible tool. Its value increases as a function of object count, type, and proximity increases. That said, I've found it useful in simple scenarios too. If you want to skip ahead to play with it, feel free to launch the prototype below.Launch Prototype
I was recently exploring an awesome visual editor for game designers called Inkarnate and I found myself wanting more precision when selecting and deselecting objects. In one specific scenario I wanted to quickly select all the individual mountain objects comprising the mountain range on the left side of the island.
To achieve my desired selection requires at least two bounding box selection actions combined with additional ctrl+clicks to add or remove individual objects if the bounding box selections weren't perfect. This is when the idea surfaced. What if I could just make my selections as if I was painting? With Selection Trail this becomes one trivial and fluid action.
There were a few more unique selection scenarios that are difficult to describe so I settled on this one example. If you stop and think, I'm sure you've experienced many such selection and deselection scenarios in creative authoring tools where Selection Trail would have been preferred. Inkarnate does provide some additional selection tools to help aid granular selection like Right click > Select > All like this but that is an all or nothing action and didn't solve for my scenarios.
Selection Trail is also general enough that many other applications would benefit from implementing it. In fact virtually all visual design editors and creative authoring tools would benefit from implementing it. A shortlist includes:
- 2D tools - Figma, XD, Sketch, Illustrator, etc.
- 3D tools - 3DS Max, Maya, Blender, Unity, etc.
- Multiplayer whiteboards - Mural, Miro, Excalidraw, etc.
Each app above (among many others) could immediately adopt the pattern and thus expand their feature-set to improve their users' productivity, UX, and flow-states. I could even see an argument that the pattern could be used in operating systems like macOS, Windows, Linux, etc. but that use case is less strong.
Users want to precisely select or deselect multiple objects efficiently. The status quo of click and drag bounding box selection tools requires additional clicking when not all objects in the bounding box are the user's intended targets of selection or deselection.
Multiple objects need to be selected or deselected but the status quo click and drag bounding box option requires additional clicking to complete the user's intention.
Allow for a user to communicate their intent (most commonly via shortcut key modifier) to use the existing click and drag interaction but as a cursor trail instead of a bounding box.
Add a modifier shortcut key, keys, or dedicated tool that:
- Tracks initial mouse down to begin processing the updating of a
- Tracks mouse dragging cursor positions at some interval
- On the interval tick validate if the current mouse position is in an object's bounds (for higher precision use its silhouette, pixel alpha threshold, etc.)
- If validated, append it to the
selectedObjectIdsarray (if already in the array ignore or remove as desired)
- Updates the corresponding object selection changes in the UI
- Tracks ending mouse up to stop processing the updating of the
- Desired selection results
There are no known Selection Trail implementations that I am aware of outside the prototype I built. Free-form Selection and Lasso tools have some similarity implementation-wise but focus on pixels not objects. As mentioned before I believe virtually all visual editors and creative authoring tools that leverage the concept of objects, grouping, and ungrouping would immediately benefit from this pattern.Launch Prototype
Selection Trail is a very useful and natural pattern to introduce to existing tools and editors. It has a familiar UX when compared to bounding box selection which almost guarantees that it will be easy to adopt. Ultimately, it enables users to have more precision with less input as they don't need additional steps to modify unwanted selections or deselections that resulted from the rigid bounding box approach.
If you are a Frontend Engineer, Product Engineer, or Designer that contributes to getting this landed in a product you work on, I'd love to hear about it. Feel free to use the source code link below as a jump-off point. If you have any thoughts regarding the pattern, don't hesitate to contact me on Twitter @derekknox.View Source