The beauty of the delayed, accumulative task
Friday, 9 July 2010
For a while now, my much-beloved RememberTheMilk have adopted a classic user-interface detail, the genius of which I’m sure has been overlooked by many. They are certainly not the first — nor will they be the last — to do apply this, so I guess this is more of a celebration of user experience innovation rather than of RTM themselves, but their app does provide a perfect example that the user is explicitly made aware of.
The element I speak of is their process of synchronisation between your mobile client and their servers. When using a mobile device, you’re likely going to be connected to the web via a cellular connection (3G, EDGE or GPRS if you’re that unlucky) and thus your bandwidth is going to be severely limited compared to the fibre line connected to your home. You’ll be limited by both a by-the-second technical transfer rate limitation and maybe even an artificial monthly quota imposed by your carrier.
With a task management app like RTM, the frequency at which you sync between the mobile and your master set of data is going to be fairly high and as we all know — HTTP requests are expensive. It’s good practice to make as little of these requests as possible (a rule that is understandably disobeyed on the desktop where a reliable, snappy connection enables things like AJAX feasible). You also have to give your user a very ‘connected’ experience and ensure your mobile app mirrors the master data as closely as possible. Ahh, the good old performance/usability concession.
In steps the concept of the delayed, accumulative task. In the same way a delivery company will not deliver packages to your home one-by-one as soon as the shipment is consigned, but rather spool the deliveries received over a certain time period before sending them out as a set, your RememberTheMilk app will, upon seeing an alteration to your data, wait for 3 seconds before notifying their servers of the change. Any other data changes that occur during this 3 second delay will also get noticed by the app and will be sent, in a batch, along with the first change that triggered it.
A fantastic way to reduce the frequency of naturally very slow and bulky HTTP requests over what could be (or will be if you’re on an iPhone) a very spotty data connection where network utilisation should be kept at a minimum — a good rule to follow universally with software development, but all the more important on the mobile. The complexities of enabling data access at multiple endpoints (and concurrency issues in general) are still there, but at least it’s not taxing the device’s potentially limited connectivity.
However, this certainly isn’t a silver bullet. The 3 second delay in accuracy between server and client is not going to cause any out-of-date information inconveniences, but waiting for the sync operation to happen can be a problem. Until iOS 4, iPhone users of the RTM app would literally have to sit and wait for this 3 second delay to finish and the sync process to complete before moving away from the application to do other things (or perhaps to complete the task they just added — those 3 seconds can aggregate to a noticeable productivity sink). This isn’t much of a problem now with the new background task API but a method of interrupting the 3 second delay and forcing an immediate synchronisation I’m sure would be welcomed anywhere this technique is used.
So, in closing, I would like to issue the biggest of big-ups to all the awesome UX designers out there. I hope to someday join your ranks.
