Should browser/client drive the bulk operations?

Question

Currently I am working on developing a web UI. Backend API is supporting individual delete on resources. Users would like to do a bulk delete (say hundreds of resources). If bulk delete need to be implemented, which is good design that will have better user experience?

1) Implement Bulk delete API, which is going to take in number of resource ids and return with status url. Browser can do a GET on status api and show the progress bar in UI.

2) Bulk delete driven from Client/browser, where requests are sent in async fashion. As we have success response we show the progress. But UI is blocked and user cannot navigate until the operation is complete.

Answer 1

Neither of those option sound like an ideal experience for the user.

A couple things to consider: You can't prevent a user from navigating. If they don't want to wait, users can just leave, refresh the page, etc. (Expect users to be impatient and circumvent your controls.)

If you develop this as a SPA (Single Page Application) you can allow the user to keep interacting with the app while asynchronous calls are in progress. Since you will still be on the same page, any callbacks will function as expected. You'll just need to make sure the design of all the screen states (a.k.a the "psuedo pages" of the SPA) accommodates the display of the messaging for the asynchronous functionality.

On the screen, reserve an area for displaying the status of the bulk process (perhaps pegged to the bottom, example below). When it completes, change the message, and add a close button.

One additional note: You could allow a few more of these messages to "stack." But that's a little beyond the scope of your question.

Answer 2

The last option would be the more user friendly. By not being able to touch other actions while one is processing, you are also able to block the user from sending too many requests without thinking on the outcome but just for trying the result.

Async isn’t synonymous of slow, you can in the future make the client browser side to deal with this by allowing the user still use the site while an actions is being processed by the server, which is what probably is more ideal in your situation. So by keeping one action happening in a part of the page that doesn’t obscure you sites functionality.

Without knowing exactly what your trying to apply to, it’s a mere guess to try and give you an answer. But i most ‘fast speed user experiences’ this is what is more common to happen to prevent user errors as well.

Answer 3

From a user perspective, the user has no idea that they have just tied up a massive amount of resources on the server by doing a bulk delete, and nor do they particularly care.

So I would go for running the delete in the background, and allowing them to continue to navigate.

Before carrying out their instruction to delete everything, I would also ask "are you sure?"

Depending on the number of resources to be deleted, I would show them a list or a summary of what they are about to delete (e.g. "You are about to delete all your data" but specifying what type of data it is, e.g. blogposts).