Back into the Future of Web: HTML5 SQL Player

Like a Three Stooges carpet-pull slapstick stunt, the HTML5 client-side storage spec changed drastically the night I released my Gears wrapper. Thump. Ow!

I am ok! I am ok! And better for it! This time, I am back with the vengeance. Why fight the change? Embrace it! Dear reader, allow me to present the HTML5 SQL Player, a tool that spec developers and curious bystanders alike can use to poke and prod the spec in action. Essentially, this is a Google Gears-based sandbox, in which a user can run Javascript code to query and test the interfaces, implemented by the specification. If I were into that kind of thing, there would be a picture of a crazy-eyed Christopher Lloyd and some reference to the movie that doomed his career. Yes, my friends, this sandbox is a glimpse into the yet-to-be-implemented technology.

And as such, beware of the bleeding edge. Some things in the spec are somewhat under… erm… specified (like the mode of transaction and its effect on sequential calls of the transaction method) and some things in the sandbox are under… erm… implemented (like changeVersion or SQL sanitation). But regardless, this approach is still the best if you’re trying to evaluate spec’s viability in an effort to make it better. And that’s what this is all about.

Jumping Off Audience Navigation Bandwagon

Future Endeavor has another insightful post, followed by an interesting UX example of the University of Virginia front door. I am a big fan of this blog and would highly recommend it to anyone involved in higher education Web development. This time, Tony Dunn talks about the future of the University Web site. I like his thinking and I feel that my thinking is mostly aligned with it. Where we diverge is on the future of the audience-based navigation.

The truth is, I no longer believe in the necessity (or usefulness) of the audience-based navigation for a University. There, I said it. Having been the advocate for the last 8 years, I eventually came to realize that all it does is create an extra barrier for the user (umm, who am I? Which is the right door?) and is mostly ignored by the visitors, anyway (I am basing this on my observations and thought experiments).

Self-selection is a myth: as you probably know, the user commonly belongs to multiple or none of the offered audiences, and this artificial ritual of forcing the visitor to put the right hat on is not only confusing, it’s actually a little bit insulting.

What’s the alternative? Concentrate on three things:

  • Needs-based Clusters. Envelop topics, relevant to specific needs (How do I become a student?) into a cohesive (spit-and-polished!) and limited in scope sites.
  • Lifeline Links. Identify 3-5 most desperate and immediate needs of your visitor (I have to check my grades) and by golly, put them on the home page.
  • Ambient Findability. Make sure that each page on your site carries a potential of getting the user closer to achieving their goals.

That’s all for now. I am eager to hear your thoughts and opinions on my little turn-about.

Chewing on Open Social

So, the cat is out of the bag, in case you haven’t heard (and if you haven’t, what remote island are you living on?). I spent a bit of time this weekend, playing with the new toys, trying to analyze by immersion. Essentially, on the Javascript side, it’s one part existing Gadget API, one part new feature (you guessed it, named opensocial), and you’ve got yourself a whole new playing field to tinker with. Not being familiar with the Gadget API, I was learning both parts at the same time, which is never a bad thing.

After getting my sandbox permit, I hastily cooked up two simple gadgets, er.. social applications, the Twitter and the OpenZombie. Both of these are skeletal proofs-of-concept, on whose I have no intention to continue development. So, feel free to borrow in parts or in whole — it’s public domain, baby! I intentionally tried to keep them light-weight, client-side-only. Both have been casually tested with Firefox and IE7. In other words, don’t call me if you have a problem running either.

First application grabs data from Twitter using Gadget API calls and renders it to somewhat resemble a Twitter feed. It doesn’t actually use any of the OpenSocial API functionality and can be run in the iGoogle. It does use the UserPrefs to ask for the Twitter username, and Orkut’s current way of dealing with this is rather jarring, so be prepared for that.

Second one is my 45-minute take on the ever-ridiculous Zombies application on Facebook. Except this one actually bites automatically. As soon as the user stumbles upon my profile page, they are bitten by the OpenZombie application (with the corresponding activity stream message), and offered to install the application themselves as a vengeance-laden consolation prize. No stats are kept (and that would be hard, given that API doesn’t yet allow you to update owner’s person data), and no blood-curdling imagery is displayed. I figured, the next guy will come along and make it pretty. And by pretty I mean despicably horrific.

