Creazione di componenti e modelli di siti Web accessibili ottimizzati | firez
Web Services

Creazione di componenti e modelli di siti Web accessibili, ottimizzati per i dispositivi mobili, a caricamento rapido e accattivanti

Inizia con il design atomico

Stiamo usando disegno atomico principi per organizzare il nostro vasto numero di componenti e modelli di progettazione. Questi assumono la forma di:

  • Atomi: questi sono gli elementi costitutivi più basilari all’interno della libreria di modelli e includono elementi come pulsanti, colori, elenchi e per input come pulsanti di opzione
  • Molecole: vengono create quando mettiamo insieme due atomi dal sistema di progettazione come una barra di ricerca, banner di avviso e fisarmoniche
  • Organismi: raccolte di molecole costituiscono organismi e includono cose come un pannello di eroi che si trova nella parte superiore di una pagina
  • Modelli: simili agli organismi, tranne per il fatto che sono componenti a livello di sito come l’intestazione e il piè di pagina del sito web
  • Pagine: questi sono il più alto livello di fedeltà con la libreria di modelli e contengono tutto quanto sopra e forniscono contenuto statico effettivo affinché l’utente abbia un’anteprima di come appaiono tutti questi componenti con il contenuto reale

I componenti sono conservati in una « libreria di modelli » utilizzando uno strumento chiamato Laboratorio di modelli. Questa libreria di modelli è una parte importante del nostro nuovo sistema di progettazione; è l’unica fonte di verità per il nostro lavoro di progettazione. Ci darà coerenza in tutti i progetti futuri e ci consentirà di migliorare continuamente nel tempo.

Di seguito è riportato un esempio dell’atomo del pulsante in Schizzol’app che usiamo per progettare componenti e modelli:

Consegna allo sviluppo

Da Sketch, i disegni vengono importati in uno strumento di collaborazione online chiamato Zeplin. Consente a progettisti e sviluppatori (che spesso lavorano con team e persino paesi diversi) di garantire che i passaggi di progettazione vengano implementati correttamente con specifiche, risorse e codice accurati. Porta chiarezza a un progetto complesso e in rapido movimento.

Zeplin consente ai progettisti di aggiungere annotazioni per aiutare gli sviluppatori a capire cosa dovrebbe fare il componente, nonché i diversi « stati » (ad esempio, un campo del modulo che contiene un errore).

Questo strumento fornisce anche il padding, i margini, le altezze e le larghezze esatte su un componente per risparmiare tempo tra sviluppo e progettazione.

disegno del pulsante

requisiti zeplin

Gli screenshot sopra mostrano i requisiti di riempimento, il colore del pulsante, le specifiche dell’ombra della casella e altro ancora.

Componenti e modelli costruttivi

Una volta approvato in Zeplin, ora possiamo passare alla build front-end all’interno della libreria di pattern. Il nostro codice per la libreria di modelli vive in un repository su GitLab. Ogni componente è suddiviso in attività separate e assegnato a uno sviluppatore come mostrato di seguito:

scheda attività gitlab

Quando viene creato un nuovo componente, uno sviluppatore creerà quindi un nuovo « ramo ». Ciò consente loro di lavorare solo su quella cosa, senza influire su nient’altro su cui altre persone stanno lavorando contemporaneamente.

Quando il componente è pronto per essere esaminato da qualcuno, viene creata una « richiesta di unione ». Ciò consente ad altri sviluppatori di esaminare il nuovo componente e suggerire modifiche, se necessario.

L’approvazione di una richiesta di unione consente di unirla al ramo di sviluppo principale una volta superati tutti i test. Testiamo rispetto a una serie di « criteri di accettazione » scritti prima dell’inizio dello sviluppo, quindi è chiaro cosa dovrebbe fare il componente e come dovrebbe apparire.

Usiamo uno strumento chiamato Git Kraken per consentire agli sviluppatori di visualizzare (e utilizzare) facilmente diversi rami. Ciò semplifica la visualizzazione dello stato di ciascun ramo (quali rami sono stati uniti, ciò che lo sviluppatore ha attualmente verificato e consente persino a un utente di visualizzare il codice e vedere quali modifiche sono state apportate).

crepa

Di cosa è fatto un componente?

Ogni componente nella libreria dei modelli segue la stessa struttura:

  • File Twig: markup del componente, HTML e RAMOSCELLO
  • File MD – documentazione del componente
  • File YML: variante del documento e dati di anteprima
  • File SCSS: per definire lo stile del componente
  • File JS: file JavaScript aggiunto se necessario

Se un pattern ha molte variabili o variazioni e lo sviluppatore desidera mostrare un paio di varianti nella libreria di pattern, può aggiungere file YAML extra con la convenzione di denominazione button~VARIANTNAME.yml. Un esempio della configurazione del codice per questo è mostrato di seguito nello screenshot:

