Università*degli*Studi*di*Milano*Bicocca*

Dipartimento+di+Informatica,+Sistemistica+e+Comunicazione+

Corso+di+laurea+in+Informatica+

+********

Il+responsive+web+design++per+le+organizzazioni+non+profit+

+

*

Relatore:*prof.*Roberto*POLILLO*

Co<relatore:*prof.*Flavio*DE*PAOLI*

+

+

Relazione+della+prova+finale+di:+

Francesco*VITALE*

Matricola*726886**

*

*

Anno+Accademico+2012<2013+

II

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

III

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

IV

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

V

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

VI

Conclusioni 129

Appendice A 132

Appendice B 134

Appendice C 142

Appendice D 144

Bibliografia 145!

VII

!

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

VIII

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

IX

Figura B.1 134

Figura B.2 135

Figura B.3 136

Figura B.4 137

Figura B.5 138

Figura B.6 139

Figura B.7 140

Figura B.8 141

!

!

!

X

Elenco delle tabelle

Tabella 1.1 14

Tabella 1.2 17

Tabella 4.1 50

Tabella 4.2 54

Tabella 4.3 58

Tabella 4.4 61

Tabella 4.5 64

Tabella 4.6 68

Tabella 7.1 105

Tabella 7.2 111

Tabella 7.3 114

Tabella 7.4 125

Tabella 7.5 126

XI

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.

XII

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.

2

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.

3

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.

4

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 open-

source, 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.

5

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.

6

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.

7

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.

8

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

9

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

10

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.

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.

#blog: 400 pixel(47.916667%)

#main: 960 pixel (100%)

11

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).

12

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.

13

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) { … }

14

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ì

15

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 (min-

width: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

16

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.

17

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

18

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.

19

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).

20

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.

21

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).

22

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.

23

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à.

24

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.

25

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).

26

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.

27

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).

28

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.”

29

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).

30

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 (Wachter-

Boettcher 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.”

31

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.

32

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).

33

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.

34

• 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.

35

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.

Logo

Immagine

News

Ricerca

Bottonisocial

Linkutili

Newsletter

Menu

Call toaction

36

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.

Logo

Immagine

News

Bottonisocial

Newsletter

Menu

Call toaction

Ricerca

37

Figura 3.3: l’homepage di http://www.greenpeace.org/italy/it/ (9 maggio 2013).

Menu

Slideshow

News

Logo Ricerca

Bottonisocial

Call toaction

Contenutisocial

38

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).

39

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).

Figura 3.5: l’homepage di http://www.unicef.it (9 maggio 2013).

Menu

Slideshow

News

Menu

Bottonisocial

Call toaction

Contenutisocial

Contenutisocial

Newsletter

Call toaction

Call toaction

Logo

40

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.

41

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.

42

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).

43

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

44

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 istituzionale

(http://worldwildlife.org/), qui analizzato come caso di studio.

Il sito istituzionale di WWF (http://worldwildlife.org/) è realizzato in HTML5.

45

Figura 4.2: l’homepage di http://www.worldwildlife.org (29 aprile 2013).

46

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.

47

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.

48

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-to-

action, 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.

49

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.

50

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

complessivo

Tempo di

caricamento

Numero di

richieste

YSlow PageSpeed

Desktop

PageSpeed

Mobile

1.18 MB 3.83 s 71 C (76%) 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.

51

Figura 4.8: l’homepage di http://www.barackobama.com (3 maggio 2013).

52

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,

53

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.

54

Tabella 4.2: le prestazioni di http://www.barackobama.com (3 maggio 2013).

Peso

complessivo

Tempo di

caricamento

Numero di

richieste

YSlow PageSpeed

Desktop

PageSpeed

Mobile

1.12 MB 6.63 s 82 C (74%) 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.

55

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).

56

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-to-

action, 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.

57

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

58

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

complessivo

Tempo di

caricamento

Numero di

richieste

YSlow PageSpeed

Desktop

PageSpeed

Mobile

2.47 MB 2.57 s 96 C (76%) 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).

59

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).

60

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.

61

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

complessivo

Tempo di

caricamento

Numero di

richieste

YSlow PageSpeed

Desktop

PageSpeed

Mobile

3.42 MB 3.91 s 75 C (75%) 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.

62

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).

63

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.

64

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

complessivo

Tempo di

caricamento

Numero di

richieste

YSlow PageSpeed

Desktop

PageSpeed

Mobile

1.44 MB 5.51 s 72 B (81%) 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.

65

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).

66

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).

67

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).

68

Tabella 4.6: le prestazioni di http://www.unicef.se (3 maggio 2013).

Peso

complessivo

Tempo di

caricamento

Numero di

richieste

YSlow PageSpeed

Desktop

PageSpeed

Mobile

1.35 MB 1.93 s 45 B (80%) 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.

69

• 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).

70

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.

71

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

72

• 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.

73

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).

74

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).

75

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

76

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).

77

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).

78

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.

79

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.

80

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.

81

• 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).

82

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/)

83

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

84

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.

85

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.

86

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)

87

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.

88

• Present prototype after revision: si presenta al cliente il prototipo dopo la revisione.

• Document for production: si creano i documenti necessari per passare dal prototipo alla

produzione del progetto.

Il modello proposto da Hay è un ottimo punto di partenza, ma il suo punto di vista,

concentrato quasi esclusivamente sul lato tecnico, può rivelarsi limitato quando a sviluppare un

sito non è una sola persona, ma un insieme di professionalità diverse, con compiti distinti: è

questo il caso di grandi agenzie o progetti particolarmente complessi.

Per questo motivo il modello di Hay andrebbe integrato in un tradizionale modello di sviluppo

web più complesso e articolato, in cui siano maggiormente distinte le fasi lavorative,

includendo aspetti che Hay tralascia: la definizione dei requisiti (scenari d’uso, casi d’uso,

obiettivi del sito), la progettazione dell’architettura, la verifica e la convalida dei prototipi, i test

di usabilità (Polillo 2006).

La progettazione di un sito responsive potrebbe richiedere più tempo nelle fasi iniziali del

progetto rispetto a quella di un sito non responsive (Kadlec 2013, 130), tuttavia un processo di

sviluppo agile basato sul modello di Hay elimina la necessità di progettare almeno tre versioni

differenti dello stesso sito (una per smartphone, una per tablet, una per desktop): i wireframe

di riferimento (in inglese content reference wireframe) creati nel browser permettono di lavorare sin

da subito su un’unica vista, permettendo di concentrarsi sulle problematiche del responsive

web design. È bene chiarire che non si tratta dei tradizionali wireframe adottati finora nello

sviluppo web: Hay ritiene che i wireframe tradizionali siano diventati troppo complessi (Hay

2013, 26), perciò non hanno il grado di flessibilità richiesto dallo sviluppo di un sito

89

responsive. Nei paragrafi successivi sarà usato per semplicità il termine wireframe per indicare i

wireframe di riferimento.

In seguito si analizzerà la progettazione e la realizzazione del sito istituzionale di un’ipotetica

organizzazione non profit. Sarà realizzato un prototipo seguendo un processo di sviluppo

modellato sulle indicazioni di Hay, ma in parte modificato.

6.2 Requisiti e definizione del contenuto

Lo scopo del prototipo è rappresentare una struttura semplificata del tradizionale sito

istituzionale di un’organizzazione non profit, con gli elementi essenziali individuati in alcuni

casi di studio (capitoli 3 e 4).

Il sito ha l'obiettivo primario di informare e coinvolgere i soci dell'organizzazione e eventuali

utenti esterni all'organizzazione che vogliano approfondire le sue attività.

Nel dettaglio, gli utenti potranno (casi d’uso):

• consultare informazioni di carattere istituzionale sull’organizzazione,

• consultare notizie, foto e video riguardanti le attività dell’organizzazione,

• consultare un elenco delle attività dell’organizzazione,

• effettuare donazioni dirette all’organizzazione,

• sfogliare un elenco di prodotti da acquistare per sostenere l’organizzazione,

• individuare le sedi dell’organizzazione,

• filtrare i contenuti del sito attraverso un motore di ricerca.

90

Tenendo conto dei requisiti e dei casi di studio analizzati, il contenuto del sito è così definito e

organizzato (in parentesi le pagine, o sezioni, di secondo livello):

• Homepage

• Chi siamo (Storia, Missione, Organi dirigenti, Statuto e bilancio)

• Dove siamo

• Cosa facciamo (Progetti in corso, Progetti conclusi)

• Cosa puoi fare tu (Diventa volontario, Lavora con noi)

• Sostienici (Donazioni, Acquisti solidali)

• Novità (Notizie, Eventi, Foto, Video)

In seguito i contenuti individuati sono catalogati per tipologia di pagina (cioé si fa riferimento

alla possibile struttura del layout delle pagine e si individuano le tipologie tra cui ci sono

differenze determinanti). In questo caso possono essere definiti cinque tipi di pagina:

• Homepage (per definizione l’homepage)

• Pagine interne (Chi siamo e pagine figlie, Dove siamo, Cosa facciamo e pagine figlie,

Cosa puoi fare tu, Sostienici, Novità e pagine figlie)

• Pagina delle donazioni (Donazioni)

• Pagina degli acquisti (Acquisti solidali)

• Pagina del prodotto

6.3 Inventario del contenuto e wireframe di riferimento

