No. 205

La web community parla molto delle best practice di design e sviluppo: metodologie fondamentali per raggiungere gli utenti e trattenerli, attente abitudini di design e aree su cui dovremmo concentrarci come community.

Ma siamo onesti: ci sono molte aree su cui concentrarci. Dobbiamo mettere gli utenti in primo piano, il contenuto per primo e il mobile per primo. Dobbiamo progettare per l'accessibilità, per la performance e per l'empatia. Dobbiamo regolare e testare il nostro lavoro su molti device e browser. Il nostro contenuto deve catturare l'attenzione, parlare in maniera inclusiva e usare keyword appropriate per l'ottimizzazione SEO. Dobbiamo scrivere markup semantico e commentare il nostro codice per gli sviluppatori che verranno dopo di noi.

Le aspettative sul nostro lavoro sono maturate significativamente negli ultimi due decenni, insieme al panorama web. Ci sono molte cose da tenere presenti, sia che abbiate lavorato sul web per 20 anni o 20 mesi.

Se queste aspettative sono scoraggianti per quelli tra noi che si nutrono ogni giorno di sviluppo web, immaginatevi quanto alieni debbano sembrare questi concetti ai clienti che ci assumono per realizzare un sito o un'app: fanno affidamento su di noi in qualità di esperti che danno delle priorità a queste best practice, ma noi li deludiamo ripetutamente.

Per un certo numero di anni ho lavorato a stretto contatto con dei development vendor partner e altri professionisti del settore. Quando parlo con i development shop e gli chiedo dei loro standard di codice, dei workflow e dei metodi per mantenere consistenza e best practice nei team di sviluppo distribuiti, sono continuamente stupita dal sentire che spesso, la maggior parte delle best practice che ho elencato nel primo paragrafo non fanno parte di alcun progetto di sviluppo a meno che il cliente non ne faccia esplicita richiesta.

Riflettete su questo.

I development shop fanno affidamento sul communication team in un'agenzia finanziaria per sapere se è richiesto che il loro codice sia ottimizzato per la performance o l'accessibilità. In questo caso, mi espongo e dico che questo non dovrebbe essere il lavoro del cliente: noi siamo gli esperti, noi comprendiamo la strategia web e le best practice ed è ora che agiamo di conseguenza. È ora di smettere di parlare di ognuno di questi principi in maniera visionaria e cominciamo ad implementarli come nostre core practice. Ogni volta. Di default.

Che lavoriate in un dev shop interno o per clienti esterni, probabilmente avete clienti il cui focus è la realizzazione di obiettivi di business. I clienti vengono da voi, l'esperto tecnico, per essere aiutati nel raggiungimento dei loro obiettivi di business nel modo migliore possibile. Potrebbero conoscere un po' del gergo del web che possono usare per avviare la conversazione, ma spesso si concentreranno su elementi superficiali del progetto. Quasi tutti i clienti si preoccuperanno più delle loro hero image e della palette di colori piuttosto che di qualunque altro pezzo del loro progetto. Questo non cambierà e va bene così, perché non sono loro gli esperti del web. Non è il loro lavoro. È il vostro lavoro.

Se voglio costruire una casa, assumerò degli esperti per progettare e costruire detta casa. Dovrò fare affidamento sugli architetti, sui muratori e sui carpentieri per sapere che materiale usare per le fondamenta, dove costruire i muri portanti e dove mettere le tubature e l'impianto elettrico. Non conosco le leggi e i regolamenti in materia di costruzioni per essere sicura che la mia casa resisterà ad una tempesta. Non conosco nemmeno le domande che dovrei fare per scoprirle. Devo fare affidamento sugli esperti per progettare e costruire una struttura che non crollerà e poi passerò il mio tempo a scegliere i colori della vernice e a cercare un tappeto che unisca gli elementi della stanza.

Questa analogia si applica perfettamente ai professionisti del web. Quando i clienti ci assumono, contano su di noi per architettare qualcosa di stabile che soddisfi gli standard e le best practice del settore. I nostri clienti business non sanno che domande fare o in che modo guardare nel codice per essere sicuri che aderisca alle best practice. Sta a noi come professionisti del web sostenere i principi di design e sviluppo che avranno un forte impatto sul prodotto finale ma che sono invisibili ai nostri clienti. Sono questi elementi quelli a cui i nostri clienti si aspettano che noi diamo delle priorità e non devono nemmeno conoscerli. Proprio come noi ci affidiamo agli architetti e ai muratori per costruire case su fondamenta solide con una struttura ben salda, così dovremmo progettare i nostri siti su una base solida di codice.

