Section 15.4. Malleable Content | Ajax Design Patterns

15.4. Malleable Content

Affordance, Collaborate, Edit, Hint, Input, Microcontent, Mutable, Outline, P2P, Selection

Figure 15-9. Malleable Content

15.4.1. Goal Story

Reta is logged in and is revamping the catalogue web site. 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.

15.4.2. Problem

How can you let users change content?

15.4.3. 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 roles are, 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 are often 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.

15.4.4. Solution

Compose the page of Malleable Content blockssmall chunks of content that can be edited in page. The page is structured in chunks of small "microcontent," 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.

The reload problem is one reason why conventional web sites must present large forms in which everything can be set at once. It's often the only practical way to edit content. However, users have difficulty relating the editing interface to the readable interface. Worse, it discourages editing; users are subjected to a sequence of at least two-page reloads in order to change a single character.

Ajax technologies lead to a smoother editing process. Display Manipulation (Chapter 5) and Dynamic Behavior (Chapter 7) help the user locate and open up editable Malleable Content. Display Manipulation also shows you how to conjure up a new editable area, or morph read-only Malleable Content into an editable form. Once the user has made the edit, you can seamlessly upload the response, as described in Web Remoting (Chapter 6), at which point the content can revert to read-only again.

In most cases, each block of Malleable Content is a div or textarea element. It can become editable in one of several ways:

The display of the original element is adjusted and augmented with editing controls.
A new div or textarea is created in its place.
The original element becomes hidden and a hidden div or textarea is revealed.

Is that the sound of your inner usability critic banging his fists on the table and exclaiming "this defies 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 following section.

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 goalone that shouldn't be neglected because you have a few "one-percenter" improvementsbut Ajax represents a 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 become familiar to users in the not-too-distant future.

15.4.5. Decisions

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

A read-only page will contain several editable Malleable Content blocks and various other regions that cannot be edited. Some of those regions are program-generated; others might be Malleable Content that this user is not permissioned to edit. So the user needs to know what can be edited. The static appearance should provide some cues, and events like mouse rollovers can refine that information.

The static appearance should make the location of the Malleable Content apparent. There are a few techniques to consider, some which are based on the Highlight pattern:

When there are multiple Malleable Content blocks, increase spacing or alternate fonts between them to keep them distinct.
Present the Malleable Content with a distinct background.
Apply an explicit border around the Malleable Content.
Expose the edit controls (e.g., Undo button), or the controls which initialize the edit (e.g., Edit button), but faded out.
Add a label and auxiliary information beside each Malleable Content block. (See the following.)

These provide enough information for the user to detect that Malleable Content is present. However, too many of these cues will defeat the purpose of this pattern by making the whole thing hard to read. So you might use only a few subtle cues, or even none at all, and rely instead on dynamic behavior. 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 Malleable Content was altered. Then, apply (or unapply) the effect generically to that element.

All of the preceding static cues qualify as suitable dynamic cues, too. For example, change the background color 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. These dynamic cues, combined with just one or two static cues, are an effective way for users to pinpoint blocks of editable Malleable Content.

15.4.5.2. 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.

The following auxiliary information, which can be automatically gathered by the server, might also be shown:

The user who created the content
The user who last edited the content
The number of edits
The creation date
The last edit date

15.4.5.3. 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 that item's 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, influence the size of Malleable Content 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 that the data structure is a suitable size. If it's too big, split it. If it's too small, aggregate it.

15.4.5.4. How will the user stop editing content?

Now you've decided how the user will open up content for editing, but how will she complete the edit? Here are the typical options:

As soon as focus is blurrede.g., when the user clicks on an external objectthe content is saved and becomes read-only. This is good for power users who might wish to tab through content fields.
Explicit controls, such as Save and Cancel, are added during editing. This may involve rearranging items on the page.

15.4.5.5. Is it okay to have several Malleable Content blocks open for editing at one time?

Because Malleable Content is an Ajax App, the user might not reload for a while, so he'll need to close each block manually in order to see the page become read-only again. You might enforce a rule that one field can be 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.

15.4.6. Real-World Examples

15.4.6.1. Flickr

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

Several things happen here:

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

Figure 15-10. Flickr caption

