On a learning platform, a course card should expand into the course detail view. How do you design that shared-element transition, and when would you avoid one?

## What a shared-element transition is A **shared-element transition** animates an element that appears in two views so that it seems to travel from its place in the first view to its place in the second. A **container transition** is the related pattern in which a whole surface, such as a card, grows or shrinks into another surface, such as a full page, with its contents changing inside it. Both serve **spatial continuity**: they tell the user that the new view is not a new place but a closer look at the thing they chose. This question is about the design decisions. How to animate the layout change without jank (measuring the start and end positions and animating between them cheaply) belongs to the web performance subject. ## Designing the card-to-course transition 1. **Decide what is shared.** Only elements that are the same object in both views: the course image and the course title are good candidates. A "save" icon on the card and a large enrol button on the page are not the same element, even if they sit in a similar place. 2. **Grow the container.** The card's outline expands to the detail view's bounds. This is what carries the relationship: the page *is* the card, opened up. 3. **Crossfade the contents.** Inside the growing container, the card's layout fades out while the page's layout fades in. Elements unique to one view (the card's rating row, the page's syllabus) fade rather than travel. 4. **Plan the image crop.** A thumbnail is often square or wide; the page header may be much wider. Letting the image stretch between aspect ratios distorts it. Design the transition as a change of crop or mask on an image that keeps its proportions. 5. **Keep the rest of the catalogue quiet.** The surrounding cards should fade or recede, not animate independently, so the eye stays on the card that is opening. 6. **Reverse on back.** Returning collapses the page into the same card, at the same place in the same scroll position. A back transition that lands on a different position breaks the promise the forward transition made. ## When the transition cannot keep its promise | Situation | Why it fails | Better choice | |---|---|---| | Learner opened the course from a deep link or notification | There is no card to grow from | The standard navigation transition | | On return, the card has been filtered out or scrolled away | The reverse path has no destination | Standard back transition, then restore scroll | | "Related course" link on a detail page | The target is a different object, so continuity would lie | A forward navigation transition | | Detail page's shared parts load late | The morph stalls on an empty frame | Show shared parts from data already held by the card, or skip the morph | | Many elements marked as shared | Several things fly at once and none reads as "the" object | Share one or two elements, fade the rest | The common thread: **a shared-element transition is a claim that the same object persists**. Use it only when the claim is true and both ends are on screen to prove it. ## How this differs from ordinary navigation motion - Ordinary forward navigation (a push or slide) says "you moved to a new place, one level deeper". - A container transition says "you are looking more closely at the thing you chose". Both are legitimate; they express different relationships. A system usually offers both and says when each applies, rather than letting each team pick whichever looks better. ## Across platforms Web and native mobile both have ways to animate an element between two screens, and the design decisions above are the same on each: what is shared, how the container grows, what fades, how back reverses, and what happens when one end is missing. A design system describes the transition in those terms so each platform implements the same choreography. ## Common mistakes - Marking elements as shared because they look similar, not because they are the same object. - Stretching an image between different aspect ratios instead of designing the crop. - A forward transition with a fancy morph and a back transition that simply cuts, so the relationship is only half told. - Forcing the morph when the source card is missing, which produces an element flying in from nowhere. - Letting every card in the grid respond at once, so the learner loses track of the one they tapped.