Think about painting: we have painters that created entire worlds inside the frame and still the frame was often part of the painting itself: by negating the view of a larger picture, we have to use our imagination to fill it. At times, artists also worked around that limit, going beyond the canvas, using a wider space as their canvas. The play on that limit is one of the things on which the artist must confront himself, every time.

How would the Mona Lisa be on a 7.7×5.3 meters canvas instead of 77x53cm? And what if the proportions were different, maybe 53x77cm?

Think about photography, where what’s left outside the frame is a critical choice in the hands of the photographer, as much as what’s inside the frame. One of the widest discussions about photography is about how much this boundary is able to manipulate the truth.

Think about books: the beauty of great book designs lies in a dance inside the page boundaries. Change those and you have another edition, another result. Sometimes, a completely different experience. For example huge discussions stem around new editions of comics/manga that change the layout of the original edition.

The strip was horizontal! Now it’s split! And the surprise when you turn the page is ruined!

The variable frame

Then, the web.

The web introduced the concept of a variable frame (well, even before: computers did it). It added flexibility, but flexibility needs a different skill. You have to program how something will behave in a mutable environment, you have to think about all the different screens, sizes, proportions and plan for them.

Note that this is different from the variability of sizes of canvases and books: once you choose a canvas, a photo format or a book size, that’s it, you live inside that boundary. In this situation, you have to account in realtime for that variability.

To create something inside this variable frame you need two skills: the rule-based, logical thinking of a developer and the view-based, spatial thinking of a graphic designer. This is more than a slight difference in approaches, it’s a clash of worlds, because those two views usually mean also two very different people and personalities.

That’s the exact reason why we praise in awe the few hybrids that have both of those skills, guys like Shaun Inman.

The war ended when the average screen size got big enough to allow good readability – the main reason for liquid layouts – within a fixed layout. From an external point of view each part had good point, but as often happens, the balance was in between. And there’s still who is working on this, take for example this good recent post by Jeremy Keith.

An example of this difference of perspectives was years ago the war of liquid layouts. There was a group that said that the liquid layout was the best thing to do and another group that instead kept working on fixed layouts. Guess what? The first group was usually composed by people with a rule-based thinking (developers, engineers, usability experts, etc) while the second one was composed by people with a view-based thinking (graphic designers, artists, etc).

The rule-based approach and the view-based approach on the web are now forced to live together: either in the hands of a hybrid professional, or two vertical professionals.

But what’s the ‘right’ answer? There’s no right answer.
Think about it, ignoring for a while all the reasons for having different screen sizes: if you have to build your own software, would you prefer a platform with a fixed screen size, or a variable one?

The answer is simple: a single, fixed size screen, is the best.
And that’s true either as a developer or as a visual designer.

What you see, is seen by everybody.
You don’t have to spend time to adapt the interface to every device.
You can play on the boundary of the screen itself, since you perfectly know where it is.
You can create interactions that make use of every pixel and every space on the screen.
The visual balance is built inside that specific frame.
And so on: there are a lot of reasons.

Why Apple gets it

The reason is simple, and it’s probably obvious by now. But let me set it clear:

  • iPhone (2007), screen size: 320×480
  • iPhone 3G (2008), screen size: 320×480
  • iPhone 3GS (2009), screen size: 320×480
  • iPhone 4 (2010), screen size: 640×960
  • iPod Touch (2007), screen size: 320×480
  • iPod Touch (2008), screen size: 320×480
  • iPod Touch (2009), screen size: 320×480
  • iPod Touch (2010), screen size: 640×960

As you can see, the only screen variation happened this year, but nothing has really changed: since the size is doubled, the frame isn’t changed at all, it’s just the same as before, just 4x more dense.

Apple’s designers just picked what they found to be the perfect resolution and size and stuck with that. The reason is simple: since they had to build a platform and they knew that in a mobile-sized device every pixel is important, they wanted to be perfectly sure that every App ever built was going to be perfect.