Dopo aver definito il contenuto, si procede a un inventario per ogni tipologia di pagina.

L’inventario serve a definire gli elementi presenti in ciascuna pagina, fornendo una base per la

realizzazione del layout.

91

In questa fase gli elementi sono definiti in modo generico; in seguito, vista la natura indicativa

dell’inventario, alcuni elementi potrebbero essere modificati o eliminati, se ciò dovesse essere

necessario.

Inventario per l’homepage:

1. Logo/Nome organizzazione

2. Navigazione

3. Modulo di ricerca

4. Contenuto in primo piano

5. Foto e video

6. Eventi

7. Notizie

8. Modulo newsletter

9. Link a piè di pagina

Inventario per le pagine interne:

1. Logo/Nome organizzazione

2. Navigazione

3. Modulo di ricerca

4. Contenuto pagina

5. Contenuto di supporto

6. Link a piè di pagina

Inventario per la pagina delle donazioni:

1. Logo/Nome organizzazione

2. Navigazione

3. Modulo di ricerca

92

4. Form donazioni

5. Contenuto di supporto

6. Link a piè di pagina

Inventario per la pagina degli acquisti (elenco dei prodotti):

1. Logo/Nome organizzazione

2. Navigazione

3. Modulo di ricerca

4. Descrizione acquisto

5. Elenco prodotti

6. Link a piè di pagina

Inventario per la pagina degli acquisti (singolo prodotto):

1. Logo/Nome organizzazione

2. Navigazione

3. Modulo di ricerca

4. Scheda del prodotto

5. Prodotti simili

6. Link a piè di pagina

Usando l’inventario come riferimento si creano i wireframe di riferimento in HTML, uno per

tipologia di pagina. La struttura dei wireframe può essere abbozzata rapidamente su carta,

prima di passare alla realizzazione in HTML.

La creazione dei wireframe può avvenire con la scrittura di proprio codice HTML, oppure con

l’aiuto di un framework. L’uso di un framework è particolarmente indicato se si intende

realizzare il prototipo in HTML con lo stesso framework: questa prima fase permette di

93

acquisire familiarità con i moduli e le funzionalità offerte dal framework, velocizzando la

successiva realizzazione del prototipo. Il risultato finale è indipendente dalla scelta. Un’altra

possibilità è quella di realizzare più di un wireframe per tipologia di pagina, in maniera

incrementale: un primo wireframe in HTML estremamente schematico, seguito da un secondo

wireframe realizzato con il framework scelto e più dettagliato o con parziali modifiche rispetto

al primo wireframe se si individuano già necessità particolari non emerse inizialmente. Si può

procedere fino alla realizzazione di un wireframe tradizionale, completo di tutti gli elementi

presenti nel sito, creato in HTML grazie al framework.

I wireframe consistono di un insieme di <div>, ciascuno appositamente modellato in CSS

perché occupi una certa porzione di spazio all’interno del layout. All’interno di ogni <div>

sono inserite alcune etichette numerate che fanno riferimento all’inventario del contenuto della

tipologia di pagina. Di seguito sono riportati alcuni esempi: l’homepage (figure 6.1, 6.2), la

pagina delle donazioni (figure 6.3, 6.4), la pagina degli acquisti solidali (figure 6.5, 6.6).

Il processo di progettazione illustrato può essere ripetuto iterativamente; si può inoltre tornare

a questa fase anche durante quelle successive o dopo un’iterazione completa se è necessario

aggiungere nuove tipologie di pagina o modificare in modo rilevante quelle già presenti.

94

Figura 6.1: il wireframe di riferimento dell’homepage, visualizzato in una viewport larga circa 1000 pixel.

95

Figura 6.2: il wireframe di riferimento dell’homepage, visualizzato in una viewport larga circa 500 pixel.

96

Figura 6.3: il wireframe di riferimento della pagina delle donazioni, visualizzato in una viewport larga circa

1000 pixel.

97

Figura 6.4: il wireframe di riferimento della pagina delle donazioni, visualizzato in una viewport larga circa 500

pixel.

98

Figura 6.5: il wireframe di riferimento della pagina degli acquisti solidali, visualizzato in una viewport larga

circa 1000 pixel.

99

Figura 6.6: il wireframe di riferimento della pagina degli acquisti solidali, visualizzato in una viewport larga

circa 500 pixel.

100

6.4 Breakpoint e design

I breakpoint graphs ipotizzati da Hay sono una schematizzazione statica dei wireframe di

riferimento e pertanto possono essere poco utili. I vantaggi dei wireframe in HTML sono la

rapidità di realizzazione e la possibilità di modificarli ripetutamente e iterativamente senza

grande sforzo. I grafici statici, invece, sono più complessi da realizzare perché richiedono l’uso

di uno strumento grafico, meno malleabile rispetto al linguaggio HTML. Alternativamente,

potrebbero essere realizzati attraverso schermate statiche dei wireframe, risparmiando tempo.

Tuttavia, nel caso di un prototipo base, come quello oggetto di studio, i wireframe, insieme a

semplici sketch su carta del design strutturale del layout nelle differenti viste, sono più che

sufficienti per iniziare a lavorare in HTML.

L’uso di un framework riduce considerevolmente il tempo dedicato a queste fasi: non avendo a

disposizione il vero contenuto del sito, la fase del design testuale ha un’importanza marginale e

il design lineare proposto dal framework è sufficiente per gli scopi del progetto. In questa sede

sono tralasciate le fasi dedicate al design visuale.

6.5 Conclusioni

La progettazione di un sito responsive richiede molta flessibilità e la capacità di adattare vecchi

strumenti a nuove esigenze.

Organizzare il processo di sviluppo secondo un preciso metodo di lavoro sin dall’inizio

permette di evitare problemi nel lavorare con più dispositivi.

101

I wireframe di riferimento creati in HTML sono uno strumento semplice e malleabile, adatto a

essere modificato più volte, iterativamente, fino a raggiungere il grado di fedeltà desiderato

nella definizione degli elementi principali del layout.

L’uso di un framework può accelerare il processo di creazione dei wireframe e anticipare le

possibili soluzioni che saranno poi adottate nella realizzazione del prototipo in HTML.

102

Capitolo 7

Realizzazione di un prototipo in HTML

Sommario

In questo capitolo è illustrata la realizzazione del prototipo in HTML di un sito responsive

progettato per una fittizia organizzazione non profit. Sono analizzati gli aspetti più rilevanti del

processo di sviluppo: la navigazione, il layout delle pagine, l’uso di HTML5 per i form e la

geolocalizzazione, il problema delle immagini responsive in WordPress. Infine si propongono

alcune considerazioni sull’ottimizzazione del codice, riportando i risultati ottenuti con il

prototipo.

7.1 Strumenti di lavoro: ambiente di sviluppo e framework

Il prototipo in HTML è sviluppato in ambiente WordPress (si veda il capitolo 5 per alcuni

dettagli sul funzionamento di questo CMS), con l’uso di un framework.

In ambiente WordPress il termine framework può avere due significati (WordPress Codex):

• una libreria con elementi pronti per facilitare lo sviluppo di un tema: da sola non può

essere installata e usata come tema WordPress;

103

• un tema base, che permetta di accelerare lo sviluppo di temi WordPress attraverso la

creazione di temi figli, la personalizzazione di alcune caratteristiche del tema di

partenza o la realizzazione di prototipi.

I framework disponibili per WordPress sono numerosi. Segue un elenco di alcuni tra i

maggiori framework responsive per WordPress appartenti alla categoria dei temi base:

• Bones18, creato dall’agenzia Themble, basato su HTML5 Boilerplate19;

• Foundation20, creato dall’agenzia Zurb;

• Reverie21, creato dall’agenzia ThemeFortress, basato su Foundation;

• Roots22, creato dallo sviluppatore Ben Word, basato su HTML5 Boilerplate e su Bootstrap23 di Twitter;

• WP Bootstrap24, realizzato dall’agenzia 320press, basato su Bootstrap di Twitter.

Foundation è in realtà un generico framework HTML, identificabile come una libreria, di cui

esistono diverse implementazioni per WordPress, tra cui:

• Foundation, for WordPress25, creato dallo sviluppatore Drew Morris, basato sulla

versione 4.0 di Foundation;

18 http://themble.com/bones/

19 http://html5boilerplate.com/

20 http://foundation.zurb.com/

21 http://themefortress.com/reverie/

22 http://www.rootstheme.com/ 23 http://twitter.github.io/bootstrap/

24 http://320press.com/wpbs/

104

• Reverie, già citato, basato sulla versione 4.0 di Foundation;

• WP-Foundation26, creato dall’agenzia 320press, basato sulla versione 3.0 di

Foundation.

7.1.1 Criteri di valutazione dei framework

Il framework può essere valutato e scelto anche prima dello sviluppo del prototipo in HTML e

usato per sviluppare i wireframe di riferimento, come illustrato nel capitolo precedente.

Alternativamente si può usare un framework per sviluppare i wireframe e un altro framework

per lo sviluppo del prototipo. Oppure non usare alcun framework.

Nella valutazione dei framework elencati, si è tenuto conto di alcune caratteristiche:

• licenza,

• prezzo,

• documentazione,

• supporto,

• codice HTML5,

• mobile-first,

• navigazione responsive implementata,

