Mentre si fa un gran parlare (e giustamente) di servizi web, rimane sempre fuori dai radar una voce di costo informatico estremamente rilevante nella PA italiana: quella per lo sviluppo dei software a uso dei dipendenti. Nei più svariati settori: dagli uffici anagrafe, ai servizi sociali, al catasto, all’ambito medico-sanitario.
Il tema si interseca con quello dei servizi online rivolti al cittadino. Perché spesso questi operano sugli stessi “oggetti”, e spesso con funzioni simili, a quelli di questi software che possiamo chiamare di back-office. Ad esempio, se un cittadino può, che ne so, prenotare esami sanitari online grazie a un nuovo servizio online della sua Azienda Sanitaria, la funzione dovrà in qualche maniera utilizzare lo stesso database di prenotazioni sul quale opera anche il software dell’operatore dell’ufficio prenotazioni che riceve i cittadini allo sportello.
E così via: ogni cosa che si mette online per il cittadino, non opera in solitudine (tranne rari casi) ma interopera con basi di dati già esistenti su cui operano altri software, a volte di molte generazioni fa (quindi con logiche molto diverse da quelle che operano oggi attraverso le tecnologie web attuali).
La moltiplicazione dei software e dei pesci
Questa interoperabilità è ovviamente un problema. Ma c’è un altro problema, altrettanto occulto: il fatto che molti soldi vengano spesi per realizzare adattamenti continui alle nuove normative o alle modifiche delle stesse.
Un esempio su tutti.
Quando è stato introdotto il SIA, sostegno al reddito sperimentato in alcune regioni, le aziende informatiche regionali hanno dovuto (o avrebbero dovuto…) realizzare dei software per l’apertura della pratica con il cittadino che ne facesse richiesta, che comprendesse la registrazione dei dati, delle firme sui moduli, il possesso dei requisiti, l’accettazione delle condizioni, il calcolo dei parametri economici. A volte queste procedure richiedono una comunicazione fra diversi uffici (per esempio con i Centri per l’Impiego, o l’INPS). Insomma, sono cose che devono essere usate dagli operatori pubblici ogni giorno, se si vuole che il provvedimento venga attuato.
In molti casi l’applicazione dei provvedimenti come il SIA varia da regione a regione, a volte viene attuata in modo diverso anche in parti diverse della stessa regione: questo si traduce naturalmente in una moltiplicazione dei costi.
Spesso poi i tempi di implementazione delle misure normative sono estremamente accelerati, anche per ragioni di comunicazione politica. Questo fa mancare altrettanto spesso i tempi tecnici per un’analisi e una progettazione efficace, lasciamo stare orientata al cittadino, di questi software. Che poi vengono corretti in corsa. Quando vengono corretti, intendo…
Quando i costi si scaricano sui dipendenti
A volte si verificano casi in cui gli operatori pubblici sono costretti a iniziare a implementare le misure senza avere ancora la disponibilità del software. Raccolgono documentazione cartacea, obbligandosi poi a reinserire i dati nel sistema informatico non appena il software viene rilasciato.
Ma non solo: a volte, semplicemente, proprio per una scarsa linearità e prevedibilità delle norme, insomma, per incertezza politica, si preferisce aspettare prima di realizzare il software. Magari la norma cambia. Formalmente quindi la misura, la policy inizia ad essere attuata, ma senza fornire ai dipendenti gli strumenti per farlo.
Questo rende l’implementazione delle politiche inefficaci, e sicuramente la produttività dei dipendenti si abbassa… ma non per colpa loro! Quando si parla di inefficienza della PA, i media generalisti forse dovrebbero iniziare a parlare non solo dei “furbetti del cartellino”, che ci sono, ma sono una minoranza; ma pure delle condizioni nelle quali i dipendenti pubblici che vogliono lavorare si trovano costretti a operare. Non solo a livello informatico: ma anche a livello informatico.
Cambiare per cambiare, non importa a quale costo
Ma c’è dell’altro. Nell’esempio del SIA di cui s’è detto sopra, la sperimentazione è partita in alcune regioni da pochi mesi, e da poco si è deciso di sostituirla con una misura differente, il REI, reddito di inclusione. Ebbene, senza entrare nel merito dei singoli provvedimenti, che non ci competono: qualcuno si è posto il problema di quanto costi modificare/adattare i software per attuare questi cambi di politiche? Passare da una misura all’altra, dal punto di vista degli strumenti informatici?
E, se queste modifiche non vengono realizzate per ragioni di tempo o di costi, quanto ci costi in ore uomo buttate il lavoro dei dipendenti che sono costretti a operare senza lo strumento informatico, o con uno strumento informatico inefficiente, che provoca errori, danneggia i cittadini e aumenta lo stress lavoro-correlato?
E’ chiaro che una sperimentazione va fatta, per politiche di questo genere: ma non sarebbe meglio in quei casi evitare di produrre software diversi, per poi trovarsi ad aggiornarli o a sostituirli, e partire subito con un software unico per le diverse realtà locali che si candidano alla sperimentazione, magari fornito dallo Stato, e già pensato per eventuali successive modifiche qualora dalla sperimentazione si passasse a una misura definitiva?
Il sistema operativo delle applicazioni pubbliche
In tempi di design-jam, di codesign e di linee guida, utili ma ancora lente a produrre servizi online per il cittadino, vi è tutto un capitolo di produzione informatica grosso, rilevante, e completamente occulto nella PA italiana che contribuisce all’inefficacia e all’inefficienza della macchina amministrativa. E, no, non sono i dipendenti. Non sono le regole tecniche. Sono le decisioni dall’alto.
E’ possibile che l’annunciato “sistema operativo della PA” in fase di realizzazione dal team guidato da Diego Piacentini possa rendere presto più semplice sia la rapida implementazione di strumenti software (anche realizzati da soggetti diversi, che si troverebbero parte dell’infrastruttura realizzata e API ben definite), che più rapida una loro modifica. Togliendo discrezionalità alle molte aziende private che ci lavorano, velocizzando al tempo stesso il loro lavoro. Ce lo auguriamo, perché di questo ci sarebbe davvero bisogno, anche più di SPID.
Un’interessante articolo del programmatore Quincy Larson racconta molto meglio degli articoli della stampa generalista il dilemma che abbiamo davanti, come “operatori dell’informatica”. Uso questo termine, perché, anche se Larson la vede dal lato programmatore, il problema riguarda tutti noi: designer, analisti, progettisti dell’esperienza, esperti di interfacce, di usabilità, di architettura dell’informazione, di service design, e quante altre etichette volete assumervi.
Ed è un problema etico. Per nulla teorico, però.
Larson racconta fatti noti e meno noti di come 3 grandi aziende abbiano mentito, tratto profitto e ingannato, al punto da prendersi l’accusa di aver causato delle morti, grazie al software.
Uber, ovvero, come ti aggiro le leggi senza che tu lo sappia
Nelle città in cui non è ancora concesso a Uber di operare, a volte poliziotti in borghese tentano di prendere un passaggio sull’app Uber, con l’obiettivo di multare il conducente in flagrante. Uber ha trovato il modo di evitare i controlli di polizia in un modo molto ingegnoso: identifica i poliziotti sotto copertura riconoscendoli attraverso un incrocio di dati, sia dai social, sia, forse da altre fonti (Larson parla di una banca dati di carte di credito usate dalla polizia). Quando l’utente identificato come appartenente alle forze dell’ordine cerca il passaggio Uber, l’app mostra (a lui, e solo a lui) delle macchine fantasma. Che non esistono, e che lui non vedrà mai arrivare, perché l’app gli mostrerà che devono fermarsi a prendere un altro cliente, o che sono dirette altrove.
Di fatto, il poliziotto non riuscirà mai a incastrare alcun autista Uber abusivo. E rimarrà semplicemente convinto di essere sfortunato, e di non riuscire a prendere un passaggio perché capita sempre nel posto sbagliato al momento sbagliato.
Questa tecnologia, chiamata Greyball, è stata in uso dal 2014, ed è stata sfruttata sia in alcune città USA, come Portland, Las Vegas e Boston, sia a Parigi, in Australia, Cina e Corea del Sud.
Dopo essere stata svelata dal New York Times, e come risposta anche ad altre controversie, Uber ha annunciato una revisione del modo in cui questa tecnologia è stata usata, e ne ha proibito l’uso per aggirare l’intervento delle forze dell’ordine. Attualmente è in corso un’inchiesta federale sull’uso di Greyball dai potenziali risvolti penali.
Zenefits, o il più classico degli imbrogli sulla formazione
Ok, visto come noi in Italia sfruttiamo i soldi europei per la formazione, creando una miridade di corsi inutili, con il tasso di occupazione a seguire fra i più bassi d’Europa, può sembrare una frode ridicola. Ma se prendiamo sul serio le garanzie, non lo è. Zenefits produce software per la gestione di uffici assicurativi. Nel 2016 si è scoperto che, grazie a una estensione proprietaria per il browser, aveva aiutato le agenzie a far saltare ai nuovi assunti un corso online obbligatorio per avere l’abilitazione a operare come agenti assicurativi.
52 ore di corso, con tanto di quiz annessi, saltate, per consentire alle agenzie di sfruttare quelle ore facendo lavorare subito i nuovi arrivati. Un bel risparmio per le agenzie, una bella garanzia in meno per il cliente. Un imbroglio per i certificatori.
Volkswagen, le emissioni differenziali e i 60 morti
Lo scandalo emissioni del 2015 della Volkswagen è noto a tutti, perché abbastanza clamoroso da arrivare sui telegiornali nazionali. Meno noto è il meccanismo usato. In pratica, un software era in grado di identificare i pattern di regolazioni e parametri usati dagli ispettori per il test sulle emissioni, perché evidentemente differivano da quelli di uso comune.
Il resoconto delle emissioni veniva dunque alterato, ma, appunto, solo per le ispezioni.
In pratica, è come se il software funzionasse normalmente, e non fosse ingannevole, tranne durante i test. L’interfaccia di output mentiva, ma solo a poche specifiche domande: quelle che ponevano gli ispettori.
L’andamento del titolo Volkswagen con il crollo in corrispondenza dello scandalo di settembre-ottobre 2015
Rispetto agli altri casi citati, questo è anche il più grave. Volkswagen è accusata di aver venduto 10 milioni di macchine che inquinavano fino a 40 volte il limite consentito (negli USA).
Stime del MIT sostengono che questo avrebbe contribuito ad un aumento del cancro ai polmoni, causando una morte prematura di 60 persone solo in America.
Il farmaco adatto a tutte le situazioni
Un altro autore, Bill Sourour, in un altro articolo fa un altro esempio personale, risalente a diversi anni fa, quando venne incaricato di realizzare un sito informativo di carattere medico-sanitario. Questi siti avevano il divieto di reclamizzare direttamente dei farmaci, così il committente aveva richiesto che il sito ponesse domande all’utente sui propri sintomi e poi, qualunque fossero le risposte (tranne in caso di accertata allergia ai componenti, suppongo per evitare cause legali) che l’utente venisse comunque rimandato alla reclame di un farmaco specifico, sempre lo stesso, fingendo che fosse una scelta basata sulle sue risposte.
L’autore scoprì poco dopo aver realizzato l’algoritmo che il farmaco era sotto accusa perché aumentava, in una piccola percentuale di utilizzatori, le tendenze suicide!
Non è tutto: Sourour scoprì poco dopo che la sorella assumeva il farmaco e fece di tutto per convincerla ad abbandonarlo, per fortuna con successo. Naturalmente, non si sentì benissimo ad aver realizzato il software che guidava l’utente sul sito, e poco dopo si dimise dall’agenzia web per cui lavorava.
Il codice può mentire. E lo fa attraverso le interfacce
Qui però ci troviamo di fronte a software che mentono consapevolmente. Ed è ancora più facile che farlo di persona, perché non c’è il contatto diretto con le persone (come nel front-end degli sportelli o nei call-center). E’ facile per i progettisti sentirsi a posto con la coscienza, anche se sanno che stanno progettando un meccanismo fraudolento, perché in realtà non lo stanno somministrando loro: svolgono solo un lavoro.
Ma dovrebbe essere ancora più chiaro che non è il codice a mentire: il codice fa quello che gli diciamo di fare. Il codice è il nostro discorso, la nostra retorica, l’architettura delle azioni e delle reazioni che noi progettiamo.
Poiché il codice è nascosto, sono le interfacce, quelle che alla fine dicono il vero o mentono. Perché è attraverso la componente di interfaccia che il codice agisce e si fa capire, si relaziona con gli utenti. Di questo potenziale manipolatorio avevamo già parlato in passato, e sappiamo che anche i social hanno un forte orientamento persuasivo. Qui andiamo ancora oltre: non modifichiamo solo la probabilità dei comportamenti, ma mentiamo agli utenti attraverso il codice.
Un codice etico è in realtà già in vigore per i membri dell’American Computer Machinery (ACM), la principale associazione e comunità di pratiche in ambito informatico. Ciò non ha impedito che anche in realtà informatiche nordamericane si realizzassero pratiche fraudolente attraverso il codice.
L’ACM sta provando ad aggiornare il proprio codice etico, con il progetto di licenziarlo entro il 2018.
Ma, proprio come i codici etici in ambito medico non garantiscono da medici imbroglioni, come potrà un nuovo codice etico in ambito informatico garantirci dalla presumibile crescente pressione da parte dei committenti a produrre codice e interfacce che servano soprattutto a difendere i loro interessi, piuttosto che il bene della società nel suo insieme?
Esiste un modo legale per difendersi?
Il tema da porsi è semmai se l’attuale impianto legislativo e sanzionatorio sia adeguato a scoraggiare comportamenti che poi, una volta messi in atto, sono difficili da scoprire, perché “nascosti” dietro algoritmi chiusi in una scatola nera, che potrebbero anche non rivelarsi mai come truffaldini in modo palese, se l’interfaccia mente bene. E molto diversi dalle tradizionali “frodi informatiche” di cui si parla di solito sui giornali, associate a imprecisati soggetti oscuri, esperti informatici solitari che agiscono individualmente o per conto del miglior offerente. No, qui parliamo di software ufficiali di grandi gruppi.
Il problema diventa quindi di metodologie di controllo, in primis, e in seguito di meccanismi di sanzione.
Un tema molto difficile da affrontare, e su cui è molto probabile continueremo a interrogarci ancora a lungo.
L’articolo di oggi ricalca in parte l’intervento che feci al World Usability Day di Torino nello scorso novembre, e si focalizza sui problemi che sembrano esserci con l’approccio mobile-first alla progettazione dei siti web. Almeno per come lo intendiamo noi oggi.
Partendo da alcuni dati, vediamo cosa sembra non andare in questo approccio, come alcuni grandi gruppi scelgano di interpretarlo, e cosa dovremmo comunque fare noi, nel nostro piccolo (più o meno grande che sia). Buona lettura!
nasce per mettere a disposizione di tutti il codice sorgente, un moderno sistema per la gestione della documentazione e gli strumenti di interazione per coordinare e sviluppare i progetti digitali della pubblica amministrazione in modo più efficace e veloce, con l’obiettivo di creare un ambiente aperto, in grado di promuovere l’interazione con gli sviluppatori del settore pubblico e privato.
Si tratta di un primo passo per realizzare quello che Piacentini aveva chiamato, in un post su Medium dello scorso dicembre, il sistema operativo del Paese. In sostanza, si condivide codice e documentazione, attraverso piattaforme collaborative, per facilitare tutti coloro che devono realizzare servizi pubblici online. Evitare doppioni, usare il più possibile documentazione condivisa, API aperte, e tutto ciò che potrebbe rendere i servizi fra loro interoperabili, omogenei e più economici.
Sviluppatori aperti, appalti opachi
Le dichiarazioni d’intenti sono tutte ottime. Al momento però è presto per dire la direzione che prenderà il progetto e soprattutto per capirne l’efficacia. L’informatica pubblica in Italia è, sfortunatamente, gestita attraverso appalti elefantiaci, appannaggio di poche grosse e grossissime aziende, che non sempre hanno l’efficienza come primo obiettivo, anche perché devono mantenere strutture corpose e, sostanzialmente, pagare un sacco di stipendi.
Problema che non è solo italiano, e che in USA e UK viene affrontato, non senza qualche polemica, dando spazio anche a gruppi più piccoli di sviluppatori. In teoria, condividere codici, documentazioni e standard dovrebbe aiutare a far lavorare di più i piccoli. Ma dico in teoria: perché ovviamente è sugli appalti che bisognerebbe intervenire, e in generale sui controlli interni ai progetti. Spesso carenti – anche laddove gli appalti li prevedano – per ragioni troppo complesse per esaminarle in queste poche righe.
Due rischi dietro l’angolo
Altri due rischi del progetto è che venga usato con delle finalità non dichiarate:
La prima, di copertura: sostanzialmente un richiamo mediatico alla cultura della condivisione in rete, che si traduca in una piattaforma poi poco praticata e di fatto irrilevante per i progetti che contano; intanto però si guadagna tempo e si spinge sulla retorica dell’innovazione, poi si vedrà. Speriamo ovviamente che non sia così, e la concretezza degli scopi di questa piattaforma fa ben sperare.
La seconda è quella della dell’uso del nome “comunità” per un luogo dove si fa in realtà una comunicazione unidirezionale e gerarchica; le comunità di solito funzionano se sono ben gestite, moderate, e se danno vantaggi a tutti i partecipanti. Il Team di Piacentini dovrà quindi attivamente dedicare risorse anche alla moderazione della comunità, renderla un canale realmente interattivo, altrimenti rimarrà, come per altre comunità pubbliche con scopi analoghi, un guscio vuoto.
Il nuovo che cancella il vecchio; che poi cancella il nuovo
C’è poi un’ulteriore idea che serpeggia dietro questo modo di portare avanti le strategie digitali. Quella secondo cui tutto quello che è stato fatto e tutte le competenze interne alla PA degli ultimi anni siano inutili. E quindi sarebbe meglio spazzarle via con continui “nuovi inizi”, nuovi progetti. Sappiamo invece – ma lo si ricorda poco nei continui pianti su quanto male vanno le cose digitali in Italia – che nella PA è all’incirca dal 2008 che le cose sono peggiorate. Magari non eravamo i primi in Europa neanche prima, ma dal 2008 al 2014 siamo semplicemente peggiorati, mentre gli altri hanno fatto passi avanti.
Potenziare ciò che c’era e che funzionava, indicarlo chiaramente, potrebbe anche servire a conquistare una maggior adesione da chi nella PA ci lavora, adesione senza la quale, s’è visto, i progetti di rinnovamento radicale e ambizioso sono destinati al fallimento.
Vedremo: sono tutti dubbi che solo il tempo dissiperà. Siamo ai primi passi di un tentativo di “cambio di direzione” in logiche molto complesse e stratificate. Non pensiamo sia semplice, non abbiamo soluzioni alternative da proporre, tranne forse di essere concreti e onesti: proporre cose utili e giuste, attraverso queste piattaforme, e non solo imporre decisioni magari discutibili. Fare in modo di avere davvero una comunicazione bidirezionale, ed essere realmente aperti ai buoni contributi, se arriveranno. Il nostro augurio è che tutto vada per il verso giusto, e che i risultati superino le aspettative.
Male che vada, comunque, almeno non rimarremo a corto di comunità online…
Anche quest’anno nel mondo si terrà il World Usability Day, giornata mondiale per la tecnologia a misura d’uomo. E anche quest’anno ci saranno più sedi in Italia: se l’anno scorso sono stato ospite a Roma, quest’anno avrò il piacere di tornare a Torino, dove il tema della sostenibilità sarà declinato come “User eXperience e il paradigma della circolarità di prodotti e servizi”. Lo svolgimento avrà -come si intuisce dal titolo – una logica come sempre multidisciplinare.
Il mio intervento affronterà però un tema specifico di progettazione web, con un breve intervento introduttivo nelle sessioni mattutine e un workshop nel pomeriggio. Il workshop ha l’impegnativo titolo di “Principi, linee guida e pattern ai tempi del mobile-first. Come riutilizzare la conoscenza per velocizzare un design (riutilizzabile) su web”.
Affronta, o tenta di affrontare, un tema i cui prodromi si possono trovare già in quest’articolo. In pratica, è come evitare che il mobile-first sia l’occasione per rovinare tutto, e si trasformi invece in opportunità, rendendo i siti mantenibili nel tempo e i pattern opportunamente riutilizzabili.
Per chi è interessato, vi aspetto a Torino il 10 novembre prossimo!
Il mobile-first è una filosofia di progettazione sorta attorno al 2009 secondo la quale per accomodare i siti alla fruizione da molti canali (desktop, tablet, smartphone…), e in generale con molte dimensioni dello schermo diverse (qui ne ho parlato tempo fa), è bene partire progettando il sito per il mobile, cioè la situazione con più vincoli, e poi farne una versione arricchita per i dispositivi più grandi.
Ma è efficace? Alcuni dati sembrano suggerire qualche dubbio in merito.
Questione di numeri, alla fine
La ragione principale per dedicare attenzione progettuale fin dall’inizio ai dispositivi mobili sta naturalmente nella loro crescente diffusione, con una quota di visita sempre crescente nei confronti del desktop. Questo vecchio grafico ci mostra che abbiamo già superato il punto di svolta.
Dal 2014 gli utenti globali provenienti da mobile superano quelli provenienti da desktop. Ma questo non rende il desktop meno importante, come vedremo.
Ma l’esigenza di un miglior metodo progettuale per i siti mobili deriva anche dall’osservazione che nei test di usabilità sugli smartphone e nelle statistiche d’uso degli accessi da mobile le persone tendono:
a trovare meno facilmente le informazioni,
a completare un minor numeri di transazioni,
ad avere maggiori abbandoni e
a rimanere per minor tempo sulle pagine.
In altre parole, tutti i parametri di comportamento utente sono peggiori sul mobile che sul desktop.
Un obiettivo importante di una logica mobile-first sarebbe quindi quello di alzare questi parametri, avvicinandoli a quelli del destkop.
L’efficacia (o l’assenza di-) del mobile-first
Per capire se ci stiamo riuscendo dovremmo avere dei dati di efficacia mobile vs desktop, prima e dopo l’adozione di questo approccio. Per capire se, cioè, i siti mobile-first funzionano meglio, per l’utente, sul mobile, senza nel frattempo perdere performance lato utente sul desktop.
Le prime risultanze non sembrano favorevoli.
Nel 2009 la differenza era circa del 20%
I dati di Nielsen sui test di usabilità su mobile, tanto per avere un punto di riferimento, risalenti al 2009, prima cioè che la strategia si diffondesse, dicono alcune cose:
Che il tasso di successo per i siti mobili era sensibilmente più basso dei loro corrispondenti usati da desktop (circa 20 punti percentuali di differenza)
Che siti ottimizzati, costruiti per il mobile avevano tassi di successo più alti di circa 10 punti rispetto ai siti non ottimizzati per mobile, quando usati da mobile.
Questi risultati sembravano confermare che ci fosse bisogno di siti pensati per il mobile. E che solo così avremmo potuto alzare il tasso di successo e gli altri parametri.
Dati parziali recenti su siti costruiti con pattern mobile-first mostrano una differenza del 17%
Da due test di usabilità recenti che ho avuto modo di coordinare e svolti su siti realizzati secondo logica mobile-first e testati sia su mobile che su desktop (per ciascun sito 8 utenti mobile e 8 utenti desktop, per un totale di 32 partecipanti testati), risulta che il tasso di efficacia sullo stesso sito è di circa 17 punti percentuali più basso se viene fruito da mobile.
Avete capito bene: erano 20 nei dati di Nielsen del 2009, sono 17 nei primi test attuali.
Possiamo leggerlo come un miglioramento, ma siccome non abbiamo campioni elevati noi, e non è dato sapere il numero del campione di Nielsen, il risultato potrebbe collocarsi all’interno del margine d’errore, e potrebbe non esserci alcuna differenza reale fra i due dati!
Ma se c’è, è evidentemente molto piccola. Tutto questo sette anni dopo e su siti appena ridisegnati!
Ad aggiungere alltri dubbi ci sono le statistiche. Su pressoché ogni sito mobile-first di cui ho modo di vedere le statistiche, le visite da mobile hanno ancora parametri più bassi delle visite da desktop, esattamente come prima dell’approccio mobile-first.
In altre parole: alcuni dati (parziali e limitati quanto vogliamo, e urge senz’altro raccoglierne degli altri) ci suggeriscono che non sembra funzionare. O, se davvero c’è un miglioramento, è ridicolmente esiguo.
Perché succede?
Non fidatevi, insisto: valutate le statistiche dei vostri siti, guardate il tempo in pagina, le pagine viste per visita, i tassi di conversione e ogni altro parametro che risulti utile al vostro modello di business, per visite da mobile e da destkop. Comparateli con quelli che avevate prima dell’adozione di una logica mobile-first.
Se anche nel vostro caso non si vedono grandi differenze, e i dati da mobile rimangono più bassi, abbiamo un problema.
Le ragioni di questo problema possono essere diverse.
Potrebbe essere che il mobile-first lo stiamo facendo male. Non è una ipotesi da escludere. Infatti il mobile-first si è diffuso più come una moda con i temi pronti per i blog e i cms, da installare e utilizzare, che come esito di un vero processo di progettazione. Quindi, temi che devono essere soprattutto belli sulla vetrina del negozio online che vende il tema stesso, applicati con minime personalizzazioni su blog o siti portfolio o vetrina, hanno influenzato i pattern di interazione usati anche negli altri siti. Voci di menu ridotte o scomparse, colonna unica o quasi, spazi larghi e vuoti, riduzione della densità informativa: questo è ciò che del mobile-first si sta vedendo soprattutto in giro. Anche in recenti e costosi redesign di nostri gruppi bancari: il che testimonia come minimo il rischio che il mobille-first sia stato usato come una moda, che i designer lo interpretino come un “mobile-only”, ovvero un tema mobile che su desktop ingrandisca semplicemente testi, bottoni e spazi vuoti, e che quindi venga meno il senso profondo di una progettazione per scenari.
Oppure potrebbe essere che il mobile-first, come logica, filosofia e strategia non funzioni.
A prevalere è il mix di fruizione, perciò le grandi aziende non adottano il mobile-first
I dati provenienti da ComScore, azienda statunitense specializzata in analytics, suggeriscono proprio questo: forse il mobile-first è sbagliato!
Quello che si sta vedendo dai dati generali di fruizione, è proprio che, mentre gli utenti mobili sono più di quelli desktop, la maggior parte delle transazioni avviene comunque su desktop, anche perché – dato trascurato – la maggior parte degli utenti visitano lo stesso sito da diverse piattaforme! Sono i cosiddetti “multi-piattaforma”, che come si vede da questo grafico, sono saldamente la maggioranza degli utenti che visitano i siti web:
Dati ComScore sulla prevalenza di visite multipiattaforma – ovvero lo stesso utente che visita il sito sia da mobile che da tablet o desktop – richiedendo così un design coordinato ma adattato e ottimizzato per entrambe le piattaforme
Questo, unito al fatto che le transazioni sono comunque maggiori sui siti “grandi” (tablet o desktop) fa sì che:
Il sito desktop è ancora più importante per generare traffico utile e remunerativo, quindi l’attenzione progettuale su questa versione del sito deve essere massima e non può essere solo un “adattamento” o un “allargamento” della versione mobile
Entrambe le versioni, desktop e mobile, devono essere coordinate, cioé devono fornire esperienze simili; e, tenendo conto delle differenze fra le piattaforme, potrebbero perciò dover essere entrambe pesantemente ottimizzate.
Per chi non avesse dimestichezza con questi termini, in estrema sintesi:
le tecniche di responsive webdesign prevedono che un codice (HTML, CSS e JS) unico venga fornito a tutti i dispositivi, e che questi, sfruttando i breakopoint dei fogli di stile, riadattino la disposizione e la visibilità dei contenuti; fra gli svantaggi c’è che il contenuto è lo stesso per tutti i dispositivi e che viene caricato anche codice non necessario; è inoltre limitata la possibilità di riprogettazione per diverse piattaforme
Le tecniche di adaptive webdesign prevedono che il server riconosca il tipo di dispositivo usato dall’utente e invii versioni diverse dello stesso codice HTML, CSS, JS (e anche delle immagini e dei video) a seconda delle potenzialità del dispositivo; senza però usare URL differenti. Il vantaggio è che ogni dispositivo riceve una versione ottimizzata e progettata quasi ad hoc della pagina, con tempi di caricamento minori: solo ciò che serve a quel dispositivo viene caricato; fra gli svantaggi la difficoltà a mantenere versioni diverse, potenziali problemi di SEO e possibili errori nel riconoscimento della pagina; ogni contenuto deve poi poter essere adattato ai diversi dispositivi, il che nel tempo significa un mantenimento del sito più oneroso, non solo in fase di progettazione.
Le tecniche responsive sono quelle più usate in un approccio mobile-first, ma non sembrano funzionare come atteso, almeno per gli obiettivi di ridurre il gap fra versione desktop e versione mobile. Come dicevamo, molte aziende, specialmente grosse, tendono ad adottare una filosofia mista.
RESS, il costoso meglio dei due mondi
Tale filosofia è a volte chiamata (sempre dal solito Luke Wroblewski) anche RESS, ovvero REsponsive Web Design with Server Side Components. Usando tecniche molto più evolute e raffinate delle vecchissime tecniche di “browser sniffing” (un modo per riconoscere quale versione di browser l’utente stesse usando e servire una versione adattata del codice HTML), si riconoscono con elevato grado di precisione piattaforme, dimensioni del display, sistema operativo, velocità di connessione, oltre che versione del browser del client.
Queste informazioni vengono passate al server prima che venga servito l’HTML. A quel punto viene decisa quale versione di HTML, CSS, JS e immagini servire, non adattandole però a ogni dispositivo, ma pescandole da un bacino limitato di versioni, ottimizzate per “famiglie di dispositivi”.
Ad esempio, sugli smartphone viene servita una versione diversa da tablet e desktop, ma diversa anche dai vecchi telefonini con accesso a internet. Una versione che, a quel punto, è anche responsive: nel senso che può adattarsi e rispondere a una certa gamma di dimensioni del display, di densità, ecc, ma senza dover caricare tutti gli asset della pagina che si caricano su connessioni stabili e dispositivi più grandi e potenti.
Ogni versione servita del sito è dunque responsive, ma con un range minore di adattamenti, e una qualità più alta di ottimizzazione per “famiglie” di dispositivi. Questo elimina la necessità di servire lo stesso codice a tutti, e consente di progettare meglio per dispositivi differenti, aumentando ovviamente i costi di progettazione e gestione.
E per enti e aziende che non hanno le risorse per mantenere versioni diverse e ugualmente ottimizzate del sito?
Proposta: partire dalla progettazione, non dalle tecniche
Forse non tutti possono adottare un approccio RESS. Ma è anche un errore pensare che il problema sia solo tecnologico. La tecnologia non è neutra, quindi adottare un approccio responsive, adaptive o RESS pone certamente dei vincoli, ma bisogna ricordare che sopra a ogni approccio c’è la progettazione.
Qualunque filosofia riteniate di adottare, bisogna ricordare che ogni sito va prima di tutto correttamente progettato. Vanno cioè evitate le soluzioni stereotipate, i temi pronti, i pattern non verificati, magari derivanti da siti vetrina.
Vanno analizzati i bisogni degli utenti, armonizzandoli con il modello di business e una strategia di lungo termine. Va trovato il senso migliore per le versioni desktop (che rimangono ancora le più efficaci) e per quelle mobile, senza pretendere che servano allo stesso scopo. Accettando le differenze fra le piattaforme e i loro usi. E scegliendo soluzioni di interazione in base ai principi che rispettano o violano, piuttosto che semplicemente e pigramente perché sono “pattern consolidati”.
Questo è più difficile, perché apre a esiti più incerti e processi più lunghi.
Tuttavia, tutte le scorciatoie che io ho visto intraprendere negli anni per evitare di progettare sono finite inevitabilmente dove era logico finissero: in un buco nell’acqua.
Se non vogliamo che il nostro mondo web sia un luogo che porta a crescita economica, come i report europei a sostegno dell’agenda digitale continuano a predicare, forse dobbiamo cambiare approccio e passare dalle linee guida di design alle linee guida del processo di progettazione. E quindi fornire indicazioni su:
Come fare analisi,
Come capire i bisogni,
Come organizzare i contenuti,
Come disegnare le pagine nei diversi dispositivi/dimensioni in cui verranno fruiti,
Come testare costantemente le ipotesi di progetto,
Come monitorare costantemente i risultati.
e così via…
Conclusioni
Ricapitolando:
Il mobile ha dati di utilizzo anche superiori al desktop, ma molti utenti usano entrambe le piattaforme, e completano più probabilmente transazioni complese sui siti desktop
Di conseguenza, un approccio mobile è necessario, ma il mobile-first, come realizzato finora (usando prevalentemente il responsive webdesign, temi pronti, e adattamento di versioni mobile anche sul desktop) non sembra garantire tassi di efficacia simili fra mobile e desktop
Quindi è necessario progettare la miglior esperienza su tutte le piattaforme principali; il desktop in particolare non può essere trascurato perché rimarrà ancora a lungo la piattaforma sulla quale la maggior parte delle transazioni verranno compiute
A seconda del budget, mobile, desktop e tablet vanno attivamente considerate piattaforme in cui le persone compiono attività differenti in modi differenti, e vanno inserite nel processo progettuale considerandole touchpoint (ovvero punti di incontro fra utilizzatore e servizio offerto) diversi, come in effetti sono.
Ok, un articolo chiaro e semplice su uno degli elementi di design di cui abbiamo già parlato, ma rivisto alla luce di nuovi dati, sia personali che internazionali: il menu con l’icona ad hamburger.
E alcune considerazioni su altri aspetti di un design mobile-first complessivamente ostacolanti, e che non vengono sempre presi in considerazione. Buona lettura!
Mi è capitato di fare dei test di usabilità su siti e applicazioni che usavano l’icona ad hamburger. Senza farla lunga: per chiunque non lavori nel settore informatico, quelle tre righette sono incomprensibili. Ovviamente diventano subito comprensibili se ci scrivete sotto, o a fianco, la parola “menu”. Questo quindi è il minimo sindacale.
Ma un’altra cosa che non è chiara a tutti è che usare un’icona per far apparire un menu che normalmente nei siti desktop dovrebbe essere visibile senza fare niente, occulta contenuti e riduce il profumo dell’informazione. In pratica state nascondendo loro quello che offrite e dove possono andare.
Ribadisco che le due questioni sono distinte:
la prima riguarda la comprensibilità di quella specifica icona, ed è risolvibile;
la seconda riguarda la pessima idea di occultare le voci di menu principale anche dove lo spazio c’è, come sul desktop, dietro un qualunque tasto che richiede un’azione dell’utente.
Il NNGroup riporta anche diversi dati quantitativi, raccolti con test di usabilità remoti, che potrebbero convincervi di più, se i miei test, condotti con un numero inferiore di utenti, ma ripetuti in diverse tornate, e se i diversi articoli sul web non vi sembrano sufficienti.
La fascia in alto nasconde cose, ed è pure scomoda
A questo si aggiunge un terzo problema dei design mobile-first che stanno diventando tanto diffusi: spesso questi design prevedono che la fascia orizzontale che contiene logo, icona ad hamburger e qualche altra icona/funzionalità, come i social o la ricerca, rimangano visibili, magari minimizzandosi con un’elegante animazione, nella parte alta della pagina, facendo scorrere sotto il contenuto. Ebbene, pessima idea anche questa per tre ragioni:
In schermi orizzontali, si riduce lo spazio verticale di lettura; su display non enormi come i tablet, questo può essere anche fastidioso. Tanto più se accoppiato magari con il banner dei cookie che improvvidi regolamenti hanno reso obbligatorio in tutta europa, e su cui torneremo.
Si interrompe il corretto funzionamento dello scrolling che utenti un po’ esperti adottano premendo la barra spaziatrice per scorrere più rapidamente (ma anche cliccando sulla parte vuota della scroll-bar laterale). Così capita che scorrendo a pagine, rapidamente, alcune righe di testo vengano coperte da questa simpatica quanto inutile barra orizzontale bloccata in cima alla pagina.
Infine, in alcune particolari situazioni (che curiosamente sono capitate proprio nei test di usabilità di cui sopra), questa barra può coprire i messaggi di errore o di conferma che in alcuni pattern di design vengono mostrati in cima alla pagina; questo può avvenire del tutto o in parte, ma se l’utente non se ne avvede, magari perché poco avvezzo al pattern (e, indovinate un po’: capita) e magari inizia a scorrere la pagina, anche solo di poco, questo messaggio non verrà mai notato e letto. Può capitare anche senza questa fascia in alto, ma con la fascia la probabilità che capiti aumenta, perché basta uno scorrimento minimo.
Scorrendo, un eventuale messaggio in cima alla pagina finisce per scomparire sotto la fascia bloccata in alto.
Non si sta dicendo che su mobile un design di questo tipo non abbia senso:
infatti, su mobile lo spazio è poco, e aprire un menu mediante un tasto è sensato;
inoltre, lo sviluppo è principalmente verticale, quindi non si ha l’effetto di accorciamento percettivo dell’area di testo;
infine, non esistono le barre spaziatrici e quindi non si verifica neanche l’ultima categoria di problemi.
Su mobile, basta accertarsi di usare la parola “menu” vicino all’icona, o mostrare alcune voci e poi far comparire le altre con un tasto, come suggerisce il NNGroup.
Mobile-first non vuol dire mobile-only: e lo dice gente importante
Ma, ecco, il problema è proprio nell’interpretazione del significato di “mobile-first”: come sottolineano proprio Kara Pernice e Raluca Budiu che hanno redatto l’articolo per il NNgroup, non significa “mobile-only”. Se un design funziona su dispositivi mobili touch di piccole dimensioni, non basta ingrandirlo a tutto schermo affinché funzioni anche su desktop. Esistono i breakpoint dei CSS per consentirvi di rimodulare il design, eliminando del tutto icona del menu e mostrando da subito le voci principali di default sul desktop, evitando di lasciare inutili fasce coprenti in cima.
Naturalmente, potreste anche fidarvi delle mode, anziché dei molteplici risultati empirici che dimostrano che si tratta di cattive pratiche, e pensare che siamo noi specialisti di usabilità ad essere un po’ fissati. Ma il problema delle mode di design è che solitamente devono prima prender piede, affinché ci si accorga che sono sbagliate. Succede da sempre, non solo nel web-design. Interi quartieri in città importanti hanno afflitto generazioni di inquilini, perché andava di moda (e per convinzioni civilmente degnissime) il cemento armato: per fortuna nel web-design le conseguenze sono meno gravi…
I design di siti commerciali e istituzionali devono essere verificati con la ricerca e con i test di usabilità e adattati caso per caso. Specialmente poi se pensate di farli durare a lungo, o, il cielo non voglia, se avete in mente di renderli obbligatori – o anche solo consigliati – per un’intera famiglia di siti. O addirittura per un’intera categoria di siti.
Per coloro che fossero di Bologna e dintorni, segnalo che giovedì 14 aprile, alle 12:30, terrò una breve lezione presso il Dipartimento di Informatica, su gentile invito del prof. Fabio Vitali, docente del corso di Interazione Persona-Computer. Il tema suonerà scontato a chi segue usabile.it: “Valutare e misurare l’usabilità in pratica: un caso di studio”.
Attraverso l’analisi di un’esperienza particolare di sviluppo di un’applicazione web e della relativa conduzione di test di usabilità iterati nel tempo, intendo sottolineare:
i punti di forza e di debolezza degli strumenti e dei dati raccolti durante i test
come affrontare in pratica gli imprevisti e i vincoli che ci si trovano davanti nei contesti lavorativi, e che obbligano spesso ad un adattamento dei piani di test originari
come l’adozione di metriche di UX durante i test (anche con pochi soggetti) possa consentire di quantificare, oltre che di qualificare, gli avanzamenti di usabilità e il progresso del progetto in un modo persino più attendibile – dati gli scopi – di quanto si pensi.
Per chi è più “design-oriented” ci sarà spazio per evidenziare anche alcune pratiche consigliate e sconsigliate nel design delle interfacce web, naturalmente, basate sulle evidenze empiriche. L’appuntamento è in Aula Ercolani 1 – Mura Anteo Zamboni 2, a Bologna.
Il prossimo 12 novembre sarò a Roma al World Usability Day romano (e se siete al nord vi ricordo che c’è anche quello torinese) per parlare di… opinioni dell’utente. In realtà nell’intervento “La tua opinione è importante per noi. Dalla soddisfazione alla comprensione dell’esperienza.” parlerò anche di cosa determina maggiormente il successo dei nostri siti, prodotti e servizi, o almeno di come scoprirlo e di come lavorare per massimizzarlo, dal punto di vista dell’esperienza utente.
E qualche giorno dopo sarò a Firenze. Dopo aver partecipato ad una delle prime edizioni, ritornerò quest’anno a Better Software, la bella manifestazione rivolta agli sviluppatori che si svolge nella città gigliata il prossimo 17 novembre.
In “What UX is your UX” porterò avanti in parte il filo iniziato con l’intervento romano, ma da un taglio diverso: quello del project management. Come capire quali aspetti del nostro prodotto o servizio influenzano l’esperienza d’uso, come tenerne conto nella progettazione e come valutare i risultati, allocando le risorse a quelli davvero più importanti?
Arrivederci a Roma, dunque. E se non potete, almeno a Firenze!