That means that a developer has to spend exactly ZERO time to figure out how the app is going to behave on different screens. That means that a graphic designer doesn’t have to change his way of thinking to try to adapt to the variable world.

Check the best applications existing for iPhone: look at those and think if that beautiful UI and interaction would be possible without the security of a same-sized screen everywhere.

Why Google doesn’t get it

Unfortunately for Android there are no specifications of the screen size associated with the OS: Android is built, at least for now, to target every screen size from 2.8″ to 7″, variable resolution and variable proportions.

Even with “more than a hundred different versions of Android software on 244 different handsets” (transcript) there are developers like TweetDeck that are saying that it’s not a problem:

From our perspective it’s pretty cool to have our app work on such a wide variety of devices and Android OS variations.

I might guess why they didn’t have problems: they designed the app from the beginning to take into account that flexibility, exactly what you would have done with a liquid layout on the web.

But the point here is that the openness of the Android platform isn’t an excuse for not even having a suggested screen size, to allow both manufacturers and developer to focus.

That said, it’s not a problem by itself, like I was saying at the beginning: it just makes things harder, and since this fact isn’t the only thing that counts, that’s relevant but just up to a certain extent.

So you might well say: it’s not the end of the world, we developed flexible applications since the first desktop operating systems and we are still doing that on the web.
That’s true: but still, developing for a single size is simpler.

A fragmentation and UX failure from the recent past

We also already have an example of failure in the mobile space due to making the life harder to developers: Symbian and Java ME.

Think also to the world before the iPhone and the new wave of smartphones: we had – and still have – almost everywhere Symbian and a Java runtime. Take your non-smartphone mobile, it’s probably built using those technologies.

Those two technologies, by themselves, are okay. They aren’t great, but they work. Technology-wise, they are comparable. You could even choose between a low-level C++ app, or a high-level Java app
But almost nobody ever developed anything on those platforms. I tried, too. It was hard. Hard to begin, hard to develop, hard to be sure that your app would have worked everywhere.

What failed – and still fails? The user experience, for both users and developers.
Hard to develop.
Hard to model a good UI on such a fragmented market.
Hard to use in the end.

Microsoft seems to get it

A few contacts I have told me that Microsoft is imposing a few restraints for the manufacturers to use his new Windows Phone 7. And also it’s a kind of rumor that doesn’t seem strange:

It’s very difficult to tell one Windows Phone 7 phone from the next, largely because Microsoft has been so tough in enforcing minimum specifications that are, for the tail-end of 2010, at the very least good enough for the market.
— David Meyer (2010) On Windows Phone 7, apps and the enterprise – ZDNet

The official documentation Microsoft says:

All Windows Phone 7 phones will have WVGA screens at 800 x 480 pixel resolution, no matter the screen size.

And that was already evident if you take the lineup of the Windows Phone 7 smartphones, you’ll find something interesting:

  • HTC 7 Mozart, screen size: 480×800
  • HTC 7 Pro, screen size: 480×800
  • HTC 7 Surround, screen size: 480×800
  • HTC 7 Trophy, screen size: 480×800
  • HTC HD7, screen size: 480×800
  • LG Quantum, screen size: 480×800
  • LG Optimus, screen size: 480×800
  • Samsung Focus, screen size: 480×800
  • Dell Venue Pro, screen size: 480×800

…and so on.

If this is something that Microsoft is enforcing, developers are going to be able to build applications exactly targeted for that size, spending again zero time on sizing and screen issues.

Where the real issue is

It’s not a problem within the technology. From a technological point of view, all those systems are ok. You can build amazing things. The problem is that living inside the “digital” world we often don’t look at the very boundary of that world: the screen itself, because we are so immersed in it.

But when you start looking at the screen itself like a painter does with his canvas, everything changes a bit. The experience starts way before the screen, and what’s inside the screen itself is defined by it.

Sure, Google is going to have way more cards to play in this game. But the screen size is one of them, an overlooked card with a huge impact in the ecosystem, from the developers to the final users.

It’s all matter of user experience, and simplicity.