• librerie JavaScript in uso.

25 https://github.com/drewsymo/Foundation

26 http://320press.com/wp-foundation/

105

7.1.2 Scelta del framework

Tabella 7.1: criteri di valutazione dei framework.

Bones Foundation Reverie Roots Bootstrap

Licenza WTFPL27 MIT28 MIT MIT Gpl, Apache29

Prezzo Gratuito Gratuito Gratuito Gratuito Gratuito

Documentazione Parziale Dettagliata Dettagliata Parziale Dettagliata

Supporto No Sì Parziale Parziale No

HTML5 Sì Sì Sì Sì Sì

Mobile-first Sì Sì Sì No No

Navigazione No Sì Sì Sì Sì

Librerie JS jQuery,

Modernizr

Zepto,

Modernizr

Zepto,

Modernizr

jQuery,

Modernizr

jQuery,

Modernizr

27 http://en.wikipedia.org/wiki/WTFPL (7 giugno 2013) 28 https://en.wikipedia.org/wiki/MIT_License (7 giugno 2013)

29 https://www.apache.org/licenses/LICENSE-2.0.html (7 giugno 2013)

106

Il framework scelto è Foundation: offre un’ottima documentazione, ha un design lineare molto

gradevole, è molto flessibile, offre una navigazione responsive con un menu a comparsa (la

tipologia più diffusa e che rappresenta il miglior compromesso attuale).

7.2 Navigazione

L’inventario del contenuto redatto nella fase di progettazione del sito (vedi capitolo 6) è un

utile punto di partenza per creare il menu principale di navigazione, che deve permettere

all’utente di raggiungere tutte le sezioni del sito.

Sono presenti sei voci di primo livello e quattordici di secondo livello, così organizzate (in

parentesi le voci di secondo livello):

• Home

• Chi siamo (Storia, Missione, Organi dirigenti, Statuto e bilancio)

• Dove siamo

• Cosa facciamo (Progetti in corso, Progetti conclusi)

• Cosa puoi fare tu (Diventa volontario, Lavora con noi)

• Sostienici (Donazioni, Acquisti solidali)

• Novità (Notizie, Eventi, Foto, Video)

La prima voce, che permette di tornare all’homepage da qualsiasi pagina, è sempre presente e

identificata col nome dell’organizzazione; la voce “Novità”, invece, non corrisponde a una

sezione del sito, ma raccoglie le categorie dei contenuti dinamici (notizie, eventi, foto, video).

Il framework Foundation offre una navigazione responsive realizzata con un menu a comparsa

che, al variare della viewport (quando la larghezza è inferiore a 768 pixel), è attivato da un

107

bottone a tre linee (�), accompagnato da un’etichetta testuale (figura B.2). Il menu a

comparsa, che mantiene i secondo livelli, funziona grazie a JavaScript.

Se l’utente disattiva JavaScript (o accede al sito con un browser che non supporta JavaScript), il

menu non è accessibile: per ovviare a questo problema è stato sufficiente creare un secondo

menu di navigazione, posizionato nel footer di ogni pagina. Questo secondo menu raccoglie

tutte le voci di primo livello e solo alcune di secondo livello: in questo modo tutti i contenuti di

primo livello del sito sono accessibili da ogni pagina, in tutte le situazioni; i contenuti di

secondo livello, invece, nel caso in cui JavaScript non sia disponibile, sono accessibili da un

menu interno presente nelle pagine interne.

7.3 Layout e media queries

I layout dell’homepage e delle pagine interne del prototipo sono realizzati usando la griglia

fluida di Foundation, che permette un discreto controllo sulla gerarchia del contenuto.

Il layout adottato in tutte le pagine è di tipo fluido: quando la larghezza della viewport

diminuisce, il contenuto è impilato verticalmente. Si tratta del più diffuso e semplice pattern di

layout responsive (si veda il capitolo 4 per ulteriori dettagli). Il suo comportamento è

particolarmente adatto per la struttura del sito, che prevede la disposizione del contenuto in

due colonne: nella colonna a sinistra è presente il contenuto principale della pagina; nella

colonna a destra (di dimensioni inferiori, perché meno importante) il contenuto aggiuntivo o di

supporto. Un layout fluido, attraverso la disposizione lineare delle colonne (dall’altro verso il

108

basso) permette di preservare la gerarchia del contenuto, almeno in casi in cui la struttura del

sito è così semplice.

Le media queries adottate sono di tipo proporzionale, cioè al loro interno non sono usati i

pixel come unità di misura per stabilire i breakpoint, ma gli em. L’uso degli em permette di

conservare le proporzioni del layout anche quando l’utente usa le funzioni di zoom del

browser30 o modifica la grandezza dei caratteri. In questo modo l’utente è in grado di

personalizzare e ottimizzare l’aspetto del sito secondo esigenze personali, senza che il layout

risulti compromesso.

7.3.1 Homepage

L’homepage del prototipo (figura B.1) è composta da quattro sezioni (senza contare la testata e

il footer), come già illustrato nell’inventario del contenuto (si veda il capitolo 6). Queste sono,

in ordine gerarchico: primo piano, foto e video, eventi, notizie. Quando la viewport si restringe

le sezioni sono impilate verticalmente, rispettando la gerarchia (figure B.2, B.3).

Poiché HTML e CSS non permettono ancora una completa manipolazione del contenuto,

l’ordine gerarchico delle sezioni deve essere rispettato e riprodotto quando si scrive il codice

della pagina.

30 Un bug di webkit causa un malfunzionamento della funzione di zoom in Safari. Per questo motivo le media queries proporzionali non hanno effetto. Maggior dettagli: https://bugs.webkit.org/show_bug.cgi?id=41063 (8 giugno 2013).

109

Si tratta di un layout molto semplice ideato con lo scopo di creare una homepage informativa,

con alcuni elementi multimediali.

7.3.2 Pagine interne

La struttura delle pagine interne è molto simile a quella dell’homepage, a eccezione della

differenza di contenuti.

Nella colonna di sinistra è presente il contenuto principale della pagina, preceduto da uno

schema di navigazione (breadcrumb) che indica all’utente in quale sezione del sito si trova. Nella

colonna di destra il contenuto di supporto, usato per orientare l’utente verso gli altri contenuti

del sito: un archivio per categorie e data, un elenco di tag, un elenco di ultimi articoli, un

bottone call-to-action.

Questa struttura varia soltanto in due tipologie di pagina: la pagina degli acquisti solidali

(realizzata con la creazione di un apposito Custom Post Type), costituita da una griglia fluida al

cui interno ci sono le foto dei prodotti (figure B.7, B.8) e quella delle donazioni (analizzata nel

paragrafo successivo).

7.4 Donazioni: i form di HTML5

La pagina delle donazioni è una delle sezioni più importanti nel sito di un’organizzazione non

profit.

Nel prototipo questa sezione è sviluppata su due colonne: nella colonna a sinistra è inserito un

form in cui l’utente inserisce i propri dati per portare a termine la donazione (l’ipotesi è che il

110

sito non si appoggi a un servizio di terze parti per la raccolta dei dati); nella colonna a destra è

posto un modulo call-to-action (figura B.5). Al variare della viewport le due colonne sono

posizionate verticalmente una sotto l’altra (figura B.6).

Una pagina di questo tipo permette di sfruttare i nuovi input introdotti nella specifica di

HTML5, grazie a una serie di attributi e nuove funzionalità (Keith 2010, 40).

L’attributo type permette di specificare la tipologia di dati che l’utente deve inserire

nell’elemento (R. Clark 2013):

• email (un indirizzo email),

• tel (un numero di telefono),

• number (un numero),

• url (un indirizzo web),

• search (una stringa di ricerca),

• range (un range numerico),

• date (anno, mese e giorno),

• datetime (anno, mese, giorno, ore, minuti, secondi, fuso orario),

• datetime-local (come sopra, senza fuso orario),

• time (ore, minuti, secondi),

• month (mese),

• week (settimana),

• color (un colore espresso in notazione esadecimale).

L’attributo type, soprattutto nel caso di dispositivi mobile, condiziona il comportamento del

browser, che in molti casi è in grado di mostrare all’utente un layout di tastiera su schermo

adeguato al tipo di input (figura 7.1) o un elemento visuale appropriato. In alcuni casi (per

111

esempio con il tipo di input email) i browser possono eseguire un semplice test di validazione

(non sempre affidabile).

Figura 7.1: gli input di HTML5 in azione.

La tabella 7.2 riassume il supporto browser per i form di HTML5: la maggior parte dei browser

per pc desktop non supportano questo tipo di input, ma ciò non è un problema perché in

questo caso i dati saranno inviati come se si trattasse di input di tipo testuale. L’esperienza

utente su questi browser non sarà ottimale, ma resterà accettabile.

Tabella 7.2: il supporto dei browser ai form di HTML5, http://caniuse.com (7 giugno 2013).

Browser Versione

Internet Explorer Supporto parziale nelle versioni 10.0 e 11.0

Firefox Supporto parziale dalla versione 4.0

112

Browser Versione

Chrome Supporto parziale in tutte le versioni

Safari Supporto parziale dalla versione 4.0

Opera Supporto completo dalla versione 9.0 alla 12.1;

supporto parziale nella versione 15.0

iOS Safari Supporto parziale dalla versione 4.0 alla 4.3; supporto

