Før min karriere sprang ind i udvikling, lavede jeg en masse motion graphics-arbejde i After Effects. Men selv med den baggrund fandt jeg stadig animation på nettet ret forvirrende.
Videografik er designet inden for et bestemt forhold og eksporteres derefter ud. Færdig! Men der er ingen "eksportindstillinger" på nettet. Vi skubber bare koden ud i verden, og vores animationer skal tilpasse sig den enhed, de lander på.
Så lad os tale responsiv animation! Hvordan griber vi bedst an animation på det vilde vilde web? Vi kommer til at dække nogle generelle tilgange, nogle GSAP-specifikke tips og nogle bevægelsesprincipper. Lad os starte med nogle rammer...
Hvordan vil denne animation blive brugt?
Zach Sauciers artikel om responsiv animation anbefaler at tage et skridt tilbage for at tænke over det endelige resultat, før du hopper i kode.
Vil animationen være et modul, der gentages på tværs af flere dele af din applikation? Skal det overhovedet skaleres? At holde dette i tankerne kan hjælpe med at bestemme metoden, hvor en animation skal skaleres, og forhindre dig i at spilde kræfter.
Dette er et godt råd. EN kæmpe en del af design af responsiv animation er at vide, om og hvordan den animation skal skaleres, og derefter vælge den rigtige tilgang fra starten.
De fleste animationer falder i følgende kategorier:
- Fast: Animationer til ting som ikoner eller indlæsere, der bevarer samme størrelse og billedformat på tværs af alle enheder. Intet at bekymre sig om her! Indtast nogle pixelværdier hårdt derinde, og kom videre med din dag.
- Væske: Animationer, der skal tilpasses flydende på tværs af forskellige enheder. De fleste layout-animationer falder ind under denne kategori.
- Målrettet: Animationer, der er specifikke for en bestemt enhed eller skærmstørrelse, eller ændrer sig væsentligt ved et bestemt brudpunkt, f.eks. animationer, der kun er på skrivebordet, eller interaktioner, der er afhængige af enhedsspecifik interaktion, såsom berøring eller svæv.
Flydende og målrettede animationer kræver forskellige måder at tænke på og løsninger. Lad os se…
Flydende animation
As Andy bell siger: Vær browserens mentor, ikke dens mikromanager – giv browseren nogle solide regler og hints, og lad den derefter træffe de rigtige beslutninger for de mennesker, der besøger den.
(Her er rutsjebanerne fra den præsentation.)
Flydende animation handler om at lade browseren gøre det hårde arbejde. En masse animationer kan nemt tilpasses forskellige sammenhænge blot ved at bruge de rigtige enheder fra starten. Hvis du ændrer størrelsen på denne pen, kan du se, at animationen vha viewport enheder skaleres flydende efterhånden som browseren justerer:
Den lilla boks ændrer endda bredde ved forskellige brudpunkter, men da vi bruger procenter til at flytte den, skalerer animationen også sammen med den.
Animerende layoutegenskaber som left , top kan forårsage layout reflows og nervøs 'janky' animation, så hvor det er muligt, hold dig til transformationer og opacitet.
Vi er dog ikke kun begrænset til disse enheder - lad os tage et kig på nogle andre muligheder.
SVG enheder
En af de ting, jeg elsker ved at arbejde med SVG, er, at vi kan bruge SVG-brugerenheder til animation, som er responsive ud af boksen. Ledetråden ligger i navnet virkelig - Skalerbar Vektor grafik. I SVG-land er alle elementer plottet på bestemte koordinater. SVG-plads er som en uendelig smule millimeterpapir, hvor vi kan arrangere elementer. Det viewBox definerer dimensionerne af det millimeterpapir, vi kan se.
viewBox="0 0 100 50”I denne næste demo, vores SVG viewBox is 100 enheder bred og 50 enheder høj. Det betyder, at hvis vi animerer elementet ved 100 enheder langs x-aksen, vil den altid bevæge sig i hele bredden af sin moder-SVG, uanset hvor stor eller lille den SVG er! Giv demoen en ændring af størrelsen for at se.
At animere et underordnet element baseret på en overordnet containers bredde er et lille trick i HTML-land. Indtil nu har vi været nødt til at gribe forældrenes bredde med JavaScript, hvilket er nemt nok, når du animerer from en forvandlet position, men lidt mere besværlig, når du animerer to et sted, som du kan se i følgende demo. Hvis dit slutpunkt er en transformeret position, og du ændrer størrelsen på skærmen, bliver du nødt til at justere denne position manuelt. Rodet... 🤔
Hvis du justerer værdier ved ændring af størrelse, skal du huske det debounce, eller endda tænde funktionen, når browseren er færdig med at ændre størrelsen. Ændre størrelse lyttere affyrer et væld af begivenheder hvert sekund, så det er meget arbejde for browseren at opdatere egenskaber for hver begivenhed.
Men denne animationshastighedsbump hører snart fortiden til! Trommerulle tak... 🥁
Containerenheder! Dejlige ting. På det tidspunkt, jeg skriver dette, virker de kun i Chrome og Safari - men måske når du læser dette, har vi også Firefox. Se dem i aktion i denne næste demo. Se på de små drenge går! Er det ikke spændende, animation, der er i forhold til forældreelementerne!
Denne browserunderstøttelsesdata er fra Kan jeg bruge, som har flere detaljer. Et tal angiver, at browseren understøtter funktionen fra den pågældende version og opefter.
desktop
| Chrome | Firefox | IE | Edge | Safari |
|---|---|---|---|---|
| 105 | Ingen | Ingen | 105 | 16.0 |
Mobil / tablet
| Android Chrome | Android Firefox | Android | iOS Safari |
|---|---|---|---|
| 106 | Ingen | 106 | 16.0 |
Flydende layoutovergange med FLIP
Som vi nævnte tidligere, er hvert element i SVG-land pænt placeret på ét gitter og virkelig nemt at flytte rundt på responsiv måde. I HTML-land er det meget mere komplekst. For at bygge responsive layouts gør vi brug af en masse forskellige positioneringsmetoder og layoutsystemer. En af de største vanskeligheder ved at animere på nettet er det en masse ændringer i layout er umulige at animere. Måske skal et element flyttes fra position relative til fixed, eller nogle børn af en flex-beholder skal blandes jævnt rundt i viewporten. Måske skal et element endda genforældres og flyttes til en helt ny position i DOM.
Vanskeligt, hva'?
Godt. FLIP-teknikken er her for at redde dagen; det giver os mulighed for nemt at animere disse umulige ting. Den grundlæggende forudsætning er:
- Fornavn: Tag fat i startpositionen for de elementer, der er involveret i overgangen.
- Efternavn: Flyt elementerne og tag den endelige position.
- Inverter: Udregn ændringerne mellem den første og sidste tilstand, og anvend transformationer for at invertere elementerne tilbage til deres oprindelige position. Dette får det til at se ud som om elementerne stadig er i første position, men det er de faktisk ikke.
- Leg: Fjern de omvendte transformationer og animer til deres fingerede første stat til sidste tilstand.
Her er en demo, der bruger GSAPs FLIP-plugin, som gør alt det tunge løft for dig!
Hvis du vil forstå lidt mere om vaniljeimplementeringen, så gå over til Paul Lewis's blogindlæg — han er hjernen bag FLIP-teknikken.
Flydende skalering af SVG
Du fik mig... det er det ikke virkelig et animationstip. Men at sætte scenen korrekt er afgørende for god animation! SVG skalerer super flot som standard, men vi kan styre, hvordan det skalerer endnu længere med preserveAspectRatio, hvilket er mega praktisk, når SVG-elementets billedformat og den viewBox aspektforhold er forskellige. Det fungerer meget på samme måde som background-position , background-size ejendomme i CSS. Erklæringen består af en justeringsværdi (background-position) Og en Mød or Slice reference (background-size).
Med hensyn til disse Meet and Slice-referencer - slice er ligesom background size: coverog meet er ligesom background-size: contain.
preserveAspectRatio="MidYMax slice"— Juster til midten af x-aksen, bunden af y-aksen, og skaler op for at dække hele visningsporten.preserveAspectRatio="MinYMin meet"— Juster til venstre for x-aksen, toppen af y-aksen, og skaler op, mens heleviewBoxsynlig.
Tom Miller tager dette et skridt videre ved at bruge overflow: visible i CSS og et indeholdende element for at afsløre "stage left" og "stage right", mens højden holdes begrænset:
For responsive SVG-animationer kan det være praktisk at bruge SVG-visningsboksen til at skabe en visning, der beskærer og skalerer under en bestemt browserbredde, og samtidig afslører mere af SVG-animationen til højre og venstre, når browseren er bredere end det. Grænseværdi. Vi kan opnå dette ved at tilføje overløb synligt på SVG og slå det sammen med en
max-heightindpakning for at forhindre SVG i at skalere for meget lodret.
Flydende skalering lærred
Canvas er meget mere effektiv til komplekse animationer med masser af bevægelige dele end at animere SVG eller HTML DOM, men det er i sagens natur også mere komplekst. Du skal arbejde for disse præstationsgevinster! I modsætning til SVG, der har dejlige responsive enheder og skalering ud af boksen, skal bosses rundt og mikrostyres lidt.
Jeg kan godt lide at sætte min op så det fungerer meget på samme måde som SVG (jeg kan være forudindtaget) med et dejligt enhedssystem at arbejde indenfor og et fast billedformat. skal også tegnes om hver gang noget ændrer sig, så husk at udskyde gentegningen indtil browseren er færdig med at ændre størrelsen, eller debounce!
George Francis også sammensætte dette dejligt lille bibliotek som giver dig mulighed for at definere et lærred viewBox egenskab og preserveAspectRatio - præcis som SVG!
Målrettet animation
Du kan nogle gange have brug for en mindre flydende og mere målrettet tilgang til din animation. Mobile enheder har meget mindre fast ejendom og mindre animationsjuice-mæssigt end en stationær maskine. Så det giver mening at vise reduceret animation til mobilbrugere, potentielt endda ingen animation:
Nogle gange er den bedste responsive animation til mobil slet ingen animation! For mobil UX skal du prioritere at lade brugeren hurtigt forbruge indhold frem for at vente på, at animationer er færdige. Mobile animationer bør forbedre indhold, navigation og interaktioner i stedet for at forsinke det. Eric van Holtz
For at gøre dette kan vi gøre brug af medieforespørgsler til at målrette mod specifikke viewport-størrelser, ligesom vi gør, når vi styler med CSS! Her er en simpel demo, der viser en CSS-animation, der håndteres ved hjælp af medieforespørgsler, og en GSAP-animation, der håndteres med gsap.matchMedia():
Enkelheden af denne demo skjuler en masse magi! JavaScript-animationer kræver lidt mere opsætning og oprydning for at fungere korrekt ved kun én bestemt skærmstørrelse. Jeg har tidligere set rædsler, hvor folk lige har skjult animationen fra visning i CSS med opacity: 0, men animationen tøffer stadig væk i baggrunden og bruger ressourcer. 😱
Hvis skærmstørrelsen ikke stemmer overens længere, skal animationen aflives og frigives til affaldsindsamling, og de elementer, der påvirkes af animationen, skal ryddes for alle bevægelses-introducerede inline-stile for at forhindre konflikter med anden stil. Indtil gsap.matchMedia(), dette var en besværlig proces. Vi skulle holde styr på hver animation og styre alt dette manuelt.
gsap.matchMedia() lader dig i stedet nemt gemme din animationskode ind i en funktion, der kun udføres, når en bestemt medier forespørgsel Tændstikker. Så, når det ikke længere matcher, vil alle GSAP-animationerne og ScrollTriggers i den funktion vendes automatisk tilbage. Medieforespørgslen, som animationerne er poppet ind i, gør alt det hårde arbejde for dig. Det er i GSAP 3.11.0, og det er en game changer!
Vi er heller ikke kun begrænset til skærmstørrelser. Der er en ton af mediefunktioner derude at koble sig 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 demo har vi tilføjet en check for prefers-reduced-motion så brugere, der finder animation desorienterende, ikke bliver generet af ting, der suser rundt.
Og tjek Tom Millers anden sjove demo, hvor han bruger enhedens billedformat til at justere animationen:
Tænker ud af boksen, ud over skærmstørrelser
Der er mere at tænke på responsiv animation end blot skærmstørrelser. Forskellige enheder giver mulighed for forskellige interaktioner, og det er nemt at komme i et virvar, når man ikke tænker på det. Hvis du opretter hover-tilstande i CSS, kan du bruge hover mediefunktion for at teste, om brugerens primære inputmekanisme kan svæve over elementer.
@media (hover: hover) {
/* CSS hover state here */
}Nogle råd fra Jake Whiteley:
Meget af tiden baserer vi vores animationer på browserbredde, hvilket gør den naive antagelse, at desktopbrugere vil have svævetilstande. Jeg har personligt haft mange problemer i fortiden, hvor jeg ville skifte til desktop-layout >1024px, men måske lave berøringsdetektion i JS – hvilket førte til et misforhold, hvor layoutet var til desktops, men JS var til mobiler. I disse dage læner jeg mig op af hover og pointer for at sikre paritet og håndtere ipad Pros eller windows overflader (som kan ændre pointertypen afhængigt af om coveret er nede eller ej)
/* any touch device: */
(hover: none) and (pointer: coarse)
/* iPad Pro */
(hover: none) and (pointer: coarse) and (min-width: 1024px)Jeg vil derefter samle mine CSS-layoutforespørgsler og mine JavaScript-forespørgsler, så jeg betragter inputenheden som den primære faktor understøttes i bredden i stedet for det modsatte.
ScrollTrigger tips
Hvis du bruger GSAP'er ScrollTrigger plugin, der er et praktisk lille værktøj, du kan tilslutte for nemt at skelne enhedens berøringsfunktioner: ScrollTrigger.isTouch.
0- ingen berøring (kun markør/mus)1- kun berøring enhed (som en telefon)2– enheden kan acceptere input og mus/markør (som Windows-tablets)
if (ScrollTrigger.isTouch) {
// any touch-capable device...
}
// or get more specific:
if (ScrollTrigger.isTouch === 1) {
// touch-only device
}Endnu et tip til responsiv scroll-udløst animation...
Følgende demo nedenfor flytter et billedgalleri vandret, men bredden ændres afhængigt af skærmstørrelsen. Hvis du ændrer størrelsen på skærmen, når du er halvvejs gennem en skrubbet animation, kan du ende med ødelagte animationer og forældede værdier. Dette er et almindeligt fartbump, men et der er let at løse! Indsæt beregningen, der er afhængig af skærmstørrelsen, i en funktionel værdi og sæt den invalidateOnRefresh:true. På den måde vil ScrollTrigger genberegne denne værdi for dig, når browserens størrelse ændres.
Bonus GSAP nørd tip!
På mobile enheder vises og skjules browserens adresselinje normalt, mens du ruller. Dette tæller som en hændelse til at ændre størrelse og vil udløse en ScrollTrigger.refresh(). Dette er måske ikke ideelt, da det kan forårsage spring i din animation. GSAP 3.10 tilføjet ignoreMobileResize. Det påvirker ikke, hvordan browserbjælken opfører sig, men det forhindrer ScrollTrigger.refresh() fra at fyre for små lodrette størrelser på enheder, der kun kan berøres.
ScrollTrigger.config({
ignoreMobileResize: true
});Bevægelsesprincipper
Jeg tænkte, at jeg ville give dig nogle bedste fremgangsmåder, du skal overveje, når du arbejder med bevægelse på nettet.
Afstand og lempelse
En lille, men vigtig ting, der er let at glemme med responsiv animation, er forholdet mellem hastighed, momentum og distance! God animation skal efterligne den virkelige verden at føle sig troværdig, og det tager længere tid i den virkelige verden at tilbagelægge en større afstand. Vær opmærksom på afstanden, din animation rejser, og sørg for, at den anvendte varighed og lempelse giver mening i sammenhæng med andre animationer.
Du kan også ofte anvende mere dramatiske lempelser på elementer med længere rejse for at vise det øgede momentum:
I visse tilfælde kan det være nyttigt at justere varigheden mere dynamisk baseret på skærmens bredde. I denne næste demo gør vi brug af gsap.utils for at klemme den værdi, vi får tilbage fra strømmen window.innerWidth inden for et rimeligt interval, så kortlægger vi det tal til en varighed.
Afstand og mængde
En anden ting at huske på er afstanden og mængden af elementer ved forskellige skærmstørrelser. Citerer Steven Shaw:
Hvis du har en form for miljøanimation (parallakse, skyer, træer, konfetti, dekorationer osv.), der er placeret rundt om vinduet, skal du sørge for, at de skalerer og/eller justerer mængden afhængigt af skærmstørrelsen. Store skærme har formentlig brug for flere elementer spredt ud over, mens små skærme kun har brug for få for samme effekt.
Jeg elsker hvordan Opher Vishnia tænker på animation som en scene. Tilføjelse og fjernelse af elementer behøver ikke kun at være en formalitet, det kan være en del af den overordnede koreografi.
Når man designer responsive animationer, er udfordringen ikke, hvordan man propper det samme indhold ind i viewporten, så det "passer", men snarere, hvordan man kuraterer sættet af eksisterende indhold, så det kommunikerer den samme hensigt. Det betyder, at man træffer et bevidst valg af, hvilket indhold der skal tilføjes, og hvilket der skal fjernes. Normalt i animationsverdenen popper ting ikke bare ind eller ud af rammen. Det giver mening at tænke på elementer som at gå ind eller ud af "scenen" og animere denne overgang på en måde, der giver visuel og tematisk mening.
Og det er partiet. Hvis du har flere responsive animationstip, så pop dem i kommentarfeltet. Hvis der er noget super nyttigt, vil jeg tilføje dem til dette kompendium af information!
Tillæg
Endnu en bemærkning fra Tom Miller da jeg forberedte denne artikel:
Jeg er nok for sent med dette tip til din responsive animationsartikel, men jeg anbefaler stærkt "afslut alle animationerne før du bygger". Jeg er i øjeblikket ved at eftermontere nogle webstedsanimationer med "mobilversioner". Gudskelov for
gsap.matchMedia… men jeg ville bestemt ønske, at vi havde vidst, at der ville være separate mobile layouts/animationer fra begyndelsen.
Jeg tror, vi alle sætter pris på, at dette tip til at "planlægge fremad" kom i det absolut sidste øjeblik. Tak, Tom, og held og lykke med disse eftermonteringer.
