Anton Warnhag

Skapa bättre kod med ett designdiagram

Överlämningen mellan en designer och en utvecklare är ett kritiskt skede i ett projekt. Det här är första delen i en serie inlägg om hur vi på Rebel & Bird försöker göra det här på bästa sätt. I dag skriver Anton Warnhag, utvecklare på Rebel & Bird.

Jag fick för en tid sedan i uppgift att översätta designen för en iOS-applikation till en fejkad webbversion (CSS, HTML och Javascript för ett gränssnitt utan någon koppling till en backend). Detta som ett totalt mörkerdyk; jag hade ingen egentlig insikt i appens funktionalitet sedan innan.

Överlämningen från vår designer Axel bestod i ett första steg av en uppsättning målbilder för alla olika vyer som appen skulle innehålla. En av dem var det här event-flödet:

Bild på event-flödet

(Notera: Detta är inte den faktiska applikationen, utan en mockup av en annan app med liknande karaktär.)

Att skicka arbete från designer till utvecklare i den här formen är problematisk av flera skäl. Jag tänkte illustrera ett av dem genom att visa upp en lösning på det: Ett enkelt komplement vi snubblade över i just det här projektet.

Vår projektledare hade förutsett att det kunde bli råddigt att implementera designen enbart baserat på vy-bilderna, och satt av tid för mig att sitta ner med Axel och få en genomgång av olika vyer och tanken bakom hans design. I förbifarten visade han mig de här diagrammen.

Diagram över event-typer

Diagram över färgsättning av event-typer

Axel skapade de här diagrammen för en presentation av designen för produktägaren, utan någon tanke på att det skulle vara en del av underlaget för utvecklarna. Men det här ger en helt annan insikt i varför vissa element ser ut som de gör, och ger ett mycket bättre underlag för att skriva en utvidgningsbar styling.

Varför?

Baserat på enbart den första bilden kan jag utläsa följande:

Det finns två typer av event i flödet;

  • de som har en hatt i variabel färg och
  • de som har en accent av dito.

Om jag skulle skriva det i Sass blir det:

/* Version 1 */
%card {
  padding: 10px;
  color: #000;
  /* et.c. */
}
.card--hatted {
  @extend %card;
  .hat {
    background: green;
    color: #fff;
  }
}
.card--accented {
  @extend %card;
  .accent {
    background: green;
  }
}

Och sedan skulle jag sätta de här klasserna på de HTML-element som ska ha respektive utseende. Allt gott. Men om man nu bestämmer sig för att de event som har en hatt inte ska se ut så längre, de ska ha en bakgrund helt i färg i stället:

Event med en hatt får solid bakgrund i stället

Okej, inga problem. Vi byter helt enkelt ut den klassen i vår Sass:

/* Version 2 */
%card {
  padding: 10px;
  color: #000;
  /* et.c. */
}
.card--solid {
  @extend %card;
  background: green;
  color: #fff;
}
.card--accented {
  @extend %card;
  .accent {
    background: green;
  }
}

Det är ingen stor grej i sig, men nu måste vi gå igenom all HTML och byta ut varje instans av .card--hatted mot .card--solid. Om vi har knutit något javascript till den här klassen måste det i sin tur uppdateras. Än värre blir det om detta ska göras av en tredje person som är ansvarig för markup. Och det måste göras varje gång som designen går igenom en ny iteration.

Vad vi egentligen vill ha är ett bättre namn på klasserna till att börja med. För att ens stylesheets ska vara lätta att ta till sig och lätta att utvidga för nya typer av element bör klasser ges namn efter deras funktion och innehåll snarare än deras utseende. Det minskar förvirring och behov av att uppdatera annat än just ens stylesheets. Och här kan vi använda det andra diagrammet Axel gjorde som referenspunkt.

Utifrån det förstår vi att event inte är av typerna ”accentuerad” och ”med hatt”, de är av typerna hög- och lågfrekventa (förväntad frekvens, i alla fall). Med den informationen kan vi skriva följande Sass i det först skedet i stället:

/* Version 1 */
%card {
  padding: 10px;
  color: #000;
  /* et.c. */
}
.card--lf {
  @extend %card;
  .hat {
    background: green;
    color: #fff;
  }
}
.card--hf {
  @extend %card;
  .accent {
    background: green;
  }
}

Vi använder således klasserna .card--hf och .card--lf i vår HTML. Vilket när designen sedan uppdateras innebär en förändring till det här i stället:

/* Version 2 */
%card {
  padding: 10px;
  color: #000;
  /* et.c. */
}
.card--lf {
  @extend %card;
  background: green;
  color: #fff;
}
.card--hf {
  @extend %card;
  .accent {
    background: green;
  }
}

Men den här lösningen finns det inget behov av att göra någon förändring i vår HTML eller annan del av logiken.

Det finns mycket mindre tydliga fall än det här, där det är lätt att missförstå designen bara lite och ändå ha en struktur på sina stylesheets som är helt fel för de ändringar som kan komma.

Diagrammet är inte magiskt, det är bara tydligt för någon som likt mig kommer in i projektet utan koll. Det viktiga är att den som ska skriva ett stylesheet förstår hur applikationens logik informerar designen.