6

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 enter image description here

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 enter image description here

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 enter image description here 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?

  • Have you looked at old questions? I have a feeling this has been asked and answered at least once. – dnbrv Feb 11 '15 at 19:57
  • Hmmmm, I saw some questions about inline vs section edit for regular inputs but I couldn't find anything relating to speed of entry for tabular data. If you know of something and can point me to it that'll be great. – nightning Feb 11 '15 at 20:04
  • 1
  • Thanks for linking them for me @dnbrv The first Inline editing link I saw before, it didn't have what I need when dealing with table editing though. Section edit is like Table Row Edit but run into issues with the position of the save button being very far due to the size of the table. First time I've seen the 2nd question. Got some great tips on table design in there, but nothing with regards to editing speed. – nightning Feb 11 '15 at 20:59
2

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)

inline edit

0

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.

0

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
  • Yes. This is ultimately the experience the users are looking for. However, for my current use case, due to complexity of the data where the state of some fields are dependent on others, it takes quite a lot of effort to track all state changes to effectively handle undo/redo. Error handling is also quite messy. We just don't have the budget to deal with this. – nightning Aug 21 '15 at 19:14

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.