2. Indice
Elenco delle figure
VII
Elenco delle tabelle
X
Glossario
XI
Introduzione
2
Capitolo 1
Il responsive web design
6
Sommario
6
1.1 Cos’è il responsive web design
6
1.2 Come funziona il responsive web design
8
1.2.1 Layout flessibili e griglie fluide
9
1.2.2 Immagini e media flessibili
11
1.2.3 Media queries
13
1.3 Vantaggi e svantaggi del responsive web design
16
1.4 Quando e perché usare il responsive web design
18
1.5 Critiche al responsive web design
20
1.6 Il futuro del responsive web design
22
1.7 Conclusioni
23
Capitolo 2
Il web mobile
25
Sommario
25
II
3. 2.1 I dati sul mobile
25
2.2 Sviluppare per il mobile
27
2.3 Superare l’idea di mobile
29
2.4 Conclusioni
31
Capitolo 3
Le organizzazioni non profit
32
Sommario
32
3.1 Il settore del non profit
32
3.2 Le organizzazioni non profit sul web
33
3.3 Esempi di siti non profit
34
3.3.1 Amnesty International
34
3.3.2 Emergency
35
3.3.3 Greenpeace Italia
36
3.3.4 Unicef Italia
39
3.4 Conclusioni
40
Capitolo 4
Il responsive web design per le organizzazioni non profit
42
Sommario
42
4.1 Esempi di siti responsive in ambito non profit
42
4.1.1 Strumenti di raccolta e analisi dei dati
43
4.1.2 WWF
44
4.1.3 Organizing for Action
50
4.1.4 JDRF
54
4.1.5 Malaria No More
58
III
4. 4.1.6 Boot Campaign
61
4.1.7 Unicef Svezia
64
4.2 Pattern, buone pratiche, fattori critici
68
4.2.1 Contenuti
68
4.2.2 Layout
68
4.2.3 Navigazione
70
4.2.4 Donazioni
75
4.2.5 Prestazioni
75
4.3 Conclusioni
76
Capitolo 5
WordPress
78
Sommario
78
5.1 Cos’è WordPress
78
5.2 Come funziona WordPress
79
5.3 Perché usare WordPress
81
5.4 Esempi di siti non profit in WordPress
82
5.5 Conclusioni
83
Capitolo 6
Progettazione di un sito responsive
85
Sommario
85
6.1 Metodo di lavoro
85
6.2 Requisiti e definizione del contenuto
89
6.3 Inventario del contenuto e wireframe di riferimento
90
6.4 Breakpoint e design
100
IV
5. 6.5 Conclusioni
100
Capitolo 7
Realizzazione di un prototipo in HTML
102
Sommario
102
7.1 Strumenti di lavoro: ambiente di sviluppo e framework
102
7.1.1 Criteri di valutazione dei framework
104
7.1.2 Scelta del framework
105
7.2 Navigazione
106
7.3 Layout e media queries
107
7.3.1 Homepage
108
7.3.2 Pagine interne
109
7.4 Donazioni: i form di HTML5
109
7.5 Geolocalizzazione in HTML5
113
7.6 Immagini responsive
115
7.6.1 Immagini fluide
115
7.6.2 Tecniche basate su JavaScript
116
7.6.3 Percorso alternativo con JavaScript
116
7.6.4 Il tag noscript
118
7.6.5 Tecniche server-side
119
7.6.6 Proposte per la specifica di HTML5
119
7.7 Immagini responsive in WordPress
121
7.7.1 Gestione delle immagini in WordPress
121
7.7.2 Immagini in evidenza
122
7.7.3 Una soluzione ibrida per le immagini in linea
123
7.8 Prestazioni, ottimizzazione e risultati ottenuti
126
V
7. !
Elenco delle figure
Figura 1.1
10
Figura 3.1
35
Figura 3.2
36
Figura 3.3
37
Figura 3.4
38
Figura 3.5
39
Figura 3.6
40
Figura 4.1
44
Figura 4.2
45
Figura 4.3
46
Figura 4.4
47
Figura 4.5
47
Figura 4.6
48
Figura 4.7
49
Figura 4.8
51
Figura 4.9
52
Figura 4.10
53
Figura 4.11
55
Figura 4.12
56
VII
8. Figura 4.13
57
Figura 4.14
59
Figura 4.15
60
Figura 4.16
60
Figura 4.17
62
Figura 4.18
63
Figura 4.19
63
Figura 4.20
65
Figura 4.21
66
Figura 4.22
66
Figura 4.23
67
Figura 4.24
69
Figura 4.25
71
Figura 4.26
74
Figura 4.27
74
Figura 6.1
94
Figura 6.2
95
Figura 6.3
96
Figura 6.4
97
Figura 6.5
98
Figura 6.6
99
Figura 7.1
111
VIII
11. Glossario
Call to action: un elemento che spinge l’utente a compiere un’azione.
CMS: Content Management System, un sistema per la gestione di contenuti.
CSS: Cascading Style Sheets, linguaggio usato per descrivere l’aspetto visivo e la formattazione
di un documento scritto in un linguaggio di markup.
Device detection: processo di identificazione del tipo di dispositivo in uso.
dpi: Dot per inches, misura di densità del video.
em: Unità di misura tipografica, relativa alla grandezza dei punti specificata (nel CSS, relativa
alla grandezza del carattere).
Framework: un insieme di librerie e componenti software riusabili e modificabili.
GPL: General Public License, una licenza gratuita per software e altri contenuti.
Gzip: un’applicazione creata per la compressione e decompressione di file.
Header Expires: in HTML, un tipo di header che specifica il tempo dopo cui una risorsa è
considerata scaduta.
.htaccess: file per la configurazione del server web.
XI
12. HTML: HyperText Markup Language, il principale linguaggio di markup per creare pagine
web.
JavaScript: linguaggio di programmazione.
Pixel: ciascuno degli elementi puntiformi che costituiscono la rappresentazione di
un’immagine digitale su un dispositivo.
Slideshow: una serie di contenuti presentati in sequenza in forma di slide (immagini, testo o
entrambi).
User agent: in ambito software, un agente che agisce per conto dell’utente; in ambito web è il
browser.
Viewport: La porzione di schermo al cui interno è visualizzato un contenuto; la sua
dimensione non sempre coincide con quella dello schermo del dispositivo usato.
W3C: World Wide Web Consortium, una comunità internazionale che si occupa dello
sviluppo degli standard web.
XII
13. Introduzione
Il mercato globale di Internet è in continua evoluzione: la crescente diffusione di dispositivi
mobile (smartphone, tablet) ha causato un cambiamento nei paradigmi di sviluppo per il web.
Tra le pratiche di maggior interesse è emerso negli ultimi anni il responsive web design: si tratta di
una metodologia di lavoro, una serie di tecniche sperimentali per creare siti responsive, reattivi,
che si adattino alle caratteristiche del dispositivo usato dall’utente.
Internet è uno strumento ormai indispensabile per le organizzazioni non profit di tutto il
mondo, che nel progettare una strategia di presenza online devono considerare i cambiamenti
dettati dall’evoluzione di questo mercato globale.
Il responsive web design offre numerosi vantaggi per la creazione di un’esperienza utente
distribuita su numerosi dispositivi e può rappresentare una scelta ottimale per numerose
organizzazioni non profit, soprattutto in determinati mercati come quelli dei paesi in via di
sviluppo, in cui i dispositivi mobile rappresentano una fetta di mercato sempre più numerosa.
L’obiettivo principale della tesi è studiare lo stato dell’arte del responsive web design, in
particolare in ambito non profit: individuare problemi e fattori critici, pattern comuni, buone
pratiche.
L’analisi di alcuni casi di studio è affiancata dalla realizzazione di un prototipo, sviluppato per
sperimentare alcune delle tecniche disponibili per realizzare siti responsive e far emergere
possibili linee guida sul processo e metodo di sviluppo.
2
14. Il primo capitolo introduce i princìpi del responsive web design, illustrandone l’origine e
l’evoluzione: dopo aver descritto gli elementi fondamentali usati per creare un sito responsive
(griglie fluide, contenuti multimediali flessibili, nuove funzionalità di CSS3 e HTML5), si
analizzano i possibili vantaggi e svantaggi di tale approccio, attraverso un confronto con altre
metodologie e una sintesi del dibattito scientifico che ha scatenato. In particolare si considera
l’opinione di Jakob Nielsen, esperto di usabilità, in merito allo sviluppo di siti per dispositivi
mobile. Infine, si accenna brevemente ai possibili sviluppi futuri nel campo del responsive web
design.
Il secondo capitolo dà una panoramica d’insieme sul web mobile, fornendo alcuni dati sulla
diffusione dei principali dispositivi (smartphone e tablet), in Italia e all’estero. Si evidenzia la
crescente importanza di tali dispositivi nel mercato globale, attraverso l’analisi di nuove
tipologie di pubblico. In seguito si illustrano brevemente i possibili approcci per sviluppare una
presenza web mobile (siti responsive, siti mobile, applicazioni) e si analizza il dibattito che li
vede come oggetto, allargando il punto di vista all’idea stessa di web mobile che si contrappone
all’idea di web unico.
Il terzo capitolo riassume le caratteristiche del settore del non profit (o terzo settore) in Italia e
studia la presenza delle organizzazioni non profit sul web. Attraverso alcuni casi di studio di siti
non responsive di grandi organizzazioni, si analizza la tipica struttura del sito istituzionale di
un’organizzazione non profit, articolato in genere in quattro sezioni principali: chi siamo, cosa
facciamo, cosa puoi fare tu, sostienici.
3
15. Il quarto capitolo è dedicato a una dettagliata analisi di alcuni siti responsive di organizzazioni
non profit. Per ogni caso di studio sono considerati molteplici aspetti del sito: il layout, la
navigazione, i contenuti, le prestazioni. I dati ottenuti sono in seguito generalizzati in una serie
di pattern e pratiche comuni, utili a tracciare le prime linee guida per la realizzazione di un sito
responsive in ambito non profit.
Il quinto capitolo analizza la struttura e il funzionamento di WordPress, uno dei CMS più
diffusi in ambito web e, soprattutto, in ambito non profit. Si tratta di un CMS gratuito e opensource, che offre numerosi vantaggi a un’organizzazione non profit, grazie alla sua struttura
flessibile e alla semplicità d’uso. Le caratteristiche principali di WordPress sono considerate
tenendo conto delle esigenze del responsive web design e di un’organizzazione non profit,
attraverso alcuni esempi di siti non profit realizzati in WordPress.
Il sesto capitolo affronta il problema del processo di lavoro per la progettazione e la
realizzazione di un sito responsive, un ambito in cui non esistono linee guida standard. Si
illustrano alcuni possibili modelli di lavoro e si procede alla progettazione pratica di un sito, che
sarà il punto di partenza per la realizzazione di un prototipo.
Il settimo capitolo riproduce il processo di sviluppo di un prototipo in HTML di un sito
responsive ideato per un’organizzazione non profit. Sono riassunte e illustrate le più importanti
fasi della realizzazione del prototipo: la scelta dell’ambiente di sviluppo, la creazione degli
elementi principali del sito, l’uso di tecniche sperimentali di HTML5. Particolare rilievo è dato
al problema delle immagini all’interno di un sito responsive: dopo un’analisi delle possibili
tecniche di risoluzione, si opera una scelta in merito, grazie a una serie di test quantitativi.
4
16. Infine, si considerano le prestazioni del prototipo, evidenziando i risultati ottenuti attraverso
un processo di ottimizzazione del codice e delle risorse.
In conclusione, nonostante alcune problematiche ancora aperte (riguardanti soprattutto le
immagini e la gerarchia del contenuto), è possibile tracciare alcune prime linee guida per la
realizzazione di un sito responsive in ambito non profit, basate su un processo di sviluppo
flessibile che tenga conto delle convenzioni individuate e delle nuove esigenze rilevate.
5
17. Capitolo 1
Il responsive web design
Sommario
In questo capitolo si introduce l’idea di responsive web design, tracciandone una breve storia a
partire dall’origine e illustrandone in breve i princìpi di funzionamento. In seguito si analizzano
vantaggi e svantaggi del responsive web design, evidenziando casi e contesti d’uso e
sintetizzando il dibattito che ha accolto la sua introduzione. Infine si dà uno sguardo alle
possibili evoluzioni future del responsive web design.
1.1 Cos’è il responsive web design
Nel 2010 Ethan Marcotte, designer e sviluppatore web americano, pubblica sulla rivista “A List
Apart” un articolo intitolato “Responsive Web Design” (Marcotte 2010) che introduce un
insieme di tecniche per creare siti responsive1, cioè siti flessibili e reattivi, che si adattino al
dispositivo attraverso cui vengono visualizzati. L’obiettivo è creare un’esperienza utente
ottimale anche sui dispositivi mobile (tablet e smartphone), la cui diffusione è in continua
crescita. Fin qui le dimensioni ridotte degli schermi di questi dispositivi e le loro ridotte
1
“A List Apart” è una rivista online fondata nel 1997 che «esplora la progettazione, lo sviluppo ed il significato dei
contenuti web […]» All'edizione originale scritta in lingua inglese, si aggiungono alcune traduzioni locali, tra cui
“Italian A List Apart”, in cui l'articolo di Marcotte a cui si fa riferimento era stato inizialmente tradotto con il
titolo “Web Design Reattivo”. La redazione ha poi deciso di modificarlo e mantenere il titolo originale.
6
18. capacità avevano reso difficile l’uso della maggior parte dei siti web, introducendo una barriera
tra il contenuto e l’utente, costretto a sopportare testi illeggibili, elementi multimediali inusabili
e layout rotti. Piuttosto che creare un sito mobile separato e indipendente da quello desktop o
un’applicazione (nativa, web o ibrida), Marcotte propone di considerare i diversi dispositivi
parte di un’unica esperienza web, adattando e modificando un unico sito web alle loro
caratteristiche.
Il reponsive web design si ispira a una disciplina emergente nel campo dell’architettura
chiamata responsive architecture, che si interroga su “come gli spazi fisici possano reagire alla
presenza delle persone che vi passano attraverso” (Marcotte 2010). Allo stesso modo, in
ambito web ci si chiede come debbano comportarsi i siti web quando il dispositivo usato
dall’utente è uno smartphone, un tablet o un tradizionale pc desktop.
Marcotte amplia e approfondisce il proprio lavoro in un libro intitolato “Responsive Web
Design” (Marcotte 2011), che riprende i concetti introdotti nel 2010, mettendoli in pratica in
un esempio di sito responsive.
Sono tre gli ingredienti usati da Marcotte per create un sito responsive:
•
un layout flessibile basato sulle griglie fluide,
•
immagini e media flessibili,
•
le media queries.
7
19. Si tratta di un insieme di tecniche che si avvale delle nuove possibilità offerte da HTML5 e
CSS3.
Questi tre ingredienti, tuttavia, da soli non sono sufficienti.
Un ingrediente fondamentale per la realizzazione di un sito responsive è un cambiamento
radicale nella progettazione che precede lo sviluppo: non si dovrebbe ideare i siti basandosi sul
loro aspetto finale come visualizzato da un browser di un particolare dispositivo; invece è
necessario adottare un’estrema flessibilità già nella fase di progettazione e prototipazione. Per
questo motivo, il responsive web design incoraggia a lavorare di più nel browser e meno nei
programmi di grafica (Foster 2012): in questo modo si può finalmente parlare di uno sviluppo
web non più legato, almeno in parte, alle vecchie metodologie della carta stampata.
1.2 Come funziona il responsive web design
I tre ingredienti principali del responsive web design sono un layout flessibile basato sulle
griglie fluide, immagini e media flessibili, le media queries.
A questi ingredienti bisogna aggiungere l’inserimento di un tag HTML per la gestione della
viewport nella testata della pagina:
<meta name="viewport" content="width=device-width, initial-scale=1">
Il parametro width può essere un numero (per esempio 320 per un sito mobile largo 320
pixel) o, come nell’esempio, può indicare al browser di considerare l’intera larghezza dello
8
20. schermo del dispositivo; il parametro initial-scale, invece, dice al browser di visualizzare il
sito con una proporzione 1:1, cioè senza zoom.
Questo importante tag, senza cui un sito responsive non funzionerebbe sui dispositivi mobile,
è stato introdotto da Apple per gestire la visualizzazione delle pagine web (Apple 2012): i
browser dei dispositivi mobile, infatti, alterano le proporzioni di una pagina web e usano
viewport molto larghe (quella di Safari in iOS è di 980 pixel) per poter visualizzare la pagina in
tutta la sua larghezza nonostante uno schermo molto stretto. Il tag viewport è usato per
impedire che ciò accada.
1.2.1 Layout flessibili e griglie fluide
I layout flessibili ottenuti con le griglie fluide sono la base di partenza per creare un responsive
design.
Una griglia è, nell'ambito del design, uno strumento per ordinare gli elementi grafici (testo e
immagini) all'interno di una pagina (Boulton, A Practical Guide to Designing for the Web
2009, 199-200).
Una griglia fluida si ottiene passando, all'interno del CSS, dall'uso di unità di misura assolute
(pixel) a unità di misura relative (espresse in percentuale), grazie a una semplice formula
(Marcotte 2009):
target ÷ context = result
9
21. Si consideri l’esempio di un <div> con id #blog, largo 400 pixel, contenuto all’interno di un
altro <div> con id #main, largo 960 pixel (figura 1.1).
Volendo esprimere la larghezza del <div> #blog in percentuale, è possibile usare la formula
in questo modo: il target è la larghezza in pixel del <div> #blog, il context è la larghezza in pixel
del <div> #main.
Sostituendo, si ottiene: 460 ÷ 960 = 0.47916667, in percentuale 47.916667%, che sarà la nuova
larghezza assegnata al <div> #blog.
#main: 960 pixel (100%)
#blog: 400 pixel
(47.916667%)
Figura 1.1: un esempio in cui è applicata la formula target ÷ context = result.
La formula permette di mantenere le proporzioni degli elementi grafici della griglia quando
varia la sua grandezza, cioè quando varia la viewport o la risoluzione dello schermo.
10
22. 1.2.2 Immagini e media flessibili
Per ottenere immagini e media flessibili è sufficiente un'altra regola da applicare nel CSS:
img, object { max-width: 100%; }
In questo modo le immagini e gli oggetti multimediali (i video incorporati, per esempio) sono
ridimensionati per avere una grandezza massima pari a quella del loro contenitore.
In realtà si è presto reso evidente come questa tecnica sia problematica e onerosa in termini di
prestazioni. Sono state proposte tecniche alternative che facciano affidamento direttamente sul
markup HTML e su JavaScript: si inserisce nel tag img un’immagine di dimensioni ridotte,
pensata per i dispositivi mobile, e a questa si aggiunge il percorso per un’immagine di
dimensioni maggiori, come nell’esempio:
<img src="images/mobile.jpg" data-fullsrc="images/desktop.jpg">
A questo punto tramite JavaScript si legge la grandezza dello schermo del dispositivo per
indirizzare il browser verso l’immagine più adatta: tutto ciò deve essere fatto prima di caricare
l’immagine contenuta nel tag img.
Questa tecnica si è rivelata fallimentare quando alcuni browser hanno introdotto funzioni in
grado di caricare le immagini prima della lettura del corpo del documento HTML, rendendo
vani gli sforzi per ridurre le richieste client-server. (Marquis, Responsive Images: How they
Almost Worked and What We Need 2012).
11
23. Il problema delle immagini rimane una delle questioni aperte del responsive web design: le
proposte finora avanzate non hanno funzionato per evidenti limiti nelle attuali specifiche di
CSS e HTML (Marquis, Responsive Images and Web Standards at the Turning Point 2012),
ma un gruppo di lavoro ha proposto al W3C l'introduzione di un nuovo elemento <picture>
nella specifica di HTML5 per risolvere il problema (Marquis e Bateman).
La proposta prevede di caricare immagini diverse in base al browser e alle caratteristiche del
display del dispositivo in uso attraverso le media queries; un esempio di markup è il seguente:
<picture width="500" height="500">
<source media="(min-width: 45em)" src="large.jpg">
<source media="(min-width: 18em)" src="med.jpg">
<source src="small.jpg">
<img src="small.jpg" alt="">
<p>Accessible text</p>
</picture>
Nell’esempio l’elemento picture è “riempito” con un’immagine attraverso l’uso dell’elemento
source
e di alcune media queries, che caricano file diversi a seconda di specifici parametri (in
questo caso la larghezza minima della viewport): se la larghezza è maggiore o uguale a 45 em
sarà usato il file large.jpg, se maggiore o uguale a 18 em il file med.jpg e in tutti gli altri casi il
file small.jpg. L’elemento img, infine, garantisce compatibilità con i vecchi browser che non
supportano l’elemento picture.
12
24. Al momento questa specifica è solo una bozza, limitata e prolissa (Wilcox 2012), ma evidenzia
come il responsive web design e il markup HTML possano influenzarsi a vicenda. Inoltre il
problema delle immagini responsive rileva l'importanza della semanticità di HTML5 e la sua
utilità nel creare contenuto adattivo (Wachter-Boettcher 2012, 97-98), cioè contenuto riusabile,
strutturato, indipendente dalla presentazione e corredato da metadati significativi (McGrane
2012, 45).
1.2.3 Media queries
Una media query è un’espressione logica che restituisce un risultato (vero o falso) in base alla
valutazione del tipo di media e di alcune sue caratteristiche inserite nell’espressione come
parametri; più espressioni possono essere concatenate tra loro tramite l’operatore logico and.
Alcuni esempi:
@media screen and (min-width:500px) { … }
Quest’espressione restituisce un risultato vero per tutti i dispositivi quando la viewport ha una
larghezza minima di 500 pixel; a questi dispositivi sono applicate le regole presenti nelle
parentesi graffe. La larghezza inserita come parametro nella query è definita breakpoint, perché
rappresenta un punto in cui il comportamento del sito cambia.
@media screen and (orientation: portrait) and (max-resolution:
300dpi) { … }
13
25. Questa seconda espressione restituisce un risultato vero per i dispositivi che sono orientati
verticalmente e il cui schermo ha una massima risoluzione di 300dpi.
Tabella 1.1: i parametri accettati dalle media queries (Marcotte 2011, 76-78).
Parametro
Descrizione
Prefissi min- e max-
width
La larghezza dell’area del display
visualizzata.
Sì
height
L’altezza dell’area del display
visualizzata.
Sì
device-width
La larghezza della superficie di
rendering del dispositivo.
Sì
device-height
L’altezza della superficie di
rendering del dispositivo.
Sì
orientation
L’orientamento del dispositivo
(portrait o landscape).
Sì
aspect-ratio
Il rapporto tra la larghezza e
l’altezza dell’area del display
visualizzata.
Sì
device-aspect-ratio
Il rapporto tra la larghezza e
l’altezza della superficie di rendering
del dispositivo.
Sì
color
Il numero di bit per componente di
colore del dispositivo.
Sì
color-index
Il numero di elementi nella lookup
table dei colori del dispositivo.
Sì
monochrome
Il numero di bit per pixel nei
dispositivi a una solo colore.
Sì
14
26. Parametro
Descrizione
Prefissi min- e max-
resolution
La densità dei pixel nel dispositivo.
Sì
scan
Il processo di scanning per
dispositivi televisivi
(progressive o interlace).
No
grid
Il tipo di dispositivo (grid o
bitmap).
No
È possibile specificare le media queries in quattro modi (Hay, Responsive Design Workflow
2013, 43):
•
attraverso l’elemento <link> all’interno di un file HTML: <link rel=”stylesheet”
href=”style.css” media=”only screen and (min-width:400px)”>
•
usando @media all’interno di un file CSS: @media only screen and (minwidth:400px) { … }
•
attraverso l’elemento <style> all’interno di un file HTML: <style media=”only
screen and (min-width:400px)”> [regole CSS] </style>
•
usando @import all’interno di un file CSS: @import url(style.css) only
screen and (min-width:400px);
Grazie alle media queries è quindi possibile modificare e adattare il contenuto di un sito
secondo determinate caratteristiche del dispositivo in uso: il loro obiettivo è colmare alcune
15
27. lacune dei media types, presenti in HTML4 e CSS2 e usati per applicare stili diversi in base al tipo
di media, permettendo per esempio di creare uno stile per le stampanti (Marcotte 2011, 74).
Le media queries sono parte della specifica di CSS3 e sono uno standard dal 19 giugno 2012
(Rivoal 2012); sono incluse anche nella specifica di HTML5, che è ancora una bozza, pronta a
diventare uno standard (Berjon, et al. 2012).
1.3 Vantaggi e svantaggi del responsive web design
Dal punto di vista tecnico, i vantaggi nell’uso del responsive web design sono molteplici:
Google, per esempio, dà molta importanza al fatto che lo stesso contenuto sia presente sulla
versione desktop del sito e su quella per dispositivi mobile con un unico indirizzo perché ciò
permette una migliore indicizzazione dei contenuti e agevola l’utente nella condivisione (Far
2012); le media queries possono accelerare il processo di sviluppo e ridurne i costi se
considerate dall’inizio della progettazione, possono inoltre aumentare il grado di leggibilità di
una pagina web su mobile, rendendo migliore l’esperienza dell’utente (M. Lawson 2011).
Dal punto di vista dell’utente un sito responsive è leggibile da ogni dispositivo, limitando l’uso
di gestures come lo zoom, che rallentano l’interazione con il contenuto. Accedere allo stesso
contenuto su dispositivi diversi riduce la barriera di apprendimento dell’utente e garantisce
un’esperienza uniforme su tutte le piattaforme. Non avviene il caso di non poter eseguire un
compito o accedere a un determinato contenuto perché non presente nella versione mobile del
sito: in genere, un sito responsive garantisce che il contenuto sia sempre accessibile.
16
28. Gli svantaggi del responsive web design emergono soprattutto sul piano tecnico: alcuni vecchi
browser (tabella 1.2) potrebbero non supportare le media queries (M. Lawson 2011); i tempi di
caricamento potrebbero essere rallentati da immagini troppo pesanti che sono poi
ridimensionate o da contenuti caricati ma non visualizzati; il ridimensionamento di immagini e
altri contenuti effettuato dal browser potrebbe essere oneroso in termini di utilizzo della
memoria e della CPU (Grigsby, CSS Media Query for Mobile is Fool’s Gold 2010).
Alcuni di questi svantaggi sono destinati a scomparire nel tempo (il supporto dei browser sarà
sempre più capillare), mentre altri sono dovuti a problemi ancora ampiamente dibattuti (le
immagini responsive).
Tabella 1.2: supporto browser per le media queries di CSS3, http://caniuse.com (6 giugno 2013).
Browser
Versione
Internet Explorer
Dalla versione 9.0
Firefox
Dalla versione 3.5
Chrome
Tutte le versioni
Safari
Dalla versione 4.0 (nelle precedenti il supporto è
parziale)
Opera
Dalla versione 9.5
17
29. Browser
Versione
iOS Safari
Tutte le versioni
Opera Mini
Tutte le versioni
Android
Tutte le versioni
Blackberry
Tutte le versioni
Opera Mobile
Tutte le versioni
Chrome per Android
Tutte le versioni
Firefox per Android
Tutte le versioni
1.4 Quando e perché usare il responsive web design
Il responsive web design, ancorché molto diffuso, non è, a oggi, il sistema standard di design
del web. È ancora necessario valutare caso per caso se usare queste tecniche oppure, al
contrario, se sia preferibile implementare tradizionali siti mobile indipendenti o applicazioni
native, cioè applicazioni sviluppate per specifiche piattaforme (iOS, Android, Windows Phone,
ecc.) in specifici linguaggi di programmazione, i cui dati sono salvati nel dispositivo dell’utente.
18
30. La scelta dipende dal budget del progetto, dalla tipologia di sito, dalla quantità di interazione
richiesta da parte dell’utente, dal CMS usato (se è usato un CMS). In alcuni casi è preferibile
realizzare un sito mobile separato, in altri uno responsive: la decisione dovrebbe essere presa in
seguito a un’attenta analisi dei bisogni degli utenti attraverso ricerche sul loro comportamento
(Marcotte, Toffee-nosed. 2011). Ovviamente ciò non sempre è possibile. Allo stesso modo
non potrebbero esserci i presupposti economici per realizzare un sito responsive oppure il
numero di utenti che accedono da dispositivi mobile potrebbe essere insufficiente a giustificare
un investimento di tempo e risorse in questo settore (Young 2013).
Ipotizzando una situazione senza i limiti sopra evidenziati, perché scegliere di adottare un
responsive web design?
Le ragioni sono numerose: un sito responsive è un sito accessibile (dove per accessibilità si
intende la possibilità di accesso universale a una pagina web: un obiettivo che il responsive web
design aiuta a raggiungere) e flessibile (Allsopp 2000), è leggibile (Foster 2012), è pronto per il
futuro (Stocks 2013), è tutelato dalla crescente frammentazione dei dispositivi (Marcotte 2011,
6), è consapevole del contesto in cui opera (Marcotte 2011, 41).
I motivi per scegliere un responsive web design non si limitano ai vantaggi nell’accessibilità e
nell’esperienza utente. Il responsive web design, secondo alcuni autori, è un ritorno alle origini
e alla vera natura del web, che è sempre stato fluido: “Abbiamo sprecato anni tentando di
forzare i pixel in posizione fissa in un ambiente che è per natura adattivo; è ora di smetterla”
(Stocks 2013).
19
31. A confermare la validità del responsive web design, una serie di dati ricavati da analisi e
ricerche sul comportamento degli utenti di alcuni siti di importanti compagnie: diminuzione
significativa del bounce rate2, incremento del numero di pagine lette per visita, incremento del
conversion rate3 su dispositivi mobile, incremento del numero di utenti unici, incremento del
tempo trascorso sul sito (Wroblewski 2013).
1.5 Critiche al responsive web design
Sin dall’inizio il lavoro di Marcotte sul responsive web design è stato accolto da un dibattito
tuttora in corso nell’ambiente del design e dello sviluppo web e incentrato su alcune
problematiche come quelle dell’usabilità e delle prestazioni.
Jakob Nielsen, tra i più conosciuti consulenti di usabilità web, ha scritto che per avere
un’esperienza utente soddisfacente in ambito mobile occorre creare un sito diverso da quello
desktop, collegando i due siti con la tecnica del cross-linking4; un’applicazione mobile potrebbe
essere ancora più indicata (Nielsen 2012).
In seguito alle dichiarazioni di Nielsen, Bruce Lawson, sviluppatore web per Opera, ha
spiegato come sia impossibile sapere con certezza quale contenuto vogliano gli utenti,
2
Il tasso di abbandono, cioè il numero di utenti che esce dal sito dopo aver visualizzato una pagina per pochi
secondi.
3
La percentuale di utenti che compiono una determinata azione, ritenuta uno degli obiettivi del sito (per esempio,
acquistare un prodotto).
4
Domini o sottodomini di siti diversi che si linkano vicendevolmente. Nel caso dei siti mobile, in genere, si crea
un sottodominio per la versione mobile del sito: http://m.sito.com o http://mobile.sito.com.
20
32. rilevando come la realizzazione di un sito mobile separato, al contrario dell’uso del responsive
web design, non sia una tecnica che guarda al futuro (B. Lawson, Why We Shouldn’t Make
Separate Mobile Websites 2012). Josh Clark, fondatore di Global Moxie, ha invece spiegato
che il web mobile non esiste, criticando Nielsen per aver confuso il contesto in cui opera il
dispositivo con le intenzioni dell’utente (J. Clark 2012). Jason Mark, fondatore di Gravity
Switch, un’agenzia di sviluppo web che si occupa di organizzazioni non-profit, ha cercato di
mediare tra le posizioni di Nielsen e Clark, affermando che dovrebbero essere i dati ricavati dai
test sul comportamento degli utenti a influenzare scelte di questo tipo e non le tecnologie
(Mark 2012).
La vivace polemica ha spinto Nielsen a chiarire le proprie idee in un’intervista (Combrinck
2012): il problema cui tutto si riduce è quello del budget; il responsive web design “è uno dei
modi per ottenere interfacce utente diverse secondo il dispositivo in uso”, ma è solo un
dettaglio implementativo, che potrebbe creare problemi di prestazioni.
Per Karen McGrane, user experience designer e autrice di “Content Strategy for Mobile”, nello
scontro tra siti mobile e applicazioni o tra responsive design e siti separati si trascura il
problema principale che dovranno affrontare la maggior parte delle organizzazioni in futuro:
una totale riconfigurazione del processo di creazione e produzione del contenuto. La scelta
nell’approccio di sviluppo sarà secondaria perché tutte queste tecniche evolveranno e
raggiungeranno uno stato di standard (McGrane 2012, 45).
21
33. 1.6 Il futuro del responsive web design
Il responsive web design è un insieme di tecniche ancora molto giovane e per questo destinato
a evolversi: così come cambieranno i dispositivi con cui accediamo al web nei prossimi anni,
allo stesso modo cambieranno le tecniche usate per creare siti responsive.
Il futuro del responsive web design risiede nel passaggio dal semplice design di layout alla
creazione di siti realmente adattivi, che sarà possibile gradualmente con l’accesso a nuove
specifiche e tecniche per la maggior parte ancora impossibili da usare, fino al momento in cui
siti web e applicazioni saranno indistinguibili (Stocks 2013).
Marko Dugonjić, uno sviluppatore croato, ha realizzato un interessante esperimento: una
pagina web in cui, dopo aver individuato il volto dell’utente di fronte al pc, la grandezza del
testo aumenta e diminuisce secondo la distanza dallo schermo, in modo da garantire maggiore
leggibilità (Dugonjić). Un esempio rudimentale che illustra le possibilità offerte da un
approccio incentrato sui princìpi del responsive web design.
Alcune tecniche sperimentali sulle immagini SVG5 sembrano indicare una strada per risolvere il
problema delle immagini responsive, con l’uso delle media queries all’interno delle stesse
immagini (Grigsby 2013). Tuttavia per le immagini non vettoriali, che rimangono la maggior
parte, si dovranno attendere le possibili evoluzioni di HTML e delle proposte avanzate in
merito.
5
Scalable Vector Graphics: un formato per immagini vettoriali.
22
34. Una discussione coinvolge le media queries: si propone l’introduzione, all’interno della
specifica di CSS, di queries non più basate sui tipi di media (cioè sulle caratteristiche dello
schermo o della viewport) ma sugli elementi e la loro larghezza, come in questo esempio:
.classe-elemento (max-width: 27em) {
font-size: 0.8em;
}
L’obiettivo di questa proposta è rendere il CSS un linguaggio modulare. L’ipotesi è che le
media queries siano uno strumento temporaneo destinato a essere superato perché sempre più
insufficiente a soddisfare le esigenze degli sviluppatori, come già avvenuto con i media types
(Storm Taylor 2013).
Le prime proposte per la specifica di CSS4 includono nuovi parametri per le media queries per
interrogare i sensori di luminosità dei dispositivi o il tipo di puntatore usato (Walter 2013).
Mentre in ambito web il dibattito è ancora aperto, i princìpi del responsive web design hanno
contaminato altre aree di sviluppo, incoraggiando le prime applicazioni per desktop responsive
(Reichenstein 2012): in questo senso il responsive web design non si limita al design di siti web,
ma propone un nuovo approccio per l’esperienza utente e l’usabilità dei sistemi interattivi.
1.7 Conclusioni
Il responsive web design non è una moda (Foster 2012). Evolverà, cambieranno le tecniche di
implementazione, ma non sparirà.
23
35. Le attuali specifiche web hanno influenzato l’evoluzione del responsive web design e in futuro
potrebbe accadere il contrario, cioè che esigenze nate dallo sviluppo di siti responsive
influenzino l’evoluzione di HTML5.
Griglie fluide, immagini flessibili e media queries costituiscono l’attuale punto di partenza per
realizzare un sito responsive, ma non possono essere considerate un punto di arrivo.
Questo insieme di tecniche costituisce una scelta valida tra quelle possibili per sviluppare una
presenza web mobile, ma non solo.
Il cambiamento introdotto dal responsive design non si limita all’aspetto grafico di una pagina
web, ma coinvolge la sua progettazione e il suo sviluppo. In futuro si potrebbe superare l’idea
di responsive web design: al suo posto lo sviluppo web responsive o semplicemente
l’esperienza utente responsive.
24
36. Capitolo 2
Il web mobile
Sommario
In questo capitolo si forniscono alcuni dati sulla diffusione e l’uso di dispositivi mobile
(smartphone e tablet), analizzando il loro impatto sullo sviluppo web. Si prendono in
considerazione i possibili approcci per la realizzazione di una presenza mobile e infine si
affronta il dibattito che circonda il web mobile.
2.1 I dati sul mobile
Alla fine del 2010 il numero di smartphone presenti sul mercato globale ha superato per la
prima volta quello dei pc (Menn 2011), in anticipo rispetto a quanto predetto dagli analisti, che
ipotizzavano un sorpasso nel 2011. Si stima che tra il 2012 e il 2016 il numero di smartphone
crescerà con un tasso di crescita annuale composto del 17,9%, passando da 694 milioni di
esemplari nel 2012 a un miliardo e 342 milioni nel 2016 (mobiThinkingA 2013).
A inizio 2012 si parla insistentemente del declino o, addirittura, della morte dei pc (Wingfield
2012), le cui vendite nel primo trimestre 2013 subiscono una flessione del 14% (De Biase
2013).
25
37. Gli analisti prevedono inoltre che nel 2013 il numero di tablet sul mercato supererà per la
prima volta quello dei pc laptop (Arthur 2013) e che entro il 2017 saranno venduti tra i 353
(Arthur 2013) e i 500 (Gobry 2012) milioni di tablet ogni anno. Il mercato dei tablet avrà un
tasso di crescita annuale composto del 35,3%: si passerà cioè da 114 milioni unità vendute nel
2012 a 383 milioni nel 2016 (mobiThinkingA 2013).
In conseguenza al diffondersi di questi dispositivi, cambiano le modalità di accesso al web:
l'87% dei possessori di smartphone negli Stati Uniti usa questi dispositivi per navigare in
Internet o controllare l'email (Smith 2011). In Italia 16,8 milioni di persone possono accedere a
Internet da cellulare e 2,7 milioni da tablet (Audiweb 2013).
Cresce la percentuale di utenti mobile-only (ovvero che usano prevalentemente o esclusivamente
dispositivi mobile per accedere a Internet), soprattutto in determinate aree geografiche:
•
il 17% dei possessori di telefoni negli Stati Uniti usano quasi esclusivamente questo
dispositivo per navigare in Internet (Smith 2012),
•
in Egitto 7 milioni di persone rientrano nella definizione di mobile-only, ovvero il 70%
degli utenti che accedono a Internet da un dispositivo mobile, in India questa
percentuale scende al 59%, in Sud Africa al 57%, in Cina al 30%, in Russia al 19%
(mobiThinkingB 2013).
Le stime e le cifre citate sono suscettibili a lievi variazioni tra fonti diverse, ma i risultati sono
inequivocabili: in futuro smartphone e tablet avranno la stessa importanza, se non maggiore,
dei pc nell'accesso a Internet, soprattutto nei paesi in via di sviluppo, che costituiscono un
mercato importante per molte organizzazioni non profit.
26
38. 2.2 Sviluppare per il mobile
La crescita delle percentuali di diffusione e uso di smartphone e tablet ha portato a dare
maggiore importanza a una presenza web su mobile, possibile attraverso approcci diversi:
•
un responsive design, mobile first;
•
un sito mobile in HTML, separato da quello desktop;
•
un’applicazione nativa.
Il primo approccio prevede un'aggiunta agli ingredienti base del responsive design, introdotti
nel capitolo 1: l’idea del mobile first prevede di sviluppare un sito partendo dalla sua versione
mobile, per arrivare a quella desktop e non viceversa. Questo metodo, illustrato da Luke
Wroblewski (Wroblewski, Mobile First 2011), aiuta a concentrarsi su ciò che è veramente
essenziale nello sviluppo di un sito e richiama alcuni princìpi alla base del progressive enhancement6.
Eric Schmidt, CEO di Google, ha dichiarato (Schmidt 2011):
“Dunque, questa rivoluzione del mobile, che io chiamo mobile first — la linea guida è:
qualsiasi cosa fai, falla prima per il mobile. E quello che ho notato è che gli sviluppatori
migliori, le agenzie più giovani e brave stanno usando questa tecnica del mobile first.
6
Una strategia che propone di adattare e migliorare l’esperienza utente in base alle capacità del dispositivo in uso
(Champeon e Finck 2003). Un requisito in particolare rende questa tecnica possibile: i browser ignorano il
contenuto che non comprendono (Gustafson 2011).
27
39. Partono dando per scontate la connettività e la localizzazione in un modo che la mia
generazione non avrebbe mai predetto.”7
Dello stesso parere Kevin Lynch, ex-CTO di Adobe (Lynch 2010):
“Dobbiamo davvero cambiare modo di pensare, dando priorità al mobile… Si tratta di un
cambiamento più grande di quello avvenuto con la rivoluzione dei personal computer.”8
I sostenitori del secondo approccio (un sito mobile indipendente da quello desktop) affermano
che questa sia la soluzione ideale perché utenti desktop e utenti mobile hanno esigenze d'uso
diverse, in contesti diversi (Grigsby, New to Mobile? Welcome to the One Web Debate. 2010).
Nella maggior parte dei casi un sito mobile indipendente garantisce migliori prestazioni, ma è
più difficile da realizzare, consuma molte risorse (in termini di tempo dedicato alla sua
manutenzione) e introduce una curva di apprendimento per l'utente tanto più alta quanto più
differisce dal sito desktop (M. Lawson 2011).
Il terzo approccio (sviluppo di applicazioni native) ha diversi vantaggi (integrazione grafica
all'interno della piattaforma, minimo uso della banda e delle risorse, accesso a funzionalità
aggiuntive), ma si scontra con il crescente moltiplicarsi dei dispositivi e dei sistemi operativi (M.
7
La dichiarazione in originale: “So, this mobile revolution, which I call mobile first, right? The simple guideline is:
whatever you're doing, do mobile first. And what I've noticed is that the top device developers, the smartest,
young, firms – they're doing mobile things first. They start with the presumption of connectivity, location, and
locality and interaction in a way that my generation never foresaw.”
8
In originale: “We really need to shift to think about mobile first… This is a bigger shift than we saw with the
personal computing revolution.”
28
40. Lawson 2011): in molte realtà è impossibile creare un’applicazione nativa per ogni piattaforma
disponibile (Wroblewski, Mobile First 2011, 15).
Dal punto di vista dell’utente, un sito responsive offre un’unica esperienza, coerente tra i
diversi dispositivi, eliminando la difficoltà di cercare le stesse informazioni presenti sul sito in
un ambiente completamente o parzialmente diverso (degli altri vantaggi del responsive web
design si è discusso nel capitolo 1). Un’applicazione nativa, invece, occupa spazio sul
dispositivo in cui è installata, richiede continui e spesso numerosi aggiornamenti, è legata alle
caratteristiche della piattaforma per cui è stata sviluppata (se l’utente possiede più di un
dispositivo con piattaforme diverse, deve installare e imparare a usare altrettante applicazioni).
Molte applicazioni possono funzionare anche offline, avendo una cache, ma ciò è ormai
possibile anche per i siti web grazie a ApplicationCache, una nuova interfaccia introdotta nella
specifica di HTML5 (Bidelman 2010).
In definitiva la scelta tra un approccio o un altro deve essere considerata in base all’ambiente in
cui si opera; ogni approccio ha vantaggi e svantaggi. Gli operatori di settore sono comunque
tutti concordi nel ritenere che sia ormai essenziale sviluppare una presenza web su mobile.
2.3 Superare l’idea di mobile
Il principio del mobile first, insieme al responsive design, aggiunge una nuova prospettiva alle
considerazioni già fatte: il mobile in realtà non esiste (Wolski 2013). Il web è unico
(Wroblewski, Mobile First 2011, 3).
29
41. Come spiega il W3C (Rabin e McCathieNevile 2008):
“Web unico vuol dire fornire le stesse informazioni e gli stessi servizi agli utenti,
indipendentemente dal dispositivo che stanno usando, nei limiti ragionevoli. Tuttavia, non
vuol dire che le stesse informazioni sono rappresentate nello stesso identico modo in
dispositivi diversi.”9
È impossibile dare una definizione precisa e non ambigua del termine mobile: è determinato dal
contesto? Dal dispositivo in uso? Dalla grandezza dello schermo? (Ramsden 2013)
Allo stesso modo è difficile, e sbagliato, fare assunzioni sul comportamento degli utenti
unicamente in base al dispositivo che stanno usando (McGrane 2012, 1-2, 18, 19). Il mobile
può suggerire i possibili stati mentali dell'utente e le relative esigenze, per esempio la necessità
di informazioni urgenti, la necessità di svago, o l’esigenza di completare micro-task
(Wroblewski, Mobile First 2011, 50).
L'obiettivo dovrebbe essere quello di sviluppare siti agnostici nei confronti dei dispositivi e
creare contenuto adattivo, pronto a essere usato in qualsiasi situazione, comportandosi nel
modo più consono, essendo stato progettato sin dall'inizio per essere flessibile (WachterBoettcher 2012, 13).
9
In originale: “One Web means making, as far as is reasonable, the same information and services available to
users irrespective of the device they are using. However, it does not mean that exactly the same information is
available in exactly the same representation across all devices.”
30
42. 2.4 Conclusioni
Il panorama dei dispositivi con cui è possibile navigare in Internet è in continua evoluzione. Il
pc desktop è in parte superato, ma non è morto: ha perso il suo ruolo egemonico, lasciando
spazio a smartphone e tablet.
Sviluppare per il mobile è un’esigenza non più trascurabile: analizzando il contesto e in base a
limiti operativi si può scegliere uno dei differenti approcci per essere presenti sul web mobile.
Il vantaggio del responsive web design è dato dalla sua flessibilità e dalla capacità di abbracciare
l’idea di web unico, un’idea che scatenato un dibattito ancora in corso, assimilabile per
posizioni e contrapposizioni a quello che ha accolto il responsive web design.
La creazione di contenuto adattivo è il naturale passo successivo per uno sviluppo orientato al
futuro.
31
43. Capitolo 3
Le organizzazioni non profit
Sommario
In questo capitolo si illustra brevemente il settore del non profit (terzo settore) in Italia; si
analizza la struttura standard del sito istituzionale di un’organizzazione non profit, fornendo
alcuni esempi.
3.1 Il settore del non profit
In Italia il settore del non profit (detto anche terzo settore) è composto da organizzazioni di
svariate tipologie.
L’esistenza di queste realtà è regolata da numerose leggi nazionali, regionali e comunitarie, che
ne stabiliscono le caratteristiche: in genere, un’organizzazione non profit deve essere
caratterizzata da attività socialmente utili, dall’assenza dello scopo di lucro e da una natura
privata.
Secondo i dati dell’8° Censimento Generale dell’Industria e dei Servizi effettuato da Istat nel
2001 le istituzioni non profit in Italia sono circa 235.000 (Istat 2005).
32
44. Tra le organizzazioni non profit più note figurano Emergency, Medici con l’Africa, Terres des
Hommes, Amnesty International, Greenpeace, Medici Senza Frontiere, Save the Children,
Unicef, WWF, Bill & Melinda Gates Foundation, Livestrong Foundation, Malaria No More.
3.2 Le organizzazioni non profit sul web
La presenza delle organizzazioni non profit sul web è ormai diffusa a tutti i livelli, grandi e
piccoli, e vede il suo centro nella realizzazione di un sito istituzionale, una vetrina, con
numerosi scopi: informare sulle proprie attività; coinvolgere e reclutare volontari e soci;
affermare l’identità dell’organizzazione; raccogliere fondi e donazioni.
Il sito istituzionale di un’organizzazione non profit è in genere strutturato come segue:
•
Chi siamo: una sezione che descrive la missione, la storia e la struttura
dell’organizzazione (spesso al suo interno si trova il bilancio sociale).
•
Cosa facciamo: una sezione dedicata alle attività e ai progetti in corso (o già conclusi)
dell’organizzazione, solitamente ricca di materiale multimediale.
•
Dove siamo: una sezione con i contatti, le sedi e i luoghi in cui opera l’organizzazione.
•
Sostienici: una sezione che illustra in che modo è possibile sostenere economicamente
l’organizzazione; a questa sezione si può affiancare una sezione in cui effettuare
donazioni direttamente online (tramite carta di credito) e una, strutturata come un
negozio virtuale, in cui acquistare oggetti di merchandise.
•
Notizie, eventi: una sezione di contenuti dinamici, spesso strutturata in forma di blog (in
alcuni casi si preferisce separare le notizie dagli eventi), con segnalazioni di novità e
appuntamenti che coinvolgono l’organizzazione.
•
Collabora: una sezione con le informazioni necessarie a chi voglia collaborare
direttamente con l’organizzazione, diventando volontario o socio.
33
45. •
Newsletter: non una vera sezione, ma un servizio offerto dal sito, un bollettino periodico
recapitato via mail a chi decide di abbonarsi (gratuitamente), con aggiornamenti e
novità; all’interno del sito è solitamente presente un modulo per l’iscrizione.
L’homepage del sito generalmente contiene un menu che indirizza l’utente alle sezioni
principali, uno slideshow con immagini molto grandi che attirano l’attenzione sui contenuti in
rilievo, le ultime notizie, banner e bottoni call-to-action, bottoni per i social network, link utili, un
modulo per la ricerca, un modulo per la newsletter.
3.3 Esempi di siti non profit
I seguenti casi di studio esemplificano le pratiche più diffuse nella realizzazione di siti
istituzionali di organizzazioni non profit:
3.3.1 Amnesty International
Il sito di Amnesty International ha una struttura tradizionale, organizzata attorno a poche
sezioni principali: “chi siamo”, “cosa facciamo”, “cosa puoi fare tu”, “come sostenerci”.
L’homepage (figura 3.1) presenta una testata con un menu di primo livello e il modulo per la
ricerca, un’immagine in evidenza, le ultime notizie, link utili, un modulo per la newsletter,
bottoni per i social network, banner call-to-action.
Il sito non ha una versione mobile.
34
46. Logo
Ricerca
Menu
Call to
action
Immagine
Bottoni
social
Newsletter
News
Link
utili
Figura 3.1: l’homepage di http://www.amnesty.it (9 maggio 2013).
3.3.2 Emergency
Il sito di Emergency è organizzato attorno alle sezioni “chi siamo”, “cosa facciamo”, “cosa
puoi fare tu”; a queste affianca una sezione multimediale e una dedicata alla ricerca di
collaboratori stipendiati. L’homepage (figura 3.2) presenta una testata con due menu e un
modulo di ricerca, un’immagine in evidenza, banner call-to-action, ultime notizie.
Il sito non ha una versione mobile.
35
47. Ricerca
Menu
Logo
Immagine
Newsletter
Call to
action
News
Bottoni
social
Figura 3.2: l’homepage di http://www.emergency.it (9 maggio 2013).
3.3.3 Greenpeace Italia
Il sito di Greenpeace Italia ha una struttura organizzata in maniera simile a quella di
Emergency: “chi siamo”, “cosa facciamo noi”, “cosa puoi fare tu”, “multimedia”. L’homepage
(figura 3.3) presenta una testata con menu e modulo di ricerca, uno slideshow per i contenuti
in rilievo, gli ultimi aggiornamenti (filtrabili per tipologia di contenuto), bottoni call-to-action e
per i social network, contenuti incorporati dai social network.
36
49. Il sito ha una versione mobile (figura 3.4), che offre soltanto gli ultimi aggiornamenti e una
serie di link che indirizzano alla iniziative dell’organizzazione.
Figura 3.4: la versione mobile di http://www.greenpeace.org/italy/it/ (9 maggio 2013).
38
50. 3.3.4 Unicef Italia
Il sito di Unicef Italia è organizzato attorno alle sezioni “chi siamo”, “cosa facciamo”, “diventa
volontario”, “sostienici”. L’homepage (figura 3.5) presenta una testata con menu e modulo di
ricerca, uno slideshow, numerosi banner call-to-action, contenuti incorporati dai social
network (Facebook, Twitter, YouTube).
Menu
Logo
Menu
Bottoni
social
Slideshow
Contenuti
social
Call to
action
Call to
action
News
Contenuti
social
Newsletter
Call to
action
Figura 3.5: l’homepage di http://www.unicef.it (9 maggio 2013).
39
51. Il sito ha una versione mobile (figura 3.6) in cui sono presenti soltanto alcuni contenuti: le
ultime notizie e i prossimi eventi.
Figura 3.6: la versione mobile di http://www.unicef.it (9 maggio 2013).
3.4 Conclusioni
Le organizzazioni non profit usano i siti web come vetrina di promozione delle proprie attività.
L’organizzazione del contenuto ruota in genere attorno a quattro sezioni principali: chi siamo,
cosa facciamo, cosa puoi fare tu, sostienici.
40
52. La maggior parte delle più importanti organizzazioni non profit (soprattutto quelle italiane)
non ha un sito responsive e in alcuni casi la presenza su mobile è del tutto trascurata.
41
53. Capitolo 4
Il responsive web design per le organizzazioni non
profit
Sommario
In questo capitolo sono analizzati alcuni siti responsive di organizzazioni non profit come casi
di studio per evidenziare pattern, pratiche comuni, fattori critici.
4.1 Esempi di siti responsive in ambito non profit
Seguono sei casi di studio che hanno come oggetto i siti responsive di altrettante
organizzazioni non profit, di varia tipologia e indirizzo (ambiente, politica, salute).
Si analizza la struttura di ciascun sito, evidenziando i suoi elementi fondamentali e il loro
comportamento nell’ambito del responsive web design adottato (homepage, navigazione,
pagine interne, sezione dedicata alle donazioni).
In seguito si forniscono alcuni dati quantitativi sulle prestazioni del sito in esame, calcolate sulla
sua homepage: peso complessivo (in mega byte), tempo totale di caricamento (in secondi),
numero di richieste HTTP, risultati di test di velocità (YSlow e PageSpeed Insights).
42
54. 4.1.1 Strumenti di raccolta e analisi dei dati
I dati sulle prestazioni delle homepage dei siti analizzati sono stati raccolti grazie a PageSpeed
Insights10 e GTmetrix11.
YSlow è un progetto open-source che valuta una pagina web basandosi su alcune regole
proposte da Yahoo per l’ottimizzazione dei siti web: compressione del CSS, uso di redirect e
cache, richieste HTTP, elementi dell’albero DOM, ecc. (YSlow FAQ). La pagina web riceve un
punteggio per ogni regola; il punteggio finale è una media pesata dei punteggi ricevuti (a ogni
regola è assegnato un peso). GTMetrix esprime il punteggio di YSlow con una lettera (in
ordine decrescente: A, B, C, D, E, F), che corrisponde a una fascia percentuale.
PageSpeed Insights è un progetto di Google: valuta una pagina web basandosi su regole in
parte differenti da quelle scelte da Yahoo e assegna alla pagina un punteggio da 0 a 100,
calcolato separatamente per browser che operano su pc desktop e browser che operano su
dispositivi mobile.
I punteggi forniti dai due strumenti devono considerarsi indicativi, perché in alcuni casi sono
trascurati fattori non precisamente misurabili (per esempio, la variazione della quantità di
banda nel misurare il tempo di caricamento). Allo stesso modo è importante considerare che il
punteggio è assegnato secondo l’efficienza della codifica della pagina, indipendentemente dalle
scelte fatte (inserire immagini o meno, usare codice JavaScript o meno, ecc.).
10
https://developers.google.com/speed/pagespeed/insights
11
http://gtmetrix.com
43
55. Il riferimento per il peso complessivo di una pagina web è la media di 1.4 MB, arrotondata per
eccesso (HTTP Archive - Interesting Stats 2013) (figura 4.1).
Figura 4.1: il peso medio di una pagina web è di 1427 kB (aggiornato al 1 maggio 2013),
http://httparchive.org/interesting.php (15 maggio 2013).
4.1.2 WWF
WWF (World Wildlife Fund) è una delle più importanti organizzazioni non profit che opera a
livello internazionale (con quasi cinque milioni di membri in tutto il mondo): la sua missione è
la protezione dell’ambiente.
L’organizzazione ha una ricca presenza sul web, articolata in numerosi siti: un sito informativo
che raccoglie i contatti delle numerose sedi nel mondo (http://wwf.panda.org/), i siti locali, un
sito
internazionale
(http://wwf.panda.org/)
e
infine
un
sito
(http://worldwildlife.org/), qui analizzato come caso di studio.
Il sito istituzionale di WWF (http://worldwildlife.org/) è realizzato in HTML5.
44
istituzionale
57. L’homepage è molto semplice e composta dai seguenti elementi (figura 4.2):
•
una testata con i menu di navigazione, bottoni call-to-action e un modulo di ricerca,
•
un grande slideshow con fotografie che attirano l’attenzione dell’utente sui contenuti
principali del sito,
•
una sezione con alcuni contenuti dinamici (notizie, quiz, storie),
•
una sezione di chiusura contenente un modulo di iscrizione alla newsletter e alcuni
bottoni per i social network (a sinistra), la rassegna stampa (al centro), il richiamo a
un’iniziativa rilevante (a destra),
•
un footer (o piè di pagina) con alcuni link di servizio e bottoni che rimandano ai social
network (in realtà ridondanti, perché già presenti nella sezione di chiusura).
Gli elementi della homepage sono fluidi (la loro larghezza varia insieme a quella della
viewport).
Figura 4.3: i pulsanti di scorrimento dello slideshow.
46
58. Quando la larghezza della viewport è inferiore a 768 pixel (figura 4.3) cambiano i pulsanti per
sfogliare lo slideshow (più bassi e più larghi, con colori che risaltano maggiormente all’occhio
dell’utente), mentre il resto degli elementi si adatta allo spazio disponibile, senza
compromettere l’usabilità, a eccezione del form per l’iscrizione alla newsletter, che risulta
sacrificato (figura 4.4).
Figura 4.4: il form della newsletter non ha abbastanza spazio.
Al di sotto di 640 pixel di larghezza gli elementi vengono riorganizzati: i contenuti dinamici
sono disposti su due righe e non più una, allargandosi nuovamente; i contenuti della sezione di
chiusura sono invece disposti uno sotto l’altro, occupando l’intera larghezza della viewport.
Figura 4.5: la testata del sito.
47
59. La testata del sito contiene quattro elementi (figura 4.5): il logo WWF in alto a sinistra; un
menu a destra del logo; un secondo menu, di carattere informativo e con due bottoni call-toaction, in alto a destra; un modulo per la ricerca all’interno del sito, posizionato al di sotto dei
due bottoni call-to-action, in linea con il primo menu. Quando la larghezza della viewport è
compresa tra 768 e 1000 pixel il primo menu non è mostrato: l’ipotesi è che il dispositivo in
uso sia un tablet.
Quando la larghezza della viewport è inferiore a 768 pixel il menu è quasi completamente
nascosto: rimangono visibili i due pulsanti call-to-action, mentre il resto delle voci (insieme al
modulo per la ricerca) è accessibile cliccando su un bottone ( ) posizionato in alto a destra
(figura 4.6). Si tratta di tre linee disposte verticalmente: è un bottone usato anche all’interno
delle applicazioni native per dispositivi mobile.
Figura 4.6: il menu del sito su dispositivi mobile.
48
60. Le pagine interne sono più ricche di contenuti rispetto all’homepage, ma il loro
comportamento è simile, con elementi fluidi che sono disposti verticalmente quando la
viewport diventa più stretta.
La pagina dedicata alle donazioni contiene alcuni form per raccogliere i dati, i cui elementi
sono responsive. Tuttavia, quando si accede al sito da un dispositivo mobile si è indirizzati a
una versione della pagina ideata appositamente per questi dispositivi (figura 4.7). In sostanza, si
tratta di una sezione del sito in cui si è preferito evitare un approccio responsive.
Figura 4.7: la pagina delle donazioni visualizzata su un pc (a sinistra) e uno smartphone (a destra).
Dal punto di vista delle prestazioni il sito di WWF raccoglie un buon punteggio (tabella 4.1): le
immagini presenti sono ottimizzate; la compressione gzip è abilitata; HMLT, CSS e JavaScript
sono compressi; non è presente codice duplicato.
49
61. Tra i fattori critici segnalati da YSlow e Google: le dimensioni delle immagini non specificate
con gli appositi attributi HTML (si tratta di immagini fluide ridimensionate dal browser al
variare della viewport); l’uso di query-string12 per risorse statiche; la mancanza di header Expires.
Tabella 4.1: le prestazioni di http://worldwildlife.org (2 maggio 2013).
Peso
Tempo di
Numero di
complessivo
caricamento
richieste
1.18 MB
3.83 s
YSlow
71
PageSpeed
Desktop
C (76%)
PageSpeed
Mobile
89/100
77/100
4.1.3 Organizing for Action
Organizing for Action è un’associazione non profit creata per supportare il presidente degli
Stati Uniti Barack Obama nella realizzazione del proprio programma elettorale. Il sito
istituzionale dell’organizzazione (http://www.barackobama.com) è realizzato in HTML5.
L’homepage (figura 4.8), che si sviluppa su due colonne, è estremamente semplice e ha due
obiettivi: coinvolgere l’utente (il primo elemento in alto a sinistra è un pulsante per le
donazioni), informare (un blog con le ultime notizie occupa gran parte della pagina). Non è
presente un vero e proprio menu: alcuni link si trovano all’interno della testata, gli altri
(numerosi) sono presenti nel footer.
12
I parametri all’interno di un indirizzo dinamico.
50
63. La pagina ha due breakpoint principali (960 e 768 pixel) che impongono una trasformazione
poco fluida degli elementi, causando per esempio un taglio parziale dell’immagine in apertura
(figura 4.9).
Figura 4.9: l’homepage di http://www.barackobama.com, visualizzata su un pc desktop (a sinistra) e su uno
smartphone (a destra).
La pagina dedicata alle donazioni si presenta in due versioni, distinte da un breakpoint a 768
pixel. La prima versione, pensata per tablet e desktop, caratterizzata da un forte impatto visivo,
divide il processo di donazione in tre passaggi distinti (figura 4.10, a sinistra).
La seconda versione, pensata per smartphone e dispositivi dallo schermo più stretto, elimina gli
elementi grafici della prima e la distinzione dei tre passaggi del processo di donazione,
52
64. proponendo una versione ottimizzata del form: bottoni più grandi e più larghi, testo più
leggibile, campi del form che occupano l’intera larghezza della viewport (figura 4.10, a destra).
Figura 4.10: la pagina delle donazioni, visualizzata su un pc desktop (a sinistra) e su uno smartphone (a destra).
Dal punto di vista delle prestazioni il sito ottiene un punteggio nella media, nonostante il
tempo di caricamento sia di quasi sette secondi (tabella 4.2).
Tra i fattori critici segnalati da YSlow e PageSpeed: immagini non ottimizzate e le cui
dimensioni non specificate in HTML; uso di JavaScript non asincrono che può bloccare il
caricamento della pagina; mancanza di header Expires; un elevato numero di richieste HTTP;
mancanza di una cache per il browser lato server.
53
65. Tabella 4.2: le prestazioni di http://www.barackobama.com (3 maggio 2013).
Peso
Tempo di
Numero di
complessivo
caricamento
richieste
1.12 MB
6.63 s
YSlow
82
PageSpeed
Desktop
C (74%)
PageSpeed
Mobile
81/100
73/100
4.1.4 JDRF
JDRF è un’organizzazione americana che si occupa di curare e prevenire il diabete di tipo 1. In
origine l’associazione era chiamata Juvenile Diabete Research Foundation; in seguito ha scelto
di usare soltanto l’acronimo JDRF come proprio nome ufficiale, per dare meno importanza
alla parola “gioventù”, non più associabile alla malattia (oggi l’85% dei pazienti affetti da
diabete di tipo 1 negli Stati Uniti sono adulti).
Il sito istituzionale dell’associazione (http://jdrf.org) è realizzato con WordPress, in HTML5.
54
66. Figura 4.11: l’homepage di http://jdrf.org (3 maggio 2013) visualizzata su un pc desktop (a sinistra) e su uno
smartphone (a destra).
55
67. Il layout dell’homepage è composto da una colonna che occupa l’intera larghezza della
viewport (figura 4.11). In ordine si susseguono una testata (con logo, menu, bottoni call-toaction, modulo di ricerca); uno slideshow; alcune sezioni call-to-action dal forte impatto visivo,
con icone e immagini e caratteri molto grandi; una sezione dedicata alle notizie; una sezione
con la rassegna stampa, i bottoni social e per la newsletter; una sezione dedicata alle donazioni;
un footer con link di servizio.
Gli elementi dell’homepage si adattano alla larghezza della viewport fino al breakpoint di 768
pixel. Da qui in poi si verificano alcuni cambiamenti: le icone della sezione “How Can We
Help?” vengono sostituite da larghi bottoni testuali, mentre le immagini delle sezioni “Get
Support” e “Location” scompaiono.
Gli altri contenuti sono adattati disponendoli verticalmente uno sotto l’altro.
Il menu principale di navigazione contiene alcune voci, ognuna della quali, se cliccata, apre un
menu di secondo livello molto articolato, contenente alcuni link disposti su due colonne e
alcuni articoli con immagini di anteprima (figura 4.12).
Figura 4.12: il menu di secondo livello.
56
68. Quando la larghezza della viewport è inferiore a 768 pixel il menu principale è accessibile da un
bottone con tre linee ( ) e include anche i bottoni call-to-action presenti in alto a destra, oltre
al modulo di ricerca (figura 4.13). Il menu di secondo livello non compare.
Figura 4.13: il menu accessibile da un bottone in alto a destra su dispositivi mobile.
Le pagine interne sono in genere sviluppate su tre colonne: a sinistra un menu di navigazione
per la sezione (si tratta dei link presenti nel menu di secondo livello a comparsa), al centro il
contenuto vero e proprio, a destra contenuti aggiuntivi.
Le tre colonne sono fluide e sono disposte verticalmente una sotto l’altra quando la viewport è
larga meno di 768 pixel.
La pagina delle donazioni presenta un form responsive; tuttavia, quando si accede al sito da un
dispositivo mobile la pagina viene visualizzata come se non fosse responsive. Analizzando il
57
69. codice sorgente è facile individuare il motivo: manca il meta tag della viewport. Una semplice
dimenticanza che compromette l’usabilità di questa sezione del sito su dispositivi mobile.
Dal punto vi vista delle prestazioni, il sito è appesantito dalle immagini, che influiscono
negativamente sulle prestazioni (tabella 4.3).
In particolare, YSlow e PageSpeed segnalano come problemi molto gravi la mancata
ottimizzazione delle immagini e l’assenza delle loro dimensioni all’interno del codice HTML.
YSlow penalizza anche il numero di richieste HTTP, che è abbastanza elevato.
Tabella 4.3: le prestazioni di http://www.jdrf.org (3 maggio 2013).
Peso
Tempo di
Numero di
complessivo
caricamento
richieste
2.47 MB
2.57 s
YSlow
96
PageSpeed
Desktop
C (76%)
PageSpeed
Mobile
83/100
79/100
4.1.5 Malaria No More
Malaria No More è un’organizzazione non profit internazionale, fondata nel 2006, che ha lo
scopo
di
debellare
la
malaria
entro
il
2015.
Il
suo
sito
istituzionale
(http://www.malarianomore.org/) è realizzato in HTML5.
Il layout dell’homepage è sviluppato su due colonne che vengono compresse in un’unica
colonna quando la viewport ha una larghezza inferiore a 980 pixel (figura 4.14).
58
70. Figura 4.14: l’homepage di http://www.malarianomore.com (3 maggio 2013), visualizzata su un pc desktop (a
sinistra) e su uno smartphone (a destra).
59
71. Il menu principale di navigazione si trova al di sotto dello slideshow che apre il sito (figura
4.15, in alto): contiene il logo e alcuni link sulla sinistra, bottoni social e un modulo per la
newsletter sulla destra.
Quando la viewport ha una larghezza inferiore a 980 pixel questo menu è nascosto, reso
accessibile tramite un bottone a tre linee ( ) e portato al di sopra dello slideshow insieme al
logo e a un bottone per le donazioni (figure 4.15 in basso, figura 4.16).
Figura 4.15: come si trasforma il menu di navigazione.
Figura 4.16: il menu di navigazione accessibile da un bottone su dispositivi mobile.
La pagina delle donazioni è responsive e consiste di un semplice form per raccogliere i dati.
60
72. Le prestazioni del sito (tabella 4.4) sono penalizzate soprattutto da tre elementi: il codice
JavaScript caricato prima del necessario; le immagini le cui dimensioni non sono specificate in
HTML; la mancanza di una cache per il browser lato server. YSlow penalizza anche la
mancanza di header Expires e il numero di richieste HTTP.
Tabella 4.4: le prestazioni di http://www.malarianomore.org (3 maggio 2013).
Peso
Tempo di
Numero di
complessivo
caricamento
richieste
3.42 MB
3.91 s
YSlow
75
PageSpeed
Desktop
C (75%)
PageSpeed
Mobile
85/100
68/100
4.1.6 Boot Campaign
Boot Campaign è un’organizzazione non profit che vuole aiutare e sostenere le truppe militari
statunitensi e le loro famiglie. L’attività dell’organizzazione consiste principalmente nella
vendita di stivali e altri prodotti di merchandise.
Il sito vetrina dell’organizzazione (http://www.bootcampaign.com) è realizzato con
WordPress, in HTML5.
61
73. Figura 4.17: l’homepage di http://www.bootcampaign.com (3 maggio 2013), visualizzata su un pc desktop (a
sinistra) e su uno smartphone (a destra).
62
74. Il layout dell’homepage è sviluppato su una colonna, favorendo un semplice
ridimensionamento degli elementi che lo compongono, che in alcuni casi passano da una
disposizione orizzontale a una verticale (figura 4.17).
Il menu principale di navigazione è costituito da un gruppo di icone con testo, che circondano
il logo (figura 4.18).
Figura 4.18: il menu principale del sito.
Quando la viewport è larga meno di 1024 pixel le icone sono spostate sotto il logo, mentre
quando è larga meno di 735 pixel le icone spariscono, sostituite da una voce “Menu” nella
testata del sito (figura 4.19, a sinistra), che nasconde un menu testuale (figura 4.19, a destra). I
breakpoint sono scelti in base al comportamento del menu e non viceversa.
Figura 4.19: il menu principale del sito su dispositivi mobile.
La pagina delle donazioni non è responsive o ottimizzata per il mobile. Lo stesso vale per la
sezione degli acquisti.
63
75. Dal punto di vista delle prestazioni il sito ottiene un punteggio superiore alla media degli altri
casi di studio presi in considerazione (tabella 4.5). YSlow penalizza la mancanza di header
Expires e il numero di richieste HTTP, mentre PageSpeed dà molta importanza alla mancanza
delle dimensioni delle immagini nel codice HTML.
Tabella 4.5: le prestazioni di http://www.bootcampaign.com (3 maggio 2013).
Peso
Tempo di
Numero di
complessivo
caricamento
richieste
1.44 MB
5.51 s
YSlow
72
PageSpeed
Desktop
B (81%)
PageSpeed
Mobile
93/100
80/100
4.1.7 Unicef Svezia
Unicef è un’organizzazione internazionale che si occupa di assistenza umanitaria nei paesi in
via di sviluppo. Unicef ha trentasei comitati nazionali (Anonimo 2012): quello svedese
(http://www.unicef.se), insieme a quello svizzero (http://www.unicef.ch), è l’unico a offrire
un sito responsive, realizzato in HTML5.
64
76. Figura 4.20: l’homepage di http://www.unicef.se (4 maggio 2013), visualizzata su un pc desktop (a sinistra) e
su uno smartphone (a destra).
65
77. Il layout dell’homepage si sviluppa su più colonne e gran parte della pagina è occupata da
un’immagine di apertura e dalle ultime notizie. Gli elementi sono fluidi e quando varia la
larghezza della viewport vengono disposti verticalmente uno sotto l’altro (figura 4.20).
Il menu principale di navigazione è costituito da poche voci che, una volta cliccate, conducono
ai rispettivi contenuti interni. Qui la testata si trasforma: scompare l’immagine di sfondo per
dar spazio a un altro menu di secondo livello (figura 4.21). Le stesse voci del menu principale e
dei rispettivi menu di secondo livello sono presenti nel footer; questi link vengono usati come
menu di navigazione quando la larghezza della viewport è inferiore a 768 pixel: nella testata
compare un bottone “Menu” (figura 4.22) che rimanda al footer con un link interno.
Figura 4.21: il menu di secondo livello nelle pagine interne.
Figura 4.22: il menu sui dispositivi mobile.
La pagina delle donazioni è responsive. Il sito contiene una sezione per la vendita di prodotti,
anch’essa responsive (figura 4.23).
66
78. Figura 4.23: la pagina degli acquisti, visualizzata su un tablet (a sinitra) e su uno smartphone (a destra).
Il sito è complessivamente il migliore dal punto di vista delle prestazioni (tabella 4.6): le
immagini (non ottimizzate e le cui dimensioni non specificate in HTML) danneggiano il
punteggio che altrimenti sarebbe stato più alto, considerato il peso inferiore alla media e il
tempo di caricamento più che accettabile. In particolare, YSlow penalizza il sito per la
mancanza di header Expires e per il numero di richieste HTTP (comunque inferiore a quello di
molti altri siti analizzati).
67
79. Tabella 4.6: le prestazioni di http://www.unicef.se (3 maggio 2013).
Peso
Tempo di
Numero di
complessivo
caricamento
richieste
1.35 MB
1.93 s
YSlow
45
PageSpeed
Desktop
B (80%)
PageSpeed
Mobile
86/100
77/100
4.2 Pattern, buone pratiche, fattori critici
4.2.1 Contenuti
I siti analizzati rispettano le convenzioni individuate nel capitolo 3 e, dal punto di vista del
contenuto, sono in genere organizzati attorno a tre sezioni principali: chi siamo, cosa facciamo,
cosa puoi fare tu. Molta importanza è data ai contenuti informativi (blog, notizie,
approfondimenti) e a quelli multimediali.
4.2.2 Layout
Luke Wroblewski, analizzando numerosi siti responsive, ha redatto una possibile catalogazione
dei più comuni tipi di layout responsive (Wroblewski 2012):
•
Mostly fluid (figura 4.24.a): un layout fluido a più colonne, realizzato con griglie fluide e
immagini flessibili, in cui le colonne sono impilate verticalmente quando la larghezza
della viewport diminuisce.
68
80. •
Column drop (figura 4.24.b): un layout a più colonne, in parte simile alla prima tipologia,
in cui, allo stesso modo, le colonne sono impilate verticalmente quando la larghezza
della viewport diminuisce, ma in questo caso non ci sono cambiamenti notevoli nella
grandezza degli elementi del sito.
•
Layout shifter (figura 4.24.c): un layout che cambia a seconda del dispositivo,
riposizionando gli elementi.
•
Off canvas (figura 4.24.d): un layout che sfrutta lo spazio al di fuori dello schermo,
posizionando parte del contenuto all’esterno della vista.
•
Tiny tweaks: layout a una colonna in cui ci sono pochi cambiamenti.
Figura 4.24.a
Figura 4.24.b
Figura 4.24.c
Figura 4.24.d
Figura 4.24: layout mostly fluid (a), column drop (b), shifter (c), off canvas (d); immagine di Luke Wroblewski,
http://www.lukew.com/ff/entry.asp?1514 (6 giugno 2013).
69
81. Su un totale di 28 siti responsive di organizzazioni non profit analizzati (per l’elenco completo
si veda l’appendice A), la maggior parte tende a usare un layout del primo tipo (fluido).
Nel dettaglio:
•
Layout fluido (o quasi): 16
•
Layout column drop: 5
•
Layout shifter: 1
•
Layout inclassificabile: 6
I layout inclassificabili in genere uniscono elementi di pattern diversi.
I sei siti considerati come casi di studio rientrano nella tipologia del layout fluido, con il
contenuto organizzato in genere su una o due colonne.
4.2.3 Navigazione
La navigazione è uno degli aspetti che varia maggiormente e i possibili approcci individuati
sono molteplici:
•
l’uso di un bottone a tre linee ( ) o di un bottone testuale per nascondere il menu
principale quando la viewport si restringe,
•
l’uso di un gruppo di link posizionati nel footer come menu di navigazione principale,
•
l’uso di un menu con l’elemento <select> che sostituisce il menu testuale quando la
viewport si restringe,
•
l’uso di icone, sostituite da un menu testuale quando la viewport si restringe,
•
l’uso di un menu testuale, in cui la grandezza del carattere varia insieme alla viewport.
70
82. Queste non sono le uniche soluzioni possibili per realizzare una navigazione responsive e
alcune sono molto simili tra loro. Di seguito una classificazione più generica e completa di
pattern per la navigazione responsive (figura 4.25):
•
menu a comparsa,
•
menu con l’elemento <select>,
•
menu off canvas,
•
menu a griglia,
•
menu nel footer,
•
nessuna modifica al menu.
Figura 4.25: alcuni pattern di navigazione responsive (menu a comparsa, menu a griglia, menu con l’elemento
<select>).
Su un totale di 28 siti responsive di organizzazioni analizzati, la maggior parte tende a usare un
menu a comparsa.
Nel dettaglio:
•
Menu a comparsa: 17
•
Menu select: 1
71
83. •
Menu off canvas: 1
•
Menu a griglia: 1
•
Menu invariato: 7
•
Menu inclassificabile: 1
Vantaggi e svantaggi di ognuna delle soluzioni individuate sono da considerarsi in relazione al
contenuto del sito e alla fattibilità all’interno del progetto.
L’elemento <select> permette di risparmiare molto spazio, ma il suo uso è considerato un
abuso poiché si tratta di un elemento ideato per i form e non per la navigazione; inoltre
l’elemento <select> è dispersivo quando le voci di menu sono numerose o organizzate in più
livelli.
L’organizzazione del menu a griglia non è possibile quando le voci di navigazione sono
numerose: il rischio è di occupare gran parte della pagina con il menu. Inoltre con un menu di
questo tipo le voci di navigazione possono essere troppo piccole perché evitino errori nel
tocco.
Lasciare il menu invariato è difficoltoso nella maggior parte dei casi, perché la lista delle voci di
navigazione finisce per perdere di senso.
Infine, il menu off canvas può essere più complesso da realizzare rispetto alle altre soluzioni,
pur rimanendo una possibilità efficiente e sempre più diffusa all’interno di numerose
applicazioni mobile.
72
84. La scelta più diffusa, quella di un menu a comparsa attivato da un bottone sistemato in alto a
destra (o a sinistra), è in molti casi il compromesso migliore.
I pattern individuati si concentrano sulle trasformazioni e gli adattamenti che il menu di
navigazione può subire al variare della larghezza della viewport e sono spesso ideati e
ottimizzati per gli schermi di dispositivi mobile di piccole dimensione (smartphone e simili).
Nella maggior parte dei siti analizzati, infatti, la navigazione nella vista intermedia dei tablet
risulta invariata, alternativamente, rispetto alla vista smartphone o a quella desktop.
Accanto a questi pattern è possibile individuarne altrettanti relativi al menu di navigazione nella
vista che si riferisce ai pc desktop e a schermi di grandi dimensioni: si tratta di pattern
tradizionali (menu oizzontale a tendina, menu a barre orizzontali, menu a più livelli) che non
sono alterati dalla scelta di sviluppare un sito responsive. Anzi, in molti casi, ci si limita soltanto
ad adattare questi menu (anche molto complessi) nel modo più semplice, senza ripensarne
l’usabilità a seconda dello dispositivo in uso e delle sue caratteristiche.
Luke Wroblewski ha elaborato alcune interessanti considerazioni sulle problematiche della
navigazione dei siti responsive, proponendo alcuni pattern che risultano molto più adattivi
rispetto a quelli evidenziati: questi pattern cercano di ripensare la navigazione secondo le
esigenze di dispositivi touch, che hanno requisiti di usabilità diversi rispetto a un normale pc
desktop fornito di un puntatore molto preciso come il mouse (Wroblewski, Responsive
Navigation: Optimizing for Touch Across Devices 2012).
73
85. Wroblewski individua le aree che un utente riesce a raggiungere facilmente con le dita su tablet
e smartphone (figura 4.26): spesso i menu nei siti responsive (o mobile) sono posti nelle aree
più difficili da raggiungere.
Figura 4.26.a: smartphone.
Figura 4.26.b: tablet.
La soluzione proposta prevede che la navigazione cambi posizione in base al dispositivo in
uso, come illustrato in figura 4.27.
Figura 4.27: proposta per una navigazione responsive, http://www.lukew.com/ff/entry.asp?1649 (18 giugno
2013).
74
86. 4.2.4 Donazioni
Le pagine dedicate alle donazioni, come già evidenziato nel capitolo 3, sono una delle sezioni
più importanti nel sito di un’organizzazione non profit: tuttavia, sono le sezioni più trascurate
dal punto di vista dell’interazione. In molti casi la pagina delle donazioni non è responsive, ma
è offerta in una versione mobile, differente dal resto del sito. In altri casi la pagina delle
donazioni non è ottimizzata in alcun modo per i dispositivi mobile.
Nei casi in cui il sito indirizza a una pagina di servizi terzi (come PayPal) la responsabilità del
design del layout è esterna: al momento PayPal non offre pagine ottimizzate per i dispositivi
mobile.
4.2.5 Prestazioni
Dal punto di vista delle prestazioni, il peso complessivo delle homepage dei siti usati come casi
di studio si mantiene vicino alla media di 1.4 MB, mentre il tempo di caricamento è molto
variabile e in gran parte influenzato dalla quantità di immagini e contenuti multimediali
presenti.
In particolare le immagini influenzano negativamente i tempi di caricamento e i risultati dei test
di prestazione perché non sono caricate ridimensionate su dispositivi mobile e, spesso, nel
codice HTML non sono specificate le loro dimensioni, proprio perché variano insieme alla
75
87. viewport: è considerata una buona pratica specificare la larghezza e l’altezza di un’immagine nel
codice HTML perché aiuta a evitare reflow13 e repaint14 del browser (Google 2012).
Anche la presenza di codice in JavaScript contribuisce a rallentare i tempi di caricamento,
perché spesso questo codice è inserito, e quindi caricato dal browser, prima che sia necessario e
non è ottimizzato: rimandare il caricamento di questo codice, rendendolo asincrono o
esternalizzando le risorse (sono solo alcune delle tecniche possibili), potrebbe aiutare a ridurre i
tempi di caricamento.
4.3 Conclusioni
Il responsive web design in ambito non profit al momento è adottato soprattutto da
organizzazioni di medie o grandi dimensioni, con un’affermata presenza sul web.
È ancora presto per individuare pratiche standard che possano essere adottate anche da
organizzazioni più piccole: i pattern individuati (per il layout, la navigazione, alcune sezioni
specifiche) forniscono una prima linea guida, non priva di problematiche (riguardanti
soprattutto le prestazioni).
13
Un reflow avviene in seguito a un cambiamento che coinvolge il layout di una porzione o dell’intera pagina web:
dopo questo cambiamento il browser deve calcolare nuovamente la posizione e la geometria degli elementi nel
documento (Google 2012).
14
Un repaint avviene in seguito a un cambiamento che coinvolge l’aspetto di un elemento, ma non il layout della
pagina (un cambiamento nella visibilità, per esempio).
76
88. Un sito responsive per un’organizzazione non profit può rappresentare una scelta valida per
colmare una mancata presenza web su dispositivi mobile: è questo il caso di molte medie e
piccole organizzazioni.
Allo stesso modo la scelta di orientarsi verso uno sviluppo responsive potrebbe aiutare le
organizzazioni a ottimizzare l’esperienza utente su più dispositivi, rendendola meno
frammentaria (come si è individuato in alcuni casi).
77
89. Capitolo 5
WordPress
Sommario
In questo capitolo si introduce la storia e il funzionamento di WordPress, un CMS ideato per la
gestione di blog e siti, particolarmente popolare in tutto il mondo, anche in ambito non profit.
Si analizzano la struttura di un tema WordPress e alcune delle sue caratteristiche funzionali
particolarmente rilevanti per la realizzazione di un responsive web design. Infine si portano
alcuni esempi di siti non profit realizzati in WordPress.
5.1 Cos’è WordPress
WordPress è un CMS open-source creato nel 2003 da Matt Mullenweg e Mike Little a partire
da b2 cafelog, un software per la gestione di blog lanciato nel 2001 da Michel Valdrighi
(WordPress Codex).
La WordPress Foundation è un'organizzazione senza scopi di lucro che detiene logo e marchio
commerciale di WordPress. Fino al 2010 logo e marchio commerciale erano posseduti da
Automattic, una compagnia di sviluppo web fondata nel 2005 da Matt Mullenweg.
Attualmente la WordPress Foundation si occupa del supporto di WordPress e altri prodotti
correlati; Automattic, invece, gestisce WordPress.com, un servizio di hosting per blog basato
su WordPress.
78
90. WordPress è distribuito attraverso il sito WordPress.org con una licenza GPL, che dà all'utente
la libertà di condividere e modificare il codice, con alcuni limiti: i prodotti derivati devono
essere distribuiti con la stessa licenza.
Inizialmente WordPress offriva poche funzioni di base per la gestione di un blog; nel corso
dello sviluppo si è evoluto con l'introduzione di plugin, tassonomie personalizzate, formati per
gli articoli, diventando un CMS in grado di competere con concorrenti come Drupal e Joomla.
Tuttavia, l'obiettivo degli sviluppatori rimane quello di offrire un prodotto semplice, che non
richieda particolari competenze tecniche per essere usato (WordPress Philosophy).
5.2 Come funziona WordPress
WordPress è basato su PHP e MySQL ed è sviluppato da una comunità di utenti in tutto il
mondo, che periodicamente rilascia una nuova versione con funzionalità aggiuntive e
miglioramenti.
Dalla versione 3.2 i requisiti minimi per il corretto funzionamento di WordPress sono la
versione 5.2.4 di PHP e la versione 5.0 di MySQL.
Una bacheca (in inglese dashboard) permette di gestire e amministrare un’installazione
WordPress; ogni utente, secondo i propri permessi, può svolgere determinate funzioni:
inserimento e modifica di contenuti testuali e multimediali; gestione delle impostazioni di
installazione; personalizzazione dell'interfaccia.
79
91. I contenuti testuali inseriti in un'installazione WordPress sono denominati post: i due tipi
standard di post sono gli articoli e le pagine statiche. A ogni post sono associate delle
tassonomie (quelle standard sono le categorie, gerarchice, e le tag, non gerarchice15). Dalla
versione 3.0 WordPress supporta i Custom Post Types e dalla versione 2.9 le Custom Taxonomies.
Con i Custom Post Types è possibile definire nuovi tipi di post con caratteristiche
personalizzate (tassonomie e funzionalità supportate, permessi). Lo stesso vale per le Custom
Taxonomies, ma con riferimento alle tassonomie.
Dalla versione 3.1 WordPress ha introdotto i formati per i post, usati per personalizzare la
presentazione e la struttura del contenuto. Al momento i formati supportati sono nove: aside,
gallery, link, image, quote, status, video, audio, chat.
I formati per i post di WordPress ereditano in parte un modello di contenuto introdotto dalla
piattaforma per blog Tumblr (http://www.tumblr.com)16. Questi formati aiutano a rendere
WordPress un CMS adatto alla creazione di contenuto adattivo.
All'interno di un'installazione WordPress la presentazione dei contenuti è gestita attraverso un
tema, solitamente strutturato come segue:
15
Esiste un'altra tassonomia standard chiamata link_category e usata per la categorizzazione dei link in un'apposita
area della bacheca. Quest'area, però, è stata nascosta dalla versione 3.5, come spiegato in:
http://codex.wordpress.org/Links_Manager. Ultima visita: 29 marzo 2013.
16
Tumblr utilizza i seguenti formati: text, photo, quote, link, chat, audio, video.
80
92. •
index.php: è il file responsabile dell'aspetto dell'homepage e di tutte le altre pagine
se non sono presenti i file specifici a esse associati; questo file richiama i file
header.php e footer.php e non può essere assente da un tema,
•
header.php: contiene l'apertura del tag HTML <body> e tutte le informazioni
che devono essere inserite all'interno del tag <head>,
•
footer.php: contiene la chiusura dei tag HTML <body> e <html>,
•
style.css: il foglio di stile principale, che contiene anche alcuni dettagli obbligatori
sul tema (nome, URI, autore, descrizione); questo file non può essere assente dal tema,
•
functions.php: un file opzionale in cui sono racchiuse funzioni necessarie per il
funzionamento del tema.
A questi si aggiungono altri file per la gestione di categorie, tag, pagine, articoli, archivi, custom
post types, ecc. (Walk 2011).
Altri componenti importanti per il funzionamento di WordPress sono i plugin (pacchetti che
una volta installati offrono funzioni aggiuntive) e i widget (sezioni di contenuto solitamente
inserite all'interno di una barra laterale, chiamata sidebar).
5.3 Perché usare WordPress
WordPress è gratuito, open-source, personalizzabile e semplice da usare, soprattutto nella
gestione di siti non esageratamente complessi. WordPress è anche molto popolare e tra i siti
che utilizzano un CMS, occupa una fetta di mercato maggioritaria (Mark, How WordPress
Took The CMS Crown From Drupal And Joomla 2011).
81
93. WordPress può essere definito un CMS coupled, cioè “un CMS che non permette di
personalizzare separatamente l'esperienza utente per il desktop e il mobile senza un grande
sforzo” (McGrane 2012, 78).
Si potrebbe ipotizzare che WordPress non sia un CMS ideale per sperimentare con il
responsive web design. Tuttavia la presenza di determinate funzioni (custom post types,
formati per i post) testimonia la flessibilità che lo caratterizza e suggerisce una sua evoluzione
diretta verso la semanticità del markup, ingrediente essenziale per la creazione di contenuto
adattivo (Wachter-Boettcher 2012, 97).
Inoltre, nell’ambiente delle organizzazioni non profit, WordPress rappresenta una scelta
sensata per motivi di natura economica e funzionale (Maier 2013), nonostante i suoi evidenti
limiti nell’incorporare determinati princìpi della programmazione orientata agli oggetti che
limitano la sua maturazione (Shakespeare 2013).
5.4 Esempi di siti non profit in WordPress
Alcuni esempi di siti di organizzazioni non profit realizzati con WordPress:
•
American Foundation for Equal Rights (http://www.afer.org/)
•
Boot Campaign (http://www.bootcampaign.com, analizzato come caso di studio nel
capitolo 4)
•
Cure International (http://cure.org/)
•
JDRF (http://www.jdrf.org, analizzato come caso di studio nel capitolo 4)
•
Il blog della Livestrong Foundation (http://blog.livestrong.org/)
•
Il blog di TED (http://blog.ted.com/)
82
94. Questo breve elenco di siti sintetizza i due approcci più diffusi nell’uso di WordPress per le
organizzazioni non profit:
•
usare WordPress per la realizzazione dell’intero sito (la cui homepage sarà poi
costituita da un insieme di elementi statici e dinamici – è questo il caso di American
Foundation for Equal Rights, Boot Campaign, Cure International, JDRF),
•
usare WordPress per la creazione di un blog separato dal sito principale, raggiungibile
attraverso un link nel menu di navigazione principale (TED, Livestrong Foundation);
in questo caso gli ultimi contenuti del blog potrebbero essere ripresi nell’homepage del
sito principale, che però è gestito in maniera indipendente.
La scelta tra i due approcci può essere determinata da numerosi fattori (budget di operatività,
presenza o meno di un sito istituzionale non facilmente trasferibile in WordPress, esigenza di
separare la gestione dei contenuti statici e dinamici, ecc.).
5.5 Conclusioni
WordPress è un CMS semplice e ancora non del tutto maturo rispetto agli obiettivi che si
pone. Il suo uso, anche in ambito non profit, è molto diffuso e destinato a crescere. La sua
evoluzione costante, la sua flessibilità, il suo essere gratuito e open-source lo rendono una
scelta consigliata nell’ambito non profit.
Le sue funzionalità si sono evolute e arricchite nel tempo, introducendo elementi molto
importanti per l’organizzazione e la strutturazione del contenuto. WordPress non è ancora un
CMS in grado di fornire un markup completamente semantico, ingrediente importante per la
83
95. realizzazione di contenuto adattivo e quindi di siti responsive, tuttavia lo fa almeno in parte e
per questo può essere ritenuto una scelta valida in tale ambito.
84
96. Capitolo 6
Progettazione di un sito responsive
Sommario
In questo capitolo si descrive un possibile processo di sviluppo di un sito responsive,
illustrandone la prima fase, dedicata alla progettazione: definizione dei requisiti, definizione e
inventario del contenuto, realizzazione di wireframe di riferimento.
6.1 Metodo di lavoro
Non esiste un metodo standard per la progettazione, la prototipazione e la realizzazione di un
sito responsive.
Nel caso di un sito web con layout fisso il processo di sviluppo si concentra su un’unica vista
(il sito su uno schermo desktop), articolandosi in genere nelle fasi di progettazione, creazione
di wireframe, design statico, codice HTML, lancio.
Un sito responsive, al contrario, richiede la capacità di lavorare contemporaneamente su più
viste (almeno tre, modellate secondo le caratteristiche delle tipologie di dispositivi più
importanti: desktop, tablet, smartphone) e di modificare gli elementi del sito secondo le
esigenze di ognuna di esse, rispettando allo stesso tempo la gerarchia del contenuto.
85
97. L’obiettivo del responsive web design, come si è detto, è di usare lo stesso contenuto su tutti i
dispositivi, creando un’esperienza utente unica e coerente.
Nel 2012 un gruppo di sviluppatori, designer e operatori del settore ha organizzato a Londra
un summit17 sul responsive design per discutere alcune delle problematiche più importanti sul
tema, tra cui quella del processo di sviluppo o workflow.
Mark Boulton ha raccolto quanto emerso dalla discussione, sintetizzando un ideale processo di
sviluppo per un sito responsive, articolato in più fasi e in parte diverso dal tradizionale
processo di sviluppo web (Boulton 2012):
•
Sketch. Nella prima fase si creano dei mockup, contemporaneamente alla raccolta dei
requisiti del progetto.
•
Prototipo in HTML. Nella seconda fase si crea un prototipo funzionante del progetto,
in modo da capire nelle prime fasi come si comporterà su dispositivi diversi,
individuando subito possibili errori o fattori critici.
•
Design. Nella terza fase si crea il design del progetto (con strumenti di grafica o
direttamente nel browser, la scelta è indifferente).
•
Iterazione. Il progetto va incontro a numerose iterazioni.
•
Discussione. Una fase di incontro tra chi realizza il progetto e il cliente.
Boulton sottolinea anche la somiglianza tra un processo di questo tipo e un processo di
sviluppo agile, ovvero un processo basato sull’iterazione e lo sviluppo incrementale, che dia
17
http://www.responsivesummit.com/ (6 giugno 2013)
86
98. importanza agli individui, alle interazioni, al software funzionante, alla collaborazione con i
clienti (Beck, et al. 2001).
Il modello di Boulton non è l’unica proposta avanzata.
Durante la conferenza Mobilism 2012 (Mobilism 2012), svoltasi a Amsterdam nel maggio
2012, Stephen Hay, sviluppatore e designer a capo di Zero Interface, ha proposto un modello
di processo di sviluppo articolato in dieci fasi (Hay 2012), illustrato in maniera più dettagliata
nel volume “Responsive Design Worflow” (Hay 2013).
Le dieci fasi del modello sono così descritte da Hay:
•
Content inventory: si crea una lista degli elementi che costituiscono una pagina web.
•
Content reference wireframes: per ogni tipologia di pagina presente nel sito si crea un
wireframe di riferimento molto semplice, basato sugli elementi individuati nella prima
fase e si stabilisce una priorità nell’ordine di visualizzazione, ipotizzando una
navigazione della pagina lineare, cioè dall’alto verso il basso.
•
Designing in text: la pagina web è realizzata in forma testuale, in HTML, senza alcuno
stile grafico.
•
Linear design: si inseriscono le immagini all’interno del contenuto (se presenti) e si
applica uno stile grafico essenziale, concentrandosi sulla tipografia e i colori e non sul
layout.
•
Breakpoint graphs: si definisce il comportamento del layout del sito sulla base di alcuni
breakpoint.
•
Design for various breakpoints: si realizzano alcuni mockup in base ai breakpoint
individuati.
•
HTML prototype: si realizza un prototipo in HTML.
•
Present prototype screenshot: si presentano al cliente gli screenshot del prototipo in HTML.
87
