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.
> 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.