microformats – Page 6

A combined view of the world

In a post titled “The new Combined View and hybrid web/desktop apps“, Brent Simmons reveals that’s he’s starting to see the power of AJAX-powered interfaces in Mac apps, namely NetNewsWire (beta 3.0b7 now available).

Going one step further, he makes a very important observation:

The key to the whole thing is JavaScript. When something happens in the page—you click on a news item, for instance—the page calls back into the app, and the app tells the page how to update.

It’s kind of like Ajax in that way, except that the communication channel is not http and it’s synchronous (which it can be, since it’s right there on your machine).

And in that, he’s beginning to pull away at what very likely will become the next generation platform of the next revolution in web development.

For some time, people have gone on and on about the LAMP stack — made up of Linux, Apache, MySQL and PHP. It’s certainly a veritable and productive bundle of technology — if you’re always online. The truth of the matter, however, is that our local content stores don’t sync well with the remote stores… that my local LAMP don’t talk much with remote LAMPs. And in terms of offline productivity, that makes for huge dilemmas.

I’m seeing a third generation stack emerging that holds a great deal of promise for sewing up the future of offline-sync-online experiences.

That stack looks a bit more like Rails, SQL Lite (which the next rev of the Firefox bookmarks will be based on), Microformats, some blend of JSON/AMASS/jQuery/behaviour.js/scriptaculous/prototype and, yes, WebKit. What do they have in common? Well, enough inter-woven stickiness to make the heart of a true web geek start to murmur.

The missing link? The client and server OS component to tie them all together. Now, I’d love to see hAtom used as the data transport and storage mechanism in the OS. It would simply so much… but alas, it looks like RSS is the chosen son in the near term.

Why do I say that I wish hAtom were used for this purpose? Well, consider this. The language of the web is, for whatever you make it, HTML (and lately XHTML). This means that any webpage you visit, and indeed, any feed that you suck up, probably has some of this markup in it. In fact, rendering engines are getting better at both supporting web standards and as well as enabling some crazy cool things that you might not have thought possible before. All the while, XHTML is becoming the modern day ZIP format, able to store rich media as well as metadata about that data in microformats.

The browser is also constantly caching this data for you, in order to load sites faster and faster.

Now think about that: where are you doing most of your work in any given web app? Not surprisingly — in the browser! So you’ve got this cached version sitting on your harddrive with all the JavaScript, all the XHTML source, all the graphics and all the CSS, but nowhere to stick the data should you re-instantiate or open that page from the cache. Which is kind of ironic, since AJAX is all about asynchronous messaging… that is, sending messages non-immediately.

So, the thinking here is… if we’ve got this new “stack” at our disposal, it’s only a matter of time before we rewire our web apps to learn to write to a local SQL Lite store, using Rails as the delivery system, meanwhile storing the views and interactivity later, like Brent has done, in XHTML, CSS and JavaScript. In fact, most of the entire stack will end up as strictly JavaScript and XHTML storage unites once we see some diversification in microformat schemas. There’s no reason why you couldn’t save your bookmarks, your emails, your blog posts, your IM conversations, your documents, your financial records and the whole lots of content that means something to you in simple, basic, readable-everywhere, XHTML.

And so I appreciate, very much, that Brent is starting to see this — and the power that might be found therein — not just for him or for his app, but for anyone for whom the web and its online-offline machinations has caused great consternation. An XHTML-driven world, though potentially messy at first, offers a great deal of flexibility, of efficiency and of reuse and cross-polination.

If only I could get Brent to use hAtom… and if only I could get Microsoft and Apple to support hAtom in the OS like they all do for RSS… We’d begin to bear witness to the promise of this so-called “semantic web”.

WordPress makes a move towards hAtom, gets upgrades

I missed WordCamp this weekend (owing to the fact that I was presenting at Wikimania) but there seems to have been some good announcements that came out of the event.

For one thing, the hosted WordPress service added a few features, one of which is a $15 premier service that lets you edit your CSS. Blogger offers this service for free, but heck, WordPress is still independent and needs to have a way to bring in some dough — and as this is a highly desirable feature, will probably lead to income for the Automattic folks at least a fraction of what Cyworld is pulling in with all their custom digital paraphernalia and trinkets.

So but that’s not all… no, Andy Skelton announced (from what I hear) the availability of a new skeleton theme called Sandbox that is designed for themers. If you’re on WordPress.com you can go enable it now, as I have (it’s totally basic, so I imagine that you’ll see a lot of styles start to appear for it) or download it to put on your own blog.

I’ll actually be doing this once I return to San Francisco.

Why?

Simple: Sandbox is the first known theme to support hAtom.

Why does this matter?

