It also hits the uncertainty like in some games when a cutscene ends but you have yet to figure out that it's time to move. At the first time I tapped on a box I had to decide whether my action is required. And it was, I had to scroll anyway. It failed easy interaction before all else.
We can discuss form and composition forever, but we all know that a simple scrollable page with screen-high tiles and/or a floating "next" button would do the job a million times better than this. If that was a job-related tool and not a site that you can read once and close forever, I would consider an alternative immediately. Fun fact, I didn't even bother to go further than few "articles" and read 6-8 times more text here itt than on their site in the same amount of time.
Your points are probably correct for a ux that has such problems, but if you do not create a problem, you do not have to solve a problem, and you cannot fail at it (which is easy to do).
FWIW, I'm not discussing form or composition at all, nor am I defending the site's high level design choices at all. I'm just trying to help clarify what the rules on this page actually mean, because rule #2 was misunderstood above. This page has been posted before, and other people have also misunderstood rule #2 to assume it means that interactions have to be complete in a certain amount of time. The rule is simpler than that, and lower level than page layout issues. I would guess that part of the reason this rule is misunderstood is because it's rarely broken these days in commercial apps and web pages. Unlike the 80's, it's not that common anymore for computers to not respond at all in any way to a user input in more than 400ms, and browsers take care of a lot of the cases where it might happen.
"System Response Time. This is the time span between the moment the user enters a command and the moment a complete response is displayed on the terminal."
Note the phrase "complete response" and that the paper itself is titled "The Economic Value of Rapid Response Time".
Yes the phrase "complete response" does sound like a full task finished, but what, exactly, is a "complete response"? Isn't a popup or dialog box or a loading spinner a complete response from a UI perspective? If not, why not?
The definition of "complete response" in the paper is not specific. What were the tasks being studied? Can you have sub-tasks for which there are multiple complete responses? Note the interactions this paper is discussing are terminal commands on a terminal connected to a local mainframe. They didn't have web pages.
There are notes in the paper that give clues as to what kind of tasks & responses they are talking about: "In 1979 their installed system was designed to offer 300 simultaneous users word processing, programming, computing, and remote job entry capabilities, with the response to 80 percent of the transactions being processed in .5 seconds or less."
There are lots of other clues that the kinds of interactions they are talking about are so basic and tiny that we don't even think about them as individual tasks anymore. When you read the entire thing and study the charts, what the paper is really showing is that computers in 1982 were excruciatingly slow, so slow that they interfered with basic word processing and data entry, so slow that they could actually calculate the financial savings of being able to execute shell commands slightly faster.
Even though it says the subjective words "complete response", there are and always have been large tasks that take much longer than 400ms. Does that mean any task that takes longer than 400ms is automatically bad UX? I don't think so, I consider starting a 3GB video download, for example, to be a complete response when the browser acknowledges sending the request, and starts showing progress. I think the paper's definition would agree with that because I can submit other tasks to the computer immediately, I can read other pages, type other commands, save files, etc., etc.
A spinner is not a complete response because the system is still going to respond more without additional input.
Here is another quote that the paper quotes: "...each second of system response degradation leads to a similar degradation added to the user's time for the following [command]. This phenomenon seems to be related to an individual's attention span. The traditional model of a person thinking after each system response appears to be inaccurate. Instead, people seem to have a sequence of actions in mind, contained in a short-term mental memory buffer. Increases in SRT [system response time] seem to disrupt the thought processes, and this may result in having to rethink the sequence of actions to be continued."
A spinner still disrupts the thought process in the same way. I would personally say that yes, anything that takes longer (I'd say more like 100ms even, possibly less) is automatically bad. It might still be the best possible in a particular situation and pretending that something will necessarily be fast when it often isn't is also bad. It is easier to plan around tasks that take longer when a small and reliable set of tasks take longer and somewhat fits with the theme in that way, but I'd still say the core idea here is "everthing that happens should happen quickly" and have other guidelines to deal with the cases where that isn't possible. Don't try to trick yourself that the system is actually responding quickly when it really isn't.
You could say that the most extreme reading of this principle would imply that a computer should never play video or audio. Personally, I would say it shouldn't except when I ask it to. My top guideline for websites would be something like "your website is not an experience". You can put an experience on your website and some people will appreciate it, but let me accomplish what I wanted to do when I visited your site quickly. Breaking my thought process to insert marketing is not a good experience.
I disagree this is not relevent today; I didn't use a mainframe in 1982 but I wouldn't be surprised if the experience was more responsive than what is common today. Part of this is due to everything making network requests today but in general system response does not seem to be valued particularly highly. I regularly wait over two seconds for a particular text entry box in Windows 10 to work on a fast modern system with an SSD and no network connection that is interacting with a small local database. Windows 7 seemed more responsive to me, as did a lot of older software compared to modern versions.
> A spinner is not a complete response because the system is still going to respond more without additional input.
The paper talks about launching batch jobs. How does that fit into your interpretation of a "complete response"? What would the complete response to starting a batch job have been in 1982?
> I didn't use a mainframe in 1982 but I wouldn't be surprised if the experience was more responsive than what is common today.
I did use mainframe terminals in high school and college, and they were nowhere near the responsiveness that is common today. Not in the same ballpark, not even on the same planet. Our expectations for responsiveness have grown as fast as response times have shrunk, computing today is orders of magnitude more responsive across the board.
> Don't try to trick yourself that the system is actually responding quickly when it really isn't.
That sounds pretty catchy, but is completely subjective, it depends on what you mean by response, which is what we are trying to flesh out here. I'm trying to make the case that in the context of UI/UX best practices this is a red herring. The questions are about interaction and expectations, about acknowledging your input, not about whether computers can magically perform impossible feats of physics. Speed of light prevents some servers on earth from getting a response to you in under 100ms. I do tasks all the time that takes seconds or minutes, and I bet you do too. I disagree that long tasks are automatically bad UX. Bad UX is failing to notify you that you started a task, or failing to notify you that a task finished. Bad UX is giving no indication of how long a very long task will take. Bad UX does not automatically exist merely because a task takes time.
"At NIH there was an average of 90 transactions and two batch submissions per work session. This did not vary, even though work session length varied with the computer response time."
The paper is not talking about turning non-batch jobs into batch jobs (or batch jobs at all really), it is just an aside where they insert magic marketing numbers to sound good. Presumably for practical reasons they would consider the response "batch job started" to be the complete response. I think we can at least agree that it is unhelpful to call an unavoidably long task bad design just for being unavoidably long.
Nothing in the paper suggests that making tasks avoidably long is ok if the system gives an indication it is doing something.
Right. ‘Batch job started’ is the same “complete response” as a spinner. A progress bar is a better response and UI design than either because indicates time to completion.
> Nothing in the paper suggests that making tasks avoidably long is ok if the system gives an indication it is doing something.
I can agree with that statement as written, but there are a couple of minor issues with your framing here. One, I didn’t suggest that making tasks avoidably long is okay. I can see why I might appear to have hinted in that direction, but your summary, especially inserting the word “avoidably”, is not a generous interpretation of my words, and I was explicit from the start about stating that I’m not a fan of CSS transitions and not defending the design choices of the Laws of UX site. Two, you already know the context of this paper is 1980, when the alternative to what they actually mean by “complete response” is a blinking terminal cursor that doesn’t move. They’re not talking about partial response of some kind, and they are considering “batch job started” to be a complete response. In that sense, and in the context of the time the paper was written, it is very much suggesting that more quickly giving an indication that it’s doing something is the goal.
Beyond this paper, the broad idea of fast response in the UI/UX and web world has adopted the idea that showing acknowledgement of input very quickly is important. There are multiple examples of this in the nearby threads, and many hundreds of papers beyond Doherty’s that discuss these topics and demonstrate the humans perceptually prefer to see fast reactions even when the final result takes a while.
It might also be worth pointing out that for the arrow buttons on the Laws of UX site, the animation itself literally is the “complete response”. The function of the button is to trigger the animation. Animations are really out of the scope of Doherty’s paper, their idea of a “complete response” in 1980 was a line of text that could display at once.
> It might also be worth pointing out that for the arrow buttons on the Laws of UX site, the animation itself literally is the “complete response”.
This is where we disagree. The animation is exactly what I mean by "avoidably long". It interrupts the user the same way the long response times mentioned in the paper do. If you quote this paper, expect people to say that it means what it clearly states since this is a source of real frustration for many of us. As I mentioned earlier, some people do appreciate a more paced "experience", but many of us never want such an experience from a website and just want rapid response.
It’s fine if you don’t want animations, your opinion is valid if you don’t like them, but you’re conflating a design choice with the idea of a “response”. You can’t disagree with the fact that the arrow buttons on the site are the complete response. It makes no sense to say that, because those buttons do nothing else; their single solitary function is to trigger an animated scroll, and once the animation is done playing, there is nothing else involved in the “response”.
Yes, the length of animation is a design choice, and is in that sense avoidable — precisely because the length of time the animation plays was a conscious intent. What you’re talking about is not related to what Doherty’s paper was talking about.
We can discuss form and composition forever, but we all know that a simple scrollable page with screen-high tiles and/or a floating "next" button would do the job a million times better than this. If that was a job-related tool and not a site that you can read once and close forever, I would consider an alternative immediately. Fun fact, I didn't even bother to go further than few "articles" and read 6-8 times more text here itt than on their site in the same amount of time.
Your points are probably correct for a ux that has such problems, but if you do not create a problem, you do not have to solve a problem, and you cannot fail at it (which is easy to do).