completo dalla versione 5.0

Opera mini Nessun supporto

Android Supporto parziale dalla versione 4.0

Blackberry Supporto parziale dalla versione 10.0

Opera mobile Supporto completo dalla versione 10.0; supporto

parziale nella versione 14.0

Chrome per Android Supporto parziale

Firefox per Android Supporto parziale

I nuovi tipi di input sono una delle più importanti caratteristiche di HTML5 che aiutano a

creare un sito semantico e responsive.

113

7.5 Geolocalizzazione in HTML5

La sezione “Dove siamo” fornisce un valido esempio per l’impiego di una nuova API31

introdotta in HTML5 e relativa alla geolocalizzazione dell’utente (Popescu 2012).

Se il dispositivo (e il browser) in uso supporta questa funzione (tabella 7.3), è possibile avere

accesso alla posizione dell’utente, espressa in coordinate (latitudine e longitudine).

Tramite JavaScript è possibile usare i dati ottenuti per manipolare i contenuti della pagina o

fornire funzionalità aggiuntive.

Nel caso di un’organizzazione non profit si può ipotizzare l’esigenza di fornire un elenco delle

sedi (inserite con la creazione di un Custom Post Type che supporti un sistema di etichettatura

geografica) che si trovano a una certa distanza dalla posizione dell’utente.

Tralasciando la creazione dell’algoritmo di ordinamento, per ottenere la posizione dell’utente è

sufficiente implementare alcune semplici funzioni usando le proprietà della specifica (Pilgrim):

un esempio è disponibile nell’appendice C.

All’interno della pagina sarà sempre presente un form per filtrare i dati manualmente: non solo

perché la geolocalizzazione potrebbe essere negata, non supportata o non individuata, ma

anche perché l’utente potrebbe non voler visualizzare le sedi più vicine a lui in un determinato

31 Application Programming Interface: un insieme di procedure di programmazione.

114

momento. Presumere il comportamento dell’utente in base alle capacità del dispositivo sarebbe

sbagliato e contrario allo scopo del responsive web design.

Tabella 7.3: il supporto browser alla geolocalizzazione, http://caniuse.com (10 giugno 2013).

Browser Versione

Internet Explorer Dalla versione 9.0

Firefox Dalla versione 3.5

Chrome Dalla versione 5.0

Safari Dalla versione 5.0

Opera Dalla versione 10.6

iOS Safari Tutte le versioni

Opera Mini Nessun supporto

Android Tutte le versioni

Blackberry Tutte le versioni

Opera Mobile Dalla versione 11.0

115

Browser Versione

Chrome per Android Tutte le versioni

Firefox per Android Tutte le versioni

7.6 Immagini responsive

Il problema delle immagini responsive rimane una delle questioni più critiche all’interno del

dibattito sul responsive web design. Si tratta di un problema particolarmente importante nel

caso del sito di un’organizzazione non profit, che in genere fa un ampio uso di contenuti

multimediali.

In attesa di scoprire l’evoluzione della specifica di HTML5, esistono alcune tecniche già

sperimentate, come già accennato nel capitolo 1, che possono fornire una possibile soluzione.

7.6.1 Immagini fluide

Ethan Marcotte, ideatore del responsive design, propone l’uso di immagini fluide (o flessibili),

attraverso una regola da inserire nel CSS:

img { max- width: 100%; }

Si tratta di una soluzione banale da implementare e valida su qualsiasi immagine di un sito web

(inserita in passato o in futuro). Tuttavia, i problemi delle immagini fluidi sono molteplici:

116

l’immagine è ridimensionata dal browser, è caricata indipendentemente dal dispositivo in uso,

senza essere ottimizzata e perciò rallenta enormemente il caricamento di una pagina. Inoltre,

ridimensionando eccessivamente un’immagine molto grande, se ne potrebbe perdere il senso,

compromettendone l’art direction (Grigsby, 8 Guidelines and 1 Rule for Responsive Images

2013).

7.6.2 Tecniche basate su JavaScript

Molte tecniche proposte per ottenere immagini responsive fanno affidamento su JavaScript.

Soluzioni di questo tipo introducono complessità nel processo di sviluppo e causano un

incremento nel numero di richieste HTTP, oltre a essere inaccessibili agli utenti che decidano

di disattivare JavaScript (Cáceres, Marquis e Weiss 2013). Vale comunque la pena esplorarle

per giungere a un compromesso.

7.6.3 Percorso alternativo con JavaScript

La tecnica del percorso alternativo prevede di inserire l’indirizzo di un’immagine alternativa a

quella standard, attraverso parametri o attributi introdotti nel tag img, come in questi esempi:

• <img src="small.jpg?full=large.jpg"> (tag con parametro),

• <img src=”small.r.jpg” data-fullsrc=”large.jpg”> (tag con attributo).

In seguito con JavaScript si decide quale immagine caricare.

117

Questa tecnica permette di caricare immagini diverse secondo le caratteristiche del dispositivo

e, se si desidera, di curarne l’art direction. Ma senza JavaScript non funziona, può creare

conflitti con la cache, i proxy e i Content Delivery Network32 e crea un ciclo nella ricerca di

tutti i tag img all’interno della pagina (Grigsby, Responsive IMGs Part 2 — In-depth Look at

Techniques 2011).

Un altro problema, come già accennato nel capitolo 1, è dato dal fatto che “molti dei browser

più nuovi hanno implementato una feature di image prefetching che permette alle immagini di

essere caricate prima del parsing del body del documento”33 (Marquis, Responsive Images:

How they Almost Worked and What We Need 2012).

Come spiega Mat Marquis (Marquis, Responsive Images: How they Almost Worked and What

We Need 2012):

“Il nostro scopo è quello di rappresentare e mandare il contenuto in maniera appropriata e

per questo motivo credo che andrebbe risolto nel markup. Tuttavia, il tag img non è adatto

a questo scopo. [...] Quello di cui abbiamo bisogno è un nuovo pattern di markup, uno che

ci permetta di specificare più file sorgente, ma che specifichi ancora il markup

32 Un sistema di server distribuiti. 33 Traduzione a cura di Italian List Apart: http://www.italianalistapart.com/articoli/58-numero-44-14-febbraio-

2012/234-immagini-responsive-quasi-funzionato-cosa-ci-serve (7 giugno 2013).

118

universalmente riconosciuto come contenuto di fallback per i browser che non

riconoscono il nuovo tag.”34

7.6.4 Il tag noscript

Per risolvere i problemi evidenziati nel paragrafo precedente, una tecnica introdotta da Mairead

Buchan fa uso del tag <noscript> per evitare caricamenti ridondanti, come in questo esempio

di Antti Peisa:

<noscript data-large='Koala.jpg' data- small='Koala-small.jpg' data-

alt='Koala'>

<img src='Koala.jpg' alt='Koala' />

</noscript>

In seguito con JavaScript si decide quale immagine caricare: nessuna delle altre immagini è

caricata.

Questa tecnica fornisce un’immagine di fallback quando JavaScript non è presente, evita

caricamenti ridondanti, non richiede di appoggiarsi sui cookie o sul file htaccess per

funzionare. Si tratta però di una tecnica poco elegante, che potrebbe dare problemi con alcune

implementazioni di JavaScript (Grigsby, Responsive IMGs Part 2 — In-depth Look at

Techniques 2011).

34 Ibid.

119

7.6.5 Tecniche server-side

Le possibili soluzioni server-side al problema delle immagini responsive prevedono di affidarsi

a servizi di terze parti per il ridimensionamento dell’immagine. In seguito, grazie alla device

detection o all’uso delle stringhe degli user agent è possibile decidere le dimensioni dell’immagine

da caricare.

Un esempio che implementa questa soluzione è Sencha.io35.

Una tecnica ibrida (server e client side) è proposta da Adaptive Images36, un plugin che sfrutta

JavaScript, PHP, la libreria GD e il file htaccess per rendere le immagini in una pagina web

responsive.

7.6.6 Proposte per la specifica di HTML5

Sono due le proposte per la specifica di HTML5 che puntano a risolvere il problema delle

immagini responsive: l’elemento <picture> (di cui si è già discusso nel capitolo 1), proposto

da Bruce Lawson, e l’attributo srcset, proposto da Apple (B. Lawson, HTML5 adaptive

images: end of round one 2012).

L’elemento picture prevede di specificare un numero variabili di immagini e di scegliere quale

caricare grazie alle media queries, come nel seguente esempio:

35 http://www.sencha.com/products/io/

36 http://adaptive-images.com/

120

<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>

L’attributo srcset, invece, è una possibile estensione del tag img che permette di specificare

immagini alternative a quella standard attraverso una sintassi non esattamente intuitiva:

<img alt="The Breakfast Combo" src="banner.jpeg" srcset="banner-

HD.jpeg 2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x">

In questo esempio l’immagine standard è banner.jpeg. Le altre immagini sono caricate in altri

casi:

• banner-HD.jpeg, quando il dispositivo in uso ha uno schermo ad alta densità di pixel

(2x),

• banner-phone.jpeg, quando la viewport ha larghezza massima di 100 pixel (100w),

• banner-phone-HD.jpeg, quando la viewport ha larghezza massima di 100 pixel e lo

schermo è ad alta densità.

L’elemento picture e l’attributo srcset possono essere combinati insieme.

121

