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!

Full-Text for Widgets

The other day, I noted the Ajax Patterns widgets have been broken down into content, form, and page architecture. The patterns for those are now complete. Give me yellow! Yellow is the colour for full-text descriptions, and the bottom of the page is starting to look a nice shade of yellow.

There are full summaries for each pattern on the homepage too. So the upshot is there’s a description for each of these:

Content Widgets

  • Drilldown To let the user locate an item within a hierarchy, provide a dynamic drilldown.
  • Microcontent Compose the page of “Microcontent” blocks – small chunks of content that can be edited in-page.
  • Microlink Provide 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

  • Live Command-Line In command-line interfaces, monitor the command being composed and dynamically modifying the interface to support the interaction.
  • Live Form Validate and modify a form throughout the entire interaction, instead of waiting for an explicit submission.
  • Live Search As the user refines their search query, continuously show all valid results.
  • Query-Report Table Report on some data in a table, and support common querying functions.
  • Slider Provide a Slider to let the user choose a value within a range.
  • Suggestion Suggest words or phrases which are likely to complete what the user’s typing.

Page Architecture

  • Drag-And-Drop Provide a drag-and-drop mechanism to let users directly rearrange elements around the page.
  • Sprite Augment the display with “sprites”: small, flexible, blocks of content.
  • Status Area Include a read-only status area to report on current and past activity.
  • Virtual Workspace Provide a browser-side view into a server-side workspace, allowing users to navigate the entire workspace as if it were held locally.

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.