I have a problem deciding what the user is expecting from the app when using the export functionality.

I have a web app which allows the user to export data from a grid, either one row at the time or by selecting multiple/all rows. The data that would be exported may be very large as we display only some fields in this step. As an example, an export could last ~1 minute as it builds an excel of ~500 pages.

  • v1. Block the UI so the user is not able to do anything until the export is done.
  • v2. Do the export in a separate tab and let the user continue using the app.

For v1 the inconvenient is that the user could be annoyed because he has to wait.

For v2 there is the risk of having inconsistent data due to the fact that giving the control to the user, he could alter some data that is going to be exported.

  • 1
    I'd certainly lock any data that is currently being exported. You don't want half changed data, as there could be broken relationships etc. Perhaps give the user more feedback about what is being done so that it is less boring? – VoronoiPotato Jan 27 '14 at 15:08
  • 1
    So you suggest combining the 2: block the data but not the entire UI, letting the user to use the app, but in the same time inform him the data is locked? – lucian Jan 27 '14 at 15:18
  • That would certainly be an option, so read only use. – VoronoiPotato Jan 27 '14 at 16:19

(If the export is taking a minute or more, I would consider analyzing whether the method used to build the file is inefficient. This may be a good topic for you or one of your engineers to cross-post on Stack Overflow.)

The export should contain the most-current content from the data set. I would implement a step in export: When they click [Start], perform an action to estimate the size (and time to export), then alert them if it will be greater than X seconds (test to optimization there). In this way, let the user know that it's going to take a while.

Then, lock the screen during the export.

In both the alert and during the export, give the user an option to abort. They may determine that they're trying to export too much and want to further refine their data, reducing the load on your system.

In either case, alerting them to the time it will take manages their expectation of the interaction, while also mitigating the issue of them updating anything or them navigating away and potentially interrupting the export action.

  • @Zhouzi, I like the thought behind progress indicators, but it's a complicated topic in its own right. I think we can leave it for other questions that have been asked previously, if you don't mind. – Matt Jan 27 '14 at 16:41

When export is time consuming, it often is the output generation processing that takes time and not the data selection. You may be able to break the process into two steps:

  1. Snapshot the data: the system could quickly (order of 100ms) gather a consistent snapshot of the report data into temporary tables. You can then let user proceed.
  2. Generate the output: in a background process build the file required, then remove the temporary data.

When file is ready can offer download in UI, but since it is an export file could initially offer to leave the file in DropBox / Google Drive, or email it to the user. These would be naturally asynchronous operations.

FYI Nielsen has 10 seconds as upper limit of acceptable delay for an non-disruptive task.

  • 1
    Very nice solution, thanks for your time. If I could I would have accepted both answers – lucian Jan 28 '14 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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