Goed responsief webontwerp, van nature, blijft onopgemerkt voor degenen die online content consumeren. Dus wanneer iemand om een nieuwe website vraagt, zijn ze vaak niet op de hoogte van het concept, ondanks dat ze het dagelijks ervaren. En toch wordt responsief websiteontwerp nu erkend als standaardpraktijk in de hele branche.
Het bouwen van responsieve websites heeft onze processen veranderd, van het maken van mockups van complete pagina's tot het bouwen van bibliotheken met herbruikbare componenten en lay-outs.
lay-out is inhoudsgestuurd en stijlen zijn merkgericht
Onlangs werden we benaderd door een bestaande klant om hun website responsief opnieuw te ontwerpen. We hadden eerder met hen samengewerkt met behulp van een rigide watervalproces. Op weg naar een flexibele workflow konden we op elk moment in het project verandering omarmen.
Gedurende het hele proces hebben we ons gehouden aan de filosofie dat lay-out inhoudsgestuurd is en dat stijlen merkgericht zijn.
Specificatiedocumenten werken geweldig om een lijst te maken van alle functionaliteit die een site nodig heeft. Maar is het echt wat de klant nodig heeft? Het is erg moeilijk om deze functies op hun plaats te visualiseren. Het resultaat is dus dat specificatiedocumenten vaak in opgeblazen wishlists veranderen. Dit helpt de klant, de ontwerpers of de uiteindelijke website niet.
In plaats van specificatiedocumenten hebben we ervoor gekozen om draadframes te gebruiken. De eerste stap van het project was het maken van draadframes voor elke pagina. Dit klinkt misschien als overdreven, maar de draadframes leidden tot vroege discussies over de inhoud en functies van elke pagina. We hebben ontdekt dat functies die we nooit eerder hebben beschouwd, zijn toegevoegd, terwijl er veel zijn verwijderd.
Draadframes gaven ons een duidelijke, visuele weergave van hoe inhoud en functionaliteit op elke pagina voorrang moesten krijgen. Deze draadframes werden toen een referentiepunt, ter vervanging van een specificatiedocument.
Belangrijkste afhaalmaaltijd: het produceren van draadframes in plaats van specificatiedocumenten richt iedereen op de kernfuncties en het belang van inhoud.
Door de draadframes te controleren, kunnen we een lijst met alle gangbare componenten vormen. Over een enkele site zijn er tientallen kleine secties op elke pagina die erg op elkaar lijken. Deze componenten kunnen worden samengevoegd in een volledige lijst die later zal worden gebruikt.
Deze fase heeft drie belangrijke voordelen:
Belangrijkste afhaalmaaltijd: het plannen van de front-end ontwikkeling van een project is belangrijk om een onderhoudbare, lean codebasis te creëren.
Patroonbibliotheken zijn een verzameling gemeenschappelijke elementen die op een website worden gebruikt. Door de front-end ontwikkeling toe te spitsen op componenten die niet afhankelijk zijn van pagina's, kunnen we de overhead van de code verminderen en de consistentie verbeteren.
Met behulp van de lijst met componenten die we tijdens de auditfase hebben verzameld, kunnen we onze Sass in een overzichtelijke verzameling bestanden structureren.
We hebben patroonbibliotheken gebruikt voor een paar projecten, maar hebben altijd moeite gehad met naamgevingsconventies, met name de mappenstructuur: waar plaats je je stijlen voor deze muziekspeler, in componenten of in gedeelten?
Eerder gebruikten we terminologie zoals partials en componenten om onze Sass-bestanden te ordenen. Hoewel dit volkomen legitieme naamgevingsconventies lijken, staan ze open voor interpretatie. Als er meerdere ontwikkelaars aan een project werken, leidt het achterlaten van de organisatie van de codebasis voor interpretatie tot ongeorganiseerde CSS.
BEM (Block, Element, Modifier) biedt ons een gemeenschappelijke conventie om te volgen en creëert een overeenkomst tussen front-end ontwikkelaars. De oude manier werd overgelaten aan individuele ontwikkelaars om klassennamen te bedenken die al te hoog waren om elke betekenis te achterhalen. Gelukkig hadden we het geluk om te zien Brad Frost spreek over zijn patroonbibliotheek in de Voorafgaande conferentie in Manchester. Pattern Lab geeft termen uit de chemie om de componenten te beschrijven die deel uitmaken van de bibliotheek. Het gebruik van atomen, moleculen en organismen om de verschillen tussen componenten op een pagina te beschrijven, helpt het concept uit te leggen aan ontwikkelaars die nieuw zijn in het project.
Atomic Design is voor gebruikersinterfaces: http://t.co/eEZSYeK5VF Je kunt atoomontwerp toepassen op elke gebruikersinterface, zoals Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10 juli 2015
In de natuur zijn atomen de kleinste denominatie (tenzij we ons verdiepen in quarks en elektronen). In webontwikkeling zijn atomen de meest elementaire elementen van HTML. Ze doen eigenlijk niet zoveel op zichzelf. Deze omvatten koppen, alinea's, ingangen, knoppen, lijsten ... Je snapt het.
Dit is de volgende laag omhoog. In de chemie zijn moleculen opgebouwd uit atomen, en hetzelfde geldt voor de structuur van CSS. Moleculen zijn componenten op de website die atomen gebruiken om ze te vormen.
Een goed voorbeeld van een molecuul is een zoekvak. Deze bevat 3 atomen: een label, invoer en knop. De molecuullaag begint enkele elementen te vormen die we op de website kunnen gebruiken. Het is belangrijk om al deze moleculen schaalbaar te maken. Ze moeten worden ontworpen met het idee dat ze overal op de site kunnen worden gebruikt. Ons uiteindelijke doel is om de CSS zo flexibel en herbruikbaar mogelijk te maken.
Zoals de naam al doet vermoeden, zijn organismen groeperingen van moleculen. Enkele voorbeelden hiervan zijn een koptekst, voettekst of lijst met producten.
Als we het voorbeeld van een header nemen, zou dit een logo, een zoekopdracht en navigatie omvatten. Deze werden allemaal gemaakt als moleculen en worden gecombineerd om een koporganisme te vormen.
Dit is waar de analogie van de biochemie eindigt. Zoals Brad zegt: "Begeef je in taal die logischer is voor klanten en uiteindelijke output" . Sjablonen zijn de lijm van een website. Deze combineren alle organismen die we hebben gemaakt in een lay-out die kan worden toegepast op een pagina op de website.
Een voorbeeld kan een blogvermelding zijn. Deze sjabloon bevat een koptekst, voettekst, een lijst met blogitems en een zijbalk. Sjablonen zijn over het algemeen structureel en bevatten alleen de lay-out.
Het laatste deel is pagina's. Hier kunt u de sjablonen testen met echte gegevens. Pagina's zijn specifieke exemplaren van een sjabloon. Dit deel is belangrijk omdat het ons laat zien hoe succesvol de atomen, moleculen, organismen en sjablonen zijn geweest.
Het is onvermijdelijk dat bij het bouwen van de website bepaalde scenario's worden gemist. Het klassieke voorbeeld is lange titels of catering voor verschillende valuta's en talen.
Belangrijkste afhaalmaaltijden: benamingsconventies zijn belangrijk. CSS in lagen maken maakt een schone codebase om vanaf te werken zo klein mogelijk.
Patronen ontwerpen is moeilijk. U kunt een geïsoleerd patroon zoals een nieuwsitem niet ontwerpen en verwachten dat het bij de rest van de pagina past. De manier waarop we websites bouwen en de manier waarop we ze ontwerpen, verschillen.
Ontwerpen zullen waarschijnlijk veranderen, ongeacht of we aftekenen ... Sign-off werd een niet-relevante stap in het proces dat alleen druk uitoefende op beide zijden
We gebruikten Photoshop om mockups van de draadframes te maken met deze gestileerde componenten op hun plaats. Toen we eenmaal tevreden waren met het uiterlijk van de ontwerpen, zijn we overgeschakeld naar het isoleren van elk onderdeel. Hierdoor konden we ervoor zorgen dat elk onderdeel flexibel genoeg was om overal op de website te werken.
We waren ons zeer bewust van het feit dat we geen ontwerpwerk konden doen. Design sign-off creëert een barrière waar de ontwerper zich onder druk gezet voelt om iets te maken dat in steen zal worden gezet. Ontwerpen zullen waarschijnlijk veranderen, ongeacht of we ondertekening krijgen of niet. Over het algemeen houden we rekening met eventuele wijzigingen op elk punt in de projecttijdlijn. Sign-off werd een niet-relevante stap in het proces dat alleen druk uitoefende op beide zijden ten nadele van de relatie.
Weten wanneer je moet verhuizen van Photoshop naar code is belangrijk. Deze stap is veel eerder dan we gewend waren om twee redenen:
In plaats van extra tijd door te brengen in Photoshop hebben we ervoor gekozen om de tijd in code te investeren. Als we iets perfectioneren, zou het de code moeten zijn, het bit dat daadwerkelijk door alle websitegebruikers zal worden gebruikt en gezien. Voor ons was Photoshop een hulpmiddel voor het maken van een ontwerpstijl die op de hele website kon worden gebruikt.
Design gaat veel meer over samenwerking tussen iedereen in het team. Mockups waren nog steeds een zeer belangrijk onderdeel van het proces en hielpen de klant om te visualiseren hoe de site er zou uitzien. Als we allemaal blij waren met de algemene richting van het ontwerp, zouden we het naar code verplaatsen. We hebben zelden de tijd genomen om heen en weer te gaan en het goed te doen met Photoshop-documenten.
Belangrijkste afhaalmaaltijd: Photoshop is een geweldig hulpmiddel voor het maken van ontwerpconcepten. Zo snel mogelijk naar de code gaan is belangrijk. Perfectioneer het in code, niet Photoshop.
Het mooie van deze workflow is dat er zoveel plaatsen zijn om de website te beoordelen en te verbeteren.
Het is belangrijk om op te merken dat dit losse stappen zijn in ons projectproces. Als we tijdens het project iets nieuws nodig hebben, zullen we het over het algemeen behandelen als een op zichzelf staande, modulaire component die op de website kan worden geplaatst en het ontwerpthema van de site kan aannemen.
Elk van deze stappen biedt een punt waarop we ons werk tot nu toe kunnen beoordelen. Het zorgt ook voor een nieuwe reeks ogen om dingen vanuit een ander perspectief te bekijken.
Tijdens deze fasen kunnen we merken dat sommige onderdelen niet zo goed werken als verwacht. Dit is oke. Het is zelfs goed. Vroegtijdig gebruik van slechte bruikbaarheid is de sleutel tot een succesvolle website. Teruggaan en wire-framing van deze delen van de website maakt het project beter wanneer het live gaat.
Belangrijkste afhaalmaaltijden: wees niet bang om terug te gaan naar het begin als iets moet worden verbeterd. Als je ze vroeg inhaalt, wordt het project beter wanneer het live gaat.
We hebben dagenlang samengewerkt om ervoor te zorgen dat elk deel van de website naar een hoge standaard was afgewerkt. We hebben zoveel mogelijk scenario's getest en ervoor gezorgd dat de browse-ervaring consistent was.
Zodra de gegevens op de website staan, kunnen we de website volledig testen. Het is vaak te gemakkelijk om een project live in te stellen zonder volledig te testen. We kunnen de snelheid, het navigatiegemak en vooral de inkoopstroom controleren.
Iedereen noemt Apple als perfectionist, maar ik weet zeker dat hun eerste pogingen verre van perfect waren. Het kost tijd en toewijding om die laatste verbeteringen aan te brengen om ons de producten te geven waar we van houden vandaag. Met behulp van ons apparaatlaboratorium, inclusief de meeste populaire apparaten en platforms, konden we ervoor zorgen dat de ervaring geoptimaliseerd was op zoveel mogelijk van de nieuwste platforms en schermformaten.
Leren van elk project is belangrijk, zodat we continu processen kunnen verbeteren die leiden naar betere websites.
Dit project heeft de geboorte van een eigen interne patroonbibliotheek opgeleverd die consistentie tussen projecten bevordert. Wanneer we in een agentschap werken, hebben we misschien tientallen projecten die momenteel tegelijkertijd worden ontwikkeld. De mogelijkheid voor iedereen om aan een project te werken is belangrijk.
Het creëren van een basis waar we allemaal aan kunnen werken, zal bijdragen aan dit doel.
De prestaties van de website werden pas aan het einde van het project overwogen. Een succesvolle responsieve website moet lean en snel zijn. Het enorme aantal apparaten en hun mogelijkheden variëren enorm van gloednieuwe Mac-computers tot oude smartphones. Bij het bouwen van een media-rijke website kan het erg moeilijk zijn om de performance te beheren, vooral als je deze achteraf probeert te verbeteren.
Bij Upfront Conference in Manchester, zagen we Yesenia Perez Cruz spreek over het overwegen van prestaties in elke fase van een project, inclusief ontwerp. Achteraf gezien is dit iets dat we hadden moeten implementeren. Als een team van meerdere ontwerpers, ontwikkelaars en front-end ontwikkelaars had het beheren van de algehele omvang en prestaties (met name de waargenomen prestaties) een grotere prioriteit moeten zijn geweest.
Alles op een pagina brengt kosten met zich mee. Door prioriteit te geven aan wat belangrijk is, is de website niet alleen snel, maar ook toegankelijk voor meer apparaten. Op sommige oudere apparaten hebben we vastgesteld dat de website niet alleen de browser heeft gecrasht, maar het hele apparaat. Een poging om de website te versnellen met terugwerkende kracht, betekende dat we de website niet zo snel konden maken als mogelijk was.
De volgende keer zullen we ervoor zorgen dat de prestaties in elke fase van het proces ingebakken zijn, dus het is geen bijzaak.