Building a better mouse trap

Mousetrap

I’m struggling to make sense of something here. In Blogger’s announcement about its new beta was an interesting tidbit that didn’t get much pickup: Blogger now has a Google Data API.

There’s a lot that I could say about this, and my initial reaction was actually wrong. It seemed to me that Google was going off and inventing its own blog-publishing protocol, pulling the same crap that it did with its non-standard Event Publisher API (using random values that don’t map directly to the international icalendar standard.

But, no, it turns out that GData is actually just Atom “plus some extensions for handling queries”, but branded as a proprietary Google format (kind of ironic, given the long and pained open development of Atom).

So whatever, Atom is what comes next after RSS and MetaWeblog (in particular as ).

The important thing that started to dawn on me was this part of the announcement:

So just as Yahoo had done with Flickr (inspiring a fairly wide backlash), Blogger is going to be fully absorbed into the Google Auth-borg. This continued amalgamation of services behind the Google Account Authentication has consequences beyond the momentary outcry over Google’s supposed steamrolling of companies.

Business is business and competition is a threat to any member of an ecosystem, which is why you’ve got to keep innovating, adapting and bettering to survive. But it’s different when it comes to setting protocols and standards and the seamless moving of data in and out of disparate systems. When those protocols are closed or locked up or can be sealed off at any time, the competitive environment becomes very different.

The problem that I see is Google’s ability to shut out third party services once you’ve imported yourself into the proverbial gLife. No doubt there are feeds and the aforementioned GData APIs but it’s not an open system; Google decides which ports it wants to open and for whom. Think you’ll ever be able to cross-post calendar items from to your Google Calendar? Only if Narendra strikes a deal on your behalf — even though it’s your data. Think you’ll ever be able to share your Picasa Albums with your Flickr account? Don’t bet on it. Or — or — how about sharing your Google search history with your Yahoo account? Or merging your buddy list between Orkut and Flickr? Not a chance.

In simplest terms, with the state we’re in with centralized authentication in web applications, it’s like waiting for Microsoft and Apple to strike a deal enabling you to copy and paste from Appleworks to Word. And on top of that, you’d need to have to had created an account in both apps to even boot them up. So from a “normal person perspective”, this is a situation that you’d never want to have to worry about.

But that’s essentially where we’re at.

To put it in greater perspective: Web2.0 should have been the “great wide opening” — that is, where you could be in utter control of your data and move it in and out of services at your whim, just as you can with your money, in and out of banks depending on the quality and diversity of services they offer. And indeed, they’ve got to compete just to keep your business — if you leave, you won’t be stuck with a bunch of expiring pre-loaded debit cards.

But there’s a new trend, seen in Google’s spreading account authentication that foretells of the inevitable Passport-like lock-in that sunk Microsoft the first go ’round. You see, Google’s Account Authentication API makes it easy for you to add more and more of Google services by simply using your Gmail credentials. For Google, this leads to huge network effects, because they can essentially merge behavior data from across its entire network of services to build out a better picture of you — leading to a kind of competitive advantage that no one else can touch.

The problem though, both for you and for independent developers, is that you can’t pick and choose who or what Google works with. They’ll make themselves just open enough to be above reproach but not quite open enough to allow third parties to compete with them on their home turf (man, it’d be nice if there were a “Reply by Skype” link in Gmail — oops, Gtalk only!).

And this is how Google will build a better user mousetrap by leveraging its superior cross-product integration that its authentication system affords them.

(Aside: 37Signals partially benefits from the same kind of integration in typing Writeboards into Backpack but could go further by sharing accounts between different Basecamps).

Designing the Business Card 2.0

openBC's open DESIGN contest

In case you missed it (I know I did), a friend from abroad pinged me about the openBC openDESIGN contest — basically an opportunity to design the Business Card 2.0. (Haven’t heard of openBC? You should!).

They’re looking to drum up interest over in the states, so I figured I’d pass the word along. Heck if you win, it’s pretty good money, so I don’t mind doing a little PSA.

What’s in it for you? Well, according to the contest challenge page, you’ll:

  • Get your design talent featured on a high-traffic site and generate awareness for your microbrand
  • Have your work judged by jury made up of prominent experts
  • Receive a contract to work together with a prestigious and global client to integrate your ideas
  • Win 12 months’ free premium membership if you are voted a weekly winner
  • Be in with a chance of winning €10,000 up front if you produce the winning design concept
  • The winners name will be featured on over 1.5 million profile pages for the first 3 months

Sounds good, eh? What’s in it for me? Well, in exchange for pimpage, there’s a good chance they’ll be doing up their new profile pages in and (now to keep them to their part of the deal… heh.)

Now, the site redesigners have been keeping a log of their efforts across the whole site, almost like watching the Tour de France of web design (getting quite contentious at times). Things are nearing the last leg though, with only a week to go before the contest is up… So, if you want your shot at €10,000, get your entries in ASAP. Veloso, Stamatiou and you 9rules folks — I’m lookin’ at you!

Could AppleScript be the next scripting language of the web?

I’d never thought about it, but man!, wouldn’t it be amazing if you could use all the Mac developer gooodies to develop any website? XCode for web apps? AppleScript instead of JavaScript? WebKit on Rails?

I mean, by all accounts, AppleScript is much more readable and human friendly than JavaScript… I wonder if it would it be possible to abstract JavaScript to a point where I could write something as simple as this (which is AppleScript syntax)?


tell application "MarsEdit"
	activate
	make new post window
	tell post window 1
		set title to "[[pageTitle]]"
		set link to "[[pageURL]]"
		set body to "[[bodyText]]"
	end tell
end tell

Imagine this, just for example, running in any webapp:


tell webapp "30boxes"
	activate
	make new vcalendar event
	tell post vcalendar event 1
		set title to "[[eventTitle]]"
		set link to "[[eventURL]]"
		set body to "[[bodyText]]"
	end tell
end tell

Ok, so again, I’m not much of a codesmith, but that seems pretty simple, even for me.

A combined view of the world

NetNewsWire + Shiira Tabs

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

Safari on Windows

Safari on WIndows

With nary a peep from the XUL Runner folks on the recent proliferation of WebKit apps, I was going to say, “Man, Firefox is so effed” but I shouldn’t say that without backing it up. And being more specific and saying “Man, Gecko is so effed” isn’t all that helpful either. And anyway, I wouldn’t be entirely correct, since really what I mean is that “the collective Gecko and Firefox community seems to be taking a long time shipping a widgetizeable and stand-alone platform for running web applications as desktop applications compared with the WebKit community”.

But anyway, in the meantime, WebKit (whose party I attended last night) is steaming right along. Especially now that you can run Safari on the PC things are going to get very interesting in the rendering engine space very quickly.

Can we get a Linux port already?

WordPress makes a move towards hAtom, gets upgrades

WordPress login

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.

Email isn’t dead

activate us

With cultureware services like Flavorpill launching a new email newsletter called Activate (“World News Once a Week”subscribe) and Amit Gupta and co‘s PhotoJojo pulling in over 10K subscribers (4K via RSS) and getting Wall Street Journal ink, email newsletters are far from dead.

Just put that one away in your quiver next time some tries to suggest that email’s dead (I’ll have more on this later).

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.