Edit-in-Place
OmniGraffle label edited in place |
|
What: |
Use a small, dynamic text editor to let the user change text "in place": position the editor directly over the original text, rather than using a separate panel or dialog box. |
|
The builder UI contains text that the user may want to change sometimes. The names of objects, text elements in a graphic layout, labels, and even property values are good candidates. |
Why: |
Making the user go somewhere else -- a place far away spatially, or
disconnected from the original text, in another window -- usually
isn't a good idea. The user may not find the editor, for one thing.
It also takes time to switch one's attention from one place to
another, and the perceived complexity of the the interface is
increased.
That said, an alternative to this pattern is to edit the text in a separate panel, such as a Property Sheet (see Chapter 4) or in a dialog box. You should do this only if Edit-in-Place is too technically difficult, or if the text in question is so long and complex that it deserves specialized editing and formatting tools -- fonts, text sizes, the kinds of things you'd find on text editors' toolbars. |
How: |
When the user clicks or, more typically, double-clicks on
the text to be edited, simply replace it with an editable text field
containing the string. Anything the user types is then entered
into the text field. End the edit session when the user clicks
somewhere else.
Make sure the text field appears in precisely the same apparent location as the original non-editable string. If it seems to jump when editing starts, it may irritate users. (This situation doesn't seem like a big deal, but it can be.) Also, retain the same typeface as the original text, if you can. In short, make it as WYSIWYG as possible. Usually a border appears around the text when the editor is invoked, indicating to the user that editing has begun. That may not even be necessary, though. Other cues may suffice: a text-entry cursor should appear (often blinking), and if a common user task is to replace the original string entirely, then the whole original string should be automatically selected when the editor appears. |
Examples: |
|
From Windows Explorer Windows Explorer is where many people see Edit-in-Place for the first time. Explorer isn't an editor, but it established a precedent for how one interacts with Edit-in-Place. Explorer differs from most editors because you invoke Edit-in-Place via a "slow" double-click (not always easy to do, and not recommended), whereas most editors use an ordinary single or double click. But the rest is the same. The previous text is automatically selected, a box is drawn around the text, and a blinking text-entry cursor appears. |
|
From Flickr Flickr isn't an editor either, but it allows users to edit picture titles and descriptions in place. What's interesting about it, from an interaction-design point of view, is how the edit session ends. Most applications end it when the user clicks somewhere else. The Flickr designers decided to make it more explicit: they offer Save and Cancel buttons that appear dynamically along with the text fields. First-time users will have no trouble figuring it out (once they learn they can click on the text in the first place). |
|