Voordat ik mijn carrière in ontwikkeling zette, deed ik een heleboel motion graphics-werk in After Effects. Maar zelfs met die achtergrond vond ik animaties op het web nog steeds behoorlijk verbijsterend.
Video graphics zijn ontworpen binnen een specifieke verhouding en vervolgens geëxporteerd. Gedaan! Maar er zijn geen "exportinstellingen" op internet. We duwen de code gewoon de wereld in en onze animaties moeten zich aanpassen aan het apparaat waarop ze terechtkomen.
Dus laten we het hebben over responsieve animatie! Hoe pakken we het animeren op het wilde wilde web het beste aan? We behandelen enkele algemene benaderingen, enkele GSAP-specifieke tips en enkele bewegingsprincipes. Laten we beginnen met wat framing...
Hoe wordt deze animatie gebruikt?
Zach Saucier's artikel over responsieve animatie raadt aan een stap terug te doen om na te denken over het uiteindelijke resultaat voordat u in de code springt.
Wordt de animatie een module die in meerdere delen van uw applicatie wordt herhaald? Moet het überhaupt worden geschaald? Als u dit in gedachten houdt, kunt u bepalen in welke methode een animatie moet worden geschaald en voorkomt u dat u moeite verspilt.
Dit is een geweldig advies. EEN reusachtig een deel van het ontwerpen van responsieve animatie is weten of en hoe die animatie moet worden geschaald, en vervolgens vanaf het begin de juiste aanpak kiezen.
De meeste animaties vallen in de volgende categorieën:
- Fixed: Animaties voor zaken als pictogrammen of laders die op alle apparaten dezelfde grootte en beeldverhouding behouden. Hier hoeft u zich geen zorgen over te maken! Codeer daar wat pixelwaarden in en ga verder met je dag.
- Vloeistof: Animaties die zich vloeiend moeten aanpassen op verschillende apparaten. De meeste lay-outanimaties vallen in deze categorie.
- gerichte: Animaties die specifiek zijn voor een bepaald apparaat of schermgrootte, of aanzienlijk veranderen op een bepaald breekpunt, zoals alleen desktopanimaties of interacties die afhankelijk zijn van apparaatspecifieke interactie, zoals aanraken of zweven.
Vloeiende en gerichte animaties vragen om andere denkwijzen en oplossingen. Laten we kijken…
Vloeiende animatie
As Andy Bell zegt: Wees de mentor van de browser, niet zijn micromanager - geef de browser enkele solide regels en hints, en laat hem dan de juiste beslissingen nemen voor de mensen die hem bezoeken.
(Hier zijn de dia's uit die presentatie.)
Bij vloeiende animatie draait alles om de browser het harde werk te laten doen. Veel animaties kunnen eenvoudig worden aangepast aan verschillende contexten door vanaf het begin de juiste eenheden te gebruiken. Als je het formaat van deze pen aanpast, kun je zien dat de animatie met viewport-eenheden schaalt vloeiend terwijl de browser zich aanpast:
Het paarse vak verandert zelfs van breedte op verschillende breekpunten, maar omdat we percentages gebruiken om het te verplaatsen, schaalt de animatie ook mee.
Opmaakeigenschappen animeren zoals left en top kan lay-outterugloop en zenuwachtige 'janky'-animatie veroorzaken, dus blijf waar mogelijk bij transformaties en dekking.
We zijn echter niet alleen beperkt tot deze eenheden - laten we eens kijken naar enkele andere mogelijkheden.
SVG-eenheden
Een van de dingen die ik leuk vind aan het werken met SVG, is dat we SVG-gebruikerseenheden kunnen gebruiken voor animaties die direct uit de doos reageren. De aanwijzing zit echt in de naam - schaalbare Vector afbeelding. In SVG-land worden alle elementen op specifieke coördinaten uitgezet. SVG-ruimte is als een oneindig stuk ruitjespapier waar we elementen kunnen rangschikken. De viewBox definieert de afmetingen van het millimeterpapier dat we kunnen zien.
viewBox="0 0 100 50”In deze volgende demo, onze SVG viewBox is 100 eenheden breed en 50 eenheden hoog. Dit betekent dat als we het element animeren door 100 eenheden langs de x-as, zal het altijd over de gehele breedte van zijn bovenliggende SVG bewegen, ongeacht hoe groot of klein die SVG is! Geef de demo een resize om te zien.
Het animeren van een onderliggend element op basis van de breedte van een bovenliggende container is een kleine truc in HTML-land. Tot nu toe moesten we de breedte van de ouder met JavaScript pakken, wat gemakkelijk genoeg is als je aan het animeren bent from een getransformeerde positie, maar een beetje lastiger als je animeert to ergens zoals je kunt zien in de volgende demo. Als uw eindpunt een getransformeerde positie is en u de grootte van het scherm wijzigt, moet u die positie handmatig aanpassen. Rommelig…
Als u waarden aanpast bij het wijzigen van de grootte, vergeet dan niet om ontspringen, of activeer de functie zelfs nadat het formaat van de browser is gewijzigd. Formaat wijzigen luisteraars starten elke seconde een heleboel gebeurtenissen, dus het updaten van eigenschappen voor elke gebeurtenis is veel werk voor de browser.
Maar deze verkeersdrempel met animatie behoort binnenkort tot het verleden! Tromgeroffel alstublieft...
Container-eenheden! Heerlijk spul. Op het moment dat ik dit schrijf, werken ze alleen in Chrome en Safari - maar misschien hebben we tegen de tijd dat je dit leest ook Firefox. Bekijk ze in actie in deze volgende demo. Kijk die kleine jongens gaan! Is dat niet spannend, animatie die relatief is aan de bovenliggende elementen!
Deze browserondersteuningsgegevens zijn van: Kan ik gebruiken, die meer details heeft. Een getal geeft aan dat de browser de functie vanaf die versie ondersteunt.
Desktop
| Chrome | Firefox | IE | rand | Safari |
|---|---|---|---|---|
| 105 | Nee | Nee | 105 | 16.0 |
Mobiel / Tablet
| Android Chrome | Android Firefox | Android | iOS Safari |
|---|---|---|---|
| 106 | Nee | 106 | 16.0 |
Vloeiende lay-outovergangen met FLIP
Zoals we eerder vermeldden, is in SVG-land elk element netjes op één raster geplaatst en heel gemakkelijk responsief te verplaatsen. In HTML-land is het veel complexer. Om responsieve lay-outs te bouwen, maken we gebruik van een heleboel verschillende positioneringsmethoden en lay-outsystemen. Een van de grootste problemen bij het animeren op internet is dat: veel van wijzigingen in de lay-out zijn onmogelijk te animeren. Misschien moet een element van positie worden verplaatst relative naar fixed, of sommige kinderen van een flexcontainer moeten soepel door de viewport worden geschud. Misschien moet een element zelfs opnieuw worden geplaatst en naar een geheel nieuwe positie in de DOM worden verplaatst.
Lastig, hè?
We zullen. De FLIP-techniek is er om de dag te redden; het stelt ons in staat om deze onmogelijke dingen gemakkelijk te animeren. Het uitgangspunt is:
- Voornaam*: Pak de beginpositie van de elementen die bij de overgang betrokken zijn.
- Achternaam*: Verplaats de elementen en pak de uiteindelijke positie.
- Omkeren: bereken de veranderingen tussen de eerste en de laatste toestand en pas transformaties toe om de elementen terug te keren naar hun oorspronkelijke positie. Hierdoor lijkt het alsof de elementen nog in de eerste positie, maar dat zijn ze eigenlijk niet.
- Spelen: verwijder de omgekeerde transformaties en animeer naar hun vervalst eerste staat aan de laatste staat.
Hier is een demo die gebruikmaakt van de FLIP-plug-in van GSAP die al het zware werk voor u doet!
Als je iets meer wilt weten over de vanille-implementatie, ga dan naar Paul Lewis's blogpost — hij is het brein achter de FLIP-techniek.
Vloeiend schalen van SVG
Je hebt me... dit is niet werkelijk een animatietip. Maar voor een goede animatie is de juiste setting essentieel! SVG schaalt standaard super mooi, maar we kunnen bepalen hoe het nog verder schaalt met preserveAspectRatio, wat superhandig is als de beeldverhouding van het SVG-element en de viewBox beeldverhouding zijn verschillend. Het werkt grotendeels op dezelfde manier als de background-position en background-size eigenschappen in CSS. De declaratie bestaat uit een uitlijningswaarde (background-position) En een Maak kennis met or Plak referentie (background-size).
Wat betreft die Meet and Slice-referenties - slice is als background size: cover en meet is als background-size: contain.
preserveAspectRatio="MidYMax slice"— Lijn uit met het midden van de x-as, de onderkant van de y-as, en schaal omhoog om het hele kijkvenster te bedekken.preserveAspectRatio="MinYMin meet"— Lijn uit aan de linkerkant van de x-as, de bovenkant van de y-as, en schaal omhoog terwijl u de heleviewBoxzichtbaar.
Tom Miller gaat nog een stap verder door overflow: visible in CSS en een bevattend element om "stage left" en "stage right" te onthullen terwijl de hoogte beperkt blijft:
Voor responsieve SVG-animaties kan het handig zijn om gebruik te maken van de SVG-viewbox om een weergave te creëren die onder een bepaalde browserbreedte wordt bijgesneden en geschaald, terwijl ook meer van de SVG-animatie naar rechts en links zichtbaar wordt wanneer de browser breder is dan dat drempel. We kunnen dit bereiken door overloop zichtbaar op de SVG toe te voegen en samen te werken met a
max-heightwrapper om te voorkomen dat de SVG te veel verticaal wordt geschaald.
Vloeiend schalend canvas
Canvas is veel performanter voor complexe animaties met veel van bewegende delen dan het animeren van SVG of HTML DOM, maar het is ook inherent complexer. Voor die prestatiewinst moet je werken! In tegenstelling tot SVG dat mooie responsieve eenheden heeft en direct uit de doos kan worden geschaald, moet een beetje worden gecommandeerd en gemicromanaged.
Ik vind het leuk om mijn zodat het ongeveer op dezelfde manier werkt als SVG (ik ben misschien bevooroordeeld) met een mooi eenheidssysteem om binnen te werken en een vaste beeldverhouding. moet ook elke keer dat er iets verandert opnieuw worden getekend, dus vergeet niet om het opnieuw tekenen uit te stellen totdat de browser klaar is met het wijzigen van het formaat, of debounce!
George Francis zet dit ook in elkaar mooie kleine bibliotheek waarmee je een Canvas kunt definiëren viewBox attribuut en preserveAspectRatio - precies zoals SVG!
Gerichte animatie
Het kan zijn dat u uw animatie soms minder vloeiend en gerichter moet benaderen. Mobiele apparaten hebben veel minder onroerend goed en minder prestaties qua animaties dan een desktopcomputer. Het is dus logisch om mobiele gebruikers beperkte animatie te bieden, mogelijk zelfs geen animatie:
Soms is de beste responsieve animatie voor mobiel helemaal geen animatie! Geef voor mobiele UX prioriteit aan het snel laten consumeren van inhoud door de gebruiker in plaats van te wachten tot de animaties zijn voltooid. Mobiele animaties moeten de inhoud, navigatie en interacties verbeteren in plaats van vertragen. Eric van Holtz
Om dit te doen, kunnen we mediaquery's gebruiken om specifieke viewport-groottes te targeten, net zoals we doen wanneer we stylen met CSS! Hier is een eenvoudige demo die een CSS-animatie laat zien die wordt afgehandeld met behulp van mediaquery's en een GSAP-animatie die wordt afgehandeld met gsap.matchMedia():
De eenvoud van deze demo verbergt een heleboel magie! JavaScript-animaties vereisen wat meer instellingen en opschonen om correct te werken op slechts één specifieke schermgrootte. Ik heb in het verleden verschrikkingen gezien waarbij mensen de animatie net in CSS verborgen hebben gehouden met opacity: 0, maar de animatie pruttelt nog steeds op de achtergrond en verbruikt bronnen.
Als de schermgrootte niet meer overeenkomt, moet de animatie worden afgebroken en vrijgegeven voor het verzamelen van afval, en moeten de elementen die door de animatie worden beïnvloed, worden ontdaan van alle door beweging geïntroduceerde inline-stijlen om conflicten met andere styling te voorkomen. Tot aan gsap.matchMedia(), dit was een moeizaam proces. We moesten elke animatie bijhouden en dit alles handmatig beheren.
gsap.matchMedia() in plaats daarvan kun je eenvoudig je animatiecode in een functie stoppen die alleen wordt uitgevoerd wanneer een bepaald media query wedstrijden. Dan, als het niet meer overeenkomt, worden alle GSAP-animaties en ScrollTriggers in die functie wordt automatisch teruggezet. De mediaquery waarin de animaties worden geplaatst, doet al het harde werk voor u. Het zit in GSAP 3.11.0 en het is een game changer!
We zijn ook niet alleen beperkt tot schermformaten. Er zijn een heel veel mediafuncties die er zijn inhaken!
(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 */In de volgende demo hebben we een cheque toegevoegd voor: prefers-reduced-motion zodat gebruikers die animatie desoriënterend vinden, geen last hebben van rondsnuffelende dingen.
En bekijk de andere leuke demo van Tom Miller waar hij de beeldverhouding van het apparaat gebruikt om de animatie aan te passen:
Buiten de gebaande paden denken, verder dan schermformaten
Er komt meer bij het nadenken over responsieve animatie kijken dan alleen schermformaten. Verschillende apparaten zorgen voor verschillende interacties, en het is gemakkelijk om een beetje in de war te raken als je daar geen rekening mee houdt. Als u zweeftoestanden maakt in CSS, kunt u de hover mediafunctie om te testen of de gebruiker primair invoermechanisme kan over elementen zweven.
@media (hover: hover) {
/* CSS hover state here */
}Wat advies van Jake Whiteley:
Vaak baseren we onze animaties op de breedte van de browser, waarbij we de naïeve veronderstelling maken dat desktopgebruikers zweeftoestanden willen. Ik heb persoonlijk in het verleden veel problemen gehad waarbij ik overschakelde naar desktoplay-out> 1024px, maar misschien wel aanraakdetectie in JS - wat leidde tot een mismatch waar de lay-out voor desktops was, maar de JS voor mobiele telefoons. Tegenwoordig leun ik op de aanwijzer en de aanwijzer om pariteit te garanderen en om te gaan met iPad Pro's of Windows-oppervlakken (die het type aanwijzer kunnen veranderen, afhankelijk van of de hoes naar beneden is of niet)
/* any touch device: */
(hover: none) and (pointer: coarse)
/* iPad Pro */
(hover: none) and (pointer: coarse) and (min-width: 1024px)Ik zal dan mijn CSS-lay-outquery's en mijn JavaScript-query's met elkaar verbinden, dus ik beschouw het invoerapparaat als de primaire factor ondersteund door de breedte, in plaats van het tegenovergestelde.
ScrollTrigger-tips
Als u GSAP's gebruikt ScrollTrigger-plug-in, is er een handig klein hulpprogramma waarop u kunt aansluiten om gemakkelijk de aanraakmogelijkheden van het apparaat te onderscheiden: ScrollTrigger.isTouch.
0- niet aanraken (alleen aanwijzer/muis)1- alleen aanraken apparaat (zoals een telefoon)2– apparaat kan accepteren input en muis aanwijzer (zoals Windows-tablets)
if (ScrollTrigger.isTouch) {
// any touch-capable device...
}
// or get more specific:
if (ScrollTrigger.isTouch === 1) {
// touch-only device
}Nog een tip voor responsieve scroll-getriggerde animatie...
In de volgende demo hieronder wordt een afbeeldingengalerij horizontaal verplaatst, maar de breedte verandert afhankelijk van de schermgrootte. Als je het formaat van het scherm aanpast wanneer je halverwege een gescrubde animatie bent, kun je eindigen met gebroken animaties en oude waarden. Dit is een veelvoorkomende verkeersdrempel, maar wel een die gemakkelijk kan worden opgelost! Pop de berekening die afhankelijk is van de schermgrootte in een functionele waarde en stel in invalidateOnRefresh:true. Op die manier berekent ScrollTrigger die waarde opnieuw voor u wanneer de browser het formaat wijzigt.
Bonus GSAP-nerdtip!
Op mobiele apparaten wordt de adresbalk van de browser meestal weergegeven en verborgen terwijl u scrolt. Dit telt als een resize-gebeurtenis en wordt geactiveerd a ScrollTrigger.refresh(). Dit is misschien niet ideaal, omdat het kan leiden tot sprongen in je animatie. GSAP 3.10 toegevoegd ignoreMobileResize. Het heeft geen invloed op hoe de browserbalk zich gedraagt, maar het voorkomt ScrollTrigger.refresh() van het vuren op kleine verticale formaatwijzigingen op apparaten met alleen aanraking.
ScrollTrigger.config({
ignoreMobileResize: true
});Bewegingsprincipes
Ik dacht dat ik u enkele praktische tips zou geven om te overwegen bij het werken met beweging op internet.
Afstand en versoepeling
Een klein maar belangrijk ding dat gemakkelijk te vergeten is met responsieve animatie is de relatie tussen snelheid, momentum en afstand! Goede animatie zou de echte wereld moeten nabootsen geloofwaardig te voelen, en in de echte wereld duurt het langer om een grotere afstand af te leggen. Besteed aandacht aan de afstand die uw animatie aflegt en zorg ervoor dat de gebruikte duur en versnelling zinvol zijn in samenhang met andere animaties.
Je kunt ook vaak meer dramatische versoepeling toepassen op elementen met verder te reizen om het toegenomen momentum te tonen:
Voor bepaalde gebruikssituaties kan het handig zijn om de duur dynamischer aan te passen op basis van de schermbreedte. In deze volgende demo maken we gebruik van gsap.utils om de waarde vast te leggen die we terugkrijgen van de stroom window.innerWidth binnen een redelijk bereik, dan koppelen we dat aantal aan een duur.
Afstand en hoeveelheid
Een ander ding om in gedachten te houden is de afstand en hoeveelheid elementen op verschillende schermformaten. citeren Steven Shaw:
Als je een soort omgevingsanimatie hebt (parallax, wolken, bomen, confetti, decoraties, enz.) die rond het raam zijn geplaatst, zorg er dan voor dat ze schalen en/of de hoeveelheid aanpassen, afhankelijk van de schermgrootte. Grote schermen hebben waarschijnlijk meer elementen nodig, terwijl kleine schermen er maar een paar nodig hebben voor hetzelfde effect.
Ik hou ervan hoe Opher Vishnia denkt over animatie als een podium. Het toevoegen en verwijderen van elementen hoeft niet alleen een formaliteit te zijn, het kan onderdeel zijn van de totale choreografie.
Bij het ontwerpen van responsieve animaties is de uitdaging niet hoe dezelfde inhoud in de viewport te proppen zodat deze "past", maar eerder hoe de set bestaande inhoud te beheren zodat deze dezelfde intentie communiceert. Dat betekent dat je een bewuste keuze moet maken welke stukjes inhoud je wilt toevoegen en welke je wilt verwijderen. Gewoonlijk komen dingen in de wereld van animatie niet zomaar in of uit het frame. Het is logisch om elementen te zien als het binnenkomen of verlaten van het "podium", en die overgang animeren op een manier die visueel en thematisch zinvol is.
En dat is het lot. Als je nog meer responsieve animatietips hebt, plaats ze dan in het opmerkingengedeelte. Als er iets super nuttigs is, zal ik ze toevoegen aan dit compendium met informatie!
bijvoegsel
Nog een opmerking van Tom Miller terwijl ik dit artikel aan het voorbereiden was:
Ik ben waarschijnlijk te laat met deze tip voor je artikel over responsieve animaties, maar ik raad ten zeerste aan om "alle animaties af te ronden voordat je ze gaat bouwen". Ik ben momenteel enkele site-animaties aan het aanpassen met "mobiele versies". Godzijdank voor
gsap.matchMedia… maar ik zou zeker willen dat we vanaf het begin hadden geweten dat er aparte mobiele lay-outs/animaties zouden zijn.
Ik denk dat we het allemaal waarderen dat deze tip om 'vooruit te plannen' op het allerlaatste moment kwam. Bedankt, Tom, en veel succes met die aanpassingen.
