In 2006 the rumors of Apple making a phone were ramping up again and one day I had an idea by reading of the LED screens powering devices like the Sony NW-A3000: a phone that will have a full touchscreen surface, with a under-the-skin screen. I wasn’t really thinking of the “iPhone”, but I decided to give the mockup that title to get into the discussions.
A few months later, trying to make a better render with the help of Cristiano, I inherited however an element from the iPod: the wheel, because I thought that it might still be a good way to go through a long list of items.

In hindsight, it’s clear that with just a little more thought I should have dropped the scroll wheel as well like I did on the first mockup. Still, I think that given the timing it’s strikingly similar to the Apple patented prototype and I got also right the most important feature of the final iPhone: the full touchscreen surface with an ad-hoc interface.

However, while the other mockups now feel old, I still find the following rendering very fascinating with its glowing logo and its seamless screen, reminding a bit Space Odyssey.

Today there was a really well thought article by Joe Hewitt regarding AirPlay and the Apple TV. Here a few excerpts:

Not nearly enough of these analyses have talked about AirPlay. It’s clear to me that AirPlay would be so important to the Apple TV, you might as well call it AirPlay TV.

If I were an iOS developer, I’d start investing in AirPlay right now.
— Joe Hewitt (2011) AirPlay TV

Joe did an excellent summary. While I was noticing as well how little AirPlay was discussed and all its potential for both business and games, I never did a structured article as he did. It’s probably time. :)

For me, AirPlay has a huge potential, but let’s make a step back. The problem today is that most of the time there’s no proximity detection in our digital interaction.

Think about it: try to send a message to the person near you. You’re probably going to write an email and send it. That email then wirelessly connects to the WiFi access point, gets routed to a server somewhere maybe in the USA if you use a service like GMail, then there’s some server-to-server talk around the world and the email is sent back to the device. If it was a physical object, its gas consumption would be deemed as crazy, given that the person is right on your side.

Today, we don’t have any good tech to allow discovery and communication with a near device.

The one big technical hurdle for Apple to overcome is the unreliable WiFi connection between your iOS device and the TV.
— Joe Hewitt (2011) AirPlay TV

Or do we?

Well, it might not be perfect and it might not perform well enough, but Apple sneaked a really interesting piece of technology that, like AirPlay, looked nice but simple and got under most radars: AirDrop.

AirDrop is interesting because as Apple defines it works only on a few selected MacBooks, from 2008 onward, and there’s a reason for that: it requires a WiFi chipset (like the Broadcom BCM4322) that supports multiple streams. Why is this important? Because it needs to be able to stay connected to a WiFi network and at the same time use AirDrop. And it just works: you turn it on, drop a file, done. At a really impressive speed. I guess that the problem is power consumption, so AirDrop isn’t always on, a problem however that will disappear on a TV set, always powered.

I don’t know however if the answer is going to be AirPlay + AirDrop. There might be a problem of power consumption, given that even with iOS5 and iPhone 4S Apple requires you to connect to a power cord before syncing, but that’s might be just be something to avoid problems, given it’s syncing delicate data and AirPlay itself is WiFi.

What about the future?

It’s always very hard to make prediction, because there are lots of problems that involve also partnerships and politics between companies, but I’d like to think that:

1. One day I might walk into an office with an iPhone and start presenting without any cable, since I can do AirPlay to the projector, zero-configuration.
2. One day I could sit with a few friends on the couch and everyone could stream to the screen, zero-configuration.
3. One day I could send anything to a device that sits near to mine, zero-configuration.
4. One day, maybe, I might not even need any Apple device do do that, because everyone agreed on a standard.

I think that Proximity Interactions (PIx) are the near future of mobile. And these above are just the few things that could be possible with an AirPlay like solution, but proximity isn’t limited to that, think for example to NFC or what could be possible if we get a proximity technology that’s also able to get the position of the devices near you. But this is probably material for another topic.

But even with just this, it means that we don’t need “computer” anymore, just screens. A screen could be anywhere, without any controller, and just works. And I wouldn’t need to ask a WiFi password to stream something to some one near me, getting angry eyes from IT people from foreign companies.

And while this is somewhere Apple seems headed to, nothing avoids other companies to do the same. And this future scenario would be better with a lot of interoperability, since I don’t expect Apple to build things like projectors for meeting rooms. ;)

I really hope for a future with more Proximity Interactions, regardless of its form.

10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, “seven in order to make three look good”, which seems to be a fairly standard practice elsewhere. They’ll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.
— Helen Walters (2008) Apple’s design process

The magicians say “Presto!” and we gasp in delight. But they deflect our attention from the back-breaking labor that goes into assuring a perfect customer experience, hundreds of times a day, at 300 stores around the world, and countless conversations on the phone.
— Adrian Slywotzky (2011) Steve Jobs and the Eureka Myth

It’s hard to find informations about Apple’s way of doing things, and as human beings our perception is biased in thinking that the most visible person does most of the work, exactly like it’s more probable that you’ll know the name of the lead singer of a band, but not of each member of the band itself.

These two articles are good because they are the rare ones that actually try to shed some light – real light – on the merits and ways of doing things. Some informations are from Michael Lopp, senior engineering manager at Apple:

