Based on our experience creating great iOS apps, we’ve come up with a list of 5 things we believe designers should keep in mind while conceptualizing interfaces for iOS. While the focus of this article is only on iOS apps, much of the advice here translates directly to other mobile platforms.

1. Understand Your Medium

This seems obvious, but designing apps instead of websites actually represents a huge shift in mindsets. Apps aren’t websites and shouldn’t be designed like them, either. Let’s talk about specifics.

Apps have a completely different user interaction model from websites: taps vs. clicks, views vs. pages, buttons vs. links, etc. We believe a change in language when discussing app design helps us keep the right frame of mind.

In addition to a different interaction model, apps should have different modalities. Don’t overload the user with too much in one view; separate different functionality into different views. This is even more important on the iPhone than on the iPad, since screen space is even more constrained.

How users get around in apps vs. on websites is another area of contrast to consider. Navigation hierarchies in apps tend to be narrower and deeper than on the web. Users are used to having to tap several times in order to achieve some goal or to access some content; don’t try and prevent this natural drilling-down behaviour by putting too much on the screen at once.

Navigation is very different on iOS – there is no browser chrome or Back button. Since iOS launched, many navigation conventions have emerged; which one is right for your app depends on your specific needs. Check out Pttrns for a great collection of approaches that apps have taken in regards to navigation.

Finally, remember that iOS apps run on iOS devices. Duh, right? But it’s an important point. Rendering semitransparent content with rounded corners and a drop shadow over top of a image overlaid with an animated gradient is probably going to cause a performance problem. Work with a developer to figure out a way to implement tricky designs without causing user-noticeable lagging in the interface.

Wikipedia has a comprehensive breakdown of all iOS devices, but we thought we’d distill that down to a short list of devices running iOS 6. We’re hoping this will help you make informed decisions about your app’s design and how it can degrade gracefully on less capable hardware.

2. Design Universally

We believe that the best applications are those that work universally. That means they work on Retina screens and non-Retina screens; they work on tall screens and short screens; they work on iPads and iPhones and iPod touches; most importantly, they work well in all these contexts.

This is hard, but we’ve got a few quick tips to get you 80% of the way there.

Avoid odd-sized Retina graphics

Non-Retina assets must have exactly half the size of their Retina counterparts. That means that a non-Retina asset corresponding to a 101 pixel Retina asset would have a dimension of 50.5 pixels, which is impossible. Save yourself and your developer some headaches and always use round dimensions for Retina assets.

Make Tap Targets Big Enough

Remember how users aren’t using your app in a web browser? Well, they also aren’t using a mouse. Instead, all interactions with your app are made with a far less precise instrument: a finger.

In order to make sure that users can easily interact with your app’s interface, make sure that anything they can tap is at least 44 points wide and tall.

3. Design on a Device

iOS devices have a range of pixel densities and vary in their reproduction of colour. When designing iOS apps, you should take that into account.

In order to get an accurate idea of what your app will look like, you need to render it on a range of devices: Retina and non-Retina, tall and short, iPad and iPhone. Use LiveView or Skala to mirror your photoshop files on your device. Lastly, don’t forget to vary the screen brightness to make sure your app looks good in all circumstances.

4. Animate your Interface

Animations are easy on iOS – Apple has gone to a lot of trouble so apps can easily be supplemented with cool animated transitions. It would be a shame not to take full advantage of this opportunity.

Unfortunately, animations are not easily conveyed through PSDs. The best idea for designing awesome animations is to work with a developer to prototype them on an actual device. Together, you can make throwaway apps that explore your idea for an animation. This will let you get a precise feel for exactly how your animations behave.

When designing animations, take advantage of what the user is already familiar with. Users expect that when they tap on an item to see more details, the new view should “push” in from the right; they also expect views for creating new content to slide up from the bottom. Mimic those motions in your own custom animations and don’t associate new actions with the existing animations. You should lean on what the user is familiar with to give them a better sense of familiarity and trust with your app.

5. Involve Developers Early

We believe that the best apps are made when developers are involved early in the design process, and when designers stay involved late in the development process. Collaboration between designers and developers will lead to some great work.

Implementing any reasonably complex design will have implementation challenges – the sooner developers can start thinking about solving those problems, the better the solutions will be.

We developers have ideas about interfaces that we’re not necessarily able to polish into an actual design. We also know iOS like the back of our hands, so we can point out elements of designs that don’t fit well within iOS. When designers and developers work together, awesomeness happens.

