6 ms·

Here is a copy of the 1982 paper: https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html https://jlelliotton.blogspot.com/p/the-economic-

Here is a copy of the 1982 paper: https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html https://jlelliotton.blogspot.com/p/the-economic-value-of-rap... "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".

dahart 6y ago
Ah, thanks for the link! 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.
- joveian 6y ago
  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.
  - dahart 6y ago

dahart 6y ago

Ah, thanks for the link! 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.

joveian 6y ago
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.
- dahart 6y ago