Hvordan de gjorde det Apples heve ekspedisjonen

Vi takler en stor dag i dag: Apples «Oppheve ekspedisjonen» iPad-markedsføringssiden.

Muligens er det et imponerende nettsted i seg selv som viser noe kraftig JavaScript og CSS. Apple har også tatt konseptet målgruppen veldig seriøst i sine beslutninger med dette nettstedet. La oss dykke inn!

Et første blikk: grunnleggende elementer

Dette nettstedet kommer som et tillegg til en lang liste over nettsteder som benytter rulling for å forbedre innholdspresentasjon og utløser utformede animasjoner. Når du ruller på nettstedet, kan du se innholdsbefolkningen mens du ruller, inkludert en høyde telling på høyre side som øker mens du ruller ned Dette er en indikator som følger med fortellingen av klatrerens historie om oppstigning. 

Vi ser også noen subtile parallax animasjoner (for eksempel skyene), noen få illustrasjonsutløsere som oppstår når de kommer til syne, og noen uendelige animasjoner som ikke stole på noen interaksjon.

Svært store bilder brukes over hele nettstedet (mer om dette i neste avsnitt), både som bakgrunnsbilder og som inline-innholdsbilder.

Beslutninger: Hvorfor beste praksis er noen ganger relativ

Apple tok noen interessante beslutninger med denne markedsføringssiden. Kanskje den mest skarpe beslutningen er størrelsen på eiendelene på siden. Nedenfor kan du se et skjermbilde fra Chrome's inspektør. På en rask internettforbindelse tar nettstedet bra over 2s bare for å laste eiendelene på siden. Den totale nedlastingsstørrelsen for nettstedet overstiger 12,5 MB. Apple har selvfølgelig optimalisert ganske mange ting (som vi vil dekke), men spørsmålet gjenstår - hvordan kan noen rettferdiggjøre en 4MB PNG for det som er teknisk en "ekstra" sky animasjon?

Svaret er ganske sannsynlig at Apples mål for denne siden aldri vil oppleve noen problemer med å laste ned de ginormøse eiendelene, og hvis de gjør det, kan de ikke bry seg. Målgruppen er mest sannsynlig på en Mac eller en annen moderne skjerm, og de er sannsynligvis på et raskt nettverk. Derfor har Apple tatt beslutningen om å støtte en spesielt overbevisende opplevelse, og tillate en mindre opplevelse for de som sannsynligvis ikke er i deres målgruppe.

Det bør også vurderes at denne siden er en markedsføringskampanje som eksisterer utenfor Apples salgsstrøm, noe som betyr at ingen er sperret fra å kjøpe en iPad fra deres oppringte Dell på en SD CRT-skjerm, hvis de velger det.

En annen interessant beslutning Apple har gjort (både her og i mange andre webprosjekter) er bruken av bilder for tekstoverskrifter. 

Dette er en png

De fleste vet at Apple i mange år har prided seg på konsistent, klar typografi. Den sene Steve Jobs tok til og med en kalligrafi klasse på Reed College, som han sier inspirerte ham til å bringe artikulert skriftkontroll til Mac-operativsystemet. Med denne prioriteten i tankene velger Apple regelmessig å gjengi bilder av tekst i stedet for skrifter for de fleste overskriftene, antagelig slik at de har kontroll over hva alle ser. Selv om det er noen utgifter til denne beslutningen, håndterer Apple denne regningen for konsistent kvalitet og full kontroll over sluttproduktet.

Interessant nok har de selv gått så langt som å gjøre dette med nummerindikatoren på oksygenkartet. 

Se selv, her er SVG-sprite

Progressiv forbedring

Apple brukte noen enkle, progressive forbedringsmetoder på dette nettstedet; nemlig at designen forblir intakt i alle nettlesere, mens samspillet kan variere basert på nettleserens evner. Apple bruker css forvandle; og de fleste av de progressive forbedringene dreier seg om dette aspektet. Andre elementer, som skyveinngangen i den andre delen, vises kun i støttende nettlesere. Apple bruker hack som følgende, som brukes til å skjule elementer i IE 7-9, men viser i alle andre nettlesere. Dette er nyttig ved gjengivelse av statiske elementer for IE, for eksempel toppmøntediagrammet.

.diagram .oksygen-glidebryteren posisjon: absolutt; top: 246px; venstre: 45 piksler; display: none \ 9;  .ie-graph display: none; display: block \ 9; stilling: i forhold; topp: 0;  