Le due soluzioni sono semantiche e pensate per la specifica di HTML, ma sono verbose e

poco intuitive (Wilcox 2012); inoltre non sono state accolte con entusiasmo dai produttori di

browser (B. Lawson 2013).

7.7 Immagini responsive in WordPress

Qualunque sia la tecnica scelta per affrontare il problema delle immagini responsive, deve

essere in seguito integrata all’interno dell’ambiente WordPress. Esistono alcuni plugin che

mettono in pratica alcune delle tecniche illustrate nel paragrafo precedente e offrono così una

soluzione parziale al problema.

7.7.1 Gestione delle immagini in WordPress

In ambiente WordPress esistono due tipi di immagini:

• le immagini inserite in linea, all’interno di una pagina, attraverso l’editor WYSIWYG37;

• le immagini featured (o immagini in evidenza): se ne può assegnare al massimo una a

ogni pagina che le supporta.

Di ogni immagine caricata attraverso l’editor WYSIWYG, WordPress genera tre anteprime

(thumbnail, medium, large) con le dimensioni scelte dall’utente nella bacheca delle impostazioni.

Grandezze aggiuntive (senza limiti, ognuna col proprio nome) possono essere specificate nel

file functions.php di un tema.

37 What You See Is What You Get: un editor in cui il contenuto inserito compare in una forma corrispondente a quella finale.

122

Le immagini in evidenza sono richiamate all’interno dei file di un tema attraverso la funzione

the_post_thumbnail(); in cui è possibile inserire come parametro il nome della dimensione

desiderata.

Ipotizzando delle dimensioni arbitrarie (thumbnail: 200x200 pixel, medium: massima

larghezza/altezza 350pixel, large: massima larghezza 700 pixel o massima altezza 500 pixel), a

partire dal file esempio.jpg (di dimensioni 1400x90 pixel), saranno generate le seguenti

immagini:

• esempio-200x200.jpg,

• esempio-350x218.jpg,

• esempio-700x437.jpg.

7.7.2 Immagini in evidenza

Le immagini in evidenza possono essere manipolate attraverso richieste condizionali basate

sull’user agent (McCollin 2012). Una soluzione più affidabile consiste nel creare dimensioni

adatte al tipo di layout ideato: in questo modo, anche se in alcuni casi le immagini sono

ridimensionate dal browser, il loro peso è trascurabile e non incide più del dovuto sulle

prestazioni.

Nel prototipo le immagini in evidenza sono presenti in più di un layout: nell’homepage, nelle

categorie “Foto” e “Video”, nella pagina dei prodotti acquistabili.

123

Si tratta di immagini di dimensioni 200x200 pixel, che, grazie alla compressione di WordPress,

pesano circa 15 KB nel caso di immagini complesse e tra 4 e 10 KB nel caso di immagini con

sfondo prevalentemente vuoto.

Alcuni problemi in termini di prestazioni sono presenti soprattutto per le categorie “Foto” e

“Video” quando visualizzate su uno schermo largo: in questo caso le immagini in evidenza

sono ridimensionate, causando un overload38 di circa 125 KB.

Questo approccio è un possibile compromesso, nato dall’esigenza di non fare affidamento sul

rilevamento dell’user agent, una tecnica discutibile: in questo modo si ha un overload solo nella

situazione meno problematica, quella dei pc desktop con uno schermo largo. In tutti gli altri

casi le immagini risultano della dimensione giusta per risultare al tempo stesso poco pesanti e

adeguate allo schermo.

7.7.3 Una soluzione ibrida per le immagini in linea

Le immagini in evidenza possono essere gestite nella creazione del tema, ipotizzando soluzioni

di compromesso, come illustrato nel paragrafo precedente. Ciò non è possibile con le

immagini in linea, che saranno inserite all’interno delle pagine dall’utente che si occupa di

gestire il sito.

Per garantire l’usabilità del sistema occorre una soluzione che manipoli i tag img all’interno

delle pagine senza che sia richiesta un’azione da parte dell’utente.

38 Peso aggiuntivo che potrebbe essere eliminato.

124

Tra i numerosi plugin che cercano di risolvere questo problema, i due più validi sono

Picturefill.WP sviluppato da Kyle Reicks39 e PB Responsive Images sviluppato dall’agenzia

Phenomblue40.

Picturefill.WP si basa su Picturefill41, un plugin JavaScript sviluppato da Scott Jehl, che imita la

sintassi proposta nella bozza dell’elemento picture, attraverso elementi HTML non

sperimentali.

Picturefill.WP analizza il contenuto di una pagina WordPress alla ricerca dei tag img, e li

sostituisce con una sintassi in cui le immagini sono racchiuse in elementi <span>, con

un’immagine di fallback racchiusa in un elemento <noscript>. L’immagine da caricare è

scelta con l’uso di media queries inserite come attributi degli elementi <span>.

PB Responsive Images funziona in maniera molto simile a Picturefill.WP, con gli elementi

<span> che racchiudono le immagini e i rispettivi parametri e un tag <img> usato per

l’immagine di fallback.

Un esempio di codifica è presente nell’appendice C.

Inoltre PB Responsive Images usa SLIR42 (Smart Lencioni Image Resizer), una libreria creata

per ridimensionare le immagini in maniera dinamica, attraverso una serie di parametri inseriti

nell’url.

39 http://wordpress.org/plugins/picturefillwp/ 40 http://wordpress.org/plugins/pb-responsive-images/

41 https://github.com/scottjehl/picturefill

125

In questo modo è possibile personalizzare i parametri da passare alle media queries.

Un confronto quantitativo tra i due plugin evidenzia la superiorità di PB Responsive Images.

Si considera una pagina in cui sono inserite, all’interno del testo, quattro immagini di grandi

dimensioni, che portano il peso della pagina a 4.2 MB.

Il framework Foundation adotta la regola CSS per la creazione di immagini fluide: in questo

modo tutti i dispositivi devono caricare 4.2 MB di dati, con 15 richieste HTTP.

L’uso di Picturefill.WP, con i parametri impostati di default, permette una riduzione del peso

considerevole (tabella 7.4): da 4.2 MB si passa a 566 KB.

Tabella 7.4: prestazioni ottenute con Picturefill.WP.

Desktop Tablet Mobile

Richieste 16 16 16

Peso 566 KB 566 KB 229 KB

PB Responsive Images, con i parametri impostati di default, è ancora più efficiente (tabella

7.5): il peso complessivo scende a 375 KB, mentre le richieste HTTP aumentano.

42 https://github.com/lencioni/SLIR

126

Tabella 7.5: prestazioni ottenuto con PB Responsive Images.

Desktop Tablet Mobile

Richieste 17 17 17

Peso 375 KB 375 KB 178 KB

PB Responsive Images offre anche alcune funzioni che possono essere usate all’interno dei file

di un tema: in questo modo anche le immagini in evidenza possono essere gestite attraverso il

plugin e ulteriormente ottimizzate.

In aggiunta al plugin è importante continuare a usare la regola per le immagini fluide, in ogni

caso valida all’interno di un responsive design.

In conclusione, PB Responsive Images, in unione alla tecnica delle immagini fluide, offre

un’ottima soluzione al problema delle immagini responsive all’interno di WordPress:

configurando adeguatamente i parametri si può ottenere una netta diminuzione del peso delle

immagini, che avranno una dimensione adeguata rispetto al dispositivo in uso.

7.8 Prestazioni, ottimizzazione e risultati ottenuti

Le prestazioni di un sito sono parte integrante del design (Frost 2013).

127

Sviluppare un sito nel browser, come ipotizzato nel processo di sviluppo illustrato, permette di

controllare da subito l’efficacia del progetto in termini di prestazioni.

I fattori critici individuati nel capitolo 4 forniscono una panoramica dei più comuni problemi

di prestazione all’interno di un sito responsive: le immagini, il codice JavaScript, la mancata

ottimizzazione del codice.

Oltre il 60% del peso di una pagina web è dato dalle immagini (HTTP Archive - Interesting

Stats 2013): adottare una soluzione per ottenere immagini responsive contribuisce a diminuire

notevolmente il peso di una pagina, soprattutto per i dispositivi mobile, per i quali le

prestazioni sono ancora più importanti.

A termine dello sviluppo è necessario ottimizzare anche il codice, in termini di peso e

caricamento.

Il prototipo realizzato, in una pagina qualsiasi, usa circa sei librerie JavaScript:

• jQuery (per il funzionamento di alcuni plugin),

• zepto (per il funzionamento del framework),

• Modernizr (per la compatibilità con vecchi browser),

• Picturefill (per il funzionamento di PB Responsive Images),

• Matchmedia (per il funzionamento di PB Responsive Images),

• Foundation (per il funzionamento del framework).

Il numero aumenta se si includono altre funzionalità aggiuntive come la paginazione in

JavaScript usata negli archivi o le gallerie interattive, usate in determinati articoli.

128

Minimizzare il codice di ciascuna libreria porta a un notevole risparmio nel peso delle pagine:

in alcuni casi il peso di ogni file si riduce di oltre il 40%.

Ciò non basta. Uno sviluppo di tipo responsive porta ad analizzare le esigenze di ogni tipologia

di pagina e caso d’uso e adattare il sito secondo quanto individuato: grazie ai tag condizionali di

WordPress (che si basano sul tipo di contenuto della pagina), è possibile caricare le librerie

