I’ve recently noticed a new design pattern appearing in mobile applications, and I haven’t seen anyone write about it yet. That said, I don’t really know it would be called so I can’t search to make sure. While all of these examples are slightly different, they all have one thing in common: overlapping content panes, used to convey hierarchy and provide a way of navigating it. For lack of a better name, I’ll call this the Stacked Hierarchy pattern.
The new Gmail and Facebook apps use a navigation that hides behind the main content, and can be summoned by a tap in the upper left — on a “Menu” button and row of lines icon, respectively — or by dragging the content out of the way using the menu bar.
Facebook’s also serves a place to list search terms (Gmail’s search is included in the main interface).
Another place I’ve seen this stacked hierarchy is in Asana’s HTML5 mobile app, app.asana.com. Here there are three levels of hierarchy, and the main menu is always visible, even if only slightly. There’s no dragging here (probably partly because it’s a web app living in Safari) but the cards do slide left and right, strengthening the sense of overlap.
I also found some screenshots (on Behance) of a Russian application called Beeline that also appears to be using this strategy.
Update (9/20) Some readers told me about Twitter’s iPad app, which was apparently the first to implement the pattern (in both portrait and landscape views):
At first this stacking pattern struck me as weird because all of these screens are more constrained horizontally than they are vertically, so a smallish sliver of vertical content is actually quite a lot of screen real estate. This doesn’t seem to be a problem, however. Facebook doesn’t need the entire screen width for navigation, and Asana’s task card looks fine with a little less space on the left.
Lastly, the fact that these interfaces use card-like is vaguely reminiscent of Palm OS, except Palm only uses cards to represent entire applications. The hint of off-screen (or “teaser”) content also reminds me of the Windows Phone 7 UI, except I don’t believe Windows uses it for hierarchy.
Are there other examples out there? Has anyone else written about this or given it a name? Let me know.
I’m interested in seeing how this pattern evolves over time.
I’ve been using your iPhone app a lot recently, and for the most part it’s great. But there’s something that annoys me: the passcode screen. It doesn’t accept my passcode taps for a few seconds, which leads to me typing the last two digits of my passcode, then backspace twice, then the whole thing. Slow and annoying. Or, I just wait for a while, slowly building rage, and then type it in. You don’t want to enrage your users.
Now, I suspect that what you’re doing is showing a Default.png image (which loads immediately) that looks exactly the same as the functional passcode screen, and then showing the real interface. This is a neat trick that is usually supposed to make applications feel like they are loading faster. But in this case it’s making your app feel like it’s broken, because when I tap what looks like a button, nothing happens. So I have to wait for a while — probably longer than I have to, in fact, just to make sure — which actually makes logging in slower. Oh no.
So, here’s my advice for you: use a Default.png image that is similar to the real passcode screen, but not exactly the same. That way I know when it’s time to type in my digits. One idea would be to show an interface that looks disabled, with a greyed out input box and buttons. Alternatively, don’t even show the buttons, and instead show a witty message, like “Finding buttons” or “Please hold.” I’m sure you’ll think of something.
(Oh, and I love the recent pending transactions update, with the dashed lines. Pretty.)
I’ll post more about this soon but here are the slides from the pitch/presentation that Jane and I gave in Boulder this past weekend for the Interaction ’11 student competition. All of the brainstorming, ideation, research, iteration, and creation happened during the 3 days of the conference. Lots of fun.
The slides make more sense with narration, so I’ll be adding captions to them soon, or maybe I’ll post a video of the presentation, depending on how the quality is.
Many of the icons are from the free Glyphish set that is licensed under CC-Attribution.
This has been bothering me for a while now. If the image you’re viewing in Preview is already at 100%, the menu item for “Actual size” is greyed out, which makes it hard to find because my eyes skip over inactive menu items. Also, pressing the ⌘0 shortcut for it beeps, which is the same result as (for example) ⌘9, which never has a function. So I think I’m doing something wrong.
I argue that the command for making an image actual size should never be hidden or sound like an error. Trying to scroll up at the top of a webpage doesn’t beep. Making the font size 12 in a document where it’s already 12 isn’t an error. Pressing backspace in an empty document is not a crime. These are all things people do just to make sure they’re at the top, that the font size is 12, or that their document is empty. I just want to make sure that I’m seeing things at 100%, which is reasonable because the current zoom level isn’t displayed anywhere.
I know this is a small detail, but Apple is usually very good about things like this. I wonder if this is an oversight or a deliberate decision.
Control of our systems through interactions that bypass the conventional mechanical switches, keyboards, and mice is a welcome addition to our arsenal. Whether it is speech, gesture, or the tapping of the body’s electrical signals for “thought control,” all have great potential for enhancing our interactions, especially where the traditional methods are inappropriate or inconvenient. But they are not a panacea. They come with new problems, new challenges, and the potential for massive mistakes and confusion even as they also come with great virtue and potential.
Gets me brainstorming what the gestures for copy and undo should be, the right ways to show users what gestures are available (and what they do), and conventions for feedback when a gesture doesn’t elicit a response.