Hvordan de gjorde det Bygg Windows

I dag skal vi dykke inn på Build Windows-siden og se på de praktiske kodefilosofiene, verktøyene og strategiene som brukes av denne svært trafikkfulle, høyt anerkjente konferanse destinasjonssiden. Vi kommer inn i det nitty gritty, men vi vil også dekke noen ting fra et miles høyt perspektiv.


Hvem er ansvarlig?

Build Windows-området var et samarbeid mellom tre-personers Paravel-team og Windows Nishant Kothary. (Ta en titt på Trent Walton av Paravels innlegg, det offisielle innlegget fra Paravel, og Nishants innlegg om prosjektet.)


Et imponerende førsteinntrykk

Turnaround for front-end siden av prosjektet var ca 10 dager.


metodikk

Som innleggene fra laget antyder, ble deres primære metodikk hentet designet i nettleseren så fort som mulig. For Paravel er dette helt avgjørende, så mye av arbeidet deres dreier seg om media-spørringsbasert responsiv design.

Iterasjonsprosessen var inkrementell og rask; to personer fokuserte på layout og innhold, mens de to andre fokuserte på front-end-koden.


verktøysett

Bygg Windows-nettstedet er avhengig av noen viktige verktøy og biblioteker.

JavaScript-verktøy

  • Modernizr bruker denne egendefinerte bygningen
  • jQuery - Brukt gjennom hoved script.js-filen
  • Lea Verou er PrefixFree.js - Brukes over hele CSS til å automatisk legge til leverandør-prefikser til animasjoner / overganger og andre CSS-egenskaper som krever dem
  • Responsiveslides.js - Brukes til "Meet the Family" bilde fading rotator
  • Webtrends.js - Analytics (notat: IKKE Google Analytics)
  • En fantastisk ascii-fil - Dette kan tjene en annen hensikt, men ingen som vi kan se annet enn å være fantastisk

Det er alt i detaljene http://www.buildwindows.com/javascript/dev.js

CSS verktøy, etc.

  • Grunnleggende tilbakestilling - Vanligvis sett over hele nettet
  • @ Font-face - brukes til å importere Windows Segoe UI-skrifttypen

Mye av oppslag og styling ser veldig ut som HTML5 Boilerplate anbefalinger.


Strategi for Responsive Design

BuildWindows.com gjør omfattende bruk av medieforespørsler, med 8 totalt bruddpunkter:

  • 480px
  • 680 piksler
  • 780px
  • 900px
  • 1280px
  • 1500px
  • 1700px
  • 1950px

De største endringene skjer mellom 680px og 1280px. Over 1280px, de viktigste endringene som skjer, er seksjonskryssing og marginalendringer, og viktigst av alt, skriftstørrelsesjusteringer (opptil skriftstørrelse: 200%;). "Metrofliser" står for en stor del av CSS; Spesielt tilpasser disse flisene fra 4 til 8 kolonner gjennom mediene.

Grasiøs nedbrytning

I alt 15 ".lt-ie9" regler er til stede, hvorav 7 er for ".lt-ie8". Generelt er disse margin-, polstring-, bredde- og skrifttyperettelser, samt en regel for ".button" bakgrunnsfarge.


interaksjoner

Det er tre hovedanimasjoner som forekommer, alt oppnådd med CSS-overganger og animasjoner utløst ved å se rullehendelsen og legge til klasser i "in-view" -deler. For eksempel:

 funksjon isScrolledIntoView (elem) var docViewTop = $ (vindu) .scrollTop (); var docViewBottom = docViewTop + $ (vindu) .height (); var elemTop = $ (elem) .offset (). topp * 1,10; // Legg til klasse hvis 10% i visningsport. returnere (docViewBottom> = elemTop);  funksjon addInView () (hvis (isScrolledIntoView ('metro-fliser')) if (! $ ('. metro-fliser'). harClass ('in-view')) ) .addClass ('in-view'). animate ('opacity': 1);  // ... $ (vindu) .scroll (funksjon () addInView (););

