14 ms·

I cannot even begin to fathom how a ux website that literally touts "don't make your users wait more than 400ms" as it's #2 rule also has - 400ms css transitio

by jakear 6y ago

I cannot even begin to fathom how a ux website that literally touts "don't make your users wait more than 400ms" as it's #2 rule also has - 400ms css transition - network load of new page - scrolling down to view content - another 400ms transition to go back to main content as its primary mechanism of interaction... is the irony totally lost on them? Or did they drink the #1 kool aid to the extent that they believe their "design" will outweigh their myriad UX failures?

pretty_lorelei 6y ago
The button in the bottom left corner of individual rule pages is almost sadistic: "Do you want to scroll down a screen to view actual content you already clicked for - or find and click the button in the place your cursor spends the least time at?" Edit: also I will never click the social links on the right, because they are absolutely unreadable to me.
petepete 6y ago
Contrast ratio of 1.19 on the numbers isn't a good start either.
csours 6y ago
The point is, don't have a static screen for 400ms after an interaction. If I click on something, and nothing at all happens for half a second, I feel a disconnect. A 400ms animation is a choice that you may not make, but does not 'feel' the same as a page load, or other stall.
- stefan_ 6y ago
  Lies of UX web developers tell themselves, #1.
  - csours 6y ago
    If git had a 400 ms animation I would be very upset. If Amazon had a 400 ms animation for every purchase/page load I would be very upset. If an art project had a 400 ms animation, that would be part of the art.
- jakear 6y ago
  Feels the same to me... in fact, I'd probably prefer 400ms of a static screen to 400ms of animation. Withe the static screen I can blame my internet and not think much of of it, if I'm watching an animation I have to sit there and think about how the "designer" chose to force me to wait for them to twirl around and take a bow before I can move on. Edit: Exact test of rule 2: Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other. Nowhere does it say that waiting is only bad if you don't see something happening. I am waiting on the computer to finish it's little jig. That is bad, and a violation of rule #2. 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, this the Doherty threshold has not been met.
  - mrob 6y ago
    I've only ever seen one unintrusive animation in UI, which was the window minimization animation of the Metacity window manager. It minimized the window immediately, but then followed up with an animated outline showing where the window had gone. It was thin enough that you could easily ignore it, but still provided all the benefit that designers claim from their slow and disruptive animations.
  - csours 6y ago
    I hear you. I read this as: what if you can't meet the Doherty threshold? Do you try harder? More caching? Put a spinner on it? Animate? Try to tell some jokes?
- askxnakjsn 6y ago
  The big problem with this is that you expect the computer to respond to your clicks naturally and instantly and instead you are put on hold while an animation plays. It may not break the latency rule strictly, but theoretically feels like it should be added on there because it has the same effect for users who don't care about animations (aka most users).
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.
GuB-42 6y ago
The 400ms rule is that if the user does something, the UI must do something, anything. It can mean "display the linked page within 400ms" or "start the animation within 400ms". You can't expect 1 TB of data to be transferred within 400ms but you can display a progress bar within 400ms. Apple used that to great effect. iPhones, at least in the early days always felt more responsive than Android phones. That because they hid latency using smooth animation. And it worked. It was also apparent when I compared Chrome and Firefox a few years ago. Chrome felt faster but mostly because Chrome was faster at showing something on screen. They took about the same time to fully load the page.
- jakear 6y ago
  Discussing "waiting for an animation is okay" at https://news.ycombinator.com/item?id=24031824 https://news.ycombinator.com/item?id=24031824 Side note, it would be very interesting if comments were a DAG rather than a Tree... that way one could respond to several comments with the same thread.
- jakear 6y ago
  Also, this is a Very different scenario to the listed. The html loads in < 10ms, But I have to wait 400ms (!!!) to see it. It’s actually the exact opposite of the cases you mentioned above, they take a fast operation and dramatically reduce the perceived performance by making you wait 400ms (!!!) for it to complete.
arcturus17 6y ago
> scrolling down to view content Shouldn't this be normal?
- jakear 6y ago
  No, I don’t think a link taking you to an empty page where the content only appears after you decipher what interaction you’re supposed to perform then perform it should be normal. Instead, I think links taking you to pages where the content is immediately visible should be normal.
