2013-01-04
In a recent and widely cited essay, Craig Mod argues that:
"... business skeuomorphism happens when we take... decisions explicitly tied to one medium, and bring them to another medium - no questions asked."
He's referring to the way in which digital magazines are created. Seemingly, it is no different to the way in which printed magazines are produced, often to the point of using the same schedules, the same covers and the same content. He goes on to say that: "unfortunately... it is almost impossible to produce a digitally indigenous magazine" (my emphasis) in this way.
Why? "Because... we use tablets and smartphones very differently than we use print publications."
A similar kind of thinking can be seen in app design -- though, to be clear, I am not talking about skeuomorphism in in either a business sense or, indeed, the more usually accepted sense. Instead, I have in mind the well-established practise of taking a navigational model that worked brilliantly for desktop apps and bringing it across to app design where, in my view, it works less well.
In his book, Tapworthy, Josh Clark describes how a "tree-structure app" borrows directly from the one-window drilldown pattern that we use to organise our desktop computers. To reinforce the point, he shows the Finder alongside the Mail app.
On one level, it should come as no surprise that mobile apps have borrowed from this pattern -- it's a familiar and efficient way of organising a big collection of information. But is the Finder the right solution for the iPhone? For me, yes and no. Yes, because it's well known to anyone that has used a computer. And no, because I think there's a simpler and more indigenous alternative, which I'll come to shortly.
As I see it, a spatial metaphor works to great effect with a large screen device, like a PC. But not a small one, like the iPhone, where the movement from screen to screen is temporal, not spatial. Or as Josh Clark says: "Because the iPhone's not large enough to show the entire document tree, you see just one 'column' at a time, each one skidding into view from the right as you tap through another level".
It's the "one 'column' at a time" that I want to call attention to.
By breaking the pattern down into smaller units of "just one 'column' at a time", a different model is created, one that has similarities to music and, most especially, comics. Let me explain. When we view the pattern, the columns are delivered in short bursts of information. On their own, each burst of information is not enough to give us a complete picture of the pattern. But as a group, they are.
It's the same with comics.
Consider the strip below by Chris Ware.
When we look at the strip for the first time, it's very likely that what we 'see' are the individual panels. On their own, the panels can be read as a conventional comic. But stand back for a moment and the panels fade into the background, to be replaced by... a tree, appropriately enough.
It's a technique Ware borrowed from another comics' genius, Frank King.
In King's hands, a scene would be divided into a dozen different "places". Each place would represent a moment in time. But again, stand back and you'll see that while there are twelve different panels, or moments, they are all of the same scene.
Why is this relevant?
Because it contains the outlines of what could become an alternative to a drill-down pattern. To understand why, I like to go back to a concept that is central to the point I am trying to make: groups.
At its most basic, an app is made up of a series of screens. The screens can be organised or divided into groups. In the first group are the individual screens. These are the base units on which the app is organised -- or, to use an analogy from a previous post, the 'beats' that carry you backwards and forwards through the app.
The name I use to describe this group of screens is the metric level.
Underlying the metric level are two more levels. The first of these is the group level. At this level, the screens are organised into cycles -- or what I've previously referred to as 'group patterns'.
The third level is the culminating one -- the grouping of all the preceding levels into complete apps.
It's the group level on which I want to focus.
A group is a repeatable pattern that can be used in solving or addressing a design problem. For the most part, it works in exactly the same way as a design pattern, though instead of showing the pattern in one, all-encompassing window, it is broken down into smaller units -- of, for example, one column each, which are distributed across a number of screens.
At the root of a great many of these groups is a triad of screens. The prevalence of this triad is so general as to make you wonder if it follows a universal 'law' -- a law that is broadly similar to the universal instinct of accentuation in twos and threes, which you find in music. Nowhere is the 'law of three' better illustrated than in what must be the most common group pattern of all -- a drill down menu. The basic structure of this pattern is nearly always the same -- a top, a middle and a bottom level.
Together, the three levels form a sequence that you have to follow in order, one screen at a time -- that is, you start at one level and proceed to the next. The most usual way of showing the levels is this:
Or maybe this:
Now, it's tempting to think that because a drawing shows the screens stacked one on top of the other, the user has an immediate picture of how say, the built-in Notes app is organised. Like I said, it's tempting... but no more. Why? Because the model that we use to describe the organisational structure of an app is a far cry from what we see and interact with on our phones. What we see on our phones is this:
A keyhole view of the app.
Notice, too, that at no point do we see the organisational tree in its entirety. Instead, we get a series of windows that step us through the 'tree', one level at a time. It means that when we view an app, we see only one bit of it at a time. To view another bit, we navigate to a new screen. And so on. Taken together, the screens are like the panels in a comic -- we 'read' them as a sequence, from left to right, with one screen following another.
I want to conclude by looking at another app, Clear. Like the Notes app, it too is built around a tree structure. But instead of going from left to right, the 'layers' are arranged vertically, with the end of one layer leading to the beginning of the next.
You can switch between the layers by swiping up and down, like so:
Nothing out of the ordinary, you might think. But look more closely and you'll see that you are not moving up and down through a vertical space, but linearly, across two adjoining layers. Separating the layers is a black border (or gutter) with an arrow to tell you where you are.
Until recently, this was the sole paradigm for moving through the app. But not any more. A recent update has introduced a second paradigm -- only this time, it doesn't constrain you to a vertical row of screens. Instead, you now have the option of moving between your items by swiping from the edges of your device, like so:
If we map the two paradigms to a drawing, you'll notice two things:
1) The app's navigational scheme can be operated with just two gestures: up and down for moving between the outline branches of the app (the vertical axis), and left and right for moving between the item views (the horizontal axis).
2) I've shown the two axes in what could be thought of as the default position. But what happens if you're on the second or third item along? How do you return to the vertical or outline axis? Ordinarily, you might think that you would need to go back to the first screen in the horizontal axis. But that's not how it works. Why? Because wherever you are on the horizontal axis, the vertical axis is always aligned with your position. Or to put it another way, whenever you switch to a new item, the outline axis gets pulled across with you, like so:
Notice how the interaction of the two axes creates a pattern that is conceptually similar to the panelled stories of a comic. Now think back to the work of Chris Ware and his method of dividing a scene into fifteen different windows. Recall that the windows show a series of moments, or time spots -- which can be read as a sequence, just as you would a normal comic. But they also do something else. If you stand back and look at them as a whole, they become a single image -- a tree that fills the entire comic.
It's the same with Clear.
If you stand back and consider the app as a whole, what you see is a series of windows, which are laid out in a grid. Look beyond the grid and you'll see that it is organised around a tree structure.
I began by asking if a spacial metaphor was the right solution for a mobile device. I suggested, not. For me, it comes down to a simple matrix: a spatial metaphor works best with a large, all-inclusive surface, like a PC; where it works less well is on a small-screen device, like the iPhone, where the movement from screen to screen is temporal, not spatial
.
Using the example of Chris Ware, I put forward the idea that a sequential or panelled art, like music or comics, was a better or more promising model for how we experience or interact with our phones -- a promise that has begun to take shape in the evolving interface of Clear.
2012-04-29
Drafts, a recent app from Agile Tortoise, has had some very favourable reviews. Typical of the reaction is a piece by Ben Brooks -- he loves it. No, he really loves it. Ever curious, I decided to try the app for myself and surprise, surprise I, too, am hooked -- it's good. No, it's really good.
It is also one of the most beguiling, and that too got me thinking -- I was curious to know why.
On using it for the first time, I had a distinct feeling of vertigo -- I had no idea where I was within the app or how I had got there.
It's an odd feeling but, interestingly, at no point did I feel lost or out of control. Quite the opposite. Ben makes a similar point. Toward the end of his post, he says: "That’s what I love, no organization and not naming things".
And it's true: the app's organisational scheme is not at all obvious -- though unlike Ben, I wouldn't go so far as to say that there is "no organisation". There is -- it's just very different to the usual tree structure that you find in most apps.
It is also true that there is no scheme for giving the notes a heading -- though again, it's to do with how the app is organised.
To get an understanding of why it's different, consider an app that does something broadly similar: Apple's Notes.
The app uses a conventional nested structure that allows you to move from one list to another and then another before you end up at the task or note you want. Along the way, you're continually updated as to where you are in the app by a combination of the screen title and the Back button. It's a very anchored experience and at no point do you feel lost or adrift without a paddle.
Turning to Drafts, you'll see that it uses a very different navigational scheme.
Instead of a nested structure, the notes are reachable from a central hub which, appropriately, is positioned in the middle of the app. As the name implies, the hub is surrounded by 'spokes', which are the four screens at the top and bottom of my drawing.
To access a screen, you have to go through the hub. There are no options for going from spoke to spoke, so once you've completed a task -- say, tweeting a note -- the only way to trigger the next task is to go back to the hub.
On the face of it, you might think that going back to the hub is an extra step but, in fact, the reverse is true -- it simplifies the navigation. How so?
Because there are no hierarchies or views within views to bother about, no checking to see which account or note you're in... just a simple 'step this way to enter a note, this way to email or tweet it, and this way to return to the hub'.
It's that straightforward!
One more thing. The app has been updated and now includes a new theme -- greyscale. If you set the text to Courier, the theme and the text work brilliantly together and, for me, transform the app from a first-rate tool to a great looking one, too.
For a detailed discussion of the hub and spoke pattern, see Bob Baxley's piece on: Views and Forms: Principles of Task Flow for Web Applications Part 1.
Update: since writing this piece, a new version of Drafts has been released, so I've changed the ending.
