Best practices for data file upload error handling

Question

I am currently revisiting a data upload field in our system. These files (csv, xlsx) contain thousands of rows, which can produce hundreds of errors. Currently, the way we handle this is to spit out a monstrous tooltip of each individual error which is far from user friendly.

I have ideas on how I think I want to handle it, but am looking for examples/best practices of rolled up views of such large amounts of errors.

Answer 1

In my experience IDEs have the best UIs for dealing with large amounts of errors unobtrusively. An example of a UI for managing large numbers of errors can be found in XCode.

When I build a project with warnings or errors, it lets me know without throwing up massive dialogs in my face:

They're already classified into warnings or errors so I can ignore them if they're just warnings. They're surfaced in the UI in the same place I normally look for progress/status.

I can drill in to inspect them by clicking on the disclosure icon (so when I click the yellow warning icon above. Doing so opens the errors and warnings pane:

Within this view I can choose to see my errors grouped By Type or By File, and I can also filter them with a live search for keywords:

Clicking on an error takes me to the place that the error was found.

I guess the best practice would be to treat the errors the same as any other information you are designing interactions with. You could roll up the errors into a summary, allow the users to drill down, sort and filter them depending what their requirements are regarding inspection of errors, or you could even hide them away completely if the users aren't ever going to care about them (you can always log them and notify someone about them in the background so that you don't interrupt the user), just as you would with any other information that doesn't have relevance to the interaction at hand.

Answer 2

Show a summary of the upload results and include any errors.

I was faced with this task in one project and the approach that worked for us was to show a summary of the results complete with any errors that occurred. Depending on the task, the user could either back out, make their changes, and try again, or fix the issues with the upload on the system after committing their updates.

Here are some design considerations we thought about.

• Can we fix any errors for the users? Sometimes users could be penalized for formatting we didn't expect.
• Should we commit only the good rows or everything? We thought it would be more work for partial commits since then the user would have to remove the "good" rows from their source file, fix the ones that caused an error, and try again.
• Can we preview the upload for them? This preserves the state of the system and allows the user to choose to ignore errors as needed.

For UI ideas consider the wizard of importing data into SQL Server. There is a step to make adjustments to the data and a preview before committing.

Answer 3

We have a similar situation. We summarize in the UI after file upload with an error alert and a bullet in it for each error type, count, and any helper text.

For example:

• 12 row(s) - Missing {field1}
• 5 row(s) - Duplicate {field2} (must be unique for each {field3})

Now, we're adding a "Download error report" button (final label TBD) to that alert so that users can get more detail, like the exact row/cell that had the issue.

What we're not sure about is if this report should only include rejected line items.