The same reason why hResume matters. And then some. It’s because it not only puts more of the power of publishing into the author’s hands, but it also removes the need to RSS or ATOM.

Let me say that again: because the Sandbox theme is marked up with hAtom in its HTML, there’s no need to supply an alternative link to RSS or ATOM because the page itself is able to be read by newsreaders.

Or, will be. In the meantime, we can use Chris Casciano‘s script for NetNewWire to allow client-side subscribing or server-side transforms to convert any page into a subscribable document.

The potential here is immense — if Matt’s able to move the entirety of the WordPress.com theme base over to hAtom, we’d have quite the playground for an HTML-based syndication format, removing the overhead of generating RSS or ATOM feeds. Instead, you’d subscribe to a website and its content, not some anti-DRY format.

Update: Bill Humphries has released a version of Kubrick that supports hAtom.

Chris Casciano’s microformats hacks

In case you haven’t been watching, Chris Casciano has been pushing in some potential…ful directions lately (“potent” just seems wrong in this context) with microformats. First he releases a script to extract microformats in NetNewsWire then he creates a tool for subscribing to hAtom feeds (which basically allow you to subscribe to an properly marked up HTML document instead of nasty-looking RSS).

On top of that, he pushing the envelope for microformats support in Camino. Not too shabby.

Keep track of this stuff in my Microformats Ma.gnolia group.

Backpack gets a calendar

In case you hadn’t seen it (which I assume you have), Backpack now sports a shiny new calendar for organizing your life. Available for pay accounts only (it’s a measly $5 bucks for a basic account), the reviews seem pretty positive so far, even though I haven’t tried it yet. Personally if it’s less heavy and AJAX’d than Google’s implementation, I might be suaded to dish out some moola.

I mean, with Hiker on its way and voicemail for Backpack pages, why wouldn’t I try it?

Well… (and I respectfully disagree with Jason that iCal export is sufficient) hCalendar and hCard support would be a pretty sweet addition. But, as he correctly points out, I’m not really his target audience. Phooey. It’s such a drag when folks are adament about not doing what the early adopters demand. It’s like they have, I dunno, backbone or something.

hResume plugin now available

Alex Muse et al have announced the availability of the hResume plugin for WordPress. This plugin will essentially allow you to publish your resume on your own blog using semantic microformatted content so that search engines (like Technorati and eventually other sites like Emurse) can index and offer your resume as a result.

Why is this better than going to Monster.com and others? Well, for one thing, you’re always in charge of your data, so instead of having to fill out forms on 40,000 different sites, you maintain your resume on your site and you update it once and then ping others to let them know that you’ve updated your resume. And, when people discover your resume, they come to you in a context that represents you and lets you stand out rather than blending into a sea of homogeneous-looking documents.

Finally, you’re free to share as much (or as little as you like) and if the data doesn’t fit in their predefined templates, you’ve got nothing to worry about because you’re in total control of your employed (or unemployed) destiny!

On the flip side, Emurse already outputs hResume so if you do want to use an external service to publish your resume (maybe you still don’t have a blog… heh) you feel free to do so. And yeah, it’ll look pretty darn good too.

Picoformats: microformats for mobile

Andrew Turner pinged me about a project I started up as an offshoot to my work with Mozes called Picoformats. He wrote that a picoformat is a standard-means for defining markup in small, probably mobile, devices.

That’s not exactly the original idea, but it actually makes a lot of sense and, the more that Tara and I use our Blackberries, the more we see a need for standard micro-interfaces. Sure it’s great that you can download my hcard into your address book from your regular web browser, but the same seems not to hold true on mobile devices.

Anyway, that’s an issue that needs to be addressed in mobile browsers, and Opera‘s well on their way working on such problems.

Andrew’s post did highlight both the need for me to get the word out about this project and also explain it a little more clearly since Microformats could actually address the formating of data for mobile devices (especially when we start pairing up microformatted content with relevant media-specific CSS).

The goal of the Picoformats project is to use an open process that reflects existing behavior and come up with standards for an SMS-based dialect for interacting with mobile services.

Dodgeball already has a pretty good SMS/email dialect. In fact, I use it all the time. What I want is service interoperability, so that when I send a message to (okay, I’ll reveal my bias) Mozes, I can use the same syntax to compose the command or message. For example, if I send a message formed like this: “! heading to the movies at 10pm”, it shouldn’t matter if I’m on Dodgeball, Facebook Mobile, MySpace Mobile, or FactoryCity Mobile — each service that supports Picoformats should send out the blast message to my friends, just as I’d expect it to. But already there’s divergence — with Mozes using “@” for blast messages and Dodgeball using “!”. This is the kind of thing that will make it extremely hard for people to move between services or, worse yet, use a multitude of services.

