6.3.1.1.1. Web design responsivo¶

Il sito web deve sempre essere progettato e sviluppato con un approccio responsive, con l’obiettivo di fornire un’esperienza d’uso ottimale indipendentemente dalla risoluzione dello schermo e dal tipo di dispositivo utilizzato, consentendo in ogni situazione facilità di lettura e navigazione.

Al concetto di responsive web design vanno associate pratiche di semplificazione delle interfacce in ottica mobile first, e un’attenzione particolare nel fornire un’esperienza soddisfacente anche a coloro che hanno difficoltà visive o motorie.

6.3.1.1.2. Mobile first¶

L’approccio mobile first è, assieme all’utilizzo di progressive enhancement trattato di seguito, una pratica oramai consolidata: consiste nel valutare in prima istanza l’esperienza e le necessità per gli utilizzatori di dispositivi mobili, per poi arricchire di elementi e funzionalità la composizione della pagina mano a mano che la dimensione, le capacità computazionali e di rete del dispositivo aumentano.

Fig. 6.24 Un esempio di approccio mobile first.

Nell’approccio mobile first si parte dall’essenziale.

La forzatura nella progettazione di un’applicazione con ridotte disponibilità di spazio, di interazione, di velocità di caricamento costringe a stabilire delle priorità e a fare delle scelte che risulteranno utili all’usabilità del prodotto.

Per progressive enhancement si intende una pratica fondante per lo sviluppo di una nuova applicazione web flessibile e a prova di future evoluzioni di dispositivi e browser, con la quale la lavorazione inizia da un nucleo solido e irrinunciabile di contenuti che vengono via via arricchiti man mano che il dispositivo utilizzato dal cittadino è più performante e all’avanguardia.

Al contrario, nel caso della graceful degradation, con la programmazione ci si fa carico di verificare che l’interfaccia, inizialmente pensata per i dispositivi più moderni, rimanga navigabile e permetta comunque di accedere alle sue funzioni fondamentali anche man mano che viene fruita attraverso tecnologie meno moderne o meno interattive. In questo secondo caso, si può pensare anche in termini di tolleranza del sito all’assenza di alcune funzionalità.

Come si potrà notare, si tratta in fondo di due risposte diverse alla stessa esigenza: rendere il contenuto accessibile su dispositivi con diverse caratteristiche e potenzialità.

6.3.1.1.3. Feature detection¶

Tecnicamente, l’approccio appena analizzato può essere realizzato attraverso la cosiddetta feature detection (riconoscimento delle caratteristiche): il sito web può rilevare una miriade di proprietà che caratterizzano il metodo di accesso al sito da parte del cittadino.

Attraverso una feature detection puntuale, è possibile sapere come indirizzare ogni aspetto dell’informazione che si vuole trasmettere. Tali caratteristiche possono spaziare dallo schermo utilizzato, in termini di dimensioni, risoluzione e densità dei pixel, fino ai metodi di input (mouse, touch-screen, tastiera, input vocale, ecc.); senza dimenticare le opzioni per la stampa e le tecnologie di ausilio per le persone con disabilità.

Ad esempio, attraverso semplici media-queries nel CSS, è possibile mostrare versioni diverse di una pagina web a seconda che il cittadino stia utilizzando uno smartphone, un televisore o voglia stampare la pagina stessa con la propria stampante.

Sia CSS che Javascript permettono di rilevare la presenza puntuale di determinate caratteristiche nei dispositivi usati.

Javascript permette di analizzare qualsiasi funzionalità presente tra le Web API, oltre a poter conoscere praticamente ogni dettaglio dell’utente che è collegato. Ad esempio, attraverso la geo-localizzazione di un dispositivo, è possibile fornire un servizio più preciso a seconda della posizione dell’utente nello spazio, a patto che tale feature sia disponibile nel dispositivo utilizzato. Ecco come si può realizzare:

if("geolocation" in navigator) {
  navigator.geolocation.getCurrentPosition(function(position) {
    // è possibile ottenere la posizione
  })
} else {
  // il browser non può fornire la posizione
}

CSS ha capacità più limitate, ma ad esempio attraverso la regola @support (in modo simile a quanto avviene per la più conosciuta regola @media), può verificare la corretta interpretazione di proprietà CSS da parte dei browser su cui viene usata. Ecco, ad esempio, come si può verificare attraverso il codice se il browser prevede il supporto della funzionalità CSS grid:

@supports not (display: grid) {
  .nome-classe {
    float: right;
  }
}

Esistono moltissimi strumenti per la feature detection e per le pratiche di polyfill e shim (librerie o frammenti di codice che riescono ad arginare le differenze tra i vari Browser nel pieno supporto di alcune funzionalità); di seguito ne sono riportate alcuni.

6.3.1.2.1. Supporto browser¶

