A Few Ajax Gotchas At Jalecode

Andrew Sutherland offers a few Ajax Gotchas/Tips. I’ll add some comments.

  • Escape content with encodeURIComponent() which is superior to escape.

  • XMLHttpRequest’s readyState tells you how far the request has progressed. MM: If you’re confused about readyState‘s transition from 0 to 4, you have good reason to be. Read the recent posting and comments on David Flanagan’s blog, and you’ll learn that 2 and 3 are ambiguous to the point of being unusable. Essentially, you want to wait for either 4 or timeout, and probably ignore everything else.

  • Permission Denied” for XMLHttpRequest is usually due to trying to call another domain. MM: The standard security policy is that requests can only be sent to the originating server, just like the traditional policy for Java applets. To get to another domain, you can set up a Cross-Domain Mediator. This security issue has become interesting with the growing popularity of Single Page Applications (SPA). What can an HTML page sitting on you hard drive access? All domains or no domains? It would certainly be convenient if it could access the web at large. I don’t think it can access any domains on standard browsers, but it’s still possible if the user wants it to happen. Here’s what Steve Yen (TrimPath) says on this issue: “I’m shooting for now to have explicity user-driven synchronization working, which my experiments lead me to believe is workable.”

  • MM: Finally, I’ll add another gotcha-inspired tip to Andrew’s collection: Set content type to XML (in the case where you want to treat the response as XML), e.g. in PHP, header("Content-Type: text/xml");.

A Fading Habit

I’ve noticed that I’ve recently habitualised the Yellow Fade Technique, or what the Ajax patterns refer to as One-Second Spotlight.

The typical Fade example is a form field. When you change it, the field is suddenly highlighted, then gradually fades back to its original form. This tells the user that “the computer” knows something’s happened, and also serves to draw their attention to a particular element.

This is one of those things that could have been big years ago, but never happened. Despite the fact it’s only become popular recently, it’s all quite simple from a technical perspective, even more so with the new libraries coming out. I created a couple of demos a while back – one is powered by Scriptaculous, the other uses a custom-built fading engine. The first demo runs opacity through a sequence, the second demo does the same to colour, rather than opacity.

In the Scriptaculous case, running the effect is mind-numbingly simple to invoke:

new Effect.Appear(“defaultTimeLabel”);

And likewise in the case of my custom fader (which lets the user specify colour preferences):

fader.fade(defaultTimeLabel, $(“startColor”).value, $(“endColor”).value);

Anyway, I’ve lately been coding some more dynamic DOM manipulations, and it’s occurred to me that I now ask myself, whenever I add or remove an element, if I need to run an effect. Having scriptaculous handy makes it so easy to do. So fading started off as a bit of a novelty and is now standard practice.

I can hear people saying, “not the blink tag” and re-living 1995-esque motion sickness. That will definitely happen on some Ajaxian sites, but let me clarify that I’m only asking the question each time a change comes up, not actually implementing the change. Apps using the One-Second” visual effects include TiddlyWiki and Backpack (one of the first uses). They show how it can be used effectively and without going overboard.

Of all the new JS libs coming out, I haven’t seen any that augment or replace basic XHTML DOM manipulation. If one does emerge, I’d like to see it provide support for auto-effects and perhaps a parameter to indicate the effect. e.g. el.hide(Effect.FadeOut); el1.add(el2, Effect.BlindDown).

Stealth Startup “Register For Interest” Pattern

Has anyone else noticed the Ajaxian “Register for Interest” pattern sported by the new-skool stealth startups? The new Firefox+++ project, Flock (via Ajaxian) is doing it right now.

Essentially, “This is happening in a few weeks, leave your mail, we won’t spam you, and we’ll tell you about it.”

I submit my email.

Then the page morphs and thanks you for your interest. (Not altogether different from Lazy Registration.)

And if Flock is different to the last one I tried, they’ll actually send something back.

Update: They’ve auto-mailed me an invite to join a mailing list. I guess they can’t do RSS due to auth issues, but I’m going to skip on the mailing list offer.

Ajax Periodic Refresh, Chat, and Multiplayer Gaming

First, a quick update on yesterday’s book anouncement: Thanks for your interest. Yes, it will be published as a physical book. In the O’Reilly animal format. And no, I don’t know which animal.

Periodic Refresh is a pattern where the page runs a loop to continuously grab fresh data from the server (Ajaxify Time Demo).

As that pattern explains, there are quite a few chat systems that work that way. And a slashdot poster pointed out that many Japanese chat apps worked the same way in the late-90s, albeit with full page refreshes instead of [XMLHttpRequest](XMLHttpRequest Calls), because the web handled the character set better than desktop GUIs.

When I first heard of Google Talk, I thought “Hello, Google’s doing Ajaxian chat”. But, no, the text/IM component for now is a windows-only Jabber client. There’s a great opportunity for a hybrid approach here – provide a rich client which will stay on 24×7, pop up when a message occurs, and show an appropriate icon in the system tray, and also provide a web client which can be used wherever you are. Google is well-placed to do it because (a) they certainly know how to Ajaxify; (b) they need to Ajaxify – windows clients are fine and dandy, but in order to sustain its advantage, Google has to change the rules of the game by establishing the web as the platform, not the desktop; (c) Periodic Refresh is expensive because frequent requests must be handled and Google, well, they can take the hit better than most.

