Scheduling on the Interwebs – A Wishlist

I was just reminded of Mail to the Future, a 1998 Userland webapp that lets you – anyone? anyone? – mail to the – anyone? anyone? -future. (Respect for self-documenting webapps.) Another webapp – of similar homebrew feel – that came out around then was the birthday reminder system by Philip Greenspun and Olin Shivers. It mailed you birthday reminders once a year.

Scheduling hasn’t progressed much, at least not in the mainstream. Here’s my wishlist:

  • I should be able to push something into an RSS stream for later on. Similar to using mailtothefuture for mailing myself in the future. For instance, if I’m reading an article about some new technology, and I want to discuss it with a client I’m visiting next month, I could say to Bloglines “show me in a month’s time”. Of course, this could lead to a write-only situation, like a stack of videotapes that never get viewed, but that’s another problem – the option should at least be there. This would make a nice Firefox plugin too – copy the whole contents of the current page – or a particular link – into a future RSS stream.
  • My mail client should give me a “send date” option .
  • My publication software should likewise let me schedule a document for public release at some later stage. Among other things, this would let me provide a steady stream during slow times if that is my want. It could even be extended to be a bit smart about posting frequency, so as I don’t even need to provide a precise date. Ruling out a post-apocalyptic AI algorithm in which it predicts when I’ll next be posting, perhaps I could just tell it I’ll probably be busy for the next week or two. Or it could peek in my calendar and work that out for itself.
  • E-Commerce sites should let me postpone an order until a later date. Allowing future purchase dates would help people manage their finance, and also ensure packages aren’t delivered when the recipient is in the middle of a vacation. The gut reaction from managers might be that allowing people would then have longer to cancel, in case they changed their minds or found a better deal. In practice, that’s a false economy, for a couple of reasons: (a) firstly, it’s a cheap thing to implement, so if popular, it would become standard practice and its absence would drive many customers away; (b) secondly, the option to cancel is a nice-to-have which would likely add a lot of purchases with few extra cancellations.
  • Calendars and RSS are a good fit, but there will need to be more interaction, e.g. a “remind me later” feature. I’m sure there are probably lots of people talking about adding calendar alerts to RSS feeds. That would be nice, but the history of calendar software indicates that it’s always more complex than you’d think. For instance, “Remind me later” is a very powerful feature that really needs to be included. Other forms of interaction, too, like accepting an appointment. The next big thing for RSS is destined to become more interactive, as demonstrated by Russell Beattie’s comment forms. Aggregators will play a big part here. In the calendar example, you could have a form inside the RSS entity to let you enter a future time to be reminded about the event.

As a side issue, the E-Commerce example is interesting because of something that happened to me this morning. I purchased something on and then – after receiving some further information – realised I had to cancel it soon after. So far, I haven’t received a human response, and dabs being dabs, I probably never will. So they’ll end up sending it, I’ll end up exercising my option to refund it, and we’ll both lose time and money. If they left every order open for at least a couple of hours – the most likely time that someone will change it – they would probably save themselves and their customers some grief. I’m speculating Amazon does this even when they can fulfill immediately.

“A” is for Asynchronous – Think AJAX, Think Modeless

Today’s entry is brought to you by the letter “A”. The “A” in AJAX stands for Asynchronous, and Cédric Savarese cautions that many AJAX applications treat XMLHttpRequests synchronously. That is, they submit data and do something when it responds. He cautions:

What happens really is that XmlHttpRequest is not used for what it is good at: asynchronous, behind-the-scene, access to the server, but in the context of a synchronous transaction by the user.

His solution is to get the client doing most of the work. I agree the browser needs to do more work, but I don’t think it’s as simple as turning the browser into a platform for smart Javascript applications. Instead, a better solution is to think modeless. The web has traditionally been a back-and-forth conversation between browser and web server. Many have pointed out that this style mirrors the old client-server mainframe applications from the ’70s and ’80s. Under that paradigm, the computer’s drives the show. Then came window-based GUIs and suddenly the user’s calling the shots. Everything is conceptually parallel – all the objects you see on the screen are alive, responding and communicating with each in parallel with the user’s activity.

“Modeless” is how we need to think with AJAX. I realise the latency imposes a massive constraint on that type of thinking, but it’s still the right direction to work towards. In fact, as we’ll see below, the latency makes the case all the more compelling.

A GUI examples illustrates the point. Some GUIs are more modeless than others, and Allan Cooper’s “About Face” described different styles of form validation in GUIs. Here are two ways you can validate a form in a desktop GUI: + Modal: When the user enters an invalid field, immediately pop up a dialog box, ensuring they don’t proceed. + Modeless: When the user enters an invalid field, change its background colour and let them fix it later.

The second approach is modeless, and users generally prefer this style because it feels like they’re working with the computer rather than for the computer. An AJAX live form, by analogy, might operate in two ways: + Modal: Each time the cursor leaves a field, go the server and validate it synchronously, popping up a dialog box and not proceeding if in error. + Modeless: Each time the cursor leaves a field, send an asynchronous validation request to the server, but let the user proceed and, in parallel, change the background colour (with a message perhaps) for any fields as results come back from the server. This can be be quite effective if the server provides some progress indication, as well as an indication of synchronisation status (several AJAX patterns address this).

In both cases, the user is more free when invalid fields do not cause a halt in proceedings. In the AJAX example, the modeless case is even more compelling. Due to the performance issue, modeless form-filling will proceed much more quickly. In most cases, the fields will be invalid, so there’s no major problem with the switch in attention back to any invalid fields.