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

I bought my first ever down jacket this year, while in Australia on Christmas holiday. Thanks to the post-Christmas sales, and the fact that it’s summer in Australia, I managed to pick up a $500 Kathmandu jacket for $150.

It has paid for itself already.

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 “Retinal 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.

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?

Phase 1. Use a GTD system. It works well. Things are getting done, nothing is being forgotten, and you’re feeling less stress. Life is good in Phase 1.

Phase 2. You grow confidence in your system. So much confidence that you throw new tasks into it with giddy abandon. Adding tasks to the system starts to give you the same feeling of accomplishment as actually completing the task. (This is obviously wrong, and the first warning sign.)

Phase 3. Tasks are going into the system much faster than they’re coming out. It starts to grow out of control. The number of tasks becomes overwhelming, and you resist looking at them.

Phase 4. You try to regain control by “organising” the system. You make categories and special lists. You associate actions to projects. You invent new disciplines for yourself to “keep things organised”.

Phase 5. The work required to keep the system up-to-date starts to exceed the time spent on the actual tasks it tracks. Now you feel it’s not working. Something has to change.

Phase 6. You notice an article or an ad for a “simple”, “clean”, and/or “powerful” to-do manager. You think, “That’s what I need! This system I have now is too complicated, too hard to use.” And you switch. Maybe you figure out a way to export all your projects and actions from the old system and import them to the new. Or maybe you decide to “start fresh.”

Repeat from Phase 1.

I’ve personally been through about 7 or 8 different GTD systems. That’s 7 or 8 times through the cycle above. I know it well. And I just completed Phase 6 again this week.

As a future reference for myself, more than anything else, here are some thoughts on what makes GTD tick — what makes a “good” GTD system.

First, and most important, GTD is a process of thinking, not a system or a tool.

A couple of years ago, I heard an interview with one of the “coaches” from the David Allen company, talking about her experiences teaching GTD. She said that often people will ask what’s the best tool to keep GTD lists, or complain that they really like their Filofax, or their Outlook, or their Post-it notes. She would say, “That’s fine! I can teach you how to do GTD on Post-it notes.” Her point being that GTD is about thinking what is the next action, and relieving your brain of the burden of having to remember so much stuff.

So it really doesn’t matter what your tools are. In fact, I’ve found that the tools can actually get in the way, because they distract me from the really important job of thinking.

Second, don’t invent parts of GTD that aren’t really there.

A classic and very common example is association between projects and actions. It’s so common for GTD tools to offer a way to link projects to actions, that many people I know think that it’s part of GTD. It is not. This is like that Real Monopoly meme. Go back and read the GTD book again — it’s not in there. There is even specific advice not to try to link projects and actions. You just need a Next Actions list, a Projects list, and that’s it.

The rationale for this is that if the project is current, the action real, and you are doing your Weekly Review, you will know which actions relate to which project.

Having learned this lesson once already, I again fell into this trap while using Flow. I am now convinced that trying to link projects and actions is death to a GTD system. Having actions tucked away in project lists just keeps them out of sight, out of mind. And it hides the true size of your system. Keeping your lists short should be part of the motivation to get things done, and to not over-commit yourself.

Third, use the Someday/Maybe list aggressively.

When you find yourself with a bit of time, scanning your actions list to find something you can get done, you should be able to complete any action on the list. If you look at an action, there can only be three possible reasons why you can’t do it right now:

1. It needs a context, either a place or a person, to get done. If this is the case, you should really annotate the action with that context right away, so you don’t go through this again next time.
2. It’s not really a next action, i.e. you haven’t done enough thinking to boil down the next “physical, visible thing needed to move the situation forward.” If this is the case, do that thinking now, and replace this action with the real next action. Then do it.
3. You don’t want to do it. If you don’t feel motivated to complete the action, and it’s not because of the two reasons above, then either delete it and forget about it, or move it to Someday/Maybe. (This also applies to projects.)

The goal here is to keep your Projects list and your Next Actions list as short as possible. They should be a list of things that you are really motivated to complete. Looking at these lists should get you excited, not make you groan.

Moving something to Someday/Maybe is not throwing it away, so long as you commit yourself to reviewing the Someday/Maybe list regularly, about twice per month or so. Of course, when you do, delete things that you recognise will never happen — you don’t want that list to become overgrown and full of useless crap, either.

Fourth, no metadata, no notes, just things on lists.

Another bad habit encouraged by all these GTD tools (especially electronic) is adding all sorts of tags, due dates, priorities, notes, etc. The best GTD system I ever had was paper-based. I really encourage people to try running a non-electronic GTD system for a few months. The nice thing about paper-based systems is they resist a lot of metadata cruft. You can write down due dates, tags, priorities, etc., but it’s a lot more effort, so you don’t so much.

This is how it should be, even when using an electronic tool. The occasional due date or priority highlight is fine, but over-reliance on them dilutes their meaning, to the point of becoming a waste of time.

Fifth, don’t get too hung up on contexts.

I’ve never found it helpful to keep separate lists for each context, mostly because there would just be too many of them, and again, having a lot of lists means actions are hidden and easily forgotten.

It’s best to just keep one big list of all actions (or two, if you use “the line”), and note your contexts at the beginning of the action, e.g. “@Dad — ask about ideas for Mum’s birthday present”. It works well for both paper and electronic systems, because you either scan down the list visually, or just search for “Dad”.

And anyway, what are those contexts? For me at least, there’s @Home and @Office, and maybe @Shops, and the rest are people. And since most actions in “people” contexts can be accomplished by phone, email, or text, they can actually be done anywhere, anytime. So don’t spend a lot of time adding contexts. Add them only when not being in a context prevents you from completing an action here and now.

Finally, GTD is about getting things done.

Any time spent fiddling with the system is time not spent completing actions. Behind every minute spent “organising” the system, is a reason why you’re not motivated to complete the actions in there. Find that reason. Figure it out. Move forward.

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.