15.4.6.2. Monket Calendar

The Monket Calendar (http://www.monket.net/cal/) lets you add events to a shared Ajax calendar (Figure 15-11). 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 that the field can be clicked. Once you click on the field, the rounded edges remain, but the central, horizontal component changes to white, the existing text is selected in full and becomes editable, and an "X" appears that lets you easily remove the appointment.

Figure 15-11. Monket Calendar

15.4.6.3. Tiddlywiki

With Tiddlywiki (http://tiddlywiki.com), controls appear as you roll the mouse over the Malleable Content (Figure 15-12). They are actually always present but are usually invisible, which means that surrounding fields don't move when you mouse aroundthe fields just toggle in their visibility status. One of these controls lets you edit: it 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.

Figure 15-12. Tiddlywiki

15.4.6.4. Thomas Baekdal's Business Card Creator

Thomas Baekdal's Business Card Creator (http://www.baekdal.com/articles/Usability/usable-XMLHttpRequest/) contains a business card with mostly black content on a white background. As you hover over a field, the border changes, and when you edit, the background color also changes. This interaction style was the basis of the following wiki demo.

15.4.7. Code Example: AjaxPatterns Wiki

The Wiki Demo (http://ajaxify.com/run/wiki) breaks page content into a few Malleable Content blocks. A single div is declared in the initial HTML to hold these blocks:

   <div ></div>

At periodic intervals, the incoming XML is parsed to extract each message into its own block of Malleable Content. Each message is actually a textarea but is rendered to appear read-only until it's edited. The CSS class, which initially corresponds to a grey background with no border, is set to show the text in read-only mode. Handlers are registered to provide dynamic cues that the Malleable Content can be edited and to handle the editing process:

   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;       ...       }     ...   }

We can examine each event handler to see how the editing cycle occurs. First, the user rolls over a message block. We'll outline the message with a dotted border to hint that it's in the twilight zone between read-only (no border) and editable (full border). We wouldn't want this to happen if the user was already editing the content, so we make an explicit check for that condition. Incidentally, you'll notice that the event handlers also manipulate colors here. That shouldn't be necessary; it is a workaround for the fact that some browsers unfortunately resize the border when it changes style. Without the workaround, the other content blocks would undergo slight movement each time one block changes.

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

And when the user rolls off this message block, the appearance is reset:

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

Okay, our user has just rolled over a message block and now clicks on it to begin the edit. In the previous handler, we performed a check based on a hasFocus field to see whether the message was being edited. That's not built into the DOM, so we have to set it manually when the edit begins. During editing, the background is white and the border solid black. Finally, we ensure that no synchronization occurs while the user is editing (which is not always advisable):

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

The user signals end of edit by clicking elsewhere on the page, causing a blur event to occur. The message returns to its original read-only form. Or, if a change has occurred, the message is highlighted and will eventually be reset once the change has reached the server. Also, a resize function adjusts the height according to the new content. Finally, synchronization can begin again:

   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( );   }

15.4.8. Alternatives

15.4.8.1. Compound Edit

It's possible to edit the whole page content at oncethe typical approach in conventional web apps. As explained earlier in this section, there are problems with the approach, but users may prefer it for long editing sessions. Ideally, both styles should be provided.

15.4.9. Related Patterns

15.4.9.1. Live Form

Upon becoming editable, a Malleable Content block might become a Live Form (Chapter 14).

15.4.9.2. Rich Text Editor

One way to edit Malleable Content is with a Rich Text Editor (Chapter 14).

15.4.9.3. Microlink

Malleable Content can be summoned onto the page using a Microlink (see the next pattern)the approach used by TiddlyWiki (http://tiddlywiki.com).

15.4.9.4. One-Second Spotlight, One-Second Motion, and One-Second Mutation

The "One-Second" visual effects (Chapter 16) are a good way to support editing. It's becoming common to Fade In recently saved content as a means of hinting that it has been acknowledged. Mutations such as Blow Up and Disappear imply that Malleable Content is being deleted.

15.4.9.5. Highlight

Malleable Content is often highlighted to show that it's being edited and as a dynamic cue that it's available for editing.

15.4.10. Metaphor

Applications using Malleable Content are like a communal whiteboard.