JavaScript solo quando necessario.

Le librerie usate dal plugin PB Responsive Images, per esempio, devono essere caricate

soltanto nelle tipologie di pagina che contengono immagini; quelle relative alla paginazione in

JavaScript solo negli archivi; quelle relative alle gallerie di immagini solo in questo tipo di

articoli (che può essere differenziato con l’uso dei formati per i post, si veda il capitolo 5 per

ulteriore dettagli). In questo modo, anche l’uso di JavaScript diventa responsive e permette di

migliorare notevolmente le prestazioni.

Usando altre tecniche più tradizionali di compressione (header Expires, compressione gzip,

cache del browser, unificazione dei file CSS e JavaScript) è possibile ottenere pagine molto

leggere e veloci.

Il prototipo finale, grazie a questi accorgimenti, ha un punteggio superiore al 90% (A) su

YSlow e PageSpeed (si veda il capitolo 4 per una panoramica sul funzionamento di questi

strumenti): l’homepage effettua 14 richieste HTTP, pesa 280 KB ed è caricata in meno di due

secondi.

129

Conclusioni

Obiettivo della tesi, attraverso l’analisi di alcuni casi di studio e la realizzazione di un prototipo,

era studiare lo stato dell’arte del responsive web design in ambito non profit.

I pattern individuati sono utili per tracciare alcune possibili soluzioni e linee guida per gli

aspetti principali di un sito responsive (la navigazione, il layout), ma evidenziano anche gli

attuali limiti del responsive web design, causati dal distacco tra esigenze di sviluppo e strumenti

disponibili.

La progettazione e lo sviluppo del prototipo hanno fornito un possibile modello di lavoro per

la realizzazione di un sito responsive. Tale modello è parziale e perfettibile, soprattutto se

l’obiettivo non è realizzare un prototipo, ma un sito in cui siano coinvolte numerose entità con

compiti diversi e distinti: in questo caso la metodologia di lavoro andrebbe rivista, ampliata e

approfondita, per meglio affrontare i problemi legati alla gestione di un progetto complesso.

Un aspetto che meriterebbe un successivo approfondimento è l’impatto del responsive web

design sull’esperienza utente e l’interazione uomo-macchina, con particolare riguardo per le

esigenze dei siti non profit: attraverso test di usabilità da condursi durante le diverse fasi di

progettazione e sviluppo, si potrebbe valutare il grado di efficacia dell’esperienza creata o delle

scelte effettuate (il tipo di navigazione, il tipo di layout, l’organizzazione dei contenuti) e

misurare i risultati ottenuti rispetto agli obiettivi iniziali (quanti utenti portano a termine le

donazioni o acquistano prodotti? Quanti riescono a trovare le informazioni cercate?).

130

Tra i più importanti problemi ancora aperti, che influenzeranno i futuri sviluppi del responsive

web design:

• Le immagini responsive: qualsiasi soluzione attuale non può considerarsi definitiva o

completa, perché è necessaria una soluzione integrata nella specifica di HTML5 che

soddisfi i creatori di contenuti, gli operatori industriali e, ovviamente, gli utenti finali. I

contenuti multimediali sono tra i più importanti in un sito non profit e, tuttavia, sono

quelli che influiscono maggiormente sulle prestazioni: un sito responsive dovrebbe

essere per definizione veloce.

• La gerarchia del contenuto: le griglie fluide sono uno strumento utile e per ora valido,

ma non sono sufficienti a una manipolazione completa del contenuto che può arrivare

solo grazie a funzioni create per questo scopo, da introdurre nelle future specifiche di

CSS e HTML.

• Le API: è auspicabile l’arrivo di CMS di nuova generazione che introducano API per il

contenuto, in modo da permettere una manipolazione semantica, flessibile e completa

delle pagine. Le stesse considerazioni possono essere estese alle API di terze parti che,

in futuro, dovranno fornire un controllo maggiore agli sviluppatori, permettendo una

completa separazione e personalizzazione di contenuti e presentazione.

In conclusione, è comunque possibile tracciare alcune prime linee guida da adottare per la

creazione di un sito responsive in ambito non profit:

• Flessibilità nella progettazione e nello sviluppo; lo sviluppo nel browser aiuta a

inquadrare da subito i problemi di un sito responsive.

• Processo di sviluppo agile.

• Approccio agnostico nei confronti dei singoli dispositivi.

• Adesione alla struttura tradizionale di un sito istituzionale non profit (semplice e

facilmente adattabile), semplificando dove necessario.

131

• Unità di misura proporzionali all’interno del CSS.

• Uso di framework per accelerare la realizzazione di prototipi e wireframe in HTML.

• Sperimentazione con le nuove funzionalità di HTML5, particolarmente utili per alcune

tipologie di contenuto di un sito non profit.

132

Appendice A

Elenco dei siti responsive di organizzazioni non profit analizzati:

