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:
Commit the current state. Update/save the entry with whatever the current contents are.
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.
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 edit1), 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.
1 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.