AjaxPatterns
Console, Log, Message, Status
Pam wants to revise the list of project issues. As she begins ticking off those that are now resolved, she notices the Status Area below update, showing number of issues resolved and number still outstanding.
The same data can be represented in different ways.
Users often benefit from redundant summary information.
Screen real estate is limited - you can't augment each field with its own summary information.
Include a read-only Status Area to report on current and past activity. The Status Area is usually some auto-generated text based on some aspect of system state. The main purpose is to save space, by occupying the same region with information from different sources, by dynamically altering the information according to current context.
Applications include:
Summarising information about elements the mouse is hovering over.
Summarising information about the element being edited.
Summarising information about the overall application state.
Capturing past events in a log.
Offering a preview.
Often, there's no server-side processing involved - the browser has enough information to maintain the Status content itself. For example, the browser can easily show a count of selected elements or a log of past data that's been retained. A Status Area can be particularly valuable for monitoring the state of dynamic objects. For example, an E-Commerce system can use “Periodic Refresh” to continuously update the state of an order within the user's profile - "Submitted", "Credit Card Verified", "Stock Available", and so on.
The Status Area is usually a div element, with changes triggered by events such as mouse rollovers and form editing.
Note that this pattern is mostly speculative and based on analogies from conventional desktop systems (where Status Areas are indeed commonplace).
The Status Area is usually a relatively small element, sometimes just one row of text. You need to perform some analysis to determine the worst-case situation, i.e. what's the most content the Status Area could hold, and how will you deal with overflow. Strategies include:
Compressing the text somehow - e.g. by trimming the message or extracting a summary.
Introducing scrollbars. This is reasonable for a console-like Status Area which retains a history.
Dynamically resizing the Status Area (which is not very common).
Betfair includes a “Live Form” to create new bets (see Real-World Examples in “Live Form”). A Status Area tracks your total liability, dynamically updated as you change the stake.
Brett Stimmerman's Lace Chat is an Ajax chat app. A Status Area contains a live preview of your message. As you type, a preview of the output, including any markup, is shown.
The Basic Wiki Demo is refactored here to include a “Status Area”, in the Status Wiki Demo. While the focus is on a message, there's a Status Area below maintaining the word count, row count, and character count (Figure 1.77, “Showing the Status of a Wiki Entry”).
The static HTML has been refactored to include a Status Area, with a table for all the values. This means the script need only set the actual count values, rather than performing any HTML manipulation:
<div id="status">
<table id="statusTable">
<tr>
<td class="label">Message ID</td>
<td class="value" id="messageId"></td>
</tr>
<tr>
<td class="label">Row Count</td>
<td class="value" id="rowCount"></td>
</tr>
<tr>
<td class="label">Word Count</td>
<td class="value" id="wordCount"></td>
</tr>
<tr>
<td class="label">Character Count</td>
<td class="value" id="characterCount"></td>
</tr>
</table>
</div>
The CSS stylesheet makes the status initially hidden:
#status {
visibility: hidden;
text-align: center;
}
When the message gains focus, it makes the status visible and calls showStatus() to set its values according to the message's initial state. The Status Area remains until the message is blurred. Also, to update on each change, showStatus is called on keyup:
function onMessageFocus(event) {
...
$("status").style.visibility = "visible";
showStatus(message);
}
function onMessageBlur(event) {
...
$("status").style.visibility = "hidden";
...
}
function onMessageKeyUp(event) {
var message = getMessage(event);
showStatus(message);
}
The showStatus message analyses the message and posts its results to the status table cells:
function showStatus(message) {
$("messageId").innerHTML = message.id;
$("characterCount").innerHTML = message.value.length;
$("rowCount").innerHTML = message.value.split('\n').length + 1;
var messageCopy = message.value.replace("\n", " ");
messageCopy = message.value.replace(/^ */, "");
messageCopy = messageCopy.replace(/ *$/, "");
$("wordCount").innerHTML = messageCopy.match(/^ *$/) ? 0:messageCopy.split(/\s+/g).length;
}
A Popup is another way to show some auxiliary information without dedicating a permanent space on the page for it. A Status Area is less intrusive, but at the expense of some screen real estate.
Most browsers contain a status bar at the bottom, which you can access with the window.status object. That's an okay place to include some status information, but there are drawbacks. First, it's a very rudimentary interface with no support for structured content, styling, and animation. Second, users expect to see URLs there as they hover over hyperlinks, and you might be breaking that model. Third, there are cross-browser issues. Firefox, for instance, disables scripting the status line by default, due to security concerns (malicious websites can fake the URL you're heading to).
Where the Status Area shows server-related status, use a “Periodic Refresh” to keep it up to date.