Weborandom – Now With Snapshots

This mashup was just obvious. You’ve probably seen these snap.com website previews that hover over links on TechCrunch and various other sites. Can be useful and can be, well, a bit annoying, depending on the site in question. For Weborandom, though, there was no question. It just made eternal sense and I kept imagining it was there, so it was high time I added it in. Admittedly, Weborandom already provides a preview, so this is a kind of preview for a preview. Works for me anyway. With thanks to snap.com for providing their easy-to-integrate API, it’s now live.

Go visit the new, new, Snapshots (TM)-enabled, Weborandom.com!!!

The main challenge was to make the previews refresh dynamically, which was achieved with a little On-Demand Javascript magic:

javascript

  1. function refreshSnapshots() {
  2.   var head = document.getElementsByTagName("head")[0];
  3.   var script = $("snapshotScript");
  4.   if (script) { head.removeChild(script); }
  5.   script = document.createElement("script");
  6.   script.id = 'snapshotScript';
  7.   script.type = 'text/javascript';
  8.   script.src = "http://shots.snap.com/snap_shots.js?ap=1&key=d2e3ec72c47f90dc1ccf4c25de818ed2&sb=0&th=silver&cl=0&si=0&po=0&df=0&oi=0&link_icon=on&shots_trigger=icon&size=large&lang=en-us&domain=weborandom.com";
  9.   head.appendChild(script)
  10. }

I daresay the next installment will be the big one: search. It was originally intended to do that, but mysql fulltext queries crawl with several million records. I’ll need to experiment with ferret and friends.

Weborandom Has a Practical Use!!!

Paint me Melbourne Blue and call me a serial straw clutcher, but I just discovered a practical use for Weborandom, the Web Bling-Point-Oh app that shows random websites in an Ajax carousel and has accrued no less than eight, yes that’s a superb EIGHT-point-oh Diggs :/.

Have you ever found your net connection a little slow? You start typing in web addresses that pop into your head – “google.com” “yahoo.com”, etc. You want to ensure the content isn’t cached, so you keep switching web addresses or type random queries into the Google. After a while, this gets pretty tired. You’d rather concentrate on the content and stop coming up with random things to tell Google. So, no more randomising…let Weborandom choose random websites all day. Funny that this actually ties into Weborandom’s sister website timer.

Anyway, one even better step would be to just send random queries to Google, which as we all know comes back insanely fast. Maybe I’ll do that sometime. I could extend WebWait to do that, so you get the load time displayed for each random query.

So I never knew Weborandom had a practical use. I feel like the 17th century mathematicians who delighted in the purely theoreticalism of their prime number research, only to discover it would dictate every credit card transaction 200 years later. Although I don’t feel Weborandom is quite as important as PKI. Not yet…

.

The New Timers: The Power of Blink Tags and HTML Whitespace

It seems that Ajax people have been profoundly touched by my April 1 Ajaxian post on the new Ajax timing mechanisms. Hopefully it will lead to a new age of enlightenment for humanity and finally a cool acceptance of the fearsome blink tag.

On blink:

…And so it was that <blink>’s true purpose became known. Reborn as much out of frustration with setTimeout as it was with the promise of a more robust solution. No longer eye candy, but a super-precise timing mechanism. The thinking geek of 2007 embeds a single <blink> tag on the page, hides it with CSS, and arranges all application scheduling against the swift oscillations of this postmodern crystal timer.

On HTML whitespace:

… With the trend towards parallel computation, whitespace promises a way out of the concurrency and synchronization headaches that Ajax developers often endure.

Get the full picture @ Ajaxian. And no, no-one has yet updated AjaxPatterns to incorporate these important advances in the state of Ajax.

New Website: Web-O-Random

I made a new Ajax toy. Web-O-Random is a random website finder with some Ajaxy goodness:

  • Sites load into a carousel (slider) component. Thanks to Bill Scott and Yahoo! for providing the original component and Sebastien Gruhier for the prototype port which is used here.
  • Pages load into an IFrame (as with WebWait).
  • User can re-randomize, which leads to a JSON payload of new random sites.

If you hunt for it, you’ll find there’s a way to search too, but I had to de-emphasise it as mysql full-text search takes 1-2 minutes to crunch through 4M (indexed) rows (each representing a website). If I have time, I may set up a reverse index table to cache results.

