Pensare in maniera responsive: un framework per l’apprendimento futuro

Prima dell’arrivo degli smartphone e dei tablet, molti di noi avevano assunto una posizione di beata ignoranza. Credendo di poter domare l’imprevedibilità intrinseca del web, abbiamo fatto delle assunzioni sui requisiti per il suo accesso, dando priorità ai nostri bisogni prima che a quelli dell’utente.

Proprio quando le nostre supposizioni diventavano più dettagliate, il responsive web design ha mostrato una via d’uscita. Oltre ad offrire i mezzi per creare layout indipendenti dai device, RWD ha dato il via a un periodo di riconsiderazioni: era dall’adozione degli standard web che il nostro settore non vedeva un riallineamento così radicale di teoria e pratica.

Nei cinque anni da quando l’articolo di Ethan Marcotte è apparso la prima volta su queste pagine, migliaia di siti web sono stati lanciati con un layout responsive come loro centro. Durante questo periodo, abbiamo sperimentato con nuovi modi di lavorare e abbiamo ridefinito la nostra pratica di design e sviluppo così che sia più adatta ad un medium fluido e disordinato.

Mentre emergiamo da questo periodo illuminato, abbiamo bisogno di consolidare la nostra cultura e di considerare come andare avanti costruendo su questa base.

Un framework responsive#section1

Quando pensiamo ai framework, spesso immaginiamo librerie di software e altre astrazioni riguardanti l’esecuzione e il codice. Ma questo tipo di framework ci allontana dalle difficoltà che ci troviamo di fronte quando progettiamo per il medium. L’anno scorso, quando Ethan ha parlato della necessità di un framework, ne ha proposto uno focalizzato sul nostro approccio: un framework per aiutarci a modellare la discussione in corso e per misurare la qualità e l’adeguatezza del nostro lavoro.

Credo che possiamo ideare questo framework mettendoci prima d’accordo su un insieme di principi di design sottostanti. Il concetto potrebbe esservi familiare. Organizzazioni come GOV.UK e Google li usano per definire le caratteristiche dei loro prodotti e perfino delle loro organizzazioni. Kate Rutter descrive i principi di design come:

…brevi frasi intelligenti che fungono da luci guida e supportano lo sviluppo di grandi esperienze di prodotto. I principi di design vi permettono di essere fedeli ai vostri utenti e leali verso la vostra strategia a lungo termine (l’enfasi è mia).

La strategia a lungo termine del web è di permettere l’accesso universale alle informazioni e ai servizi. Questo nobile obiettivo è fondamentale per l’importanza continua del web. I nostri principi di design devono operare a servizio di questa visione, gestendo:

• i nostri utenti: possiamo raggiungere una portata più ampia creando dei team inclusivi che ascoltano gli utenti e ci lavorano perfino assieme.
• il nostro medium: possiamo creare prodotti più adattabili facendo meno assunzioni sul contesto e sull’interfaccia, concentrandoci di più sui task e sugli obiettivi degli utenti.
• Noi stessi: possiamo ottenere una maggior collaborazione all’interno dei team scegliendo strumenti che siano accessibili, semplici da usare e aperti al cambiamento.

Rispecchiare la diversità nella pratica#section2

Può essere avventato tentare di categorizzare le caratteristiche comuni dei device con accesso al web mentre se ne esamina il panorama. Sebbene a volte questa ampiezza e fluidità possano risultare frustranti, la frammentazione dei device è solo un riflesso della diversità umana e dei clienti che esercitano il proprio diritto a scegliere.

Fino a poco tempo fa, l’empatia verso i consumatori era largamente dominio dei designer e dei ricercatori di user experience. Tuttavia, sebbene un’interfaccia utente mal progettata possa influenzare negativamente l’usabilità di un sito, allo stesso modo possono farlo le scelte tecnologiche sbagliate. Dobbiamo tutti tenere presente le nostre responsabilità sul nostro lavoro, perché possono influenzare l’esperienza risultante.

Il design per tutti#section3

Il design universale promuove la creazione di prodotti utilizzabili da tutti indipendentemente dall’età, abilità o status. Mentre queste idee godono di un riconoscimento maggiore tra gli architetti e i product designer, sono altrettanto rilevanti nella nostra professione.

