Affordance and the API

Geeks spend a lot of time talking about what’s possible with a particular technology. We pride ourselves in being able to wring every drop of interactivity out of a platform, of doing things with the tools that the toolmakers never would have thought possible. As a result, any argument about software platforms often falls into the following pattern: Detractor of Platform A will say something like “you can’t do drag and drop in Platform A”. Supporter of Platform A will respond that you can so drag and drop in Platform A, and will post the code to prove it. Score one for the supporter: the detractor simply wasn’t able to use the tool.

From an engineering perspective, the entire conversation is pretty juvenile. Being able to do something with a tool is irrelevant. Software is so flexible (that’s why they call it soft ware) that with dedicated, smart people, and enough money and time, most things are possible. The problem is that most software teams don’t have enough dedicated smart people, a big enough budget, or enough time. If you have to write custom code to do drag and drop in platform A, than your application likely won’t support drag and drop.
Gmail is a living example of this frustrating tension between the possible and the practical. The Gmail UI is pretty sweet: data is cached on the client so that it displays instantly when you ask for it. It’s written in old-school DHTML, but it feels as responsive as a next-generation RIA. Why wasn’t this done before?
The short answer is: this is what happens when a company with 25 biiiiiiillion dollars and every Stanford PhD who has graduated in the last 10 years decides to tackle a problem. The accomplishment is so impressive because writing cross-browser compatible code is really hard. Writing organized, maintainable javascript code is also really hard. We’ve had the basic ingredients of DHTML (CSS, Javascript, HTML) for a while now, and haven’t seen much more than interactive pop-up menus come from the technology until now. If something is really hard to accomplish using a particular platform, a typical engineering organization simply won’t do it.
In order for a platform or tool to have utility for a typical engineering organization, you must use it only for what it is “meant” to be used for. This is because your work is typically being done by engineers who 1)are fairly new to the platform, and 2)are too busy to invent, discover, or copy any of the tricks that would come up in a “you can’t do X on platform A” conversation.
The word for this characteristic of what things are “meant” to be used for is affordance. A button calls out to be pushed. A hammer calls out to be swung. Javascript calls out to be used to code client-side form validation. Flash calls out to be used to make cartoons. Affordance is about the action that is easy and natural to do with a given item.
The reason that the technology industry is salivating over Flex and Lazslo technology isn’t that they enable us to write software that was previously impossible. Anything you can write in Lazslo or Flex, you can write in Flash (if you’re really smart, really rich, and have a lot of time). But Laszlo and Flex call out “use me to make an RIA with dynamic, liquid layout and standard, off-the-shelf UI widgets”. They solve the hard parts of that task (how do I write a layout manager? How do I structure my code? Where do I get my widgets from? How do I hook this thing up to a server?). They have affordances that make them suitable platforms for building SWF-based RIAs.
Affordance is the single most reliable predictor of how much success your engineering organization will have using a given tool for a particular purpose. Imagine coming to the tool fresh, without having been exposed to a blizzard of marketing. What does it look like it’s good for? If you’re using it for something different, you’re swimming upstream, and may be signing yourself up for a world of hurt.

One thought on “Affordance and the API

  1. Arpit July 24, 2004 / 1:14 pm

    hey jon… its true how we fall for marketing blizzards, and actually make software work on those lines… creating affordance, while people can b more creative while using it otherwise.

Comments are closed.