AsynchronousAutorefresh

MeatballWiki | RecentChanges | Random Page | Indices | Categories

The traditional Wiki RecentChanges imposes some repetitive tasks on the user: filtering out changes they have seen already; filtering out day-to-day site maintenance from new content; and sporadically reloading to watch for new changes as they arrive. However, repetitive tasks are best performed by the computer, leaving the user to focus on what cannot be automated: PeerReview and collaboration.

While filtering can be performed on-server, the traditional Web interaction model demands reloading an entire page when new information arises. Automating this is a good way of annoying the user, as page reloads break their interaction model, periodically stalling user interaction on slower connections, and disrupting and even preventing longer tasks like reading a long list of changes. However, modern browsers allow data loaded asynchronously from the server to be merged into a web-page without a complete reload, a technique currently popularized as WikiPedia:AJAX. If coded properly, this interferes minimally with long interactions.

Therefore, add asynchronous auto-refreshing to RecentChanges for those browsers that support it. Highlight new information, both graphically and in the title, to make the user's task easier. Make minimal changes to the page to minimize the chance of disrupting the user.

AsynchronousAutorefreshing can be extended to every part of a wiki. Category listings and other searches can be updated dynamically. Page histories can grow as users edit the page. Pages can flag when they become outdated, giving the reader the option of seeing a diff or just bringing up the new version (though automatically refreshing on text change will probably negatively affect the overall user experience by breaking long interactions). Edit pages can notify when a conflicting edit occurs, and even integrate the modifications into the evolving text.

Going further, one can maintain a continuous connection with the server during edits, allowing editors to see every change as it happens. (See, for example, JotSpot.) However, this breaks with the traditional wiki interaction model, where one has time to review one's text before letting anyone else see it. That model allows for a much more relaxed pace of editing, and is probably preferable in many circumstances.

Implementation notes

The current cutting-edge of AJAX design is to form HTML on-server and slip it straight into the page. This unfortunately ties the user to the server, denying the ability to change filtering and display preferences without a delay. It is also rather jarring if done automatically, as large swathes of the page will periodically change invisibly, breaking any text selection the user may be performing. Best practice therefore is to minimize page changes and maximize independence from the server, if that can be done without imposing unacceptable performance penalties.

AsynchronousAutorefresh can be done in most Javascript-capable browsers; however, a recent addition to the libraries, XMLHttpRequest, makes the job much easier. Implementors will probably demand more recent browsers, therefore.

AJAX is also useful for implementing CacheableCustomizability: however, unlike AsynchronousAutorefresh, this is a property of the server and ideally invisible to the user.

In general, Javascript is ill-equipped to parse large XML feeds (more than a hundred or so items) or post-process large amounts of HTML. Recommended best practice is to follow [Rakesh Pai's advice on XMLHttpRequest], and provide feeds as WikiPedia:JSON.

CategoryWikiTechnology CategoryUncommonWikiTechnology

AsynchronousAutorefresh on MeatballWiki

There are a few flaws in the script:

There's a slight mismatch between server and client regarding the list of authors of a page: while it will always contain the last author, and all named authors from the last 24 hours, the list may vary in length otherwise. I took the Javascript from my experimental site, which doesn't yet have page history, hence the issue. Since it's not a show-stopper, merely weird, it probably won't get fixed before the script goes mainstream.

New changes are highlighted with a red border for a short time after they appear. This has some bizarre interactions with the actual entry on some browsers, but still gets the point across so, again, will probably remain in the first mainstream version.

For some reason, Javascript implementors like ugly date strings ("Updates since Mon Oct 03 2005 10:39:31 GMT+0100"). They also don't like customization options. Rolling my own date formatter means more work now, and more work later getting things multilingual. Ugliness is probably going to stay, therefore. Sorry.

New changes may be lost if the script doesn't connect to the server for more than 24 hours. Fixing this would require debug sessions lasting more than a day and tying up a whole computer for the duration. Unfortunately, I don't have the resources to spare right now. Putting in an untested fix could produce some nasty, subtle, undocumented bugs. I'm therefore sticking with the one well-documented one for now ;)

I think that, despite these flaws, the script is an improvement on what we have now. Please do comment, as I currently plan on bringing AsynchronousAutorefresh to the mainstream version of the site sometime mid-October. -- ChrisPurcell

Bug Reports

I've pushed live an update to the AA script that may fix various problems people have encountered. I can't test the script on Safari or IE7, and it needs a run for its money on others. Please try the script and see if it works for you. -- ChrisPurcell

Discussion

Chris, I switch our discussion to FractalAggregator!