In questo articolo affrontiamo un tema apparentemente minore che sta acquistando sempre più valore ‘industriale’ con l’affermarsi di dispositivi di fruizione dei contenuti sempre più frammentati e diversificati. Nel panorama della produzione di ‘contenuti editoriali’ in senso lato, la visione originaria del web, con la tripartizione attualmente incarnata da HTML5-CSS3-JavaScript, potrebbe rappresentare la soluzione ideale per realizzare applicazioni web indipendenti dalla piattaforma che abbiano le stesse caratteristiche delle app native.
Introduzione: content e “contenuti”
C’è una parola, “contenuto” o “contenuti”, calcata sull’originale inglese content, che oggi un po’ tutti tendiamo utilizzare. Quando parliamo di “contenuti”, ci stiamo chiaramente riferendo a tutti quegli elementi (testi, immagini, video, audio, animazioni, e così via) che fanno parte di un “prodotto editoriale” in senso lato, non costituendone però la piattaforma tecnologica. Il discorso si può semplificare pensando a qualcosa di estremamente tradizionale, come un classico della letteratura: anche per un’opera come “La Commedia” di Dante, possiamo chiaramente differenziare i contenuti (il racconto in versi di un viaggio immaginario nel mondo ultraterreno secondo l’ottica di un uomo di cultura del basso medioevo) dalle tecnologie con cui poi questi contenuti vengono presentati (l’antico volume manoscritto, il libro di carta a stampa tipografica, l’ebook, la riproduzione audio del testo recitato da un attore e così via).
A voler essere precisi, però, il termine “contenuto” usato per indicare appunto immagini, testi, video, etc., si è diffuso nell’adozione comune solo negli ultimi sette o otto anni. Anche solo una decina di anni fa, parlare di contenuti, specie in certi ambiti un po’ più “tradizionalisti” faceva storcere il naso a più di un art director o caporedattore di riviste o case editrici: “contenuto” sembrava un concetto più adatto alla borsa della spesa o alla confezione di alimenti che non al ricco patrimonio di informazioni e dati rappresentato appunto da testi, immagini, audiovisivi e così via. Oggi invece le cose non stanno così: sull’eleganza dei termini content e contenuto si può discutere, ma sull’importanza strategica ed economica di ciò che essi significano tutti concordano.
In questo breve articolo vogliamo fare un po’ il punto di sul modo in cui questi contenuti vengono resi disponibili e fruibili, vengono “recapitati” all’utente, in un momento che dal punto di vista tecnologico vede un fenomeno contraddittorio: aumenta la quantità di contenuti giornalmente fruiti dagli utenti, ma si moltiplicano anche le piattaforme tecnologiche su cui questi contenuti vengono distribuiti.
Di cosa parliamo nell’articolo
Di fatto la crescente importanza dei contenuti nell’economia globale della rete è sotto gli occhi di tutti: che si tratti di un prodotto editoriale tradizionale o delle informazioni strutturate che una qualche azienda intende rendere disponibili, per i più svariati motivi (dalla campagna di marketing alla pubblicazione dei manuali o delle specifiche di un determinato prodotto), testi e immagini rappresentano degli elementi fondamentali da cui non si può prescindere; un esempio dell’importanza delle immagini nella comunicazione in rete ce la dà una infografica di MDG Advertising, intitolata “It’s All About The Images” [1].
Divideremo l’articolo in tre argomenti principali:
- contenuti e web design
- app native vs standard comune
- vantaggi e svantaggi dell’adozione di HTML5
Lo standard comune di cui si parla qui è HTML5 (e quello che gli sta accanto, cioè CSS3 e tecnologie JavaScript). Vedremo perche‘ una azienda che elabora o in qualche modo produce contenuti (quindi non necessariamente una azienda editoriale in senso lato, ma anche una banca, una grande compagnia assicurativa o una amministrazione pubblica) dovrebbe se non altro valutare l’adozione di tali tecnologie, anche se poi esternalizza il lavoro. Per precisare l’ambito che vogliamo trattare, non parleremo di big data, web semantico, data mining e business intelligence, argomenti importanti e comunque legati anche ai contenuti, e di cui a più riprese ci siamo occupati su MokaByte. Quel di cui ci interessa parlare, però, non è la gestione dei dati, quanto il modo in cui i contenuti vengono “somministrati” agli utenti (il termine inglese che spesso viene usato in questo caso è deliver, cioè “consegnare”, “recapitare”).
Contenuti e web design
Cosa c’entra il web design? Be’, già è difficile dire esattamente che cosa sia il web design: la risposta dipende in genere dalla formazione culturale e tecnica (e anche dalla provenienza geografica) di chi la formula. Spieghiamoci meglio: in Italia è molto probabile che a questi termini sia data una connotazione e soprattutto “grafica” e “creativa”, a volte quasi “artistica”; mentre nel mondo anglosassone è la parola design a farla da padrona: e design vuol dire sostanzialmente “progettazione”, “ideazione”.
In ogni caso, anche se 20 anni non sono tanti, sono comunque serviti a far sviluppare una serie di buone pratiche e di approcci sensati alla progettazione delle modalità di fruizione dei contenuti sul web, e a far capire che nel web design si fondono approcci e competenze multiformi, da quelle del progettista a quelle del grafico, da quelle dell’esperto di architettura dell’informazione a quelle che un tempo erano proprie di altri mondi, come la redazione o la direzione editoriali. Una interessante riflessione su questi temi, che dice anche molto altro, la potete leggere in [2], sul blog Tiragraffi.
Una evoluzione “lenta”
Comunque la si metta, è certo che, negli ultimi due o tre anni, molte delle lezioni apprese dalla seconda metà degli anni Novanta fino a poco tempo fa sono state rapidamente superate dagli eventi. Certo, non erano mancate piccole rivoluzioni anche in precedenza: il passaggio dall’impaginazione dei siti “in tabelle” al concetto di tableless, l’affermazione dei siti dinamici che hanno sostituito quelli statici, l’arrivo di schermi di forma e risoluzione diversa (visto con gli occhi di oggi, come è lontano il mondo dei monitor 4:3 a 800 x 600 pixel…), l’avvento di tecnologie per l’animazione come Flash (e tutti i meno giovani ricorderanno la breve ma invadente moda dei siti in Flash con le “palline” ruotanti in cui già cliccare sulla “pallina” giusta rappresentava una vittoria…), la sempre maggiore pervasività dei video, e così via.
Di fatto, però, certi principi fondamentali per “trasmettere” contenuti sul web sono rimasti sostanzialmente stabili e questo per una ragione precisa: la fruizione dei contenuti avveniva sostanzialmente in una sola modalità ossia il computer desktop (che poi fosse una workstation fissa o un notebook cambiava poco) che usava sostanzialmente gli stessi paradigmi, lo stesso hardware e lo stesso software (al di là delle ovvie variabili).
“Leggere il giornale” sul web, ad esempio, significava guardare a schermo il sito web del giornale: e questo lo si faceva “al computer”, che fosse quello dell’ufficio, di casa, di una biblioteca pubblica o altro. E il computer, nel senso di dispositivo desktop, ha chiaramente dei limiti e delle potenzialità che sono sostanzialmente simili nelle varie sue incarnazioni: una volta messi a punto certi meccanismi, essi continuano a valere anche se poi nella realtà dei fatti ci sono delle differenze fra i vari computer.
Buone pratiche invalse nell’uso
Volete qualche esempio? Dove si collocano i menu in una pagina? In genere, in alto. Dove si collocano gli elementi più importanti? In alto a sinistra… e così via. E di queste buone pratiche di architettura dell’informazione ce ne sono moltissime, che proprio le varie discipline del web design hanno contribuito a mettere a punto in tutti questi anni.
A spingere in certe direzioni, comunque, non è stato solo il buon senso e il feedback degli utenti. Ci sono stati anche degli aspetti (in certi casi dei limiti) meramente tecnologici. Qual è la ragione per cui le immagini da distribuire sul web sono ottimizzate a 72 o 96 ppi? Semplice: gli schermi dei computer non hanno risoluzioni superiori tali da giustificare una maggiore definizione, e quindi si può risparmiare sul peso delle immagini, favorendone la velocità di caricamento a parità di banda. Sappiamo tutti che le stesse immagini, se dovessero andare in stampa, verrebbero sgranate perche‘ la stampa ha una definizione molto maggiore.
E la stessa ragione sta alla base della raccomandazione di scrivere testi sul web con caratteri senza grazie (come quello che state leggendo), evitando quando possibile il corsivo. La ragione è che una risoluzione bassa degli schermi favorisce la lettura di font dal disegno lineare, rispetto a font dal disegno più complesso (come i caratteri con grazie o i corsivi).
Chiaramente, con l’arrivo di schermi ad alta risoluzione sia per i dispositivi mobile che per i computer desktop, questi accorgimenti subiranno una revisione. Anzi, in certi casi (immagini HD per certi dispositivi, caratteristiche “tipografiche” implementate in HTML5/CSS3) tale cambiamento è già in atto.
App native verso standard comune
Insomma, in tutti questi anni, pur con cambiamenti anche importanti, avevamo assistito a una evoluzione relativamente lenta del modo di far fruire i contenuti agli utenti: nelle sue varie evoluzioni, il paradigma fondamentale era quello del sito web. Ma il fatto che la domanda posta dai responsabili commerciali dei committenti sia sempre meno spesso “Quanto costa (ri)fare il sito?” e sempre più frequentemente “Quanto costa fare un’app?” deve farci riflettere sul fatto che molte cose sono cambiate.
La frammentazione delle piattaforme: dai siti alle app
La moltiplicazione delle piattaforme tecnologiche (sia desktop che mobile, nelle loro varie declinazioni) va di pari passo con l’affermazione del nuovo paradigma della app nativa (ossia di fatto di un software scritto appositamente per un determinato sistema operativo) che negli ultimi due o tre anni ha preso piede in maniera massiccia. Non si può certo dire che la app nativa abbia soppiantato il sito in generale, ma di certo, sulle piattaforme mobile è così: su un dispositivo mobile (smartphone o tablet, sia esso iOS, Android o altro) piuttosto che usare il browser per controllare le previsioni meteo sul mio sito di riferimento, mi scarico l’app del meteo.
È banale, ma è quello che succede: se proprio vogliamo fare un discorso ad alto livello di astrazione, possiamo dire che un tempo avevamo un “browser orizzontale” che usavamo per fruire di tutti i vari contenuti, mentre ora abbiamo una moltitudine di “browser verticali” (le app) ciascuno dedicato alla fruizione di un determinato e limitato contenuto. Questo cambia ben poco agli utenti: in fondo, i contenuti fruiti sono gli stessi, che siano visti sul sito con il browser o sul tablet tramite app (ma notate bene che il paradigma app si sta affermando sempre di più anche a livello desktop).
Però questo cambia qualcosa a chi tali contenuti li deve distribuire: un tempo si trattava di realizzare un sito che, nonostante alcune incongruenze, era fruibile indistintamente sui diversi browser. Ma oggi devo realizzare un’app per Apple iOS, una per Android, magari una per Blackberry (anche se il sistema della RIM è in netto calo di diffusione) e una per Windows Phone (che resterà probabilmente un sistema operativo minoritario, ma la cui diffusione è in aumento, specie in Asia). E devo tener presenti le varie versioni. E devo considerare le differenze nelle dimensioni e nelle risoluzioni degli schermi. E considerare anche che lo schermo molte volte può ruotare. E devo pensare che probabilmente in futuro i dispositivi (smartphone e tablet) e anche i sistemi operativi aumenteranno ulteriormente. Se intendo lavorare in modo nativo, anche riducendo al minimo i sistemi operativi (cioè solo iOS e Android) devo perlomeno “duplicare” la base di codice che produco e mantengo, e considerare comunque le diverse versioni degli stessi.
La soluzione: responsive and adaptive design
La discussione “teorica” (che poi tanto teorica non è) che gli esperti di web design e usabilità stanno facendo negli ultimi anni (grosso modo dal 2010) è proprio quella sulla reattività e adattabilità dei siti: ottenere prodotti che siano responsive e adaptive [3] che siano cioè in grado di rispondere e adattarsi alle diverse piattaforme su cui saranno fruiti. È un discorso al tempo stesso di design quasi “tipografico” (disegnare delle “griglie” fluide e suddivise in percentuali su cui impaginare i contenuti) e di possibilità tecnologiche: lo standard HTML5/CSS3 consente un uso raffinato del comando CSS media queries, il quale modifica le proprietà degli elementi di una pagina (i contenuti) in base alla risoluzione, alla dimensione e all’orientamento (verticale o orizzontale) del dispositivo, favorendo di fatto una ridistribuzione e una disposizione ottimale dei vari contenuti nella “pagina”. Per comprendere il concetto, provate a visitare il sito [4] del comune di Staffanstorp (Svezia) con diversi dispositivi (smartphone, computer desktop, tablet) e, dove possibile, con diverso orientamento degli stessi, per vedere il modo in cui i contenuti vengono adeguatamente ridistribuiti nella pagina.
Vantaggi e svantaggi dell’adozione delle tecnologie HTML5
Molte ragioni e molti casi di esempio spingono a una progressiva adozione del paradigma dei siti responsive e adaptive per la distribuzione dei contenuti. Tutti i programmatori Java hanno ben presente la promessa iniziale del linguaggio, ben riassunta nello slogan di Sun: “Write once, run everywhere“.
Ecco, l’adozione delle tecnologie HTML5-CSS-JavaScript nell’ambito della produzione “editoriale” in senso lato (cioè la produzione di contenuti) potrebbe tradursi in una sorta “Create once, deliver everywhere” cioè creare contenuti che poi possano essere fruiti dai diversi dispositivi in maniera ottimale, senza dover stare a duplicare il lavoro di codifica e sviluppo, il che, nei workflow aziendali può significare molto in termini di ottimizzazione e risparmio. Framework come Sencha Touch 2, pur con certi limiti, puntano proprio in questa direzione [5], e i miglioramenti apportati da release a release lo rendono un tool da tenere in considerazione.
Questa strategia che tende a privilegiare i siti mobile rispetto alle app native per la distribuzione di contenuti è già adottata da alcuni editori importanti [6], anche per le edizioni americane di Playboy e Rolling Stone [7].
Vantaggi di HTML5 per la distribuzione dei contenuti
Ma vediamo di seguito le ragioni per cui conviene adottare (almeno nel medio termine) proprio questa strategia (siti mobile reattivi e adattabili).
- Create once, deliver everywhere: Come detto, con l’aumento dei dispositivi e delle versioni, sarà più conveniente, in termini di ottimizzazione dei workflow e delle risorse, realizzare prodotti “compatibili” piuttosto che creare un’app nativa per ciascun dispositivo. Il mercato del mobile è in pieno fermento. Anche quei dispositivi “affidabili” con specifiche chiare e rigide non sono comunque “unici”. Si pensi alle difficoltà che anche le varie generazioni di iPod, iPad e iPhone con versioni di iOS e schermi anche molto diversi presentano per gli sviluppatori, per non pensare al gran numero di dispositivi Android spesso molto diversi fra loro per caratteristiche hardware (e implementazione finale del sistema operativo). In tal senso il responsive and adaptive design risulterà migliori in termini costi/benefici rispetto a creare tante app native specifiche per i vari device.
- Meno codice: Avere la stessa base di codice per tutti i propri contenuti, che poi vengano distribuiti nel web desktop, nei siti mobile o anche come ebook è un passo avanti verso l’ottimizzazione dei processi. Il codice da mantenere si riduce, si riducono gli errori e le ridondanze, si riducono i link interrotti o altri errori che possono compromettere la user experience.
- Migliore “ricercabilità” dei contenuti: Dal momento che, con il responsive design, la base di codice HTML5 è la stessa per tutto, è possibile ottimizzare i contenuti per la ricerca sui motori di ricerca, facendo un unico lavoro. Google non ricerca dentro le app, ma può ricercare dentro i siti mobile. Questo potrebbe essere un punto importante da tenere in considerazione, almeno per certi contenuti.
- Esperienze “ricche”: Le nuove caratteristiche di HTML5-CSS3-JavaScript consentono un’esperienza utente ricca, tutt’altro che limitante. Anche con il progressivo abbandono di Flash (che notoriamente non funziona su iOS) si può comunque continuare a realizzare animazioni di tutto rispetto. Adobe stessa afferma che gli standard web sono in grado di svolgere l’80% del lavoro un tempo fatto da Flash [8] e spinge su Edge, un tool per realizzare animazioni e interazioni web sfruttando HTML5, JavaScript e CSS in sostituzione di Flash.
Questi sono solo alcuni dei punti a favore dell’utilizzo di HTML5.
Qualche punto debole
Tutte rose e fiori? Be’ lo sviluppo di siti mobile responsive e adaptive con HTML5 e tecnologie annesse presenta anche qualche limite. Anzitutto va considerata la velocità: ad oggi, la velocità di caricamento dei siti mobile reattivi e adattabili è inferiore alla applicazione nativa. La ragione è presto detta: nelle app native tutto (immagini in primis) è adattato al dispositivo; nei siti mobile responsive and adaptive, le immagini sono quelle alla massima risoluzione/dimensione (adatte ai agli schermi HD) che poi vengono riadattate e ridimensionate per la particolare combinazione di dimensione e orientamento dello schermo. E questo è un passo in più che prende tempo.
Un altro problema, molto importante per chi produce i contenuti, è che sarà necessario aggiornare i loro Content Management Systems affinche‘ supportino HTML5, CSS3 e JavaScript e il conseguente responsive and adaptive design. Questo passaggio da CMS “vecchi” ma oramai assodati e affidabili, a CMS nuovi e HTML5-compliant ha un costo in termini di prezzo e tempi di “adattamento” da parte del personale che li deve impiegare.
Conclusioni
Abbiamo ripercorso brevemente il passaggio di paradigma da sito web ad app nativa, mettendo in luce come forse, grazie ai siti dal design reattivo e adattabileo possibili con le nuove tecnologie HTML5-CSS3-JavaScript, si tornerà, almeno sul lungo periodo, a fare un web mobile, che si adatti “da se'” alla moltitudine di dispositivi mobile che invaderanno il mercato nei prossimi anni. Per chi crea contenuti da far fruire sui dispositivi mobile, resta il dubbio su cosa fare: investire tempo e risorse per realizzare app native, o privilegiare un approccio basato su HTML5 e framework? Al momento attuale le risposte sembrano andare in entrambe le direzioni.
Forse il quadro più sensato ce lo dà il solito Jakob Nielsen, l’inventore del termine “usabilità”, che parla [9] di un lento cambiamento di strategia; Nielsen fotografa la situazione attuale come dominata, ancora almeno per qualche anno, dal paradigma delle app native, ma ritiene che nel lungo termine i mobile sites finiranno per affermarsi, proprio per una ragione di “praticità”: il probabile ulteriore aumento delle piattaforme mobili (intese sia come mobile OS che come dispositivi) finirà per rendere ben poco economico e gestibile produrre “a monte” app native adattate a ciascuna “variante” e faranno preferire la realizzazione di un mobile web che si adatti “a valle” alle caratteristiche dei diversi device. E va detto che, anche se qualche volta si è sbagliato, di solito le previsioni tecnologiche di Nielsen si sono puntualmente avverate: un po’ saccente, ma sempre arguto.
Riferimenti
[1] MDG Advertising, “It’s all about the images”
[2] Ciro Esposito, “Web Design, tra presente, passato e futuro”
[3] Ethan Marcotte, “Responsive Web Design”, A Book Apart, 2011
[4] Un esempio di sito adattabile e reattivo: quello del comune svedese di Staffanstorp
[5] Il framework Sencha Touch 2 per scrivere applicazioni mobile usando HTML5
http://www.sencha.com/products/touch/
[6] Rob O’Regan, “HTML5 trumps native iPad apps for some publishers”, Emedia Vitals, 08/03/2012
http://www.emediavitals.com/content/html5-trumps-native-ipad-apps-some-publishers
[7] Steve Smith, “Playboy, Rolling Stone Archives Go HTML5, Become iPad-Friendly”, MediaPost
[8] Stephen Shankland, “Adobe: Web standards match 80 percent of Flash features”, cnet, 02/07/2012
[9] Jakob Nielsen, “Mobile Sites vs. Apps: The Coming Strategy Shift”, Alertbox, 13/02/2012
http://www.useit.com/alertbox/mobile-sites-apps.html