From Ajax Patterns

Revision as of 17:22, 1 June 2006

Evidence: 3/3

Tags: Affordance Border Edit Hint Input Outline Selection

In A Blink

Field becomes editable.

Goal Story

Reta is logged in, revamping the catalogue website. It looks clean, a replica of the read-only page that public users will see. But as she runs the mouse down the screen, she sees that many regions can be edited.

Problem

How can you let users change content? Would you?

Forces

• The web is not just about consuming information. Administrators, and increasingly everyday users, spend a lot of time adding and editing content.
• All users, no matter what their role is, need to know what they're allowed to change.
• To encourage contributions and improve user experience, editing should be simple and free of barriers.
• Editable content pages often look ugly, with an overload of form controls, labels, and buttons. Worse, they create a divide between the contributors and the readers - while editing content, it's often difficult to imagine how a reader will see it.

Solution

Compose the page of "Malleable Content" blocks - small chunks of content that can be edited in-page. The page is structured in chunks of small content, each editable in isolation. There might be a way to edit the whole page too, but the usual style of editing is to view the read-only display and carve up little pieces as you see fit.

I hesitated to use "Malleable Content" because it's an overloaded term. Back in 1998, Jakob Nielsen defined "Malleable Content" essentially as headlines, page titles, and subject lines. The other common definition is that used here: small blocks of content, such as blog entries, with a sense of unique identity. A chunk of text, but not necessarily a single web page. The latter definition seems to be more common nowadays, perhaps because it works well for wikis, and has been popularised by its association with Tiddlywiki and related wikis.

The solution has been applied to conventional websites as well, but the problem is page reloads. Editing a page, you often want to change several pieces in one session and iterate back and forth. That's just too frustrating with a form-based website - way too many page reloads.

The reload problem is one reason why conventional websites must present large forms, where everything can be set at once. It's often the only practical way to edit content. However, it is really a form of modal interaction - you're either editing content or reading it - and that means users have difficulty relating the editing interface to the readable interface. Worse, it creates a barrier to editing - users are subjected to a sequence of at least two page reloads in order to alter just a few words.

Ajax technologies lead to a smoother editing process. Dynamic Behaviour and Display Manipulation help the user locate and open up editable microcontent. Display Manipulation also lets you conjure up a new editable area, or morph some read-only microcontent into editable form. Once the user has made the edit, Web Remoting will seamlessly upload the response, at which point the content can revert to read-only again. Let's look at these three stages in more depth.

In most cases, each block of microcontent is a div element. When the microcontent becomes editable, a different, editable, div element can be swapped in, or the initial div manipulated to become editable. Another trick is to use text fields or text areas, and simply remove their borders to make them appear-in read-only format.

Is that the sound of your inner usability critic banging fists on the table and exclaiming "this breaks everything that users have come to know about the web"? Fair point. The forms are gone, so where's the affordance to let the user know what can be edited? Affordances can indeed be provided, as discussed in the Decisions below.

Even if sufficient affordance can be provided, you might object that the whole thing is a complete departure from the usual forms-based approach. You've got me there. It certainly is a departure, but it's a departure from a ten-year old approach that's remained frustrating since day one. Consistency is certainly an admirable goal, and shouldn't be broken because you have a few "one-percenter" improvements. But Ajax represents a whole new approach, and the benefits of in-page editing are just too big to ignore in the name of consistency. Better to adopt the approach and use sensible design to guide users through it. In any event, Malleable Content is likely to take off and will be familiar to users in the not-too-distant future.

Decisions

How will users locate Malleable Content and open it up for editing?

A read-only page will contain several editable microcontent blocks and various other regions that cannot be edited. Some of those regions are program-generated, others might be microcontent this user is not permissioned to edit. So the user needs to know what can be edited. There are two ways to do this: the static appearance provides some cues and event-handling can refine that information.

The static page appearance should make it apparent where the Malleable Content is located. A few techniques to consider, some of them based on the Highlight pattern:

• Increase spacing between successive Malleable Content blocks.
• Alternate fonts between successive Malleable Content blocks.
• Present the Malleable Content with a distinct background.
• Apply an explicit border around the Malleable Content.
• Expose the edit controls, or the controls which initialise the edit, but faded out.
• Add a label and auxiliary information beside each Malleable Content block. (See next Decision.)

All of that is enough information for the user to detect that microcontent is present. However, that approach does break continuity and might not be ideal for reading. So you might only use a few subtle cues, or none at all. That can still work, because you can also rely on dynamic behaviour. Mouse movement is the most important activity to monitor: fields can be morphed to advertise their editability as the mouse rolls over them. Here, onmouseover sets up the cue and onmouseout takes it away. You can write a generic event handler and inspect the incoming event to see which piece of microcontent was altered. Then, apply (or unapply) the effect generically to that element.

All of the static cues above qualify as suitable dynamic cues too. For example, change the background colour as the mouse rolls over a particular block of Malleable Content. Or make the label and edit controls visible only during that time. In addition, the cursor can also be varied using the cursor property. Combined with just one or two static cues, these dynamic cues are an effective way for users to pinpoint blocks of editable Malleable Content.

Will the Malleable Content be labelled? What auxiliary information will be included?

Many times, the Malleable Content has some form of identity, so you may wish to explicitly associate a name with it. The name might be shown above it as a heading or summary, on the side as an annotation, or as a tooltip.

