Ajax: From Tipping Point to Koolaid Point

Kathy Sierra explains a variation of the “Tipping Point”:

The Koolaid Point: A Threshold at which enough users become so passionate that others accuse them of “drinking the koolaid”. Often fueled by commercial success.

Kathy makes a great point: passion doesn’t mean happiness – people can be passionately opposed too.

Nice to see how universal this phenomenon is – Ajax isn’t listed, but the backlash has certainly begun. HTML Matters (presumably a joke on “AjaxMatters“) is doing a great job at becoming the poster-child for the counter-revolution. It’s not surprising. When the original Design Patterns book came out, people derided it on the basis that they’d already used those patterns, so there’s nothing new! Ajax is a pattern, and people either don’t see the point (perhaps because they’ve never seen Google Maps in action), feel that Javascript is such a scarce resource and – though it’s almost been around for a decade – we shouldn’t rely on browser support. And some are just resentful that latecomers are jumping aboard when they’ve been doing it all along (the same bizzare attitude of people who yearn for the days of pre-web internet).

Anyway, I’m pleased for Ajax Patterns to link to any of those sites, and it’s for that reason I included the “Ajax Achilles Heel” article when I first created that page. At one point, someone deleted it, with best intentions I presume, but I quickly restored it. It’s good to have sites like this to keep things in check. And, though I didn’t think about it that way before, it’s proof that Ajax has hit Koolaid Point.


Asides on the Koolaid Terminology:

  • Where I’m from, the Koolaid Point would be called the Tall Poppy Syndrome.
  • Some labels for the transition points of the traditional product life cycle:
    • Tipping Point: Introduction->Growth
    • Koolaid Point: Growth->Maturity
    • Jump-The-Shark Point: Maturity->Decline
  • The Creating Passionate Users blog is awesome. If and when a book comes out, its popularity will extend well beyond the software community.

Meta-Search with Ajax

I just discovered a new feed meta-search: TalkDigger (via Data Mining). It’s Ajax search all the way (buzzword overload!).

The site shows how ideal Ajax is for meta-search. Each time you enter a query, the browser fires off multiple queries – one for each engine it searches. That means the results all come back in parallel – no bottlenecks.

Back in the day, metacrawler and others were smart enough to start writing out the page straightaway, so users start seeing some results while others are still pending. The Ajax meta-search improves on the situation by directly morphing the result panels, so the page structure remains fixed even as all the results are populated. Each panel gets its own Progress Indicator.

This is an example of Multi-Stage Download – set up a few empty blocks and populate them with separate queries. When I initially created the pattern, it was pure speculation, but TalkDigger now makes the third real example I know of. I recently created a Multi-Stage Download Demo.

Another nice feature of TalkDigger, which fits well with meta-search, is the use of Microlinks: You can click on the results to immediately expand out a summary.

