Activity-Based Computing

A couple of weeks back I had the great pleasure of accompanying researchers from KDDI Research Institute in visiting various Silicon Valley entities doing pioneering work in the field of user interface. It was great great fun and made me very appreciative of working where I work.

One common theme cited during each meeting, seemingly without coordination, was a move to activity-based computing, one definition of which is available here, at the home of the Activity Based Computing project at the IT University of Copenhagen, which reads:

Activity-based computing has emerged as a response to the traditional application- and file-centered computing paradigm, which is oblivious to a notion of a user task spanning heterogeneous devices, multiple applications, services, and information sources.

Put in layman’s terms, activity-based computing had two implications when compared to a traditional application-based workflow, one on the input side, i.e., the user side of the device, and the second on the storage side, i.e., where user data resides, off-device.

An example of the first is a common UI that straddles applications. Professors John Canny and Tye Rattenbury of UC-Berkeley presents one example of this here. Files are shown in an activity cluster.

Another public example of this is Mozilla Labs’ Ubiquity, which is also, by dint of being Mozilla and therefore public anyway, is the one visit I can talk about. We met with Aza Raskin, head of User Experience at Mozilla Labs. (As it turned out, Aza had spent time at Tokyo University doing research into dark matter and speaks Japanese. Truly a man of many talents.)

Aza showed us an alpha demo of Ubiquity, which was truly, truly impressive. Within a common UI, the user can invoke functions that would normally require multiple separate tabs and likely a fair bit of cutting and pasting – email, mapping, search, language translation.

Ubiquity is command based. Language is more natural than, say, a DOS prompt, and commands can be added on the fly. This, in turn, is predicated on a level of trust, as certainly one could see the potential for malevolent populating of commands. I suspect the same swarm techniques that deal with email spam or comment spam could applied here.

There’s an implication to ABC on the back end, which is the ability to view and interact with the same data across multiple devices, be it a PC or wireless phone or public terminal. Some call this cloud-based computing.

Replicating comparable user experiences across heterogeneous devices is predicated upon relatively unfettered access, say, at the level found on the PC-based Internet. In wireless, this is both a throughput issue, an openness issue and in some cases a simple UI issue. There are many tasks I just don’t bother attempting in my Blackberry Curve’s WAP browser because I know it won’t render well, and some I don’t attempt because it’s running on an EDGE network with nominal throughput of 220 kbps, and effective throughput around 1/3 that. (Don’t get me wrong. I love my Blackberry. What it was designed to do, it does very well.)

From the access provider’s point of view, there may not be full incentive to be “open”. Wireless pioneer John Stanton, at the recent CTIA Wireless IT show, noted that access providers typically grow at the rate of GDP growth, where as the US wireless industry is still growing at high single-digit rates. Why, then, should wireless service providers rush to act like ISPs?

A broader subject than this post, perhaps. Suffice it to say Ubiquity is indeed worth checking out.