Initial reactions:

  • “…?” This is the typical reaction. It may be interpreted as a polite version of Cartman’s “Dude, this is pretty **** right here?” as in “Who would ever use this?”. Sometimes people forget that not everything has to be as popular as Google…apps like Weborandom and Webwait can be coded in a few days and hosting costs are pretty trivial nowadays. As development time trends downwards to zero, it’s the long tail of web apps! See What Happens When t Approaches Zero?
  • “So I get a new site by clicking Randomize?” (You’re meant to use the carousel first. I added some initial animation to the carousel, which looks cool and shows people there’s more than meets the eye. I also made the carousel default to start in the middle instead of on the left.)
  • “Are those your ads?” (He thought the carousel was adsense. I refactored by showing a boldfaced website title instead of a blue link).
  • “How do I click the arrow key? I can’t see the cursor.” (Confusing to have keyboard bindings in the absence of a textarea/input control. Changed the instruction text.)

Current concerns with Ajax

A reader just mailed me about what I see as concerns with Ajax right now…what’s still worryng?

Well, here are a few things off the top of my head…

Accessibility is still a key issue, but more to do with if people bother to Ajaxify at all than if people break accessibility. If developers are required by their companies or regulations to make their web apps accessible, what’s the incentive to add Ajax and make it more usable as well? Making a website Ajax-enabled and accessible can sometimes be a lot of work. Managers really have to be aware of the benefits of Ajaxifying their apps so they can make a balanced choice.

Documentation for the key open-source frameworks (prototype and dojo) is still very lacking, though it’s good for Yahoo! and Mochikit. I really want to use Dojo in a big way and the mailing list support is great, but every time I look for docs, it’s just too discouraging and I revert to Prototype (being the default Rails library of choice). For a long, long, time, Prototype’s homepage was completely empty – essentially just a download link. Now there’s a little more, and also the Scriptaculous wiki, but still pretty raw.

In this world of mashups, it’s ironic that XMLHttpRequest is not at all suited to cross-domain calls. We can sort of work around that with Cross-Domain Proxy or On-Demand Javascript, but they are both hacks. The first is inefficient as it involves the host server in all calls, the second requires explicit permission and support from the external server. Neither is the ideal, clean, call that XHR was supposed to facilitate. A better model is required. Doug Crockford’s JSONRequest will help, but is unlikely to be adopted by MS – in an earnest way – anytime this decade.

Cross-browser programming is still painful. CSS is inconsistent and DOM models vary in subtle ways.

Comet (HTTP Streaming) is becoming really important, but is still out of reach for the typical Ajax programmer. Too resource-intensive, too many issues to overcome, especially in the server.

Time Your Website with WebWait.com


