Interface animation is almost always discussed as a matter of taste: some people like it, some do not. In reality it has testable functions, and those show clearly when it is working and when it is merely present.<\/p>\n
The rule everything below reduces to: animation should explain what happened, not decorate what was already clear<\/strong>.<\/p>\n All five share a trait: the animation answers a question the person actually had. Remove it and uncertainty appears.<\/p>\n There are working benchmarks here, and they are rarely broken by accident:<\/p>\n A practical rule: if the animation is noticed as an animation, it is too long. The exception is when you are deliberately drawing attention, to an error for instance.<\/p>\n One more detail: appearing should be slower than disappearing. An element arriving needs to be noticed; one leaving does not.<\/p>\n Animations come in cheap and expensive varieties from the browser’s point of view, and that determines whether motion stays smooth on a weak phone.<\/p>\n In practice this means the same visual effect of shifting a block can be built two ways, and one will be smooth on any device while the other stutters on a budget phone. The difference is invisible on a developer’s machine, which is exactly why it goes unnoticed.<\/p>\n Operating systems have a reduced motion setting, enabled by people for whom animation is a physical problem.<\/p>\n One rule in your stylesheet disables or simplifies animation for them. This is not a separate version of the site, it is a few lines, and it is precisely what separates a correct implementation from a careless one.<\/p>\n Important: disabling motion does not mean removing feedback. A button should still show it was pressed, just without the smooth transition.<\/p>\n The sixth point is critical: if a block only appears once a script fires, and the script fails to load, the page ends up blank. The correct approach is content visible by default, with animation adding smoothness on top.<\/p>\n Good micro-animation is invisible: the person simply understands what is happening and never wonders why. Bad animation is noticed immediately, either because it obstructs or because it is admiring itself. The test is simple: remove the animation and see whether things got worse. If not, it was decoration.<\/p>\n","protected":false},"excerpt":{"rendered":" Five functions that make animation useful, six cases where it hurts, working timings in milliseconds, why some animations stay smooth on any phone while others stutter, and a seven-point checklist.<\/p>\n","protected":false},"author":5,"featured_media":8224,"template":"","insight_category":[154],"insight_tag":[190,178,160],"class_list":["post-8228","insight","type-insight","status-publish","has-post-thumbnail","hentry","insight_category-guides","insight_tag-accessibility","insight_tag-performance","insight_tag-ui-ux-design"],"acf":[],"_links":{"self":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight\/8228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight"}],"about":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/types\/insight"}],"author":[{"embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/users\/5"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/media\/8224"}],"wp:attachment":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/media?parent=8228"}],"wp:term":[{"taxonomy":"insight_category","embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight_category?post=8228"},{"taxonomy":"insight_tag","embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight_tag?post=8228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What makes animation useful<\/h2>\n
\n\n
\n \nFunction<\/th>\n Example<\/th>\n What it delivers<\/th>\n<\/tr>\n<\/thead>\n \n Confirming an action<\/td>\n A button responds to being pressed<\/td>\n The person knows the click registered<\/td>\n<\/tr>\n \n Connecting states<\/td>\n A menu expands from the button’s position<\/td>\n It is visible where the element came from<\/td>\n<\/tr>\n \n Directing attention<\/td>\n An error in a field is highlighted<\/td>\n The eye finds the right place<\/td>\n<\/tr>\n \n Indicating waiting<\/td>\n A loading indicator<\/td>\n It is clear a process is running<\/td>\n<\/tr>\n \n Establishing hierarchy<\/td>\n A modal appears above everything<\/td>\n It is clear this is what matters now<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Where it gets in the way<\/h2>\n
\n
How long it should last<\/h2>\n
\n\n
\n \nType<\/th>\n Duration<\/th>\n<\/tr>\n<\/thead>\n \n Response to tap or hover<\/td>\n 100-150 ms<\/td>\n<\/tr>\n \n A small element appearing<\/td>\n 150-250 ms<\/td>\n<\/tr>\n \n Transition between screen states<\/td>\n 250-400 ms<\/td>\n<\/tr>\n \n Anything longer<\/td>\n Reads as sluggishness<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The technical side that determines smoothness<\/h2>\n
\n
Respecting system settings<\/h2>\n
Pre-launch checklist<\/h2>\n
\n