Kinetics & Mobile Devices
How Touchscreens and Small Viewports Affect Kinetics
Mobile devices have unique properties that affect the way we think about motion. Note that these properties aren’t unique to mobile phones, and are worth considering in similarly equipped laptop and desktop computers.
A small viewport can be a small device screen, or a small browser window on a desktop. Smaller viewports sometimes change the visual design of a component. For example, the Lightning progress indicator enlarges its dots for easier touchability in a compact space. For minor visual adjustments like these, the component can use the same transitions as its larger-viewport counterpart. But if the component looks entirely different, it needs its own component motion design.
As viewports get smaller, components become larger in relative size, covering more of the screen. Transitions that cover an entire screen can be harmful to some users. Make sure to use the operating system’s reduced motion preference
These considerations apply to any device with a touchscreen: mobile phones, tablets, touch-enabled laptops, watches, etc.
- Beware of small transitions that occur below touch targets. The user’s hand might cover the transition.
- For component active stages to work on touchscreens, web developers will need to set an empty ontouchstart event handler. (Learn more about Implementing Kenetics)
- Touchscreens afford motion that’s controlled both instantly and continuously: triggered by a discrete gesture like a button tap, or a continuous gesture like a swipe or pan. Continuous gestures should track 1:1 with the motion. When the gesture is complete – for example, the user lifts their finger – a Kinetics motion should complete the transition. The speed and acceleration of this finishing motion should complement the remaining travel distance of the element that’s in motion. (Learn more about Implementing Kenetics)
Most touchscreen devices don’t support hover states. Feedback hovers are okay to ignore on touchscreens, but reveal hovers need to be touchscreen-accessible. To present supplemental information in mobile, consider using a tap or long press, or present the information automatically depending on the context of use.
To ensure accessibility and ease of discoverability of essential information, avoid hiding important information behind long presses. Instead, use long presses to support power user interactions like quick access of an opportunity.
Accelerometers and gyroscopes offer unique opportunities for immersive motion. For select moments, consider how the shake or tilt of a device could drive motion effects like parallax. However, uses this carefully. Studies have repeatedly revealed that long scrolling parallax don’t add much of a visual or functional value to its users. Parallax and similar immersive effects can also be harmful to users with vestibular disorders. In general, dependance on the use of parallax effects for visual storytelling is not recommended. Turn these effects off if the operating system’s reduced motion preference is enabled. (Learn more Kinetics & Accessibility.)
Integrating with Native Systems
These considerations apply to any operating system integration: mobile, desktop, watch, etc.
- Current Lightning mobile apps take a hybrid approach, blending the native operating system’s navigation model with Lightning components and Kinetics. There are distinct spatial models for each operating system.
- In general, when developing a native app, a principal consideration is the spatial model. If you’re using the operating system’s built-in perspectives on things like modals and navigation, you’ll usually want to observe the system’s model for staging and direction. For example, iOS modals hide below the viewport while off-screen, so they should animate upward into view.
- If the system allows it, you may customize native components to have Kinetics qualities – especially if you’ve customized the visual design to look like a Lightning component. For example, you might consider using Kinetics activation patterns like ripples or border swirls in components like buttons.
For native components that you use as-is – for example, date pickers and other virtual keyboards – you don’t need to apply Kinetics.