Køen display: none \ 9; og display: block \ 9; linjer er bare gyldige i IE 7-9; dette lille trikset unngår å bruke IE-spesifikke stilark.

Glidebryteren og animasjonen på dette diagrammet vises ikke i IE.

Apple benytter også JavaScript for å gjøre enkle ting som å erstatte bilder med deres hi-res-versjoner etter behov. Mens Chromium har offisielt implementert responsive bilder, er det fortsatt langt fra full adopsjon, slik at dette gjennom JavaScript er for øyeblikket en av de eneste tilgjengelige alternativene.

Massive filer: Hvordan de kommer unna med det

Hvordan laster du massive filer og kommer unna med det? La oss ta noen leksjoner fra dette nettstedet.

1. Optimaliser hvor det er mulig

Det er utrolig viktig å optimalisere, når det er mulig. I dette tilfellet har Apple optimalisert noen bilder mye. For eksempel er 1024 × 1766 header-bildet 341 KB, og pakkeelementene er 49,9 KB. Selv om ingen byte bør anses å være dispensabel, blir disse størrelsene relativt rask nedlastet ved de fleste moderne tilkoblingshastigheter, inkludert mange mobiloperatørhastigheter.

2. Ikke blokkér siden

Bilder og skript kan redusere hastigheten på en side betydelig. Når det er mulig, bruk noe som latisk lasting (lasting med JavaScript når siden allerede har lastet inn) for å laste inn store bilder, eller ta med dem i CSS som bakgrunnsbilder hvis de ikke er en del av den semantiske innholdsstrømmen. Apple jobber med en etterlastende JavaScript-teknikk med alle høykvalitetsbilder, som tidligere diskutert, og bruker også CSS til å angi de store skyen PNG-bakgrunnsbilder.

3. Plassering er nøkkel

Ønsker siden din å føle seg rask? fokus på å gjøre toppen 2000px så fort som mulig. Uansett hva som er under 2000px, hvis du legger inn innhold i to vinduhøyder, er det mye mer sannsynlig at innholdet utover 2000px skal lastes når brukeren ruller til den. Apple har gjort dette til en prioritet ved å skyve de store PNG-ene ned til ca 4400 px fra toppen av siden, og har lagt raske lastebilder mot toppen.

Hvordan de gjorde det: Noen detaljer

Slider Element

Skyveelementet gir brukeren sin første interaksjon på siden (unntatt rulling). Apple har brukt en område innspill, og litt CSS magi, for å trekke dette av. Som tidligere nevnt, er tallet til høyre for diagrammet gjort med bilder, men vi bruker vanlig typografi for å holde fast ved punktet. (Hvis du er interessert i å lære denne teknikken, start med å lære om CSS sprites.)

Du kan se denne skyveknappen i handling på CodePen

Det er noen ting å merke seg i dette eksemplet. Først, det er ganske mye CSS dedikert til å gjøre skyveinngangen ser riktig ut. De fleste av resten av CSS er rettet mot posisjonering og etter / før triks.

Et annet interessant aspekt ved denne demoen er indikatorelementet. La oss se på JavaScript et øyeblikk.

var skyveknappen = $ (".bgslider"); var max = slider.attr ("max"); var min = slider.attr ("min"); var colBg = $ (".fg"); var indikert = $ ("indikator"); slider.on ("endre", funksjon () var val = slider.val () / max * 100; colBg.css ("høyde", val + "%"); indic.css .7 + "%") [0] .innerHTML = Math.round (val);); 

Vi ser umiddelbart at skyveknappen er der all interaksjon er sentrert. Men ser på indikatoren, ser vi denne linjen:

indic.css ("top", val * .7 + "%") [0] .innerHTML = Math.round (val); 

Hva gjør denne linjen? For det første setter den høyeste verdien av indikatoren til prosentverdien av skyveknappen, multiplisert med .7 - dette gir oss en indikator som ikke går til bunnen av elementet. I eksemplet gitt av Apple følger indikatoren bildet; I dette eksemplet beveger indikatoren oss en annen hastighet enn bildet vårt. Dette gir oss mer kontroll over selve animasjonen.

Deretter ser vi animasjonen JavaScript.

$ "input"). animate ("value": 20000, trinn: funksjon () slider.val (this.value); slider.trigger ("change");, fullfør: funksjon slider.val (max) .trigger ("change");, varighet: 3000); 

