None of those things you listed are in conflict with rule #2.
The length of an animation is not the same as making your users wait for an initial response to your input. The rule is talking about how fast the computer appears to acknowledge and begin responding to a user input, it is not talking about how fast any given task is completed. The wait is the length of time between clicking the button and when the screen starts to animate.
Animation you have to wait for can sometimes be a bad design choice on a page, and I'm not a big fan of overuse of css transitions. But a navigation transition helps the user keep mental track of where they are, and it specifically signals that the computer is responding to your input. The animation itself here doesn't break the Doherty threshold, it does the opposite, it meets the Doherty threshold.
Network loading of a new page is unavoidable (out of the control of the page author), is absolutely standard practice for internet apps (see Jakob's law), and your browser (not the page) is what handles the interaction. The browsers adhere to the rules listed here to every extent possible, and they respond to page loads instantly by showing you a loading spinner, a blank page, and allowing interactions like cancelling the load while loading. Again, the interaction criteria here is that the computer acknowledges your input, not that it is required to finish something that can take time.
Scrolling is another interaction that meets rule #2, it doesn't break the rule. The rule is not about design or layout. When scrolling, if the page is moving in response to your input, then it's meeting the rule. And scrolling is one of the things browsers bend over backward to make as smooth and fast as possible.
> Network loading of a new page is unavoidable (out of the control of the page author)
Nope, the author had complete control over how much information they wanted to show on the main page vs the details page. In desktop view they show the single-sentence descriptions on the main page, in mobile they don't. So they've forced mobile users to wait for the network load (potentially much more than 400ms) completely unnecessarily.
> Scrolling is another interaction that meets rule #2, it doesn't break the rule.
Sure, it doesn't break rule #2 specifically, but it does break #3. And, more importantly, it's shitty UX and has no place on a "Rules of UX" website, except maybe as a counterexample.
> I'd probably prefer 400ms of a static screen to 400ms of animation.
The alternative here is no visual response to a click at all. I'm not okay with that, and I seriously doubt you'd be okay with it in general. Most people aren't (this has been shown). A 400ms delay after button clicks and scrolling and other interactions is an indication that your input was not received, and it feels intolerable to people today. The 400ms standard here was set 40 years ago. Today software feels completely broken if it doesn't respond with something in under 100ms, and desktop browsers typically do something within 33ms.
> the author had complete control over how much information they wanted to show
That's irrelevant. The browser does respond to your page load request instantly, with a blank page and a spinner. It doesn't break the rule.
Again, you can criticize the choices with your own opinion at a subjective level, this doesn't mean the authors aren't following their own advice. It feels like you're looking for reasons to justify not liking the page. You're free to not like the page, I won't disagree with that. What I disagree with is the reason given.
> Sure, it doesn't break rule #2 specifically, but it does break #3.
It seems like you're moving on to misunderstanding rule #3. Scrolling and clicking does not apply to Fitts' Law.
EDIT: I said scrolling doesn't apply to Fitts' law, and I meant that specifically as a reponse to, and in the context of the suggestion being made here by the parent: scrolling to find a new unknown target plus acquiring a new target, plus moving to click on the new target.
Extending the law to include the number of interactions is going to be tautological in the sense that if number of manual interactions is your "distance" then of course more will take longer. Including targets that are unknown is just beyond the scope of what has been studied and shown, I'm saying it is not really in the spirit of Fitts' law. https://en.wikipedia.org/wiki/Fitts%27s_law
Are you honestly, and I mean honestly honestly, trying to argue that needing to scroll then move your mouse to reach a target can not be thought of as a target being further away when it comes to Fitts' law and the relationship between distance and time to acquire a target? It seems to me that you are choosing to focus on the specific text used in a rule as opposed to the concept that rule is trying to convey. I don't enjoy arguing over that sort of thing whatsoever, so I'll have to call it a day and go back to spreading mulch. Good day :)
Your question is a straw man. You can think of scrolling as something being further away if you want, and I don't disagree. That doesn't mean Fitts' law applies.
Fitts' law is referring to a single interaction ("movement") with visible targets, not a general abstract concept of "futher away" that you can extend in any way and to any topic you want across multiple interactions. It is precisely because you have to use two different movements, as you pointed out, to both scroll to see the target and then move your mouse or hand to reach the target, that Fitts' law does not apply here.
Speaking more generally, there is a big problem with your assumption here that you can take interaction studies (or any scientific results) out of context just because you can think of it as analogous. When researchers have studied human perception and motions under specific conditions, you cannot assume the findings apply to conditions that weren't tested.
There isn't anything to be argued. You said that the scrolling violates Rule #3, which is about Fitts's law specifically. Scrolling has nothing to do with Fitts's law.
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.
It absolutely does force you to wait though. If I click Learn More, then try pressing the PREV or NEXT buttons at the top, they do not respond to user input until the CSS animation is finished. I'm fairly certain this is exactly what rule #2 is talking about, trying to quickly go to the end or front of the list this way is extremely frustrating.
CSS transitions can be fine, but they shouldn't block user input or force the user to wait until they finish before moving on.
For this particular instance it might not matter a ton that they broke rule 2. But imagine if this was a table of paginated data, having to wait up to an extra second each time you go to the next or previous page just so the data could animate in would be rage inducing after a long period of time.
You are right. It took me a couple of tries to hit More and then move up to NEXT fast enough to repro the problem, you sort-of have to be in QA mode to catch this one. I'd say it's a problem with the NEXT button, and not a problem with scrolling. I'd also say the average reader is not very likely to bump into this.
I do agree that transitions shouldn't make you wait, and I mentioned above that I'm not the biggest fan of transitions. BUT the transitions here do not break rule #2, regardless of whether they are good design or not. Forcing you to wait as part of the interaction is not the same thing as not responding in the first place. The animation is the response to the input, and it acknowledges that the system is up and running.
A good way to understand rule #2. Here are two scenarios. A breaks rule #2 and B does not break rule #2.
A - You hit a button that makes an AJAX call. The response takes 10 seconds to arrive. The CSS has disabled button hover highlights, and button press state changes. There is no indication on screen that the request has been made.
B - You hit a button that makes an AJAX call. The response takes 10 seconds to arrive. Default CSS rules show the button press, and the page pops up a loading spinner.
Actually you can just click NEXT multiple times in a row. Imagine you are on item 1 but really want to see item 5. You would have to click next, wait for transition to finish, click next, wait, etc.
(I found this because I already read the first 2-3 laws and closed the page, reopened to see the "Details" and wanted to quickly navigate to the middle/end of the list. Instantly the site felt super sluggish and unresponsive)
I totally agree with you BTW, clicking a button and having a quick (<200ms in my eyes) visual response is completely fine, even if that response is just a CSS transition. I do this all the time.
The specific problem I had is the NEXT button stops responding during that CSS transition which might not technically break rule #2 but definitely makes the UI feel sluggish and non responsive.
Note that scrolling in some browsers is a specific interaction that disables JavaScript and all other interactions while scrolling in order to maintain high frame rates and smooth scrolling. This might be an unintentional bug or side-effect of using scrolling at all, and some people consider it a browser bug. It does mean it's important to think before triggering a scroll, OTOH, the interaction here of jumping instantly to another item without scrolling could be disorienting to some people. Maybe the whole issue would be fixed by changing the transition time from 400ms to 200ms?
I'd also note that rule #2 serves a more specific purpose than avoiding any wait times. It's there to avoid confusion about what's happening in response to a click, not to eliminate all waiting, nor to eliminate all annoyances in UX delays. With a transition, it's annoying that you can't interact while the animation plays, but it's not (in this case) confusing about what's happening. I know why the button isn't working, and very quickly I know how long I have to wait before it works again, even though I'd rather that it did work instantly.
The rule is talking about whether the system acknowledges your input visually. The input is specifically acknowledged by the animation starting and then playing. That is the indicator that the click was received.
On a technicality, I'll mention that a 400ms transition technically isn't more than 400ms, it's equal to 400ms. That's just me being cheeky though, it's irrelevant, because rule #2 is met on my laptop within 17ms when the animation begins.
Let’s look at the rule itself instead of making baseless declarations about what the rule is talking about:
Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
Further, from the original study itself:
"When a human being’s command was executed and returned an answer In under 400 milliseconds, it was deemed to exceed the Doherty threshold, and use of such applications were deemed to be “addicting” to users."
My answer has not been returned within 400ms, and I had to wait for the computer, and the site was so un addicting that I exited out after suffering through those animations only 2 times. Thus not a single interpretation of Doherty threshold in its original form has been met. It’s really quite simple.
If acknowledging input rather than returning an answer was all that was needed, the rule would state as such and the old hat engineers making the original computers would have had wired “Enter” up to “bell” and called it a day. Luckily they weren’t nearly as lazy as many in this thread seem to be.
For cases such as the “downloading a 3gb file” that get brought up, I’d consider the “answer” to pressing the download link to be the dialog box saying that a download has started. I would not consider the “answer” to clicking a link to be an animation saying... I’m not sure what; rather, the “answer” to clicking a link is clearly my browser starting to navigate to that link
Side note: just for funzies, I patched vscode to show a loading animation for 400ms before opening new files. After playing around with it for a couple minutes, I can assure you that if I pushed that to master, insiders users would come screaming tomorrow morning and all the “well actually this is in compliance with XXX law because technically...” would not appease them. If you wouldn’t accept it in your editor, why accept it in your websites?
The length of an animation is not the same as making your users wait for an initial response to your input. The rule is talking about how fast the computer appears to acknowledge and begin responding to a user input, it is not talking about how fast any given task is completed. The wait is the length of time between clicking the button and when the screen starts to animate.
Animation you have to wait for can sometimes be a bad design choice on a page, and I'm not a big fan of overuse of css transitions. But a navigation transition helps the user keep mental track of where they are, and it specifically signals that the computer is responding to your input. The animation itself here doesn't break the Doherty threshold, it does the opposite, it meets the Doherty threshold.
Network loading of a new page is unavoidable (out of the control of the page author), is absolutely standard practice for internet apps (see Jakob's law), and your browser (not the page) is what handles the interaction. The browsers adhere to the rules listed here to every extent possible, and they respond to page loads instantly by showing you a loading spinner, a blank page, and allowing interactions like cancelling the load while loading. Again, the interaction criteria here is that the computer acknowledges your input, not that it is required to finish something that can take time.
Scrolling is another interaction that meets rule #2, it doesn't break the rule. The rule is not about design or layout. When scrolling, if the page is moving in response to your input, then it's meeting the rule. And scrolling is one of the things browsers bend over backward to make as smooth and fast as possible.