There’s some more features I’m hoping to see:

  • The results page definitely needs work – it’s nice seeing a brief summary of all results and having them expandable, but it’s difficult to get an overall feel. An “Expand All” would help, or showing at least one posting for each search engine.
  • The results are broken up by an ad. To me, that’s counter-productive as they look like two separate panels. I think most users will mentally filter out the ad anyway and just see the results as broken into two.
  • [Sortable columns](http://ajaxpatterns.org/Query-Report Table] – so I could sort by engine name or feed count.
  • Unique URLs Unique URLs are critical for a search engine. Unique URL Demo. Jon Udell mentioned the issue recently, regarding MSN Virtual Earth, Google Maps, and others’ lack thereof. This demo, based on Mike Stenhouse’s ideas shows it’s actually fairly straightforward to emulate standard URLs.

Ajax Frameworks – JS, Server-Side, or Both

Jason Salas is a blogger-podcaster who’s been writing a lot of good stuff about Ajax lately. He notes the new ComfortASP .Net abstracts away the DHTML/JS so you can do everything server-side. The new Ajax JSP Taglib does that too. The idea’s been used previously with libraries like the struts validation module. Custom libraries are also useful – in the past I’ve hand-coded JSP taglibs to provide better user feedback in the browser, but prevent Java programmers from having to deal with the JS.

So of the Ajax Frameworks out there, there’s a fairly common theme: either libraries let you code everything in Java/.Net/etc, or they are pure DHTML/JS or sometimes both.

Two reactions:

  • In aggressive dotcom markets, the pure abstraction libraries won’t work. In mainstream intranet apps, they will be a big thing. There are already a lot of smart JS developers and many more coming on. Where Ruby is riding the Rails train, JS is surfing the Ajax wave (I know JS and Ajax are essentially the same technology, but it sounded cool. More accurately, JS is benefiting from the Ajax branding.) So you have the new JSAN project, all the stuff coming out of Scriptaculous and DOJO and Rico. And then you have talented guys like Jon Tiersen applying their Java/Agile expertise to improve JS tooling. So overall, you will be able to do a lot more with JS than pure abstraction. Market forces dictate that public dotcoms will be forced to work directly on the browser-side in order to keep their edge. However, in the other world of internal projects, where satisficing – doing enough to just get by – is the logical mode of development, these libraries will be superb. For typical intranet apps, the incremental benefit of hand-coding JS often isn’t there – there’s not enough users and it’s often more cost-effective to train users to work around problems. Very different story from dotcoms.
  • I’d like to see these pure server-side libraries offer some pluggable behaviour, to let users customise lots of browser-side appearance and behaviour if they want to. Provide sensible defaults so users can write pure server-side code, but let them tweak it later on. So, in the browser-side, you should be able to plug in new appearances, new event handlers, maybe even event interceptors. I understand Naked Objects is headed in that direction – it will autogenerate all GUI code from the domain model, but you can then hand-code a particular object’s look-and-feel if so desired. To me, that’s the key to a good framework: strong flexibility (but only where it matters), combined with sensible defaults.

Ajax Patterns: Widgets broken down

For a long time, the Ajax Patterns had a big section of widgets, about 15 in all. This week, I’ve been working on full-text versions and they’ll be finished on the weekend. Writing the low-level details helped crystallise some of the relationships for me, and I’ve been able to break those widgets into three groups, which makes a bit more sense now.

So now the structure is this:

  • Content Widgets
  • Form Widgets
  • Page Architecture, which will be renamed, it sounds too grandiose and overarching at the moment, whereas it’s really just more patterns at the same level as above.

Here’s what they contain – see the ajaxpatterns homepage for up-to-date info. (Excuse the cut-and-paste job).

Content Widgets

  • Drilldown See http://betfair.com sidebar.
  • Microcontent Compose the page of “Microcontent” blocks – small chunks of content that can be edited in-page.
  • MicrolinkProvide Microlinks that open up new content on the existing page rather than loading a new page.
  • Popup Support quick tasks and lookups with transient Popups, blocks of content that appear “in front of” the standard content.
  • Portlet Introduce “Portlets” – isolated blocks of content with independent conversational state.
[]

Form Widgets

[]

Page Architecture

Podcasting is Easier than Blogging (in Theory)

One of several reasons why podcasting won’t be as big as blogging, according to Paul Scrivens :

Blogging requires a browser (if you are using a webmin interface) and an Internet connection. That’s it. Podcasting takes it a step further by requiring a microphone. I know many of you have mics on your computers, but I know a lot of people who don’t. Podcasting adds one more step to the publsihing process and if you mess up during the podcast it isn’t as easy to correct with a press of the backspace button as it is in blogging.

There are a couple of assumptions here.

Podcasting is Blogging and More But many people just publish podcasts without any shownotes. So if you have a libsyn account for instance, you can just upload the file and have it automatically pushed to an RSS feed. All you need to publish a podcast is the ability to get a file onto a server – FTP it, mail it, fax it, whatever.

Personal experience leads me to agree with the point about messing up. It’s for that reason that Adam Curry, Dave Slusher and others have led the way by demonstrating the notion of keeping things simple and not being obsessed with little glitches. Tools are still desperately required and the big breakthrough will be speech recognition, which I’m hoping will catch the end of the web 2.0 funding wave.

Podcasting requires a Microphone

Yes, but most people carry a microphone in their pocket all day long. More so than people with permanent access to a PC — 300 million+ Chinese mobile users can’t be wrong! Using a dialing gateway, you can easily create an MP3 from your phone. There’s a lot of opportunity for better services here, but the basic technology is already there. Note that none of this requires a smartphone – in theory, you just dial in, leave your message, and it’s updated to your podcast. There’s no editing, but again, that comes back to the idea of learning how to podcast without needing edits.

For those using a computer, they do need a microphone, but that’s hardly a showstopper for someone interested enough to want to podcast. To be fair, there’s actually a much bigger problem for many people: finding a quiet time and place to record a podcast.

Podcasting has arrived

It’s great to see how quickly podcasting has caught on. Two big VC deals and the American president becoming the latest podcaster (even if the term is not explicitly used; via Micropersuasion). Don’t tell me about fads – this won’t kill radio, but rest assured that podcasting has arrived.

Spying on Users With XMLHttpRequest

Earl Castledine points out the allegedly dark side of XMLHttpRequest: spying on users (thanks Ajaxian). It seems that this capability will cause it to “likely fall from grace”! (I mentioned the issue a little while ago regarding the Heartbeat pattern).

Two examples are given in the new article:

you write an e-mail to Apple support that says: “I just bought a brand new iPod. I dropped it down a set of stairs. It stopped working.” You then decide to delete the second sentence to help your cause. TOO LATE! If the site uses AJAX, your response may already have been zapped to the complaint desk in the sky!

I agree this could actually happen. The live chat/wiki demo, for example, is based on a Fat Client model, where the browser essentially runs a full app and periodically synchronises with the server, during which time intermediate info is logged. HOWEVER, even if the Apple support guy had access to the data, and felt like poring through every partial text at 5-second intervals, and the user was unlucky enough to have submitted the guilty message, I doubt it would hold up because you can sync all you like, but the user can’t be held responsible for what they wrote until they’ve acknowledged the message is done. This legal motivation is one reason why you’ll always see Explicit Submission in some Ajax apps, even though Submission Throttling renders it unnecessary from a technical perspective.

The second example:

Or — a little more malevolently — consider this: most people have one or two username/password combinations that they use for all of their “unimportant” sites such as news sites, blogs, and forums. They probably also have a few reserved for use on more sensitive sites — banking, Web mail and work accounts. It’s a very common and easy mistake to begin typing incorrect login details for a given page. Force of habit is responsible, but people usually realize what they’ve done before hitting the submit button.

I suppose it’s possible once again, but since there’s a concrete example to go by, I’m going to take this one literally too. The problem here could just as easily occur in a traditional app – I’m sure users frequently submit the wrong user/password too. That would actually be more dangerous than just periodically capturing what the user’s typing, because how do you know when they’re finished. Even when someone does capture such information, they still have to start guessing where it applies. Also, if users only have one or two combinations, they’re pretty likely to type in the same password anyway, ne? So what’s the devious webmaster getting at that they couldn’t get at before?

The thing is, you could have captured all this information before. Here’s how you do it the new way, with XMLHttpRequest:

  • Every few seconds, post the current browser state to the server.

Here’s how you do it with standard forms:

  • Every few seconds, push the state onto an array.
  • When the user eventually submits a form, upload a string representation the array. Note both of the examples above involve submitting a form eventually, and note that even an external hyperlink can easily be scripted to force a form submission. It’s a little more work, but it was always feasible.

Admittedly, one difference is that XMLHttpRequest provides some cover for malicious activity, because periodic submission is standard practice, whereas periodically submitting history is just a little suspect.

While this sort of stuff is mostly FUD, Ajax does bring out the common tension between usability, security, and privacy. The Heartbeat pattern, for instance, involves monitoring page events to see if the user’s active. Definite security benefit, definite benefit for resource conservation, but also a definite increase of personal monitoring.

In any event, users need to be aware the security model of the web is that whatever basic actions they perform on the page are open to the operator of that site. XMLHttpRequest may play a small part, but it won’t be falling from grace anytime soon.

Ajax Business Improvement: Lazy Registration

Lazy registration is a killer app for Ajax usage in business. Tim Haines has a contest going on to improve a business model with Ajax (right on, Rick Strahl). The contest is about an online ecommerce site – I can do better than a suggestion … I’ve got a working prototype for this one and an explanation at http://ajaxpatterns.org/Lazy_Registration. (Lazy registration sits nicely with a lazyweb contest of this nature 🙂 .

The idea is not mine at all actually, it’s been done for a long time by sites like Amazon, and Chris Were, AKA Tahpot had the insight to see what Ajax can hold for it.

The demo is online at: http://ajaxify.com/run/shop/. Go and see how easy it is to register when it all happens on the page. (It’s all cookie-based, your account won’t really be persisted). A small website like HandyShop (that in the contest) gets killed by Amazon because users don’t want to go through another registration process. Ajax makes registration light work, thus dropping a massive barrier for ecommerce sites.

And yes, it’s just a demo. Some things could be improved.

Quick summary:

  • New users get an ID immediately.
  • All registration occurs inside an independent Portlet. There’s no 10-minute distraction caused by page reloads and email verifications, all those things which traditionally kill an ecommerce site’s chances of a user buying something. The registration is completely parallel to the main site usage, the user can gradually flip between the two.
  • Gradually accumulate info, whether officially registered or not. In the demo:
    • You can enter your email to have the shopping cart mailed to you. Once you do this, the email is already known and will always appear in the profile. You’ve just dropped a major barrier to the registration, as the user has provided their login ID (the email address) in exchange for a service.
    • Your preferences are monitored and shown in your profile. You can override it and set them manually.

Each of the Ajax Patterns has a story to provide a concrete illustration of how they can be used. Here’s the story for Lazy Registration:

It’s Saturday afternoon, and Stuart is busy planning the evening’s activities. He visits a band listings website, where he clicks on a map to zoom into his local area. Even though he’s never visited the site before, a profile is already being constructed, which he can see on the top of the site. At this stage, the profile guesses at his location based on his actions so far. As he browses some of the jazz bands, the profile starts to show an increasing preference for jazz bands, and some of the ads reflect that. Since the jazz thing is a one-off idea, he goes in to his profile and tweaks some of those genre preferences, but leaves the location alone as that was correctly guessed. Finally, he decides to make a booking, at which point he establishes a password for future access to the same profile and also his address, which is posted back to the profile.

I’m tempted run my own competition to see if anyone can tell me how this can’t be a good thing for businesses.

XMLHttpRequest gets most of its groovy factor from the fact that the user doesn’t see an entire page reload. But there’s another big benefit people often overlook: state remains on the page. So you can really have entire parallel conversations going on within the same page, and no need to post twenty variables in hidden fields just because one tiny query is required.

Actually, there are plenty more ideas possible and many of the ajaxpatterns.org stories, like the one above, are intended to give a glimpse as to what’s possible. So while most of the demos at ajaxify.com are of the ‘Hey look what I can do’ variety, the corresponding patterns show how Ajax can go well beyond the hype.

Update: Just an hour after posting this, I saw Ajaxian has linked to the Palmosphere website, which actually performs a kind of lazy registration, letting you add favourites before logging in. I’ll go add the example to the pattern write-up shortly.