Inhoud
- Ontwerpen voor het onbekende
- Een pragmatische benadering van design
- Lay-out-agnostisch worden
- Geleidelijk coderen
- Duiken in de mark-up
Het lijkt erop dat iedereen het tegenwoordig over responsive webdesign heeft, en terecht; naarmate het aantal apparaten met internettoegang blijft groeien - elk met verschillende mogelijkheden en functies - is het niet langer verstandig om websites met een vaste breedte te bouwen.
De waarheid is dat het nooit was. Toch werd het tot nu toe als best practice beschouwd om ervaringen te ontwerpen die een aantal aannames deden, of het nu ging om schermresolutie, bandbreedte of invoermethode. Als je ooit een 960px brede website hebt ontworpen en deze alleen op de kleine netbook van een vriend kunt bekijken (en ja, ik schrijf hier uit pijnlijke ervaring), dan begrijp je waarom dit geen bijzonder slimme aanpak was. Nu smartphones en tablets in de mix zijn gegooid, is het duidelijk dat onze traditionele methoden niet langer geschikt zijn voor het beoogde doel.
Gelukkig betekent de komst van CSS-mediaquery's en een groeiende erkenning dat internet een medium op zich is, dat we de ware aard van het platform beginnen te omarmen en accepteren dat de universaliteit ervan een sterkte is, geen zwakte.
De komende vijf dagen zal ik je door een techniek leiden die dit feit erkent: responsief webdesign. Dit werd ontwikkeld door Ethan Marcotte en combineert vloeiende lay-outs, flexibele afbeeldingen en mediaquery's om ons te helpen sites te bouwen die zich gracieus aanpassen aan elke omgeving die ze tegenkomen.
Ik zal deze aanpak demonstreren door u te laten zien hoe u een eenvoudige mediagalerij kunt bouwen. In mijn voorbeelden ga ik een kleine website maken om een recente roadtrip te documenteren die ik door de Verenigde Staten heb gemaakt, maar voel je vrij om de code en het ontwerp aan te passen aan je eigen behoeften.
Ontwerpen voor het onbekende
Een groot deel van deze tutorial zal zich concentreren op het ontwikkelingsaspect van responsive design. Maar laten we, voordat we in een code ingaan, even nadenken over hoe we een website kunnen ontwerpen die mogelijk oneindig veel lay-outs heeft.
Nu heb ik het geluk dat ik interfaces kan ontwerpen en ontwikkel de frontend-code die ze echt maakt. Dit is natuurlijk geen unieke vaardigheid - als je voor jezelf werkt, ben je waarschijnlijk hetzelfde. Maar het is zeker een voordeel om te begrijpen hoe inhoud kan worden aangepast en opnieuw kan worden geplaatst bij het maken van vloeiende ontwerpen.
Ik werk ook als onderdeel van een groter team waar mijn rol meer gespecialiseerd is. In een dergelijke omgeving kan de visuele ontwerper zich uitsluitend concentreren op het vertalen van wireframes naar aantrekkelijke, boeiende (afgetekende, pixel-perfecte) composities. En het is niet ongebruikelijk dat ontwikkelaars zich afzonderlijk bevinden en deze lay-outs vertalen naar gestroomlijnde en efficiënte markeringen en CSS.
Dergelijke lineaire en gescheiden workflows worden echter snel afgebroken zodra we beginnen te evalueren hoe ontwerpen zich zullen aanpassen aan verschillende omgevingen. Net als bij elke nieuwe tool of technologie, moeten we ook nadenken over meer collaboratieve en flexibele manieren van werken. Veel van de lastigste problemen die u tegenkomt bij het ontwerpen van responsieve websites kunnen eenvoudig worden opgelost door middel van conversatie, experimenten en iteratie.
Een pragmatische benadering van design
Dat wil niet zeggen dat er geen ruimte is voor ontwerpers om na te denken over hoe een ontwerp kan werken buiten de beperkingen van een bepaald apparaat.
Bij Clearleft initiëren we visueel ontwerp vanuit het perspectief van de desktop. We beginnen met het definiëren van een overkoepelende ontwerptaal en visuele esthetiek, waarbij we aanvankelijke verkenningen vaak baseren op een kernstuk van de inhoud. Als we bijvoorbeeld een voedselsite ontwerpen, beginnen we met een receptenpagina; voor een nieuwssite, een verhaalpagina.
Dit is niet alleen een belangrijke pagina op de site, maar het bevat waarschijnlijk ook voldoende gestructureerde inhoud om een typografisch palet op te bouwen. We zullen ook nadenken over hoe de lay-out kan worden aangepast, ook al zit het in dit stadium gewoon in ons achterhoofd.
Een handige manier om een ontwerp te testen, is door zo'n pagina te nemen en deze aan te passen voor een smaller (~ 320px breed) scherm. U zult waarschijnlijk ontdekken dat sommige aspecten van het ontwerp opnieuw moeten worden overwogen om ze op deze breedte te laten werken. Hier zijn enkele voorbeelden:
- Typografie: Grote koppen kunnen goed werken op bredere lay-outs, maar op kleinere schermen kunnen ze veel verticale ruimte innemen en daarom extra scrollen vereisen. Als lijnlengtes veranderen, moet u ook rekening houden met lijnhoogtes en andere typografische behandelingen.
- Links: Hoe werkt uw ontwerp op touchscreen-apparaten? Hoewel we nog geen gemakkelijke manier hebben om deze te detecteren (wat betekent dat we bij alle aspecten van ons ontwerp rekening moeten houden met aanraking), kan het ontwerpen voor een smaller scherm ons de mogelijkheid geven om na te denken over doelgebieden voor links en andere interactieve elementen. . De iOS-richtlijnen bevelen aan dat deze minimaal 44 pixels / punten in het vierkant zijn, wat een goed cijfer is om naar te streven.
- Navigatie: Dit is waarschijnlijk het meest lastige onderdeel van elk responsief ontwerp, vooral als uw site veel secties en een diepe hiërarchie heeft. Brad Frost heeft een samenvatting geschreven van enkele verschillende benaderingen van navigatie die momenteel worden overwogen.
- Overbodige inhoud: Is bepaalde inhoud niet vereist? Moet andere inhoud alleen in bepaalde scenario's worden getoond? Ik ben er geen voorstander van om inhoud te verbergen op basis van het apparaat dat een gebruiker toevallig gebruikt, maar technieken zoals voorwaardelijk laden (die we later deze week zullen bekijken) kunnen ons helpen kleinere pagina's weer te geven die alleen aanvullende inhoud laden wanneer dat nodig is.
Door twee contrasterende lay-outs te ontwerpen, wordt het idee versterkt dat een ontwerp zich zal aanpassen, terwijl potentiële valstrikken al vroeg worden gladgestreken. Hoewel dit klinkt als een verdubbeling van het werk, moet u er rekening mee houden dat we niet elke pagina tot op de pixel nauwkeurig ontwerpen. In plaats daarvan richten we ons op het bouwen van een schaalbare ontwerptaal: een taal die zal evolueren naarmate we deze in code gaan implementeren, en een taal die is gebaseerd op afzonderlijke modules en componenten.
Lay-out-agnostisch worden
Het is niet verwonderlijk dat voor een branche die het web van oudsher als drukwerk heeft behandeld, lay-outs met een vaste breedte doordrongen zijn van veel van de producten die we produceren. Terwijl we beginnen met ontwerpen voor een aanpasbaar medium, worden er nieuwe benaderingen overwogen die ons in staat stellen problemen op te lossen en ideeën te communiceren, terwijl we de fluïde aard van het medium erkennen. Hier zijn een paar van mijn favorieten:
- Paginabeschrijvingsdiagrammen: Hoewel wireframes vaak lay-out impliceren (en dus een bepaald type apparaat aannemen), verwijderen paginabeschrijvingsdiagrammen deze aanname en beschrijven in plaats daarvan de afzonderlijke componenten, gerangschikt in het document in termen van prioriteit.
- Stijltegels: Bij het communiceren van ontwerpideeën met klanten, kunnen we merken dat we ‘schilderijen van websites’ presenteren. Als we niet oppassen, zullen klanten terecht vragen om concepten te zien die laten zien hoe een ontwerp er ook op andere apparaten uit zal zien. Dit kan ons in een onhoudbare situatie dwingen om meerdere pagina's voor meerdere apparaten te produceren. Samantha Warren heeft over dit probleem nagedacht en stijltegels bedacht. Deze zitten ergens tussen een moodboard (maar minder vaag) en volledig gerealiseerde composities (maar minder nauwkeurig), en helpen ons typografie, knopstijlen en masthead-behandelingen te communiceren. Ze moedigen ook een meer volwassen niveau van discussie met onze klanten aan.
- Mobilify-ontwerpspel: Deze oefening kan heel goed werken tijdens gezamenlijke ontwerpworkshops. In deze oefening schrijft iedereen op Post-it notities de elementen op die op een bepaalde pagina kunnen voorkomen. Deze worden vervolgens in volgorde van belangrijkheid aan de muur geplakt, alsof ze gelineariseerd lijken op een mobiele telefoon. De resulterende discussie kan enkele verrassende conclusies opleveren. U kunt zich bijvoorbeeld realiseren dat navigatie niet het belangrijkste onderdeel van de pagina is. Dit zou kunnen volgen op het ontwerp, waar een link voor overslaan bovenaan de pagina naar de navigatie in de voettekst verwijst.
Er is natuurlijk nog ruimte voor de tools die we al gebruiken, maar bij het ontwerpen van een website in grote lijnen moeten we er rekening mee houden dat de lay-out niet meer bekend is.
Geleidelijk coderen
Gelukkig hoeven we ons geen zorgen te maken over het visuele ontwerp in het voorbeeld waar we aan werken, want het harde werk is al voor ons gedaan! In plaats daarvan kunnen we ons concentreren op het coderen van ons ontwerp in een volledig responsieve website.
Nog een ding voordat we beginnen. Het is belangrijk om een basisprincipe te onthouden van het medium waarmee we werken: universaliteit. Dat betekent niet alleen bouwen voor de web-enabled apparaten van vandaag, maar ook zorgen voor compatibiliteit met die van gisteren en morgen. John Allsopp beschreef waarom dit principe belangrijk is in zijn post The Next 6 Billion:
"De volgende zes miljard zijn kinderen op het platteland van India, Afrika, China, waar de toegang tot stroom en netwerken af en toe kan zijn. Het is iemand op Sumatra met een tien jaar oude Wintel-box. Het zijn mensen die honderden verschillende talen spreken, met tientallen verschillende schrijfsystemen. Het zijn mensen die als eersten in hun familie kunnen lezen en schrijven. Het zijn de 20 procent van de mensen wereldwijd die niet kunnen lezen of schrijven. Toch.’
We kunnen ons begrip van het web traceren door te kijken naar de verschillende modes (bij gebrek aan een beter woord) die in ons beroep hebben plaatsgevonden: webstandaarden, toegankelijkheid, onopvallend JavaScript… het zijn allemaal varianten op hetzelfde thema: progressieve verbetering. Hetzelfde geldt voor responsive webdesign. Om een werkelijk responsive website is om een site te bouwen die niet alleen achterwaarts compatibel is, maar ook toekomstvriendelijk.
Duiken in de mark-up
Oké, genoeg van de inleiding, het is tijd om een teksteditor te openen.Onze ontwerper heeft ons een desktopgeoriënteerd ontwerp gegeven en is zo vriendelijk geweest om voorbeelden te geven van hoe dit ook in een smallere viewport zou kunnen verschijnen.
Het is misschien verleidelijk om deze afzonderlijk te coderen, maar ik ga een andere benadering voorstellen. Door de afzonderlijke componenten - of patronen - waaruit het ontwerp bestaat op één pagina te plaatsen, kunnen we een patroonportfolio samenstellen. Dit stelt ons in staat om componenten te ontwikkelen buiten de grenzen van elke pagina-indeling, en geeft ons iets om later naar te verwijzen voor eventuele regressietesten. Laten we de eerste opmaak op een paar verschillende apparaten bekijken:
Bekijk ons portfolio met gemarkeerde patronen
Nou, ik zal verdoemd zijn - we hebben al een responsieve website! Onze inhoud past zich aan de beperkingen van elk apparaat aan, of dat nu een mooie nieuwe iPad is of een afgedankte featurephones. Het werkt zelfs in een browser met alleen tekst, zoals Lynx.
Dankzij de onderliggende principes van universaliteit is het web dat wel reageert standaard. Dat is geweldig, maar het betekent ook dat alles wat we vanaf nu met de code doen, dit native aanpassingsvermogen in gevaar kan brengen.
Morgen: We gaan voorzichtig te werk en beginnen het eerste aspect van responsief ontwerp toe te passen: typografie en vloeiende rasters.
