Multithreading a User
Programmers spend lots of time writing multithreaded applications that can get work done while the user is thinking, or reading, or whatnot. We know, almost instinctively, how to make the program fast. But we often don’t think about making the user fast. Why?
Well, the first reason is that computer science classes often say “Waiting for I/O is slow;” and leave it at that. The implied conclusion is that the program should be doing real work while it waits for the user to decide what to do. Often this makes sense, because a person thinks on the order of 100 milliseconds or so, and a PC can compute millions of instructions during this time.
But let’s use a real world example here: try depositing a check at an average ATM. Here is how it works:
- Click deposit
- Click check
- Insert check
- Confirm check amount
- Click confirm deposit
- Click receipt yes or no
In between each of these steps, the ATM has to contact the server to get approval from the bank to proceed. This means each page takes 300ms round trip, then 150-250ms for me to make my choice, then another 300ms for the next page to load. The end result is glacial.
Contrast this to Amazon’s checkout page. You click checkout, and Amazon selects all your default choices and presents you with a confirmation screen. If you want to edit anything, you click on the “Change This” button by each section. The end result is that an order is easy.
Why does this work so much better? There are a few principles at play.
- Show the user all the necessary information at once. Don’t hide necessary information behind a second button click. Organize the information in a clear fashion and hide anything not immediately useful.
- Present sensible defaults and allow the user to change them. Keep in mind that it’s very tempting to steal from your users using defaults: if Amazon did something sinister like add an opt-out “Donate $1 to Cancer Prevention” checkbox, or worse, the end result could be a major lawsuit.
- Gauge how much choice is necessary. Perhaps you don’t always need to ask if the ATM user wants a receipt; it might be better to show a button on the login screen that says “receipts: on” and allow the user to click to change their settings, which they will probably only do once in their lifetime.
