Editing data on forms

Blast from the #PatternPast! This article was formerly located on our old WordPress blog. It was originally written by Matt Carrano and published on April 21, 2017.

In designing enterprise applications, we very often encounter situations where the user needs to edit existing information. In many cases this editing is done in the context of a form where users can make and commit changes. You may sometime need to apply role-based access to enable editing for authorized users, only. How should you accomplish this using components available through PatternFly? This post identifies some common use cases for form based editing and potential design approaches.

Common patterns

There are at least three approaches to editing that are commonly found. Each of these has advantages and disadvantages so the right approach may be dependent on context. Understanding the tradeoffs involved will lead to better decisions about editor design. To illustrate these approaches, I will use a simple use case that’s easy to understand. Let’s consider that an application has a database of users and I, as an administrator, want to edit the credentials of a selected user. What are some potential approaches that can be taken?

First, let’s suppose our high-level view of users is presented in a list view that looks something like this:

If I want to edit the details of one or more of these users. How should I proceed?

Pattern A — Drill down to edit details

A simple approach is to open each user record in a separate editable form. The editable form can be contained in a modal dialog or as a full-page drill down. The user makes the required edit and clicks Save to commit them back to the user database.

Or if modals aren’t for you, the same pattern can be accomplished by substituting a full page view for the modal dialog.

Advantages

This approach is clear and straight forward. Users are clearly presented with editable information, can make their changes, and can click Save when done. If using a modal approach, users are focused on the task at hand and cannot navigate away without saving or cancelling changes. Role-based access control is easily accomplished by preventing unauthorized users from clicking Edit.

Disadvantages

The drill-down approach requires an extra navigation step to edit the details of an object. It also does not allow these details to be exposed to some users in a read-only mode. This may be a problem if there are details that should be viewable to all but cannot be represented on the parent view.

Pattern B — Toggle between view and edit modes

One way to allow read-only access for some users and full editing privileges to others is to support drill-down to details and then require an additional step to enable editing.

The Edit button placed in the header of the page gives the user the option to turn the page into an editable form. Access can be denied to some users by disabling or hiding the edit control. After the user has made their edits, they can commit their changes by clicking Save or click Cancel to discard changes and return to the read-only mode.

Advantages

This approach allows the same page to be used for viewing as well as editing details. Access to edit mode can be controlled via the Edit button.

Disadvantages

Switching between read-only and edit modes will require a page refresh. Depending on the content on a page, it may be necessary for layout to change significantly when switching between modes. This has the potential to disorient users as elements change position.

Pattern C — In-line edit on a form

Like in Approach B, the details are presented in a read-only page view. When users want to edit a specific element, they can put that element directly into an editable mode, make their changes, and save them. They can make multiple edits on the same page in this way.

Advantages

This approach does not require a page refresh and only one element is made editable at a time. This works well when only a few elements are likely to be edited at a given time. If validation needs to be performed in the back-end, inline editing will provide more immediate feedback since each change is submitted separately.

Disadvantages

This method will become tedious if many items will be edited on the page due to the additional clicks required and the potential turn around time after each change is submitted. Making this behavior clearly visible can also be challenging. A small icon or other signifier can be added adjacent to editable fields, however this may add clutter to the form.

Conclusions

While there is not a one size fits all approach to editing data on forms, there are some high-level guidelines that we can apply in most cases:

• In most cases drill down from some content view (Card, List or Table view) into a separate edit page should be your default approach. This may be accomplished using either a standard modal dialog or on an edit page with appropriate submit buttons.
• Toggling between view and edit modes on the same form is useful when you want to show the details to all users, but only some can edit.
• In-line editing is a very efficient approach when users are likely to edit only a single parameter at a time.

What’s your take on this? I welcome other approaches that I have not covered here and you can expect to see these guidelines on the PatternFly site in the near future.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.