Yahoo’s Tom Coats was of seven star speakers at Carson Workshops‘ Future of Web Apps Summit last month. As usual, Ryan Eby was pretty quick to point out his slides to me, mostly by way of pointing out Jeremy Zawodny’s translation of them.
If it’s not clear yet: I wasn’t there, though I very much wanted to be, especially given some of what can be found in the post-summit blog posts.
Still, there’s a lot to be learned from just this one slide:
- Look to add value to the Aggregate Web of data
- Build for normal users, developers, and machines
- Start designing with data, not pages
- Identify your first order objects and make them addressable
- Use readable, reliable, and hackable URLs
- Correlate with external identifier schemes
- Build list views and batch manipulation interfaces
- Create parallel data services using standards
- Make your data as discoverable as possible
I’ve been making a lot of noise about Coates’ point number five in my own presentations about how to build an OPAC for Web 2.0 (though the lesson should be applied to every library application), but there’s a lot to like in all nine. And it’s a bunch easier to understand his point when you read Zawodny’s take on it.
Here are my favorite bits:
Use readable, reliable, and hackable URLs
If the URL is hard to read over the phone or wraps in email, you’re not there yet. Simplicity and predictability rule here. Consider something like http://socialshopping.com/item/12345. You can guess what that URL does, can’t you?
You may not grasp how important this is, but don’t let that stop you from worry about it. This stuff really does matter. Look at how most URLs in del.icio.us are guessable and simple. Mimic that.
Correlate with external identifier schemes
Don’t go inventing complete new ways to represent and/or structure things if there’s already an established mechanism that’d work. Not only is such effort wasteful, it significantly lowers the chance that others will adopt it and help to strengthen the platform you’re building.
You are building a platform, whether you believe it or not.
Create parallel data services using standards
Developers (and the code they write) will want to consume your data. Do not make this an afterthought. Get your engineers thinking about how they might use the data, and make sure they design the product to support those fantasies. Again, always default to using an existing standard or extending one when necessary. Look at how flexible RSS and Atom are.
Don’t re-invent the wheel [link added –Casey].
Make your data as discoverable as possible
The names and attributes you use should be descriptive to users and developers, not merely a byproduct of the proprietary internal system upon which they’re built. This means thinking like an outsider and doing a bit of extra work.