Good Will Blogging
How do you like them apples...

Listening to @siracusa’s podcast, he prescribes an interesting solution to the problem he perceives with OS X moving to a yearly update schedule: Intel’s tick-tock model.

It certainly seems to fit with Apple’s behaviour in recent years.

Exhibit A: iPhone

The iPhone 3G, a big update to the original iPhone, was followed by the relatively modest 3GS. It had an identical external design, and even its name acknowledged that it was intended as a better iPhone 3G.

The next update, iPhone 4, was clearly a “tock” — radically new design, and big improvements across the board. And again we saw the “tick” as iPhone 4S, similar to iPhone 3GS in both the magnitude of changes and the naming. iPhone 4S is an iPhone 4, plus an S. It is the iPhone 4 that has become logistically practical to manufacture in 2011/12.

Exhibit B: iPad

Okay, we haven’t actually seen the third episode in the iPad saga yet, but I’m convinced it will be a “tick” — a refinement on the current iPad 2 design.

Certainly the iPad appears to be following the same pattern as iPhone for its first two designs. We shall see.

Exhibit C: Mac OS X

As Mr Siracusa points out, Snow Leopard was a functionally minor increment over Leopard, as Apple focussed most of its resources on stability, performance, and architectural improvements.

What he didn’t mention, unless I missed it, was that its name was an increment of its predecessor. Just like the iPhone 3GS, just like the iPhone 4GS.

And here we are again, with Mountain Lion. If I’m right, its name intentionally signals a “tick”, meaning it is intended to be a better Lion. If I’m right, we can think of 10.8 as “Lion S”.

From what I’ve seen of it so far, it does appear to be functionally minor. The headline features touted on Apple’s teaser page are almost all existing features of iOS, so really, there isn’t much new design work there. Think back to Snow Leopard — it wasn’t completely devoid of new functionality; there was actually quite a lot. I think Mountain Lion is approximately on par with Snow Leopard in terms of the visible stuff.

All of this is meant to support the case for 10.8 as a big stability and performance release in disguise. Is this wishful thinking?

The next iPad will not be iPad 3. It will be iPad 2S.

Apple has established the pattern already with iPhone: after the original iPhone, there was a significant external hardware design change in the second generation, iPhone 3G. The third generation iPhone retained the exact same external hardware design as the second generation, and got the name “iPhone 3GS”. This was repeated with the new design of iPhone 4, inherited by the iPhone 4S.

The first generation hardware was not repeated, and served almost as a prototype. From the second generation, the hardware design lasts two product cycles — two years.

I would not be the first to speculate that this is related to the costs of manufacturing machinery and processes. Apple sees its competitive lead as being more than 2 years anyway, so why waste resources re-tooling its plants every year?

So far, the iPad seems to be following the same pattern: the second generation got a significant external hardware design change. Apple’s product naming strategy for iPad may differ from iPhone, meaning Apple may choose to name the next iPad “3”, but I predict the external hardware design will be exactly the same as iPad 2.

Note that this does not discount the possibility of a Retina Display. A double-resolution display does not affect the external design. It will certainly require different internals, but I’m only talking about the external design here — both the iPhones 3GS and 4S had huge internal upgrades.

So here are my predictions for the next iPad, just for fun:

• Name: iPad 2S.
• Form factor: Exactly the same as iPad 2.
• Screen: 9.7-inch diagonal; 2048 x 1536 resolution at 264 ppi. (This will qualify as “Retina Display” by way of typical viewing distance.)
• Storage: 32 GB, 64 GB, and 96 GB.
• Chip: Next-gen (“A6”?) dual-core SoC; improved graphics.
• Cameras: At most, a modestly improved rear camera.
• Software: Siri support; a point upgrade to iOS, probably “5.2”; more iCloud-based features; and at least one new feature that doesn’t work outside the US.
• Release date: 16th March, 2012.
• Price: USD $499 for 32 GB WiFi model; $829 for 96 GB WiFi + 3G model.

UPDATE: Since iOS 5.1 still hasn’t been released, I expect it will with the new iPad announcement. Also, it looks like the new chip will be named “A5X”, which leads me to think the name of the new iPad will be “iPad 2X”.

On his podcast with Dan Benjamin The Talk Show, episode #68, John Gruber said, of the way he views the Kindle Fire’s competitive position relative to the iPad:

The Fire is way more interesting, because it’s not an iPad rip-off. I mean, clearly it’s following the path that the iPad blazed in terms of basic form factor, and that the key to tablet computing is touch-based interfaces. It’s not the previous Microsoft style of styluses and full Windows operating system.

He’s right, of course, but what I anticipated him to say was, “The Fire is clearly sailing in the iPad’s wake, but that’s not to say they’re copying iPad.”

The truth is, as everyone knows, Apple didn’t invent the tablet computer. Microsoft didn’t invent it either, but they were the first to bring an actual product to market (AFAIK) with the Windows Tablet PC.

But the Tablet PC didn’t catch on. It didn’t leave a wake for others to follow. To stretch the boating metaphor, it was like a cargo ship scraping its hull on in too-shallow water.

The iPad followed the Tablet PC’s path, but it sails in deeper water — water that wasn’t there before. Apple brought the ocean.

And now the ocean is there, the Kindle Fire has an ocean to sail in. What we haven’t found out yet is, are they another boat in iPad’s wake, or just waterskiers?

Later in the podcast, Gruber makes the point that quite possibly zero people who have bought a Kindle Fire were first-time Amazon customers:

That you can say, ‘Look, if you trust us, and you already have an account with us…’ And I can’t help but think that almost everybody… I mean how many people do you think have bought a Kindle Fire, who didn’t already have an Amazon username and password? I mean, maybe zero! It might literally be zero people who’ve done that.

Thinking about what makes the Kindle Fire the first credible competitor to the iPad, it occurs to me that Amazon and Apple both have an immeasurably valuable asset to their names: millions and millions of credit cards.

Once a company already has your credit card details, it is so much easier for them to get you to give them money. This is obvious, but to finish the point, the user experience of entering credit card and shipping address details is long and painful. You have to type a lot of personal details into the website of a company you just met, and any mistake might mean you don’t get what you want, or worse, lose some money.

To flip it over, the point is that every account they have, with credit card details, is an expression of trust from the customer. Credit Card = Trust. You are already in business together. The asset that both Apple and Amazon have is the trust of millions of people.

And it’s all about trust. Amazon was the first truly successful retailer on the Internet. They basically invented online commerce. They had to invent a lot of the technology that allows us to use credit cards — a hopelessly insecure technology conceived in simpler times — on the new world of the Internet. When it comes to using credit cards online, Amazon brought the ocean.

Apple started building its stockpile of credit card accounts much later than Amazon, with the iTunes Music Store. And they leveraged the trust they had earned from making stuff that “just works” to add more accounts with the App Store. Steve Jobs quoted the number of accounts a few times in keynotes, particularly at WWDC, to encourage developers to write more apps, which sold more iPhones and iPads, which got them still more credit cards. This feedback loop has generated a great foundation for Apple to sell things to people, and it’s probably not even 10% of Amazon’s credit card accounts.

If credit cards are a proxy for trust, or at the very least a gateway for digital commerce, then what other companies have this? Seriously — who else has as many credit cards on file as Amazon and Apple? Nobody, right? Certainly not Google, and probably not PayPal, either.

If you stop and think about that, it implies a potential for almost all digital commerce to go through Amazon and Apple. That’s an incredible prospect. And it’s why I expect Apple to enter the market for ad-hoc payments. Maybe NFC, maybe something like Square, maybe something more like EasyPay, maybe something totally different.

But no company can do that without Trust. So the only question is, will it be Apple or Amazon?

The API for developers to interact with Siri will be in the cloud.

Siri requests are processed in the cloud, so the shortest path from Siri to apps is within iCloud.

This will require apps to be integrated with iCloud. Siri API will be a part of the iCloud API.

How this could work:

• An iPhone user speaks to Siri.
• Siri in the cloud deciphers the user’s speech, and figures out that the user wants a service from app X.
• Siri invokes the iCloud API of app X. App X responds with some text, an image, and/or a URL that their iPhone app has registered.
• iCloud returns this data to the iPhone, and Siri speaks the text, displays the image, and/or jumps to the developer’s app on the device.

What I haven’t figured out yet is how developers will register their apps to be invoked for certain phrases. Seems incredibly broad. And how will competing apps register to receive the same invocations?

