If I start editing one table cell without saving changes to another cell, should it apply my unsaved changes?

Question

I have some table and adding row. You can add elements to the table by typing something and clicking on Add.

Every data item can be edited. Now i want to add something and i type in input "Ite" (look picture below), than i remember i have to edit "Item 2", so i click Edit on Item 2.

In this case is it better for UX to delete input (Ite) or just leave it?

If i edit Item 2 and click OK or check, than i can go back to finish my input. Or is it better when i edit other element, text in input is deleted. I think it is better to leave text in input.

Answer 1

The essence, as I see it, is: if the user is part-way through editing (including adding) one entry, and attempts to edit (or add) another entry, then what should happen to the first entry? I see three options:

1. Commit the current state. Update/save the entry with whatever the current contents are.

2. Discard the current state. For an edit, this would mean reverting to the previous name/text; for an "Add", it would mean discarding the partially created entry.

3. Remain editing. Leave the entry "mid-edit" so that the user can come back to it when they've finished dealing with the interruption.

There is probably no one "right" answer: some factors that may help you decide:

• The commit behaviour is essentially what Windows Explorer does. If you start to edit the name of a file, and part-way through click on another entry (or switch the focus away) it will commit the current state of the edit as the new name (providing it doesn't clash with an existing name). In the case of a new entry (e.g. "New folder"), the new item will be created.

  Many users will be familiar with this behaviour (even if some find it occasionally annoying), so that's a potential reason for choosing it.

• I'm finding it hard to think of a good reason for the discard behaviour... the best I can do is if you create a new item but don't finish giving it a new name, it keeps things tidy. There should, ideally, be a way of discarding changes to a partially edited item, but I don't think selecting a different object should be that way.

  This behaviour would be particularly annoying if a user accidentally clicked away from the item they were editing and lost all their changes.

• The remain editing option is not common (probably because there is more work for the software in tracking the states of multiple "being edited" items) but allows the greatest freedom to the user – if while editing one item, they realise the need to edit another (perhaps a dependent edit¹), they can do so and return to the original edit without losing (and having to re-enter) any changes.

  There are, however, costs to providing a "multi-edit" capability:

  • Extra complexity to maintain the current state of multiple items.

  • At some point, the user will do something that will require all pending edits to be committed (or discarded). An intuitive way of handling this would need to be devised (at a minimum, probably involving three options: commit all; discard all; and the ability to cancel/postpone the "triggering action" so the user can manually commit/discard/finish editing all pending items).

  • In some situations, having multiple items "in the process of being edited" could become more confusing to users that the benefits gained.

Overall, "commit" seems to be the most common, probably because it is easy to implement. Most of the time, it is adequate, though there have been frequent situations when I would have liked a "remain editing" / "multi-edit" ability. Whether the extra complexity justifies the freedom will be a case-by-case decision. Discarding a partial add/edit would, in my opinion, nearly always be the wrong thing to do.

---

¹ One example of a dependent edit would be: you are in the process of renaming a file (e.g. NewData) when you realise the target name (e.g. CurrentData) already exists. With the ability to "remain editing" the user can rename the existing file to some other name (perhaps to maintain an archive of old files, e.g. OldData-Jan, OldData-Feb etc.) and then save the changes to the original rename. Without this ability, they would have to cancel the first rename operation, rename the clashing file, then re-rename the original file.

Answer 2

Keep it. You are offering the possibility to edit multiple items at once, so you should do exactly that.

Unless the user tells you to clear input or reset it, don’t. (Consider what an action would be named if you did: Clear-input-and-switch-to-editing-other-item? Should that go on a button?)

Answer 3

There's a scenario that I don't think you've considered here: I'm halfway through writing in the title of the new field I want to create when I remember that I need to edit one of the other fields first. I go and edit the other field then come back to resume creating my new field. - what happens there?

The alternative is to find a new way of adding a field. I've seen a lot of forms that work like this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

this avoids the whole area of having a new field open while editing another.

Although you will also need some way of removing fields (delete button + sanity check)

Answer 4

Whether it'll be visible to the user or not (giving up on new element addition and choosing an item to edit), keeping the information which is entered by user as an input worth to keep.

I don't know if you're aware of the SE environment's question/answer/comment editors but, it really make me feeling good to see what I already typed whenever I open it on another page, media or device.