Speaking of the next guy, here are a couple of tips that I have for you:

  • When debugging the application, appending &bpc=1 to the URL of the page itself will disable caching of the application. Someone already built a Greasemonkey script for that.
  • Modularize your development. Make your application a harness that calls scripts and styles remotely:
  • <Module>
    	<ModulePrefs [attributes go here]>
    		<Require feature="opensocial-0.5"/>
                    [more feature requirements go here]
            [user prefs, etc. go here]
    	<Content type="html">
    		<script type='text/javascript'
    			src='[absolute script url]'></script>
    			@import url('[absolute style url');
    		<div id="message"></div>
    		<div id="panel"></div>

    Then, in your script, do something like this:

    _IG_RegisterOnloadHandler(function() {
            // your code goes here
  • Once you have modularized your application, you can do another simple trick: edit your hosts file to temporarily point the hostname in the script and style URLs to localhost. Then make sure that these files are accessible from your local web server. Now you can edit them and see the changes without having to push the files to the server on which the application will eventually be hosted. Just don’t forget to remove the edits in the hosts file when you’re done developing.

Now, for a quick technology review of the OpenSocial Javascript API (can’t speak for the GData stuff, haven’t played with it). On the contrary to the few negative reactions in the blogosphere, I find OpenSocial pretty impressive. I think the API is easy to learn and follow, the transparent authentication and identity data management model is neat, and there’s plenty of room to play, or even build something useful. Bringing application development into the Javascript domain is a good thing. Yeah, the sandbox squeaks and rattles, but that’s typical for an early release. Give it a little time.

The API itself is wordy and a bit inelegant, though this may be a viewpoint,
skewed by the laconic beauty of JQuery. I am guessing that its current shape is probably a result of being tailored toward the more arcane Javascript
implementations. I can’t find any other explanation for the gratuitous global
namespace pollution or things like API objects having accessible underscored methods/fields.

But my biggest beef is with the Gadget API. With it’s let’s start now, it’s so simple! approach, it practically encourages hacky, spaghetti-style Web development. Adding even a primitive asset management to the XML declaration would be a win-win: developers are nudged to separate behavior, presentation, and markup, and the server gets to know in advance what’s needed to render a gadget, thus providing opportunities for caching, embedding, or aggregating the assets:

    <Asset Type="js" Src="" />
    <Asset Type="css"  Src="" />

Another thing that stood out is the lack of user experience management. Facebook went a long way (they invented their own language!) to keep the consistency of the user interface by offering common primitives, like profile action or the freshly baked board. Walking from application to application, you can easily see where the primitives end and developer’s own creative aspirations begin (and believe me, in 8 cases out of 10, it ain’t pretty). But at least they tried. The only thing that Gadget API has in this regard is handling of user preferences. That’s it. The containing IFRAME is essentially an open canvas. This is something that has to be addressed, especially considering that some partners in the alliance are pretty good about keeping their UX noses clean.

I hesitate to draw any sort of conclusions in regard to direction or
viability of the project. Obviously, this is a very early developer’s
preview, where it’s perfectly acceptable to come across matchsticks and
duct tape. As it stands right now, OpenSocial is certainly not as
well-oriented and focused as Facebook, and Orkut doesn’t make a good sandbox
container, because… well, let’s just say it won’t win any usability
awards. And certainly not visual design awards. Even with that, I can
see fairly clearly what Google wants to become: they want to be the social networking plumbing. Just like their search became the the Internet
for many users, I can speculate that Google hopes to offer free,
ubiquitous, and highly mashable pieces of infrastructure that power the
majority of person and community-centric software on the Web. Ultimately, I don’t believe
it’s a move in a game of chess, but a tiny step in the strategy that reaches much
farther and wider than everyone’s favorite blue-shaded time waster.

Slides from my IPSA presentation on HTML5 and Google Gears

Today, at the monthly IPSA meeting, I gave a presentation on Google Gears and HTML5 client-side storage part of the spec. As promised, I uploaded the slides to this blog.

… Yes, I am going slide-less from now on. Jeff Keeton and I have already done a couple of browser tabs-only presentations before, and the simple method works as well or better than the slides.

HTML5 Wrapper for Gears

This is possibly the lowest-hanging fruit ever. After WebKit folks released their implementation of the HTML5 SQL storage specification, Gears immediately became the odd man out, the non-standards-compliant implementation. Never you mind that this part of the spec is still basically a twinkle in Hixie‘s eye. By adding the SQL bit into the latest WebKit nightlies (Windows users are still blissfully unaware of this, by the way), the legendary Apple team put a symbolic stake into the metaphoric ground: this better not be moving anywhere.

So I thought, why not connect the dots? Gears is a capable and much more mature implementation, both WebKit and Gears use the same SQLite server, so it should be just a matter of writing a simple wrapper to bring Gears back into the standards fold.

So here they are, WebKit’s Stickies running in Firefox with Gears, using a tiny bridge script I wrote (see the screenshot on Flickr if you aren’t inclined to install Gears). If you’re running Firefox 3, you may actually be able to write on those stickies. For Firefox 2 users, the lack of contenteditable support means that you can just create, move, and delete the notes. IE users are SOL‘d, because the Stickies sample uses DOM Level 2 events and other happy standards goodies. Do not let this stop you from using the bridge itself, though: it works in IE just peachy-fine.

The script, as I mentioned before, is laughably small and oh yes, incomplete. But I figured, the openDatabase and executeSql support take you about 80% of the way for most Web application development needs, and should the need for the other 20% arise, I would gladly oblige and be your code monkey.

Gearites and Safaritans, if you feel like I encroached on any of your wonderful work by creating this frankenstein, please let me know and we’ll sort this out.

My iPhone SDK

So, my good friend Steve spills the beans about the upcoming SDK. The crowd screams like girls at the Beatles concert. Even ever-curmudgeonly Dave eeks a “hooray”. And that’s a big deal, my reading acquaintance. Now, I don’t own an iPhone, but I play with one at the local store every other week. And I also am a gearhead, as we’ve discussed before. And, I watch google-gears and
WHATWG groups like a hawk whenever there’s talk about gear-related stuff.

With all that, it is only logical to assume that I am siding with Chris on the mournful thoughts for the Web-based application development on the delectable slice of glass-sided aluminum. Because in my opinion, Safari 3 is only five tiny steps away from being a full-fledged application platform.

These steps are:

The “nice-to-haves” and “coming-soons” may include direct TCP Network connections, history and browsing context management, and other neat things from the HTML5 spec, but those first five is what could really make the Web applications first-class. Think about it.

HighEdWebDev 2007

The HighEdWebDev 2007 conference begins tomorrow and I am all ready to go. This is my second year to attend this gathering. Last year, I was sitting at the vendor table (Hello, I would you like to buy a pound of CMS?), guest-blogging at, and that’s about it. This year, I (thankfully!) will not be vending software
goods, but I did sign up for guest-blogging. In addition, Jeff
and I will have a post-conference Workshop 2.0, a boundary-busting, mashpit-flavored jam session of collaborative learning.

We’ll start with breaking down the what’s, the who’s, and the why’s of the gnarly beast we all lovingly call Web 2.0. We’ll talk about the traits and the hype, the comers and the goners, but please pelt us with rotten iPhones if we spend more than 20 minutes doing that.

Next, we’ll conduct an exclusive virtual (hold your fingers crossed for Skype) expert panel, discussing what the future holds in store for the Web of tomorrow. The panel will feature several gurus and senseis of the Web, including our own, battle-tested Mark
and Web 2.0’s uncle Chris FactoryJoe Messina. We tried to get Father Tim, but Twitter was down at the time.

In another 20 minutes, we’ll pull the plug on the Skypecast, claiming technical difficulties, and get to the most exciting part of the shop:
the hands-on. In the remaining 2 hours, we will venture to build a new site. Together. Not to compete with the CSS experts next door, we’ll skip the part of finding fun rendering bugs in IE, but rest assured, we’ll follow the process from start to finish. Please bring
your smocks — this is going to get messy.

Armed with our shockingly brilliant collective intelligence, our Team 2.0 will pick the site project, brainstorm goals, audiences, creative concept, doodle wireframes and even say words like AJAX and Controlled Vocabulary. Together, we’ll argue about pros and cons of promotion techniques, mull over minute details of information architecture, decide on underlying technology and discuss details of implementation while the Photoshop geeks in the corner will
be quietly cooking rounded corners, gradients and drop-shadows.

Throughout, we’ll use social networking tools to facilitate the architecture, development, and promotion of the site, making sure to squeeze the most utility out of the Web 2.0 hype. We probably won’t walk away with a real site. But we sure will try. And in the process, we’ll capture and cherish the spirit of
working together and having a good time.