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.

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.

Post navigation

4 thoughts on “Native To Web & The Future Of Web Apps”

Well, to be fair… MARC/MODS and SRU aren’t really reinventing the wheel. Amazon reinvented the wheel (regardless of whether or not they were more successful at it). All of those technologies existed before their AWS counterpart.

However, point #5 is much more difficult than just /item/isbn/1234567890x in most real world scenarios.

Take articles for instance. Yes, some may have standard identifiers (dois, pmids, etc.), but many, many do not. And the doi isn’t even that friendly, anyway.

As I struggle to make a link resolver that “works better”, I’m still finding it nigh-on-impossible to improve on the readability of the openurl (and still actually be able to resolve anything).

I’m not sure #5 is ultimately all that important (although, yes, containing all of the information in a hash or behind session identifiers is wrong — and maybe what you’re actually getting at).

I’m not sure how I feel about being typecast as the anti-SRU guy, but your points are valid.

I’ll quickly agree that the challenge of making openurl readable is probably insoluble, but let’s at least make the URLs in our apps durable enough to be bookmarkable, blogable, IMable, emailable, and indexable (so it’s Googleable(?)).

Now back to “standards…” The’ slides are good, but they don’t speak to your first point about priority and reinvention. What Coates couldn’t say, because the decision was made far above his head, was that successful organizations know when to change their game. Yahoo!’s acquisition of so many internet properties (and Coates himself) in the past year shows they know this.

What would we think of Yahoo! if they’d stuck to their old game? Would we respect them for claiming they did internet portals first? Would we care?

We need to think critically about our standards. MARC and SRU and others we love (and love to hate) may have been first, but there are substantially similar standards in broader use outside libraries.