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.
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.
AJAX is also useful for implementing CacheableCustomizability: however, unlike AsynchronousAutorefresh, this is a property of the server and ideally invisible to the user.
There are a few flaws in the script:
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
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
Chris, I switch our discussion to FractalAggregator!