I Don’t Typically Do This

That we had to wait two years for the iPhone’s text selection and pasteboard is a good example of one aspect of the Apple way: better nothing at all than something less than great. That’s not to say Apple never releases anything less than great, but they try not to. This is contrary to the philosophy of most other tech companies — and diametrically opposed to the philosophy of Microsoft. And it is very much what drives some people crazy about Apple — it’s simply incomprehensible to some people that it might be better to have no text selection/pasteboard implementation while waiting for a great one than to have a poor implementation in the interim.

It’s hard to prove that good is the enemy of great, but the evidence speaks for itself.

I find the Apple’s way of handling the App Store approval process and John Gruber’s assessment of their desire for perfection to be in complete contradiction with one another.

(Hat tip to nikf for helping me draw the connection by posting the two links one after another)

Last year when I got my iPhone 3G to replace the first-gen iPhone, I took a screenshot of my data usage and then reset the statistics. I did the same this year when I got my 3GS to replace the 3G. Here are the two shots for comparison:

AT&T:

All of that said, we’ve been listening to our customers. And since many of our iPhone 3G customers are early adopters and literally weeks shy of being upgrade eligible due to iPhone 3G S launching 11 months after iPhone 3G, we’re extending the window of upgrade eligibility for a limited time.

We’re now pleased to offer our iPhone 3G customers who are upgrade eligible in July, August or September 2009 our best upgrade pricing, beginning Thursday, June 18.

I got my 3G S for $199 using my mom’s upgrade eligibility (I’m not eligible for an upgrade until March 2010), so this doesn’t affect me, but given how poorly AT&T fared at the WWDC keynote, the fact that they actually listened to their customers is a welcome surprise.

As a paid member of the iPhone developer program, I was invited to beta test push notifications using a beta of AIM. After spending a few hours last night with push notifications turned on, I quickly realized that Apple’s implementation of push notifications needs some work before it comes close to both Google’s and Palm’s offerings.

Apple introduced push notifications as an answer to the complaints that the iPhone OS doesn’t allow apps to run in the background. The APNS (Apple Push Notification Service) works by having the iPhone maintain a connection to Apple servers. Developers can send messages consisting of text, badge icon numbers and/or sounds to Apple’s servers, which are then relayed to the phone. When a phone receives a push notification that includes text, an alert (similiar to an SMS alert) is presented to the user with options to close the alert or view the message. If the user chooses to view the message, an application is launched and it handles the message.

Apple hopes that push notifications serve as an alternative to background apps, which decrease battery life, complicate the user experience and can affect performance. In reality, push notifications fail as a solution when the iPhone is disconnected from the internet and when applications need to access data from the device, namely media players and GPS applications.

The first case is the most disconcerting because it removes push notification functionality from all applications, even for those which the solution is appropriate. This is especially detrimental for applications such as to-do applications who wish to remind users when a task is due that might utilize APNS as a workaround for the lack of a calendar API. These applications might appear to not need access to the internet, but Apple’s solution requires it in order to get full functionality.

The second class of applications have the most pressing need for the ability to run in the background, and push notifications do absolutely nothing to address their needs. For example, push notifications do nothing to allow users to listen to Pandora while playing a game, surfing the web or composing an email.

Further, Apple’s implementation of push notifications is so simple it borders on detracting. Here is how I spent the first few minutes with the AIM beta:

• Incoming IM
• Push “View”
• AIM opens, takes 20 seconds to log in
• Respond to IM
• Quit AIM
• Return to Tweetie/Flight Control/etc, takes 5-10 seconds to load
• Incoming IM (ignored)
• Incoming IM (ignored)
• Incoming IM
• Push “View”
• AIM opens, takes 20 seconds to log in
• Respond to IM
• Quit AIM
• Return to Tweetie/Flight Control/etc, takes 5-10 seconds to load
• Incoming IM
• Push “View”
• Respond to IM
• Sign out of AIM and disable push notifications

For each notification, I lose 30 seconds if I choose to respond, and since the notification is modal, I am forced to interact with the alert even if I want to ignore it. Compared this to Android and webOS, where notifications are unobtrusive and can be dealt with at the user’s convenience.

After spending just a few minutes with push notifications, it is apparent that Apple’s implementation is not only too limited, but it actually detracts from the user experience. The APNS also doesn’t address the entire class of applications that require background processing, the main reason Apple developed the service. This new system only serves as a shiny thing to distract us for a few months until the shine wears off and we’re all back to complaining about the continuing inability to run background applications.

Jason Snell on the lack of public iPhone specs:

The more complicated a product gets, the more technical acumen is required to put it together. Bad Web sites are built by people who know how to code HTML and JavaScript but don’t understand how people use the Web. Bad software is written by people who are experts at knowing how a computer works and how to write code to make it do what they want, but no idea about how regular people behave and how those people expect to interact with that software. Bad hardware is designed by people who choose the shape of devices and the placement of buttons based on the best way to lay out the internal circuit board, not by people who think about the most convenient ways for the human body to grab hold of that hardware and press its buttons.