Still from the dev angle, I think it helps to flip “user agent” around to meaning something approximately like “an agent which may behave like a person operating a browser/RIA”. Looking at the wire at that point allows the components to be built with reference to a common interface (essentially RESTful HTTP).

Ok, so far this doesn’t sound like it helps the humans much. But if the machine components have a consistent interface, it enables a clear distinction to be made between the machine-machine comms and the human-machine comms. The latter interface is decoupled from the former, and there’s less likelihood of developers shoehorning designs for one into the other.

It’s a bit paradoxical, but I also think this “agent which may behave like a person” model liberates the developer from the human-facing considerations.

In essence this is only really about separating UI design from backend design, but traditional approaches to this have been developed on the desktop/LAN, a very different environment from having the whole Web as a backend.

I’ve recently had great experiences on a Sun project working with senior user experience engineer Jen McGinn, and Jen also contributed greatly to the analysis I did for the talk — so let me take this opportunity to thank her! Her approach gives me hope that ordinary non-experts can become better designers without taking a huge resource hit.

I will recommend Don Norman’s book “The Design of Everyday Things”.. Even though it’s mostly about doors — you heard me, doors — it discusses these concepts and near the end there’s a list of human-centered design principles.