Quantcast

Tom’s Future of Web Apps, Translated…

Get the WebProNews Newsletter:


[ Technology]

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 building.

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 view.”

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.

Jeremy Zawodny is the author of the popular Jeremy Zawodny’s blog. Jeremy is part of the Yahoo search team and frequently posts in the Yahoo! Search blog as well.

Visit Jeremy’s blog: Jeremy Zawodny’s blog.

Tom’s Future of Web Apps, Translated…
Comments Off
Top Rated White Papers and Resources

Comments are closed.

  • Join for Access to Our Exclusive Web Tools
  • Sidebar Top
  • Sidebar Middle
  • Sign Up For The Free Newsletter
  • Sidebar Bottom