codice componente

Quanto sopra mostra il codice per il primario e una variante. Il codice sopra produrrà quanto segue nel browser:

pulsante principale nel browser

L’utente può anche visualizzare l’HTML/TWIG e la descrizione del componente tramite una fisarmonica:

visualizzazione del codice front-end di pattern lab

Come viene testato un componente?

Una volta che il nuovo componente è stato codificato, è il momento di iniziare il « test di regressione visiva ». Questo è gestito da BackstopJS. In breve, il test di regressione verifica che le modifiche al codice di uno sviluppatore (nel nostro caso, come parte di un ramo) non abbiano influito negativamente sulle funzionalità esistenti.

I test mostreranno:

  • Riferimento: queste immagini dovrebbero essere i componenti aggiornati corretti già nel laboratorio di modelli
  • Test: sono le nuove immagini generate da nuovi componenti o quando sono state apportate modifiche ai componenti esistenti
  • Differenza: fornisce una sovrapposizione di entrambe le immagini precedenti, evidenzia le modifiche in viola

Attualmente il colore principale del pulsante è il nostro marchio arancione. I test passeranno attualmente in quanto ha l’immagine di riferimento di un pulsante principale come il marchio arancione. Se uno sviluppatore dovesse cambiare il colore del pulsante in blu brand, i test fallirebbero poiché le immagini di test sarebbero diverse dalle immagini di riferimento. Questo cambiamento sarebbe anche evidenziato in un 3rd colonna che mostra il cambiamento visivo. Se si trattava di una modifica necessaria, lo sviluppatore eseguiva semplicemente un comando per approvare la modifica e rieseguiva i test per aggiornare le immagini di riferimento.

Cosa succede quando un componente è pronto?

Una volta che le immagini sono passate, è il momento di eseguire il commit e inviare il codice al ramo del componente specifico per una revisione peer e del codice del componente. Altri sviluppatori idealmente abbatteranno il ramo, daranno un’occhiata al codice e controlleranno il componente nel browser, verificheranno il componente rispetto ai requisiti in Zeplin e controlleranno le immagini prodotte da BackstopJS.

Una volta che tutto funziona e è corretto, gli approvatori (di solito altri sviluppatori) sulla richiesta di ramo/unione approveranno l’unione del componente nel ramo di sviluppo principale. Il nuovo componente verrà unito ai componenti già esistenti insieme alle nuove immagini di riferimento. Da qui, gli sviluppatori possono quindi trasferire questi nuovi componenti sulla loro macchina locale tramite il ramo di sviluppo principale.

Come vengono utilizzati i modelli dal sistema di gestione dei contenuti Drupal?

Il laboratorio di modelli è un’entità separata da un sistema di gestione dei contenuti. La nostra scelta del sistema di gestione dei contenuti per il nuovo sito web, Drupal, fornisce un modo semplice per integrare una libreria di modelli in un progetto. La libreria di pattern viene inserita nel progetto Drupal e utilizzando una serie di funzioni personalizzate del laboratorio di pattern, uno sviluppatore può facilmente estrarre componenti dalla libreria di pattern da utilizzare nei modelli Drupal per visualizzare dati dinamici. Uno screenshot di questo è mostrato di seguito:

codice ramoscello nel tema drupal personalizzato

Il codice sopra mostra un pulsante secondario inserito in un modello Drupal tramite la funzione pattern lab e con le sue variabili dichiarate in modo che possa essere utilizzato come trigger di filtro dei risultati di ricerca per consentire all’utente finale di visualizzare un set personalizzato di risultati.

Pattern Lab consente agli sviluppatori di inserire facilmente componenti pre-stilizzati senza doversi preoccupare del codice o del design front-end. Se dobbiamo apportare una modifica a un componente nella libreria di pattern, piuttosto che aggiornare il codice nel tema personalizzato, tutto ciò che uno sviluppatore deve fare è semplicemente aggiornare la libreria di pattern tramite un’istruzione della riga di comando che aggiornerà quindi gli stili in entrambi i laboratorio di modelli e tema Drupal personalizzato.

Lavorare con Manifesto

Come accennato, le revisioni tra pari e del codice sono una parte fondamentale per assicurarsi che non solo i requisiti siano stati soddisfatti, ma che il codice sia leggibile, facile da mantenere, aggiornare e ottimizzato per Drupal. La squadra a Manifesto sono stati in grado di portarci al passo con tecnologie che non avevamo realmente utilizzato all’Università di Dundee, come Twig e BackstopJS. Quando hanno affidato il codice alle filiali per la revisione tra pari, sono stati in grado di guidare e fornire consigli sul nostro codice per assicurarsi che fosse il più efficiente e affidabile possibile.

