Hvordan de gjorde det Kickstarters lagside

Fortsett med vår serie av desconstructive artikler, i dag skal vi se på byggeblokkene til Kickstarters lagside.

Hvis du ikke er kjent med Kickstarter, er det et selskap som gjør det mulig for folkemessig finansiering for prosjekter. Kickstarters suksess har naturlig forplantet seg til kreative bedrifter over hele verden, noe som gir noen utrolig vellykkede prosjekter og oppstart.

I stedet for å fokusere på hvor kjempebra Kickstarter er, vil vi i stedet diskutere den tekniske tilnærmingen Kickstarter-teamet tok for å lage deres Team-side.

Vi snakker litt om detaljer, og vi snakker også fra et perspektiv på høyt nivå. La oss komme i gang!


En oversikt over kilden

Når vi ser gjennom kilden til Kickstarters Team-side, kan vi utlede noen få ting. For det første bruker de nesten helt sikkert Rails. Dette kommer som en liten overraskelse, siden de fleste lagets Github-sider er fullpakket med Ruby-repositorier (sammen med JavaScript og Objective-C, som vanligvis brukes til iPhone / iPad Apps).

Det neste vi kan se er en konsekvent avhengighet av CDN-drevne eiendeler. Seks (eller syv hvis du er IE) eksterne stilark og åtte eksterne skript (noen lastet asynkront) kommer alle fra forskjellige CDN. Vi kan også umiddelbart se at Kickstarter i det minste delvis støtter IE, helt tilbake til IE6. Alle disse eiendelene blir minifisert og, når det er aktuelt, komprimert.

Ytterligere avledninger kan gjøres om Kickstarter-teamets tilnærming til CSS; en compass.css filen er lastet like etter a fonts.css fil, sannsynligvis generert av Compass og Sass. Dette er de to første stilfilene lastet.

Kickstarter benytter Facebook-tilkobling samt Apple-touch / iPad-koblingsikonene for å lagre webapper til hjemmeskjermen til iOS.

Kickstarter bruker også en rekke analysetjenester. Quantcast, Mixpanel, New Relic, Chartbeat og Google Analytics-skript er alle inkludert på siden.

Vi kan også se oppslag for Zendesk, en kunderelasjonstjeneste, så vel som jGrowl, en growl-esque notifier. Disse blir sannsynligvis brukt av andre sider på nettstedet og lagt til dynamisk via JavaScript.

Ikke overraskende, Kickstarter er avhengig av jQuery og / eller Zepto, avhengig av situasjonen.


Ok, videre til Cool (est) Stuff

(Spesielt de fantastiske videoene) ...

Det første vi umiddelbart merker er det 600px høye videoelementet til Kickstarter-teamet, foran og midtpunkt. Hver av de 46 medlemmene henger tilfeldigvis foran noen trepaneler.

Videoen (som faktisk er seks separate videoer sydd sammen) er satt til sløyfe automatisk. For nettlesere som ikke støtter videoelementet, brukes plakatelementet; For eksempel bruker den lengste venstre videoen denne plakaten:

en ramme fra videoen som fortsatt viser laget. Dette er et godt eksempel på grasiøs nedbrytning.

Videoene er "draggable" ved hjelp av JavaScript; Dette er det primære interaktive elementet på denne siden. Markøren endres til markør: flytt via JavaScript. En stor mengde matte- og tverrkontrollfunksjonskontroller er i JavaScript for videoens trekkbare funksjonalitet. I særdeleshet brukes touchstart og touchend hendelser hvis tilgjengelig (i stedet for mousedown og mouseup). En betydelig mengde av JavaScript som er relevant for denne siden, er dedikert til glatt kinetisk rulling. Prøv å dra videoen raskt og slippe av; ligner Apples innebygde rulleadferd, ser vi videobåndet å holde hastigheten og senke over tid.

Den grunnleggende strukturen til videostripen HTML er som følger:

 

De #video_header elementet er satt til å være en bredde på 100% (skjermbredden) med et overløp av skjult, med .video_scroll div har en bredde som inneholder alle videoene (over 7000px), som er satt til display: inline og float: left; scrollTop eller scrollLeft av et element med overløp: skjult kan fortsatt settes dynamisk med JavaScript, selv om ingen rullefelt er synlig.

Ta en titt på denne CodePen for et eksempel på et "draggbart" avsnitt:

Merk: dette eksemplet virker ikke for berøringsenheter, og har ingen funksjoner for kinetisk rulling, noe som tyder på oppmerksomhet på detaljer Kickstarter ansatt.

Ett siste notat: Vi har ikke tilgang til den uformidlede versjonen av JavaScript, men å se en prettified versjon av den minifiserte skriptfilen kan gi litt innsikt i strukturen og teknikkene som brukes.


Kinetisk rulling

Så hvordan ville du gå om å implementere kinetisk rulling? En kombinasjon av setTimeout-baserte funksjoner (eller, hvis tilgjengelig, requestAnimationFrame) for å finne ut hastigheten som du ruller når du slipper drahåndtaket, brukes til å definere en starthastighet, som deretter senker over tid basert på en lettelse fungere til elementet stopper.