Dette, litt endret fra script.js-filen, viser den primære funksjonen som ser på rullingen og legger til klasser tilsvarende. Vi kan da se for eksempel den nederste "nedtelling" -animasjonen som er definert i css.

 .nedtelling margin: 0 auto 0; posisjon: absolutt; bredde: 100%; venstre: 0; høyre: 0; margin-topp: 20em; overgang: margin 0.9s let-in;  .no-js. countdown margin-top: 1em;  .countdown.in-view margin-top: 1em; 

Et viktig notat her er ".no-js" -klassen, som brukes på kroppsklassen i oppslaget. Modernizr fjerner denne klassen når den kjører, men hvis Modernizr aldri kjører, vet vi at nettleserens JavaScript er slått av, og derfor kan vi ikke utløse animasjonen for å få ned nedtellingen. I stedet viser vi det som standard uten animasjonen.

Lignende animasjoner er definert for fliser og logoer, og Responsiveslides bildefader startes når den delen er rullet inn i visning. "Tunnelfliser" har også fliser definert for den "aktive" pseudovelgeren, som bruker en overgang på forvandle eiendom. ex:

 / * Tilt venstre * / .metro-fliser .tile: nth-of-type (4n-4) a: aktiv img transform: perspektiv (1000px) rotateY (-20deg); 

Tatt direkte fra http://www.buildwindows.com/css/style.css.

Unntak

Lagbygningen på dette nettstedet bestemte seg for å umiddelbart legge til "i-visning" -klassen til alle aktuelle seksjoner på DOM klar på en hvilken som helst iOS-enhet.

 $ (dokument) .ready (funksjon () hvis (navigator.userAgent.match (/ (iPhone | iPod | iPad) / i)) $ ('metro-fliser'). addClass ('in-view') .css ('opacity': 1); $ ('. egenskaper'). addClass ('in-view'). css ('opacity': 1); $ ('nedtelling'). css ('opacity': 1); $ (". rslides"). addClass ('in-view'). responsiveSlides (timeout: 3000););

Dette er mest sannsynlig en beslutning om å øke ytelsen og unngå scrollTop-problemer i Mobile Safari. Vanligvis utsender mobile nettlesere ikke en rullehendelse før rullen har kommet til et fullstendig stopp. Sjekk ut denne skrive om problemet og noen mulige løsninger: Uscroll Event Issues på Mobile Browsers.

De fleste av JavaScript i script.js er dedikert til å legge til disse klassene og oppdatere timeren på bunnen. Nedtellingen er satt til å bruke a serverTime og forteller brukeren, til minuttene, hvor mye tid som gjenstår til hendelsen begynner. Servertid er mye mer pålitelig, som brukerens dataklokke (hvilket JavaScript er Dato() funksjon bruker som standard) kan settes til noe.

Andre funksjoner er en skala bug fix for iOS og sub-pixel antialiasing på Mac Webkit.


Hva å lære

Bygg Windows-nettstedet har fått mye positiv anmeldelse fra samfunnet. Hva kan vi ta bort fra å vurdere dette nettstedet, og se hvordan det ble gjort fra grunnen opp?

Alle spill er av hvis du er erfaren. Faktisk fokuserer bevisst og "tar deg tid" vil faktisk skade ytelsen din hvis du er noen med stor erfaring i feltet ved hånden. - Nishant Kothary

Bygg raskt

Som Nishants innlegg om prosjektet indikerer, er det svært givende for erfarne utviklere og designere å stole på ditt første instinkt og raskt bygge og gradvis revidere et designprosjekt..

Bygg: Enkel, Grasiøs og Responsiv

Bygg Windows-området er veldig enkelt, og bruker en enkelt destinasjonsside som er avhengig av noen få store deler for å formidle en begrenset mengde informasjon og anspore en enkelt anrop til handling. Denne typen enkelhet gir mulighet for en solid og fokusert stemme og merkevare, ryggraden i enhver god design.

... vi designet, prototyped og bygget flertallet av nettstedet i nettleseren, slik at vi kunne sikre at nettstedshierarkiet og oppsettet var ideelt til alle skjermstørrelser. - Paravel

