Is it ok to force a user to reenter data instead of editing existing

Question

Is it acceptable to force users to delete and recreate data they entered incorrectly or should they be provided with a way to edit every instance of that particular data?

---

Use Case:

The wireframe below illustrates the workflow we are currently discussing internally. Because of technical requirements users must enter a modal to enter information and on completion they are sent back to the page with the new data appearing at the bottom of the table. There is no case where the user would have to fill out more than three fields, and in many cased users would only have to fill out the first two.

The re-enter scenario arises if they made a mistake in an entry - they'd have to delete the entry then create a new entry, instead of editing the existing entry.

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

Answer 1

If the field has no meaning when not correct, or where you shouldn't store the data, then it's fair to clear it. Examples are password confirmation fields or dates that are impossible.

If however the field includes information that could plausibly be edited to correct (such as a phone number) it is best to keep the data in the field and allow your customers to edit it in place.

One thing that you should definitely not do is clear all the fields if one field fails validation. Occasionally I've seen this when submitting a form with captcha, and it has always proved incredibly frustrating.

Answer 2

It depends.

Let me explain.

For example, there is a table with dates and pay info like in your app. And users have to fill it and sometimes they need to change the data entered by a mistake or something. From the first sight you may think it will be great to give user an ability to edit the data inplace, but...

There is another kind of users of your system, people who sit at the other side of it: managers or whatever. And these people should process that data. And everything is OK until a moment somebody want to modify the old data.

So, here is the problem: the data goes the way that managers could pick it one by one from the top of the queue. And what happens with the modified data? Should it pop up at the top (and change it's order or return back later, etc) or just be highlighted somehow (so, how managers fill catch this and proceed), etc?

The one solution will be to not let users to edit the data, but let them remove it and then place a new row which will pop up at the managers side (so, the queue will be the same, etc).

I mean, this is a kind of imagined scenario, an illustration, but I know there are a lot of systems which will not allow you to edit your data but to remove and add instead (twitter). And that's just a trade-offs we have to do to keep our systems useful, usable and simple to all kinds of users. So, answering your question, I think that actually it depends.

In your case I believe you may let your users to edit dates inplace by showing a datepicker right near the cell, etc.

Answer 3

I have two general situations in a web app I'm working on, where the user has to add rows of data in a table. In the first case: When the user press the add button, a new row is added to the table, allowing him to enter new data in place (usually many fields), and edit it again when needed (without pressing an edit button). When the user have checked all the data he can press a save button, which then saves the whole table. In that case I prefer that the adding and edits were done in place.

In the second case, I have a table where is expected that every rows is saved in database one by one: the user clicks add, fills the form and press save, then clicks add again if needed, etc. In that case, when the user has to add a new row or edit an existent one, I show him a modal form with all the fields (usually less than 10).

Since in your case there are only three fields I think that it would be acceptable to ask the user to delete the data row and add it again: that is because the benefit for allowing the user to edit may not worth the additional codding needed in order to allow the update of the data.

But, if you are going to use more than one modal dialog in order to enter data in another forms of your app, then you should also consider that is generally encouraged to do it in the same fashion along different forms, so users feel that all forms are consistent.

Answer 4

Why not have an "edit" button next to the "delete" button?

Pressing the "edit" button for a particular row could bring up the modal containing the data as entered, and then the user just makes modification as necessary, then saves, as per a new entry. Seems the most flexible approach, and it doesn't require any other means of data entry than you already have (i.e. modal window).

PS - I would suggest "save" rather than "saved" for the modal window button. "Saved" is past tense (or an adjective?), but the data isn't saved until the button is used (i.e. the desired action – or verb – is "save").