There's no reason for route transition to be a special case of state transition.
Here are some examples of state transitions that can be augmented with animations:
- reorder items in a lost
- add/remove an item from a list
- expand/collapse an element
- hover/press/disable a button
- show a popup
- show an inline error message
- open a drop down menu
- open/close a burger menu
- change the burger menu button to a back button
- change the scroll offset to a new item/anchor
- increase the height of a text field
- show/hide the top menu/navigation bar
- add an item to the cart (and the count badge appears/increases)
- increase the value of a progress bar
- image goes from loading/placeholder to loaded
As you can imagine, most of these state changes benefit from transition animations (scale, translate, opacity). We just add linear interpolation to a discrete change.
Can you think of a good reason to use different techniques and APIs to implement route transition animations and button state transitions? I can't.
Once you think about using gestures for continuous transitions (swipe to go back on iOS), it makes even more sense to think of these components as physical overlapping sheets of material, with their own weight, inertia, grip/transition/friction, rails, anchors, springs.
Consider these interactions:
- swiping from the edge to reveal a side burger menu
- swiping from the edge to reveal the previous page
- swiping down to dismiss a bottom sheet
- scrolling down to reveal additional list items
- swiping horizontally to reveal actions under a list item
- dragging horizontally to move the thumb of a slider around
- pinching to zoom-in on a picture
These are all types of continuous navigations. They don't require animations because you're continuously animating them using touch. These interactions should be easy to implent. Programmatic discrete state changes should automatically infer transitions based on physical characteristics of these materials.
What's a route? Should the currently selected tab be part of the route? Should the expanded/collapsed state of a widget be part of the route? Should the visibility of a popup be part of the route? Should the vertical scroll offset be part of the route? Should the zoom level of a map be part of the route? Should the open/close state of a burger menu be part of the route? I think the concept of a route doesn't make a lot of sense if it doesn't capture the entire state and history of a person's interaction with an app. I see no reason why the browser history/backstack should discriminate against different navigation patterns, and only store pages. Adding all state changes to the history makes it easy to use the back button to dismiss a popup, close a burger menu, close the keyboard, etc. Heck, all apps should have universal undo/redo functionality.
Another specific type of transition people are struggling with are shared element transitions. For example, you tap on a thumbnail and it seamlessly animates into a detail page with a larger version of that image. This is easier to do as a layout transition than as a route transition.
A last thing to keep in mind is that layouts don't need to immediately create and render all of their elements. We can use virtualization, to only materialize what is currently visible. For example, a list of 1000 items will only materialize the 10 or so items it can display at once, and will dynamically create/recycle items as the user scrolls. The exact same strategy can be used if we're stacking items on a Z axis. For example, we could create and render the top 2 items (so that the previous item is immediately visible in a swipe back to reveal scneario), and only create and render other items as they get closer to the top of the stack.
A route is the thing that I send to another person or save myself so that the specific piece of information I am looking at can be found again. There is a decision that has to be made, though. My selected text is never part of a route, but that might be the information I want to share. Conversely, when I open a hamburger menu to click the share button, the hamburger menu's open state is never the information I want to share.
Another consideration: does the route encompass the concept of the information being displayed, or the actual information? We typically solve this with a "permalink", where one route represents the concept (feed, newest, etc) and the permalink represents the specific information.
Here are some examples of state transitions that can be augmented with animations:
- reorder items in a lost
- add/remove an item from a list
- expand/collapse an element
- hover/press/disable a button
- show a popup
- show an inline error message
- open a drop down menu
- open/close a burger menu
- change the burger menu button to a back button
- change the scroll offset to a new item/anchor
- increase the height of a text field
- show/hide the top menu/navigation bar
- add an item to the cart (and the count badge appears/increases)
- increase the value of a progress bar
- image goes from loading/placeholder to loaded
As you can imagine, most of these state changes benefit from transition animations (scale, translate, opacity). We just add linear interpolation to a discrete change.
Can you think of a good reason to use different techniques and APIs to implement route transition animations and button state transitions? I can't.
Once you think about using gestures for continuous transitions (swipe to go back on iOS), it makes even more sense to think of these components as physical overlapping sheets of material, with their own weight, inertia, grip/transition/friction, rails, anchors, springs.
Consider these interactions:
- swiping from the edge to reveal a side burger menu
- swiping from the edge to reveal the previous page
- swiping down to dismiss a bottom sheet
- scrolling down to reveal additional list items
- swiping horizontally to reveal actions under a list item
- dragging horizontally to move the thumb of a slider around
- pinching to zoom-in on a picture
These are all types of continuous navigations. They don't require animations because you're continuously animating them using touch. These interactions should be easy to implent. Programmatic discrete state changes should automatically infer transitions based on physical characteristics of these materials.
What's a route? Should the currently selected tab be part of the route? Should the expanded/collapsed state of a widget be part of the route? Should the visibility of a popup be part of the route? Should the vertical scroll offset be part of the route? Should the zoom level of a map be part of the route? Should the open/close state of a burger menu be part of the route? I think the concept of a route doesn't make a lot of sense if it doesn't capture the entire state and history of a person's interaction with an app. I see no reason why the browser history/backstack should discriminate against different navigation patterns, and only store pages. Adding all state changes to the history makes it easy to use the back button to dismiss a popup, close a burger menu, close the keyboard, etc. Heck, all apps should have universal undo/redo functionality.
Another specific type of transition people are struggling with are shared element transitions. For example, you tap on a thumbnail and it seamlessly animates into a detail page with a larger version of that image. This is easier to do as a layout transition than as a route transition.
A last thing to keep in mind is that layouts don't need to immediately create and render all of their elements. We can use virtualization, to only materialize what is currently visible. For example, a list of 1000 items will only materialize the 10 or so items it can display at once, and will dynamically create/recycle items as the user scrolls. The exact same strategy can be used if we're stacking items on a Z axis. For example, we could create and render the top 2 items (so that the previous item is immediately visible in a swipe back to reveal scneario), and only create and render other items as they get closer to the top of the stack.