4 ms·

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 y

by dahart 6y ago

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.

jakear 6y ago
Response to "making users wait for an animation is okay" here: https://news.ycombinator.com/item?id=24031824 https://news.ycombinator.com/item?id=24031824 > 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.
- dahart 6y ago
  > 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. Fitts' Law has been studied on scrolling alone, for example: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/Scrolling_CHI02.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... 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 https://en.wikipedia.org/wiki/Fitts%27s_law
  - jakear 6y ago
    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 :)
hannib 6y ago
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.
- dahart 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - hannib 6y ago
    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.
wruza 6y ago
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).
- dahart 6y ago
  > We can discuss form and composition forever 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.
  - joveian 6y ago
    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".
pbreit 6y ago
How is setting a 400ms transition NOT breaking the "law" to not make users wait more than 400ms?
- dahart 6y ago
  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.
  - jakear 6y ago
    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?

by dahart 6y ago

jakear 6y ago

Response to "making users wait for an animation is okay" here: https://news.ycombinator.com/item?id=24031824 https://news.ycombinator.com/item?id=24031824 > 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.

dahart 6y ago
> 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. Fitts' Law has been studied on scrolling alone, for example: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/Scrolling_CHI02.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... 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 https://en.wikipedia.org/wiki/Fitts%27s_law
- jakear 6y ago
  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 :)

hannib 6y ago

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.

dahart 6y ago
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.
- deleted 6y ago
  [deleted]
- hannib 6y ago
  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.

wruza 6y ago

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

dahart 6y ago
> We can discuss form and composition forever 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.
- joveian 6y ago
  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".

pbreit 6y ago

How is setting a 400ms transition NOT breaking the "law" to not make users wait more than 400ms?

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