Auxiliary information, which can automatically gathered by the server, might also be shown:

• User who created the content
• User who last edited the content
• Number of edits
• Creation date
• Last edit date

What content will be marked as Malleable Content? How big will the Malleable Content be?

Any editable information is a good candidate for inclusion as editable Malleable Content. One reason against making an item editable is interaction with other data on the page. If there are certain combinations of data that are invalid, you may prefer to force the user to edit everything at once.

Malleable Content should be big enough to form a coherent unit of content, but small enough to be comfortably edited without scrolling and with enough room for some surrounding context. Of course, it's the users who will determine the exact size, and enforcing limits often achieves nothing but frustration. You can, however, infleunce the size in several ways:

• Provide guidelines.
• Illustrate the guidelines and establish norms by restructuring existing content.
• Where the Malleable Content represents a data structure rather than just free text, ensure the data structure is a suitable size. If too big, split it. If too small, aggregate it.

How will the user stop editing content?

Now you've decided how the user opens up content for editing, how do they cease editing? Typical options:

• As soon as focused is blurred, such as when the user clicks on an external object, the content is saved and becomes read-only.
• Explicit controls are added during editing, such as Save and Undo buttons. This may involve some movement of items around the page.

Consider:

• Is it okay to have several Malleable Content blocks open for editing at one time? Being an Ajaxian application, the user might not be reloading for a while, so they'll need to close each one manually in order to see the page read-only again. You might enforce only one field open at a time. This could be achieved by closing any existing block when a new one is opened, or by refusing to open a second block.
• The user often needs a way to cancel an edit.

Real-World Examples

Flickr

When you manage one of your photos with Flickr, you'll see a title above the pic and a caption below it. Both are rendered in black-on-white, and appear as ordinary read-only text, so there's actually no static cue. But it'sa easy enough to discover, especially given that most users are aware these items can be edited. Hover over these fields and the background will switch to a light tan colour. Then click the button, and the field becomes editable. Specifically:

• A border appears, outlining the field and suggesting its editable.
• The entire text is initially selected, an additional cue that you're now editing the field, and also a useful time saver as you can just start typing a new entry and the existing text will automatically be deleted.
• Save and Cancel buttons are inserted to the page , slightly displacing the content below. Clicking on Save or Cancel reverts the content back to read-only; otherwise the field remains and multiple fields can be open at once.

Monket Calendar

The Monket Calendar lets you add events to a shared Ajax calendar. Each appointment is rendered as an orange-background rectangle, with curves on either side. As the mouse hovers over a field, the field remains as is, but the cursor changes to a pointer style, suggesting it can be clicked. Once you click on the cursor, the rounded edges remain, but the central, horizontal, component changes to white, the existing text is selected in full and editable, and there is also an "X" which lets you easily remove the appointment.

Tiddlywiki

With Tiddlywiki, controls appear as you roll the mouse over the Malleable Content. They are actually always present, but usually invisible, which means there is no movement of surrounding fields as you mouse around - the fields just toggle in their visibility status. One of these controls lets you edit, which switches the field into a textarea with an input field for the title. As you hover over the textarea, new controls appear allowing you to save, cancel, or delete the item. It's possible to have more than one Malleable Content open at once.

Thomas Baekdal's Busines Card Creator

Thomas Baekdal's Busines Card Creator contains a business card, with mostly black content on white background. As you hover over a field, the border changes, and when you edit, the background colour also changes. This interaction style was the basis of the wiki demo below.

Google Base

Google Base is building up a massive database of Malleable Content, which an Ajax application might incorporate - subject to licensing issues - using a Cross-Domain Proxy. The content is wide and varied, including classified ads, documents, and recipes. And maybe one day, Ajax patterns!

Code Examples

Wiki Demo

 function onMessagesLoaded(xml, callingContext) {
  
   for (var i=0; i<wikiMessages.length; i++) {
     ...
     var messageArea = document.createElement("textarea");
     messageArea.className = "messageArea";
     messageArea.id = serverMessage.id;
     messageArea.serverMessage = serverMessage;
     messageArea.rows = 3;
     messageArea.cols = 80;
     messageArea.value = serverMessage.content;
     messageArea.onmouseout = onMessageMouseOut;
     messageArea.onmouseover = onMessageMouseOver;
     messageArea.onfocus = onMessageFocus;
     messageArea.onblur = onMessageBlur;
     ...
    }
   ...
 }

 function onMessageMouseOver(event) {
   var message = getMessage(event);
   if (!message.hasFocus) {
     message.style.borderStyle="dotted";
     message.style.borderColor="black";
   }
 }

 var message = getMessage(event);
 if (!message.hasFocus) {
   message.style.borderStyle="solid";
   message.style.borderColor="white";
 }

 function onMessageFocus(event) {
   var message = getMessage(event);
   message.hasFocus=true;
   message.style.borderStyle="solid";
   message.style.borderColor="black";
   message.style.backgroundColor="white";
   stopPeriodicSync();
 }

 function onMessageBlur(event) {
   var message = getMessage(event);
   message.hasFocus=false;
   message.style.borderStyle="solid";
   message.style.borderColor="white";
   message.style.backgroundColor="#cccccc";
   resize(message);

   var initialMessageContent = message.serverMessage.content;

   if (message.value != initialMessageContent) {
     pendingMessages[message.id] = true;
     message.style.backgroundColor = "#ffcc33";
   }

   startPeriodicSync();

 }