Inline-editing: use one submission button?

[mavcook]

Problem
When using the inline editing features, there is an edit-submit button that appears next to each cell. This can be confusing on first use, because it ends the editing of the entire row, instead of the corresponding cell.

Additionally, the button takes up space per cell even when it isn't displayed, which can be undesirable depending on your styling.

Motivation / Goals
I would like to have the option to display one edit-submit button per row or perhaps for the entire table (see Discussion). I think this would be more clear to the user.

Discussion
Assuming this issue is acceptable to fix, where is a good place to put the edit-submit button? For wide, scrolling tables, a button embedded in the row itself could become hidden, which is not a great user experience either.

• D1 - I am wondering if a "global" submission button for the entire table, that would submit all rows that are currently being edited, would be better than a button per row. I also wonder if that would be better for accessiblity?
• D2 - Above begs the question: why can you edit multiple rows at a time? Is it an unintentional feature? I am wondering if a better use of multiple row edit/selection is a true batch edit: select multiple rows, and edit one row, having its changes mirrored across all selected rows.

---

Would this functionality be reasonable to add, or is there a way to accomplish this with the current feature set?
If there is not a way to currently accomplish this, I am happy to take a stab at implementing it.

[muonw-public]

This can be confusing on first use, because it ends the editing of the entire row, instead of the corresponding cell.

I know this is not your main point, but it's worth mentioning that the problem with submitting edits for a single cell is that as soon as the edit is submitted, the search and filters will reapply and the row you were editing might be filtered out (similar to issue #5)

I would like to have the option to display one edit-submit button per row or perhaps for the entire table

It's possible to optimize the inline editing for a certain use case, but it might make it less ideal for other use cases. It would be best to let the user decide which implementation works best for them. Perhaps your other solution can also address this to some extent by letting the user decide whether to display a submit button for each field.

Implementing a global submit button might not even require changing the code. If you implement this, it would be important to let the user know if there are edits outside of the displayed page that are going to be submitted (could be integrated with a solution for this issue)

I am wondering if a "global" submission button for the entire table, that would submit all rows that are currently being edited, would be better than a button per row.

I am wondering if a better use of multiple row edit/selection is a true batch edit: select multiple rows, and edit one row, having its changes mirrored across all selected rows.

I think the answers to these questions depend on the use case. Does the user occasionally edit some fields here and there, or do they need to copy and past large number of updated vales from a spreadsheet? Do they prefer to submit the changes with keyboard, or do they prefer to use a mouse whenever possible? Do they benefit from entering the same value on multiple fields?

[mavcook]

This can be confusing on first use, because it ends the editing of the entire row, instead of the corresponding cell.

I know this is not your main point, but it's worth mentioning that the problem with submitting edits for a single cell is that as soon as the edit is submitted, the search and filters will reapply and the row you were editing might be filtered out (similar to issue #5)

Oh interesting, I didn't even realize that was an issue, that is a good callout.

I would like to have the option to display one edit-submit button per row or perhaps for the entire table

It's possible to optimize the inline editing for a certain use case, but it might make it less ideal for other use cases. It would be best to let the user decide which implementation works best for them. Perhaps your other solution can also address this to some extent by letting the user decide whether to display a submit button for each field.

Implementing a global submit button might not even require changing the code. If you implement this, it would be important to let the user know if there are edits outside of the displayed page that are going to be submitted (could be integrated with a solution for this issue)

I agree 100%. You bring up an interesting point about #29 being useful here. I will ponder that a bit.

I think the answers to these questions depend on the use case. Does the user occasionally edit some fields here and there, or do they need to copy and past large number of updated vales from a spreadsheet? Do they prefer to submit the changes with keyboard, or do they prefer to use a mouse whenever possible? Do they benefit from entering the same value on multiple fields?

Yeah I would be curious to hear how users are using the editing features, and get some feedback if anyone else cares about this issue. It is a pretty minor and nitpicky issue. I am also fine with just closing this.