So in a way, I feel like Google’s missed a trick here (but then, you can never be sure what they have up their sleeves). There’s already JWChat, an open-source Ajaxian Jabber Client. While JWChat’s demo is really just a demo, I wouldn’t be surprised to see someone picking it up and creating a serious public website based on it. Meanwhile, there are offerings like QWAD Chat which are taking the business model for Ajaxian chat very seriously.

Yesterday, another interesting announcement:

We are working on an open source project to develop a peer to peer graphical adventure game, using AJAX! Looking for AJAX developers of any skill level who want to pitch in and help out! Interested? Download the first version (single player) at http://www.p2pmud.com

With Periodic Refresh, Ajaxian multi-player is feasible. I’m curious to see how far it can go. There’s a few game examples already, including Crisp’s stupendous DHTML Lemmings effort. In their inaugural Ajaxian podcast, the Ajaxians discuss SVG, which is finally about to become a reality on Firefox 1.1. Combine SVG with Periodic Refresh and we’ll be gaming like it’s 1995. (But without the sound effects. Playstation and X-Box have nothing to fear.)

As an aside, a thread a while back on Google Groups discussed whether unique URLs are worthwhile for Ajax apps. The argument was, why bookmark your state within an app? Of course, one answer is that you want to bookmark a particular object, like a location in Google Maps. But, when you think about it, why not bookmark the state in an app. I mention this because it would be sweet if you could have a unique URL for a position in a game. So you just bookmark it instead of saving it or you can mail it to your mates.

As another aside, I’m glad Google Talk went with Jabber and I hope they really do move to SIP for voice as they’ve hinted. IM today is popular, but it could easily have been ubiquitous by now if not for the fragmentation caused by AIM/ICQ/MSN/Yahoo/IRC/Jabber splitting the market, thus exponentially dropping the value of using a given solution. Now, voice has skype, Gizmo (SIP-based), Google Talk, as well as the offerings from the IM incumbents.

Ajax Design Patterns Book

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

I’m pleased to announce the in-progress patterns at ajaxpatterns.org will be completed and published as an O’Reilly book: “Ajax Design Patterns”. The accompanying podcast explains the details, here’s a summary:

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This entry has a Podcast attached- an embedded MP3 link. On Internet Explorer, Click on the Podcast icon to listen, or click the right mouse button and “Save As…” to download. Better yet, you can subscribe for updates straight into your PC or ipod – it’s easy, open, and free. Install the free, open-source, Ipodder client and when it starts, just paste this in: “http://www.softwareas.com/podcast/rss2”. Or search for “software” under the ITunes Podcast Directory. More info in the Podcast FAQ.

Protopage as Portal

I mentioned Protopage yesterday. It’s look-and-feel has so much more appeal than the standard Ajaxian portals (Google Homepage, Backbase, Start, etc.). Considering the others are more powerful functionally – given that you can do stuff like grab RSS feeds and search history – I wondered why I like Protopage so much more. There’s a lot to like, but I’ve decided one particular design decision was critical:

The portlets are free-floatingI.

By portlets, I mean all the little bits of self-managing content. In the standard Ajaxian portlet apps, you can drag-and-drop, but you’re constrained to a three-column layout, and each column must begin at the top and continue unbroken. Eschewing that approach and going for completely arbitary positioning gives Protopage several advantages:

  • It’s classical direct manipulation, the idea that made windowing desktops so popular. The user feels in control when they can move and drop content anywhere instead of being constrained by the desktop traffic laws. I’m saying “desktop” rather than web page because I can’t help thinking of protopage as a desktop right now (despite its name!).

  • Not only does the user feel in control, but the free-range arrangement makes protopage more valuable as a portal. With content arranged according to the user’s mindset, it’s easier to navigate and manage.

  • The design exploits whitespace. As building architects and town planners know, some space is good. It helps structure things and is visually appealling. The 3-column portals do contain space, but only by virtue of there being no content there yet – the user can’t directly create space.

  • Another benefit of the space is the background actually becomes useful. You can have a personalised desktop image, which can be any image URL. And the user has the power to work around any blurring effect because they are in complete control: they can move portlets around, change the background, and even change the colour scheme. Users can even arrange the portlets around the structure of the background image.

All in all, I’m impressed! Protopage is pure Ajax, one of the finest production-level Ajax apps to arrive since the hype began.

The Ajax Desktop

I know. “The Ajax Desktop” sounds like I’m taking things just a bit too far. But I wanted to point out that people are experimenting with things you’d associate more with the web.

To wit:

  • Protopage:I was triggered to write this after discovering an awesome new Ajaxian app: Protopage (via FloatingSun). It’s essentially a start page, similar to the portal efforts. However, it feels more like your desktop, with configurable background, colour schemes, and sticky notes. One really nice feature is an “Add to Protopage” link for website owners – an update of the old “Bookmark This Page!” (Does delicious have this?). Some patterns here include:
    • Lazy Registration Register all you want, but the homepage really comes down to a unique URL, which is established immediately.
    • Drag-And-Drop Another desktop-like feature.
    • Popup For configuration.
  • Ajaxian Screensaver: A post on creating an Ajaxian Screensaver. I made a comment in the Ajaxian Blog posting that linked to it about the possibility of a SETI webapp. Mostly tongue-in-cheek, but I can see it happening. It would be trivial to create (and critics might say it would be sufficiently slow to make a trivial contribution too).
  • JSCalc: A calculator bookmarklet.

How far can it go? All we need now is a web-based splash-screen. Oh, wait!

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