In an effort to maintain consistency and quality of our application icons, I have been collating a GUI (Graphical user interface) reference doc. As we produce applications on different devices and platforms, we need to take native UI styles and features into account. Although there can be no “generic” iconon all platforms, we can still achieve a consistency of drawing shape and general ‘character’ of icons across apps. For instance: to create tab and activity icons in iOS you provide white shapes on transparent backgrounds, the “blue gloss” styling is added dynamically within the app.
This matrix is more of “how are we doing” document to see if Last.fm style shines through the veneer of native UI styling. The grid shows platforms in columns (names removed for confidentiality of work in progress) and the rows display the various activity states: rest, hover, press)
It’s very easy to get lost when designing an app, but when you’re designing for a touch-screen experience, with gestures replacing clicks and scrolling, it’s even more complicated. Touch-screens introduce physical concepts to help the user navigate: spatial planes that you can “swipe” across, representations of physical objects, and zooming in and out and content. This makes the user flow in and out of content very tricky.
Immersive Vs productivity apps
In a productivity app, like email, its better if a user can drill in and out of tasks in a straightforward way. Therefore the folder based metaphor of desktop operation systems makes sense. But for a more immersive experience where you want the user to get “lost” in the experience, you need a more “open’ and loose heirachy. In my experience, “Open” is very hard to develop… as it’s harder to anticipate all the possible routes and outcomes, so the UI presents consistent behavious where ever the user is.
In this example I’m looking at an immersive touch-screen way to explore music artists. A list of artists is presented as a photo grid (or quilt), and the user can zoom into the grid to look at an individual artist. They can then swipe left and right to see the next artist in the grid. This mixes two existing navigation metaphors: picture thumbnail gallery and a page-turn magazine experience. Phew.
But now the hard bit…
Every artist has similar, or related, artists. Daft Punk has: Justice, deadmau5, Digitalism, etc. We want to encourage the user to follow these connections and explore more artists freely, but at the same time, need to give them a clear way back to the start of the app.
The user zooms in on an artists, then when the click on a related artists, that opens another grid. In the programming model, each artist opens as a new level in the app, and each related artist grid is another level on top. Phew! The layers build and build, and for to get back to the start, do they have to press “back” through each of these layers?
The user can zoom in and out of the grid to see artists, but if they want to click on a related artists, that launches a new grid in a new session. To get back, the user goes from grid to grid. It’s more like a concept of islands of artists, than levels. This will be much easier to develop, as each time you press to see a set or related artists, you are clearing he grid before, much like performing a new search.
If this comes across as an incoherent ramble, it is because my mind has been broken by too long in front of the whiteboard!
I’ve had the opportunity to move from print design to web design to app design.
Looking back over these very different mediums, each has a learning curve, each has very different thinking and best practice. But the hardest part is that going from one medium to another requires you to “forget” the thinking of the previous medium.
“Your must un-learn what you have learned” – Yoda
In print there are categories and indexes to organise your content, on the web you can slice and filter the content dynamically by combinations of categories and tags, with apps (on touchscreen devices) you have a new interaction model based on “direct manipulation”, where utility needs to be more focused and access to content needs to be flatter and more direct.
One app – one function.
In the web world, if you wanted to offer 5 different things you’d have 5 sections on your site, in the app model, it’s better to make five different apps and focus them clearly around one task, defined by an application definition statement. It’s not a hard rule, more a principle that will help to make a better, more straightforward app.
The magazine metaphor
The iPad has ignited a great deal of excitement and activity from the news and magazine nedia, who are eager to find a new avenue for thier content in the face of years of competition from the free web.
Certainly, apps like Flipboard have shown there is great potential in the magazine browsing metaphor for consuming any kind of content, in fact trad publishers are signing up to delver their content through Flipboard (Lonely Planet Mag, Washington Post).
The challenge for these companies is to make the most of this potential without reverting to print thinking when it comes to content structure. The periodic “issue” may make sense and feel comfortable commercially, but seem anachronistic on an iPad constantly wired to the web. Wired and The Economist deliver periodically, despite the fact their websites have “live” content.
It’s a bit of a downer to open an app to find there’ll be nothing new for another week or month. Just like discovering just missed your favourite TV show only to find they don’t do “on demand” and have to wait for a scheduled repeat. Old skool.
Read the iOS Human Interface Guide lines
Apple know what they’re talking about, and it’s better to be inspired by built-in apps than by copying competitors. One word of warning though… don’t assume that all functionality in built-in apps is available in the SDK. It ain’t always! iOS Human Interface Guidelines
Write an “Application Definition Statement”
An ADS helps you to focus the app and keep it simple. You need to define the:
USP – what makes it a cut above the rest?
Purpose of the app
Who is the app for?
Then, if at any point you think of other features (or if some smart-alec starts pitching in), alwasy check it against the core purpose of the app, to make sure you’re not overcomplicating things and bloating the app.
Write a feature list
of all the things users might like. I brainstorm this through think-maps and work-flow diagrams to think through the various uses of this app, and the processes people use in the real world to achieve the same tasks. Compare the feature list against the ASD and focus the app to core features. Do I really need to offer offline browsing, when the core purpose is user is out and about and needs to look something up”.
Work out the key screens
Make quick paper prototypes to help think through different models and identify which key screens need designing to show a user through a task (or tasks).
Create paper prototypes the most successful models to test with users. Alternatively, you can put your flat designs into the “Photos” app, to give users a more hands-on experience.
Test, iterate, and test again I prefer batches of 5-10 users. Keep iterating until every user is sailing through the tasks your app is designed to fulfill, and when you feel confident enough to swear on a stack of bibles you’ve nailed it.
Design your final UI
The lovely chaps at www.teehanlax.com have created an Adobe Photoshop layered PSD of the iPad and iPhone GUI, which will save you a million years. My tip would be to use this for designing only. When it comes to building the app, use as much of the built-in UI assets and styling as available, rather than slicing all the graphics from your design. Here’s the iPad GUI