Robert Chien's Blog

To facilitate push Email to mobile devices? I'm doubtful, here are the reasons:

First, IMAP IDLE relies on keeping the IMAP connection alive. Mobile devices are more likely than desktop clients to experience network errors and timeouts as they travel. And devices capable of both Wi-Fi and cellular, like Apple's iPhone, automatically switches from one network to the other, terminating the connection as they do so. I feel that a true push solution should not depend on a persistent connection.

Second, an IMAP IDLE session only monitors a single mailbox. If you need to watch multiple folders simultaneously (like if you use server-side filtering or subaddressing), you need multiple sessions. Is any client capable of that?

Third, maintaining the session not only drains the battery, of which mobile devices have limited amount, it also hogs the data channels so I don't think telcos like that idea very much.

Michael told me OMA-EMN uses sideband SMS for notification, so it's designed to be friendlier to battery and network operators compare to IMAP IDLE. But I've yet to come across a client that supports OMA-EMN.

Last Friday, we got a Samsung Blackjack II (not by choice) in the family and naturally, being the Chief Geek, I had the "honor" of setting the phone up. I have to say this Q/BlackBerry killer turns out to be quite a disappointment. The WM6 user interface is convoluted, the device is cluttered with AT&T junkware and the thumb keyboard feels cramped. Motorola's mobile enterprise messaging and calendaring suite called Good is a pain to use.

But the biggest turn-off is the booklet of manual that comes with the phone. Why couldn't the product designers make a feature so intuitive that it needs little to no explanation?

As WSJ's review of the Flip says: "[Devices should be] so simple, mastery is immediate, and so is your sense of pride and happiness."

The importance of that latter part is what the collective Microsoft-AT&T-Samsung-Motorola team did not understand and embrace. While they packed the smartphone with an impressive list of functionalities, they also overlooked the experience of unboxing the gadget for the first time. Result: customers are overwhelmed with features they can't use unless they read the manual first.

In contrast, Apple's approach to product design reflects in their minimalistic user manual. The entire iPhone manual comes on a single double-sided sheet with large screenshots.

If you make a consumer product, it's best to assume they won't read the manual at all.

If your product has features that are fragile or unusable without some manual reading up front, you need to rethink your design.

If you're improving on a product, slashing the existing manual by 50% or more should be a top priority. Then slash it again. Why do it if people aren't going to read it? Because the exercise forces you to create intuitive features, leading to a better experience, therefore a better product.

This is a follow-up and correction to my previous post: iPhone supports IMAP IDLE.

After more testing, turns out iPhone does not support IMAP IDLE (on a Wi-Fi connection, firmware 1.1.3), it instead Auto-Checks every 2-5 minutes despite the Setting says don't. I verified this by enabling IMAP telemetry in Dovecot 1.0 through its rawlog facility. Even though the server advertises IDLE in its CAPABILITY response, iPhone's client never issues the IDLE command.

Is that a loss? Probably not. According to this thread, beta testers of the iMapIdle utility report significant battery drain while IDLE runs on a Wi-Fi connection. On an EDGE connection, the drain is not as bad. But when iPhone switches between Wi-Fi and EDGE, the IDLE session gets dropped. For these reasons, I can see why Apple designers chose to not implement IMAP IDLE on iPhone.

Now that IMAP IDLE support in Gmail is confirmed, the logical next step is to see if iPhone supports it as well, and more importantly perhaps, how much value does it add over client-side polling? The short answer is yes, iPhone has IMAP IDLE, but updates don't come in real time. Here's how I tested it (on a Wi-Fi connection, firmware 1.1.1):

1. Under Settings -> Mail, make sure Auto-Check is set to Manual
2. Under Settings -> General, make sure Auto-Lock is set of Never
3. Open my Gmail Inbox on the iPhone
4. Create an IMAP IDLE session to my Gmail Inbox using openssl(1)
5. Send a test message to my Gmail account

I repeated the test 3 times. The messages took 2-4 minutes to show up on the iPhone so there's quite a bit of delay. Header information shows end-to-end delivery times of 3-14 seconds so the delay isn't in SMTP. In the IMAP IDLE session, the server transmitted updates also within seconds so the delay isn't in IMAP either. I believe it's fair to conclude that the delay is caused by iPhone, specifically the way it handles IMAP IDLE. My guess is the designers opted for battery conservation over speed of new mail notification.

Then how much better is push IMAP than pull IMAP? Based on the above, I'd have to say not much, at least not on iPhone.

[UPDATE Feb 21, 2008] Part 2: turns out iPhone does not support IDLE.