Før karrieren begynte å utvikle seg, gjorde jeg en haug med bevegelsesgrafikk i After Effects. Men selv med den bakgrunnen syntes jeg fortsatt animasjon på nettet var ganske forvirrende.
Videografikk utformes innenfor et spesifikt forhold og eksporteres deretter ut. Ferdig! Men det er ingen "eksportinnstillinger" på nettet. Vi presser bare koden ut i verden, og animasjonene våre må tilpasse seg hvilken enhet de lander på.
Så la oss snakke responsiv animasjon! Hvordan nærmer vi oss best animasjon på det ville ville nettet? Vi skal dekke noen generelle tilnærminger, noen GSAP-spesifikke tips og noen bevegelsesprinsipper. La oss starte med litt innramming...
Hvordan vil denne animasjonen bli brukt?
Zach Sauciers artikkel om responsiv animasjon anbefaler å ta et skritt tilbake for å tenke på det endelige resultatet før du hopper inn i koden.
Vil animasjonen være en modul som gjentas over flere deler av applikasjonen din? Trenger den i det hele tatt skaleres? Å ha dette i bakhodet kan bidra til å bestemme metoden som en animasjon skal skaleres på, og forhindre at du kaster bort innsats.
Dette er et godt råd. EN stort en del av å designe responsiv animasjon er å vite om og hvordan den animasjonen må skaleres, og deretter velge riktig tilnærming fra starten av.
De fleste animasjoner faller inn i følgende kategorier:
- fast: Animasjoner for ting som ikoner eller lastere som beholder samme størrelse og sideforhold på alle enheter. Ingenting å bekymre seg for her! Hardkode noen pikselverdier der og fortsett med dagen.
- Væske: Animasjoner som må tilpasses flytende på tvers av forskjellige enheter. De fleste layout-animasjoner faller inn i denne kategorien.
- Målrettet: Animasjoner som er spesifikke for en bestemt enhet eller skjermstørrelse, eller endres vesentlig ved et bestemt bruddpunkt, for eksempel animasjoner som kun er på skrivebordet eller interaksjoner som er avhengige av enhetsspesifikk interaksjon, som berøring eller sveving.
Flytende og målrettede animasjoner krever ulike måter å tenke på og løsninger. La oss ta en titt…
Flytende animasjon
As Andy Bell sier: Vær nettleserens mentor, ikke mikromanageren – gi nettleseren noen solide regler og hint, og la den deretter ta de riktige avgjørelsene for folk som besøker den.
(Her er lysbildene fra den presentasjonen.)
Flytende animasjon handler om å la nettleseren gjøre det harde arbeidet. Mange animasjoner kan enkelt tilpasses ulike kontekster bare ved å bruke de riktige enhetene fra starten av. Hvis du endrer størrelsen på denne pennen kan du se at animasjonen bruker viewport-enheter skaleres flytende når nettleseren justerer:
Den lilla boksen endrer til og med bredde ved forskjellige bruddpunkter, men ettersom vi bruker prosenter for å flytte den, skalerer animasjonen sammen med den.
Animerende layoutegenskaper som left og top kan føre til reflow av layout og nervøs 'janky' animasjon, så hold deg til transformasjoner og opasitet der det er mulig.
Vi er imidlertid ikke bare begrenset til disse enhetene – la oss ta en titt på noen andre muligheter.
SVG-enheter
En av tingene jeg elsker med å jobbe med SVG er at vi kan bruke SVG-brukerenheter for animasjon som er responsive ut av boksen. Ledetråden ligger i navnet egentlig - Skalerbar Vektorgrafikk. I SVG-land er alle elementer plottet på bestemte koordinater. SVG-plass er som en uendelig bit av millimeterpapir der vi kan ordne elementer. De viewBox definerer dimensjonene til millimeterpapiret vi kan se.
viewBox="0 0 100 50”I denne neste demoen vår SVG viewBox is 100 enheter bred og 50 enheter høy. Dette betyr at hvis vi animerer elementet ved 100 enheter langs x-aksen, vil den alltid bevege seg i hele bredden av sin overordnede SVG, uansett hvor stor eller liten SVG er! Gi demoen en endre størrelse for å se.
Å animere et underordnet element basert på bredden til en overordnet beholder er et lite trick i HTML-land. Frem til nå har vi måttet ta tak i foreldrenes bredde med JavaScript, noe som er enkelt nok når du animerer from en forvandlet posisjon, men litt mer uklar når du animerer to et sted som du kan se i følgende demo. Hvis endepunktet ditt er en transformert posisjon og du endrer størrelsen på skjermen, må du justere denne posisjonen manuelt. Rotete... 🤔
Hvis du justerer verdier ved å endre størrelse, husk det avvise, eller til og med utløs funksjonen etter at nettleseren er ferdig med å endre størrelsen. Endre størrelse på lyttere avfyrer massevis av hendelser hvert sekund, så det er mye arbeid for nettleseren å oppdatere egenskaper for hver hendelse.
Men denne animasjonsfartshumpen er snart en saga blott! Trommerull takk... 🥁
Containerenheter! Nydelige greier. På det tidspunktet jeg skriver dette, fungerer de bare i Chrome og Safari – men kanskje når du leser dette, har vi Firefox også. Sjekk dem i aksjon i denne neste demoen. Se på de små guttene går! Er ikke det spennende, animasjon som er i forhold til foreldreelementene!
Denne nettleserens støttedata er fra Kan jeg bruke, som har flere detaljer. Et tall indikerer at nettleseren støtter funksjonen i den versjonen og oppover.
desktop
| Chrome | Firefox | IE | Edge | Safari |
|---|---|---|---|---|
| 105 | Nei | Nei | 105 | 16.0 |
Mobil / nettbrett
| Android Chrome | Android Firefox | Android | iOS Safari |
|---|---|---|---|
| 106 | Nei | 106 | 16.0 |
Flytende layoutoverganger med FLIP
Som vi nevnte tidligere, i SVG-land er hvert element pent plassert på ett rutenett og veldig enkelt å flytte rundt på responsiv måte. Over i HTML-land er det mye mer komplekst. For å bygge responsive layouter bruker vi en haug med ulike posisjoneringsmetoder og layoutsystemer. En av de største vanskelighetene med å animere på nettet er det mye av endringer i layout er umulig å animere. Kanskje et element må flyttes fra posisjon relative til fixed, eller noen barn av en flex-beholder må stokkes jevnt rundt i visningsporten. Kanskje et element til og med må endres og flyttes til en helt ny posisjon i DOM.
Vanskelig, ikke sant?
Vi vil. FLIP-teknikken er her for å redde dagen; det lar oss enkelt animere disse umulige tingene. Den grunnleggende forutsetningen er:
- Først: Ta tak i startposisjonen til elementene som er involvert i overgangen.
- Siste: Flytt elementene og ta den endelige posisjonen.
- Inverter: Regn ut endringene mellom første og siste tilstand og bruk transformasjoner for å invertere elementene tilbake til deres opprinnelige posisjon. Dette gjør at det ser ut som om elementene fortsatt er i først posisjon, men det er de faktisk ikke.
- Spille: Fjern de inverterte transformasjonene og animer til deres forfalsket først stat til siste tilstand.
Her er en demo som bruker GSAPs FLIP-plugin som gjør alt det tunge løftet for deg!
Hvis du vil forstå litt mer om vaniljeimplementeringen, kan du gå til Paul Lewis blogginnlegg — han er hjernen bak FLIP-teknikken.
Flytende skalering av SVG
Du har meg... dette er ikke virkelig et animasjonstips. Men å sette scenen riktig er avgjørende for god animasjon! SVG skalerer superpent som standard, men vi kan kontrollere hvordan det skaleres enda lenger med preserveAspectRatio, noe som er veldig nyttig når SVG-elementets sideforhold og viewBox sideforhold er forskjellige. Det fungerer mye på samme måte som background-position og background-size eiendommer i CSS. Erklæringen består av en justeringsverdi (background-position) Og en Møt or Slice henvisning (background-size).
Når det gjelder de Meet and Slice-referansene – slice er som background size: coverog meet er som background-size: contain.
preserveAspectRatio="MidYMax slice"— Juster til midten av x-aksen, bunnen av y-aksen, og skaler opp for å dekke hele visningsporten.preserveAspectRatio="MinYMin meet"– Juster til venstre for x-aksen, toppen av y-aksen, og skaler opp mens du beholder heleviewBoxsynlig.
Tom Miller tar dette et skritt videre ved å bruke overflow: visible i CSS og et inneholdende element for å avsløre "stage left" og "stage right" mens du holder høyden begrenset:
For responsive SVG-animasjoner kan det være nyttig å bruke SVG-visningsboksen for å lage en visning som beskjærer og skalerer under en viss nettleserbredde, samtidig som den avslører mer av SVG-animasjonen til høyre og venstre når nettleseren er bredere enn det. terskel. Vi kan oppnå dette ved å legge til overflow synlig på SVG og slå det sammen med en
max-heightinnpakning for å forhindre at SVG skalerer for mye vertikalt.
Flytende skalering lerret
Canvas er mye mer effektiv for komplekse animasjoner med masse av bevegelige deler enn å animere SVG eller HTML DOM, men det er iboende mer komplekst også. Du må jobbe for disse ytelsesgevinstene! I motsetning til SVG som har nydelige responsive enheter og skalering ut av esken, må sjefes rundt og mikrostyres litt.
Jeg liker å sette opp min slik at det fungerer mye på samme måte som SVG (jeg kan være partisk) med et nydelig enhetssystem å jobbe innenfor og et fast sideforhold. må også tegnes på nytt hver gang noe endres, så husk å utsette omtegningen til nettleseren er ferdig med å endre størrelsen, eller debounce!
George Francis sette sammen dette også nydelig lite bibliotek som lar deg definere et lerret viewBox attributt og preserveAspectRatio – akkurat som SVG!
Målrettet animasjon
Noen ganger må du kanskje ta en mindre flytende og mer rettet tilnærming til animasjonen. Mobile enheter har mye mindre eiendom, og mindre animasjonsjuice-messig ytelsesmessig enn en stasjonær maskin. Så det er fornuftig å vise redusert animasjon til mobilbrukere, potensielt til og med ingen animasjon:
Noen ganger er den beste responsive animasjonen for mobil ingen animasjon i det hele tatt! For mobil UX, prioriter å la brukeren raskt konsumere innhold i stedet for å vente på at animasjonene skal fullføres. Mobile animasjoner bør forbedre innhold, navigasjon og interaksjoner i stedet for å forsinke det. Eric van Holtz
For å gjøre dette kan vi bruke mediespørringer for å målrette spesifikke visningsportstørrelser akkurat som vi gjør når vi styler med CSS! Her er en enkel demo som viser en CSS-animasjon som håndteres ved hjelp av mediespørringer og en GSAP-animasjon som håndteres med gsap.matchMedia():
Enkelheten i denne demoen skjuler en haug med magi! JavaScript-animasjoner krever litt mer oppsett og opprydding for å fungere riktig på bare én bestemt skjermstørrelse. Jeg har sett grusomheter i det siste hvor folk nettopp har skjult animasjonen fra visning i CSS med opacity: 0, men animasjonen tømmer fortsatt i bakgrunnen og bruker opp ressurser. 😱
Hvis skjermstørrelsen ikke stemmer overens lenger, må animasjonen drepes og frigis for søppelinnsamling, og elementene som påvirkes av animasjonen må fjernes for bevegelsesintroduserte stiler for å forhindre konflikter med annen stil. Opp til gsap.matchMedia(), dette var en vanskelig prosess. Vi måtte holde styr på hver animasjon og administrere alt dette manuelt.
gsap.matchMedia() lar deg i stedet enkelt legge animasjonskoden inn i en funksjon som bare kjøres når en bestemt media spørring fyrstikker. Så, når det ikke lenger stemmer, vil alle GSAP-animasjonene og ScrollTriggers i den funksjonen blir tilbakestilt automatisk. Mediesøket som animasjonene vises i, gjør alt det harde arbeidet for deg. Det er i GSAP 3.11.0, og det er en game changer!
Vi er ikke bare begrenset til skjermstørrelser heller. Det finnes en massevis av mediefunksjoner der ute å hekte seg på!
(prefers-reduced-motion) /* find out if the user would prefer less animation */
(orientation: portrait) /* check the user's device orientation */
(max-resolution: 300dpi) /* check the pixel density of the device */I den følgende demoen har vi lagt til en sjekk for prefers-reduced-motion slik at brukere som synes animasjon er desorienterende, ikke blir plaget av ting som suser rundt.
Og sjekk ut Tom Millers andre morsomme demo der han bruker enhetens sideforhold for å justere animasjonen:
Tenker utenfor boksen, utover skjermstørrelser
Det er mer å tenke på responsiv animasjon enn bare skjermstørrelser. Ulike enheter gir mulighet for ulike interaksjoner, og det er lett å havne i en floke når du ikke tenker på det. Hvis du oppretter hover states i CSS, kan du bruke hover mediefunksjon for å teste om brukerens primære inngangsmekanisme kan holde musepekeren over elementer.
@media (hover: hover) {
/* CSS hover state here */
}Noen råd fra Jake Whiteley:
Mye av tiden baserer vi animasjonene våre på nettleserbredde, noe som gjør den naive antagelsen at stasjonære brukere vil ha svevetilstander. Jeg har personlig hatt mange problemer tidligere der jeg ville bytte til skrivebordsoppsett >1024px, men kan gjøre berøringsdeteksjon i JS – noe som fører til et misforhold der oppsettet var for stasjonære datamaskiner, men JS var for mobiler. I disse dager lener jeg meg på hover og peker for å sikre paritet og håndtere ipad Pros eller Windows-overflater (som kan endre pekertypen avhengig av om dekselet er nede eller ikke)
/* any touch device: */
(hover: none) and (pointer: coarse)
/* iPad Pro */
(hover: none) and (pointer: coarse) and (min-width: 1024px)Jeg vil deretter slå sammen CSS-layoutforespørslene mine og JavaScript-spørringene mine, så jeg vurderer inndataenheten som den primære faktoren støttes etter bredde, i stedet for det motsatte.
ScrollTrigger-tips
Hvis du bruker GSAP ScrollTrigger-plugin, det er et praktisk lite verktøy du kan koble til for enkelt å se berøringsfunksjonene til enheten: ScrollTrigger.isTouch.
0- ikke rør (bare peker/mus)1- kun berøring enhet (som en telefon)2– enheten kan godta berøre innspill og mus/peker (som Windows-nettbrett)
if (ScrollTrigger.isTouch) {
// any touch-capable device...
}
// or get more specific:
if (ScrollTrigger.isTouch === 1) {
// touch-only device
}Et annet tips for responsiv rulleutløst animasjon...
Følgende demo nedenfor flytter et bildegalleri horisontalt, men bredden endres avhengig av skjermstørrelsen. Hvis du endrer størrelsen på skjermen når du er halvveis i en skrubbet animasjon, kan du ende opp med ødelagte animasjoner og foreldede verdier. Dette er en vanlig fartsdump, men en som er lett å løse! Sett beregningen som er avhengig av skjermstørrelsen inn i en funksjonell verdi og sett invalidateOnRefresh:true. På den måten vil ScrollTrigger beregne verdien på nytt for deg når nettleseren endrer størrelse.
Bonus GSAP nerdetips!
På mobile enheter vises og skjules adresselinjen i nettleseren vanligvis mens du blar. Dette teller som en endringshendelse og vil avfyre en ScrollTrigger.refresh(). Dette er kanskje ikke ideelt, da det kan føre til hopp i animasjonen din. GSAP 3.10 lagt til ignoreMobileResize. Det påvirker ikke hvordan nettleserlinjen oppfører seg, men det forhindrer ScrollTrigger.refresh() fra å skyte for små vertikale endringer på berøringsenheter.
ScrollTrigger.config({
ignoreMobileResize: true
});Bevegelsesprinsipper
Jeg tenkte jeg skulle gi deg noen beste fremgangsmåter du bør vurdere når du arbeider med bevegelse på nettet.
Avstand og lettelser
En liten, men viktig ting som er lett å glemme med responsiv animasjon er forholdet mellom hastighet, momentum og avstand! God animasjon bør etterligne den virkelige verden å føle seg troverdig, og det tar lengre tid i den virkelige verden å tilbakelegge en større avstand. Vær oppmerksom på avstanden animasjonen din reiser, og sørg for at varigheten og lettelsen som brukes gir mening i sammenheng med andre animasjoner.
Du kan også ofte bruke mer dramatiske lettelser på elementer med lengre reise for å vise økt momentum:
For visse brukstilfeller kan det være nyttig å justere varigheten mer dynamisk basert på skjermbredden. I denne neste demoen vi bruker gsap.utils for å klemme verdien vi får tilbake fra strømmen window.innerWidth inn i et rimelig område, så tilordner vi det tallet til en varighet.
Avstand og mengde
En annen ting å huske på er avstanden og mengden av elementer ved forskjellige skjermstørrelser. Siterer Steven Shaw:
Hvis du har en slags miljøanimasjon (parallakse, skyer, trær, konfetti, dekorasjoner osv.) som er plassert rundt vinduet, sørg for at de skalerer og/eller justerer mengden avhengig av skjermstørrelsen. Store skjermer trenger nok flere elementer spredt utover, mens små skjermer bare trenger noen få for samme effekt.
Jeg elsker hvordan Opher Vishnia tenker på animasjon som en scene. Å legge til og fjerne elementer trenger ikke bare være en formalitet, det kan være en del av den overordnede koreografien.
Når du designer responsive animasjoner, er ikke utfordringen hvordan man kan stappe det samme innholdet inn i visningsporten slik at det "passer", men heller hvordan man kuraterer settet med eksisterende innhold slik at det kommuniserer den samme intensjonen. Det betyr å ta et bevisst valg av hvilke deler som skal legges til, og hvilke som skal fjernes. Vanligvis i animasjonsverdenen dukker ikke ting bare inn eller ut av rammen. Det er fornuftig å tenke på elementer som å gå inn eller ut av "scenen", og animere denne overgangen på en måte som gir visuell og tematisk mening.
Og det er mye. Hvis du har flere responsive animasjonstips, kan du legge dem inn i kommentarfeltet. Hvis det er noe veldig nyttig, legger jeg det til i dette kompendiet med informasjon!
Tillegg
En annen merknad fra Tom Miller mens jeg forberedte denne artikkelen:
Jeg er sannsynligvis for sent ute med dette tipset for den responsive animasjonsartikkelen din, men jeg anbefaler på det sterkeste "avslutt alle animasjonene før du bygger". Jeg holder for øyeblikket på å ettermontere noen nettstedanimasjoner med "mobilversjoner". Takk og lov for
gsap.matchMedia... men jeg skulle ønske vi hadde visst at det ville være separate mobile layouter/animasjoner fra begynnelsen.
Jeg tror vi alle setter pris på at dette tipset om å "planlegge fremover" kom i siste liten. Takk, Tom, og lykke til med disse ettermonteringene.