So there you go. Apps aren’t websites. Design universally. Design on a device. Animations are awesome. Involve developers early. These points will get you most of the way there – the rest is up to you.

I’ve always had much love for Cooliris and its refreshing, fluid 3D interface for viewing and sharing photos, so I was happy to catch up with co-founder and CTO Austin Shoemaker and VP of Bizdev Sebastian Blum at the Mobile World Congress in Barcelona last week.

They had good reasons for attending the event: Cooliris has been offering a nifty free app for iPhone and iPad since July 2012, and it’s seen a great deal of activity from users thanks to 3 million total installs since then.

That said, the Silicon Valley startup, which is backed by over $28 million in funding from the likes of Kleiner Perkins Caufield & Byers, DAG Ventures, T-Venture and DOCOMO Capital, wasn’t at the Mobile World Congress to make any major announcements but rather to meet partners and press.

An Android version of the Cooliris iOS app is in the works, although it isn’t anywhere near launch yet, so don’t hold your breath.

Time for stats

The company did, however, share with TNW some recent – and rather respectable – usage statistics: in February, Cooliris had already announced that it crossed 1 billion connected photos in its iPhone, iPod touch and iPad apps, with 1,000 photos being viewed per minute in total.

Overall, more than 350 million photos have been ‘meaningfully engaged’ with using Cooliris’ iOS apps, which I gather means they were viewed, tapped and commented on by, or shared with, others.

What the first stat means is that Cooliris users linked up over 1 billion photos from a variety of supported sources that are integrated into the iOS app, including Facebook, Instagram and Google Drive.

It gets more interesting when you break that number down.

More than half of that 1 billion photos, 600 million to be more precise, were connected by iPad owners using Cooliris’ app, with 200 million photos viewed on the popular Apple tablet to date.

Cooliris says 550 photos are being viewed via its iPad app every minute, while 22 million of them have been ‘pinched’ so far.

One thing Shoemaker told me during our meeting that really stuck with me is that Cooliris basically wants to make its application become the default, top-of-mind replacement for Apple’s ‘Photos’ app for iPhone and iPad. The numbers seem to prove that the company actually has a shot (pun intended) at achieving this, especially on the iPad.

I’ve replaced the Photos app on my iPad 2 to see if it’s an adequate alternative, and was pleasantly surprised.

According to Cooliris, the top two sources for viewing photos are Camera Roll and Instagram, and the same applications came out at the top as the most popular sources for sharing photos from.

The top destination for sharing photos to is private conversations in Cooliris, which is the kind of basic feature that you’d almost forget mentioning, yet proves to be popular among its users.

When we built websites we usually started by defining the body text. The body text definition dictates how wide your main column is, the rest used to follow almost by itself. Used to. Until recently, screen resolution was more or less homogenous. Today we deal with a variation of screen sizes and resolutions. This makes things much more complicated.

In the heat of the relaunch I wrote a quick blog post on responsive typography, focussing solely on the aspect of our latest experiment: responsive typefaces. Without knowing the history of iA, you’d miss some key aspects to the responsive typography and design in our relaunched site. Instead of mashing up all our articles on the matter, I decided to start from scratch and explain responsive typography step by step. This is step one.

To avoid designing different layouts for every possible screen size, many web designers have adopted the concept of Responsive Web Design. In a nutshell this is the idea that your layout automatically adapts to the screen definition. There are different ways to define it. I like to put it this way:

1. Adaptive layouts: adjusting the layout in steps to a limited number of sizes
2. Liquid layouts: adjusting the layout continuously to every possible width

While both have advantages and disadvantages, we believe that adaptive with as few as possible break points is the way to go, because readability is more important than having a layout that is always as wide as the viewport. This is a debatable opinion on a complex matter in itself, but optimal readability requires a certain amount of control over the measure (column width) of the text, and in this regard a liquid layout creates more problems than it solves. More about that another time.

Note: Responsive design already incorporates a lot of macro typographic issues (type size, line height, columns width). So responsive design already incorporates responsive typography in many ways. What we focused on in our first post on the responsive typography on our own site, mainly referred to our use of graded fonts. I’d like to talk about grading in the next post and dive right into the basics of responsive macro typography on the screen now.

Choosing a typeface

The right tone