• African Wildlife Foundation (http://www.awf.org/)

• AIDS.gov (http://www.aids.gov/)

• AmeriCares (http://www.americares.org/)

• ANERA (http://www.anera.org/)

• Area Onlus (http://www.areato.org/)

• Arthritis Foundation (http://www.arthritis.org/)

• Bill & Melinda Gates Foundation (http://www.gatesfoundation.org/)

• Boot Campaign (http://www.bootcampaign.com/)

• CIFA Onlus (http://www.cifaong.it/)

• CIPSI (http://cipsi.it/)

• Citizens Against Government Waste (http://cagw.org/)

• Creative Commons (http://creativecommons.org/)

• Fairtrade Italia (http://www.fairtradeitalia.it/)

• Future 500 (http://www.future500.org/)

• Global Found for Women (http://www.globalfundforwomen.org/)

• JDRF (http://jdrf.org)

• Malaria No More (http://www.malarianomore.org/)

• Mercy Corps (http://www.mercycorps.org/)

• One (http://www.one.org/us/)

• Organizing for Action (http://www.barackobama.com/)

• Partners in Health (http://www.pih.org/)

• Samaritan’s Purse (http://www.samaritanspurse.org/)

• St. Paul’s Hospital Foundation (http://www.helpstpauls.com/)

133

• Teach for America (http://www.teachforamerica.org/)

• Unicef Svezia (http://unicef.se/)

• Water.org (http://water.org/)

• World Vision International (http://www.wvi.org/)

• WWF (http://worldwildlife.org/)

134

Appendice B

Figura B.1: l’homepage del prototipo, visualizzata su un pc desktop.

135

Figura B.2: l’homepage del prototipo, visualizzata in una viewport larga circa 900 pixel.

136

Figura B.3: l’homepage del prototipo, visualizzata in una viewport larga circa 600 pixel (a sinistra) e in una

viewport larga circa 500 pixel (a destra).

137

Figura B.4: il comportamento del menu di navigazione del prototipo al variare della viewport.

138

Figura B.5: la pagina delle donazioni,visualizzata su un pc desktop.

139

Figura B.6: la pagina delle donazioni, visualizzata in una viewport larga circa 500 pixel.

140

Figura B.7: la pagina degli acquisti solidali, visualizzata su un pc desktop.

141

Figura B.8: la pagina degli acquisti solidali, visualizzata in una viewport larga circa 680 pixel (a sinitra) e in una

viewport larga circa 500 pixel (a destra).

142

Appendice C

Le funzioni di geolocalizzazione in HTML5:

<script type="text/javascript"> // Controllo se il browser supporta la geolocation if (navigator.geolocation) { navigator.geolocation.getCurrentPosition(print_success, show_error); } else { suggest_form(); } // Stampa la posizione dell'utente function print_success(position) { var latitude = position.coords.latitude; var longitude = position.coords.longitude; $("#message").html("Le tue coordinate: "+latitude+", "+longitude+"."); } // Gestione degli errori function suggest_form() { $("#message").html("Impossibile trovare la tua posizione."); } function show_error(error) { switch(error.code) { case error.PERMISSION_DENIED: $("#message").html("User denied the request for Geolocation.") break; case error.POSITION_UNAVAILABLE: $("#message").html("Location information is unavailable.") break; case error.TIMEOUT: $("#message").html("The request to get user location timed out.") break; case error.UNKNOWN_ERROR: $("#message").html("An unknown error occurred.") break; } } </script>

143

La sintassi di PB Responsive Images:

<!-- viewport larga meno di 450 pixel, immagine larga 300 pixel --> <span data-src=”http://sito.com/slir/w300/img.jpg” data-media=”all”></span> <!-- viewport larga 450+ pixel, immagine larga 450 pixel --> <span data-src=”http://sito.com/slir/w450/img.jpg” data-media=”(min-width:450px”></span> <!-- immagine nel tag noscript, larga 450 pixel --> <noscript> <img src=”http://sito.com/slir/w450/img.jpg” width=”450” height=”300”> </noscript> <!-- viewport larga 650+pixel, immagine larga 700 pixel --> <span data-src=”http://sito.com/slir/w700/img.jpg” data-media=”(min-width:650px”></span> <!—immagine di fallback, larga 300 pixel --> <img src=”http://sito.com/slir/w300/img.jpg”>

144

Appendice D

Elenco delle risorse usate, non citate altrove:

• Browser Stack (http://www.browserstack.com), un emulatore di browser.

• Firesizer (https://addons.mozilla.org/en-US/firefox/addon/firesizer/), un’estensione

di Firefox per visualizzare e modificare le misure della viewport.

• Paparazzi (http://derailer.org/paparazzi/), un’applicazione per catturare schermate di

pagine web.

• Responsive Design Testing di Matt Kersley (http://mattkersley.com/responsive/),

uno strumento per visualizzare il comportamento di un sito in viewport di dimensioni

diverse.

• Responsive Inspector di Piotr Walczyszyn (http://tinyurl.com/responsiveinspector),

un’estensione di Google Chrome per visualizzare i breakpoint usati nelle media queries

di un sito.

• Responsive Navigation di Erick Arbe (http://responsivenavigation.net/), una raccolta

di esempi di navigazioni responsive.

• Responsive Resources di Brad Frost (http://bradfrost.github.io/this-is-

responsive/resources.html), una raccolta di articoli e link sul responsive web design.

• Screengrab (https://addons.mozilla.org/en-US/firefox/addon/screengrab/),

un’estensione di Firefox per catturare schermate di pagine web.

• Snoopy di Mark Perkins (http://snoopy.allmarkedup.com/), un bookmarklet per

visualizzare il codice sorgente di una pagina web su dispositivi mobile.

145

Bibliografia

Audiweb. «Audiweb pubblica i risultati della Ricerca di Base sulla diffusione dell'online in Italia

e i dati di audience del mese di dicembre 2012.» Audiweb.it. 29 gennaio 2013.

http://www.audiweb.it/cms/view.php?id=6&cms_pk=277 (consultato il giorno 28 aprile

2013).

Allsopp, John. «A Dao of Web Design.» A List Apart. 7 aprile 2000.

http://alistapart.com/article/dao (consultato il giorno 23 aprile 2013).

Anonimo. List of UNICEF National Committees. 12 settembre 2012.

http://en.wikipedia.org/wiki/List_of_UNICEF_National_Committees (consultato il

giorno 18 maggio 2013).

Apple. «Safari Web Content Guide: Configuring the Viewport.» Safari Developer Library. 19

settembre 2012.

https://developer.apple.com/library/safari/#documentation/AppleApplications/Referen

ce/SafariWebContent/UsingtheViewport/UsingtheViewport.html (consultato il giorno 7

maggio 2013).

Arthur, Charles. «Tablets will challenge PC sales by 2017 as Android passes iPad, says IDC.»

The Guardian. 13 marzo 2013.

http://www.guardian.co.uk/technology/2013/mar/13/tablets-challenge-pc-sales-2017-

android/ (consultato il giorno 29 marzo 2013).

Beck, Kent, Mike Beedle, Arie van Bennekum, e Alistar Cockburn. Manifesto for Agile Software

Development. 2001. http://agilemanifesto.org/ (consultato il giorno 6 giugno 2013).

Berjon, R., T. Leithead, S. Pfeiffer, E. O'Connor, e E. Doyle Navara. «HTML5.» W3C. 29

marzo 2012. http://www.w3.org/TR/2012/WD-html5-20120329/ (consultato il giorno

23 aprile 2013).

Bidelman, Eric. «A Beginner's Guide to Using the Application Cache.» HTML5 Rocks. 18

giugno 2010. http://www.html5rocks.com/en/tutorials/appcache/beginner/ (consultato

il giorno 9 maggio 2013).

146

Boulton, Mark. A Practical Guide to Designing for the Web. Penarth: Mark Boulton Design Ltd.,

2009.

—. «Responsive Summit: Workflow.» Mark Boulton. 24 febbraio 2012.

http://www.markboulton.co.uk/journal/responsive-summit-workflow (consultato il

giorno 6 giugno 2013).

Cáceres, Marco, Mat Marquis, e Yoav Weiss. «Use Cases and Requirements for Standardizing

Responsive Images.» Responsive Images Community Group. 15 marzo 2013.

http://usecases.responsiveimages.org/ (consultato il giorno 7 giugno 2013).

Champeon, Steven, e Nick Finck. «Inclusive Web Design for the Future.» hesketh.com. 11 marzo

2003. http://www.hesketh.com/thought-leadership/our-publications/inclusive-web-

design-future (consultato il giorno 11 giugno 2013).

Clark, Josh. «Nielsen is wrong on mobile.» .net magazine. 12 aprile 2012.

http://www.netmagazine.com/opinions/nielsen-wrong-mobile (consultato il giorno 16

aprile 2013).

Clark, Richard. « HTML5 forms input types .» HTML5 Doctor. 28 febbraio 2013.

http://html5doctor.com/html5-forms-input-types (consultato il giorno 7 giugno 2013).

Combrinck, Tanya. «Nielsen responds to mobile criticism.» .net magazine. 12 aprile 2012.

http://www.netmagazine.com/interviews/nielsen-responds-mobile-criticism (consultato il

giorno 16 aprile 2013).

De Biase, Luca. «La trasformazione del pc.» Il Sole 24 Ore. 11 aprile 2013.

http://lucadebiase.nova100.ilsole24ore.com/2013/04/la-trasformazione-del-pc.html

(consultato il giorno 19 aprile 2013).

Dugonjić, Marko. Responsive Typography Demo.

http://webdesign.maratz.com/lab/responsivetypography (consultato il giorno 29 aprile

2013).

Far, Pierre. «Recommendations for building smartphone-optimized websites.» Official Google

Webmaster Central Blog. 6 giugno 2012.

http://googlewebmastercentral.blogspot.se/2012/06/recommendations-for-building-

smartphone.html (consultato il giorno 23 aprile 2013).

147

Foster, Simon. «The Responsive Designer.» Simon Foster. 16 ottobre 2012.

http://simonfosterdesign.com/blog/web-design/the-responsive-designer/ (consultato il

giorno 3 aprile 2013).

Frost, Brad. «Perfomance As Design.» brad frost web. 28 gennaio 2013.

http://bradfrostweb.com/blog/post/performance-as-design/ (consultato il giorno 8

giugno 2013).

Gustafson, Aaron. Adaptive Web Design. Chattanooga, : Easy Readers , 2011.

Gobry, Pascal-Emmanuel. «Tablet Sales Will Blow Past PC Sales To Nearly 500 Million Units

A Year By 2015.» Business Insider. 14 febbraio 2012.

http://articles.businessinsider.com/2012-02-14/tech/31057828_1_tablet-sales-post-pc-

era-lower-prices/ (consultato il giorno 29 marzo 2013).

Google. Optimize browser rendering. 28 marzo 2012.

https://developers.google.com/speed/docs/best-

practices/rendering#SpecifyImageDimensions (consultato il giorno 19 maggio 2013).

Grigsby, Jason. «8 Guidelines and 1 Rule for Responsive Images.» Cloud Four Blog. 2 aprile

2013. http://blog.cloudfour.com/8-guidelines-and-1-rule-for-responsive-images/

(consultato il giorno 7 giugno 2013).

—. «CSS Media Query for Mobile is Fool’s Gold.» Cloud Four Blog. 3 agosto 2010.

http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/ (consultato il

giorno 23 aprile 2013).

—. «New to Mobile? Welcome to the One Web Debate.» Cloud Four Blog. 11 agosto 2010.

http://blog.cloudfour.com/new-to-mobile-welcome-to-the-one-web-debate/ (consultato

il giorno 29 marzo 2013).

—. Media Queries in SVG images. 3 aprile 2013. http://blog.cloudfour.com/media-queries-in-

svg-images/ (consultato il giorno 23 aprile 2013).

—. «Responsive IMGs Part 2 — In-depth Look at Techniques.» Cloud Four Blog. 30 settembre

2011. http://blog.cloudfour.com/responsive-imgs-part-2/ (consultato il giorno 7 giugno

2013).

Istat. «8° Censimento dell'Industria e dei Servizi.» Istat, Roma, 2005.

148

Hay, Stephen. Responsive Design Workflow. New Riders, 2013.

—. Responsive Design Workflow. New Riders, 2013.

—. «Responsive Design Workflow: Mobilism 2012.» slideshare. 11 maggio 2012.

http://www.slideshare.net/stephenhay/mobilism2012 (consultato il giorno 6 giugno

2013).

HTTP Archive - Interesting Stats. 1 maggio 2013.

http://httparchive.org/interesting.php?a=All&l=May%201%202013 (consultato il giorno

15 maggio 2013).

Kadlec, Tim. Implementing Responsive Design. Berkeley: New Riders, 2013.

Keith, Jeremy. HTML5 for Web Designers. New York: A Book Aparta, 2010.

Lynch, Kevin. «Mobile First! at Adobe.» YouTube. 27 ottobre 2010.

http://www.youtube.com/watch?v=ddrqwdWYdz4 (consultato il giorno 23 aprile 2013).

Lawson, Bruce. «Why We Shouldn’t Make Separate Mobile Websites.» Smashing Magazine. 19

aprile 2012. http://mobile.smashingmagazine.com/2012/04/19/why-we-shouldnt-make-

separate-mobile-websites/ (consultato il giorno 16 aprile 2013).

—. «HTML5 adaptive images: end of round one .» HTML5 Doctor. 16 maggio 2012.

http://html5doctor.com/html5-adaptive-images-end-of-round-one/ (consultato il giorno

7 giugno 2013).

—. «Responsive images – interim report.» 22 maggio 2013.

http://www.brucelawson.co.uk/2013/responsive-images-intrerim-report/ (consultato il

giorno 7 giugno 2013).

Lawson, Matt. «Picking A Mobile Support Strategy For Your Website.» Smashing Magazine. 11

luglio 2011. http://smashingmagazine.com/2011/07/11/picking-a-mobile-support-

strategy-for-your-website/ (consultato il giorno 29 marzo 2013).

Nielsen, Jakob. «Mobile vs. Full Site.» Nielsen Norman Group. 10 aprile 2012.

http://www.nngroup.com/articles/mobile-site-vs-full-site/ (consultato il giorno 16 aprile

2013).

149

Maier, Andrew. «Everywhere All at Once: An Interview with Sara Wachter-Boettcher.» UX

Booth. 12 marzo 2013. http://www.uxbooth.com/articles/everywhere-all-at-once/

(consultato il giorno 16 aprile 2013).

Marcotte, Ethan. «Fluid Grids.» A List Apart, n. 279 (2009).

Marcotte, Ethan. «Responsive Web Design.» A List Apart, n. 306 (2010).

—. Responsive Web Design. New York: A Book Apart, 2011.

—. «Toffee-nosed.» Unstoppable Robot Ninja. 24 marzo 2011.

http://unstoppablerobotninja.com/entry/toffee-nosed/ (consultato il giorno 23 aprile

2013).

Mark, Jason. «How WordPress Took The CMS Crown From Drupal And Joomla.» Smashing

Magazine. 29 novembre 2011. http://wp.smashingmagazine.com/2011/11/29/wordpress-

cms-crown-drupal-joomla/ (consultato il giorno 29 marzo 2013).

—. «Nielsen vs Clark - they're both wrong.» .net magazine. 30 aprile 2012.

http://www.netmagazine.com/opinions/nielsen-vs-clark-theyre-both-wrong (consultato il

giorno 16 aprile 2013).

Marquis, Mat. «Immagini responsive: perché hanno quasi funzionato e cosa ci serve.» Italian A

List Apart. 31 gennaio 2012. http://www.italianalistapart.com/articoli/58-numero-44-14-

febbraio-2012/234-immagini-responsive-quasi-funzionato-cosa-ci-serve (consultato il

giorno 7 giugno 2013).

Marquis, Mat. «Responsive Images and Web Standards at the Turning Point.» A List Apart, n.

351 (maggio 2012).

Marquis, Mat. «Responsive Images: How they Almost Worked and What We Need.» A List

Apart, n. 343 (gennaio 2012).

Marquis, Mat, e Adrian Bateman. «HTML Responsive Images Extension.» W3C.

https://dvcs.w3.org/hg/html-proposals/raw-file/9443de7ff65f/responsive-

images/responsive-images.html (consultato il giorno 17 aprile 2013).

McCollin, Rachel. 14 giugno 2012.

http://mobile.smashingmagazine.com/2012/06/14/responsive-images-with-wordress-

featured-images/ (consultato il giorno 7 giugno 2013).

150

McGrane, Karen. Content Strategy For Mobile. New York: A Book Apart, 2012.

Menn, Joseph. «Smartphone shipments surpass PCs.» Financial Times. 8 febbraio 2011.

http://www.ft.com/intl/cms/s/2/d96e3bd8-33ca-11e0-b1ed-00144feabdc0.html

(consultato il giorno 29 marzo 2013).

Mobilism. Coverage - Mobilism 2012. 2012. http://mobilism.nl/2012/coverage (consultato il

giorno 6 giugno 2013).

mobiThinkingA. «Global mobile statistics 2013 Part A: Mobile subscribers; handset market

share; mobile operators.» mobiThinking. 1 marzo 2013. http://mobithinking.com/mobile-

marketing-tools/latest-mobile-stats/a/ (consultato il giorno 29 marzo 2013).

mobiThinkingB. «Global mobile statistics 2012 Part B: Mobile Web; mobile broadband

penetration; 3G/4G subscribers and networks.» mobiThinking. 1 marzo 2013.

http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats/b#mobile-only

(consultato il giorno 15 aprile 2013).

Pilgrim, Mark. «Geolocation.» Dive Into HTML5. http://diveintohtml5.info/geolocation.html

(consultato il giorno 8 giugno 2013).

Polillo, Roberto. Plasmare il web. Milano: Apogeo, 2006.

Popescu, Andrei. «Geolocation API Specification.» W3C. 10 maggio 2012.

http://www.w3.org/TR/geolocation-API/ (consultato il giorno 8 giugno 2013).

Rabin, Jo, e Charles McCathieNevile. «Mobile Web Best Practices 1.0.» W3C. 29 luglio 2008.

http://www.w3.org/TR/mobile-bp/#OneWeb (consultato il giorno 15 aprile 2013).

Ramsden, Jim. «No More Mobile.» Jim Ramsden. 10 febbraio 2013.

http://jimramsden.com/notes/no-more-mobile (consultato il giorno 15 aprile 2013).

Reichenstein, Oliver. Bringing Responsiveness to Apps. 5 novembre 2012.

http://ia.net/blog/bringing-responsiveness-the-app-world/ (consultato il giorno 26 aprile

2013).

Rivoal, Florian. «Media Queries.» W3C. 19 giugno 2012. http://www.w3.org/TR/2012/REC-

css3-mediaqueries-20120619/ (consultato il giorno 23 aprile 2013).

Schmidt, Eric. «Eric Schmidt on Mobile First.» YouTube. 21 febbraio 2011.

http://www.youtube.com/watch?v=RUiSckZTUr8 (consultato il giorno 23 aprile 2013).

151

Shakespeare, James. «The dire state of WordPress.» James Shakespeare. 19 marzo 2013.

http://jshakespeare.com/the-dire-state-of-wordpress/ (consultato il giorno 16 aprile

2013).

Smith, Aaron. Cell Internet Use 2012. Sondaggio, Pew Research Center’s Internet & American

Life Project, Pew Research Center, Washington: Pew Research Center, 2012.

Smith, Aaron. Smartphone Adoption and Usage . Sondaggio, Pew Internet, Pew Research Center,

Washington: Pew Research Center , 2011.

Stocks, Elliot Jay. «Responsive web design: the war has not yet been won.» 1 marzo 2013.

http://elliotjaystocks.com/blog/responsive-web-design-the-war-has-not-yet-been-won/

(consultato il giorno 23 aprile 2013).

Storm Taylor, Ian. Media Queries are a Hack. 2 aprile 2013. http://ianstormtaylor.com/media-

queries-are-a-hack/ (consultato il giorno 23 aprile 2013).

Wachter-Boettcher, Sara. Content Everywhere. New York: Rosenfeld Media, 2012.

Walk, Joost de. «The anatomy of a WordPress theme.» Yoast. 10 gennaio 2011.

ttp://yoast.com/wordpress-theme-anatomy/ (consultato il giorno 29 marzo 2013).

Walter, Stéphanie. «The State Of Responsive Web Design.» Smashing Magazine. 29 maggio

2013. http://mobile.smashingmagazine.com/2013/05/29/the-state-of-responsive-web-

design/ (consultato il giorno 8 giugno 2013).

Wilcox, Matt. «Responsive images: what's the problem, and how do we fix it.» Dev.Opera. 13

giugno 2012. http://dev.opera.com/articles/view/responsive-images-problem/

(consultato il giorno 17 aprile 2013).

Wingfield, Nick. «As New iPad Debut Nears, Some See Decline of PCs.» New York Times. 5

marzo 2012. http://www.nytimes.com/2012/03/06/technology/as-new-ipad-debut-

nears-some-see-decline-of-pcs.html (consultato il giorno 29 marzo 2013).

Wolski, Marek. «There Is No Mobile Internet!» Smashing Magazine. 25 febbraio 2013.

http://www.smashingmagazine.com/2013/02/25/there-is-no-mobile-Internet/

(consultato il giorno 2 aprile 2013).

WordPress Codex. «History.» WordPress Codex. http://codex.wordpress.org/History

(consultato il giorno 16 aprile 2013).

152

—. «Theme Frameworks.» WordPress Codex. http://codex.wordpress.org/Theme_Frameworks

(consultato il giorno 6 giugno 2013).

WordPress Philosophy. «WordPress Philosophy.» WordPress.

http://wordpress.org/about/philosophy/ (consultato il giorno 16 aprile 2013).

Wroblewski, Luke. «Data Monday: Impact of Responsive Designs.» LukeW. 25 febbraio 2013.

http://www.lukew.com/ff/entry.asp?1691 (consultato il giorno 23 aprile 2013).

—. «Multi-Device Layout Patterns.» LukeW. 14 marzo 2012.

http://www.lukew.com/ff/entry.asp?1514 (consultato il giorno 6 giugno 2013).

—. Mobile First. New York: A Book Apart, 2011.

—. «Responsive Navigation: Optimizing for Touch Across Devices.» LukeW. 2 novembre

2012. http://www.lukew.com/ff/entry.asp?1649 (consultato il giorno 6 giugno 2013).

Young, James. «Non responsive.» welcomebrand. 23 febbraio 2013.

http://www.welcomebrand.co.uk/thoughts/non-responsive/ (consultato il giorno 23

aprile 2013).

YSlow. YSlow FAQ. http://yslow.org/faq/ (consultato il giorno 13 maggio 2013).