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

  • Are the technical requirements (which are the reason for the modal) also the reason why saved entries cannot be edited?
    – Erics
    Commented Dec 22, 2012 at 8:50
  • The technical requirements for the modal are because we are forced to develop on top of an older web app framework. The modal is replacing in row editing/adding/deleting.
    – JeffH
    Commented Dec 22, 2012 at 13:18
  • Does this technical requirement prevent you from offering an edit option?
    – Erics
    Commented Dec 22, 2012 at 15:10
  • As the wireframe above shows our framework allows us to use modals or even create a separate edit page if we wanted. We are just unable to create inline editing for items on the fly.
    – JeffH
    Commented Dec 23, 2012 at 16:14

4 Answers 4


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.


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.

  • 1
    A common example are accountancy systems - if there's some reason why an entered amount is not right then the user has to enter a journal correction.
    – Erics
    Commented Dec 22, 2012 at 8:54

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.


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").

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.