You can probably begin to see how this is similar to life before Adium or Trillian. Personally, I like not having to run 5 different instant messenger apps. I like having them all in one and being able to IM my friends regardless of the service they’re on from one interface. I’d like to be able to do the same with the mobile services I use. And that’s why this Picoformats idea is important — it’s syntactic interoperability.

AIMPages seems to be getting things right…

So from using open-source AJAX library DojoToolkit to creating and implementing the widget microformat, they seem to be doing some things right — of course my profile looks like arse, but the possibility for greatness persists.

Event In a Suitcase and Running Remote S5 Presentations

Continuing the tradition of the “Event in a…” meme, we came up with the notion of “Event in a Suitcase” at the most recent Mash Pit.

The idea is pretty simple: make it easy to walk into a room and make a presentation.

Well, among the five of us, we came to the conclusion that there’s nothing really that makes it easy. There are tools, both hardware and software, that make it possible, and writing them down was a good place to start from. But there really isn’t an open source or free workflow that gets us where we want to be… where everything is affordable and fits in a literal suitcase.

So anyway, we documented our work and could use more help. If you’ve got ideas, tools, solutions, workflows or whatever, add them!

· · ·

So, one of the cool hacks that we brainstormed and that Kevin Marks was actually able to implement before the day was out involved Eric Meyer’s public domain slideshow format S5. Essentially he made it possible for people watching an S5 presentation, like Tantek’s excellent Building Blocks for Independent, to see the slides change as the presenter changes them.

Of course bringing this awesome hack together with a Gizmo call-in means that people can at least watch and listen remotely as presentation happens — and participate in IRC. So voila, it’s like NetMeeting, but open source! Anyway, Kevin’s code is in Twisted and now that I’ve blogged this, hopefully he’ll be incented to clean it up and publish it!

ClaimID makes the OpenID connection

I have to say that it’s things like this that really make me shiver with excitement…

I mean, it’s pretty simple, but it’s also pretty important.

What’s the big deal? Well, for one thing, it’s yet another site adopting OpenID, a decentralized identity system. And, as more and more sites adopt this system (which should remain transparent to end-users if they don’t want an OpenID), we near ever-closer to a lightweight, single sign-on solution.

To be sure, OpenID isn’t a panacea. It’s not intended to be one. The primary attractiveness of OpenID is its simplicity: it’s decoupled the issue of trust from identity and simply offers a way of staking your identity to a given URL. In a sense, if you can trust the credentials of Website X, then you (as a web service provider) can trust accounts created on that domain as well. The benefit for the account holder is that they don’t have to re-register on Website Y.

Note that this is a web-centric solution and doesn’t carry well into the real world where people don’t identify themselves by URLs (hmm, what if instead of a social security number, we were assigned a URL at birth? whoa.).

The other thing that’s great about this announcement is that it’s the work of Scott Kveton’s new startup, JanRain. I brought Scott and Terrell Russell together some time ago, so it’s awesome to see the fruits of this connection already — and that Scott’s going off to do this kind of work full-time.

What I want to see? Well, the proliferation of OpenID across all the various sites that I use. The cost is minimal since the libraries are being developed on all kinds of platforms — and it should integrate fairly well with existing login schemes. Then I want to see either Ma.gnolia or ClaimID add support for XFN (they already support hCards and ClaimID allows for custom rel values). Then, of course, we need to be able to string together (loosely coupled, mind you) my contact list and my group membership list so that I can import and export them wherever I go (obviously this should be done with microformats). Once we’ve got that situation fleshed out, and I’ve claimed my sites with either MicroID or (preferrably) rel=me, I’ll have a pretty portable social network to carry around the web!

Yahoo! Local goes Cuckoo for CoCo Puffs!

The title means nothing, but today at Supernova, Andy Baio announced that Yahoo! Local has added support across the board for hCard, hCalendar and hReview, following Flickr, Upcoming and Yahoo! Tech (blurry video 1, video 2 — turn it up!).

I can’t exactly say what adding 10s of millions of microformatted bits of data will do for the web, but it certainly makes the rush to develop UI around this new opportunity all the greater…

Oh, and bonus: when I was at Flock, I wanted to see ground-level integration of microformats in the browser. Imagine having Lucene indexing all the microformatted content that you come across on the web (whether you know it or not) and then having that data separated out for use in extensions, in filling out forms, in generating new cross-sections and views of your ‘history’. And Rohit gave me another side of that idea: being able to autofill forms anywhere by creating an index of microformat classes-to-input value pairs for specific websites… Yeah, the client/browser part is going to be key to making all this work have obvious value for folks on the web. Can’t wait to see how this moves forward.