Tag: Motion

10 Dec

Introducing Framer Motion

by TBSCategories: News

In this article, we’ll take a closer look at how Framer Motion helps us in creating awesome animations. We’ll learn how motion components work and learn how to chain animations together. We’ll look into how to make gesture-triggered, timed, and scroll animations with Framer motion. Along the way, we’ll use the things we learn to build five demo applications I’ve set up to show us how we can integrate Framer Motion into real-world applications.

This tutorial will be beneficial to readers who are interested in integrating animations in their React application.

Note: This article requires a basic understanding of React and CSS.

What Is Framer Motion?

Framer Motion is an animation library that makes creating animations easy. Its simplified API helps us abstract the complexities behind animations and allows us to create animations with ease.

Motion Components

These are the building blocks of Framer motion. Motion components are created by prefixing motion to your regular HTML and SVG element (e.g, motion.h1). Motion components can accept several props, with the basic one being the animate prop. This prop takes in an object where we define the properties of that component we want to animate. The properties we define will be animated when the component mounts in the DOM.

Let’s animate an h1 text using Framer Motion. First, we install the framer-motion library and import motion. 

npm i framer-motion import { motion } from 'framer-motion';

Then we convert the h1 into a motion component.

<motion.h1    animate={{x: 20, y: -20}}>   This is a motion component </motion.h1>

This will cause the h1 to slide 20px to the right and move 20px up when it loads. When units aren’t added, calculations are done using pixels. However, you can explicitly set the units you want the calculations to be based on, animate={{x: "20rem", y: "-20rem"}}>.

By default, a motion component will be animated from the state defined from its styles to those in the animate prop. However, if we wanted to, we could hijack and define the initial animation state of the component using the initial prop. While the animate prop is used to define the behavior of components when they mount, the initial prop defines their behavior before they mount.

If we want our h1 to come in from the left, we control that using the initial prop.

<motion.h1     initial={{x: -1000}}     animate={{x: 20}}>    This is a motion component </motion.h1>

Now, when the h1 mounts, it slides in from the left.

We are not limited to a single animation. We can define a series of animations called keyframes in an array of values. Each value will get animated in sequence.

<motion.h1     initial={{x: -1000}}     animate={{x: [20, 50, 0, -70, 40] }}>    This is a motion component </motion.h1>

The transition prop allows us to define how the animations occur. With it, we define how values animate from one state to another. Among other things, we can define the duration, delay, and type of animation using this prop.

<motion.h1     initial={{ x: -1000 }}     animate={{ x: 0 }}     transition={{         type: "tween",         duration: "2",         delay: "1"     }}>     This is a motion component </motion.h1>

Say we were to animate several motion components simultaneously, like in the code snippet below.

<div className="App">       <motion.h1         initial={{ x: -1000 }}         animate={{ x: 0 }}         transition={{           type: "tween",           duration: "2",           delay: "1"         }}>         This is a motion h1       </motion.h1>       <motion.h2           initial={{ y: -1000 }}         animate={{ y: 0 }}         transition={{           type: "tween",           duration: "1",           delay: ".4"         }}>This is a motion h2       </motion.h2>       <motion.h3        initial={{ x: 100, opacity: 0 }}        animate={{ x: 0, opacity: 1 }}>          This is a motion h3       </motion.h3>       <motion.h4        initial={{ scale: 0.7 }}        animate={{ scale: 1.7 }}        transition={{          type: "tween",          duration: "2",          delay: "1"        }}>          This is a motion h4       </motion.h4>     </div>

While this works, the variants prop in Framer Motion enables us to extract our animation definitions into a variants object. Not only do variants make our code cleaner, but they allow us to create even more powerful and complex animations.

Extracting our animation definitions into variants objects, we have this:

const H1Variants = {   initial: { x: -1000 },   animate: { x: 0 },   transition: {     type: "tween",     duration: 2,     delay: 1   } }  const H2Variants = {   initial: { y: -1000 },   animate: { y: 0 },   transition: {     type: "tween",     duration: 1,     delay: .4   } } const H3Variants = {   initial:{ x: 100, opacity: 0 },   animate:{ x: 0, opacity: 1 } } const H4Variants = {   initial:{ scale: 0.7 },   animate:{ scale: 1.7 },   transition:{     type: "tween",     duration: "2",     delay: "1"   } }

Instead of passing the animation definitions into a component’s initial and animate props directly, we extract these definitions into standalone variant objects. In the variant objects, we define variant names that describe each animation’s name as variants.

<div className="App">       <motion.h1       variants={H1Variants}       initial='initial'       animate='animate'       >         This is a motion h1       </motion.h1>       <motion.h2           variants={H2Variants}         initial='initial'         animate='animate'        >         This is a motion h2       </motion.h2>       <motion.h3         variants={H3Variants}         initial='initial'         animate='animate'        >          This is a motion h3       </motion.h3>       <motion.h4         variants={H4Variants}         initial='initial'         animate='animate'        >          This is a motion h4       </motion.h4> </div>

In the variants prop, we pass in the name of the variant objects for each motion component and then pass in the animations to the initial and animate props.

We can take our current setup with variants further to reduce repetition. Using variants, we can propagate animation attributes down through the DOM from a parent motion component. For this to work, we create variants for the parent motion.div with similar animation names in its variant object as its children. By doing this, we won’t have to pass the animation names’ to each child component. Behind the scenes, the parent element handles that for us.

const ContainerVariants = {   initial: {},   animate: {} }; const H1Variants = {   initial: { x: -1000 },   animate: { x: 0 },   transition: {     type: "tween",     duration: 2,     delay: 1   } }; //more variants below  <motion.div       className="App"       variants={ContainerVariants}       initial="initial"       animate="animate"     >       <motion.h1 variants={H1Variants}>This is a motion h1</motion.h1>       <motion.h2 variants={H2Variants}>This is a motion h2</motion.h2>       <motion.h3 variants={H3Variants}>This is a motion h3</motion.h3>       <motion.h4 variants={H4Variants}>This is a motion h4</motion.h4> </motion.div>

Now we have a cleaner code with no repetitions. We turned the container div to a motion component so we could pass in the ContainerVariants object we defined. Since we don’t define any animations on the container, we pass in empty objects to initial and animate. Your animation names must be the same in every variant object for the propagation to work.

Now we understand the basics of Framer Motion. Let’s begin building our fist of 5 demo applications.

Icon Shop

We can create interactive animations based on gestures. Motion components are currently able to listen for hover, tap, pan, and drag gesture detection. We’ll be building this Icon Shop app using the whileHover prop.

Components

  • App.js: this holds the heading texts.
  • Card.jsx: here, we define the animations for the icon cards.
  • CardContainer.jsx: we import and loop through the icons.
  • styles.js: create, style, and export the motion components. I used styled-components for styling the components.

Let’s start with App.js.

import { H1, H2 } from "./Styles"; import CardContainer from "./CardContainer";    return (     <div>       <H1          initial={{ y: -100 }}          animate={{ y: 0, transition: { delay: 1 } }}>         Icon Shop       </H1>       <H2          initial={{ x: -1000 }}          animate={{ x: 0, transition: { delay: 1 } }}>         Hover over the cards to see the motion magic       </H2>       <CardContainer />     </div>   );

We import the H1 and H2 motion components we created in the Styles.js file. Since they are motion components, we use the initial and animate props to define their behavior before and when they mount. Here, we also import and display the CardContiner component.

Now, the CardContainer.js.

import { Container } from "./Styles"; import Card from "./Card"; import { ReactComponent as AddIcon } from "./assets/add.svg"; import { ReactComponent as AirplaneIcon } from "./assets/airplane.svg"; import { ReactComponent as AlarmIcon } from "./assets/alarm.svg"; //more svg imports below...  const icons = [   <AddIcon />,   <AirplaneIcon />,   <AlarmIcon />,   //more icons below ];  const CardContainer = () => {   return (     <Container initial={{ x: -1000 }} animate={{ x: 0 }}>       {icons.map((icon) => (         <Card icon={icon} />       ))}     </Container>   ); };

Here, we import the SVGs, the Container motion component, and the Card component.

Similar to H1 and H2 in App.js, we define animations of the Container using the initial and animate props. When it loads, it will create a cool effect of sliding in from the left of the browser.

Now, Card.js

import { CardBox, IconBox } from "./Styles"; const CardVariants = {   beforeHover: {},   onHover: {     scale: 1.1   } }; const IconVariants = {   beforeHover: {     opacity: 0,     y: -50   },   onHover: {     opacity: 1,     y: 0,     scale: 1.5,     transition: {       type: "tween"     }   } };  const Card = ({ icon }) => {   console.log(icon);   return (     <CardBox variants={CardVariants} initial="beforeHover" whileHover="onHover">       <IconBox variants={IconVariants}>{icon}</IconBox>     </CardBox>   ); };

Here, we create two variant objects with beforeHover and onHover animations. In the CardVariants object, we don’t want to do anything initially, so beforeHover is an empty object. onHover we increase the scale of the card box.

In the IconVariants object, we define the initial state of the IconBox in its beforeHover. We set its opacity to 0 and push it upwards by 50px. Then, in onHover, we set the opacity back to 1, push it back to its default position, and change the transition type to tween. Then we pass in the variants to their respective motion components. We make use of the propagation, so we don’t need to explicitly set the initial and animate props to the IconBox component.

Animated Navbar

We’ll build a simple Navigation component, and we’ll see how we can create timing relationships between parent and children motion components.

Components

  • App.js: this holds the heading texts.
  • Styles.js: create, style, and export the motion components. The components are styled using styled-components.

Let’s take a look at the App.js file.

