I’ve had a tab open in my browser pointing at Tom’s "Native to a Web of Data"
slide for a few days now. It’s been nagging me. I needed to do
something with the ideas encapsulated in that one slide, and tonight it
struck me while I was doing something completely unrelated.

Though I wasn’t at his presentation and haven’t talked with Tom
about this, I’ve decided to annotate (some may say "translate") them
for the benefit of the typical MBA laden, non-engineering focused
Product Manager that you might find at a large Internet company… or
anyone else who cares, really. 🙂

Look to add value to the Aggregate Web of data

As a company with infrastructure that can scale to scan, retrieve,
and analyze a significant portion of all the public on-line information
in the world, think about how you can use those capabilities to improve
the world. What can you do that someone looking at a much smaller set
of the data cannot? What patterns can be found? What connections can be
made? What can you simplify for people?

Build for normal users, developers, and machines

Make whatever you build easy to use, easy to hack, and make it emit
useful data in a structured form. That means you need a usability geek,
an API geek, and probably an XML/RSS/JSON geek.

Start designing with data, not pages

Figure out what data is important, how it will be stored,
represented, and transferred. Think about the generic services that one
can build on top of that repository. Only then should you get the
wireframe geeks and/or the photshop geeks involved.

This is scary, because you won’t have a mock-up right away. Your
PowerPoint presentations will look as if they’re missing something. But
that’s okay. This is about doing some engineering style design before
product design and interface mocks.

Identify your first order objects and make them addressable

Figure out what your service is fundamentally about. If it’s a
social shopping application, you’re probably dealing with people,
items, and lists of items. Nail those before going farther. And make
sure there’s a way to access each object type from the outside world.
That means there’s a URL for fetching information about an item, a
list, etc.

These are the building blocks that you’ll use to make more complex things later on. Hopefully others will too.

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

You are building a platform, whether you believe it or not.

Build list views and batch manipulation interfaces

Make it easy to see all items of a given type and make it possible
to edit them as a group. Flickr does this when you upload a batch of
photos. Search, in its many forms, is the classic example of a "list

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.

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.

By Jeremy Zawodny