Come regola generale, per la realizzazione di un servizio web per la PA, è necessario assicurare la compatibilità con versioni dei browser che abbiano una penetrazione media tra la popolazione di almeno 1 persona ogni 100 abitanti.

Ciò significa che, con i dati disponibili ad oggi, è necessario assicurare la compatibilità con almeno i seguenti browser:

• Apple Safari 11+ (mobile e desktop)
• Google Chrome (ultime versioni, mobile e desktop)
• Microsoft Edge (tutte le versioni, mobile e desktop)
• Microsoft Internet Explorer 11
• Mozilla Firefox (ultime versioni, mobile e desktop)
• Samsung Internet 7+

È buona norma analizzare regolarmente le statistiche sull’utilizzo dei dispositivi e delle diverse risoluzioni che gli utenti adoperano per accedere al sito, con lo scopo di abbracciare una base di utenti che copra più del 95% delle versioni utilizzate in Italia. Per fare questo, ci si può avvalere di diverse sorgenti di dati: una delle più usate è StatCounter.com, che permette di filtrare i dati per Paese:

• Versioni browser più usate in Italia secondo StatCounter

Come ampiamente descritto nel paragrafo precedente, non è necessario che l’interfaccia di un sito web sia assolutamente identica sui diversi dispositivi; graceful degradation significa tuttavia garantire un’esperienza utente equivalente, graficamente coerente, e completa nelle sue funzionalità. Vediamo come sia possibile farlo.

6.3.1.2.2. Misurare le prestazioni¶

Così come avviene per il design di un sito, anche le sue prestazioni concorrono a una maggiore facilità di utilizzo. In questo senso, è bene differenziare due principali ambiti che possono avere impatto determinante sull’esperienza finale dell’utente: i tempi di caricamento della pagina e le performance di esecuzione della pagina stessa.

Per analizzare i tempi di caricamento e rendering della pagina web si possono utilizzare semplici strumenti online come Google PageSpeed, WebPagetest.org. Con questi strumenti, è possibile verificare problemi di immediata risoluzione, come l’utilizzo di immagini esageratamente grandi o poco ottimizzate, oppure calibrare altri fattori, come sfruttare al meglio il caching del browser o dare priorità ai contenuti immediatamente visibili.

Per ottenere invece informazioni più dettagliate riguardo eventuali inefficienze di codice a runtime, si può fare riferimento ai strumenti di analisi presenti sui principali browser, i quali possono dare indicazioni su eventuali problemi che avvengono durante la navigazione stessa di una singola pagina.

• Google PageSpeed Insights
• WebPagetest.org
• Analisi delle prestazioni su Mozilla Firefox, Google Chrome, Microsoft Edge

In caso di progettazione di progressive web apps ideate per essere usate principalmente su dispositivi mobili, è bene tenere a mente anche il concetto di offline first, fornendo un’esperienza di base anche in caso di limitata connettività.

6.3.2.1.1. Bottoni¶

Ad esempio, per aggiungere un bottone personalizzato è sufficiente aggiungere una classe .btn, associandola a classi di tipo .btn-* per applicarne varianti di stile, dimensione, ed altro.

È possibile consultare tutti i dettagli nella pagina dedicata al componente “Bottone” nella documentazione.

Fig. 6.25 Un esempio del componente “Bottone” nelle sue varianti.

6.3.2.1.2. Interfaccia a Tab¶

Così come per i Bottoni, anche componenti più complessi come interfacce a “Tab” (o a “schede”), che mostrano il contenuto relativo al tab selezionato, possono essere realizzate semplicemente copiando il codice visibile nella documentazione di Bootstrap Italia, assicurandone così il funzionamento anche per utenti che usino la tastiera o dispositivi di comando vocale.

Fig. 6.26 Un esempio del componente “Tab” nelle sue varianti.

6.3.2.1.3. Input Toggle¶

Bootstrap Italia recepisce anche scelte di design su componenti che non esistono nello standard web, come l’input di tipo “Toggle” (una sorta di “interruttore” a due stati), un componente che si sostituisce al più usato “Checkbox” rendendone l’aspetto più chiaro ed immediato.

Fig. 6.27 Un esempio di componente “Toggle” nelle sue varianti.

6.3.2.2.1. Bottoni¶

A titolo di esempio, l’inclusione di un bottone di colore primario nei bordi, di piccola dimensione, e disabilitato sarà semplice come scrivere il codice che segue.

Per il React Kit:

<Button color="primary" size="sm" outline disabled>...</Button>

Per l’Angular Kit:

<it-button color="primary" size="sm" outline disabled>...</it-button>

La maggior parte di questi componenti prevedono già anche le funzionalità di ascolto e di modifica del proprio stato in base a valori impostati dinamicamente dall’esterno.