Updating page information - Inline vs selecting edit

Question

I am redesigning an app from scratch, and have a little dilemma on the UX behind updating page information/editing page information.

The information can range from profile settings to user pages to program pages. In the end I am looking to define a paradigm that can be used consistently on all pages.

Choices:

1. Separate View and Edit Page I certainly don't want to do a separate View & Update page where a user selects update, then is taken to an "update page" makes the edits, hits save and then is taken back to the view page.

2. Inline editing Where you click or double-click the field you want to change, change the information and hit enter to save.

3. View/Update hybrid page Where you use 1 page, hit edit, that page turns into the edit mode, make your edits and hit save.

I'm leaning toward the 3rd option, because the UX is easy for the user to understand. Select edit, make your edits, then save your edits.

I'm wondering if anyone knows of a better way to handle editing of page information? Or if what I am thinking is a good paradigm.

Answer 1

• Choose option 1 if the site includes 'easy' data. For example simple text, a comment, or anything public

• Choose option 3 if you don't want user to modify page elements accidentially. For example in an accounting program I would definitely use option 3, but in a simple notepad app (especially on mobile), would definitely choose option 1.

Answer 2

What's stopping you having just an edit page?

The page is displayed and the user can change any value they're allowed to - all text boxes are enabled. To save the changes the user hits the "Save" icon.

If they navigate away all changes are discarded, though you might want to consider a message along the lines of:

There are unsaved changes. Do you wish to save now?

This means that if the user thought that they just wanted to view the data but now realise they want to edit it, they don't have to do anything special to get into edit mode.

The main drawback with this is that they could change something inadvertently, and even though "Save" is an explicit action still hit that accidentally as well. If the data is "sensitive" in any way then having an explicit "go into edit mode" button is actually a good idea.

Answer 3

I provided this same response in another similar thread, but it is relevant here as well.

I think there are three big rules that must be taken in to account when identifying the best view/edit paradigm:

1. I want the information to be easy to read (Summary/Print view without edit clutter)
2. I want to prevent unwanted mistakes on important data
3. I want to quickly and easily edit the information

The UX solution for View/Edit may be different depending on which of the three above is the highest priority, as there is always a balance between easy editing and preventing screw ups. Some say it is better to make it difficult for users to edit data to prevent them from making mistakes. However, if a user has been given the permissions to edit the data in the first place, you must presume that said user has the intelligence and expertise to be entrusted with making changes to that data: Making something difficult to do is never a proper UX solution.

I personally like the technique used where the information is presented in a "View" state until a user hovers over an input. Then, an input bounding box is revealed, which shows the user that the information is editable. ON click, the cursor is placed inside the input, allowing the user to modify or enter data. Lastly, when the user exits focus and leaves the page, a confirmation message is presented showing the user the change that was made, allowing them to confirm or delete the change(s).

This solves all three big rules, while sacrificing none of them: The data is easy to view/read. The data is easy to edit (onfocus/onclick) and unwarranted changes are prevented (confirmation message).

Hope this helps,

Mike DeJonge Director of User Experience and Design, The Trade Desk

Answer 4

I'm responding to @ChrisF's point.

I think that a reason to list out all of the users's information (instead of showing the editable fields) off the bat would be if it's more important for the user to see the information lumped together, and there's a lot of information/sections on the page that they would have to quickly navigate through.

For example, let's say the settings page shows:

• my name
• billing address
• phone number
• cc number
• personal clothing sizes (tops, bottoms, dresses, skirts, shoes, etc)
• delivery address and options
• other opt in info

I think having all those text fields/dropdowns/radiobuttons/checkboxes/directions could be overwhelming for the user. In that case, I'd prefer to see the information clumped together, printed on the screen, with an edit button for each section. Clicking "edit" would enable the appropriate form fields for editing.

I suppose it's a question of ease of edibility (give 'em the form upfront) or ease of reading info (make 'em reveal the form).

---

I'm chewing on this issue right now. :)