Update (2 days later): The site’s been popular – 10k+ views yesterday. Hit Delicious Popular and somehow got caught up in the German blogosphere, the greatest source of hits. Technorati it. There’s a good discussion in Ajaxian of the strengths and weaknesses of this technique. As with AjaxPatterns, which also reached Delicious Popular, it failed to attract Digg users somehow. (Digg was supposedly inspired by Delicious Popular. Incidentally, Digg doesn’t let you submit URLs with fragment identifiers such as http://webwait.com#digg.com, which rules out any Ajax site attempting to allow bookmarks.) Go figure. Or better, go Digg :).

Here’s another new website – WebWait. I wanted a portable, consistent, way to benchmark Ajax web apps, that would show how long the wait is (though it’s useful for any app, especially if there were a lot of images, for instance). Using a command-line tool like curl is an improper simulation and doesn’t cut it as a proper simulation. WebWait has the following benefits:

  • Runs in a browser. You get actual load times in the same client web users are running, not simulated times.
  • Runs in multiple browsers. There are plugins that do this, but as well as the installation overhead, they are usually specific to one browser. With WebWait, you can just cut-and-paste the same URL into different browsers. (No Safari yet as it doesn’t listen to iframe onload ???.)
  • Respects your cookies and authentication – If you can access a URL in a web page, you can benchmark it with WebWait. Trying to set up cookies for use with a command-line tool like Curl is hard work. Doing it with a plugin is usually impossible. Doing it with a third-party website is dangerously insecure.

Quick feature list as it stands right now:

  • Basic functionality: Type a URL, see how long it takes to load.
  • Option: Set the delay between calls. WebWait will call the website multiple times and provide an average load time.
  • Option: Set the number of calls before ceasing activity.
  • Ability to pause.
  • Partially transparent lightbox eye candy.
  • Unique URLs – it’s Ajax, but that shouldn’t stop you from bookmarking and sending URLs with details of the website being tested. Incidentally, implementing this rare but highly useful feature took three lines of Javascript.

Have fun. Any comments/suggestions, please let me know!

See the FAQ for more info.

Quizr: Quizzes 2.0

Quizr – AKA “The reason this blog has been sparse for the past couple of months” – is online now. It’s a site I developed to allowing making, taking, and sharing of quizzes … making the most of Ajax and the assorted Web 2.0 technologies. At the heart of it is user-generated content – anyone can make a quiz and anyone can take a quiz. I always found old-school quizzes to be frustrating because: (a) you either do one question at a time, and wait 10 seconds for the page to reload to see if you were right or not; or (b) you do all questions at once, and then get all the answers at the end. Quizr gives you real-time feedback.

Features include Ajax-style editing and quiz-taking; searching and tagging of quizzes; RSS feeds for recent quizzes; tracking of results; embedded video, audio, and images.

To make it easy to make content, it uses Lazy Registration, so you can get started creating quizzes without having to sign up.

It’s currently in closed beta, but here’s a screencast – mail me with “quizr” in the subject line or sign up on the homepage if you’d like access to the beta. I’ve set up a Quizr Blog, so I won’t mention it much here, other than some technical notes at some stage.

Linux Journal Editor’s Choice Award, Development Book – Ajax Design Patterns

 

Just discovered Ajax Design Patterns has received the 2006 Editor’s Choice Award from Linux Journal for books on software development. It’s a personal honour, but it’s also a sign of the groundbreaking role Ajax has played in 2006.

Ajax Design Patterns, published by O’Reilly, assumes that you have a good idea of how HTTP, HTML, the DOM and CSS work (although it does help you brush up as necessary), and it shows you how to combine the basics into sophisticated applications. You can almost think of it as an Ajax cookbook, but with the underlying theory and advice that you need to make interesting applications.

Thanks to Jason Salas for passing on the news (Jason followed the book’s progress as it evolved and recently wrote a positive review on his blog.)

Phobos – Server-Side JS Redux

On Ajaxian, Dion points to Sun’s Phobos project, an attempt to build a new platform for server-side Javascript. Phobos came out six months ago, around the time of the May Ajax Experience.

No-one has taken server-side Javascript seriously since it died a premature death in the mid-90s. But there is great potential…

  • Server-side Javascript would allow for code sharing between browser and server. The most obvious application being validation code, but since no-one really bothers with server-side Javascript, there are probably many other patterns as well. One pattern I came up with a while ago is Dual-Side Templating, where you have the same parametized HTML template on both the server (for initial page load) and the browser (for subsequent additions to the page). I implemented the server templating in Ruby, but it would have been a lot easier if the server was running JS. That’s just one example.
  • Server-side Javascript would keep us Ajax types more sane. Right now, an Ajax developer has to constantly flip between JS and [insert favourite server-side language here]. True, you always have to flip over to other “languages” too, viz. HTML, CSS, SQL; but there’s always a special place in the programmer’s head for the core language of the day. With Ajax, you have two such languages. If those languages are quite similar (e.g. Javascript and PHP), it gets frustrating because of all the subtle differences (new Array() versus array()). If they’re different (Javascript and Ruby), you’re trapped in a Whirf-Brock disconnect, constantly flipping between two different worldviews. Slight exaggeration as it’s certainly do-able, but it would be a lot easier if programming in one main language.
  • Server-side Javascript would pose less of an issue for IDEs. With new improved Javascript, IDEs are being forced to support Javascript in order to keep up. It’s far more important than supporting SQL etc; so basically, IDEs now have to provide solid support for at least two serious languages…it would be easier if it was only one.

Now a framework like Phobos has much to offer the world compared to the server-side Javascript of the mid-90s:

  • Phobos is apparently inspired by new frameworks such as Rails. With the right libraries and improved patterns for OO, inheritance, etc, Javascript can compare admirably against Ruby. Not in every regard, but then there are actually some aspects of JS that are superior (e.g. functions as opposed to blockism; dynamic member creation).
  • There’s a lot more known about Javascript now, and it’s almost certainly the most widely understood language in the industry, even though it’s not the primary language for many (cf. English).
  • Because of all the JS code now running in the browser, there are probably a bunch of synergies with server-side JS – these could be exploited by a well-considered server-side JS framework.

As an open platform, Phobos has the best chance right now to make server-side flourish. But I agree with Dion, that there is reason for concern about whether it will happen.

Sun may already have this. Will they be able to market it? Unfortunately, the track record isn’t there, so it will probably languish. Buy maybe not.