To create special motion effects, ARWES provides an animator system to orchestrate UI elements transitions and functionalities to facilitate the execution of animations on those transitions, along with some utilities to create certain common sci-fi animation effects.

ARWES motion tools are mostly to orchestrate animations rather than running them. There are many great options already available such as GSAP, Framer Motion, and Anime.js to run animations and special effects, ARWES is intended to be used along with them.

ARWES uses Motion One behind the scenes to run animations for its performance both at run time and file size. But it is limited due to its simplicity. So using ARWES along with other tools is encouraged.

Animator System

An animator system is a tree of animator nodes, similar to the DOM, a directed acyclic graph (DAG), with a root node to control the animation flow and children nodes which transition based on a set of rules. An animator node is supposed to manage a group of UI elements to transition according to its configuration.

An animator node is a finite state machine (FSM) which can be in one of the following states:

• Exited: Denotes elements which are invisible/unavailable to the user. The default state.
• Entering: Denotes elements which are transitioning into the app.
• Entered: Denotes elements which are visible/available to the user.
• Exiting: Denotes elements which are transitioning out of the app.

An animator node has the following transitions:

• Enter: From exited/exiting to entering to entered. To show/enable elements.
• Exit: From entered/entering to exiting to exited. To hide/disable elements.

By default, a parent animator node which is in exited state will have all its children in exited state too. When it enters and transitions to entered state, then it enters its children nodes. Similar like a cascade. And then the children nodes continue the same process unless configured otherwise.

Normally, there is one root node which receives orders to activate or not. If it is activated, then it enters the cascade of nodes in their predefined order. Otherwise, it exits them all at the same time.

An animator node uses a "manager" to transition its children nodes. By default it is done in parallel but this can be configured, for example, to transition children nodes in sequence.

Some animators can "combine" all their children into one to allow more complex cascade effects and properly calculate the entire duration of animations.

These patterns simplify the creation of complex transition animations using serial, parallel, sequence, staggering, and other strategies in trees of nodes. There are also a few other settings an animator node can have to configure how and when it should transition itself and its children, allowing the creation of very rich motion effects.

Animated Elements

An animator node can be linked to zero, one, or multiple UI elements such as HTML, SVG, 2D Canvas, or 3D WebGL elements. These UI elements basically listen to their animator node state changes and execute animations on specific states.

In the example above, there is only one animator node, but the two border lines, the background shape, and the text element, listen to it and have different transition animations in different times with different durations.

Dynamic Transitions

Some effects should be calculated dynamically such as text transitions which should have a different duration based on the length of the content. ARWES provides a few text transition animations which resemble many famous special effects. They can dynamically calculate how long should a duration last and modify their linked animator nodes transition durations.

In the example above, each paragraph has its own animator node, and each one with its own calculated transition durations.

Subsystems

Normally, an app will have a main animator system with multiple nested subsystems, which can operate based on specific nodes conditions or independently as the user needs.

The common example is a app system composed of header, sidebars, content, and footer, where the header and footer remain the same but the sidebars and content are subsystems which change based on the URL. These subsystems still listen to the main system so they transition when it is their time.

For some apps, they can make use of the exit transition for the subsystems when they change, for others, they can be inmediately removed from the user experience and transition in the new subsystems. It is up to the user to decide which workflows and transitions to use for an app.

Some apps may not even need the exit transition for the most part but certain UI elements can still use it. Such as micro-interactions similar to the CSS hover effect, when the user enters the mouse in an UI element, it updates its style, and when it exits the mouse, it updates the styles back to the original styles, in this case, the exiting animations.

Accessibility

It mostly depends on the target audience to determine what kind and the intensity of animations to add to an app. For a gaming community it may be wonderful to have a game-like user experience by default, but for others, checking on user preferences before even rendering the interfaces may be a recommended option. prefers-reduced-motion is a useful API to use.

Performance

In any app, regardless of ARWES, there might be performance implications if there are too many animations running at the same time, specially for mobile devices, so choosing carefully the most important UI elements to animate and the kind of animations is recommended.

For HTML and SVG, make sure to prioritize CSS opacity, transform, and filter properties for animations for performance and compatibility reasons. See more on How to create high-performance CSS animations.

When to Use

The animator system is intended to be used for main structural UI elements but can be used anywhere for anything. For many use cases in HTML and SVG, simple CSS transitions are enough. But when the structure or interaction is more complex, an animator node can be the solution.