1. Pixel perfect mockups: they do a perfect mockup to remove all the ambiguity (animations included, afaik).
2. 10 to 3 to 1: they do 10 pixel perfect mockups, then another iteration with the best 3, to design the 1 to be implemented. This, for each and every screen / feature.
3. Paired Design Meetings: they do two kinds of brainstorming sessions: crazy brainstorming forgetting about constraints, then another production meeting that nails down what’s possible. Designer and developers together.
4. Pony Meetings: since managers sometimes ask impossible features, or “ponies”, the process is reversed: the designs are prepared (10-3-1 and pixel perfect) and then shown to the managers, that will then point in the direction they want. This to avoid them to request ponies.
5. Business Design: the products are built upon intricate levels of business design.
6. Engineered Customer Experience: the experience is crafted in every detail, from the device to the store experience. I know a bit about the training process of Apple Store personnel, and it’s kinda amazing.

This is important to understand when people try to understand “genius”, “talent” and even when company try to replicate in one or another way Apple’s success, or if you want to improve/change the working approach of your design and development teams.

It’s even more interesting when compared with the usual “Apple doesn’t do user testing” claim. That’s true, formally, because nothing goes outside the company. But on the other side the process above means that Apple does a lot of work internally. I mean, 10 people working on 10 pixel-perfect designs? Then 3, then 1. Can you imagine what does it mean both time-wise and cost-wise? ;)

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.

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

I wasn’t able to find any official proof from Microsoft of this constraint, Davide Tarasconi in the comments points out that on 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.

What makes Steve’s methodology different from everyone else’s is that he always believed the most important decisions you make are not the things you do – but the things that you decide not to do. He’s a minimalist.

He’s a minimalist and constantly reducing things to their simplest level. It’s not simplistic. It’s simplified. Steve is a systems designer. He simplifies complexity.
If you are someone who doesn’t care about it, you end up with simplistic results. It’s amazing to me how many companies make that mistake.

Engineers are far more important than managers at Apple — and designers are at the top of the hierarchy. Even when you look at software, the best designers like Bill Atkinson, Andy Hertzfeld, Steve Capps, were called software designers, not software engineers because they were designing in software. It wasn’t just that their code worked. It had to be beautiful code.

We used to study Italian designers when we were looking for selecting a design company before we selected Hartmut Esslinger from Frog to do what was called  the Snow White design. We were looking at Italian car designers.

— John Sculley (2010) Full interview transcript, by Leander Kahney

Great interview, with many quotations and insights. It also wonderfully details a lot the difference between “simple” and “simplistic”, and I couldn’t agree more.

Maybe it is a Wild West free-for-all. What a fucking mess.

— Gruber, “Jon Lech Johansen: ‘Google’s Mismanagement of the Android Market’”

Google’s answer to a closed and protected Apples App Store is an open and unprotected Android App Store.

From my point of view, that’s the wrong answer. And I think in some ways it’s not even very Google-y.

What I expected from Google was:

• A managed store, exactly like the Apple App Store
• An unmanaged and simple way to add apps to my Android device
• A common developer API to handle payments and setup

In this way, you’ll have the best of both worlds and you allow even third parties to build their store… but with your API. And Google could even add an extension to its search engine to search for apps and directly install them.

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today.
— On the iPad by Alex Payne

What’s missing today is HyperCard, or an equivalent tool that can be used to create a new wave of applications for the iPad
— The iPad needs its HyperCard by Dale Dougherty

Somehow I don’t think young Mr. Kaplan sees the iPad as hurting his sense of wonder or entrepreneurism.
— The Kids Are All Right by John Gruber

I think that the iPad is a new interaction platform. The iPhone introduced the interaction paradigm, but the platform here will be the iPad because it’s a more universal device, while the iPhone is more “just mobile”.
I do think that there’s a huge and interesting discussion that’s lying beyond the minutiae on the iPad as a technology. I call that “minutiae” because we shouldn’t just be looking at the physical thing, but at the reason why that thing exist. The computer exists to do things better, faster and easier. They exist to improve our lives. Do I really need ‘files’ to do that? Do I really need ‘windows’ to do that? No, I don’t think so.

The discussion above, threading on the web isn’t about the thing, it’s about culture, education and innovation.

I think that Alex Payne and Mark Pilgrim are rightfully worried because the iPad isn’t at this time what I call a ‘recursive platform‘: you can’t build for the iPad on the iPad. It’s exactly like the Microsoft Xbox, the Sony Playstations, the Nintendo DS, the Wii, any mobile phone or smartphone, etc, but unlike the PC industry.

But do we need recursive development tools anymore? I think that John Gruber could be right: today we have a powerful sharing and communication channel and with the free web development tools and a downloadable SDK you can do anything for the iPad.

But all this is now: in the future Apple could do many things, from opening completely the store to making development tools for the iPad. There’s technically nothing blocking Apple to do so, just economic, political and strategic reasons.

And of course there’s also ground for a ‘Hypercard for iPad’. Maybe able to build apps in HTML5, who knows. ;)

Three takes on the “upcoming” Apple Tablet, or whatever it will be. I have to say, three smart and concrete takes.

I’ve got just two words to add: handwriting recognition. And a link.