Se il nostro lavoro non segue questi principi di default, noi deludiamo i nostri clienti

Quindi, a cosa diamo la priorità e in che modo arriviamo a questa decisione? Se tutto è di importanza cruciale, allora niente lo è. Mentre i nostri clienti si concentrano sui colori e sulle immagini (e, se siamo fortunati, sul contenuto), dobbiamo concentrarci sulla realizzazione di fondamenta solide che invieranno il contenuto agli utenti finali in maniera affidabile, efficiente e bella. Come dovremmo sviluppare quelle solide fondamenta? La cosa migliore è dare la priorità a una base di codice che aiuterà il nostro messaggio a raggiungere il pubblico più vasto, nella maggior parte degli use cases. Per giungere al nodo della questione di una filosofia di sviluppo user first, dobbiamo trovare i principi che hanno il maggior impatto ma che non sono ancora impliciti nel nostro processo.

Come minimo, tutto il codice scritto per un pubblico generico dovrebbe essere:

  • responsive
  • accessibile
  • performante

Più nello specifico, non è sufficiente aderire a parole a quelle frasi ad effetto per presentarsi come un dev shop “serio” e fermarsi lì. I nostri design responsive non dovrebbero semplicemente aggiustare il flusso e la dimensione degli elementi a seconda della larghezza del device, ma dovrebbero anche tenere in considerazione il caricamento di immagini di dimensioni diverse e varianti di background basate sui bisogni del device. Gli standard di programmazione accessibile dovrebbero essere basati sugli standard più recenti, le WCAG 2.0 (Level AA), comprendendo che la programmazione per un accesso universale beneficia tutti gli utenti, non solo una piccola percentuale (insieme con la comprensione che le aziende i cui siti non rispettano questi standard possono essere citati in giudizio per mancanza di compliance). L'ottimizzazione della performance dovrebbe pensare al modo in cui le dimensioni delle immagini, gli script e il caching possono migliorare la velocità di page load e diminuire la dimensione totale dei files in ogni interazione.

Tutti questi aspetti richiedono tempo? Ovviamente. I team di sviluppo potrebbero addirittura aver bisogno di istruzione aggiuntiva e i team grandi dovranno essere normativi su come integrare tutto ciò nei workflow stabiliti. Ma più questi principi vengono costruiti nelle funzioni principali di tutti i nostri prodotti meno tempo richiederanno e migliori saranno tutti i nostri servizi.

Come ci arriviamo?

Sul lungo periodo, dobbiamo aggiustare i nostri workflow così che sia i front-end sia i backend developer inseriscano queste best practice nei propri processi e metodologie di programmazione di default. Dovrebbero far parte della nostra cultura aziendale, degli screening dei colloqui, dei nostri value statement, dei nostri script di QA testing e delle nostre code validation. Proprio come nessuno penserebbe più di costruire un layout per un sito web usando le tabelle e le immagini spacer da 1px (ringraziamo tutti i webmaster della vecchia scuola là fuori), dovremmo raggiungere il punto in cui fa ridere pensare di progettare un sito web a larghezza fissa o creare un prompt per il caricamento di un'immagine senza il campo alt.

Se siete un freelance developer o una piccola agenzia, questo cambiamento di filosofia o focus dovrebbe essere più semplice da raggiungere piuttosto che se fate parte di un'agenzia più grande. Come succede ogni volta che voi e il vostro team espandete e maturate il vostro insieme di skill, dovrete valutare quante ore extra sono necessarie per l'apprendimento iniziale delle nuove pratiche. Ma di nuovo, ognuno di questi principi diventa più veloce e più semplice da ottenere una volta che è inserito nel workflow.

Ci sono moltissimi libri, blog, checklist e how-to a cui si può far riferimento per il design responsive, per rendere i siti accessibili e per migliorare la performance. I framework responsive esistenti possono agire come punto di partenza per lo sviluppo responsive. Dopo aver sviluppato un layout e un flusso omnicomprensivo, i principali rallentamenti per il contenuto responsive si sollevano nel trattamento delle tabelle, delle immagini e degli elementi multimediali. Dovrete pianificare delle revisioni per pensare al modo in cui i vostri layout appariranno nei vari breakpoint. Un tool come embedresponsively.com può velocizzare il processo di inserimento di contenuti esterni.

