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 dabs.com 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.

Leave a Reply