Time-consuming "Request - response" steps in desktop application

Question

I prototype OLAP-analytics desktop application, that contains a lot of screens, that generate reports. Common process of such generation is:

1. Users sets up analytics parameters (period, data segment etc. — maybe similar to Google Analytics filters)
2. Application processes data (it can be really time consuming, up to minutes)
3. Application displays table with results (or any other visual representation)

Typically such task is solved like in Google Analytics — user navigates to necessary report type, and sees the table with default report (or any previously generated), that is calculated on the fly, and some filters to change analytics parameters:

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

But the problem in my cases is that generation of ANY report can take up to minutes, and there are no default or previously calculated reports, because the data for analytics go in real-time. Actually, there is no need to display last report, so such layout can have any sense only when the user wants to correct current report content.

So, the solution can be something like a master: user at first selects report type, then enters report parameters, and only then report data are displayed. But I don't see any patterns to make it fine for desktop app, because masters usually are made in modal dialogs, and here such interaction can be rather annoying.

Right now I see such solution, where user sees the report only after manipulations with analytics parameters (don't analyse the form, it is dumb, but the amount of parameters is similar).

^{download bmml source}

But it is rather "web" in approach, and the target window size is Full HD (the reports are huge in details and information), so it seems to be not really effective solution.

So, can you suggest more effective solutions for such "Select report type → Set up parameters → Request system → Wait → View report" scenario in desktop (Windows) app?

Answer 1

I guess you need to store the report request somewhere and "ding" when it's ready.

There's no reason for the users to sit next to your application and wait for it, and they certainly won't do so.

Question is,

• is it possible to do anything else in the application while the report is generated?
• Is it desirable (or at least,survivable) to start multiple reports at once?

If neither of these is desirable, show a modal progress bar indicator and let users focus on other apps. If you can tell them a good guess on when the report will be done, that's better, as they now how much time do they have left: enough to take a quick tour to the toilet, perhaps a cigarette, or even a quick meal?

When we were running long reports - albeit that was more about an hour because of some legacy database issues - we simply sent an e-mail to the user when it was done.

Since yours is a desktop application, you could try to use systray balloons.

A system tray balloon is an effective way of communicating about background processes. On OS X, a similar solution would be to use Growl

Make sure you have audio feedback after the report is done in case the application is in the background. "Ding, your report is done sir/ma'am"

A similar app could be a bittorrent client: You just don't sit there waiting for uTorrent to download the latest release of ubuntu: you start it, switch to other tasks, perhaps watch progress sometimes, but in general, you just wait for the "ding" to acknowledge download.

In case it's possible to run multiple reports, have an "inbox" and an "outbox", labeled Done and In progress respectively. Here the users can cancel the current action or view results.

Make sure you have badges then: number of unread reports, number of reports in progress.

torrents take a few minutes to load and there's little use of a torrent application besides watching as they progress: therefore it shows a badge of torrents in progress, and gives audio feedback and OS notification when a download has finished.

Hope this helps.