I think spatially, and so do you. Can you scratch your left ear without looking? Pick a booger out of your nose, without poking your brain? Remember where you left your keys? Can you type, without looking at your keyboard? Know which pocket your phone is in? Which way is up? Do you know where the bathroom is? Of course you do! We imagine multi-dimensional models in our minds, to help understand the complex world around us. We can also leverage this powerful way of thinking, to process more abstract information.
The best software is an extension of the brain. It lets us think naturally, and conforms to us, not the other way around. Translation of information is the computer’s job, not ours. A great Spatial Interface meets our expectations of a physical model. They are Interfaces that are sensible about where things lay. Like a well designed building, they’re easy to traverse through. One space flows into the other, without surprise.
To design a Spatial Interface, you need to think inside and outside the bounds of the screen. Think about the physicality of the objects in your interface. Where did they come from? Where will they go? How do they behave in respect to Kinetic influence? Do certain objects inherit physical properties of others? Where are you, relative to everything else?
These are hard questions to answer with words. Seems like a no-brainer, but I find it most effective to solve visual problems with pictures.
Drawing the map
When designing spatially, it helps to imagine an interface as a physical model, which can be manipulated, and travelled through. Rather than placing detached comps next to each other one-dimensionally, try thinking upper-dimensionally.
Here’s a breakdown of the Contextual Zooming paradigm that was key to creating Keezy Drummer.
The 4th Dimension?
You can visualize the relationships between dimensions as extrusions of lower dimensions. Each dimension creates a significantly more complex model to visualize.
We can design with time, by thinking about kinetic, Transitional Interfaces. Both Spatial & Temporal clues lead the eye around physical models.
Manipulating a list
Motion implies space. Movement re-enforces the physical characteristics of the spaces on and off the screen. Objects constrained using sensible, physical rules, help establish a clear model.
We’ve all seen this classic, list item deletion pattern. Swipe the cell, and it reveals a button behind it. Tap the icon, and the entire cell collapses.
What happens if we change the way the list item departs the screen?
If we cushion / ease the item exiting the screen, we suggest where it might stop. In this case, it stops a little short off screen. We might want to do this to imply a holding area, which could feed items back into the list. Maybe we could allow the user to swipe the viewport to the right hand side of the screen, revealing displaced list items.
If the item keeps accelerating, where does it end up? Out of reach? Are we banishing it into the void of outer space?
If the list item rotates and displaces along the x & y axis freely, does it come to rest off the grid? Is there gravity? Maybe it lands in a pile.
Z-translation implies depth.
The list item could flip over. It might fold in on itself like an accordion. Maybe it scrunches. The fill color could drain out of the cell like a liquid. I could go on with visual examples forever, but by now, I think you get the picture; one can encode quite a lot of meaning using motion and space.
Interfaces with tactful Spatial Design
Pretty conceptual, but Scorekeeper does a great job of creating focus. It isolates modes, rather than presenting the user with a bloated buffet of options to dig through. Complexity is hidden in secondary, and tertiary sub-interfaces. Each sub-interface is as simple as its parent.
Tinder famously employs a card paradigm. There’s an endless stack of cards which make use of z-depth. Toss a card from the stack to the right, for a babe you’re into, or throw them to the left to pass. Similarly, if you tap the heart or ‘x’ button, it automatically tosses the card to the respective side of screen, re-enforcing the function of space.
It’s a physical, kinetic model that’s familiar.
Secondary screens are placed along a horizontal continuum, which is reflected in the motion of the navigation, cascading to the content below. A great example of motion being leveraged to imply space.
I’m unsure if it’s intentional, but the interface for messaging your ‘matches’ happens to exist on the right hand side, within the same area you toss your Tinder crush card.
Tumblr’s model is simple. There’s a few contexts, connected with a tab bar. It’s easy to visualize if you imagine the interface from the perspective of a camera. A persistent toolbar follows us, as if attached to the camera we’re looking through. Though you don’t see explicit motion along the x-axis as we change contexts (as Tinder employs), there’s still a implicit feeling of space on either side of the columns.
None of this is groundbreaking.
What’s interesting is the use of the compose modal, triggered by touching the blue pencil icon. No matter where it’s touched, you are not transported to a new part of the interface, rather — you’re presented with a temporary offering, in a focused view. You have incredibly simple options: Either select a post type, or dismiss the menu. The view presents itself over the top of the content, as if it were a layer existing on a z-plane. Dismiss the view, and it returns to where it was summoned. Choose to make an action on it, you continue to move along the y-axis with the icons, implying a continuum. It’s like a conveyor belt on a production line.
My one gripe in Tumblr’s process, is that the metadata composer is presented with the insertion of a classic, master-detail view. If I were to push the interface further, I’d continue to present the next screen with y-axis motion, rather than introducing the extra x-dimension. This reduces the cognitive load required to imagine the spatial model.
Facebook’s Swipe to close
A classic lightbox effect, but with a little more. Tap the photo, and it moves into the ‘foreground’. The background feed dims and recedes. Flick the photo away, and it returns back to its initial position, while the original container view zooms back into focus. It’s solid.
Interfaces with careless Spatial Design
There’s a lot to learn, by deconstructing these expensive Frankensteins.
Spotify, what are you doing? 😲
One of the most spatially confusing, while popular pieces of consumer software. To describe how Spotify’s interface makes use of space, would be to describe a rat’s nest of wires. I challenge you to effectively sketch it on a piece of paper.
A user of Spotify is exposed to obscure carousels, buried inside modals, stuffed inside list views, crammed into drawers, contained by drop-downs, tucked behind gestures. Each list item in the hamburger menu forces the user through a wild goose chase in order to perform a simple action. It’s like you have to play a choose your own adventure story to get anything done.
Turkish Airlines in-flight entertainment
How do we avoid the Rat’s Nest? We need to zoom out, and quite literally. Like I mentioned earlier, it helps immensely to think in terms of diagrammatic reasoning. Simple directions on the map result in a less chaotic journey through space.
- Be careful mixing carousels, scroll areas, zooms, and hamburger menus. Each one of these devices introduces dimensional complexity.
- Avoid over-describing space. It becomes hard to digest. The time it takes to convey the space might block an interaction. Added time can cause software to feel unresponsive. Consider shortcuts to imply the feeling of space. Literal isn’t as important as feeling.
- Get drawing. Use a sketchbook, or even a whiteboard. Something more loose than pixel twerking. Think with pictures.
I hope what I’ve penned down has encouraged you to think more Spatially. Go play some video games, and study the interfaces. Go outside. Observe the physicality of reality and your expectations of it.
Spatial Interfaces, as a talk:
Feel free to email me: email@example.com, or write to me on twitter @pasql
Jake Lodwick, Eric Skogen, Mark Stultz, & Sebastiaan de With