Considerate gli utensili da cucina OXO Good Grips. Nel 1989, Sam Farber, ispirato dall’artrite di sua moglie, riprogettò il convenzionale pela-verdure, sostituendo i manici di metallo con impugnature più morbide. Ora tutti, indipendentemente dalle abilità manuali e dalla forza, possono usare questo strumento e la considerazione di Farber per l’estetica ha assicurato anche un maggior appeal per tutti. Il suo approccio è stato applicato a un range di prodotti: Good Grips è diventato un marchio premiato e internazionalmente riconosciuto, mentre l’azienda di Farber, OXO, ha continuato a generare vendite significative.

Questo lavoro ha reso molto popolare il concetto design inclusivo. OXO rimane un sostenitore del design di prodotti intrinsecamente accessibili, sottolineando che:

Quando tutti i bisogni degli utenti sono stati presi in considerazione nel processo iniziale di design, il risultato è un prodotto che può essere usato dallo spettro più ampio di utenti. Nel caso di OXO, significa progettare prodotti per giovani e vecchi, maschi e femmine, mancini e destrorsi e per molti con bisogni speciali.

Molte delle tecnologie e specifiche che usiamo hanno già adottato degli aspetti del design universale. Oltre alle specifiche come WAI-ARIA, che aumenta l’accessibilità delle interfacce dinamiche, HTML include da tempo delle feature di accessibilità di base: l’attributo alt permette agli autori di aggiungere un testo alternativo alle immagini, mentre l’elemento object permette di fornire del contenuto di feedback se non è disponibile un particolare media plug-in o codec.

Si possono trovare altri esempi anche all’interno del W3C e del WHATWG. Un principio chiave utilizzato nel design di HTML5 riguarda il modo in cui gli autori dovrebbero valutare aggiunte o cambiamenti alla specifica. Detto priority of constituencies, dichiara che:

In caso di conflitto, considerate gli utenti poi gli autori poi gli implementatori poi gli specifiers poi la purezza teorica.

Possiamo usare questa assegnazione delle priorità quando prendiamo le decisioni nei nostri progetti. Sebbene un framework MVC client-side potrebbe fornire una certa comodità allo sviluppatore, se questo implica che gli utenti debbano scaricare un grosso file JavaScript prima di poter accedere all’applicazione, allora dovremmo cercare un approccio alternativo.

Trovare un compromesso#section4

Può essere difficile per i makers, attaccati a display ad alta risoluzione e con connessioni broadband super veloci, visualizzare l’esperienza vissuta dagli utenti usando il prodotto finale su un mobile device con poca batteria e una rete cellulare inaffidabile. Più è largo il divario tra coloro i quali creano un prodotto e quelli che lo usano, più sarà probabile che i primi facciano scelte sbagliate. Dobbiamo assegnare delle priorità più vicine ai nostri utenti.

La user research e i test di usabilità ci aiutano a vedere in che modo gli utenti interagiscono con i nostri prodotti. Far partecipare diverse discipline (developer, interface e content designer, product manager) può assicurare che questo insegnamento sia ampiamente condiviso, ma possiamo sempre fare di meglio. Susan Robertson recentemente ha scritto su come passare una settimana a rispondere alle email di supporto le abbia dato una nuova conoscenza del modo in cui i clienti stavano usando l’applicazione che stava creando:

Gli utenti diventano persone con un nome, piuttosto che persone senza identità che scrivono su una tastiera, e vogliono usare quello che state contribuendo a creare.

Rendere l’intero team responsabile collettivamente dell’esperienza finale significa che le considerazioni di usabilità e accessibilità rimarranno attributi chiave del prodotto finale, ma cosa succede se il team è anche più inclusivo? Nel suo articolo “Universal Design IRL”, Sara Wachter-Boettcher fa notare che:

Il modo migliore per comprendere il pubblico per cui progettiamo è di conoscere tale pubblico. E il miglior modo per conoscere le persone è di averle proprio accanto a noi, con tutte le loro differenze di prospettive e background e, ovviamente, anche di età, genere, razza e lingua.

Forse non è una coincidenza che da quando stiamo imparando della diversità dei nostri clienti, abbiamo cominciato a riconoscere la mancanza di diversità all’interno del nostro settore. Battendoci per fare in modo di rispecchiare il mondo reale, possiamo creare team più empatici ed efficaci e, di conseguenza, prodotti migliori.

Costruire su fondamenta flessibili#section5

