The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Introducing "Sleep"

A web application I am in the process of writing is just too efficient. It is spitting good results out immediately. I am wondering if it might be wise to introduce an interstitial (like a loading screen) even whilst one is not having to truly wait to give the illusion that the application is doing something.

Naturally, my inner voice is telling me not to be so stupid, but my doubting voice wonders if users of this application will "doubt it could be right, it was too quick".

Any thoughts? (I know you just love these dilemmas at Christmas!)
Gavin Laking Send private email
Wednesday, December 20, 2006
I recall this sort of thing being suggested decades ago for applications that were sensitive to network load.  The theory was that by introducing appropriate delays at the server, within the network stack, etc. users would get used to a certain response time that was below the maximum possible.  Then when network loads would normally have caused slower and more erratic performance the "slack" would be taken in.

I think the general idea was to avoid network saturation potential in the first place by pacing things at the server.  Of course in those days server capabilities far outstripped the networks, which were often 9600 BPS or slower shared among 5 to 20 clients (terminals) using old-style multipoint protocols.
Wednesday, December 20, 2006
In general, this can be a good idea for four different reasons.

First it can remove the randomness in response times that may confuse or even alarm users for various reasons.

Second, it provides predicability to your application so that the user will learn that s/he can do something else while waiting for the results. It seems that this does not apply to your application, because you write it is too /efficient/.

The third reason is very interesting as it is against our intuition: results that are shown either to fast or to slow decrease the effectiveness of the user. If the results are presented after a few seconds, but within a second or 10, then the user makes her/his own mental model of what the results should look like. Because of this the user catches errors that s/he would not have caught if the results were shown faster or slower. I have read a detailed scientific report on this ergonic issue years ago, but I do not know where. So I do not know the exact duration. Sorry.

Fourth: if your response times are comparable with the competition, it give the user a cosy feeling.
Karel Thönissen Send private email
Wednesday, December 20, 2006
I recall this sort of thing on the dailywtf a while back, something about halving the sleep time and then charging for the 'upgrade'.
I don't know anything about your problem, I'm sure it's a serious issue, it just gave me a chuckle.
Gerry Smith Send private email
Wednesday, December 20, 2006
You're kidding right? Have an option to display more details about the results to verify the depths of the calculation. Google search comes back quicker than its competitors, but there is enough information on the screen that you don't think they cheated.
Wednesday, December 20, 2006
You don’t mention anything about a large range of variability of response, so adding delay adds no predictability. Even if variability were an issue, there are other solutions.

I think the line of research Karel Thönissen is referring to is that users sometimes make more errors when response time is fast (I recall that the Shneiderman & Plaisant has a summary of this work). The explanation Thönissen provides is interesting but seems of limited value. The time it takes to formulate an expectation varies greatly with user expertise and domain difficulty –it could be anywhere from .20 seconds to never. Also, if your users use your app for more than a few times you see in laboratory experiments, you can expect them to get better and faster at formulating expected results as they learn more about the app and how it applies to the domain, so the optimal response time diminishes over time for a given user.

Also, I have an alternative explanation for at least some of the studies: When response is slow, the cost of a user error is high (i.e., must wait a long time *again* for a response), so users are more careful about formulating their input. They may even work it out on paper then transcribe it to the UI. When response is fast, users feel more free to try something and see it if works. If it doesn’t, well, hey, no big loss, let’s try something else. Depending on your situation, you may want to encourage this kind of exploration. Let the user learn the app by using the app which likely provides better feedback than doing something in the head or on paper. Also I think it’s debatable in this context to regard fewer errors *in user input alone* as better performance. In the slow-response condition, users may be making just as many or more errors in their heads as they try determine their input, but these errors are not necessarily captured by the experimental methodology. In reviewing such research you should compare the number of errors across conditions in what the user regards as the final product, and not include errors from “drafts.” You also should only consider studies that provide the user with tangible benefits for minimizing errors.

In summary, listen to your inner voice. Don’t even consider an artificial delays unless you have empirical data that your users don’t trust the results. Even then, explore other ways to handle the issue such as through marketing/education/documentation (e.g., banner on the packaging “New! Super-accurate, and *dang* it’s fast!”).
Michael Zuschlag Send private email
Wednesday, December 20, 2006
I think Michael makes some valuable points. Whatever you do, understand the circumstances and measure the results.

The study I was referring to could very well have been Shneiderman. Perhaps it was in 'Designing the User Interface'.

The points that Micheal makes about methodology are all valid. I think the paper referred to cases where the user had to type a formula of a certain complexity. The problem is neither getting the formula syntactically correct, nor getting the correct result from the machine. The problem is whether the formula is meaningful, i.e. solves the problem at hand. For this reason, search engine queries and the response times of Google do not fall under the experimental results.
Karel Thönissen Send private email
Wednesday, December 20, 2006
Thanks everybody for your input on this. Just to clarify, I wasn't blowing my own trumpet with regards to the application efficiency; it's just it doesn't do much, but what it does do is very useful to the user of the application.

I was more concerned about the user trusting what they've seen. If I ask you 2 indirect questions about the weather then accurately predict what underwear you'll be wearing in 2 weeks then you'd be suprised, and might think I've snooping around your wash pile. Bad analogy I know. Incidently, I haven't.

I also saw that post on the DailyWTF; I think that was running subconsciously!

I don't think I'll add the screen. The competition will have to work harder then to sell their alternative. (Positive Spin!!)

Thanks again
Gavin Laking Send private email
Wednesday, December 20, 2006
You wouldn't happen to be working on a new version of Simcity and wondering if you could include the "reticulating splines...." dialog when generating a new landscape, are you? ;)
Thursday, December 21, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz