My users will work on data grids bounded to list of entities. CRUD operations can be done directly in the data grid (inline editing) or in a popups (user will click in the grid toolbar on "create" or "edit" buttons).

Which of these 2 ways is considered better UX nowadays? Is there a 3rd way which is better than these 2?

  • 1
    You mean UI in this context, not UX. UI is a small part of UX. – Stewart Dean Mar 9 '14 at 16:35
  • I don't think anyone will be able to provide the better answer. We can list all the alternatives, which is helpful, but that is as far as anyone can go. Please consider editing your title/question. – givanse Mar 10 '14 at 14:06

There is no definite answer for this.

From both usability and implementation perspective, the two are rather different; and they fall into record-editing strategies. Records can be presented in a tabular form, but events on a calendar are also considered records.

Essentially, the decision boils down to a few main factors:

  • How complicated the record is:
    • Amount of fields
    • Validation complexity
  • How often users need a quick way of editing specific fields?
  • Would users benefit from seeing other records on screen, while editing a record?

You have, in principle, 3 leading patterns:

The modal dialog

An image showing a modal dialog form

When the user wish to edit a record a model dialog is shown. There are a few advantages to this pattern:

  • It implements dead-end navigation. Meaning users can't navigate anywhere other than back to where they came from by pressing Save or Cancel to exit the dialog. This type of navigation is very intuitive and clear, where users shall be clear about what will happen (unlike with some other solution).
  • It allows Cancel option.
  • It allows a delete guard - to prevent accidental deletes, many interfaces put the delete button deep in the interaction hierarchy. A dialog allows to 'burry' the delete button within the dialog, ensuring users have to click at least once in order to request the delete of a record.
  • The fact we are using a dialog means there's more display space, which helps:
    • to present help text
    • cluster the data into headings
    • present validation errors in a clearer manner
  • It is allows one-to-many data manipulation. Say a record can have multiple attachments - the fact we are showing a window allows the editing of these.
  • Programmatically this type of pattern is easy to implement - when the user create a new record, it is only created on the client side, and only sent to the server upon Save. With other solutions the implementation is a bit more complex.

Note that a variation of this pattern is a dead-end page. Meaning we do not present an overlay dialog, but navigate aways to a page where you (in principle) can only perform Save or Cancel. This is how Google implements event editing:

An images showing the event edit page on Google Calander

One thing to consider about this pattern, is that it can get somewhat cumbersome if we have to navigate to another form. For instance, if one of the record fields is customer and you wish to provide an ability to add customer, which requires to show additional form. In general, a modal from a modal is not a great idea. And the most elegant solution to it is the implementation of the hub-and-spoke pattern in a mobile-interaction fashion.

In-place field editors

An image showing fields being edited on an ExtJs grid using in-place editor

The advantage here is that it is quick - users can simply click and edit a field, without navigating away from the view.

There are a few complexities though:

  • How exactly we know the user has finished editing the field? Mostly this is achieved via OnBlur event, but what if the user clicks a nav item while the editor is still open?
  • How do we signify to the user that the change has been persisted to the server (database). Once done editing, a request is sent to the server and the server will return with success or failure. ExtJS, marks the field with a small red triangle on the left-top corner, and when the server returns success the triangle disappear. A further complication is the case when a field has been edited, but the user has navigated away from the screen before the server returns.
  • How do you provide success/fail feedback for data that is no longer on screen (and programmatically you have to account for this, or you'll get an error).
  • Displaying validation errors may be a bit less straight forward in this case (specifically as some validation happens on the server - consider session timeout, for instance).
  • Programmatically, when the user clicks Create you would normally send a new record request to the server, getting back a new ID, then populating the table with the new record that can be edited.

Compare these to the advantages of the modal dialog, and you'll see that many are not supported by the in-place pattern. For instance, there's no cancel option.

Another thing to consider (particularly with this pattern, but also with the model dialog one) is that table sort and pagination can mess up things big time - if the table is sorted alphabetically by a person's name, and the user views entries around the letter Z, and then enter a new user whose name is 'Adam', what happens?

In-place record editors

An image showing a full record in-place editor on an ExtJs grid record

This has the efficiency (speed) advantage of in-place field editors, but allowing Save and Cancel operation. So essentially, a type of marriage between in-place editors and mini-form.

There are some interaction issues with them, like what happens if neither Save or Cancel are pressed but the user clicks on a navigation item or another records?

Edit mode with inspector panes

An image showing an inspector pane with an edit button at the bottom

An image showing an inspector pane after edit was pressed - with both save and cancel options

Inspectors is the modern name to property editors - a section on the screen showing the selected record data in a form. The form will be in view mode, unless the user clicks Edit, the data can be edited, until the user clicks either Save or Cancel.

The key problem with this pattern is that there are many interaction opportunities on screen while the record is in edit mode - users may forget to press save.

It has many of the advantages of the modal dialog pattern, yet users can see other records while editing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.