It’s going to be very interesting.

In iOS, Apple hid the file system completely from the user, making apps the main way users find their documents. From the murmurs we’ve heard from WWDC attendees last week, it appears Apple is now preparing to do the same thing to Mac OS X.

If my memory serves me, this is not the first time we’ve had an app-centric OS. Windows was also app-centric in the beginning. Although Windows users were exposed to the file system, the Program Manager presented a grid of app icons, so we were encouraged to open Word and choose File > Open, or File > Recent. What I saw of Macintosh System 9 was similar.

Starting with Windows 95, the app-centric model was turned on its head. Applications were relegated to the Start Menu in the corner, and the user was presented with a large Desktop which could hold document files. Take a look at most Windows users’ desktops today and they are covered with a grid of mostly documents. Users are encouraged to not think about which application they needed, but simply find the file they want and let the OS open the right app. Mac OS X is essentially the same, with the exception that applications get a little more love in the form of the Dock.

So to me, this return to an app-centric style feels cyclical. I tried to express this in a tweet the other day:

1. Design app-centric OS.
2. “Which app did I create that doc in?”
3. Design doc-centric OS.
4. “Where did I put that file?”
5. Repeat.

I think we are just seeing the latest iteration of what may turn out to be a circular, fruitless search for the best way to associate applications and documents. Neither doc-centric nor app-centric approaches were a good fit for the user model.

Among the chatter on this topic recently has been a consistent theme: File systems are fine for nerds, who have learned them through experience, but not for casual computer users (aka normal people). I’ve heard the same argument made for the mouse-based GUI. In both cases, it would appear iOS has solved the problem by removing it. No file system, no mouse.

OK then, if this is just cyclical, eventually we will once again think of app-centric as confusing, and doc-centric as the way to go, right? But that’s still wrong, because otherwise how would we be here today, praising the virtues of an app-centric approach!

Yes and no. The problem with the last iteration of the doc-centric approach was that it was all about the file system. Every modern desktop OS today comes with a search tool (Windows Search, Spotlight, etc.) because finding documents in a file system is hard. But ultimately search tools are just a bad and often ineffective patch over an already broken UI: the system model (file system) does not match the user model.

So if the user model is not doc-centric or app-centric, what is it?

Good question. I don’t know. My guess is that the best choice is to mix both an app-centric approach, with doc-centric features like the following, without exposing the file system to the user.

1. Project-centric
2. Context-centric
3. History-centric

Project-centric — Let’s say you are working on a project to select from a few different software packages. You need a spreadsheet document to compare numbers and feature lists, some PDF documents containing the official quotes from the vendors, and a presentation of your recommendation to management.

All of these documents open in different applications, but they are associated, mentally, with the software selection project. The file system solution for this is to stick all the document files into a directory together, with the name of the project as the name of the directory. This is convenient, because you know you can go to that directory and have everything you need to work on the project. You don’t need to know or care which apps you used to create/read these files.

The problem with using the file system to implement the project-centric idea is that it’s easy to forget where the directory is — and more importantly, for most non-nerds the concept of a directory is alien to begin with.

The solution may be keywords (aka tags, labels). Don’t expose the file system structure to the user, but strongly encourage them to add keywords to their documents. Instead of asking for a filename on save, ask for keywords, and make it insanely easy to use keywords that have been used before.

Even entering keywords can be a pain, so maybe the OS could reduce the need for it by automatically picking up frequently-used words from the document to suggest keywords. If a human can look at a file and figure out some appropriate keywords, it would probably not be too difficult for some heuristic algorithm to do so.

Context-centric — The OS could track which documents are accessed in close temporal proximity to each other, and automatically guess that they are part of a project or workflow. If Document A and Document B are frequently accessed within a few minutes of each other, the OS could make it easy to jump from A to B and back again.

To make this more explicit, users could be prompted to associate A and B when this happens: “Is this document related to A? [Link Docs] [Not Related]”.

Taken further, the OS could look deeper into the content the user is working on, and attempt to make some intelligent guesses based on their context.

History-centric — I would guess that the vast majority of work on documents happens within a relatively short time range, and therefore documents that the user needs are almost always in top 50 most recently accessed docs.

A good UI for quickly jumping to very recently accessed docs might take us 80% of the way there.