Sooner or later, you need to decide what kind of typeface you want to use. The choice of your font is mainly a matter of tone, but, as every typeface has its own qualities and demands (or forbids) certain treatments, the choice of type has a lot of visual and technological consequences. With web fonts you now have a big choice of typefaces, so finding the one that fits has become yet another challenge.

We designed our own typeface for this website to experiment with graded fonts. We chose a serif because it fits our tone, and mirrors the refinement of our content (or at least that’s what we think). For iA Writer we chose a monospaced typeface. Because the primary purpose of our program is helping you getting a first draft out, we specifically chose Nitti — a typeface that feels strong and careful at the same time. The decision to use a monospaced typeface also came about because the first iPad’s Operating System didn’t auto-kern proportional typefaces. Instead of using a proportional typeface that would be rendered poorly, we decided to go for a monospaced typeface right away.

Serif or sans serif?

Usually the choice falls between serif and sans serif. This is in itself a complex matter, but there is a simple rule of thumb that might help you: The serifed typeface is a priest, the sans is a hacker. One is not better than the other, but, for various reasons, a serifed typeface has a more authoritarian touch, whereas a sans serif feels more democratic. Remember, this is five thousand years of typographic history wrapped in two sloppy lines, so don’t take it too seriously.

A lot of people still think that for screen typography the question “serif or sans serif” answers itself. Actually, it’s not that easy. Against common beliefs, both serif and sans serif can perform equally well, if you choose a body text size above 12 pixels. Below 12 pixels serifed typefaces don’t render sharply enough, but (and this brings us to the second point) on contemporary monitors 12 pixels is definitely too small anyway.

What size?

The size of your body text doesn’t depend on your personal preference. It depends on reading distance. Since in general computers are further away than books, the metric size of a desktop typeface needs to be bigger than the sizes used for printed matter.

The illustration below shows that the further away your body text, the bigger it needs to be. The two black and the two red A’s have the same metric size. But since the right pair is held further away, the perceived size is smaller. The red A in the right image has the same perceived size as the black A in the left image:

The further away you hold the text, the smaller it becomes visually. You need to make the text size bigger the further away the text is read, to compensate for a larger reading distance. How big is, again, a science in itself. If you are inexperienced, a useful trick is to hold a well-printed book at a comfortable reading distance while looking at your website to compare.

Graphic designers without Web design experience are surprised how huge good body text on the web is in comparison to printed matter. Mind you, it’s only big if you compare it side to side, not if you compare it in perspective.

If, after increasing the size of your body text to match, the new size irritates you in the beginning, don’t worry that’s normal. However, once you’ve gotten used to it, you will not want to go back to the “standard” small sizes.

We’ve been promoting these “perspectively proportional” font sizes since 2006. Initially, our claim that Georgia 16px was a good benchmark for body text sizes provoked a lot of anger and even some laughter, but now it’s more or less a common standard. With higher resolutions, that standard is becoming slowly obsolete. But more on that later.

Line height and contrast

While body text size can be evaluated with that perspective trick, line height needs some adjustment. With more reading distance and (what we call) pixel smear, it’s wise to give screen text a little bit more line height than printed text. 140% is a good benchmark, but of course, it depends on the typeface you use.

Today it’s a given that you make sure that the contrast is not too weak (e.g. grey text on a light grey background) or too garish (e.g. pink on yellow). Since screen typefaces were designed to be displayed black on white, using dark backgrounds is also somewhat difficult, but these can work if done right. With contemporary high contrast screens it’s also preferable to choose either a dark grey for text or a light grey for the background, instead of a hard black on white. But that is, again, not the most important question.

iPhone vs iPad

A lot of what we learned about responsive typography came from finding the perfect typography for our writing app. When we designed iA Writer for iPad we invested weeks to find the right typographic definition. At the time, the high resolution screen of the iPad was a completely new challenge, and it took quite some time until we understood how it works. When Apple introduced Retina displays for iPhones and later for iPad, everything changed again. We could write a whole book to explain how we got to the iconic look of the iA Writer typeface, but there is still so much to say about more general matters so I’ll cut to the chase.

If you compare our current version of Writer for iPhone with the version for iPads, you will notice that the type size is not the same.

Why different type sizes for iPhone and iPad? If you read the above explanation attentively, you might have already guessed.

