Share
Verdergaand met onze reeks desconstructive artikelen, vandaag gaan we kijken naar de bouwstenen van de Kickstarter Team-pagina.
Als u niet bekend bent met Kickstarter, is het een bedrijf dat crowdsourced-financiering voor projecten mogelijk maakt. Het succes van Kickstarter is van nature verspreid naar creatieve ondernemers over de hele wereld, waardoor een aantal ongelooflijk succesvolle projecten en startups zijn aangedreven.
In plaats van ons te concentreren op hoe geweldig Kickstarter is, bespreken we in plaats daarvan de technische benadering die het Kickstarter-team heeft gevolgd om hun Team-pagina te maken..
We zullen wat over details vertellen, en we zullen ook vanuit een hoogstaand perspectief praten. Laten we beginnen!
Kijkend door de bron voor Kickstarter's Team-pagina, kunnen we een paar dingen concluderen. Ten eerste gebruiken ze bijna zeker Rails. Dit is geen verrassing, want de meeste Github-pagina's van het team zitten vol met Ruby-repositories (naast JavaScript en Objective-C, meestal gebruikt voor iPhone / iPad-apps).
Het volgende dat we kunnen zien, is een consistente afhankelijkheid van door CDN aangedreven assets. Zes (of zeven als u IE bent) externe stylesheets en acht externe scripts (sommige asynchroon geladen) komen allemaal van verschillende CDN's. We kunnen ook meteen zien dat Kickstarter IE ten minste gedeeltelijk ondersteunt, helemaal terug naar IE6. Al deze activa zijn verkleind en, indien van toepassing, gecomprimeerd.
Verdere conclusies kunnen worden getrokken over de benadering van CSS door het Kickstarter Team; een compass.css bestand wordt geladen net na een fonts.css bestand, waarschijnlijk gegenereerd door Compass en Sass. Dit zijn de eerste twee stijlbestanden die zijn geladen.
Kickstarter maakt gebruik van Facebook connect en de Apple touch / iPad link-pictogrammen voor het opslaan van web-apps naar het startscherm van iOS.
Kickstarter maakt ook gebruik van verschillende analysediensten. Quantcast, Mixpanel, New Relic, Chartbeat en Google Analytics-scripts staan allemaal op de pagina.
We kunnen ook een opmaak zien voor Zendesk, een klantrelatieservice, evenals jGrowl, een grommelachtige melder. Deze worden waarschijnlijk gebruikt door andere pagina's op de site en dynamisch toegevoegd via JavaScript.
Zoals te verwachten, vertrouwt Kickstarter afhankelijk van de situatie op jQuery en / of Zepto.
(Met name die geweldige video's) ...
Het eerste wat we meteen opmerken is het 600px-hoge video-element van het Kickstarter-team, vooraan en in het midden. Elk van de 46 leden hangt nonchalant voor een paar houten panelen.
De video (die eigenlijk zes afzonderlijke video's is die aan elkaar zijn gestikt) is ingesteld om automatisch te worden herhaald. Voor browsers die het video-element niet ondersteunen, wordt het posterelement gebruikt; bijvoorbeeld, de meest linkse video gebruikt deze poster:
een frame uit de video die het team nog steeds weergeeft. Dit is een goed voorbeeld van sierlijke degradatie.
De video's zijn "versleepbaar" met behulp van JavaScript; dit is het primaire interactieve element van deze pagina. De cursor verandert in cursor: verplaatsen via JavaScript. Een groot aantal wiskundige en apparaatoverschrijdende controle van de mogelijkheden staan in JavaScript voor de versleepbare functionaliteit van de video's. In het bijzonder worden de aanraak- en aanraakgebeurtenissen gebruikt, indien beschikbaar (in plaats van mouseover en mouseup). Een aanzienlijk deel van het JavaScript dat relevant is voor deze pagina is gewijd aan het soepele kinetische scrollen. Probeer de video snel te slepen en los te laten; vergelijkbaar met het ingebouwde scrolgedrag van Apple, zien we dat de videoband de snelheid behoudt en in de loop van de tijd vertraagt.
De basisstructuur van de HTML-HTML-strip is als volgt:
De #video_header element is ingesteld op een breedte van 100% (de schermbreedte) met een overloop van verborgen, met de .video_scroll div met een breedte die alle video's bevat (meer dan 7000px), die elk zijn ingesteld op weergave: inline en float: left; de scrollTop of scrollLeft van een element met overloop verborgen kan nog steeds dynamisch worden ingesteld met JavaScript, hoewel er geen schuifbalk zichtbaar is.
Bekijk deze CodePen voor een voorbeeld van een "sleepbare" paragraaf:
Accentsconagua
Notitie: dit voorbeeld werkt niet voor apparaten met aanraakbediening en heeft geen functies voor kinetisch scrollen, wat duidt op detailinformatie van Kickstarter.
Een laatste opmerking: We hebben geen toegang tot de niet-geminimaliseerde versie van JavaScript, maar het bekijken van een fraaie versie van het verkleinde scriptbestand kan enig inzicht bieden in de gebruikte structuur en technieken.
Dus hoe zou je gaan met het implementeren van kinetisch scrollen? Een combinatie van op setTimeout gebaseerde functies (of, indien beschikbaar, requestAnimationFrame) om te achterhalen met welke snelheid u scrollt wanneer u de sleephendel loslaat, wordt gebruikt om een startende "velocity" te definiëren, die vervolgens in de loop van de tijd afneemt op basis van een versnelling functioneren totdat het element stopt.
Voor een idee van hoe Easing-functies er in de loop van de tijd uitzien, neem een kijkje op easings.net, een easing cheat sheet. In het bijzonder zou een kinetische scroll starten bij zijn hoogste snelheid en in de loop van de tijd langzamer worden, dus een kubusvrije uitloopfunctie zou kunnen worden gebruikt. Als u meer wilt weten over hoe easing werkt, bekijk dan dit artikel, dat is gebaseerd op ActionScript, maar eenvoudig kan worden vertaald naar JavaScript.
Een goede oefening is na te denken over hoe verschillende versnellingsfuncties van toepassing kunnen zijn. Een stuiterende bal zou bijvoorbeeld een stuiterende functie zijn. Maar waar moet een easy-in, easy-out-functie voor worden gebruikt? Misschien als u een bal simuleert die naar beneden rolt en een heuvel oploopt; de snelheid op de top van een heuvel zou langzaam zijn, dan het snelste aan de onderkant, dan langzaam richting de top van de tweede heuvel.
De zoekfunctie (die op meerdere pagina's van de site aanwezig is) werkt via JavaScript en JSON (bekijk dit JSON-antwoord bij het zoeken naar de term "film", evenals de bijbehorende indexpagina). Het is ook afhankelijk van een element met vaste breedte dat de eigenschap scrollLeft animeert.
De voettekst heeft een net klein paasei; klikken op de scissor-reeks (die drie verschillende "schaarposities" heeft die zijn ingeschakeld door klasseveranderingen) animeert de schaar over het scherm;
Klik er drie keer op, en het "snijdt" de voettekst van de onderkant van de pagina, en onthult een raster met vierkanten (wat een leeg canvas van Photoshop impliceert). Dit alles wordt gedaan met redelijk eenvoudige jQuery-animaties en callbacks, en wordt stilistisch gevoed met CSS-klassen en jQuery inline-stijlverklaringen.
Hoewel de Kickstarter Team-pagina momenteel geen mediaquery's gebruikt voor responsief ontwerp, maken ze voorzieningen voor de toegankelijkheid van touch-apparaten. Het is mogelijk dat Kickstarter een iOS-app ontwikkelt, gebaseerd op de ervaring van het team en GitHub-opslagplaatsen. Ze maken ook een voorziening door Zepto in plaats van jQuery voorwaardelijk te gebruiken.
Omdat niemand perfect is ...
De belangrijkste kritiek die we kunnen bieden, gaat over de aanwezigheid van vier CSS-bestanden. Het splitsen van CSS in vier afzonderlijke bestanden verhoogt het aantal HTTP-verzoeken, dat moet worden vermeden; er zijn echter meerdere mogelijke redenen waarom het Kickstarter-team besloot dit te doen. Ze hebben waarschijnlijk goede redenen, gelet op de maatregelen die ze hebben genomen met betrekking tot optimalisatie anders; in het bijzonder hadden ze iets als Bless CSS kunnen gebruiken. IE staat alleen een bepaald aantal selectors per CSS-bestand toe; Zegen CSS telt automatisch je selectors en verdeelt je CSS-bestanden dienovereenkomstig als ze de limiet overschrijden. Een andere mogelijke reden is om te voorkomen dat op andere plaatsen onnodige code wordt geladen; het kan bijvoorbeeld voorkomen dat de minst gebruikte selectors (over de site) eindigen in het 4e CSS-bestand, en dus kunnen alle vier de bestanden in zeer weinig gevallen worden geladen.
Responsief ontwerp via het gebruik van mediaquery's zou leuk zijn om te zien, maar het kan zijn dat Kickstarter zijn publiek verdeelt en desktopbezoeken aanmoedigt op basis van een aantal van hun (blijkbaar uitgebreide) gegevensverzameling en -analyse. Het kan ook zo zijn dat Kickstarter liever investeert in een native app, maar dat weten we nog niet zeker..
De laatste kritiek die we hebben is simpel: wie zijn de teamleden? Natuurlijk hebben we de namen, maar ik weet niet welke persoon met welke naam correspondeert. Het zou interessant zijn geweest om de namen op een of andere manier te markeren als je bijvoorbeeld de naam van een teamlid omzeilt. Een andere eenvoudige oplossing zou zijn om te zeggen dat de mensen worden vermeld in "volgorde van uiterlijk".
Dit kan echter ook een specifieke beslissing van Kickstarter zijn geweest om de privacy van de individuele teamleden te beschermen. Als zelfs een teamlid niet geïdentificeerd wil worden, is het de juiste keuze om niet te identificeren ieder van de teamleden. Het kan ook een bericht zijn dat Kickstarter wil uitdragen, dat dit team een enkele eenheid is; dit kan echter beter worden gediend door de namen helemaal niet te tonen.
De Kickstarter Team-pagina heeft zeer positieve feedback ontvangen van de ontwerpgemeenschap en we kunnen op veel manieren van deze pagina leren. In het bijzonder moeten we het feit wegnemen dat het combineren van een paar eenvoudige ideeën op een nieuwe manier (zoals een inhoudscroller en video) kan leiden tot een aantal zeer interessante en meeslepende inhoudgestuurde interacties. Deze pagina gebruikt niets dat bijzonder "meeslepend" of gecompliceerd is, maar het trekt onze interesse en houdt het vast. De inhoud wordt opnieuw op een voetstuk geplaatst en gebruikers worden uitgenodigd om die inhoud op een leuke maar eenvoudige manier te verkennen.
Wat merk je nog meer op de Kickstarter Team-pagina? Zijn er andere, even interessante pagina's die je op Kickstarter hebt gevonden? Wat vindt u van hun beslissing om op media-vraag gebaseerde responsieve oplossingen te vermijden? Laat het ons weten in de comments!