Fordi jQuerys animerte funksjon støtter animerende CSS-egenskaper som standard, skriver vi våre egne trinn og komplette funksjoner. Dette tillater oss å utnytte jQuery's innebygde kø og lette funksjoner, og unngå å skrive tilpasset setInterval eller rekursiv setTimeout samtaler.

Vi har med vilje ikke gjort dette akkurat slik Apple oppnådde denne effekten, slik at vi kan vise deg hvordan du kan nærme det samme problemet med en annen løsning.

Pack Gear Animasjon

Neste, la oss se på pakkeutstyret.

Vi kan se at de forskjellige utstyrsdelene på en måte er lagt ut i nettleseren mens du ruller. Denne effekten oppnås ved hjelp av JavaScript-rullehendelsen, CSS-transformasjonen og CSS sprites. Apple har plassert femti forskjellige elementer ved hjelp av : N-te-barn og sprites, som ser slik ut:

.pakke: nth-barn (49) topp: 52.5px; venstre: 199px; bredde: 82px; høyde: 69.5px; bakgrunnsposisjon: -199px -52.5px;  

Den mest interessante delen av denne teknikken er imidlertid rulleanimasjonen JavaScript. Den opprinnelige JavaScript ble minifisert, men det grunnleggende oppsettet løper gjennom alle pakkepostene og samler posisjonen i forhold til midten av pakkepostene, og beveger dem videre i den retningen. Vi vil ikke dekke alle matematikkene i denne artikkelen; I stedet fokuserer vi på en måte å utforske emnet på.

http://codepen.io/jcutrell/full/krIAp

Denne CodePen viser en grov tilnærming til teknikken som brukes av Apple. Tweaking ulike deler av denne JavaScript vil gi deg forskjellige resultater, og vil hjelpe deg å utforske teknikken mer grundig.

Her er en utfordring for deg: fade elementet blokkene, som i Apples teknikk.

skyer

Sky animasjonene bruker en enkel parallax rulle teknikk, samt en uendelig CSS animasjon. Vi vil ikke dekke parallax teknikken (du kan se mange parallax teknikker dekket her på Tuts +), men la oss se på den uendelige animasjonen de skyene bruker.

Direkte fra Apples CSS:

.skyene posisjon: absolutt; venstre: 0; bakgrunn: 0 0 repeat-x; bakgrunnsstørrelse: 100% 100%;  .basecamp-clouds, .ascent-clouds z-indeks: 2; igjen: -788px;  .basecamp-clouds top: -500px; bredde: 2600px; høyde: 2413px; bakgrunnsbilde: url (http://images.apple.com/v/your-verse/elevating-expedition/a/images/clouds_basecamp_01.png);  / * maks synlig skjerm * 2 = 5200, ikke forveksles med @ 2x aktiv. * / .scent-clouds-1 .tile top: 50px; bredde: 5200px; høyde: 2000 piksler; bakgrunnsbilde-: url (http://images.apple.com/v/your-verse/elevating-expedition/a/images/clouds_ascent_01.png);  .scent-clouds-2 toppen: 600px; bredde: 2600px; høyde: 1846px; bottom: 0; bakgrunnsbilde-: url (http://images.apple.com/v/your-verse/elevating-expedition/a/images/clouds_ascent_02.png);  @keyframes cloudAnim fra transform: translateX () translateZ () til transform: translateX (-50%) translateZ () .scent-clouds-1.visible .tile -webkit-animasjon: cloudAnim 80s lineær uendelig; -moz-animasjon: cloudAnim 80s lineær uendelig; animasjon: cloudAnim 80s lineær uendelig;  

Vi kan umiddelbart se at sky animasjonen er rett frem - bruk transformere: translateX. Det som gjør denne teknikken så kraftig, er imidlertid lengden og klarheten til PNG brukt. Den store skyen PNG slår uendelig i åtti sekunder, som er lang nok til at PNGs repeterende mønster blir glemt. Selv om det ikke er for vanskelig å oppnå, er det absolutt en effektiv bruk av CSS-animasjoner.

Konklusjon

Apple kan være kantet på kontroversielt territorium med webutviklings kjerne "beste praksis" predikanter, men alle i yrket av webdesign må ta avgjørelser. Du bør alltid vurdere verdiene av en bytte; om du bør implementere en gitt funksjon, bør ikke dikteres utelukkende av beste praksis, eller av teknologiske begrensninger alene, men heller av behov og ønsker til de som vil se på tingen du lager. Ikke la reglene stå i veien for å gjøre noe fantastisk, men sørg for at du vurderer avvikene.