Inline editing or modal popup

Question

I'm interested to know what would be best the option from a UX perspective. I have a table in which I need to decide if I should edit each row with inline editing where you can click on each item in the row and edit separately, or all at once with a modal popup.

Answer 1

In-line, and here is why. When you separate the user from what they are doing in a pop up, they lose the connections of items, their detail, and placement. It takes them a few moments to re-orientate themselves.

When a user is separated from the product they take a moment to re-connect all those bits of information in their head and then start.

With in-line editing it is very straight forward.

Answer 2

Adam, that's a great question. However, you are not limited to just 2 options here - inline and popup window. The third option is to have a page to edit/create a record, and also combination of inline+page/popup.

1. Inline - is the most limited UI solution, and you have to think about how many fields the record contains. If it's up to 6 fields, inline is ok. Otherwise you will have to have both inline for couple of fields and full editing of the whole records. In addition, you should consider the amount of data to be edited - normally inline editing is done for records that are appox. 255 chars long. If it's a big text - inline is not a good approach. You should also consider where the validation messages will be placed.
2. Popup - if the record you are editing is not really complex, does not have big texts, and does not imply calling another popup inside (2 popups is considered bad practice) - then a popup will work.
3. Page - there are almost no limitation when you have a page to edit a record. You can have big texts, popups to set field values, there is no problem with placing validation messages.
4. Inline+popup/page - in this case you allow to edit some of the fields inline, other fields are edited in a separate page/popup window.

Answer 3

While inline is preferred, I'd add that it really depends on the type of application and user task.

In my experience, bulk edits are very important for enterprise applications and this is where it helps to get the user to multi-select items and then perform a bulk action. Inline in this case becomes very limiting because it doesn't make repeatable edits easy.

So some questions to consider would be- how big is the table? Is there pagination? different views? What actions would the user most likely and most frequently have to perform on the table data? Are such tables used to present data in other areas of your product?

Answer 4

I like Jon's answer a lot.

There is another aspect to be considered - multi-record editing. Clearly, if you want to allow the user to edit multiple records at the same time, the inline method does not work. Consider iTunes, or some other (better) music ID3 tag editor. Sometimes you need to correct the name of a song - inline editing is perfect for that (though you do have the challenge of disambiguating between a click to select the record, a click to play the track, and a click to edit the specific field). Sometimes, you want to select all the tracks in an album and change the genre. For this it's nice to multi-select the rows and then invoke an editor dialog (CMD+I does it in iTunes) where you can then fill in one or multiple fields and only those fields will then be updated for the entire record. (iTunes' implementation of this, while functional, is not immediately intuitive).

From the perspective of the developer, if you have a limited amount of time and can only implement one input method, you need to consider whether you're going to launch with multi-record editing enabled or not. If you will, then opt for the dialog: you take a bit of a usability and performance hit, but you can save yourself a ton of time coding.

I hate to say this, but if we're just sticking to those two ways of handling input, your best bet is to implement them both, and find an intuitive way (better than itunes at any rate) to allow the user to enter into inline editing mode (Microsoft's F2 is the pits too, though at least they're fairly consistent about it), and for the user to enter into multi-record mode.

One last thing to consider: for inline editing to work, you need to have visibility into all fields of the record in your tabular display. If you're allowing your users to hide columns, or are only choosing to show a subset of the editable fields, you have no choice but to implement some kind of editable "detail view".

Answer 5

If you are dealing with an enterprise app with transactional data that many people can modify at once then I would go for modal and have a submit button even if in-line seems more natural for those working on single user apps such as Excel.

The fact that it shifts the context out from the table is a way for the user to start thinking in edit mode and whatever fields that are marked as editable are editable rather than guessing if a table cell is editable or not.

Secondly by making it modal and have a submit button, you can do one really important check: has the record been modified by someone else while you were making changes? Albeit it is annoying when that happens it is much better than not knowing and presuming your data went through. Although it is also true that a "toast" can be shown to the user notifying them of the change after the fact the hassle could be higher.

Mind you this context is only for editing. Searches on the other hand should be inline unless it's a really weird complex query with a lot of fields.

Answer 6

I am inclined to say, why not both?

I can think of two scenarios where each of the approaches makes sense.

Approach 1: Inline

Assuming you need to update a small number of cells in a grid where the total number of columns is fairly less. You could just work like Excel and keep updating. In this approach, you need to consider the problem highlighted by Archimedes Trajano. Simultaneous updates can be an issue for everyone involved.

Approach 2: Modal Popup

Creating a new record, or changing many fields of a record when the total columns are large in numbers. Then it makes sense to open a modal popup and let the user quickly edit/enter values. This will be helpful because the user will know where exactly each field is and can quickly update them. The data integrity issue is less prominent.

In both of the approaches, multiple edits can be achieved with little innovative ways.