- Forms
- Explaining the process
- Community driven
An element of a page, for instance a title, is shown as it would normally appear viewing the page without admin rights. However, once the logged in user has his mouse over the element, its background color is highlighted and a tooltip is shown prompting the user to click the element to edit it. Once the user clicks the element, it is transformed into an input field (text, dropdown, etc.) as well as a save button and a cancel button. Often, the input field matches the styling of the original element. So that if the original element was a header written in size 20pt, the size of the font in the input field would also be 20pt. This styling is made to ensure that the user can connect the original element with the new replaced editable element.
The user can then edit the value of the input field (which is the same as the original elements value) and click save or cancel. If ‘save’ is clicked, the value is saved through and AJAX call to the underlying database, and the view of the element is changed back to the original (for instance the header without the edit input field), but now with the new value. If cancel is clicked, the view element is changed back to the original without any changes that might have been written in the edit input field.
This pattern is often combined with an the AJAX technique, which is an asynchronous call to the server through javascript, that does not require a refresh of the page. There are many javascript libraries out there, that delivers ready-to-use inplace editors.
An in-place editor provides an easy way to let the user edit parts of a page without having to be redirected to an edit page. Instead, the user can just click around on a page an edit the elements he or she wishes to change – without reloading the page.
The pattern is often associated with web 2.0 websites.
Lindsey
28 May, 2008
Very useful! I love this feature in Google docs…I’m able to edit the title of a document without leaving the page or dealing with a popup window. One of the best UI developments I’ve seen recently.
Peter
15 Aug, 2008
I would add a bullet to the usage list:
I.e. – the text that can be edited shouldn’t contain verbs (links, actions), only information. If the texts on the page are intermixed information and verbs, than do not use inline editing. This is based on maintaining a clear distinction between usage and administration.
syed sabir
24 Sep, 2010
This type feature is available in meebo too…
Jay K
26 Oct, 2010
The affordance that Google Contacts (consumer edition, not the enterprise edition) gives upon mouseover — displaying an input box around the text — is much clearer to my mind than a simple highlight. I think this will become more and more popular.
Jocelyn
9 Jul, 2012
How does this pattern work for users who without a mouse? For example, how does someone using a screenreader get access to edit capability?
jigs
2 Aug, 2012
Ideally, these in-place editors are considered to be part of Form.
And as per guidelines, you should be able to navigate to a form element through use of tabs
rakesh
2 Aug, 2012
Hi , We are developing a website which has user-profile
This user-profile page contains around 20+
in-place editors for various fields like email-id, phone-number , etc
Does it makes sense to use in-place editor when your page has so many editable fields?