Blogg

Att skapa komponenter för ett designsystem

Under de senaste åren har modulär gränssnittsutveckling och designsystem fått ett riktigt uppsving inom gränssnittsutveckling. Många pratar om designsystem och väldigt många organisationer - stora som små – har skapat eller är på väg att bygga upp sitt eget designsystem och komponentbibliotek.

Artikelverktyg:

Som koncept är det ganska enkelt att förstå. 

Man utvecklar en samling återanvändbara och isolerade komponenter som lagras i ett komponentbibliotek. Dessa komponenter och byggstenar kan sedan användas för att bygga ett, i teorin, oändligt antal olika applikationer och webbsidor. 

Så långt allt gott, men den som startar arbetet med att ta fram ett designsystem upptäcker troligen snart att svårigheten ligger i att veta vilka komponenter man ska skapa. 

Precis som med den berömda elefanten så finns det många sätt att stycka ett designsystem. 

Vissa komponenter är kanske enkla att identifiera och man är ofta ganska överens både om syfte och gränsdragning gentemot andra komponenter. Komponenter som faller inom denna kategori är exempelvis paginering, brödsmula, bildspel, kort. 

Men om tittar på behoven för en tjänst eller webbsida inser man snart att det behövs fler än dessa komponenter för att kunna skapa en helhet och det är här det kan bli svårt att veta vilka komponenter man ska skapa. Det man vill nå är ju ett komponentbibliotek som faktisk är så dynamiskt att det låter en skapa alla dessa varianter av sidor och applikationer som ett designsystemet ger löfte om. 

Nedan är några områden som jag ofta har sett blir föremål för diskussion. 

Hur stor är en komponent?

Hur stor är en komponent? Och kan en komponent finnas inuti en annan?

Det enklaste och mest pragmatiska svaret på dessa frågor är att de kan vara av olika storlekar och att det inte är några konstigheter att en komponent kan innehålla en annan komponent.

Det jag stött på i många fall är att många kommit i kontakt med designsystem genom att de läst om Atomic design. Atomic design var ett begrepp som myntades av Brad Frost i en bloggpost från 2013. I den beskriver han modulär gränssnittsutveckling med analogin atomer, molekyler och organismer för att tydliggöra att gränssnitt är uppbygga av små byggstenar som tillsammans blir större byggstenar som till slut bildar sidor.

Även om analogin är ett effektivt sätt att förklara konceptet är min erfarenhet är att det ofta blir problem om man tar analogin vidare och försöker klassificera och namnge sina komponenter utifrån dessa nivåer (även om jag är säker på att Brad Frost inte håller med här).

Mycket tid och diskussioner kan gå till att diskutera huruvida något är en atom eller organism istället för att se hur man effektivast bygger upp gränssnittet.

Min rekommendation är att acceptera att komponenter kan vara av olika storlek och att de kan ingå i varandra och istället skapa de komponenter som effektivast bygger upp designsystemet.

Är det här samma komponent eller två olika?

Ibland, när två potentiella komponenter är visuellt och funktionellt närliggande hamnar man i ett läge där man måste besluta om det är läge att skapa två separata komponenter eller om man ska slå ihop dem till en.

Att avgöra vad som är bäst är inte alltid enkelt, man vill inte slå isär en komponent om det endast är en variant av samma, men samtidigt vill man inte bygga komponenter som är som schweiziska arméknivar – som kan göra allt men inget riktigt bra.

Jag skulle säga att risken är större att man vill klämma in för mycket funktionalitet i en komponent, än tvärtom.

Ibland kan önskan att abstrahera en komponent och i för stor utsträckning arbeta enligt principen Don’t Repeat Yourself göra den svåranvänd och svårförvaltad.

Man ska komma ihåg att kod läses oftare än den skrivs och kod som gör flera olika saker är svårare att förstå och i och med det mer riskfylld att ändra på och förutse konsekvenserna.

”Repetition is better than the wrong abstraction” är en väldigt bra princip att ta fasta på.

För att avgöra huruvida man ska ha en eller flera komponenter kan man resonera kring följande saker:

Utseende

Om två saker visuellt skiljer sig markant från varandra så är det troligen bäst att skapa 2 komponenter även om de kanske delar innehållsmodell.

Syfte

• Om två komponenter är visuellt väldigt lika men syftet skiljer sig åt kan det vara ett tecken på att ändå separera dem i två olika komponenter. Kanske är de bara slumpen som gör att de är lika just nu men att de över tid kommer utvecklas åt olika håll.

Innehållsmodell

Om däremot två komponenter delar innehållsmodell och även till stor del syfte kanske man istället kan komma på ett mer generiskt namn som gör att man kan slå ihop dem till en komponent.

Vad ska den heta?

När det gäller namnsättning så är en bra utgångspunkt att inte namnge komponenten så att dess användningsområde snävas in i onödan. T.ex. så bör man undvika att namnge komponenten efter dess placering på sajten, det är alltså bättre att döpa den till Nyhetspuff är Startsidepuff.

Å andra sidan så ska man inte heller ge den ett namn som blir så generiskt att det säger för lite om vad komponenten gör.

Man ska tänka på att andra, helst genom namnet, ska kunna få en uppfattning om vad komponenten gör och när den ska användas. Av den anledningen är det också bra att inte frångå vedertagna termer i de fall som de finns, som exempelvis brödsmula eller bildspel.

Pröva idéerna i praktiken

Så, om du har tankar på att starta igång arbetet med ett designsystem för din organisation så kan du nästan vara säker på att frågan - vilka komponenter vi ska skapa? - kommer generera många (och ibland långa) diskussioner.

Tänk bara på att inte fastna för länge i långa teoretiska diskussioner utan börja testa och pröva vad som fungerar i praktiken.

För att citera den amerikanske baseballspelaren Yogi Berra:
-
“In theory there is no difference between theory and practice. In practice there is.” 

Vill du veta mer om hur vi tänker kring designsystem på NetRelations?

Tveka inte att ta en kontakt med oss via formuläret så berättar vi gärna mer. 

0 kommentarer

Skriv kommentar