cri.dev
about posts
makes uses rss

Cos’è e com’è stato sviluppato il Lean Validation Playbook

Published on
Tagged with lean1 validation2 playbook3

Insieme a Fightbean e Matteo Cavucci abbiamo costruito il Lean Validation Playbook.

Che cos’è?

The Lean Validation Playbook è una raccolta di metodi per testare idee e soluzioni legate alla creazione di prodotti digitali e affronta il lato operativo che manca a molte strategie di business.

In questo post descrivo come abbiamo messo online un sito statico con 11ty e altri strumenti utilizzati per organizzare il lavoro.

Designer + Sviluppatori = ❤

Fightbean ha dato indicazioni a livello di design e UX e realizzato un mockup su Figma.

Per chi non lo conoscesse, Figma è uno strumento per realizzare design di siti web e applicazioni.

Ecco un’anteprima del mockup su Figma, suddiviso in pagine e stati di interazione (e.g. menù aperto)

figma

Gli stili si possono direttamente copiare dal design Figma e riportare nel CSS del sito con minime modifiche.

Ho trovato molto utile la possibilità di ispezionare la spaziatura tra i vari elementi, per avere un risultato nel HTML più coerente possibile al mockup.

Contenuti

I contenuti del sito li abbiamo gestiti via Excel.

Si hai letto bene!

In un foglio di calcolo abbiamo suddiviso i testi e le proprietà dei vari workshop del Lean Value Playbook.

Successivamente, si scarica un TSV (Tab Separated Values, simile ad un CSV) e si include nel repository git.

Tramite uno script il TSV viene processato e generato un JSON.

Questo tools.json viene generato nella cartella _data da cui 11ty legge le proprietà e renderizza le pagine Workshop.

In particolare entra in gioco tools.njk che ha la funzione di creare le singole pagine /tools/...

---
layout: layouts/base.njk
pagination:
  data: tools
  size: 1
  alias: tool
permalink: tools/{{ tool.url }}
---

<div class="mx-auto container max-w-5xl lg:px-16 px-8">
  <lottie-player src="/animations/workshop-header-{{tool.normalized}}.json" class="mb-10 tool-title" background="transparent"  speed="1" autoplay></lottie-player>

  <div class="flex">
    <div class="lg:mr-4 w-full">
      <div class="lg:w-3/4">
        <div class="mt-5 lg:mt-10 mb-small0 border border-black">
          <lottie-player src="/animations/{{tool.normalized}}.json" preserveAspectRatio="xMaxYMax slice" class="lottie-margin" background="transparent"  speed="1"  loop autoplay></lottie-player>
        </div>
        {{ tool['Descrizione di massima'] | safe }}
        {% usefulness tool %}
        {% todo tool %}
      </div>
    </div>
    <div class="lg:block hidden mt-5" style="width: 250px;">
      {% info tool %}
      {% properties tool %}
    </div>
  </div>
</div>

...

Usando i “shortcodes” di 11ty fatti a mano (e.g. usefulness, todo, info, properties) viene renderizzato l’HTML definito.

Estrapolare la logica in singoli shortcode è stato anche molto utile per scrivere dei test per l’HTML generato.

Stili e animazioni

Tailwind.css

Dietro le quinte entra in gioco Tailwind.css, un ottimo framework CSS con mentalità “utility-first”.

In pratica si possono assegnare stili direttamente su elementi HTML, senza neanche toccare un file CSS.

Questo perchè esistono una miriade di classi che hanno un singolo scopo:

  • block -> display: block
  • flex -> display: flex
  • m-0 -> margin: 0
  • mt-2 -> margin-top: 0.125rem
  • lg:p-2 -> padding solo per viewport maggiori di lg
    …

Durante una build CSS viene analizzato l’HTML e generato un CSS che contiene solo le classi effettivamente usate.

Lottie / Bodymovin’

Per quanto riguarda le animazioni sul sito, abbiamo usato lottie-web

Le animazioni vengono create in After Effects / Lightroom (se non erro) ed esportate in un file JSON.

Un’animazione è possibile mostrarla utilizzando il web-component <lottie-player>:

<lottie-player src="/animations/a-b-test.json" class="mb-10 tool-title" background="transparent"  speed="1" autoplay></lottie-player>

Andiamo online

Il sito è “hostato”/ospitato su GitHub Pages, con il file CNAME che punta a leanvaluetree.it

Nel repository GitHub del progetto ho configurato una pipeline GitHub Actions per mettere online il sito.

Ad ogni commit e push da un designer o sviluppatore, entra in gioco una pipeline di deploy su GitHub Actions

Questa pipeline esegue i seguenti passaggi:

  • esegue il checkout del repository all’ultimo commit
  • installa dipendenze
  • esegue i test per i shortcode
  • (idealmente eseguirebbe anche test e2e con cypress)
  • esegue una build del progetto
  • pubblica le modifiche sul branch gh-pages usato per servire i file statici