La maggior parte delle comunicazioni è avvenuta tramite chat sui rami dei singoli componenti e nelle schede della task board in Gitlab. Le e-mail vengono attivate automaticamente ogni volta che un membro del team dell’Università di Dundee o del Manifesto commenta qualcosa in GitLab. Abbiamo comunicato regolarmente su Allentato anche per domande e domande veloci.

Test, test, test

I test stanno svolgendo un ruolo importante nel distribuire la libreria di modelli al pubblico più ampio dell’Università di Dundee. Abbiamo già toccato BackstopJS per i test, ma dobbiamo prendere in considerazione i test di accessibilità, cross browser e diversi test del sistema operativo. Il nostro piano per testare ogni componente è mostrato di seguito:

elenco di controllo dei test front-end

I requisiti vengono verificati rispetto a Zeplin e anche al ticket in Gitlab che corrisponde al componente su cui sta lavorando uno sviluppatore. Questo è un controllo visivo e anche per verificare che i valori per cose come margine e riempimento siano corretti. Pattern lab ha anche uno strumento integrato che ti consente di ridimensionare le finestre del browser per vedere un componente su schermi di dimensioni diverse. Zeplin contiene anche progetti per ciascun componente con schermi di diverse dimensioni.

Test di accessibilità

Utilizziamo una serie di strumenti per verificare l’accessibilità, tra cui ONDA E ASCIA. Entrambi sono motori di test di accessibilità per siti Web e altre interfacce utente basate su HTML. Testano diverse esigenze di accessibilità come il daltonismo, HTML semanticoetichette per elementi HTML e per aspetti come descrizioni alternative per immagini mancanti ecc.

Controlliamo anche i nostri componenti su uno screen reader come Chrome Vox, l’utilità per la lettura dello schermo NVDA per Windows o l’utilità per la lettura dello schermo integrata in macOS, VoiceOver. Questi test assicurano che le persone con problemi di vista possano navigare nel sito Web e comprendere il contenuto di una pagina. Questo lavoro contribuirà a garantire che ogni visitatore possa trovare facilmente le informazioni di cui ha bisogno o completare un’attività comune sul sito web.

Utilizziamo un altro strumento per controllare i componenti e i modelli su una serie di sistemi operativi, dispositivi e browser che si chiama Test tra browser. Questo strumento ci consente di eseguire una serie di emulatori per verificare la presenza di errori in diversi browser come Internet Explorer, Chrome e Firefox. Ci consente di eseguire test su sistemi operativi come Windows, macOS e Linux. Fornisce inoltre una serie di emulatori come dispositivi Android e Apple per diverse dimensioni dello schermo e sistemi operativi mobili e, se necessario, su diversi segnali di rete come 4G e Wi-Fi. Tale test è mostrato di seguito:

cross-browser-test

Una volta superati tutti i test, il componente è pronto per l’uso ed è completamente approvato per l’uso nel tema Drupal personalizzato. Se qualcosa deve essere risolto, possiamo creare un nuovo ramo dal ramo principale di sviluppo e creare una nuova richiesta di ramo/unione per una correzione di bug o un aggiornamento. Questo ramo verrà nuovamente sottoposto a revisione paritaria da parte di altri sviluppatori e, una volta funzionante, verrà unito al ramo principale.

Conclusione

Un sacco di lavoro eccellente da parte di sviluppatori in luoghi diversi si è riunito e ha creato un sistema di progettazione veloce, espandibile, accessibile e moderno in un breve lasso di tempo.

Vantaggi di un tale sistema:

  • Standardizzerà il nostro marchio
  • Rende facile mantenere il nostro marchio digitale
  • È facilmente trasportabile
  • È flessibile
  • Il lavoro dei nostri sviluppatori di back-end è reso più semplice grazie al minor feedback avanti e indietro
  • Le agenzie esterne possono facilmente accedere e creare con la libreria di modelli
  • È costruito pensando all’accessibilità, rendendolo disponibile a un pubblico molto più ampio

La nostra libreria di modelli continuerà a crescere man mano che aggiungiamo più componenti che risolveranno un’ampia varietà di problemi. Portare avanti ciò che abbiamo imparato da questa esperienza nella costruzione di un tale sistema andrà a beneficio non solo del nostro team ma anche di altri team dell’Università mentre continuiamo a spingere il nostro nuovo marchio digitale sul Web e oltre.

Se desideri saperne di più sul laboratorio di modelli dell’Università di Dundee, contatta me stesso (Ryan Mclauchlan) all’indirizzo rdmclauchlan@dundee.ac.uk o Steve Burrows all’indirizzo syburrows@dundee.ac.uk.