More on Response Times and User Perception

Niall Litchfield has some interesting comments on my previous posting about user response time in his blog. I think he's spot on about users expecting batch processes and large report to take a long time, and also that in many cases it also doesn't matter too much for them.

I'd add to that the concept that there are probably two different type of reports being run in data warehouses -- or that there ought to be two types, at any rate.

The first would be standard status reports -- show me all of the items that have been on backorder for more than a month, for example. This is usually a straightforward click or two, and a report pops up in a familiar format. Now for these reports I think that Niall's comments directly apply. They are standard "Monday morning" issues that the user is comfortable in dealing with, and that don't demand a great continuity of attention span that could be broken by a two minute execution time.

However the second class of report is investigative in nature. The user has run his "items on backorder" report and had a sudden "WTF!" moment on realising that there are now over two hundred items valued at more than $5,000 a piece that have been on backorder for 32 days, and he has a meeting with his boss in two hours. Now this is when the attention span issue may become more critical. He starts running ad-hoc reports to discover why this is happening, probing into sales, inventory, supplier business areas, and working on his own thesis to explain the source of the problem. While the reports are running he has a little internal dialogue running in which he thinks of different causes and how to extract the data from the system. This is where instant answers become of value, because in the time between report submission and the return of the result the user has now forgotten what the original question was. Or worse still, someone has popped his head over the cube, seen the user staring blankly at the screen (eyes slightly disposes) and asked him if he needs to put in an order for paperclips this week. * POP * There goes the train of thought.

There's a big sort-of-ironic issue here. The standard reports that the designer has built into the system, and which are therefore most amenable to optimization, are those for which the user can afford to wait. It's those stinkin' ad-hoc reports that cause the problem -- fast response required and only the designer's imagination to predict that they'd ever be submitted.

And I've just thought of a third class of report -- the one the user regularly runs for a meeting or status report, and which he knows is meaningless nonsense, and that he therefore never even bothers to read in any more than the most cursory fashion. But that's another issue, I guess.