Inline table edits: how to make it quick to edit?

Question

I'm dealing with a data table with a large number of columns and rows. Because there are so many columns, I'm thinking of putting in something that scrolls horizontally and vertically while fixing the first column which has the row title. Now the user would like to quickly edit information on this table.

Inline edit seems to be the way to go, but how should this be handled so it's quick for the user to edit info on a line and to edit specific fields?

I've looked at:

Per Row

User clicks anywhere in the row and the entire row is editable. The positioning of the "Save" button seems very far away if user was only editing a single field. The horizontal scrolling of the table also makes it awkward to place the buttons (fixed it to screen?).

Per Cell

User clicks to edit a specific cell. The action buttons are now right beside the field. From hallway tests, people say it's not clear that the grid supports keyboard tabbing to quickly move between fields. This is much more apparent with "per row" edit.

Form Style User clicks on the edit button and an edit form shows up below. I'm not sure this is the right approach though because the user now needs to re-orientate themselves to the fields because of the layout switch. Which may impact speed of editing.

Which approach, or something else is better to support quick row and specific field edits?

Answer 1

Disrupt the flow as little as possible

I agree with you that inline editing is the way to go since it provides context to what the user is currently looking at. I don't like the idea of automatically changing modes when selecting a row since just this can disrupt the user's flow and is more prone to accidental edits.

I would combine your first and last examples making the user explicitly request to edit a row and then replace the edit button with save and cancel buttons. This should help prevent any confusion as to whether changes are saved automatically or not and allow the user to cancel changes made in the row if needed.

Something like this... (it's okay to have the edit link on the left if you need it to be more discoverable)

Answer 2

Addition testing with actual users revealed that some people don't even notice the difference between Per Row vs Per Cell editing. So it may be more of a design preference as oppose to a marked difference in edit speed. Sample size was relatively small though (n=6).

I'm leaning heavily on going with the Per Cell edit option since the action buttons are the closest to the field of interest. It gives the perceived sense of an easier to edit table.

The less apparent discoverability of keyboard actions seems to me like a lesser evil. Tabbing to go to the next field is more of a nice to have for power users. It'a standard enough behaviour that people will stumble onto it with enough usage.

Answer 3

Maybe another option - and I have to admit I don't remember I had nerves to implement it ever (as it brings many technical difficulties), but anyway: if users want to quick edit data in a table, they usually compare your solution to MS Excel (or alike). So, you may consider omitting save & cancel action buttons and just leave them editing data. Saving should be then done automatically after user leaves an editor.

As mentioned, that demands several technical issues to be solved:

• as there is no set of decision buttons (Save and Cancel) a proper undo/redo feature is a must
• if huge amounts of updates are expected, updating in batches might be necessary
• intercepting the event on leaving the editor might be painful on some platforms