Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Il Responsive Web Design per le organizzazioni non profit (Tesi di laurea)

2,552 views

Published on

Tesi di laurea in Informatica, Università degli Studi di Milano-Bicocca, AA 2012-2013.

Published in: Technology
  • Be the first to comment

Il Responsive Web Design per le organizzazioni non profit (Tesi di laurea)

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

×