For en ide om hva Easing funksjoner ser ut som over tid, ta en titt på easings.net, en lettelse cheat sheet. Spesielt vil en kinetisk rulle starte ved høyeste hastighet og sakte seg over tid, slik at en kubisk utløsingsfunksjon kan bli brukt. Hvis du vil vite mer om hvordan lettelse fungerer, kan du se på denne artikkelen, som er basert på ActionScript, men kan lett oversettes til JavaScript.

En god øvelse er å tenke på hvordan forskjellige lettelsefunksjoner kan gjelde. For eksempel ville en hoppende ball være en studsende funksjon. Men hva ville en brukervennlighet, brukervennlighet bli brukt til? Kanskje hvis du simulerer en ball som ruller ned og baker opp en bakke; Hastigheten på toppen av en ås ville være sakte, så raskeste på bunnen, så sakte mot toppen av den andre bakken.


Hva annet er kul på denne siden?

Søkefunksjonen (som finnes på flere sider på nettstedet) fungerer via JavaScript og JSON (sjekk ut dette JSON-svaret når du søker etter termen "film", så vel som den tilhørende indekssiden). Den er også avhengig av en fast bredde som inneholder element og animerer egenskapen scrollLeft.

Foten har et pent lite påskeegg; å klikke på saksespannen (som har tre forskjellige "sakseposisjoner" aktivert ved endringer i klassen) animerer saksen over skjermen;

Klikk den tre ganger, og den "kutter" bunnteksten nederst på siden, og avslører et kvadratrille (impliserer et Photoshop blank lerret). Alt dette gjøres med ganske enkle jQuery-animasjoner og tilbakeringinger, og er stilistisk drevet med CSS-klasser og jQuery inline-stilerklæringer.


Responsive Strategy?

Mens Kickstarter Team-siden for øyeblikket ikke bruker medieforespørsler for responsiv design, sørger de for tilgjengelighet for berøringsenheter. Det er mulig at Kickstarter utvikler en iOS-app, basert på lagets erfaring og GitHub-depotene. De gjør også noe ved å bruke Zepto i stedet for jQuery betinget.


Kritikk

Fordi ingen er perfekt ...

4 CSS-filer?

Hovedkritikken vi kan tilby, handler om tilstedeværelsen av fire CSS-filer. Splitting CSS over fire separate filer øker antall HTTP-forespørsler, som bør unngås; men det er det flere Mulige årsaker Kickstarter-teamet bestemte seg for å gjøre dette. De har sannsynligvis gode grunner, vurderer de tiltakene de har tatt mot optimalisering ellers; spesielt de kunne ha brukt noe som Bless CSS. IE vil bare tillate et bestemt antall selektorer per CSS-fil; Bless CSS teller automatisk dine selektorer og deler dine CSS-filer tilsvarende hvis de går over grensen. En annen mulig grunn er å unngå lastingskode som ikke er nødvendig på andre steder; For eksempel kan det være tilfelle at de minst brukte seleksjonene (på tvers av siden) ender i den fjerde CSS-filen, og dermed kan alle fire filene lastes i svært få tilfeller.

Mangel på responsiv design

Responsiv design via bruk av medieforespørsler vil være hyggelig å se, men det kan være tilfelle at Kickstarter deler opp publikum og oppfordrer skrivebordsbesøk basert på noen av deres (tilsynelatende omfattende) datainnsamling og analyse. Det kan også være tilfelle at Kickstarter foretrekker å investere i en innfødt app, men det vet vi ikke sikkert enda.

Hvem er disse folkene?

Den endelige kritikken vi har er enkel: hvem er hver av lagmedlemmene? Jo, vi har navnene, men jeg vet ikke hvilken person som matahces med hvilket navn. Det ville vært interessant å markere navnene når du svinger over et lagmedlems navn, for eksempel. En annen enkel løsning ville være å si at folket er oppført i "rekkefølge av utseende".

Dette kan imidlertid også ha vært en bestemt beslutning fra Kickstarter, for å beskytte personvernet til de enkelte gruppemedlemmene. Hvis ikke ett lagmedlem ikke ønsket å bli identifisert, er det det riktige valget å ikke identifisere noen av lagmedlemmene. Det kan også være en melding Kickstarter ønsker å formere, at dette laget er en enkelt enhet; Dette kan imidlertid bli bedre servert ved ikke å vise navnene i det hele tatt.


Konklusjon

Kickstarter Team-siden har mottatt noen svært positive tilbakemeldinger fra designmiljøet, og vi kan lære av denne siden på mange måter. Spesielt bør vi ta bort det faktum at kombinere noen enkle ideer på en ny måte (for eksempel en innholdscroller og video) kan føre til noen svært interessante og overbevisende innholdsdrevne interaksjoner. Denne siden bruker ikke noe som er spesielt "fordybende" eller komplisert, men det fanger vår interesse og holder den. Innholdet legges igjen på en piedestal, og brukere blir invitert til å utforske det innholdet på en morsom, men enkel måte.

Hva mer merker du om Kickstarters lagside? Er det andre lignende interessante sider du fant på Kickstarter? Hva synes du om deres beslutning om å unngå media-spørringsbaserte responsive løsninger? Gi oss beskjed i kommentarene!