Siden nedgraderes grasiøst, slik at nettlesere som er gamle eller ikke har JavaScript, kan fortsatt hente den nødvendige informasjonen. Det blir også gradvis forbedret (CSS animasjoner brukes når det er mulig, for eksempel).

Nettstedet benytter også responsive designteknikker for å tillate tilgjengelighet over en rekke enheter uten å begrense "prime" -opplevelsen til en enkelt enhet.

Sterk fokus på type og innholdsramme

Mens nettstedet sysselsetter noen animasjon og oppførsel, innholdet og typografien er kongene i dette designet. Bildene og andre grafiske designelementer (som Reagan Rays illustrerte Seattle-skyline) støtter bare typografi og innholdsstrategier.


Microsofts humanistiske sansfigur, Segoe UI

Og mens du kanskje først tenker, er byggelogoen tekstfremstilt med Paravels egen fittext.js, er det faktisk bare en massiv gjennomsiktig .png; 1.700 px bred, men veier inn på en dårlig 13Kb.


kritikker

Fordi ingen er perfekt ...

optimalisering

Selv om nettstedet bruker mange "beste praksis", er det noen aspekter som kunne blitt ytterligere optimalisert, for eksempel sammenkobling og reduksjon av JavaScript-filer og CSS, bruken av sprites der det er mulig osv..

Nettstedet lider imidlertid ikke av disse bestemte problemene på noen signifikant måte, og laget har mest sannsynlig gjort de valgene de gjorde for å tillate en mer vedlikeholdbar kodebase. Utover dette, kan laget ha forventet at andre utviklere og designere ville se på kildekoden, og dermed forlot deler av den unminified.

Mindre bestøvelsesproblemer

Dette er i hovedsak en kritikk av bruken av bruker agent. Det bør være kjent for alle leserne i denne artikkelen at navigator.userAgent ikke er en pålitelig måte å oppdage hvilken nettleser noen bruker.

Dette nettstedet bruker imidlertid ikke og misbruker userAgent-nettleseren sniffing; de bruker den til to primære formål. Den første er å angi en CSS-regelen for anti-aliasing på Mac Webkit. Den andre er å umiddelbart legge til "i-visning" -klassen til iOS-enheter. Begge disse spesielle brukstilfeller er legitime, da det heller ikke kompromitterer innholdet tungt.

Noen av jQuery-baserte JavaScript er ikke så optimal som mulig:

 hvis (navigator.userAgent.match (/ (iPhone | iPod | iPad) / i)) $ ('. metro-fliser'). addClass ('in-view'). css ('opacity': 1) ; $ ('. egenskaper'). addClass ('in-view'). css ('opacity': 1); $ ('nedtelling'). addClass ('in-view'). css ('opacity': 1); $ (". rslides"). addClass ('in-view'). responsiveSlides (timeout: 3000); 

Kunne vært:

 hvis (navigator.userAgent.match (/ (iPhone | iPod | iPad) / i)) $ ('. metro-tiles, .properties, .countdown'). addClass ('in-view'). css opasitet ': 1); $ (". rslides"). addClass ('in-view'). responsiveSlides (timeout: 3000); 

Og addInView () funksjonen kan også optimaliseres på en rekke forskjellige måter. Når det er sagt, dette er nit-hakke bekymringer som sikkert flørter med overkroppen av over-engineering; Beslutningen kunne ha blitt gjort for å ignorere disse optimeringene av mange grunner:

  1. Gevinstene er ubetydelige
  2. Kode lesbarhet kan lide
  3. Den korte svingingen betyr sannsynligvis at prosjektet bedre kan dra nytte av mer fokusert oppmerksomhet på andre områder, for eksempel raffinering av hvert responsivt bruddpunkt med høyere presisjon og detalj

Konklusjon

Paravel og Nishant på Windows fulgte nøye med detaljer om dette prosjektet, til tross for kort tidslinjeutgift for prosjektet. Deres raske utviklingstilnærming og tillit til sine egne instinkter betalte seg i dette moderne design, langt fra Windows design av gamle.

Hva er noen innsikt du har fått ved å se gjennom dette nettstedet? Hvordan har du det med optimeringen? Hva med det store spekteret av responsive breakpoints? Gi oss beskjed nedenfor!