1. While the distance is not always the same, in general you hold the iPad a little bit further away. Whether you use your iPad on the breakfast table, on your knee sitting on your sofa or right in front of your face lying in bed gives a variety of reading distances. This was an entirely new challenge, because the reading distance on desktop and laptop computers doesn’t vary that much. In order to make it work in all instances we chose the furthest reading distance defining the type size. This might result in a slightly bigger than usual type size when you read it in bed, but it’s not uncomfortable, and generally you don’t use a writing application lying on your stomach in bed.
2. You have less screen estate on an iPhone so you are forced to make adjustments.

Luckily, the iPhone is held closer to the face so being forced to use a smaller type size works out perfectly. From an average reading distance, both iPhone and iPad have a similar perceived type size.

Since the iPhone is held closer, the line height could also be tighter, which again is a necessity because of the smaller screen:

Not everything always works in your favor when you design for the screen. Interaction design is engineering: it’s not about finding the perfect design, it’s finding the best compromise. In our case we had to reduce the line height, and also the gutter and the spacing between characters:

The adjustments were so delicate that if you don’t know it, you won’t notice how small the gutter is. Why didn’t we just get rid of the gutter? The gutter is not an aesthetic matter, it lets the text breathe and helps the eye to jump from line to line. If you think that this all sounds esoteric: no, so far we’ve just covered the basics.

What about desktop computers?

Some people complain about the big font size in Writer for Mac. Just like we had to go for the biggest minimal size choosing the font size for iPad (which is held at different reading distances), we went for the biggest minimal font size on Mac as well. At the time our benchmark was a 24 inch high resolution iMac, where the perceived size is more or less the same as on all other devices.

Since the variety of Mac computers that run iA Writer is finite, we could determine the different possible resolutions. We looked at every possible configuration to make sure that the type size was the best compromise for most machines.

You might ask “Why not just allow the user to choose the type size?” Well, adjusting type size is not a matter of taste, but a matter of reading distance. Since most websites and applications have an overly small type size, new customers would initially choose a type size that they are used to, that is: too small a size, and never experience the full pleasure of our writing app. The main reason is not that we want to force a certain look upon all users: what we want is that iA Writer works without settings without fumbling, that the only thing you can do with it is write. This has been the open secret of its success and changing that would be messing with its core. (What we need to improve are the accessibility integration for people with bad eye sight).

Okay then, why not adjusting to the device’s resolution automatically? Wouldn’t that be true responsive typography? That’s right, and we are working on something similar. Now, in adjusting to the resolution, you also have to choose the right optical weight to make sure that the typeface really works as intended with every size and resolution. With the type size and the resolution optics of the font change as well. That’s why iA Writer for Mac, iPad 1/2 and iPad3 all have different grades as well. To explain the full logic behind grading digital fonts and explain the thoughts behind our new Website, I need a little bit more time and space. So, stay tuned for Part II!

Response so far

In spite of having no social media buttons, this article got lots of of retweets, very few critique points, mainly around the question of liquid vs adaptive layouts, a topic that I’d like to address at a later point. I was surprised when Joshua Porter asked:

“@iA You had me until the line ‘interaction design is engineering’. How does that work?” @bokardo

Just in case other people wondered… The full citation is: “Not everything always works in your favor when you design for the screen. Interaction design is engineering: it’s not about finding the perfect design, it’s finding the best compromise.” Usually I say “Web design is engineering: it’s not about finding perfection, it’s finding the best compromise.” With the term “Web design” the sentence becomes a bit clearer because of the somewhat more obvious technical implication. I used “interaction design” because in the examples I used an app.

What it means is that while graphic design requires and allows you a great degree of graphic control, Web design requires you to think about compromises between visual design and technology from the very beginning. To get the optimal results you need to explore a lot of different solutions, each with its own pros and cons and try find the best compromise among all the suboptimal choices.

At this point, graphic designers often chime in and try to make the point that they, as well, deal with a lot of technology and so on. And sure, you do do. All creation of artifacts, all design requires technological knowledge. But just as there is a difference between engineering car engines and Websites, there is a difference between designing Websites and Magazines. And the difference is the degree of engineering involved.

In conclusion that means that in the process of designing Websites and apps, a lot of what we do is thinking about compromises and trying to find solutions that do not have too many downsides. This is what turns a lot of graphic designers off, because they are used to having control. More about that in the excellent presentation by Khoi Vinh on the difference between screen and graphic design (2007).