Category: microformats

On Modules and Widgets

I got a couple comments on yesterday’s post about ModuleT and widgets. I don’t post often (another vote against splitting my personal blog, I guess), but all the details about AIM Pages, our microformat or other thoughts on widgets will be over on the Alpha Blog. That’s where Joe, Shawn and I talk about module stuff. We’ve been so busy lately that we haven’t posted as much as we should, but there’s a lot to talk about, so keep your eyes peeled for news.

Microformats for APIs

There was a fun discussion at Mashup Camp about Microformats for APIs. It started as a question about using microformats for documenting APIs, which I think was resolved fairly quickly by deciding to try it using XMDP. There’s a short example on the wiki now that I came up with. It’s not complete and doesn’t contain eveything I think should be in it (error codes, response format, etc), but its a start. (Christine Herron posted some notes as well)\
The discussion turned into a plea (from me) to start thinking about using microformats instead of coming up with new XML languages for APIs. There are already competing formats that replicate, in entirely new markup, structures available in HTML. Why not just use XHTML?\
For example, instead of the various formats returned by the different search engines (and I’ve used several by now), why not return this (inside an XHTML document)?

<code>
<ol start="1">
<li><a href="http://url">Document Title</a>
<p class="description">Description goes here</p>
<blockquote>Snippet goes here</blockquote>
</li>
</ol>
</code>

You could, of course, add more, but that’s basically what you get back in any search API. Why does it need to be any more complicated than that? For sites who want something simple, they wouldn’t even need to parse the result, just display it. They could even use javascript on the client side once it’s displayed to come up with the proper next/previous links.\
I think there’s a lot of room for discussion here, and I don’t think that we can reasonably replace all XML-based APIs with microformatted XHTML, but it’s a discussion worth having.

My Favorite AIM Pages Feature

Since it launched yesterday, I can talk about it now. With the whole microformat thing, we’ve started thinking about the pages created in AIM Pages as mini web services, and the first step to doing really cool things with that is being able to pull out modules from the page so you can use them in other modules. You don’t want to have to grab the whole page just to get a piece, so today, you can request a particular module on the page and get back an XML document that contains just that piece. You could also request it with all the scripts it needs to run so you could embed your Buddy Gallery on your own web page if you wanted.\
How do you do it? If you wanted to get my buddy gallery, you’d grab:

<code>http://www.aimpages.com/kplawver/profile.html?moduleid=buddy-gallery-0</code>

If you wanted to get it with all its scripts and CSS, you’d grab:

<code>http://www.aimpages.com/kplawver/profile.html?moduleid=buddy-gallery-0&aspage</code>

Now, this opens up all kinds of possibilities for new modules that I can’t wait to start playing with. I hope you’ll beat me to it…\
update: There are a couple “quirks” with it at the moment. When you use aspage, the module’s onload isn’t being called, and there’s a lonely little double-quote in the body element. Not sure what’s up, but we’ll get it fixed. Getting just the module’s markup works fine (which is really the important bit, right?).

Presenting to The Webfather

I just did my first presentation at WWW on our microformat, and who was in the audience, but Tim Berners-Lee, the father of the web. There was a moment, sitting at the front of the room, waiting for my turn to present, that I got really nervous. I’m not normally nervous before I speak in front of a fairly small group (less than 100). This time, I was. I had a thirty minute presentation that I had to compress into 10, which didn’t help.\
I think Friday’s will be easier. I get to talk about CSS, on stage with two people I know fairly well, and I have my full time. If you’re at the conference, Friday’s Style and Layout panel should be a lot of fun. I get to talk about the guidelines we set up for CSS in modules and themes in AIM Pages, and how that process has worked out for us so far.

WWW2006 and Me

I’m headin’ to Scotland tomorrow for WWW2006, where I’ll be presenting twice:

AIM Pages

We’ve launched!! Hooray!! You can go check it out for yourself over here. If you want to create a profile, you can do that too. All you need is an AIM screen name (and who doesn’t have one of those?) to get started.\
This project has been more fun than anything else I’ve done in my \~11 years at AOL. It was full of huge technical challenges, was a great place for us to try out new things, and the team was probably the best I’ve ever worked with. From product management to QA to Operations and the rest of the developers, everyone pitched in, went the extra mile, pushed themselves to find the best (or at least the one that worked) solution, and kept a good sense of humor about it all.\
I started on this thing as a “consultant” and wasn’t supposed to write any code. I ended up:

  • joining the team responsible for it
  • writing a site’s worth of documentation
  • creating a microformat
  • coming up with a set of rules for writing CSS to accomodate modules, themes and user styles
  • writing almost a dozen modules (only some of which are actually live)
  • helping with dozens more, writing a bunch of themes, and making sure that over 60 themes were ready for launch.
  • spent late nights and weekends at the office debugging javascript
  • worked on convincing developers, management and design that web standards are the way to go
  • and discovered several one-line crashers for Internet Explorer (and one or two ways to make Firefox REALLY unhappy as well).\
    It’s not done, not by a long shot. There are still dozens of bugs and hundreds of features still to come. But, it’s a start. It’s all kinds of fun, not just for end users, but for developers too. One of my “secret” goals at the beginning of this project was to make module development easy enough that even “normals” could do it. And just this morning, sitting around a big conference table, there were three product managers talking about their modules. And my other secret goals? Here they are:
  • Get more people to learn the “right” way to write CSS.
  • Help microformats go mainstream.
  • Show the outside world that AOL can do innovative stuff, and that we support Open Source (we’re using the hell out of Dojo).
  • Show the outside world, and the internal development community, that using web standards don’t limit you. They help you. Creating modules for our product is so much easier than creating them for live.com, dashboard or Google Homepage. Why? Because microformats are “just” HTML.\
    There you go. Go play. And while you’re at it, check out my profile.\
    Oh, and for all you Digg folks, I Am Alpha is not AIM Pages.

Microformats a Go-Go

One day last week while the boys were watching TV, I decided to finally get this here blog up-to-date with microformats, especially since I’m all for them and keep telling people to use them. Might as well take my own medicine, right?\
As of sometime last week, the front page has three separate hAtom feeds and each entry has an hCard on it. I’ve been trying to find time to redo my resume (no, I’m not looking, this is just an excuse to use hResume), but haven’t had time (working nights and weekends will do that to you, along with the fact that I really need a haircut).\
I didn’t have time to remove the classes I had on there before and change the CSS, so the source looks a little cluttered, and nothing’s been done to the archives. I just didn’t have time (running theme, I know).\
If you see anything wrong, please let me know so I can fix it.