import { Header, Nav, Link, SvgBox } from "./Styles";  function App() {   const [isOpen, setIsOpen] = useState(false);   const iconVariants = {     opened: {       rotate: 135     },     closed: {       rotate: 0     }   };   const menuVariants = {     opened: {       top: 0,       transition: {         when: "beforeChildren",         staggerChildren: 0.5       }     },     closed: {       top: "-90vh"     }   };   const linkVariants = {     opened: {       opacity: 1,       y: 50     },     closed: {       opacity: 0,       y: 0     }   };

We create an isOpen state that will be used to check if the Navbar is open or not. We create 3 variant objects, iconVariants, menuVariants, and linkVariants where we define the animations for the SvgBox, Nav, and Link motion components respectively. The iconVariants is used to rotate the SvgBox 135deg when it’s hovered over. We don’t need to add “deg” to the value. In the menuVariants, we control the top position of the Nav like you would using the position property in CSS. We toggle the top position of the Nav based on the isOpen state.

With variants, we can create timing relationships between parent and children motion components. We define the relationship between parent Nav and its child, Link using the when property in the transition object. Here, set it to beforeChildren, so the parent component’s animations will finish before the child’s animation begins.

Using the staggerChildren property, we set a timing order for each link. Each link will take 0.5 seconds to appear one after the other. This creates a nice visual cue when the Nav is opened. In the linkVariants we animate the opacity and the vertical position of each link.

<div className="App">       <Header>         <SvgBox           variants={iconVariants}           animate={isOpen ? "opened" : "closed"}           onClick={() => setIsOpen(!isOpen)}         >           <svg             width="24"             height="24"             viewBox="0 0 24 24"             fill="none"             xmlns="http://www.w3.org/2000/svg"           >             <path               d="M12 4C11.4477 4 11 4.44772 11 5V11H5C4.44772 11 4 11.4477 4 12C4 12.5523 4.44772 13 5 13H11V19C11 19.5523 11.4477 20 12 20C12.5523 20 13 19.5523 13 19V13H19C19.5523 13 20 12.5523 20 12C20 11.4477 19.5523 11 19 11H13V5C13 4.44772 12.5523 4 12 4Z"               fill="#fff"             />           </svg>         </SvgBox>       </Header>       <Nav         initial={false}         variants={menuVariants}         animate={isOpen ? "opened" : "closed"}       >         <Link variants={linkVariants}>home</Link>         <Link variants={linkVariants}>about</Link>         <Link variants={linkVariants}>gallery</Link>       </Nav> </div>

Here, we pass in the variants to their respective components. In the SvgBox, we toggle the state of isOpen whenever it’s clicked, then conditionally animate it based on the state. Like the SvgBox, we conditionally animate the Nav and the Links based on isOpen‘s state.

Animated Modal

We’ll build a modal component and learn about Framer Motion’s AnimatePresence, and how it allows us animate elements as they leave the DOM.

Components:

  • App.js: we set up the showModal state here.
  • Modal.jsx: the actual animation work takes place here.
  • Styles.js: create, style, and export the motion components. The components are styled using styled-components.

Let’s look into App.js

import { ToggleButton, Container } from "./Styles"; import Modal from "./Modal";  function App() {   const [showModal, setShowModal] = useState(false);   const toggleModal = () => {     setShowModal(!showModal);   };   return (     <Container>       <ToggleButton         initial={{ x: -700 }}         animate={{           x: 0,           transition: { duration: 0.5 }         }}         onClick={toggleModal}       >         Toggle Modal       </ToggleButton>       <Modal showModal={showModal} />     </Container>   ); }

We create a showModal state that will be used to conditionally render the modal. The toggleModal function will toggle the state whenever the ToggleButton is clicked. ToggleButton is a motion component, so we can define animations for it. When it mounts, it slides in from the left. This animation runs for 0.5 seconds. We also pass in the showModal state to the Modal through props.

Now, Modal.jsx

import { AnimatePresence } from "framer-motion"; import { ModalBox, ModalContent, Container } from "./Styles";  <Container>   <AnimatePresence>     {showModal && (       <ModalBox         initial={{ opacity: 0, y: 60, scale: 0.3 }}         animate={{           opacity: 1,           y: 0,           scale: 1,           transition: { type: "spring", stiffness: 300 }         }}         exit={{ opacity: 0, scale: 0.5, transition: { duration: 0.6 } }}         >         <ModalContent           initial={{ y: -30, opacity: 0 }}           animate={{ y: 0, opacity: 1, transition: { delay: 1 } }}         >            Modal content!!!!         </ModalContent>       </ModalBox>     )}   </AnimatePresence> </Container>

We import AnimatePresence from framer-motion. It allows us to set exit animations for components when they leave DOM. We conditionally render the Modal based on the showModal state. We define the animations for the ModalBox and ModalContent through their initial and animate props. There’s also a new prop here, exit. Having AnimatePresence as a wrapper allows us to add exit animations to ModalBox in the exit prop.

Scroll Animation

We’ll use a combination of the useAnimation hook and react-intersection-observer to create scroll-triggered animations.

Components

  • App.js: we set up the animations for the Box component and render it in App
  • Styles.js: create, style, and export the motion components. The components are styled using styled-components.
import React, { useEffect } from "react"; import { useAnimation } from "framer-motion"; import { useInView } from "react-intersection-observer"; import { Container, H1,StyledBox } from "./Styles";  const BoxVariants = {   visible: { opacity: 1, x: 0, transition: { duration: 1 } },   hidden: { opacity: 0, x: 300 }, };  const Box = () => {   const controls = useAnimation();   const [ref, inView] = useInView();   useEffect(() => {     if (inView) {       controls.start("visible");     }   }, [controls, inView]);   return (     <StyledBox       ref={ref}       animate={controls}       initial="hidden"       variants={BoxVariants}     />   ); };

The useAnimation hook allows us to control the sequences in which our animations occur. We have access to controls.start and controls.stop methods that we can use to manually start and stop our animations. We pass in the initial hidden animaton to StyledBox. We pass in the controls we defined with the start method to StyledBox animate prop.

react-intersection-observer’s useInView hook allows us to track when a component is visible in the viewport. The useInView hook gives us access to ref, which we pass to the component we want to watch, and the inView boolean, that tells us if that element is inView or not. We use the useEffect to call controls.start whenever the element we’re watching, StyledBox is in view. We pass in controls and inView as useEffect’s dependencies. Also, we pass in the variants we defined, BoxVariants to StyledBox.

Hero Animation

We’ll build a cool hero banner animation using the useCycle hook. We’ll understand how useCycle allows us to cycle through animations.

import React, { useEffect } from "react"; import { useCycle } from "framer-motion"; import { Container, H1, HeroSection, Banner, TextBox } from "./Styles"; import { ReactComponent as BannerIllustration } from "./bighead.svg";  const H1Variants = {   initial: { y: -200, opacity: 0 },   animate: { y: 0, opacity: 1, transition: { delay: 1 } }, }; const TextVariants = {   initial: { x: 400 },   animate: { x: 0, transition: { duration: 0.5 } }, }; const BannerVariants = {   animationOne: { x: -250, opacity: 1, transition: { duration: 0.5 } },   animationTwo: {     y: [0, -20],     opacity: 1,     transition: { yoyo: Infinity, ease: "easeIn" },   }, };

We define 3 variants, H1Variants, TextVariants, and BannerVariants. However, our focus is BannerVariants. We define 2 animations, animationOne and animationTwo in BannerVariants. These are the animations we pass into the useCycle to cycle through.

const [animation, cycleAnimation] = useCycle("animationOne", "animationTwo");   useEffect(() => {     setTimeout(() => {       cycleAnimation();     }, 2000);   }, []);

useCycle works similar to the useState hook. In the destructured array, animation represents the animation that is active, whether animationOne or animationTwo. The cylceAnimation function that cycles between the animation we defined. We pass in the animations we want to cycle through into useCycle and call cylceAnimation after 2 seconds in useEffect.

<div className="App">       <Container>         <H1 variants={H1Variants} initial="initial" animate="animate">           Cool Hero Section Anmiation         </H1>         <HeroSection>           <TextBox variants={TextVariants} initial="initial" animate="animate">             Storage shed, troughs feed bale manure, is garden wheat oats at             augers. Bulls at rose garden cucumbers mice sunflower wheat in pig.             Chainsaw foal hay hook, herbs at combine harvester, children is             mallet. Goat goose hen horse. Pick up truck livestock, pets and             storage shed, troughs feed bale manure, is garden wheat oats at             augers. Lamb.           </TextBox>           <Banner variants={BannerVariants} animate={animation}>             <BannerIllustration />           </Banner>         </HeroSection>       </Container>     </div>

At the end of everything, we pass in the variants to their respective components and watch the magic happen. With this, the Banner will initially slide in from the right based on the animations we defined in animationOne, and after 2 seconds, cycleAnimation will be called which will trigger animationTwo.

As a wise Pig once said, “that’s all folks.”

Conclusion

We’ve gone through the basics of Framer Motion and seen some demo projects that give us a glimpse of the range of animations we can create. However, you can do so much more with it. I encourage you to dive into the docs and go wild.

Resources

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
18 Nov

How To Use Face Motion To Interact With Typography

by TBSCategories: News

Web designers are always looking for new ways to improve the presentation of a page’s content. Sometimes, this can lead to ingenious solutions or to interact with technologies that are often kept away from the design field. In this article we will bring typography in contact with Artificial Intelligence, using machine learning to detect such things as the proximity of the user’s face in order to improve the legibility of the text.

We will experiment on how to use face recognition with Tensorflow in order to extract some information from the camera, such as the distance between the screen and user’s face or the amount of people reading the page. Then, we will pass those data to CSS in order to adapt typography and to adjust the page layout.

What Is Tensorflow?

Tensorflow is an open-source platform from Google for Machine Learning. Machine Learning is a field of Computer Science that studies algorithms that learn to recognize complex relations and recurring patterns out of images, audio tracks, time series, natural text, and data in general. These algorithms generate mathematical models (also called trained models), which are a sort of schema that can be used to make decisions based on input data. If you’d like to approach the topic, Charlie Gerard wrote about ML for frontend developers here on Smashing Mag.

Tensorflow provides a lot of tools for AI developers, data scientists, mathematicians, but don’t panic if data analysis is not your daily bread! The good news is that you have not to be an expert to use it, as long as you are using pre-built models, just as we are going to.

Tensorflow models are available to be used on the Web with their JavaScript SDK.

Setup

In order to start using face recognition algorithms, we need to follow a few steps:

  • load the Tensorflow SDK.
  • load the Facemesh library which contains the mathematical model.
  • access the user’s camera and stream it to an HTML video element. Facemesh will analyze frames from the video tag to detect the presence of faces.

In this projects we are going to use Tensorflow via CDN, but it is also available on NPM if you prefer the bundler-way:

Tensorflow does not do the trick itself, so we need to add Facemesh, a library that is built on the top of the ML framework and provides an already trained model for face recognition:

<script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/facemesh"></script>

The next step is to setup the Facemesh library in order to load the trained model and to define the function that will evaluate face data from a video stream:

// create and place the video const video = document.createElement('video'); document.body.appendChild(video);  // setup facemesh const model = await facemesh.load({     backend: 'wasm',     maxFaces: 1, });  async function detectFaces() {     const faces = await model.estimateFaces(video);     console.log(faces);      // recursively detect faces     requestAnimationFrame(detectFaces); }

Now we are ready to ask the user the permission to access to its camera stream using a video tag:

// enable autoplay video.setAttribute('autoplay', ''); video.setAttribute('muted', ''); video.setAttribute('playsinline', ''); // start face detection when ready video.addEventListener('canplaythrough', detectFaces); // stream the camera video.srcObject = await navigator.mediaDevices.getUserMedia({     audio: false,     video: {         facingMode: 'user',     }, }); // let’s go! video.play();

The navigator.mediaDevices.getUserMedia method will prompt the permission and will start to stream the camera into the video element. Once accepted, the camera will start to stream to the video tag, while the browser console will log face information detected by Facemesh.

Please note that camera permissions require a secure https connection or localhost: you can not simply open the index.html file. If you are not sure how to set up a local server checkout http-server for Node or follow this guide for Python or this one for PHP.

Case 1. Adjust Typography Using The Smartphone Camera

We navigate the web everywhere with our smartphone. There was a time, not so long ago, where we used to take crowded trains or buses and we kept the smartphone very close to our eyes because there was no space. In many moments and places of our day, we often change the position and the inclination of the smartphone, even if we are watching the same site. The distance between eyes and smartphone affects our reading capabilities. Evaluating that distance we can adjust microtypography in order to optimize glyphs for a closer or more distant reading.

Face detection means, of course, eyes position detection too. We can use data provided by Facemesh to calculate the size of our face in relation with the whole picture captured by the camera. We can assume that the larger our face, the closer we are to the screen. We can set up a scale from 0 (one arm distant apart — the face approximately occupies one half of the camera) to 1 (glued to the screen) and detect the current value with a division of segments:

async function detectFaces() {     const faces = await model.estimateFaces(video);     if (faces.length === 0) {         // is somebody out there?         return requestAnimationFrame(detectFaces);     }      const [face] = faces;      // extract face surface corners     let { bottomRight, topLeft} = face.boundingBox;      // calculate face surface size     let width = bottomRight[0] - topLeft[0];     let height = bottomRight[1] - topLeft[1];     let videoWidth = video.videoWidth;     let videoHeight = video.videoHeight;     let adjustWidth = videoWidth / 2;     let adjustHeight = videoHeight / 2;      // detect the ratio between face and full camera picture     let widthRatio = Math.max(Math.min((width - adjustWidth) / (videoWidth - adjustWidth), 1), 0);     let heightRatio = Math.max(Math.min((height - adjustHeight) / (videoHeight - adjustHeight), 1), 0);     let ratio = Math.max(widthRatio, heightRatio);       // recursively detect faces     requestAnimationFrame(detectFaces); }

Now that we have calculated the ratio, it’s time to make some magic happens, passing the value to the stylesheet:

document.documentElement.style.setProperty('--user-distance', ratio);

With this value and a bit of calc we could easily apply slight changes to font weight, size, and maybe style too, but we can do something even better. Using a variable font, a font that has parameterized shapes and spaces of the glyphs, we can adjust the perception of every glyph by updating its optical size variation.

Since every variable font uses its own scale for optical size values, we need to relate our ratio value to that scale. Furthermore, we may want to move just between a subset of available optical size, in order to provide just little enhancements.

.main-text {     --min-opsz: 10;     --max-opsz: 15;     --opsz: calc(var(--min-opsz) + (var(--user-distance) * (var(--max-opsz) - var(--min-opsz))));      ...     font-family: 'Amstelvar', serif;     font-variation-settings: 'opsz' var(--opsz); }

You can see it live here. Please note that this example is just a demonstration of how the technology works. Typographical changes should be almost imperceptible to the user’s eyes in order to really provide a better reader experience. Here we leveraged glyphs shapes, but using colors to increase or decrease contrasts is just another good solution to try. Another experiment was to detect the angle of the face in order to calculate the perspective of the reading, modifying ascenders, descenders ad the height of letters:

When a large number of people are watching, we need to privilege the long-form reading context, giving more space to the main column, increasing its font size, and removing disturbing elements. To do that, we increase the number of spanned columns, moving the aside below the main text.

:root {     --watching: 10; }  section {     /** The maximum number of people watching for the default layout */     --switch: 10;     /** The default number of columns for the text */     --text: 8;     /** The default number of columns for the aside */     --aside: 4;      grid-template-columns: repeat(calc(var(--text) + var(--aside)), 1fr); }  section article {     /**      * Kinda magic calculation.      * When the number of people watching is lower than --switch, it returns -2      * When the number of people watching is greater than --switch, it returns -1      * We are going to use this number for negative span calculation      */     --layout: calc(min(2, (max(var(--switch), var(--watching)) - var(--switch) + 1)) - 3);     /**      * Calculate the position of the end column.      * When --layout is -1, the calculation just returns -1      * When --layout is -2, the calculation is lower than -1      */     --layout-span: calc((var(--aside) * var(--layout)) + var(--aside) - 1);     /**      * Calculate the maximum index of the last column (the one "before" the aside)      */     --max-span: calc(-1 * var(--aside) - 1);     /**      * get the max between --layout-span and the latest column index.      * -1 means full width      * --max-span means default layout      */     --span: max(var(--max-span), var(--span));      grid-column-start: 1;     grid-column-end: var(--span); }

Viceversa, when a small group of students is experiencing the text near the board, we could give more details, such as media files and interactive action triggers.

Beyond Face Recognition

The cases we faced (😉) are just two examples of how we can use face recognition technology for layout or typographical scopes. Tensorflow provides other models and libraries that can transform the camera stream into variables for our pages. Furthermore, we should not forget that in our smartphones there are a lot of other sensors that we could exploit using the Sensor APIs: GPS, accelerometer, ambient light, etc.

Since mood influences the way we read, study and search for information, with machine learning we can also analyze user’s expressions to switch from minimal to detailed layouts according to the user’s spirits.

For many years we have been used to using CSS Media queries for responsive web design. However, the size of the viewport is only one of the variables of the user experience. Recently, a new kind of media query designed to respect user preferences landed the browsers, such as the prefers-color-scheme and prefers-reduced-motion. This gives designers and developers a way to move a step forward in web design practices, allowing the web page to adapt to the whole environment instead of just the user’s device. In the age of big data, we have the opportunity to go beyond responsive and adaptive design. Our web pages can finally “leave the screen” and become part of the user’s global experience. Interaction design is going to involve all these possibilities, so keeping experimenting with the possible combinations between technology and web design will be crucial in the following years.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
18 Nov

How To Use Face Motion To Interact With Typography

by TBSCategories: News

Web designers are always looking for new ways to improve the presentation of a page’s content. Sometimes, this can lead to ingenious solutions or to interact with technologies that are often kept away from the design field. In this article we will bring typography in contact with Artificial Intelligence, using machine learning to detect such things as the proximity of the user’s face in order to improve the legibility of the text.

We will experiment on how to use face recognition with Tensorflow in order to extract some information from the camera, such as the distance between the screen and user’s face or the amount of people reading the page. Then, we will pass those data to CSS in order to adapt typography and to adjust the page layout.

What Is Tensorflow?

Tensorflow is an open-source platform from Google for Machine Learning. Machine Learning is a field of Computer Science that studies algorithms that learn to recognize complex relations and recurring patterns out of images, audio tracks, time series, natural text, and data in general. These algorithms generate mathematical models (also called trained models), which are a sort of schema that can be used to make decisions based on input data. If you’d like to approach the topic, Charlie Gerard wrote about ML for frontend developers here on Smashing Mag.

Tensorflow provides a lot of tools for AI developers, data scientists, mathematicians, but don’t panic if data analysis is not your daily bread! The good news is that you have not to be an expert to use it, as long as you are using pre-built models, just as we are going to.

Tensorflow models are available to be used on the Web with their JavaScript SDK.

Setup

In order to start using face recognition algorithms, we need to follow a few steps:

  • load the Tensorflow SDK.
  • load the Facemesh library which contains the mathematical model.
  • access the user’s camera and stream it to an HTML video element. Facemesh will analyze frames from the video tag to detect the presence of faces.

In this projects we are going to use Tensorflow via CDN, but it is also available on NPM if you prefer the bundler-way:

Tensorflow does not do the trick itself, so we need to add Facemesh, a library that is built on the top of the ML framework and provides an already trained model for face recognition:

<script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/facemesh"></script>

The next step is to setup the Facemesh library in order to load the trained model and to define the function that will evaluate face data from a video stream:

// create and place the video const video = document.createElement('video'); document.body.appendChild(video);  // setup facemesh const model = await facemesh.load({     backend: 'wasm',     maxFaces: 1, });  async function detectFaces() {     const faces = await model.estimateFaces(video);     console.log(faces);      // recursively detect faces     requestAnimationFrame(detectFaces); }

Now we are ready to ask the user the permission to access to its camera stream using a video tag:

// enable autoplay video.setAttribute('autoplay', ''); video.setAttribute('muted', ''); video.setAttribute('playsinline', ''); // start face detection when ready video.addEventListener('canplaythrough', detectFaces); // stream the camera video.srcObject = await navigator.mediaDevices.getUserMedia({     audio: false,     video: {         facingMode: 'user',     }, }); // let’s go! video.play();

The navigator.mediaDevices.getUserMedia method will prompt the permission and will start to stream the camera into the video element. Once accepted, the camera will start to stream to the video tag, while the browser console will log face information detected by Facemesh.

Please note that camera permissions require a secure https connection or localhost: you can not simply open the index.html file. If you are not sure how to set up a local server checkout http-server for Node or follow this guide for Python or this one for PHP.

Case 1. Adjust Typography Using The Smartphone Camera

We navigate the web everywhere with our smartphone. There was a time, not so long ago, where we used to take crowded trains or buses and we kept the smartphone very close to our eyes because there was no space. In many moments and places of our day, we often change the position and the inclination of the smartphone, even if we are watching the same site. The distance between eyes and smartphone affects our reading capabilities. Evaluating that distance we can adjust microtypography in order to optimize glyphs for a closer or more distant reading.

Face detection means, of course, eyes position detection too. We can use data provided by Facemesh to calculate the size of our face in relation with the whole picture captured by the camera. We can assume that the larger our face, the closer we are to the screen. We can set up a scale from 0 (one arm distant apart — the face approximately occupies one half of the camera) to 1 (glued to the screen) and detect the current value with a division of segments:

async function detectFaces() {     const faces = await model.estimateFaces(video);     if (faces.length === 0) {         // is somebody out there?         return requestAnimationFrame(detectFaces);     }      const [face] = faces;      // extract face surface corners     let { bottomRight, topLeft} = face.boundingBox;      // calculate face surface size     let width = bottomRight[0] - topLeft[0];     let height = bottomRight[1] - topLeft[1];     let videoWidth = video.videoWidth;     let videoHeight = video.videoHeight;     let adjustWidth = videoWidth / 2;     let adjustHeight = videoHeight / 2;      // detect the ratio between face and full camera picture     let widthRatio = Math.max(Math.min((width - adjustWidth) / (videoWidth - adjustWidth), 1), 0);     let heightRatio = Math.max(Math.min((height - adjustHeight) / (videoHeight - adjustHeight), 1), 0);     let ratio = Math.max(widthRatio, heightRatio);       // recursively detect faces     requestAnimationFrame(detectFaces); }

Now that we have calculated the ratio, it’s time to make some magic happens, passing the value to the stylesheet:

document.documentElement.style.setProperty('--user-distance', ratio);

With this value and a bit of calc we could easily apply slight changes to font weight, size, and maybe style too, but we can do something even better. Using a variable font, a font that has parameterized shapes and spaces of the glyphs, we can adjust the perception of every glyph by updating its optical size variation.

Since every variable font uses its own scale for optical size values, we need to relate our ratio value to that scale. Furthermore, we may want to move just between a subset of available optical size, in order to provide just little enhancements.

.main-text {     --min-opsz: 10;     --max-opsz: 15;     --opsz: calc(var(--min-opsz) + (var(--user-distance) * (var(--max-opsz) - var(--min-opsz))));      ...     font-family: 'Amstelvar', serif;     font-variation-settings: 'opsz' var(--opsz); }

You can see it live here. Please note that this example is just a demonstration of how the technology works. Typographical changes should be almost imperceptible to the user’s eyes in order to really provide a better reader experience. Here we leveraged glyphs shapes, but using colors to increase or decrease contrasts is just another good solution to try. Another experiment was to detect the angle of the face in order to calculate the perspective of the reading, modifying ascenders, descenders ad the height of letters:

When a large number of people are watching, we need to privilege the long-form reading context, giving more space to the main column, increasing its font size, and removing disturbing elements. To do that, we increase the number of spanned columns, moving the aside below the main text.

:root {     --watching: 10; }  section {     /** The maximum number of people watching for the default layout */     --switch: 10;     /** The default number of columns for the text */     --text: 8;     /** The default number of columns for the aside */     --aside: 4;      grid-template-columns: repeat(calc(var(--text) + var(--aside)), 1fr); }  section article {     /**      * Kinda magic calculation.      * When the number of people watching is lower than --switch, it returns -2      * When the number of people watching is greater than --switch, it returns -1      * We are going to use this number for negative span calculation      */     --layout: calc(min(2, (max(var(--switch), var(--watching)) - var(--switch) + 1)) - 3);     /**      * Calculate the position of the end column.      * When --layout is -1, the calculation just returns -1      * When --layout is -2, the calculation is lower than -1      */     --layout-span: calc((var(--aside) * var(--layout)) + var(--aside) - 1);     /**      * Calculate the maximum index of the last column (the one "before" the aside)      */     --max-span: calc(-1 * var(--aside) - 1);     /**      * get the max between --layout-span and the latest column index.      * -1 means full width      * --max-span means default layout      */     --span: max(var(--max-span), var(--span));      grid-column-start: 1;     grid-column-end: var(--span); }

Viceversa, when a small group of students is experiencing the text near the board, we could give more details, such as media files and interactive action triggers.

Beyond Face Recognition

The cases we faced (😉) are just two examples of how we can use face recognition technology for layout or typographical scopes. Tensorflow provides other models and libraries that can transform the camera stream into variables for our pages. Furthermore, we should not forget that in our smartphones there are a lot of other sensors that we could exploit using the Sensor APIs: GPS, accelerometer, ambient light, etc.

Since mood influences the way we read, study and search for information, with machine learning we can also analyze user’s expressions to switch from minimal to detailed layouts according to the user’s spirits.

For many years we have been used to using CSS Media queries for responsive web design. However, the size of the viewport is only one of the variables of the user experience. Recently, a new kind of media query designed to respect user preferences landed the browsers, such as the prefers-color-scheme and prefers-reduced-motion. This gives designers and developers a way to move a step forward in web design practices, allowing the web page to adapt to the whole environment instead of just the user’s device. In the age of big data, we have the opportunity to go beyond responsive and adaptive design. Our web pages can finally “leave the screen” and become part of the user’s global experience. Interaction design is going to involve all these possibilities, so keeping experimenting with the possible combinations between technology and web design will be crucial in the following years.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
17 Nov

How To Use Face Motion To Interact With Typography

by TBSCategories: News

Web designers are always looking for new ways to improve the presentation of a page’s content. Sometimes, this can lead to ingenious solutions or to interact with technologies that are often kept away from the design field. In this article we will bring typography in contact with Artificial Intelligence, using machine learning to detect such things as the proximity of the user’s face in order to improve the legibility of the text.

We will experiment on how to use face recognition with Tensorflow in order to extract some information from the camera, such as the distance between the screen and user’s face or the amount of people reading the page. Then, we will pass those data to CSS in order to adapt typography and to adjust the page layout.

What Is Tensorflow?

Tensorflow is an open-source platform from Google for Machine Learning. Machine Learning is a field of Computer Science that studies algorithms that learn to recognize complex relations and recurring patterns out of images, audio tracks, time series, natural text, and data in general. These algorithms generate mathematical models (also called trained models), which are a sort of schema that can be used to make decisions based on input data. If you’d like to approach the topic, Charlie Gerard wrote about ML for frontend developers here on Smashing Mag.

Tensorflow provides a lot of tools for AI developers, data scientists, mathematicians, but don’t panic if data analysis is not your daily bread! The good news is that you have not to be an expert to use it, as long as you are using pre-built models, just as we are going to.

Tensorflow models are available to be used on the Web with their JavaScript SDK.

Setup

In order to start using face recognition algorithms, we need to follow a few steps:

  • load the Tensorflow SDK.
  • load the Facemesh library which contains the mathematical model.
  • access the user’s camera and stream it to an HTML video element. Facemesh will analyze frames from the video tag to detect the presence of faces.

In this projects we are going to use Tensorflow via CDN, but it is also available on NPM if you prefer the bundler-way:

Tensorflow does not do the trick itself, so we need to add Facemesh, a library that is built on the top of the ML framework and provides an already trained model for face recognition:

<script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/facemesh"></script>

The next step is to setup the Facemesh library in order to load the trained model and to define the function that will evaluate face data from a video stream:

// create and place the video const video = document.createElement('video'); document.body.appendChild(video);  // setup facemesh const model = await facemesh.load({     backend: 'wasm',     maxFaces: 1, });  async function detectFaces() {     const faces = await model.estimateFaces(video);     console.log(faces);      // recursively detect faces     requestAnimationFrame(detectFaces); }

Now we are ready to ask the user the permission to access to its camera stream using a video tag:

// enable autoplay video.setAttribute('autoplay', ''); video.setAttribute('muted', ''); video.setAttribute('playsinline', ''); // start face detection when ready video.addEventListener('canplaythrough', detectFaces); // stream the camera video.srcObject = await navigator.mediaDevices.getUserMedia({     audio: false,     video: {         facingMode: 'user',     }, }); // let’s go! video.play();

The navigator.mediaDevices.getUserMedia method will prompt the permission and will start to stream the camera into the video element. Once accepted, the camera will start to stream to the video tag, while the browser console will log face information detected by Facemesh.

Please note that camera permissions require a secure https connection or localhost: you can not simply open the index.html file. If you are not sure how to set up a local server checkout http-server for Node or follow this guide for Python or this one for PHP.

Case 1. Adjust Typography Using The Smartphone Camera

We navigate the web everywhere with our smartphone. There was a time, not so long ago, where we used to take crowded trains or buses and we kept the smartphone very close to our eyes because there was no space. In many moments and places of our day, we often change the position and the inclination of the smartphone, even if we are watching the same site. The distance between eyes and smartphone affects our reading capabilities. Evaluating that distance we can adjust microtypography in order to optimize glyphs for a closer or more distant reading.

Face detection means, of course, eyes position detection too. We can use data provided by Facemesh to calculate the size of our face in relation with the whole picture captured by the camera. We can assume that the larger our face, the closer we are to the screen. We can set up a scale from 0 (one arm distant apart — the face approximately occupies one half of the camera) to 1 (glued to the screen) and detect the current value with a division of segments:

async function detectFaces() {     const faces = await model.estimateFaces(video);     if (faces.length === 0) {         // is somebody out there?         return requestAnimationFrame(detectFaces);     }      const [face] = faces;      // extract face surface corners     let { bottomRight, topLeft} = face.boundingBox;      // calculate face surface size     let width = bottomRight[0] - topLeft[0];     let height = bottomRight[1] - topLeft[1];     let videoWidth = video.videoWidth;     let videoHeight = video.videoHeight;     let adjustWidth = videoWidth / 2;     let adjustHeight = videoHeight / 2;      // detect the ratio between face and full camera picture     let widthRatio = Math.max(Math.min((width - adjustWidth) / (videoWidth - adjustWidth), 1), 0);     let heightRatio = Math.max(Math.min((height - adjustHeight) / (videoHeight - adjustHeight), 1), 0);     let ratio = Math.max(widthRatio, heightRatio);       // recursively detect faces     requestAnimationFrame(detectFaces); }

Now that we have calculated the ratio, it’s time to make some magic happens, passing the value to the stylesheet:

document.documentElement.style.setProperty('--user-distance', ratio);

With this value and a bit of calc we could easily apply slight changes to font weight, size, and maybe style too, but we can do something even better. Using a variable font, a font that has parameterized shapes and spaces of the glyphs, we can adjust the perception of every glyph by updating its optical size variation.

Since every variable font uses its own scale for optical size values, we need to relate our ratio value to that scale. Furthermore, we may want to move just between a subset of available optical size, in order to provide just little enhancements.

.main-text {     --min-opsz: 10;     --max-opsz: 15;     --opsz: calc(var(--min-opsz) + (var(--user-distance) * (var(--max-opsz) - var(--min-opsz))));      ...     font-family: 'Amstelvar', serif;     font-variation-settings: 'opsz' var(--opsz); }

You can see it live here. Please note that this example is just a demonstration of how the technology works. Typographical changes should be almost imperceptible to the user’s eyes in order to really provide a better reader experience. Here we leveraged glyphs shapes, but using colors to increase or decrease contrasts is just another good solution to try. Another experiment was to detect the angle of the face in order to calculate the perspective of the reading, modifying ascenders, descenders ad the height of letters:

When a large number of people are watching, we need to privilege the long-form reading context, giving more space to the main column, increasing its font size, and removing disturbing elements. To do that, we increase the number of spanned columns, moving the aside below the main text.

:root {     --watching: 10; }  section {     /** The maximum number of people watching for the default layout */     --switch: 10;     /** The default number of columns for the text */     --text: 8;     /** The default number of columns for the aside */     --aside: 4;      grid-template-columns: repeat(calc(var(--text) + var(--aside)), 1fr); }  section article {     /**      * Kinda magic calculation.      * When the number of people watching is lower than --switch, it returns -2      * When the number of people watching is greater than --switch, it returns -1      * We are going to use this number for negative span calculation      */     --layout: calc(min(2, (max(var(--switch), var(--watching)) - var(--switch) + 1)) - 3);     /**      * Calculate the position of the end column.      * When --layout is -1, the calculation just returns -1      * When --layout is -2, the calculation is lower than -1      */     --layout-span: calc((var(--aside) * var(--layout)) + var(--aside) - 1);     /**      * Calculate the maximum index of the last column (the one "before" the aside)      */     --max-span: calc(-1 * var(--aside) - 1);     /**      * get the max between --layout-span and the latest column index.      * -1 means full width      * --max-span means default layout      */     --span: max(var(--max-span), var(--span));      grid-column-start: 1;     grid-column-end: var(--span); }

Viceversa, when a small group of students is experiencing the text near the board, we could give more details, such as media files and interactive action triggers.

Beyond Face Recognition

The cases we faced (😉) are just two examples of how we can use face recognition technology for layout or typographical scopes. Tensorflow provides other models and libraries that can transform the camera stream into variables for our pages. Furthermore, we should not forget that in our smartphones there are a lot of other sensors that we could exploit using the Sensor APIs: GPS, accelerometer, ambient light, etc.

Since mood influences the way we read, study and search for information, with machine learning we can also analyze user’s expressions to switch from minimal to detailed layouts according to the user’s spirits.

For many years we have been used to using CSS Media queries for responsive web design. However, the size of the viewport is only one of the variables of the user experience. Recently, a new kind of media query designed to respect user preferences landed the browsers, such as the prefers-color-scheme and prefers-reduced-motion. This gives designers and developers a way to move a step forward in web design practices, allowing the web page to adapt to the whole environment instead of just the user’s device. In the age of big data, we have the opportunity to go beyond responsive and adaptive design. Our web pages can finally “leave the screen” and become part of the user’s global experience. Interaction design is going to involve all these possibilities, so keeping experimenting with the possible combinations between technology and web design will be crucial in the following years.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
23 Oct

Designing With Reduced Motion For Motion Sensitivities

by TBSCategories: News

CSS has recently added features that allow us to recognize certain user preferences and qualities of the user’s current environment. One of those new features, specifically the prefers-reduced-motion media feature, can be especially useful for designing more inclusive motion on the web.

A few years back, I wrote an article about designing safer web animation for motion sensitivity and the limited options we had at the time to design safe motion on the web. Some things have remained the same since that original article, like the types of motion effects that can be triggering, and the importance of context and user expectations. But what has changed is the existence and support of the prefers-reduced-motion media feature. That makes a big difference in how we can design the motion in our work to be inclusive and accessible.

Why Reduce Motion?

The release of iOS7 back in 2013 sparked a realization throughout the digital design world that some motion on screen — even if it was part of an interface — could have physical consequences for people with motion sensitivities. In the years since then, the major mobile and desktop operating systems have added functionality for people to reduce the amount of motion they encounter in their operating systems.

Articles like “Your Interactive Is Making Me Sick” and “Accessibility For Vestibular Disorders” share first-hand stories of how our design choices, especially around motion, can have physical consequences for those with motion sensitivities. The root causes of these motion sensitivities can vary greatly between individuals. For some, it’s rooted in a vestibular disorder, while for others it might stem from migraines or other factors. What’s triggering can also vary from person to person, or even from day to day for some. The physical symptoms individuals experience as a result of that triggering motion can range from slight dizziness or headaches to nausea or worse.

The design choices we make around animation in our work directly impacts how our work affects people with motion sensitivities. Knowing what kinds of motion are potentially triggering, and how we can mitigate them with our design choices, helps us design experiences that are safe for our audience and won’t cause unintended harm. Animation still absolutely can have a positive impact on our UX efforts, but it’s up to us to make sure we use it responsibly, just like we try to use our other design tools responsibly.

Prefers Reduced Motion On The Web

The prefers-reduced-motion media feature now has strong browser support. It’s supported in current versions of Edge, Firefox, Chrome, Safari, Opera, iOS Safari, as well as on Android Browsers and Chrome for Android. The level of support we have today makes it something that you can absolutely use in production. Also, if someone’s browser doesn’t support this feature, nothing bad happens, it will just be ignored and things will carry on as before.

On the development side, we can test for prefers-reduced-motion in the same way that we would use any other media query in CSS or JavaScript to find out if reduced motion has been requested.

In CSS that will look something like this: 

@media (prefers-reduced-motion: reduce)  {     /* reduced behaviour */    }

And in JavaScript: 

let motionQuery = matchMedia('(prefers-reduced-motion)');  const handleReduceMotionChanged = () => {   if (motionQuery.matches) //reduced behaviour; }  motionQuery.addListener(handleReduceMotionChanged); handleReduceMotionChanged()

Whichever way you choose to access it, this media query will return one of two values: no-preference (false), or reduce (true). Once retrieved, you can use these values to inform what you display in the browser.

Of the two values that can be returned, the only one we can be sure has been set intentionally is the reduce (true) value. No-preference (false) can mean that the person in question is fine with all types of motion, or it could mean that that preference just hasn’t been set yet. This makes any approach that equates the value of no preference (false) to the person in question opting in to all levels of motion unreliable. Because of this, the better approach is to reduce potentially triggering motion effects when a value of reduce (true) is returned.

For example, here the looping bounce animation is replaced with a fade in animation when reduced motion is requested:

/* A constant bouncing motion effect applied to the title */ h2 {   animation: bouncing 1.5s linear infinite alternate; }  /* Replace it with a safer effect when prefers-reduced-motion returns true */ @media (prefers-reduced-motion) {   h2 {   animation: fade 0.5s ease-in both;    }

Reduced Motion From The Users’ Perspective

Most major operating systems allow people to set their preferences in their system settings. The exact wording and location of the settings vary, but the preference can be set on iOS, OSX, Windows, and Android operating systems.

The Prefers Reduced Motion Media Feature In Practice

Deciding how to put the prefers-reduced-motion media feature to use is where we have space for creating solutions that best fit the context of our products and content. For most web projects, you’ll want to first identify any potentially triggering motion effects on your site, and then use the prefers-reduced-motion media feature to provide a reduced version of that effect.

Let’s look at each step in more detail.

Identifying Potentially Triggering Motion

To find any potentially triggering motion you might have, go through some typical user flows for your site or product and take a closer look at the motion effects used: Do you have any interactions that have large movements? Any large zooms, spinning effects, or parallax effects? All of those types of animated effects are very likely to be problematic for people with motion sensitivities. In contrast, animated effects like color fades, opacity changes and small changes in scale are unlikely to be problematic. If in doubt, it can’t hurt to add the effect in question to your “to reduce” list to err on the side of caution.

The Web Content Accessibility Guidelines recommend providing a reduced version for any “motion that creates the illusion of movement…that is not essential to the content’s meaning”. I think it’s helpful to see some examples too, especially if you don’t consider yourself to be sensitive to motion on screen. I cover examples of potentially triggering motion in my previous article and this post on the Webkit blog has some too. Chances are, unless your site relies heavily on motion, you’ll end up with a fairly short list of effects to focus on here.

Create A Reduced Motion Version

Next, you want to determine the most appropriate reduced motion condition for these potentially triggering effects. Can the animation easily be adjusted to use a non-motion effect like an opacity fade or crossfade for reduced motion requests? Would pausing the motion or removing the effect entirely for reduced motion preserve the meaning of the content?

The role of the motion in question will be an important factor in deciding what the most appropriate reduced version would be. You don’t want to unintentionally remove content or degrade the overall experience. Here are a few examples of what might work well for the potentially triggering effects you find:

Large Page Transitions

Large page transition effects can likely be replaced with a crossfade effect for a reduced motion mode. The same is usually true for large zooming or spinning transitions that transition between different states or views.

Animated Illustrations

Animated illustrations, on the other hand, might be best replaced with a static version for reduced motion if they are mostly for personality or branding effect. You’ll want to make sure the static version is still meaningful, and the arrangement that has the most meaning may not always be the very beginning or very end of the animation. Adding in functionality to play animated illustrations on demand for reduced motion could also be useful by allowing people to play the animation when they’re ready for it.

Don’t forget to consider the motion in your animated gifs or auto-playing videos here as well. These can also contain potentially triggering motion and would need a reduced version if they do.

Parallax Effects

Parallax effects and exaggerated smooth scrolling effects are universally triggering for folks with motion sensitivities, so those should be significantly reduced or entirely removed for reduced motion. (Every single person I’ve talked to in my research on this has called out parallax specifically as being a problem for them.) Smooth scrolling effects can be replaced with the default browser anchor link behaviour as described here by Eric Bailey. Removing parallax effects for reduced motion is the ideal solution, but make sure to check that all the necessary content is still visible and usable with the parallax removed.

In most cases substituting the potentially triggering effect with a safer effect for reduced motion is the best way to preserve as much of the content’s intent and usability as possible. Luckily, substituting a reduced effect can be pretty straight forward too.

An Example Of Reducing Motion

For example, let’s say I flagged this header animation as potentially triggering when I went through my site. The motion is large enough to create the illusion of motion, so it’s likely to be triggering, and the multiple directions of motion are also likely to be problematic. It’s definitely one I’d put on my list of effects that need a reduced version when reviewing my site.

The Airpods Pro page also responds to reduced motion preferences, but in a very different way because of the content and effects used. Almost all of the motion on the page could be potentially triggering since it has a lot of big zooming movements and parallax-style effects. When reduced motion is requested, all the parallax and large motion effects are removed, but they do more than just pause or remove the animations. The version you see with reduced motion selected has been designed with care to preserve the same content and meaning from the full motion experience. (Here’s a video of The Airpods Pro site both with and without reduced motion selected for reference.)

Add Custom Toggles For Motion-Heavy Experiences

I mentioned above that most “task-based” sites likely have only a handful of animations that might be triggering and need a reduced version. But those aren’t the only kind of web sites out there on the web. Projects that involve a large amount of motion, like sites that are meant more for storytelling or creating an experience might benefit from a slightly different approach.

For projects like these, it would be difficult to make a list of potentially triggering motions and provide a reduced alternative for each because almost all of the motion used could be potentially triggering. Plus, the motion is very much part of the content and its meaning. Designing a reduced motion mode for these types of sites will take a more global approach and more effort to be sure the meaning of your content is preserved even as motion is reduced.

For these highly animated experience sites, providing a visible custom motion toggle is a useful thing to include. This will allow people who may not yet know about the reduced motion setting, or who are experiencing some motion sensitivity at that moment in time, to quickly adjust the experience. A motion toggle provides a way for motion-sensitive folks to participate in your content in a way that won’t make them sick. That’s definitely better for everyone involved than them having to avoid your site entirely.

Context Is A Key Factor

Remember that context also plays a big role here. No one wants to be surprised by large amounts of motion where they don’t expect it. If you’re visiting a site billed as a highly interactive storytelling experience you’ll have very different expectations than when you’re visiting your bank’s web site. Both of those sites certainly could feature large amounts of animation, but it would be an unexpected surprise on the bank site.

Building A Custom Motion Toggle

The idea of a custom toggle is something that I mentioned back in my 2015 article, but today it’s a much more viable option. On today’s web, we can create one with more ease, and even make a smarter toggle than we could have just a few years ago.

Marcy Sutton has a great example of how a modern custom motion toggle could work in this CodePen. (This example is part of her course on making accessible web apps, which is also very much worth checking out.) Her example uses a toggle to remove all motion because it only includes one animation, but this approach can be used to provide reduced motion effects across an entire application or site following the same logic as well.

The key feature of this approach is how nicely Marcy ties it in with modern web technology, i.e. prefers reduced motion and local storage. When using this approach, if someone comes to your site with reduced motion requested, they automatically get the reduced motion version without having to manually activate the toggle as well. And if someone invokes the toggle to reduce motion, that preference will be saved via local storage so they won’t have to repeatedly make this selection every time they visit.

The official Animal Crossing site is a wonderful real-world example of a custom reduce motion toggle combined with the prefers-reduced-motion media feature. It’s one of my favorite examples of handling reduced motion. The design choices they made around how to reduce potentially the triggering motion, while still keeping true to the overall feel of the site and the content, is great. I wrote more about how they pulled it off in this blog post. There are a lot of sites out there whose audience could benefit from a similar approach.

Other Ways To Use Motion Toggles

If you already have a preferences or settings panel, adding a toggle to request reduced motion could be a valuable thing to add to these settings like Twitter does on its site. In this case, there aren’t large amounts of motion immediately presented when visiting the site and there’s already a settings panel, so implementing the toggle as part of the settings preferences fits well. Twitter’s toggle also respects OS-level settings via the preferes reduced motion query and is preset to either on or off based on what the user has set at the OS level. Designing your motion toggle to respect OS settings is definitely a smart approach to implementing them well no matter where the toggle might appear.

Contextual toggles are another approach that could be used to reduce motion on specific animated illustrations or other content areas that appear throughout your site. The Dark Side of The Grid article does this nicely by adding contextual toggle buttons to each animate figure to allow the reader to play the animation when they want to see it, but not have it loop endlessly while they are reading.

Along those same lines, Dave Rupert shared a technique for combining prefers reduced motion with the picture element to show static elements in place of animated gifs when reduced motion has been requested. Chris Coyier took that one step further and suggested presenting a play toggle for those animated gifs based on the same approach. Steve Faulkner’s gif de-animator example could also be a useful approach.

All of these, or something similar, could be good options for mitigating any potentially triggering motion on the web. I bring up these examples for two reasons. The first is to show that there are a number of ways to approach providing reduced motion variations and you have lots of flexibility to find an approach that fits best for your content. And secondly, as time goes on and more folks are building sites with reduced motion options, the more innovative solutions we’ll see shared in the community.

There are many creative ways to add toggles and settings in a way that makes sense for the context of your project. It’s an interesting parallel that we’re seeing more and more web sites include settings panels or options for setting preferences like dark mode. Including an option for reduced motion could be a natural next step.

The More We Use It, The Better It Will Get For Everyone

I think it’s important for us, the people designing and building things for the web, to take advantage of the prefers-reduced-motion media feature to make our work more inclusive. By taking steps to respect motion preferences we make the web safer for more people to use, and that can only be a good thing. We absolutely can be expressive and creative with motion on the web while also being responsible and inclusive.

But the awareness level is still something we need to be, well, aware of. Not everyone who might need reduced motion is aware of the option in their OS settings. Perhaps even fewer people know that it can take effect on content in their browser too since so few websites currently take advantage of it. The more we take advantage of the prefers-reduced-motion media feature, and provide a quality reduced motion experience with it, the more meaningful of a feature it will be for those who need it.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
23 Oct

Designing With Reduced Motion For Motion Sensitivities

by TBSCategories: News

CSS has recently added features that allow us to recognize certain user preferences and qualities of the user’s current environment. One of those new features, specifically the prefers-reduced-motion media feature, can be especially useful for designing more inclusive motion on the web.

A few years back, I wrote an article about designing safer web animation for motion sensitivity and the limited options we had at the time to design safe motion on the web. Some things have remained the same since that original article, like the types of motion effects that can be triggering, and the importance of context and user expectations. But what has changed is the existence and support of the prefers-reduced-motion media feature. That makes a big difference in how we can design the motion in our work to be inclusive and accessible.

Why Reduce Motion?

The release of iOS7 back in 2013 sparked a realization throughout the digital design world that some motion on screen — even if it was part of an interface — could have physical consequences for people with motion sensitivities. In the years since then, the major mobile and desktop operating systems have added functionality for people to reduce the amount of motion they encounter in their operating systems.

Articles like “Your Interactive Is Making Me Sick” and “Accessibility For Vestibular Disorders” share first-hand stories of how our design choices, especially around motion, can have physical consequences for those with motion sensitivities. The root causes of these motion sensitivities can vary greatly between individuals. For some, it’s rooted in a vestibular disorder, while for others it might stem from migraines or other factors. What’s triggering can also vary from person to person, or even from day to day for some. The physical symptoms individuals experience as a result of that triggering motion can range from slight dizziness or headaches to nausea or worse.

The design choices we make around animation in our work directly impacts how our work affects people with motion sensitivities. Knowing what kinds of motion are potentially triggering, and how we can mitigate them with our design choices, helps us design experiences that are safe for our audience and won’t cause unintended harm. Animation still absolutely can have a positive impact on our UX efforts, but it’s up to us to make sure we use it responsibly, just like we try to use our other design tools responsibly.

Prefers Reduced Motion On The Web

The prefers-reduced-motion media feature now has strong browser support. It’s supported in current versions of Edge, Firefox, Chrome, Safari, Opera, iOS Safari, as well as on Android Browsers and Chrome for Android. The level of support we have today makes it something that you can absolutely use in production. Also, if someone’s browser doesn’t support this feature, nothing bad happens, it will just be ignored and things will carry on as before.

On the development side, we can test for prefers-reduced-motion in the same way that we would use any other media query in CSS or JavaScript to find out if reduced motion has been requested.

In CSS that will look something like this: 

@media (prefers-reduced-motion: reduce)  {     /* reduced behaviour */    }

And in JavaScript: 

let motionQuery = matchMedia('(prefers-reduced-motion)');  const handleReduceMotionChanged = () => {   if (motionQuery.matches) //reduced behaviour; }  motionQuery.addListener(handleReduceMotionChanged); handleReduceMotionChanged()

Whichever way you choose to access it, this media query will return one of two values: no-preference (false), or reduce (true). Once retrieved, you can use these values to inform what you display in the browser.

Of the two values that can be returned, the only one we can be sure has been set intentionally is the reduce (true) value. No-preference (false) can mean that the person in question is fine with all types of motion, or it could mean that that preference just hasn’t been set yet. This makes any approach that equates the value of no preference (false) to the person in question opting in to all levels of motion unreliable. Because of this, the better approach is to reduce potentially triggering motion effects when a value of reduce (true) is returned.

For example, here the looping bounce animation is replaced with a fade in animation when reduced motion is requested:

/* A constant bouncing motion effect applied to the title */ h2 {   animation: bouncing 1.5s linear infinite alternate; }  /* Replace it with a safer effect when prefers-reduced-motion returns true */ @media (prefers-reduced-motion) {   h2 {   animation: fade 0.5s ease-in both;    }

Reduced Motion From The Users’ Perspective

Most major operating systems allow people to set their preferences in their system settings. The exact wording and location of the settings vary, but the preference can be set on iOS, OSX, Windows, and Android operating systems.

The Prefers Reduced Motion Media Feature In Practice

Deciding how to put the prefers-reduced-motion media feature to use is where we have space for creating solutions that best fit the context of our products and content. For most web projects, you’ll want to first identify any potentially triggering motion effects on your site, and then use the prefers-reduced-motion media feature to provide a reduced version of that effect.

Let’s look at each step in more detail.

Identifying Potentially Triggering Motion

To find any potentially triggering motion you might have, go through some typical user flows for your site or product and take a closer look at the motion effects used: Do you have any interactions that have large movements? Any large zooms, spinning effects, or parallax effects? All of those types of animated effects are very likely to be problematic for people with motion sensitivities. In contrast, animated effects like color fades, opacity changes and small changes in scale are unlikely to be problematic. If in doubt, it can’t hurt to add the effect in question to your “to reduce” list to err on the side of caution.

The Web Content Accessibility Guidelines recommend providing a reduced version for any “motion that creates the illusion of movement…that is not essential to the content’s meaning”. I think it’s helpful to see some examples too, especially if you don’t consider yourself to be sensitive to motion on screen. I cover examples of potentially triggering motion in my previous article and this post on the Webkit blog has some too. Chances are, unless your site relies heavily on motion, you’ll end up with a fairly short list of effects to focus on here.

Create A Reduced Motion Version

Next, you want to determine the most appropriate reduced motion condition for these potentially triggering effects. Can the animation easily be adjusted to use a non-motion effect like an opacity fade or crossfade for reduced motion requests? Would pausing the motion or removing the effect entirely for reduced motion preserve the meaning of the content?

The role of the motion in question will be an important factor in deciding what the most appropriate reduced version would be. You don’t want to unintentionally remove content or degrade the overall experience. Here are a few examples of what might work well for the potentially triggering effects you find:

Large Page Transitions

Large page transition effects can likely be replaced with a crossfade effect for a reduced motion mode. The same is usually true for large zooming or spinning transitions that transition between different states or views.

Animated Illustrations

Animated illustrations, on the other hand, might be best replaced with a static version for reduced motion if they are mostly for personality or branding effect. You’ll want to make sure the static version is still meaningful, and the arrangement that has the most meaning may not always be the very beginning or very end of the animation. Adding in functionality to play animated illustrations on demand for reduced motion could also be useful by allowing people to play the animation when they’re ready for it.

Don’t forget to consider the motion in your animated gifs or auto-playing videos here as well. These can also contain potentially triggering motion and would need a reduced version if they do.

Parallax Effects

Parallax effects and exaggerated smooth scrolling effects are universally triggering for folks with motion sensitivities, so those should be significantly reduced or entirely removed for reduced motion. (Every single person I’ve talked to in my research on this has called out parallax specifically as being a problem for them.) Smooth scrolling effects can be replaced with the default browser anchor link behaviour as described here by Eric Bailey. Removing parallax effects for reduced motion is the ideal solution, but make sure to check that all the necessary content is still visible and usable with the parallax removed.

In most cases substituting the potentially triggering effect with a safer effect for reduced motion is the best way to preserve as much of the content’s intent and usability as possible. Luckily, substituting a reduced effect can be pretty straight forward too.

An Example Of Reducing Motion

For example, let’s say I flagged this header animation as potentially triggering when I went through my site. The motion is large enough to create the illusion of motion, so it’s likely to be triggering, and the multiple directions of motion are also likely to be problematic. It’s definitely one I’d put on my list of effects that need a reduced version when reviewing my site.

The Airpods Pro page also responds to reduced motion preferences, but in a very different way because of the content and effects used. Almost all of the motion on the page could be potentially triggering since it has a lot of big zooming movements and parallax-style effects. When reduced motion is requested, all the parallax and large motion effects are removed, but they do more than just pause or remove the animations. The version you see with reduced motion selected has been designed with care to preserve the same content and meaning from the full motion experience. (Here’s a video of The Airpods Pro site both with and without reduced motion selected for reference.)

Add Custom Toggles For Motion-Heavy Experiences

I mentioned above that most “task-based” sites likely have only a handful of animations that might be triggering and need a reduced version. But those aren’t the only kind of web sites out there on the web. Projects that involve a large amount of motion, like sites that are meant more for storytelling or creating an experience might benefit from a slightly different approach.

For projects like these, it would be difficult to make a list of potentially triggering motions and provide a reduced alternative for each because almost all of the motion used could be potentially triggering. Plus, the motion is very much part of the content and its meaning. Designing a reduced motion mode for these types of sites will take a more global approach and more effort to be sure the meaning of your content is preserved even as motion is reduced.

For these highly animated experience sites, providing a visible custom motion toggle is a useful thing to include. This will allow people who may not yet know about the reduced motion setting, or who are experiencing some motion sensitivity at that moment in time, to quickly adjust the experience. A motion toggle provides a way for motion-sensitive folks to participate in your content in a way that won’t make them sick. That’s definitely better for everyone involved than them having to avoid your site entirely.

Context Is A Key Factor

Remember that context also plays a big role here. No one wants to be surprised by large amounts of motion where they don’t expect it. If you’re visiting a site billed as a highly interactive storytelling experience you’ll have very different expectations than when you’re visiting your bank’s web site. Both of those sites certainly could feature large amounts of animation, but it would be an unexpected surprise on the bank site.

Building A Custom Motion Toggle

The idea of a custom toggle is something that I mentioned back in my 2015 article, but today it’s a much more viable option. On today’s web, we can create one with more ease, and even make a smarter toggle than we could have just a few years ago.

Marcy Sutton has a great example of how a modern custom motion toggle could work in this CodePen. (This example is part of her course on making accessible web apps, which is also very much worth checking out.) Her example uses a toggle to remove all motion because it only includes one animation, but this approach can be used to provide reduced motion effects across an entire application or site following the same logic as well.

The key feature of this approach is how nicely Marcy ties it in with modern web technology, i.e. prefers reduced motion and local storage. When using this approach, if someone comes to your site with reduced motion requested, they automatically get the reduced motion version without having to manually activate the toggle as well. And if someone invokes the toggle to reduce motion, that preference will be saved via local storage so they won’t have to repeatedly make this selection every time they visit.

The official Animal Crossing site is a wonderful real-world example of a custom reduce motion toggle combined with the prefers-reduced-motion media feature. It’s one of my favorite examples of handling reduced motion. The design choices they made around how to reduce potentially the triggering motion, while still keeping true to the overall feel of the site and the content, is great. I wrote more about how they pulled it off in this blog post. There are a lot of sites out there whose audience could benefit from a similar approach.

Other Ways To Use Motion Toggles

If you already have a preferences or settings panel, adding a toggle to request reduced motion could be a valuable thing to add to these settings like Twitter does on its site. In this case, there aren’t large amounts of motion immediately presented when visiting the site and there’s already a settings panel, so implementing the toggle as part of the settings preferences fits well. Twitter’s toggle also respects OS-level settings via the preferes reduced motion query and is preset to either on or off based on what the user has set at the OS level. Designing your motion toggle to respect OS settings is definitely a smart approach to implementing them well no matter where the toggle might appear.

Contextual toggles are another approach that could be used to reduce motion on specific animated illustrations or other content areas that appear throughout your site. The Dark Side of The Grid article does this nicely by adding contextual toggle buttons to each animate figure to allow the reader to play the animation when they want to see it, but not have it loop endlessly while they are reading.

Along those same lines, Dave Rupert shared a technique for combining prefers reduced motion with the picture element to show static elements in place of animated gifs when reduced motion has been requested. Chris Coyier took that one step further and suggested presenting a play toggle for those animated gifs based on the same approach. Steve Faulkner’s gif de-animator example could also be a useful approach.

All of these, or something similar, could be good options for mitigating any potentially triggering motion on the web. I bring up these examples for two reasons. The first is to show that there are a number of ways to approach providing reduced motion variations and you have lots of flexibility to find an approach that fits best for your content. And secondly, as time goes on and more folks are building sites with reduced motion options, the more innovative solutions we’ll see shared in the community.

There are many creative ways to add toggles and settings in a way that makes sense for the context of your project. It’s an interesting parallel that we’re seeing more and more web sites include settings panels or options for setting preferences like dark mode. Including an option for reduced motion could be a natural next step.

The More We Use It, The Better It Will Get For Everyone

I think it’s important for us, the people designing and building things for the web, to take advantage of the prefers-reduced-motion media feature to make our work more inclusive. By taking steps to respect motion preferences we make the web safer for more people to use, and that can only be a good thing. We absolutely can be expressive and creative with motion on the web while also being responsible and inclusive.

But the awareness level is still something we need to be, well, aware of. Not everyone who might need reduced motion is aware of the option in their OS settings. Perhaps even fewer people know that it can take effect on content in their browser too since so few websites currently take advantage of it. The more we take advantage of the prefers-reduced-motion media feature, and provide a quality reduced motion experience with it, the more meaningful of a feature it will be for those who need it.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
23 Oct

Designing With Reduced Motion For Motion Sensitivities

by TBSCategories: News

CSS has recently added features that allow us to recognize certain user preferences and qualities of the user’s current environment. One of those new features, specifically the prefers-reduced-motion media feature, can be especially useful for designing more inclusive motion on the web.

A few years back, I wrote an article about designing safer web animation for motion sensitivity and the limited options we had at the time to design safe motion on the web. Some things have remained the same since that original article, like the types of motion effects that can be triggering, and the importance of context and user expectations. But what has changed is the existence and support of the prefers-reduced-motion media feature. That makes a big difference in how we can design the motion in our work to be inclusive and accessible.

Why Reduce Motion?

The release of iOS7 back in 2013 sparked a realization throughout the digital design world that some motion on screen — even if it was part of an interface — could have physical consequences for people with motion sensitivities. In the years since then, the major mobile and desktop operating systems have added functionality for people to reduce the amount of motion they encounter in their operating systems.

Articles like “Your Interactive Is Making Me Sick” and “Accessibility For Vestibular Disorders” share first-hand stories of how our design choices, especially around motion, can have physical consequences for those with motion sensitivities. The root causes of these motion sensitivities can vary greatly between individuals. For some, it’s rooted in a vestibular disorder, while for others it might stem from migraines or other factors. What’s triggering can also vary from person to person, or even from day to day for some. The physical symptoms individuals experience as a result of that triggering motion can range from slight dizziness or headaches to nausea or worse.

The design choices we make around animation in our work directly impacts how our work affects people with motion sensitivities. Knowing what kinds of motion are potentially triggering, and how we can mitigate them with our design choices, helps us design experiences that are safe for our audience and won’t cause unintended harm. Animation still absolutely can have a positive impact on our UX efforts, but it’s up to us to make sure we use it responsibly, just like we try to use our other design tools responsibly.

Prefers Reduced Motion On The Web

The prefers-reduced-motion media feature now has strong browser support. It’s supported in current versions of Edge, Firefox, Chrome, Safari, Opera, iOS Safari, as well as on Android Browsers and Chrome for Android. The level of support we have today makes it something that you can absolutely use in production. Also, if someone’s browser doesn’t support this feature, nothing bad happens, it will just be ignored and things will carry on as before.

On the development side, we can test for prefers-reduced-motion in the same way that we would use any other media query in CSS or JavaScript to find out if reduced motion has been requested.

In CSS that will look something like this: 

@media (prefers-reduced-motion: reduce)  {     /* reduced behaviour */    }

And in JavaScript: 

let motionQuery = matchMedia('(prefers-reduced-motion)');  const handleReduceMotionChanged = () => {   if (motionQuery.matches) //reduced behaviour; }  motionQuery.addListener(handleReduceMotionChanged); handleReduceMotionChanged()

Whichever way you choose to access it, this media query will return one of two values: no-preference (false), or reduce (true). Once retrieved, you can use these values to inform what you display in the browser.

Of the two values that can be returned, the only one we can be sure has been set intentionally is the reduce (true) value. No-preference (false) can mean that the person in question is fine with all types of motion, or it could mean that that preference just hasn’t been set yet. This makes any approach that equates the value of no preference (false) to the person in question opting in to all levels of motion unreliable. Because of this, the better approach is to reduce potentially triggering motion effects when a value of reduce (true) is returned.

For example, here the looping bounce animation is replaced with a fade in animation when reduced motion is requested:

/* A constant bouncing motion effect applied to the title */ h2 {   animation: bouncing 1.5s linear infinite alternate; }  /* Replace it with a safer effect when prefers-reduced-motion returns true */ @media (prefers-reduced-motion) {   h2 {   animation: fade 0.5s ease-in both;    }

Reduced Motion From The Users’ Perspective

Most major operating systems allow people to set their preferences in their system settings. The exact wording and location of the settings vary, but the preference can be set on iOS, OSX, Windows, and Android operating systems.

The Prefers Reduced Motion Media Feature In Practice

Deciding how to put the prefers-reduced-motion media feature to use is where we have space for creating solutions that best fit the context of our products and content. For most web projects, you’ll want to first identify any potentially triggering motion effects on your site, and then use the prefers-reduced-motion media feature to provide a reduced version of that effect.

Let’s look at each step in more detail.

Identifying Potentially Triggering Motion

To find any potentially triggering motion you might have, go through some typical user flows for your site or product and take a closer look at the motion effects used: Do you have any interactions that have large movements? Any large zooms, spinning effects, or parallax effects? All of those types of animated effects are very likely to be problematic for people with motion sensitivities. In contrast, animated effects like color fades, opacity changes and small changes in scale are unlikely to be problematic. If in doubt, it can’t hurt to add the effect in question to your “to reduce” list to err on the side of caution.

The Web Content Accessibility Guidelines recommend providing a reduced version for any “motion that creates the illusion of movement…that is not essential to the content’s meaning”. I think it’s helpful to see some examples too, especially if you don’t consider yourself to be sensitive to motion on screen. I cover examples of potentially triggering motion in my previous article and this post on the Webkit blog has some too. Chances are, unless your site relies heavily on motion, you’ll end up with a fairly short list of effects to focus on here.

Create A Reduced Motion Version

Next, you want to determine the most appropriate reduced motion condition for these potentially triggering effects. Can the animation easily be adjusted to use a non-motion effect like an opacity fade or crossfade for reduced motion requests? Would pausing the motion or removing the effect entirely for reduced motion preserve the meaning of the content?

The role of the motion in question will be an important factor in deciding what the most appropriate reduced version would be. You don’t want to unintentionally remove content or degrade the overall experience. Here are a few examples of what might work well for the potentially triggering effects you find:

Large Page Transitions

Large page transition effects can likely be replaced with a crossfade effect for a reduced motion mode. The same is usually true for large zooming or spinning transitions that transition between different states or views.

Animated Illustrations

Animated illustrations, on the other hand, might be best replaced with a static version for reduced motion if they are mostly for personality or branding effect. You’ll want to make sure the static version is still meaningful, and the arrangement that has the most meaning may not always be the very beginning or very end of the animation. Adding in functionality to play animated illustrations on demand for reduced motion could also be useful by allowing people to play the animation when they’re ready for it.

Don’t forget to consider the motion in your animated gifs or auto-playing videos here as well. These can also contain potentially triggering motion and would need a reduced version if they do.

Parallax Effects

Parallax effects and exaggerated smooth scrolling effects are universally triggering for folks with motion sensitivities, so those should be significantly reduced or entirely removed for reduced motion. (Every single person I’ve talked to in my research on this has called out parallax specifically as being a problem for them.) Smooth scrolling effects can be replaced with the default browser anchor link behaviour as described here by Eric Bailey. Removing parallax effects for reduced motion is the ideal solution, but make sure to check that all the necessary content is still visible and usable with the parallax removed.

In most cases substituting the potentially triggering effect with a safer effect for reduced motion is the best way to preserve as much of the content’s intent and usability as possible. Luckily, substituting a reduced effect can be pretty straight forward too.

An Example Of Reducing Motion

For example, let’s say I flagged this header animation as potentially triggering when I went through my site. The motion is large enough to create the illusion of motion, so it’s likely to be triggering, and the multiple directions of motion are also likely to be problematic. It’s definitely one I’d put on my list of effects that need a reduced version when reviewing my site.

The Airpods Pro page also responds to reduced motion preferences, but in a very different way because of the content and effects used. Almost all of the motion on the page could be potentially triggering since it has a lot of big zooming movements and parallax-style effects. When reduced motion is requested, all the parallax and large motion effects are removed, but they do more than just pause or remove the animations. The version you see with reduced motion selected has been designed with care to preserve the same content and meaning from the full motion experience. (Here’s a video of The Airpods Pro site both with and without reduced motion selected for reference.)

Add Custom Toggles For Motion-Heavy Experiences

I mentioned above that most “task-based” sites likely have only a handful of animations that might be triggering and need a reduced version. But those aren’t the only kind of web sites out there on the web. Projects that involve a large amount of motion, like sites that are meant more for storytelling or creating an experience might benefit from a slightly different approach.

For projects like these, it would be difficult to make a list of potentially triggering motions and provide a reduced alternative for each because almost all of the motion used could be potentially triggering. Plus, the motion is very much part of the content and its meaning. Designing a reduced motion mode for these types of sites will take a more global approach and more effort to be sure the meaning of your content is preserved even as motion is reduced.

For these highly animated experience sites, providing a visible custom motion toggle is a useful thing to include. This will allow people who may not yet know about the reduced motion setting, or who are experiencing some motion sensitivity at that moment in time, to quickly adjust the experience. A motion toggle provides a way for motion-sensitive folks to participate in your content in a way that won’t make them sick. That’s definitely better for everyone involved than them having to avoid your site entirely.

Context Is A Key Factor

Remember that context also plays a big role here. No one wants to be surprised by large amounts of motion where they don’t expect it. If you’re visiting a site billed as a highly interactive storytelling experience you’ll have very different expectations than when you’re visiting your bank’s web site. Both of those sites certainly could feature large amounts of animation, but it would be an unexpected surprise on the bank site.

Building A Custom Motion Toggle

The idea of a custom toggle is something that I mentioned back in my 2015 article, but today it’s a much more viable option. On today’s web, we can create one with more ease, and even make a smarter toggle than we could have just a few years ago.

Marcy Sutton has a great example of how a modern custom motion toggle could work in this CodePen. (This example is part of her course on making accessible web apps, which is also very much worth checking out.) Her example uses a toggle to remove all motion because it only includes one animation, but this approach can be used to provide reduced motion effects across an entire application or site following the same logic as well.

The key feature of this approach is how nicely Marcy ties it in with modern web technology, i.e. prefers reduced motion and local storage. When using this approach, if someone comes to your site with reduced motion requested, they automatically get the reduced motion version without having to manually activate the toggle as well. And if someone invokes the toggle to reduce motion, that preference will be saved via local storage so they won’t have to repeatedly make this selection every time they visit.

The official Animal Crossing site is a wonderful real-world example of a custom reduce motion toggle combined with the prefers-reduced-motion media feature. It’s one of my favorite examples of handling reduced motion. The design choices they made around how to reduce potentially the triggering motion, while still keeping true to the overall feel of the site and the content, is great. I wrote more about how they pulled it off in this blog post. There are a lot of sites out there whose audience could benefit from a similar approach.

Other Ways To Use Motion Toggles

If you already have a preferences or settings panel, adding a toggle to request reduced motion could be a valuable thing to add to these settings like Twitter does on its site. In this case, there aren’t large amounts of motion immediately presented when visiting the site and there’s already a settings panel, so implementing the toggle as part of the settings preferences fits well. Twitter’s toggle also respects OS-level settings via the preferes reduced motion query and is preset to either on or off based on what the user has set at the OS level. Designing your motion toggle to respect OS settings is definitely a smart approach to implementing them well no matter where the toggle might appear.

Contextual toggles are another approach that could be used to reduce motion on specific animated illustrations or other content areas that appear throughout your site. The Dark Side of The Grid article does this nicely by adding contextual toggle buttons to each animate figure to allow the reader to play the animation when they want to see it, but not have it loop endlessly while they are reading.

Along those same lines, Dave Rupert shared a technique for combining prefers reduced motion with the picture element to show static elements in place of animated gifs when reduced motion has been requested. Chris Coyier took that one step further and suggested presenting a play toggle for those animated gifs based on the same approach. Steve Faulkner’s gif de-animator example could also be a useful approach.

All of these, or something similar, could be good options for mitigating any potentially triggering motion on the web. I bring up these examples for two reasons. The first is to show that there are a number of ways to approach providing reduced motion variations and you have lots of flexibility to find an approach that fits best for your content. And secondly, as time goes on and more folks are building sites with reduced motion options, the more innovative solutions we’ll see shared in the community.

There are many creative ways to add toggles and settings in a way that makes sense for the context of your project. It’s an interesting parallel that we’re seeing more and more web sites include settings panels or options for setting preferences like dark mode. Including an option for reduced motion could be a natural next step.

The More We Use It, The Better It Will Get For Everyone

I think it’s important for us, the people designing and building things for the web, to take advantage of the prefers-reduced-motion media feature to make our work more inclusive. By taking steps to respect motion preferences we make the web safer for more people to use, and that can only be a good thing. We absolutely can be expressive and creative with motion on the web while also being responsible and inclusive.

But the awareness level is still something we need to be, well, aware of. Not everyone who might need reduced motion is aware of the option in their OS settings. Perhaps even fewer people know that it can take effect on content in their browser too since so few websites currently take advantage of it. The more we take advantage of the prefers-reduced-motion media feature, and provide a quality reduced motion experience with it, the more meaningful of a feature it will be for those who need it.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
22 Oct

Designing With Reduced Motion For Motion Sensitivities

by TBSCategories: News

CSS has recently added features that allow us to recognize certain user preferences and qualities of the user’s current environment. One of those new features, specifically the prefers-reduced-motion media feature, can be especially useful for designing more inclusive motion on the web.

A few years back, I wrote an article about designing safer web animation for motion sensitivity and the limited options we had at the time to design safe motion on the web. Some things have remained the same since that original article, like the types of motion effects that can be triggering, and the importance of context and user expectations. But what has changed is the existence and support of the prefers-reduced-motion media feature. That makes a big difference in how we can design the motion in our work to be inclusive and accessible.

Why Reduce Motion?

The release of iOS7 back in 2013 sparked a realization throughout the digital design world that some motion on screen — even if it was part of an interface — could have physical consequences for people with motion sensitivities. In the years since then, the major mobile and desktop operating systems have added functionality for people to reduce the amount of motion they encounter in their operating systems.

Articles like “Your Interactive Is Making Me Sick” and “Accessibility For Vestibular Disorders” share first-hand stories of how our design choices, especially around motion, can have physical consequences for those with motion sensitivities. The root causes of these motion sensitivities can vary greatly between individuals. For some, it’s rooted in a vestibular disorder, while for others it might stem from migraines or other factors. What’s triggering can also vary from person to person, or even from day to day for some. The physical symptoms individuals experience as a result of that triggering motion can range from slight dizziness or headaches to nausea or worse.

The design choices we make around animation in our work directly impacts how our work affects people with motion sensitivities. Knowing what kinds of motion are potentially triggering, and how we can mitigate them with our design choices, helps us design experiences that are safe for our audience and won’t cause unintended harm. Animation still absolutely can have a positive impact on our UX efforts, but it’s up to us to make sure we use it responsibly, just like we try to use our other design tools responsibly.

Prefers Reduced Motion On The Web

The prefers-reduced-motion media feature now has strong browser support. It’s supported in current versions of Edge, Firefox, Chrome, Safari, Opera, iOS Safari, as well as on Android Browsers and Chrome for Android. The level of support we have today makes it something that you can absolutely use in production. Also, if someone’s browser doesn’t support this feature, nothing bad happens, it will just be ignored and things will carry on as before.

On the development side, we can test for prefers-reduced-motion in the same way that we would use any other media query in CSS or JavaScript to find out if reduced motion has been requested.

In CSS that will look something like this: 

@media (prefers-reduced-motion: reduce)  {     /* reduced behaviour */    }

And in JavaScript: 

let motionQuery = matchMedia('(prefers-reduced-motion)');  const handleReduceMotionChanged = () => {   if (motionQuery.matches) //reduced behaviour; }  motionQuery.addListener(handleReduceMotionChanged); handleReduceMotionChanged()

Whichever way you choose to access it, this media query will return one of two values: no-preference (false), or reduce (true). Once retrieved, you can use these values to inform what you display in the browser.

Of the two values that can be returned, the only one we can be sure has been set intentionally is the reduce (true) value. No-preference (false) can mean that the person in question is fine with all types of motion, or it could mean that that preference just hasn’t been set yet. This makes any approach that equates the value of no preference (false) to the person in question opting in to all levels of motion unreliable. Because of this, the better approach is to reduce potentially triggering motion effects when a value of reduce (true) is returned.

For example, here the looping bounce animation is replaced with a fade in animation when reduced motion is requested:

/* A constant bouncing motion effect applied to the title */ h2 {   animation: bouncing 1.5s linear infinite alternate; }  /* Replace it with a safer effect when prefers-reduced-motion returns true */ @media (prefers-reduced-motion) {   h2 {   animation: fade 0.5s ease-in both;    }

Reduced Motion From The Users’ Perspective

Most major operating systems allow people to set their preferences in their system settings. The exact wording and location of the settings vary, but the preference can be set on iOS, OSX, Windows, and Android operating systems.

The Prefers Reduced Motion Media Feature In Practice

Deciding how to put the prefers-reduced-motion media feature to use is where we have space for creating solutions that best fit the context of our products and content. For most web projects, you’ll want to first identify any potentially triggering motion effects on your site, and then use the prefers-reduced-motion media feature to provide a reduced version of that effect.

Let’s look at each step in more detail.

Identifying Potentially Triggering Motion

To find any potentially triggering motion you might have, go through some typical user flows for your site or product and take a closer look at the motion effects used: Do you have any interactions that have large movements? Any large zooms, spinning effects, or parallax effects? All of those types of animated effects are very likely to be problematic for people with motion sensitivities. In contrast, animated effects like color fades, opacity changes and small changes in scale are unlikely to be problematic. If in doubt, it can’t hurt to add the effect in question to your “to reduce” list to err on the side of caution.

The Web Content Accessibility Guidelines recommend providing a reduced version for any “motion that creates the illusion of movement…that is not essential to the content’s meaning”. I think it’s helpful to see some examples too, especially if you don’t consider yourself to be sensitive to motion on screen. I cover examples of potentially triggering motion in my previous article and this post on the Webkit blog has some too. Chances are, unless your site relies heavily on motion, you’ll end up with a fairly short list of effects to focus on here.

Create A Reduced Motion Version

Next, you want to determine the most appropriate reduced motion condition for these potentially triggering effects. Can the animation easily be adjusted to use a non-motion effect like an opacity fade or crossfade for reduced motion requests? Would pausing the motion or removing the effect entirely for reduced motion preserve the meaning of the content?

The role of the motion in question will be an important factor in deciding what the most appropriate reduced version would be. You don’t want to unintentionally remove content or degrade the overall experience. Here are a few examples of what might work well for the potentially triggering effects you find:

Large Page Transitions

Large page transition effects can likely be replaced with a crossfade effect for a reduced motion mode. The same is usually true for large zooming or spinning transitions that transition between different states or views.

Animated Illustrations

Animated illustrations, on the other hand, might be best replaced with a static version for reduced motion if they are mostly for personality or branding effect. You’ll want to make sure the static version is still meaningful, and the arrangement that has the most meaning may not always be the very beginning or very end of the animation. Adding in functionality to play animated illustrations on demand for reduced motion could also be useful by allowing people to play the animation when they’re ready for it.

Don’t forget to consider the motion in your animated gifs or auto-playing videos here as well. These can also contain potentially triggering motion and would need a reduced version if they do.

Parallax Effects

Parallax effects and exaggerated smooth scrolling effects are universally triggering for folks with motion sensitivities, so those should be significantly reduced or entirely removed for reduced motion. (Every single person I’ve talked to in my research on this has called out parallax specifically as being a problem for them.) Smooth scrolling effects can be replaced with the default browser anchor link behaviour as described here by Eric Bailey. Removing parallax effects for reduced motion is the ideal solution, but make sure to check that all the necessary content is still visible and usable with the parallax removed.

In most cases substituting the potentially triggering effect with a safer effect for reduced motion is the best way to preserve as much of the content’s intent and usability as possible. Luckily, substituting a reduced effect can be pretty straight forward too.

An Example Of Reducing Motion

For example, let’s say I flagged this header animation as potentially triggering when I went through my site. The motion is large enough to create the illusion of motion, so it’s likely to be triggering, and the multiple directions of motion are also likely to be problematic. It’s definitely one I’d put on my list of effects that need a reduced version when reviewing my site.

The Airpods Pro page also responds to reduced motion preferences, but in a very different way because of the content and effects used. Almost all of the motion on the page could be potentially triggering since it has a lot of big zooming movements and parallax-style effects. When reduced motion is requested, all the parallax and large motion effects are removed, but they do more than just pause or remove the animations. The version you see with reduced motion selected has been designed with care to preserve the same content and meaning from the full motion experience. (Here’s a video of The Airpods Pro site both with and without reduced motion selected for reference.)

Add Custom Toggles For Motion-Heavy Experiences

I mentioned above that most “task-based” sites likely have only a handful of animations that might be triggering and need a reduced version. But those aren’t the only kind of web sites out there on the web. Projects that involve a large amount of motion, like sites that are meant more for storytelling or creating an experience might benefit from a slightly different approach.

For projects like these, it would be difficult to make a list of potentially triggering motions and provide a reduced alternative for each because almost all of the motion used could be potentially triggering. Plus, the motion is very much part of the content and its meaning. Designing a reduced motion mode for these types of sites will take a more global approach and more effort to be sure the meaning of your content is preserved even as motion is reduced.

For these highly animated experience sites, providing a visible custom motion toggle is a useful thing to include. This will allow people who may not yet know about the reduced motion setting, or who are experiencing some motion sensitivity at that moment in time, to quickly adjust the experience. A motion toggle provides a way for motion-sensitive folks to participate in your content in a way that won’t make them sick. That’s definitely better for everyone involved than them having to avoid your site entirely.

Context Is A Key Factor

Remember that context also plays a big role here. No one wants to be surprised by large amounts of motion where they don’t expect it. If you’re visiting a site billed as a highly interactive storytelling experience you’ll have very different expectations than when you’re visiting your bank’s web site. Both of those sites certainly could feature large amounts of animation, but it would be an unexpected surprise on the bank site.

Building A Custom Motion Toggle

The idea of a custom toggle is something that I mentioned back in my 2015 article, but today it’s a much more viable option. On today’s web, we can create one with more ease, and even make a smarter toggle than we could have just a few years ago.

Marcy Sutton has a great example of how a modern custom motion toggle could work in this CodePen. (This example is part of her course on making accessible web apps, which is also very much worth checking out.) Her example uses a toggle to remove all motion because it only includes one animation, but this approach can be used to provide reduced motion effects across an entire application or site following the same logic as well.

The key feature of this approach is how nicely Marcy ties it in with modern web technology, i.e. prefers reduced motion and local storage. When using this approach, if someone comes to your site with reduced motion requested, they automatically get the reduced motion version without having to manually activate the toggle as well. And if someone invokes the toggle to reduce motion, that preference will be saved via local storage so they won’t have to repeatedly make this selection every time they visit.

The official Animal Crossing site is a wonderful real-world example of a custom reduce motion toggle combined with the prefers-reduced-motion media feature. It’s one of my favorite examples of handling reduced motion. The design choices they made around how to reduce potentially the triggering motion, while still keeping true to the overall feel of the site and the content, is great. I wrote more about how they pulled it off in this blog post. There are a lot of sites out there whose audience could benefit from a similar approach.

Other Ways To Use Motion Toggles

If you already have a preferences or settings panel, adding a toggle to request reduced motion could be a valuable thing to add to these settings like Twitter does on its site. In this case, there aren’t large amounts of motion immediately presented when visiting the site and there’s already a settings panel, so implementing the toggle as part of the settings preferences fits well. Twitter’s toggle also respects OS-level settings via the preferes reduced motion query and is preset to either on or off based on what the user has set at the OS level. Designing your motion toggle to respect OS settings is definitely a smart approach to implementing them well no matter where the toggle might appear.

Contextual toggles are another approach that could be used to reduce motion on specific animated illustrations or other content areas that appear throughout your site. The Dark Side of The Grid article does this nicely by adding contextual toggle buttons to each animate figure to allow the reader to play the animation when they want to see it, but not have it loop endlessly while they are reading.

Along those same lines, Dave Rupert shared a technique for combining prefers reduced motion with the picture element to show static elements in place of animated gifs when reduced motion has been requested. Chris Coyier took that one step further and suggested presenting a play toggle for those animated gifs based on the same approach. Steve Faulkner’s gif de-animator example could also be a useful approach.

All of these, or something similar, could be good options for mitigating any potentially triggering motion on the web. I bring up these examples for two reasons. The first is to show that there are a number of ways to approach providing reduced motion variations and you have lots of flexibility to find an approach that fits best for your content. And secondly, as time goes on and more folks are building sites with reduced motion options, the more innovative solutions we’ll see shared in the community.

There are many creative ways to add toggles and settings in a way that makes sense for the context of your project. It’s an interesting parallel that we’re seeing more and more web sites include settings panels or options for setting preferences like dark mode. Including an option for reduced motion could be a natural next step.

The More We Use It, The Better It Will Get For Everyone

I think it’s important for us, the people designing and building things for the web, to take advantage of the prefers-reduced-motion media feature to make our work more inclusive. By taking steps to respect motion preferences we make the web safer for more people to use, and that can only be a good thing. We absolutely can be expressive and creative with motion on the web while also being responsible and inclusive.

But the awareness level is still something we need to be, well, aware of. Not everyone who might need reduced motion is aware of the option in their OS settings. Perhaps even fewer people know that it can take effect on content in their browser too since so few websites currently take advantage of it. The more we take advantage of the prefers-reduced-motion media feature, and provide a quality reduced motion experience with it, the more meaningful of a feature it will be for those who need it.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
22 Oct

Designing With Reduced Motion For Motion Sensitivities

by TBSCategories: News

CSS has recently added features that allow us to recognize certain user preferences and qualities of the user’s current environment. One of those new features, specifically the prefers-reduced-motion media feature, can be especially useful for designing more inclusive motion on the web.

A few years back, I wrote an article about designing safer web animation for motion sensitivity and the limited options we had at the time to design safe motion on the web. Some things have remained the same since that original article, like the types of motion effects that can be triggering, and the importance of context and user expectations. But what has changed is the existence and support of the prefers-reduced-motion media feature. That makes a big difference in how we can design the motion in our work to be inclusive and accessible.

Why Reduce Motion?

The release of iOS7 back in 2013 sparked a realization throughout the digital design world that some motion on screen — even if it was part of an interface — could have physical consequences for people with motion sensitivities. In the years since then, the major mobile and desktop operating systems have added functionality for people to reduce the amount of motion they encounter in their operating systems.

Articles like “Your Interactive Is Making Me Sick” and “Accessibility For Vestibular Disorders” share first-hand stories of how our design choices, especially around motion, can have physical consequences for those with motion sensitivities. The root causes of these motion sensitivities can vary greatly between individuals. For some, it’s rooted in a vestibular disorder, while for others it might stem from migraines or other factors. What’s triggering can also vary from person to person, or even from day to day for some. The physical symptoms individuals experience as a result of that triggering motion can range from slight dizziness or headaches to nausea or worse.

The design choices we make around animation in our work directly impacts how our work affects people with motion sensitivities. Knowing what kinds of motion are potentially triggering, and how we can mitigate them with our design choices, helps us design experiences that are safe for our audience and won’t cause unintended harm. Animation still absolutely can have a positive impact on our UX efforts, but it’s up to us to make sure we use it responsibly, just like we try to use our other design tools responsibly.

Prefers Reduced Motion On The Web

The prefers-reduced-motion media feature now has strong browser support. It’s supported in current versions of Edge, Firefox, Chrome, Safari, Opera, iOS Safari, as well as on Android Browsers and Chrome for Android. The level of support we have today makes it something that you can absolutely use in production. Also, if someone’s browser doesn’t support this feature, nothing bad happens, it will just be ignored and things will carry on as before.

On the development side, we can test for prefers-reduced-motion in the same way that we would use any other media query in CSS or JavaScript to find out if reduced motion has been requested.

In CSS that will look something like this: 

@media (prefers-reduced-motion: reduce)  {     /* reduced behaviour */    }

And in JavaScript: 

let motionQuery = matchMedia('(prefers-reduced-motion)');  const handleReduceMotionChanged = () => {   if (motionQuery.matches) //reduced behaviour; }  motionQuery.addListener(handleReduceMotionChanged); handleReduceMotionChanged()

Whichever way you choose to access it, this media query will return one of two values: no-preference (false), or reduce (true). Once retrieved, you can use these values to inform what you display in the browser.

Of the two values that can be returned, the only one we can be sure has been set intentionally is the reduce (true) value. No-preference (false) can mean that the person in question is fine with all types of motion, or it could mean that that preference just hasn’t been set yet. This makes any approach that equates the value of no preference (false) to the person in question opting in to all levels of motion unreliable. Because of this, the better approach is to reduce potentially triggering motion effects when a value of reduce (true) is returned.

For example, here the looping bounce animation is replaced with a fade in animation when reduced motion is requested:

/* A constant bouncing motion effect applied to the title */ h2 {   animation: bouncing 1.5s linear infinite alternate; }  /* Replace it with a safer effect when prefers-reduced-motion returns true */ @media (prefers-reduced-motion) {   h2 {   animation: fade 0.5s ease-in both;    }

Reduced Motion From The Users’ Perspective

Most major operating systems allow people to set their preferences in their system settings. The exact wording and location of the settings vary, but the preference can be set on iOS, OSX, Windows, and Android operating systems.

The Prefers Reduced Motion Media Feature In Practice

Deciding how to put the prefers-reduced-motion media feature to use is where we have space for creating solutions that best fit the context of our products and content. For most web projects, you’ll want to first identify any potentially triggering motion effects on your site, and then use the prefers-reduced-motion media feature to provide a reduced version of that effect.

Let’s look at each step in more detail.

Identifying Potentially Triggering Motion

To find any potentially triggering motion you might have, go through some typical user flows for your site or product and take a closer look at the motion effects used: Do you have any interactions that have large movements? Any large zooms, spinning effects, or parallax effects? All of those types of animated effects are very likely to be problematic for people with motion sensitivities. In contrast, animated effects like color fades, opacity changes and small changes in scale are unlikely to be problematic. If in doubt, it can’t hurt to add the effect in question to your “to reduce” list to err on the side of caution.

The Web Content Accessibility Guidelines recommend providing a reduced version for any “motion that creates the illusion of movement…that is not essential to the content’s meaning”. I think it’s helpful to see some examples too, especially if you don’t consider yourself to be sensitive to motion on screen. I cover examples of potentially triggering motion in my previous article and this post on the Webkit blog has some too. Chances are, unless your site relies heavily on motion, you’ll end up with a fairly short list of effects to focus on here.

Create A Reduced Motion Version

Next, you want to determine the most appropriate reduced motion condition for these potentially triggering effects. Can the animation easily be adjusted to use a non-motion effect like an opacity fade or crossfade for reduced motion requests? Would pausing the motion or removing the effect entirely for reduced motion preserve the meaning of the content?

The role of the motion in question will be an important factor in deciding what the most appropriate reduced version would be. You don’t want to unintentionally remove content or degrade the overall experience. Here are a few examples of what might work well for the potentially triggering effects you find:

Large Page Transitions

Large page transition effects can likely be replaced with a crossfade effect for a reduced motion mode. The same is usually true for large zooming or spinning transitions that transition between different states or views.

Animated Illustrations

Animated illustrations, on the other hand, might be best replaced with a static version for reduced motion if they are mostly for personality or branding effect. You’ll want to make sure the static version is still meaningful, and the arrangement that has the most meaning may not always be the very beginning or very end of the animation. Adding in functionality to play animated illustrations on demand for reduced motion could also be useful by allowing people to play the animation when they’re ready for it.

Don’t forget to consider the motion in your animated gifs or auto-playing videos here as well. These can also contain potentially triggering motion and would need a reduced version if they do.

Parallax Effects

Parallax effects and exaggerated smooth scrolling effects are universally triggering for folks with motion sensitivities, so those should be significantly reduced or entirely removed for reduced motion. (Every single person I’ve talked to in my research on this has called out parallax specifically as being a problem for them.) Smooth scrolling effects can be replaced with the default browser anchor link behaviour as described here by Eric Bailey. Removing parallax effects for reduced motion is the ideal solution, but make sure to check that all the necessary content is still visible and usable with the parallax removed.

In most cases substituting the potentially triggering effect with a safer effect for reduced motion is the best way to preserve as much of the content’s intent and usability as possible. Luckily, substituting a reduced effect can be pretty straight forward too.

An Example Of Reducing Motion

For example, let’s say I flagged this header animation as potentially triggering when I went through my site. The motion is large enough to create the illusion of motion, so it’s likely to be triggering, and the multiple directions of motion are also likely to be problematic. It’s definitely one I’d put on my list of effects that need a reduced version when reviewing my site.

The Airpods Pro page also responds to reduced motion preferences, but in a very different way because of the content and effects used. Almost all of the motion on the page could be potentially triggering since it has a lot of big zooming movements and parallax-style effects. When reduced motion is requested, all the parallax and large motion effects are removed, but they do more than just pause or remove the animations. The version you see with reduced motion selected has been designed with care to preserve the same content and meaning from the full motion experience. (Here’s a video of The Airpods Pro site both with and without reduced motion selected for reference.)

Add Custom Toggles For Motion-Heavy Experiences

I mentioned above that most “task-based” sites likely have only a handful of animations that might be triggering and need a reduced version. But those aren’t the only kind of web sites out there on the web. Projects that involve a large amount of motion, like sites that are meant more for storytelling or creating an experience might benefit from a slightly different approach.

For projects like these, it would be difficult to make a list of potentially triggering motions and provide a reduced alternative for each because almost all of the motion used could be potentially triggering. Plus, the motion is very much part of the content and its meaning. Designing a reduced motion mode for these types of sites will take a more global approach and more effort to be sure the meaning of your content is preserved even as motion is reduced.

For these highly animated experience sites, providing a visible custom motion toggle is a useful thing to include. This will allow people who may not yet know about the reduced motion setting, or who are experiencing some motion sensitivity at that moment in time, to quickly adjust the experience. A motion toggle provides a way for motion-sensitive folks to participate in your content in a way that won’t make them sick. That’s definitely better for everyone involved than them having to avoid your site entirely.

Context Is A Key Factor

Remember that context also plays a big role here. No one wants to be surprised by large amounts of motion where they don’t expect it. If you’re visiting a site billed as a highly interactive storytelling experience you’ll have very different expectations than when you’re visiting your bank’s web site. Both of those sites certainly could feature large amounts of animation, but it would be an unexpected surprise on the bank site.

Building A Custom Motion Toggle

The idea of a custom toggle is something that I mentioned back in my 2015 article, but today it’s a much more viable option. On today’s web, we can create one with more ease, and even make a smarter toggle than we could have just a few years ago.

Marcy Sutton has a great example of how a modern custom motion toggle could work in this CodePen. (This example is part of her course on making accessible web apps, which is also very much worth checking out.) Her example uses a toggle to remove all motion because it only includes one animation, but this approach can be used to provide reduced motion effects across an entire application or site following the same logic as well.

The key feature of this approach is how nicely Marcy ties it in with modern web technology, i.e. prefers reduced motion and local storage. When using this approach, if someone comes to your site with reduced motion requested, they automatically get the reduced motion version without having to manually activate the toggle as well. And if someone invokes the toggle to reduce motion, that preference will be saved via local storage so they won’t have to repeatedly make this selection every time they visit.

The official Animal Crossing site is a wonderful real-world example of a custom reduce motion toggle combined with the prefers-reduced-motion media feature. It’s one of my favorite examples of handling reduced motion. The design choices they made around how to reduce potentially the triggering motion, while still keeping true to the overall feel of the site and the content, is great. I wrote more about how they pulled it off in this blog post. There are a lot of sites out there whose audience could benefit from a similar approach.

Other Ways To Use Motion Toggles

If you already have a preferences or settings panel, adding a toggle to request reduced motion could be a valuable thing to add to these settings like Twitter does on its site. In this case, there aren’t large amounts of motion immediately presented when visiting the site and there’s already a settings panel, so implementing the toggle as part of the settings preferences fits well. Twitter’s toggle also respects OS-level settings via the preferes reduced motion query and is preset to either on or off based on what the user has set at the OS level. Designing your motion toggle to respect OS settings is definitely a smart approach to implementing them well no matter where the toggle might appear.

Contextual toggles are another approach that could be used to reduce motion on specific animated illustrations or other content areas that appear throughout your site. The Dark Side of The Grid article does this nicely by adding contextual toggle buttons to each animate figure to allow the reader to play the animation when they want to see it, but not have it loop endlessly while they are reading.

Along those same lines, Dave Rupert shared a technique for combining prefers reduced motion with the picture element to show static elements in place of animated gifs when reduced motion has been requested. Chris Coyier took that one step further and suggested presenting a play toggle for those animated gifs based on the same approach. Steve Faulkner’s gif de-animator example could also be a useful approach.

All of these, or something similar, could be good options for mitigating any potentially triggering motion on the web. I bring up these examples for two reasons. The first is to show that there are a number of ways to approach providing reduced motion variations and you have lots of flexibility to find an approach that fits best for your content. And secondly, as time goes on and more folks are building sites with reduced motion options, the more innovative solutions we’ll see shared in the community.

There are many creative ways to add toggles and settings in a way that makes sense for the context of your project. It’s an interesting parallel that we’re seeing more and more web sites include settings panels or options for setting preferences like dark mode. Including an option for reduced motion could be a natural next step.

The More We Use It, The Better It Will Get For Everyone

I think it’s important for us, the people designing and building things for the web, to take advantage of the prefers-reduced-motion media feature to make our work more inclusive. By taking steps to respect motion preferences we make the web safer for more people to use, and that can only be a good thing. We absolutely can be expressive and creative with motion on the web while also being responsible and inclusive.

But the awareness level is still something we need to be, well, aware of. Not everyone who might need reduced motion is aware of the option in their OS settings. Perhaps even fewer people know that it can take effect on content in their browser too since so few websites currently take advantage of it. The more we take advantage of the prefers-reduced-motion media feature, and provide a quality reduced motion experience with it, the more meaningful of a feature it will be for those who need it.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
21 Oct

Designing With Reduced Motion For Motion Sensitivities

by TBSCategories: News

CSS has recently added features that allow us to recognize certain user preferences and qualities of the user’s current environment. One of those new features, specifically the prefers-reduced-motion media feature, can be especially useful for designing more inclusive motion on the web.

A few years back, I wrote an article about designing safer web animation for motion sensitivity and the limited options we had at the time to design safe motion on the web. Some things have remained the same since that original article, like the types of motion effects that can be triggering, and the importance of context and user expectations. But what has changed is the existence and support of the prefers-reduced-motion media feature. That makes a big difference in how we can design the motion in our work to be inclusive and accessible.

Why Reduce Motion?

The release of iOS7 back in 2013 sparked a realization throughout the digital design world that some motion on screen — even if it was part of an interface — could have physical consequences for people with motion sensitivities. In the years since then, the major mobile and desktop operating systems have added functionality for people to reduce the amount of motion they encounter in their operating systems.

Articles like “Your Interactive Is Making Me Sick” and “Accessibility For Vestibular Disorders” share first-hand stories of how our design choices, especially around motion, can have physical consequences for those with motion sensitivities. The root causes of these motion sensitivities can vary greatly between individuals. For some, it’s rooted in a vestibular disorder, while for others it might stem from migraines or other factors. What’s triggering can also vary from person to person, or even from day to day for some. The physical symptoms individuals experience as a result of that triggering motion can range from slight dizziness or headaches to nausea or worse.

The design choices we make around animation in our work directly impacts how our work affects people with motion sensitivities. Knowing what kinds of motion are potentially triggering, and how we can mitigate them with our design choices, helps us design experiences that are safe for our audience and won’t cause unintended harm. Animation still absolutely can have a positive impact on our UX efforts, but it’s up to us to make sure we use it responsibly, just like we try to use our other design tools responsibly.

Prefers Reduced Motion On The Web

The prefers-reduced-motion media feature now has strong browser support. It’s supported in current versions of Edge, Firefox, Chrome, Safari, Opera, iOS Safari, as well as on Android Browsers and Chrome for Android. The level of support we have today makes it something that you can absolutely use in production. Also, if someone’s browser doesn’t support this feature, nothing bad happens, it will just be ignored and things will carry on as before.

On the development side, we can test for prefers-reduced-motion in the same way that we would use any other media query in CSS or JavaScript to find out if reduced motion has been requested.

In CSS that will look something like this: 

@media (prefers-reduced-motion: reduce)  {     /* reduced behaviour */    }

And in JavaScript: 

let motionQuery = matchMedia('(prefers-reduced-motion)');  const handleReduceMotionChanged = () => {   if (motionQuery.matches) //reduced behaviour; }  motionQuery.addListener(handleReduceMotionChanged); handleReduceMotionChanged()

Whichever way you choose to access it, this media query will return one of two values: no-preference (false), or reduce (true). Once retrieved, you can use these values to inform what you display in the browser.

Of the two values that can be returned, the only one we can be sure has been set intentionally is the reduce (true) value. No-preference (false) can mean that the person in question is fine with all types of motion, or it could mean that that preference just hasn’t been set yet. This makes any approach that equates the value of no preference (false) to the person in question opting in to all levels of motion unreliable. Because of this, the better approach is to reduce potentially triggering motion effects when a value of reduce (true) is returned.

For example, here the looping bounce animation is replaced with a fade in animation when reduced motion is requested:

/* A constant bouncing motion effect applied to the title */ h2 {   animation: bouncing 1.5s linear infinite alternate; }  /* Replace it with a safer effect when prefers-reduced-motion returns true */ @media (prefers-reduced-motion) {   h2 {   animation: fade 0.5s ease-in both;    }

Reduced Motion From The Users’ Perspective

Most major operating systems allow people to set their preferences in their system settings. The exact wording and location of the settings vary, but the preference can be set on iOS, OSX, Windows, and Android operating systems.

The Prefers Reduced Motion Media Feature In Practice

Deciding how to put the prefers-reduced-motion media feature to use is where we have space for creating solutions that best fit the context of our products and content. For most web projects, you’ll want to first identify any potentially triggering motion effects on your site, and then use the prefers-reduced-motion media feature to provide a reduced version of that effect.

Let’s look at each step in more detail.

Identifying Potentially Triggering Motion

To find any potentially triggering motion you might have, go through some typical user flows for your site or product and take a closer look at the motion effects used: Do you have any interactions that have large movements? Any large zooms, spinning effects, or parallax effects? All of those types of animated effects are very likely to be problematic for people with motion sensitivities. In contrast, animated effects like color fades, opacity changes and small changes in scale are unlikely to be problematic. If in doubt, it can’t hurt to add the effect in question to your “to reduce” list to err on the side of caution.

The Web Content Accessibility Guidelines recommend providing a reduced version for any “motion that creates the illusion of movement…that is not essential to the content’s meaning”. I think it’s helpful to see some examples too, especially if you don’t consider yourself to be sensitive to motion on screen. I cover examples of potentially triggering motion in my previous article and this post on the Webkit blog has some too. Chances are, unless your site relies heavily on motion, you’ll end up with a fairly short list of effects to focus on here.

Create A Reduced Motion Version

Next, you want to determine the most appropriate reduced motion condition for these potentially triggering effects. Can the animation easily be adjusted to use a non-motion effect like an opacity fade or crossfade for reduced motion requests? Would pausing the motion or removing the effect entirely for reduced motion preserve the meaning of the content?

The role of the motion in question will be an important factor in deciding what the most appropriate reduced version would be. You don’t want to unintentionally remove content or degrade the overall experience. Here are a few examples of what might work well for the potentially triggering effects you find:

Large Page Transitions

Large page transition effects can likely be replaced with a crossfade effect for a reduced motion mode. The same is usually true for large zooming or spinning transitions that transition between different states or views.

Animated Illustrations

Animated illustrations, on the other hand, might be best replaced with a static version for reduced motion if they are mostly for personality or branding effect. You’ll want to make sure the static version is still meaningful, and the arrangement that has the most meaning may not always be the very beginning or very end of the animation. Adding in functionality to play animated illustrations on demand for reduced motion could also be useful by allowing people to play the animation when they’re ready for it.

Don’t forget to consider the motion in your animated gifs or auto-playing videos here as well. These can also contain potentially triggering motion and would need a reduced version if they do.

Parallax Effects

Parallax effects and exaggerated smooth scrolling effects are universally triggering for folks with motion sensitivities, so those should be significantly reduced or entirely removed for reduced motion. (Every single person I’ve talked to in my research on this has called out parallax specifically as being a problem for them.) Smooth scrolling effects can be replaced with the default browser anchor link behaviour as described here by Eric Bailey. Removing parallax effects for reduced motion is the ideal solution, but make sure to check that all the necessary content is still visible and usable with the parallax removed.

In most cases substituting the potentially triggering effect with a safer effect for reduced motion is the best way to preserve as much of the content’s intent and usability as possible. Luckily, substituting a reduced effect can be pretty straight forward too.

An Example Of Reducing Motion

For example, let’s say I flagged this header animation as potentially triggering when I went through my site. The motion is large enough to create the illusion of motion, so it’s likely to be triggering, and the multiple directions of motion are also likely to be problematic. It’s definitely one I’d put on my list of effects that need a reduced version when reviewing my site.

The Airpods Pro page also responds to reduced motion preferences, but in a very different way because of the content and effects used. Almost all of the motion on the page could be potentially triggering since it has a lot of big zooming movements and parallax-style effects. When reduced motion is requested, all the parallax and large motion effects are removed, but they do more than just pause or remove the animations. The version you see with reduced motion selected has been designed with care to preserve the same content and meaning from the full motion experience. (Here’s a video of The Airpods Pro site both with and without reduced motion selected for reference.)

Add Custom Toggles For Motion-Heavy Experiences

I mentioned above that most “task-based” sites likely have only a handful of animations that might be triggering and need a reduced version. But those aren’t the only kind of web sites out there on the web. Projects that involve a large amount of motion, like sites that are meant more for storytelling or creating an experience might benefit from a slightly different approach.

For projects like these, it would be difficult to make a list of potentially triggering motions and provide a reduced alternative for each because almost all of the motion used could be potentially triggering. Plus, the motion is very much part of the content and its meaning. Designing a reduced motion mode for these types of sites will take a more global approach and more effort to be sure the meaning of your content is preserved even as motion is reduced.

For these highly animated experience sites, providing a visible custom motion toggle is a useful thing to include. This will allow people who may not yet know about the reduced motion setting, or who are experiencing some motion sensitivity at that moment in time, to quickly adjust the experience. A motion toggle provides a way for motion-sensitive folks to participate in your content in a way that won’t make them sick. That’s definitely better for everyone involved than them having to avoid your site entirely.

Context Is A Key Factor

Remember that context also plays a big role here. No one wants to be surprised by large amounts of motion where they don’t expect it. If you’re visiting a site billed as a highly interactive storytelling experience you’ll have very different expectations than when you’re visiting your bank’s web site. Both of those sites certainly could feature large amounts of animation, but it would be an unexpected surprise on the bank site.

Building A Custom Motion Toggle

The idea of a custom toggle is something that I mentioned back in my 2015 article, but today it’s a much more viable option. On today’s web, we can create one with more ease, and even make a smarter toggle than we could have just a few years ago.

Marcy Sutton has a great example of how a modern custom motion toggle could work in this CodePen. (This example is part of her course on making accessible web apps, which is also very much worth checking out.) Her example uses a toggle to remove all motion because it only includes one animation, but this approach can be used to provide reduced motion effects across an entire application or site following the same logic as well.

The key feature of this approach is how nicely Marcy ties it in with modern web technology, i.e. prefers reduced motion and local storage. When using this approach, if someone comes to your site with reduced motion requested, they automatically get the reduced motion version without having to manually activate the toggle as well. And if someone invokes the toggle to reduce motion, that preference will be saved via local storage so they won’t have to repeatedly make this selection every time they visit.

The official Animal Crossing site is a wonderful real-world example of a custom reduce motion toggle combined with the prefers-reduced-motion media feature. It’s one of my favorite examples of handling reduced motion. The design choices they made around how to reduce potentially the triggering motion, while still keeping true to the overall feel of the site and the content, is great. I wrote more about how they pulled it off in this blog post. There are a lot of sites out there whose audience could benefit from a similar approach.

Other Ways To Use Motion Toggles

If you already have a preferences or settings panel, adding a toggle to request reduced motion could be a valuable thing to add to these settings like Twitter does on its site. In this case, there aren’t large amounts of motion immediately presented when visiting the site and there’s already a settings panel, so implementing the toggle as part of the settings preferences fits well. Twitter’s toggle also respects OS-level settings via the preferes reduced motion query and is preset to either on or off based on what the user has set at the OS level. Designing your motion toggle to respect OS settings is definitely a smart approach to implementing them well no matter where the toggle might appear.

Contextual toggles are another approach that could be used to reduce motion on specific animated illustrations or other content areas that appear throughout your site. The Dark Side of The Grid article does this nicely by adding contextual toggle buttons to each animate figure to allow the reader to play the animation when they want to see it, but not have it loop endlessly while they are reading.

Along those same lines, Dave Rupert shared a technique for combining prefers reduced motion with the picture element to show static elements in place of animated gifs when reduced motion has been requested. Chris Coyier took that one step further and suggested presenting a play toggle for those animated gifs based on the same approach. Steve Faulkner’s gif de-animator example could also be a useful approach.

All of these, or something similar, could be good options for mitigating any potentially triggering motion on the web. I bring up these examples for two reasons. The first is to show that there are a number of ways to approach providing reduced motion variations and you have lots of flexibility to find an approach that fits best for your content. And secondly, as time goes on and more folks are building sites with reduced motion options, the more innovative solutions we’ll see shared in the community.

There are many creative ways to add toggles and settings in a way that makes sense for the context of your project. It’s an interesting parallel that we’re seeing more and more web sites include settings panels or options for setting preferences like dark mode. Including an option for reduced motion could be a natural next step.

The More We Use It, The Better It Will Get For Everyone

I think it’s important for us, the people designing and building things for the web, to take advantage of the prefers-reduced-motion media feature to make our work more inclusive. By taking steps to respect motion preferences we make the web safer for more people to use, and that can only be a good thing. We absolutely can be expressive and creative with motion on the web while also being responsible and inclusive.

But the awareness level is still something we need to be, well, aware of. Not everyone who might need reduced motion is aware of the option in their OS settings. Perhaps even fewer people know that it can take effect on content in their browser too since so few websites currently take advantage of it. The more we take advantage of the prefers-reduced-motion media feature, and provide a quality reduced motion experience with it, the more meaningful of a feature it will be for those who need it.

Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us