![\"A](\"https:\/\/hexboxdev.wpenginepowered.com\/wp-content\/uploads\/2023\/06\/transition-design-before.gif\"){kind=spacer}
<\/p>\n
That was easy! However, there are a few changes we can make to improve this transition<\/p>\n
- \n
- Simplify the \u201cgesture\u201d. <\/strong>The title and image move in conflicting directions, which makes the overall transition confusing to follow. When all elements move in a cohesive manner, the overall gesture becomes easier to understand.<\/li>\n
- Speed it up<\/strong>. People can make decisions on what to do next in as little as 100ms. If your transition takes much longer than that, you are slowing users down. 400ms is a good starting point for full-page transitions. It gives users just enough time to understand where elements have moved.<\/li>\n
- Make the spring effect subtler<\/strong>. We can draw less attention to the animation with a subtler easing effect. We want people to focus on the content, not the animation.<\/li>\n<\/ul>\n
Here\u2019s a version that is clearer and less distracting, keeping users focused on the content.<\/p>\n
![\"A](\"https:\/\/hexboxdev.wpenginepowered.com\/wp-content\/uploads\/2023\/06\/transition-design-after-1.gif\")
<\/p>\nTips<\/h3>\n
- \n
- Consider creating a separate prototype specifically for demoing this transition. It can be difficult to make Smart Animate work with components, AutoLayout, and other Figma features since the layer structure and naming has to match exactly.<\/li>\n<\/ul>\n
How to Build Shared Element Transitions<\/h2>\n
You might be thinking, how can I export my awesome transition from Figma? Unfortunately there isn\u2019t a reliable way to go from Figma to code on anything but the simplest projects. However, Implementing shared element transitions can be straightforward. Most platforms provide an API for this purpose. We’ll take a brief look at how to implement this transition style on each.<\/p>\n
The Process, Generally<\/h3>\n
The APIs on these platforms generally follow the same steps:<\/p>\n
- \n
- Identify elements to be transitioned in both views with a unique id<\/li>\n
- Change UI state using a special method that triggers a transition<\/li>\n
- Let the platform handle the transition animations automatically<\/li>\n<\/ol>\n
Gotchas<\/h3>\n
For the most part, implementation should be pretty simple, but there are are a few topics that could require special thought or more work in code.<\/p>\n
- \n
- Preserving scroll position.<\/strong>\u00a0you need to ensure that when users close the “expanded” view, the list page returns to the same scroll position as before. This way, users won’t lose their place when switching back and forth between the views.<\/li>\n
- Platform features don\u2019t always work well together.<\/strong>\u00a0Depending on the platform and how your app is set up, you may get frustrated when platform features don\u2019t work well together. Be prepared to compromise, simplify, or abandon this transition style.<\/li>\n
- Some users prefer reduced motion. <\/strong>This can be for accessibility or motion-sickness reasons. Many platforms offer features to check if a user has indicated their preference for reduced motion. Look into your platform’s capabilities and consider disabling the animation for those users or offering an alternative like a simple dissolve.<\/li>\n<\/ul>\n
Examples<\/h3>\n
The code in this article is simplified for brevity. For detailed code examples, I have put together this example repository<\/a> on GitHub with samples for iOS, Android, and the web.<\/p>\n
On the Web<\/h3>\n
In the past, implementing shared element transitions on the web required careful planning and tricky calculations using the “F.L.I.P. Technique”<\/a>. However, thanks to the new View Transitions API<\/a>, creating these transitions is much simpler. With this standardized API, we can smoothly transition between views with just a few lines of JavaScript and CSS.<\/p>\n
Give Unique Ids to Shared Elements<\/h4>\n
First, we give unique IDs to the elements we want to transition using the CSS rule
view-transition-name<\/code>. These IDs help the browser recognize and move the elements to their desired positions during the transition, just like how matching layer names work with Figma\u2019s Smart Animate. Here is simplified HTML for an article preview in a list:<\/p>\n<article>\n <!-- note that we need unique view transition names per article -->\n <img style=\"view-transition-name: article-1-image;\" src=\"...\" alt=\"...\" \/>\n <h2 style=\"view-transition-name: article-1-title;\">Example Article<\/h2>\n<\/article><\/code><\/pre>\nAnd the full article on another screen:<\/p>\n
<main>\n <img style=\"view-transition-name: article-1-image;\" src=\"...\" alt=\"...\" \/>\n <h1 style=\"view-transition-name: article-1-title;\">Example Article<\/h1>\n <!\u2014 ... \u2014>\n<\/main><\/code><\/pre>\nTrigger the Transition<\/h4>\n
When the article is tapped, we will present the full content of the article. To tell the browser these changes are a part of a transition, we have to use a special JavaScript function.<\/p>\n
document.startViewTransition(() => changeTheDocumentSomehow());<\/code><\/pre>\nResult<\/h4>\n
Now, when we click on the article:<\/p>\n
![\"Website](\"https:\/\/hexboxdev.wpenginepowered.com\/wp-content\/uploads\/2023\/06\/transition-web.gif\")
<\/p>\nThat’s it! As long as the shared elements share the same unique
view-transition-name<\/code> on both screens, they will transition smoothly. It’s not even necessary for the screens to have a similar structure. If desired, you can customize the transition<\/a>, but the default animation is suitable for many use cases.<\/p>\nSupport<\/h4>\n
You can use the View Transitions API today, although browser support is limited. As of now, you can expect it to work for about 65% of your users<\/a>. Don’t let this stop you from using the API. Browsers are designed to ignore unsupported CSS rules, so including
view-transition-name<\/code> won’t cause any issues. As for the JavaScript, we just have to check if thestartViewTransition<\/code> function exists before we use it.<\/p>\nif (document.startViewTransition) {\n document.startViewTransition(() => changeTheDocumentSomehow());\nelse {\n changeTheDocumentSomehow()\n}<\/code><\/pre>\nView Transitions are simple, performant, and concise. They are low-risk progressive enhancements<\/a> that can make certain kinds of page transitions easier for your users to understand.<\/p>\n
Tips<\/h4>\n
- \n
- Give transitioned images a similar aspect ratio in both views. The default animation for view transitions is more of a cross-fade than a blend. Matching aspect ratios will look smoother during the transition.<\/li>\n
- For smoother text transitions, consider utilizing the CSS properties
width: max-content;<\/code> andmax-width: 100%;<\/code> Depending on the length and style of text, this approach can result in a more seamless blend. Additionally, animating text that has the same or similar number of lines in both views will further contribute to a smoother and more cohesive transition.<\/li>\n<\/ul>\niOS and Other Apple Platforms<\/h3>\n
A SwiftUI View Modifier called matchedGeometryEffect<\/a> provides a process for animating between views very similar to the web\u2019s View Transitions API. It’s a declarative API that is flexible in terms of layout structure.<\/p>\n
Data Model<\/h4>\n
There are a dozen ways of managing state in Apple apps. Here’s what our Article model looks like.<\/p>\n
class Article: Identifiable {\n var title = \"How Now Brown Cow? Nursery Rhymes in the Age of Artificial Intelligence\"\n var content = \"Lorem ipsum dolor ist amet\"\n var image = \"hexter\"\n\n \/\/ MARK: for animations\n var titleId: String { \"article \\(id) title\" }\n var imageId: String { \"article \\(id) image\" }\n}<\/code><\/pre>\nNote
titleId<\/code> andimageId<\/code>. These will give us ids for shared elements that are unique per article. This is needed to distinguish between articles.<\/p>\nCreate The List and Detail Views<\/h4>\n
Next, lets create a View that changes based on some state.<\/p>\n
enum BlogViewState {\n case normal\n case article(article: Article)\n}\n\nstruct BlogView: View {\n \/\/...\n\n @State private var state: BlogViewState\n\n var body: some View {\n switch state {\n case .normal:\n \/\/ show a list of articles...\n\n case .article(let article):\n \/\/ show the full article...\n }\n }\n}<\/code><\/pre>\nSet up the Transition<\/h4>\n
Next, we add a namespace for this animation. SwiftUI uses namespaces to prevent animations from conflicting.<\/p>\n
struct BlogView: View {\n \/\/...\n @Namespace private var articleAnimationNamespace\n}<\/code><\/pre>\nNext, we add the
.matchedGeometryEffect<\/code> modifier to the elements we want to transition. We need to give the shared elements matching ids on both views.<\/p>\ncase .normal:\n \/\/ somewhere in a list of article previews ...\n Text(article.title)\n .matchedGeometryEffect(id: article.titleId, in: articleAnimationNamespace)\n Image(article.image)\n .matchedGeometryEffect(id: article.imageId, in: articleAnimationNamespace)\n\ncase .article(let article):\n \/\/...\n Text(article.title)\n .matchedGeometryEffect(id: article.titleId, in: articleAnimationNamespace)\n Image(article.image)\n .matchedGeometryEffect(id: article.imageId, in: articleAnimationNamespace)<\/code><\/pre>\nTrigger the Transition<\/h4>\n
Now, we\u2019ll add some code to switch between the views. Note that we need to change the state using a special method
withAnimation<\/code> to tell SwiftUI that the change should trigger a transition.<\/p>\ncase .normal:\n \/\/ ...\n VStack {\n \/\/ article preview layout...\n }\n .onTapGesture { \n withAnimation {\n state = .article(article: article)\n }\n }<\/code><\/pre>\nResult<\/h4>\n
Now, when we tap on the article:<\/p>\n
![\"iPhone](\"https:\/\/hexboxdev.wpenginepowered.com\/wp-content\/uploads\/2023\/06\/transition-mobile.gif\")
<\/p>\nIn theory, the process is concise and straightforward. However, in practice, these transitions can require lots of trial-and-error to get right, particularly when combining them with other SwiftUI modifiers like
.edgesIgnoringSafeArea<\/code>. If you intend to use this API, I suggest starting your experimentation in code before choosing a design. It could save you a lot of frustration.<\/p>\nSupport<\/h4>\n
.matchedGeometryEffect<\/code> is supported on iOS 14 and later, which is widely adopted. If you need to support older iOS versions, you may need to add a check for the iOS version to prevent errors.<\/p>\nTips<\/h4>\n
- \n
- Experiment with the
properties:<\/code> andanchor:<\/code> arguments ofmatchedGeometryEffect<\/code>. Text boxes, for example, should not animate their size because the characters will wrap, and they should have a stable top leading corner when moving.<\/li>\n- Experiment with the structure of the elements. Things like
.clipPath<\/code> andScrollView<\/code> can have various undesirable effects on the transition.<\/li>\n<\/ul>\nAndroid<\/h3>\n
Shared Element Transitions in Android can be implemented in quite a few ways. It\u2019s difficult to tell exactly which method is best. It will depend highly on how your app navigation is set up. I will show one way that works with Android\u2019s newest graph-based navigation<\/a>. I won\u2019t explain as much of the Android code because it’s a bit more verbose than other platforms.<\/p>\n
Set up Navigation<\/h4>\n
First, set up your navigation graph. A navigation graph describes how users can navigate between screens in your app. I have two screens that users can navigate between, a list view and a detail view. The navigation graph looks like this in Android Studio:
![\"nav_graph.xml](\"https:\/\/hexboxdev.wpenginepowered.com\/wp-content\/uploads\/2023\/06\/android-nav-graph.jpg\")
<\/p>\nThe Article Class<\/h4>\n
There are a thousand ways to manage state in Android. Our article data looks something like this:<\/p>\n
data class Article(\n val title: String,\n) {\n val id = UUID.randomUUID().toString()\n val imageId: String get() = \"article $id image\"\n val titleId: String get() = \"article $id title\"\n}<\/code><\/pre>\nNote
imageId<\/code> andtitleId<\/code>. This gives us unique ids that we can use to identify shared elements on the source and target screens. If they weren’t unique, Android won’t be able to distinguish article images and titles from each other on the article list page (and the program will crash!).<\/p>\nSetting up the Source View (the List View)<\/h4>\n
First, in the code for the list view, we apply the ids to each shared element’s
transitionName<\/code>.<\/p>\nval article = articles[index]\n\/\/ ...\nlistItem.textView.transitionName = article.titleId\nlistItem.imageView.transitionName = article.imageId<\/code><\/pre>\nNext, when we tap the article, we navigate to the target view (the detail view). When we do this, we have to add some extra info to tell Android to transition the shared elements.<\/p>\n
val extras = FragmentNavigatorExtras(\n textView to article.titleId,\n imageView to article.imageId\n)\nview.findNavController().navigate(R.id.articleListToDetails, null, null, extras)<\/code><\/pre>\nSetting up the Target View (the Detail View)<\/h4>\n
On the target view (the article detail view), we need to add an enter transition. First we create an xml file at
res\/transitions\/shared_element.xml<\/code>. This file tells Android what it should animate on the shared views.<\/p>\n<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<transitionSet>\n <changeImageTransform\/>\n <changeBounds\/>\n <changeTransform\/>\n<\/transitionSet><\/code><\/pre>\nNext, apply the enter transition to the target view.<\/p>\n
override fun onCreate(savedInstanceState: Bundle?) {\n \/\/ ...\n sharedElementEnterTransition = TransitionInflater.from(requireContext())\n .inflateTransition(R.transition.shared_element)\n}<\/code><\/pre>\nFinally, since we need the
transitionName<\/code>s to be unique per article, we have to set these ids dynamically in the detail view. More, we need to set the ids before the transition starts. Android providespostponeEnterTransition()<\/code> andstartPostponedEnterTransition()<\/code> for this purpose.<\/p>\noverride fun onCreate(\/* ... *\/) {\n \/\/ ...\n postponeEnterTransition()\n}<\/code><\/pre>\nNow, we add
transitionName<\/code>s to the shared elements.<\/p>\noverride fun onCreateView(\/* ... *\/) {\n \/\/ ...\n val title = view.findViewById<TextView>(R.id.article_title)\n title.transitionName = article.titleId\n \n val image = view.findViewById<ImageView>(R.id.article_image)\n image.transitionName = article.imageId\n}<\/code><\/pre>\nFinally, we resume the transition once the view has finished initializing.<\/p>\n
override fun onViewCreated(\/* ... *\/) {\n \/\/ ...\n startPostponedEnterTransition()\n}<\/code><\/pre>\nResult<\/h4>\n
![\"Android](\"https:\/\/hexboxdev.wpenginepowered.com\/wp-content\/uploads\/2023\/06\/transition-android.gif\")
<\/p>\nOnce you find the correct transition process to use for your navigation setup, it should be fairly straightforward to implement. Though, since Android requires more setup and more files than other platforms, it will take some time and debugging to make things work as expected.<\/p>\n
Cross-Platform<\/h3>\n
Similar solutions are available on popular cross-platform solutions as well. I haven\u2019t explored these thoroughly.<\/p>\n
React Native<\/h4>\n
There’s no built-in process for shared element transitions. But
react-native-shared-element<\/code> is a popular community library<\/a> for achieving this effect. For those looking for something closer to a standard API, Expo (one of the de-facto standard frameworks for react native) is working on an API for this<\/a>. It’s in alpha, so it’s not yet ready for use.<\/p>\nFlutter<\/h4>\n
Flutter calls these transitions “Hero animations,”<\/a> presumably because elements “fly” from one screen to the other. I haven’t tried it yet, but the API seems about as simple as the web’s View Transitions API.<\/p>\n
Shared Element Transitions Can Be Easy<\/h2>\n
You can build these view transitions today on some platforms without too much of a hassle. But expect some degree of debugging and compromise. If you’re interested in digging deeper to see what it takes, take a look at working example code at this GitHub repo<\/a>.<\/p>\n
\nLet’s build awesome things together.<\/h2>\n
Our approach to Product Design & UX is holistic, integrating business, tech, user needs, and market demands.<\/p>\n
Explore Software Product Design Services \u00bb<\/a><\/p>\n<\/div>\n
You Might Also Like<\/strong><\/p>\n
- \n
- 10 Figma Shortcuts to Improve Your UI Design Proficiencies<\/a><\/li>\n
- Welcome to the Dark Side: 6 Tips for Designing a Dark Mode Version of Your App<\/a><\/li>\n
- Indianapolis Web Development Example: Using Collaboration to Build a Better Product (Case Study)<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
What are Shared Element Transitions? Shared Element Transitions are animations that move elements from one screen to another within an app. They help users understand how the interface changes when navigating between screens. They are particularly effective when users are browsing diverse content and frequently switching back and forth between screens. These transitions can be […]<\/p>\n","protected":false},"author":32,"featured_media":32068,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","associated_team_member":0,"associated_user_id":0,"footnotes":""},"categories":[273,256,268,366],"tags":[398,254,295,274,292,367],"service":[],"class_list":["post-32064","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobile","category-product-design-ux","category-programming","category-web","tag-android","tag-design","tag-ios","tag-mobile","tag-ux","tag-web"],"_links":{"self":[{"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/posts\/32064","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/comments?post=32064"}],"version-history":[{"count":0,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/posts\/32064\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/media\/32068"}],"wp:attachment":[{"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/media?parent=32064"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/categories?post=32064"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/tags?post=32064"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/hexboxdev.wpenginepowered.com\/wp-json\/wp\/v2\/service?post=32064"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Welcome to the Dark Side: 6 Tips for Designing a Dark Mode Version of Your App<\/a><\/li>\n
- Experiment with the structure of the elements. Things like
- Experiment with the
- Platform features don\u2019t always work well together.<\/strong>\u00a0Depending on the platform and how your app is set up, you may get frustrated when platform features don\u2019t work well together. Be prepared to compromise, simplify, or abandon this transition style.<\/li>\n
- Preserving scroll position.<\/strong>\u00a0you need to ensure that when users close the “expanded” view, the list page returns to the same scroll position as before. This way, users won’t lose their place when switching back and forth between the views.<\/li>\n
- Speed it up<\/strong>. People can make decisions on what to do next in as little as 100ms. If your transition takes much longer than that, you are slowing users down. 400ms is a good starting point for full-page transitions. It gives users just enough time to understand where elements have moved.<\/li>\n