Empatizzando con gli utenti, possiamo fare scelte migliori. Tuttavia, le decisioni risultanti dovranno viaggiare su reti inaffidabili prima di essere utilizzate da vari device dalle caratteristiche sconosciute. È difficile prendere decisioni se non si è in grado di prevedere i risultati.

Osservando i siti web con lenti diverse, possiamo scoprire aree limite che offrono un maggior grado di possibilità e adattabilità. Se un’interfaccia funziona su un device mobile, funzionerà anche su un display più grande. Se si possono consultare i dati quando non c’è rete, una connessione non affidabile sarà un piccolo intralcio. Se il contenuto forma la base del nostro design, l’informazione sarà disponibile indipendentemente dagli stili. Le ottimizzazioni basate su assunzioni più incerte possono essere aggiunte dopo, sicuri del fatto che abbiamo fornito dei fallback.

Interface first#section6

Nel 2009, Luke Wroblewski ci ha chiesto di considerare in che modo le interfacce potrebbero trarre vantaggio dalle capacità dei device mobile prima di pensare alla loro manifestazione nei browser desktop. Il mobile-first thinking ci invita a concentrare: gli schermi dei telefoni hanno poco spazio per interfacce e contenuti non pertinenti, quindi dobbiamo sapere cosa ha più importanza. Facendo domande su quali parti di un’interfaccia siano critiche e quali non lo siano, possiamo decidere se queste parti non-critiche sono caricate in maniera condizionale o “lazily” o addirittura non caricate del tutto.

Network first#section7

Nel 2013, considerando le realtà dell’affidabilità della rete, Alex Feyerke propose un approccio offline-first. Piuttosto che trattare l’accesso offline come un caso limite, possiamo creare esperienze senza soluzione di continuità che funzionano indipendentemente dalla connettività, scaricando preventivamente gli asset e sincronizzando i dati quando si è online, e usando l’aggressive caching e la computazione lato cliente quando non si è online. Altri hanno suggerito di cominciare con gli URL o con un approccio API-first, usando queste lenti per pensare a dove vive il contenuto all’interno di un sistema. Ogni approccio adotta la struttura sottostante del web per aiutarci a creare prodotti più robusti e flessibili.

Content first#section8

Nel 2011, Mark Boulton ha segnalato uno spostamento dal nostro approccio canvas in verso uno in cui i layout vengono progettati a partire dal contenuto. Definendo relazioni visuali basate sugli elementi della pagina ed usando proporzioni invece di valori fissati, possiamo permeare una pagina di relazioni, indipendente dalle sue dimensioni.

Riconoscendo che avere il contenuto a disposizione prima di progettare una pagina possa essere una richiesta assurda, Mark ha in seguito suggerito di considerare la struttura per prima e il contenuto sempre (structure first content always). Questo va d’accordo con il Core Model, un’idea introdotta la prima volta da Are Halland nell’IA Summit del 2007. Facendo domande sul contenuto principale di un sito, quali task servono per funzionare, quali informazioni dovrebbe inviare, possiamo aiutare i clienti a pensare più criticamente ai loro obiettivi strategici, agli obiettivi di business e ai bisogni dell’utente. Recentemente, Ida Aalen notava che:

Il core model è innanzitutto uno strumento per pensare. Aiuta il content strategist a identificare le pagine più importanti sul sito. Aiuta lo UX designer a identificare quali moduli servano su una pagina. Aiuta il graphic designer a sapere quali sono gli elementi più importanti da enfatizzare nel design. Aiuta a includere i clienti o gli stakeholder che sono meno web-savvy nella vostra strategia di progetto. Aiuta i copywriter e gli editori a lasciarsi alle spalle il pensiero racchiuso nei silo e a creare contenuti migliori.

Condividere la scatola degli attrezzi#section9

Provando empatia con i nostri utenti e navigando un medium imprevedibili, abbiamo bisogno di essere sicuri che le nostre decisioni e scoperte vengano condivise tra i team.

Man mano che il responsive design diventa sempre più integrato all’interno delle organizzazioni, questi team sono sempre più collaborativi e cross-functional. I ruoli prima ben definiti adesso si stanno fondendo e i confini tra questi svaniscono. I job title e le opportunità di carriera stanno cominciando anch’essi a riflettere questo cambiamento: si vede “full-stack developer” o “product designer”. I tool che una volta erano di dominio esclusivo di specifiche discipline, vengono ora presi in prestito, condivisi e gli viene dato un nuovo scopo: fare il prototipo di un’animazione potrebbe richiedere di scrivere in JavaScript, mentre creare una libreria modulare di componenti potrebbe richiedere la comprensione del linguaggio visuale e delle teorie di design.

