techno.blog("Dion")

I love the Twitter for iPad application and how Loren et al have built an experience that feels right in your hands. There is one bug though that can drive me crazy, and that is the fact that the unread state of direct messages is broken. It feels like 99% of the time I will open up the application and the last 20 messages will have unread:true, even though I know I have read those messages. The bug is particularly irksome because it is so in your face. The messages tab is highlighted as though there are no items even though I know there is nothing new for me (and I just need to go through again and mark them all as read? ugh).

It made me wonder how Twitter was handling the state of direct messages. In creating Facebook for webOS we built out FB messaging, and the state was handled for us. The Facebook design has the notion of threading baked in (as apposed to email for example) and is as follows:

• A user has multiple mailbox folders (default messages, sent, updates)
• A folder has multiple threads
• A thread has multiple messages.

So, where is the unread flag kept? You may think that it is at the message level… after all, it is a message that is either read or not. However, the thread actually controls the flag for Facebook. This means that in a conversation there is basically an int count that shows you how many messages are unread. If zero, then all messages in the thread are read. There are trade offs on having the unread flag be a count and not a flag on the message layer, but the high level point is the core platform is keeping track of what a user has done. Whether you go through the website, or any application that speaks the Facebook API, as long as your application doesn’t cache too aggressively, you will have a good result. The key becomes: as the platform developer you very much understand that the service is the master, and you need to be smart about caching data to give your users a responsive interface, but make sure to sync on the data to make sure it is accurate.

The Twitter API on the other hand doesn’t appear to keep any unread state for messages. Echofon is a cross platform client that showcases its support for syncing this kind of data. It is a nice feature for them to be able to differentiate on, but man….. it sucks that they have to write it!

I hope that Twitter starts to own the state so we aren’t in the current situation of no one really knowing my state, and it has been interesting to see the different state of affairs, and have you thinking about what the platform should be doing, and what should be left to the clients of said platform.

I believe that 2008 and beyond will be huge for mashups and APIs. We are going to move beyond the world of “Look, I took some data and put it together with a Google Map and Calendar” and have full featured read/write in browser APIs thanks in part to the slew of cross domain friendly features that are coming from browsers, Gears, and developer hacks.

I have talked about the blog.gears example, that shows how you can use Blogger as a back-end for a blog system. It seems quite obvious to me that if you are building a Web application that isn’t the Next Blog Thing, why would you want to spend any time building a blog system to get that functionality in the product. You have a couple of choices beyond writing it yourself. You could grab an open source blogging engine (there are many great ones), you could use a service and have blog.* CNAME over, or if you want tight integration you could do what blog.gears does, and use a JavaScript API to access blogger as the store and have it hidden from the user.

I got to thinking, how will the fact that it is easier to integrate with sites through richer APIs affect M & A?

An example that got me thinking about this is Dopplr and TripIt. Dopplr is a phenomenal service that seems to nail usability and the art of doing one thing, and doing it really well. It is clean. It has subtle touches that I love (the personal colors in the header icon and favicon even).

Them came along TripIt. The killer feature that it has is the ability to email your itineraries that you got from online sites and airlines to the system, and it groks a bunch of the formats and can thus suck them in automatically. Once you hit Apple-F, you are done, and you see the new information appear in your TripIt iCal.

Compare this to Dopplr. For a long time you would manually input your travel information in some shape or form. At the London Future of Web Apps I met Matt Biddulph, who not only was a fantastic, nice, fun guy, who gave the best talk at the event, but also was able to flip a bit which enabled Dopplr to read one of my Google Calendars. This feature is now in the wild for all. That was a great improvement, as I could setup a “Travel” calendar that Dopplr reads from.

I still had to keep that calendar going through. When TripIt came out, I heard cries of Dopplr fans that they should buy TripIt, or merge, or just copy the functionality. That isn’t the way with 2008. Instead, Matt was able to integrate with TripIt in a very simple way.

TripIt produces an iCal calendar from it’s data, and you can simply tie Dopplr to that calendar… and ta da!

I have been in quite a few meetings recently where the topic of buy has changed to be integrate through APIs. This enables each piece to grow, and to have people work on one small thing and make it the best it can be.

Of course, there is a time and a place for buyouts and mergers, but I wonder if they will be a little less frequent now. Then the game changes to being the platform, and being able to monetise it (a.k.a. make money to feed your family!)

Fixing calendars

As an aside, I still find a lot of pain with calendar systems. The main problem that I have is that I want events to cross various calendars, but collapse them in my view. For example, if I am going on a trip, I want my wife to see it, as well as my work colleagues. I don’t want to have to duplicate the entry in multiple calendars and then see the same darn thing repeatedly.

Once you start delving into the WorkerPool API, you quickly see how a common pattern would be using it as a messaging system. As it stands, it looks like an Open Web version of Erlang processes.

Scott Hess wrote up his thoughts on a more formal Messaging API based on WorkerPool:

Gears WorkerPool has two pieces, the part about running a bit of JS asynchronously, and the part about trading messages with that JS. This API may be composable from more basic bits. The messaging bit could be used in other contexts, such as implementing something like WhatWG’s postMessage().

Aside: What is WhatWG’s postMessage?

postMessage is “a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.”

Here is an example:

For example, if document A contains an object element that contains document B, and
script in document A calls postMessage() on document B, then a
message event will be fired on that element, marked as originating from
document A. The script in document A might look like:

var o = document.getElementsByTagName('object')[0];
o.contentWindow.postMessage('Hello world');

To register an event handler for incoming events, the script would use
addEventListener() (or similar mechanisms). For
example, the script in document B might look like:

document.addEventListener('message', receiver, false);
function receiver(e) {
  if (e.domain == 'example.com') {
    if (e.data == 'Hello world') {
      e.source.postMessage('Hello');
    } else {
      alert(e.data);
    }
  }
}

This script first checks the domain is the expected domain, and then
looks at the message, which it either displays to the user, or responds
to by sending a message back to the document which sent the message in
the first place.

Back to the Gears Messaging API

Scott gives an example of the messaging API, starting with an end point:

var port = google.gears.factory.create('beta.messageport', '1.0');
port.onmessage = function(port, msg, sender) {
  alert("message: " + msg);
};
port.listen("name");   // Omit for anonymous listener.

and having a way to send it a message:

var port = google.gears.factory.create('beta.messageport', '1.0');
port.open("name");
port.sendMessage("hello there");

To enable cross domain, you can post.open(name, domain), and on the other side, you have to allow it via something like port.allowCrossOrigin(["www.good.com", "www.angelic.com"]);.

I am excited about a messaging API, as I think that it fits into the way in which we are developing new Web applications. Having an asynchronous queue that allows me to replay work (e.g. offline), and work nicely with Comet based interactions, would be great. We can reuse all that we have learned from other event based systems, and Gregor can rename his book and be happy!

Other Future APIs

• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.