quickthrower2 6y ago
Ahhh! You had to scroll down. I didn't realise that. Thanks!
imvetri 6y ago
"Dont cut papers". Gets printed on papers, delivers a message. Look at the message not the paper.
p_l 6y ago
Add bad rendering to the mix: https://usercontent.irccloud-cdn.com/file/9LX6jYDI/Screenshot_20200803-122909.png https://usercontent.irccloud-cdn.com/file/9LX6jYDI/Screensho...

by jakear 6y ago

pretty_lorelei 6y ago

The button in the bottom left corner of individual rule pages is almost sadistic: "Do you want to scroll down a screen to view actual content you already clicked for - or find and click the button in the place your cursor spends the least time at?" Edit: also I will never click the social links on the right, because they are absolutely unreadable to me.

petepete 6y ago

Contrast ratio of 1.19 on the numbers isn't a good start either.

csours 6y ago

The point is, don't have a static screen for 400ms after an interaction. If I click on something, and nothing at all happens for half a second, I feel a disconnect. A 400ms animation is a choice that you may not make, but does not 'feel' the same as a page load, or other stall.

stefan_ 6y ago
Lies of UX web developers tell themselves, #1.
- csours 6y ago
  If git had a 400 ms animation I would be very upset. If Amazon had a 400 ms animation for every purchase/page load I would be very upset. If an art project had a 400 ms animation, that would be part of the art.
jakear 6y ago
Feels the same to me... in fact, I'd probably prefer 400ms of a static screen to 400ms of animation. Withe the static screen I can blame my internet and not think much of of it, if I'm watching an animation I have to sit there and think about how the "designer" chose to force me to wait for them to twirl around and take a bow before I can move on. Edit: Exact test of rule 2: Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other. Nowhere does it say that waiting is only bad if you don't see something happening. I am waiting on the computer to finish it's little jig. That is bad, and a violation of rule #2. 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, this the Doherty threshold has not been met.
- mrob 6y ago
  I've only ever seen one unintrusive animation in UI, which was the window minimization animation of the Metacity window manager. It minimized the window immediately, but then followed up with an animated outline showing where the window had gone. It was thin enough that you could easily ignore it, but still provided all the benefit that designers claim from their slow and disruptive animations.
- csours 6y ago
  I hear you. I read this as: what if you can't meet the Doherty threshold? Do you try harder? More caching? Put a spinner on it? Animate? Try to tell some jokes?
askxnakjsn 6y ago
The big problem with this is that you expect the computer to respond to your clicks naturally and instantly and instead you are put on hold while an animation plays. It may not break the latency rule strictly, but theoretically feels like it should be added on there because it has the same effect for users who don't care about animations (aka most users).

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.

GuB-42 6y ago

The 400ms rule is that if the user does something, the UI must do something, anything. It can mean "display the linked page within 400ms" or "start the animation within 400ms". You can't expect 1 TB of data to be transferred within 400ms but you can display a progress bar within 400ms. Apple used that to great effect. iPhones, at least in the early days always felt more responsive than Android phones. That because they hid latency using smooth animation. And it worked. It was also apparent when I compared Chrome and Firefox a few years ago. Chrome felt faster but mostly because Chrome was faster at showing something on screen. They took about the same time to fully load the page.

jakear 6y ago
Discussing "waiting for an animation is okay" at https://news.ycombinator.com/item?id=24031824 https://news.ycombinator.com/item?id=24031824 Side note, it would be very interesting if comments were a DAG rather than a Tree... that way one could respond to several comments with the same thread.
jakear 6y ago
Also, this is a Very different scenario to the listed. The html loads in < 10ms, But I have to wait 400ms (!!!) to see it. It’s actually the exact opposite of the cases you mentioned above, they take a fast operation and dramatically reduce the perceived performance by making you wait 400ms (!!!) for it to complete.

arcturus17 6y ago

> scrolling down to view content Shouldn't this be normal?

jakear 6y ago
No, I don’t think a link taking you to an empty page where the content only appears after you decipher what interaction you’re supposed to perform then perform it should be normal. Instead, I think links taking you to pages where the content is immediately visible should be normal.

quickthrower2 6y ago

Ahhh! You had to scroll down. I didn't realise that. Thanks!

imvetri 6y ago

"Dont cut papers". Gets printed on papers, delivers a message. Look at the message not the paper.

p_l 6y ago

Add bad rendering to the mix: https://usercontent.irccloud-cdn.com/file/9LX6jYDI/Screenshot_20200803-122909.png https://usercontent.irccloud-cdn.com/file/9LX6jYDI/Screensho...