Se i tool usati sono troppo oscuri, i processi difficili da adottare, allora le opportunità di collaborazione diminuiscono. Rendete troppo complesso un sistema e l’onboarding di nuovi membri di un team diventerà difficile e time-consuming. Abbiamo bisogno di essere costantemente sicuri che il nostro lavoro sia accessibile agli altri.

Codice attento#section10

L’uso crescente delle front-end style guides è un esempio di una relazione che matura tra le discipline. Piuttosto che produrre layout statici e su misura, i designer stanno impiegando approcci più sistematici al design. I front-end developer li prendono e costruiscono delle pattern libraries e dei componenti modulari, un modo di delivery che rientra meglio negli approcci allo sviluppo backend.

Lo sviluppo component-driven ha visto l’introduzione di una successione di tool per venire incontro a questo bisogno. Tool come Less e Sass ci permettono di modularizzare, concatenare e minimizzare i fogli di stile, ma possono anche introdurre delle funzionalità procedurali in CSS, un linguaggio progettato intenzionalmente per essere dichiarativo e più facile da comprendere. Tuttavia, se prendiamo in considerazione gli altri membri del team, questa nuova funzionalità può essere usata per estendere l’insieme di feature dichiarative esistenti di CSS. Usando i mixin e le funzioni, possiamo inglobare un linguaggio di design all’interno del codice, e propagare le convenzioni di naming che sono comprese dall’intero team.

Convenzioni comuni#section11

Molto spesso, i problemi di processo non sono un limite impostato dalla tecnologia, ma una mancanza di volontà di applicare pensiero critico. Cercare di risolvere i problemi tecnologici adottando più tecnologia ignora il fatto che stabilire delle convenzioni può essere altrettanto utile e più semplice da adottare per gli altri.

La metodologia di naming BEM aiuta gli stili CSS a rimanere all’interno dello scope, incapsulati e più semplici da mantenere, tuttavia questo approccio non dipende da una particolare tecnologia: è semplicemente un insieme di convenzioni documentate. Se ne avessimo previsto il bisogno, avremmo usato BEM nel 2005. Una convenzione simile è quella dei namespace CSS, raccomandata da Harry Roberts. Usando prefissi codificati con una sola lettera implica che tutti quelli che lavorano a un progetto possono capire lo scopo di classi diverse e sapere in che modo dovrebbero essere usate.

Una lamentela comune per quelli che sperano di usare software come i preprocessori e i task runner è che spesso richiedono la conoscenza della riga di comando. I tool stuzzicano le nuove reclute con istruzioni di installazione di una riga, ma la realtà spesso implica molti grattacapi e giri inutili. Per controbattere a questo, GitHub ha creato Boxen, un tool che implica che chiunque nella propria azienda può far girare in locale un’istanza di GitHub.com sul proprio computer usando un solo comando. GitHub e altre aziende come Bocoup e il Financial Times sono sostenitori dell’utilizzo di comandi standard per installare, testare e far girare nuovi progetti.

Principi responsive, reattivi al cambiamento#section12

Dal momento che il responsive web design ci ha invitato a creare interfacce che vengono meglio incontro ai bisogno degli utenti, non sorprende che una discussione correlata si sia concentrata sempre di più sull’avere una maggior considerazione per gli utenti, il medium e gli uni per gli altri.

Se vogliamo costruire un web che sia veramente universale, poi dobbiamo abbracciare la sua natura imprevedibile. Dobbiamo ascoltare più da vicino l’intero spettro del nostro pubblico. Dobbiamo vedere opportunità per l’ottimizzazione dove prima vedevamo barriere in ingresso. E dobbiamo considerare i nostri colleghi maker in questo processo creando tool che ci aiuteranno a navigare insieme in queste sfide.

Questi principi dovrebbero dare forma al nostro approccio al responsive design e, a loro volta, potrebbero doversi adattare anche loro. Questo framework può guidarci, ma dovrebbe anche essere aperto al cambiamento man mano che continuiamo a costruire, sperimentare e imparare.

Illustrazioni: {carlok}