Molti gap di accessibilità possono essere colmati usando un markup semantico invece di rendere ogni elemento come un div o uno span. Nessuno dei requisiti di accessibilità del codice dovrebbe prendere molto tempo una volta che lo sviluppatore acquisisce familiarità con questi. La a11y Project’s Web Accessibility Checklist fornisce un modo semplice ai front-end developer per rivedere il proprio stile di programmazione generale e imparare come sistemarlo per renderlo più accessibile di default. In effetti, scrivere markup davvero semantico dovrebbe accelerare il tempo di progettazione CSS quando è più semplice avere come target gli elementi su cui si è davvero concentrati.

Più ci si concentra sulla soddisfazione di ciascuno di questi principi nelle fasi iniziali dei nuovi progetti, più rapidamente diventeranno la maniera di default di sviluppare e il tempo che si passa su di essi diventerà una parte di default del processo.

Mantenere la concentrazione

Una cosa è dire al vostro team che volete che tutto il codice che sviluppano sia responsive, accessibile e performante, un'altra cosa completamente è assicurarsi che ci si arrivi. Che siate uno sviluppatore che lavora da solo o che gestisce un team di sviluppatori, avrete bisogno di avere dei sistemi che vi permettano di mantenere il focus. Assicuratevi che i vostri sviluppatori abbiano la conoscenza richiesta per implementare il codice e le tecniche che soddisfano questi bisogni e integrate con la formazione nel caso non l'avessero.

Scrivete dei value statement. Postate elenchi. Chiedete in ogni fase cosa si potrebbe aggiungere al processo per essere sicuri che questi principi centrali vengano presi in considerazione. Quando dovete assumere un nuovo talento, potete aggiungere delle domande nel processo del colloquio per essere sicuri che i nuovi membri del team siano già in pari e abbiano gli stessi vostri valori e la vostra stessa dedizione alla qualità fin dal primo giorno.

Includete dei checkpoint all'interno di ogni fase del processo di design e development per essere sicuri che il proprio lavoro continui nella direzione di un prodotto finale completamente responsive, accessibile e performante. Per esempio, potete aggiustare il processo di design perché cominci con dei wireframes mobile per allontanare il modo di pensare del team dal progettare per il desktop e poi cercare di sistemare i layout mobile e tablet. Un altro checkpoint dovrebbe essere inserito quando si determinano le palette di colori per testare gli insiemi di colori in primo piano e di sfondo per avere un contrasto tra i colori accessibile. Aggiungete uno step per far passare i files delle immagini in un compressore prima di caricare un qualunque asset grafico. Chiedete ai designer di usare i web font in maniera responsabile, non come se fosse un automatismo. Impostate un performance budget e create step per controllare la performance durante il percorso. Presto, il vostro team “saprà” semplicemente quali feature o practice tendono a creare dei problemi di performance e quali vanno bene. Dovrete essere sicuri che anche i test e le code review controllino queste cose.

Nulla che valga la pena fare accade per caso. Ogni volta che non badiamo alle nostre responsabilità come designer e developer perché si fa prima a prendere delle scorciatoie, i nostri prodotti soffrono e il nostro settore nel suo insieme soffre. Come professionisti del web, il modo in cui lavoriamo e le cose a cui diamo la priorità quando nessuno guarda fanno la differenza in migliaia di piccoli modi per migliaia di persone che non incontreremo mai. I nostri clienti e i nostri utenti dipendono da noi.

Share/Save/Bookmark
 

Discutiamone

Ti sembra interessante? Scrivi tu il primo commento


Cenni sull'autore

Kendra Skeene

Kendra Skeene supervisiona la piattaforma web open source dello stato della Georgia. Come parte del team GeorgiaGov Interactive, sostiene iniziative per piattaforme responsive e accessibili, tra i molti altri miglioramenti focalizzati sull'utente. Seguitela su Twitter.

Questo sito per poter funzionare utilizza i cookie. Per saperne di più visita la pagina relativa all' INFORMATIVA