God responsiv webbdesign, av sin natur, går obemärkt till de som konsumerar innehåll på nätet. Så när någon frågar efter en ny webbplats, är de ofta helt omedveten om konceptet, trots att de upplever det dagligen. Och ändå är responsiv webbdesign erkänd som standard praxis i hela branschen.
Att bygga responsiva webbplatser har förändrat våra processer, från att skapa mockups av kompletta sidor, till byggbibliotek av återanvändbara komponenter och layouter.
Layouten är innehållsdriven och stilen är varumärkesdriven
Nyligen har vi kontaktats av en befintlig kund för att på ett ändamålsenligt sätt omorganisera deras hemsida. Vi hade tidigare arbetat med dem med en stel vattenfallsprocess. Förflyttning till ett smidigt arbetsflöde kunde vi omhänderta förändringar när som helst i projektet.
Under hela processen följde vi filosofin att layout är innehållsdriven och stilen är varumärkesdriven.
Specifikationsdokument fungerar bra för att lista ut alla funktioner som en webbplats måste ha. Men är det verkligen vad kunden behöver? Det är mycket svårt att visualisera dessa funktioner på plats. Resultatet är sålunda att specifikationsdokument ofta blir till uppblåsta önskelistor. Detta hjälper inte kunden, designers eller den slutliga webbplatsen.
I stället för specifikationsdokument valde vi att använda trådramar. Det första steget i projektet var att skapa trådramar för varje sida. Det här låter som överkill, men trådramarna ledde till tidiga diskussioner om innehållet och funktionerna för varje sida. Vi fann att funktioner som vi aldrig övervägde tidigare tillsattes, medan många avlägsnades.
Wire-frames gav oss en klar, visuell representation av hur innehåll och funktionalitet bör prioriteras på varje sida. Dessa trådramar blev sedan en referenspunkt som ersatte ett specifikationsdokument.
Key takeaway: Produktion av trådramar i stället för specifikationsdokument fokuserar alla på kärnfunktionerna och vikten av innehåll.
Revidering av trådramarna gör att vi kan bilda en lista över alla vanliga komponenter. På en enda sida kommer det att finnas dussintals små sektioner på varje sida som är mycket lika. Dessa komponenter kan samlas in i en uttömmande lista som kommer att användas senare.
Det här steget har tre huvudsakliga fördelar:
Key takeaway: planering hur man närmar sig framkanten av ett projekt är viktigt för att skapa en underhållbar, magert kodbas.
Mönsterbibliotek är en samling gemensamma element som används på en webbplats. Genom att fokusera front-end-utvecklingen på att bygga komponenter som inte är beroende av sidor kan vi minska koden överhead och förbättra konsistensen.
Med hjälp av listan över komponenter vi samlade under revisionssteget kan vi strukturera vår Sass till en hanterbar samling av filer.
Vi har använt mönsterbibliotek på några få projekt men har alltid kämpat med namngivna konventioner, särskilt mappstrukturen: vart ställer du in dina stilar för denna musikspelare, i komponenter eller i partiklar?
Tidigare hade vi använt terminologi som partials och komponenter för att organisera våra Sass-filer. Även om dessa verkar som helt legitima namngivningskonventioner, är de öppna för tolkning. När det finns flera utvecklare som arbetar med ett projekt, leder organisationen av kodbasen till tolkning leder till oorganiserad CSS.
BEM (Block, Element, Modifier), ger oss en gemensam konvention att följa, och skapar en förståelse mellan front-end-utvecklare. Den gamla vägen var kvar för enskilda utvecklare att komma med klassnamn som var alltför höga för att få någon mening från. Lyckligtvis hade vi tur att se Brad Frost tala om sitt mönsterbibliotek på Upfront konferens i Manchester. Pattern Lab låter terminologi från kemi för att beskriva de komponenter som utgör biblioteket. Genom att använda atomer, molekyler och organismer för att beskriva skillnaderna mellan komponenter på en sida, förklaras konceptet till utvecklare som är nya för projektet.
Atomdesign är för användargränssnitt: http://t.co/eEZSYeK5VF Du kan tillämpa atomdesign till alla användargränssnitt, som Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10 juli 2015
I naturen är atomer den minsta beteckningen (såvida vi inte dyker i kvarker och elektroner). I webbutveckling är atomer de mest grundläggande elementen i HTML. För alla ändamål gör de inte mycket på egen hand. Dessa inkluderar rubriker, stycken, ingångar, knappar, listor ... Du får idén.
Dessa är nästa lager upp. I kemi består molekyler av atomer, och detsamma gäller strukturen hos CSS. Molekyler är komponenter på webbplatsen som använder atomer för att bilda dem.
Ett bra exempel på en molekyl är en sökruta. Detta innehåller 3 atomer: en etikett, ingång och knapp. Molekylskiktet börjar bilda några av de element som vi kan använda på hemsidan. Det är viktigt att göra alla dessa molekyler skalbar. De ska utformas med idén att de skulle kunna användas var som helst på webbplatsen. Vårt ultimata mål att göra CSS så flexibel och återanvändbar som möjligt.
Som namnet antyder är organismer grupperingar av molekyler. Några exempel på dessa inkluderar en rubrik, sidfot eller produktlista.
Om vi tar ett exempel på en rubrik, skulle det inkludera en logotyp, sökning och navigering. Dessa skapades alla som molekyler och kombineras för att bilda en huvudorganisme.
Det här är där biokemi analogi slutar. Som Brad säger, "ta sig in på språk som ger större mening till kunder och slutlig produktion" . Mallar är limet på en webbplats. Dessa kombinerar alla de organismer vi har skapat i en layout som kan tillämpas på en sida på webbplatsen.
Ett exempel kan vara en blogglista. Den här mallen skulle innehålla en rubrik, sidfot, en lista med bloggartiklar och en sidofält. Mallar är vanligtvis strukturella, som bara innehåller layouten.
Det sista avsnittet är sidor. Här kan du testa mallarna med verkliga data. Sidor är specifika fall av en mall. Denna del är viktig eftersom det gör det möjligt för oss att se hur framgångsrika atomer, molekyler, organismer och mallar har varit.
Det är oundvikligt att när man bygger webbplatsen kommer vissa scenarier att saknas. Det klassiska exemplet är långa titlar eller catering för olika valutor och språk.
Viktig takeaway: Naming conventions matter. Layout CSS skapar en ren kodbas för att fungera från så liten som möjligt.
Att designa mönster är svårt. Du kan inte designa ett isolerat mönster som en nyhet och förvänta dig att den passar med resten av sidan. Hur vi bygger webbplatser och hur vi utformar dem skiljer sig åt.
Designen kommer sannolikt att förändras oavsett om vi får sign-off ... Sign-off blev ett irrelevant steg i processen som bara satte press på båda sidor
Vi använde Photoshop för att skapa mockups av trådramarna med dessa stylade komponenter på plats. När vi var nöjda med utseende och känsla av mönster som vi flyttade för att isolera varje komponent. Detta gjorde det möjligt för oss att se till att varje komponent var tillräckligt flexibel för att fungera var som helst på webbplatsen.
Vi var väldigt medvetna om att vi inte fick sign-off på något designarbete. Design sign-off skapar en barriär där designern känner sig pressad för att skapa något som kommer att ställas in i sten. Designen kommer sannolikt att förändras oavsett om vi blir avstängda eller inte. Generellt är vi glada att kunna ta emot eventuella förändringar när som helst på projektets tidslinje. Sign-off blev ett irrelevant steg i processen som bara satte press på båda sidor till nackdel för förhållandet.
Att veta när man ska flytta från Photoshop till kod är viktigt. Detta steg är mycket tidigare än vad vi var vana av av två skäl:
I stället för att spendera extra tid i Photoshop valde vi att investera tiden i kod. Om vi skulle kunna perfekta något, borde det vara koden, den bit som faktiskt kommer att användas och ses av alla webbplatsanvändare. För oss var Photoshop ett verktyg för att skapa en designstil som kan användas över hela webbplatsen.
Design handlar mycket om samarbete mellan alla på laget. Mockups var fortfarande en väldigt viktig del av processen, vilket hjälper kunden att visualisera hur webbplatsen skulle se ut. Om vi var alla nöjda med den allmänna riktningen av designen skulle vi flytta den till kod. Vi spenderade sällan tid bakåt och framåt och ändrade till Photoshop-dokument.
Key takeaway: Photoshop är ett bra verktyg för att skapa designkoncept. Att flytta till kod så snart som möjligt är viktigt. Perfekt det i kod, inte Photoshop.
Skönheten i detta arbetsflöde är att det finns så många ställen att granska och förbättra webbplatsen.
Det är viktigt att notera att dessa är lösa steg i vår projektprocess. Om vi behöver något nytt under projektet, behandlar vi det som en fristående, modulär komponent som kan släppas in på webbplatsen och anta webbplatsens designtema.
Var och en av dessa steg erbjuder en punkt där vi kan granska vårt arbete hittills. Det möjliggör också en ny uppsättning ögon för att se saker från ett annat perspektiv.
Under några av dessa steg kan vi konstatera att vissa delar inte fungerar lika bra som förväntat. Detta är okej. Det är faktiskt bra. Fånga dålig användbarhet tidigt är nyckeln till en framgångsrik webbplats. Att gå tillbaka och inrama dessa delar av webbplatsen gör projektet bättre när det går live.
Key takeaway: Var inte rädd för att gå tillbaka till början om något behöver förbättras. Att fånga dessa tidiga kommer att göra projektet bättre när det går live.
Vi tillbringade dagar som arbetade tillsammans för att säkerställa att alla delar av webbplatsen var färdiga till en hög standard. Vi testade så många scenarier som möjligt, vilket gjorde att surfupplevelsen var konsekvent.
När uppgifterna finns på webbplatsen kan vi fullt ut testa webbplatsen. Det är ofta för lätt att sätta ett projekt live utan att testa helt. Vi kan kontrollera hastighet, enkel navigering och viktigast av inköpsflödet.
Alla nämner Apple för att vara perfectionists men jag är säker på att deras första försök var långt ifrån perfekt. Det tar tid och engagemang att göra de sista förbättringarna för att ge oss de produkter vi älskar idag. Med hjälp av vårt enhetslabb, som innehåller de flesta av de populära enheterna och plattformarna, kunde vi se till att erfarenheten optimerades på så många av de senaste plattformarna och skärmstorleken som möjligt.
Att lära av varje projekt är viktigt så att vi kontinuerligt kan förbättra processer som leder till bättre webbplatser.
Projektet såg vår egen egen mönsterbibliotek som uppmuntrar till konsekvens mellan projekt. När vi arbetar i en byrå kan vi ha tiotals projekt som för närvarande är i utveckling samtidigt. Möjligheten för någon att arbeta på något projekt är viktigt.
Att skapa en bas som vi alla kan arbeta med hjälper till att bidra till detta mål.
Webbplatsens prestanda beaktades endast i slutet av projektet. En framgångsrik, mottaglig webbplats behöver vara smal och snabb. Det stora utbudet av enheter och deras kapacitet varierar kraftigt från helt nya Mac-datorer till gamla smartphones. När man bygger en media-rik webbplats kan det vara mycket svårt att hantera prestanda, speciellt när man efterhand försöker förbättra den.
Vid Upfront Conference i Manchester såg vi Yesenia Perez Cruz tala om att överväga prestanda i varje skede av ett projekt, inklusive design. I efterhand är detta något vi borde ha genomfört. Som ett team av flera designers, utvecklare och front-end-utvecklare, som har hanterat den övergripande storleken och prestanda (särskilt den uppfattade prestanda) borde ha varit en större prioritet.
Allt på en sida har en kostnad för prestanda. Prioritera vad som är viktigt säkerställer att webbplatsen inte bara är snabb men tillgänglig för flera enheter. På vissa äldre enheter fann vi att webbplatsen kraschade inte bara webbläsaren, utan hela enheten. Försök att påskynda webbplatsen med retroaktiv betydelse att vi inte kunde göra hemsidan så snabbt som det kunde ha varit.
Nästa gång vi kommer att se till att prestanda inblandas i alla skeden av processen, så är det inte en eftertanke.