Good content is sometimes not enough, the users must reach it so they can see it's good!

Edit in place

Posted: April 13th, 2009 | Author: | Filed under: Good practices, Patterns | Tags: , , | No Comments »

Since the AJAX and web 2.0 madness a new edit option appeared on the web (used for many years in desktop software though): “edit in place” or “inline editing”. It’s basically used to edit a thing and one thing only, a “one field form” if you like.

It’s not for computer naive users and it’s better to avoid it for simple applications if it’s not really obvious how to use it.

There are two distinct parts of this action: triggering the apparition of the field and the submitting of the action.

Triggering the field can be done in a few ways:
holding the mouse cursor on the text to be edited (the same as the desktop way) – simple but not obvious, you can’t know about this feature without reading the help or a proper training. (For example see the IPB (invision power board)). I don’t recommend this method for the web, it’s not intuitive enough.


clicking the text – hovering the text, the background of the text becomes yellow – a convention that nowadays seems to mean “click me, something will happen”. Used by Yahoo, Google, WordPress etc it’s a convention that is becoming a standard. Though it’s better than the previous one, it can be done better.


right click on element shows a menu with edit/rename option. Again, the user is not used to right click on things on the web, maybe on pictures to download them but that’s about it. Cool but not usable enough. See the Google Docs example:


just showing an edit button is the best solution i ever saw, straight forward. If the aesthetics don’t allow that, show the edit button/link only when hovering, but keep the yellow background on the text all the time. WordPress admin does a good job with the post slug editing:


The field must appear in the same place the text is before triggering the edit. Jenifer Tidwell says in her book “Designing Interfaces” that the field must be set only as a border on the text to be edited, the position/font/color of the text should not be changed. Although it’s a very good point, it’s hardly possible to achieve this technically when working with dynamic text and user generated content.


Some people choose to select all the text inside (like in windows explorer) to make the text replacing faster, but it’s very easy to delete the text and many users won’t know how to recover from this (it’s important that on click outside the field the action is canceled and the initial text restored).


Submitting the form is easy, either you insert a “save” button, or let the user hit “enter” (IPB for example). I prefer and recommend the first one, but make sure it works with “enter” too. A very good idea is to provide a “Cancel” button, it gives the user self confidence.

UPDATE: a few examples on quince.