Dimitri Glazkov

Web and About

Archive for November 2007

Back into the Future of Web: HTML5 SQL Player

with 3 comments

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.

Written by Dimitri Glazkov

November 17, 2007 at 9:48 pm

Posted in Uncategorized

Jumping Off Audience Navigation Bandwagon

leave a comment »

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.

Written by Dimitri Glazkov

November 15, 2007 at 10:12 am

Posted in Uncategorized

Chewing on Open Social

leave a comment »

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]
    	</ModulePrefs>
            [user prefs, etc. go here]
    	<Content type="html">
    	<![CDATA[
    		<script type='text/javascript'
    			src='[absolute script url]'></script>
    		<style>
    			@import url('[absolute style url');
    		</style>
    		<div id="message"></div>
    		<div id="panel"></div>
     	]]>
      </Content>
    </Module>
    

    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:

<Assets>
    <Asset Type="js" Src="http://example.com/twitter.js" />
    <Asset Type="css"  Src="http://example.com/twitter.css" />
...

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.

Written by Dimitri Glazkov

November 4, 2007 at 6:52 pm

Posted in Uncategorized

Slides from my IPSA presentation on HTML5 and Google Gears

with 2 comments

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.

Written by Dimitri Glazkov

November 1, 2007 at 2:43 pm

Posted in Uncategorized

Follow

Get every new post delivered to your Inbox.

Join 36 other followers