Fresh college grad turned management consultant. I come from a background in economics and computer science. I blog in my spare time about 3 major themes:

Strategy & structure
Technology & design
Telecom & media

I believe there is no such thing as an interesting fact; there are only interesting ideas. In every entry I try to introduce at least one idea, and will never report just plain news.

Keep in mind that the content here is unrelated to my profession. I invite you to read with an open mind and definitely to challenge the thinking!

FriendFeed

Classic bookmarks

Blog archives

Thoughtful
» Paul Graham
» Tim O’Reilly
» Andrew Chen

Friends
» DB
» Grex
» Dodeca
» John Guari

Just for fun
» Spill
» Yelp!
» not cot
» Freshome
» Dance Jam
» Savage Love
» Overheard in NY

Apr'08

Standardizing more than just the webpage

Every page has a <html> <head> and <body>. We all expect <H#> to indicate headings, that <b> or <strong> means bold but no one should be using <bold>, that Javascript should live inside a <script>. This is what standardized HTML is all about and allows every computer on every OS, every browser to experience the same web page (albeit, not always the same way).

We’ve standardized how a page should be built, it’s time to extend that level of standardization to other elements on the Web.

Pages are the atom, but we need elements, and a periodic table

The web used to be a bunch of pages. A page is a chunk of free-form content from which you could expect anything. But now, a lot of pages are starting to look awfully similar. We’ve advanced beyond pages—when we browse content, we tell our selves “This is a profile, this is a blog entry, this is a video, this is a playlist.” Our awareness of content type ties to a set of expectations about what properties and structure to expect. A profile should have a picture, a name, lists a couple interests. A blog posts a date and a body, title and comment-list optional. In our heads, we’ve evolved a set of schemas for each content-type we frequently use. However, web applications still serves content largely in schema-less HTML…which one would find odd considering that the data-backend is quite rigidly structured:

Backend Data

Relational database
Rigidly structured

→

Content output

HTML
Completely unstructured

→

User conception

Content elements
Moderately structured

We already conceptualize web content as different element types, not just a dumb network inter-linked pages, now we need to make the underlying technology reflect this concept.

We’re in the dark ages of data portability

Have you seen FriendFeed? It’s quite amazing, but it only handles content from a handful of sources. Want more? The developers will need to adapt new sources manually, because there are no standard data formats for most of the items that FriendFeed is trying to aggregate.

Imagine if regular web pages were in an analogous situation. It would mean that:

Different web servers use different markup languages
Different content providers require access via their own browser

And if I extended this analogy to mobile internet:

Different content requires different browser, OS, and even hardware in order to access it

That’s the depressing state of data formats today: portability extends beyond a user rights or EULA issue because we haven’t even matured the technical capability to execute.

Surely you must be talking about microformats

Microformats are super-cool. While they’re often mentioned in tandem with the semantic web, I think the first-line impact is in data portability. But I wonder if there’s a way to crank these out faster than depending on a single standards organization. There’s been niche success in describing people and events (hCard, hCalendar) but damn…shits gotta get cranking.

Permalink