Aspettative e ritardi per le applicazioni di HTML5

Ci avviciniamo alla fine dell'anno 2012, che molti avevano previsto come l'anno in cui l'HTML5 avrebbe preso il sopravvento sia sul Web che sulle interfacce mobile. Guardandoci attorno questo non sembra essere successo. Persino un colosso come Facebook sta usando il mancato successo di HTML5 come capro espiatorio per giustificare la non completa affermazione sul mercato mobile. In realta non e corretto parlare di mancato successo in riferimento ad HTML5.

Ci avviciniamo alla fine dell’anno 2012, che molti avevano previsto come l’anno in cui l’HTML5 avrebbe preso il sopravvento sia sul Web che sulle interfacce mobile. Guardandoci attorno questo non sembra essere successo. Persino un colosso come Facebook sta usando il mancato successo di HTML5 come capro espiatorio per giustificare la non completa affermazione sul mercato mobile. In realtà non è corretto parlare di mancato successo in riferimento ad HTML5. Con questo articolo cercheremo di chiarire quali erano le aspettative nei confronti di HTML5, discutendo se tali aspettative fossero giustificate o meno. Vedremo anche quali sono i ritardi dovuti alla (supposta) mancata affermazione di HTML5, e per quali motivi essi hanno impattato le strategie commerciali di molte aziende.

I ritardi che sono stati attribuiti ad HTML5 sono principalmente riassumibili in tre categorie:

  1. Difficoltà dello sviluppo cross-platform, inteso come metodologia di sviluppo compatibile per le diverse interfacce (PC, laptop, desktop, mobile ecc.)
  2. Ritardo nel supporto e rilascio delle applicazioni 3D implementabili nell’ambito del paradigma HTML5
  3. Abitudini e consuetudini degli utenti, specialmente per quanto riguarda il settore mobile

Discuteremo questi tre punti più in dettaglio nelle prossime pagine. Prima di approfondirli vogliamo spezzare una lancia a favore di HTML5. Come visto nell’articolo introduttivo al paradigma di lavoro di HTML5, non sono state fatte promesse esplicite riguardo ai tre punti sopra elencati. Le novità introdotte da HTML5 sono tecniche, mentre le critiche illustrate nell’elenco qui sopra rappresentano aspettative e interpretazioni strategiche dedotte dai diversi stake-holders. In altre parole il disappunto nei confronti del presunto insuccesso di HTML5 sembra dovuto alla polvere gettata negli occhi da chi si è fatto prendere un po’ troppo dall’entusiasmo.

Ricordiamo inoltre che non è stata ancora fissata una data ufficiale per il rilascio di HTML5. Le previsioni più ottimiste parlano del 2014. Dal punto di vista tecnico è bene essere lungimiranti e iniziare a implementare già adesso molte funzionalità del nuovo modo di lavorare, in primis quelle che riguardano le nuove tag semantiche. Ma dal punto di vista commerciale e strategico bisogna stare attenti: se vogliamo essere lungimiranti e scommettere su una nuova tecnologia, la responsabilità è solo nostra. Chi ha investito tutto su HTML5 dovrebbe essere ben consapevole di averlo fatto giocando nei margini del rischio d’impresa. Se la tecnologia non si è ancora affermata come previsto la “colpa” non va attribuita alle capacità tecniche di HTML5, ma piuttosto ad interpretazioni sbagliate che hanno “pompato” le aspettative.

Nelle prossime pagine giustificheremo meglio queste affermazioni. Per capire cosa è andato storto, e perché HTML5 rimane comunque una prospettiva valida su cui scommettere, dovremo entrare nei dettagli, confrontando le aspettative con le promesse.

Le promesse di HTML5

Le promesse di HTML5

Vediamo in breve quali sono le novità promesse dal nuovo paradigma HTML5, limitandoci ad enumerare i punti salienti della nuova tecnologia. Possiamo dividere le novità introdotte da HTML5 in due grosse categorie: le novità che riguardano la stesura del codice markup, ovvero le tag che appaiono nelle pagine Web, e le novità che riguardano l’architettura del software, trasparenti agli utilizzatori finali. Nel nostro caso ci interessa soltanto la prima categoria, perché le novità architetturali riguardano principalmente le modalità di trasmissione via HTTP e possono essere trascurate quando parliamo di compatibilità delle interfacce.

Le novità relative al codice markup possono essere divise in quattro sottocategorie:
 

  • Nuovi elementi semantici: questi elementi riguardano principalmente la manutenzione del codice, perché permettono di sostituire molti dei vecchi div, rendendoli più facilmente riconoscibili dallo sviluppatore. Ciò impatterà anche il lato client, ovvero lo user agent dell’utilizzatore, perché permetterà di riconoscere facilmente le diverse sezioni di una pagina.
  • Nuovi elementi per le form: le form HTML verranno arricchite con nuovi campi di input che permetteranno di migliorare l’usabilità del software e semplificare il processo di validazione.
  • Elementi multimediali: le nuove tag audio e video sostituiranno i vari plugin multimediali, come ad esempio Flash.
  • Canvas: tramite i canvas sarà possibile realizzare grafica interattiva semplicemente usando JavaScript, senza installare alcun plugin.

Le novità appena elencate porteranno ad una semplificazione dello sviluppo cross-platform, inteso come compatibilità tra diversi sistemi operativi, browser e dispositivi mobile. Occorre però distinguere tra le specifiche HTML5 e l’implementazione delle stesse specifiche nei vari user agent. Ad esempio, usando la nuova tag nav lo user agent potrà identificare immediatamente qual è il menù di navigazione di una pagina. Questo è un merito indiscutibile di HTML5. Quando si passa alla pratica occorre tenere conto del dispositivo specifico. Ad esempio, dopo aver capito che una certa sezione contiene i pulsanti di navigazione, dobbiamo chiederci se renderizzare tali pulsanti per uno schermo tradizionale o per la view-port di un mobile. In alcuni casi dobbiamo scegliere tra visualizzare una tastiera o un tastierino. Scelte di questo tipo riguardano l’implementazione tecnica del software, sia da parte di chi sviluppa l’applicazione, sia da parte dei produttori di browser. Chi ha interpretato l’avvento della nuova tag nav come la panacea di tutti i mali cross-platform è caduto in un errore di interpretazione: una cosa è riconoscere la sezione di navigazione, un’altra cosa è progettare un’interfaccia grafica che risulti usabile dall’utente.

Riflessioni di questo tipo si possono fare per tutte le novità introdotte da HTML5. Sia che si parli di canvas o video, la delusione di cui abbiamo parlato all’inizio dell’articolo non è dovuta alle potenzialità di HTML5 ma alle interpretazioni dello strumento da parte dei meno tecnici. È risaputo che chi lavora nei “piani alti”, occupandosi di questioni commerciali o strategiche, deve giustamente guardare lontano senza scendere nei dettagli. Scommettere troppo su HTML5, come se dovesse risolvere tutti i problemi della compatibilità delle pagine Web, assomiglia un po’ all’illusione delle “.com” avvenuta all’inizio del nuovo millennio, quando si pensava che l’e-commerce avrebbe sostituito il commercio tradizionale nel giro di un paio d’anni. In realtà HTML5 funziona, sta mantenendo le sue promesse, e ci prospetta un futuro migliore. L’importante è non sopravalutarlo.

Le aspettative di HTML5

Le aspettative di HTML5

Dopo aver chiarito che le specifiche HTML5 non hanno mai promesso di risolvere tutti i problemi di compatibilità tra le diverse piattaforme di utilizzo, vediamo quali erano le aspettative per il 2012 e perché non sono state soddisfatte. Come vedremo, in tutti i casi, la responsabilità non va attribuita ad HTML5 ma piuttosto alle aspettative strategiche di chi ha scommesso sul nuovo paradigma, forse male interpretando le capacità dello strumento.

Sviluppo cross-platform

Dagli esempi di pagina precedente dovrebbe essere chiaro che HTML5 non sarà mai in grado di risolvere tutte le sfide dello sviluppo cross-platform. Al momento, quando dobbiamo progettare un’interfaccia grafica per un sito o un’applicazione, risulta ancora vantaggioso sviluppare interfacce specifiche per i diversi dispositivi. Se pensiamo che un’applicazione verrà usata principalmente su mobile conviene sviluppare l’interfaccia solo per i dispositivi di questo tipo, lavorando sull’interfaccia tradizionale a parte. Anzi: già concentrandosi solo sui dispositivi mobile si devono affrontare numerose sfide di compatibilità tra dispositivi diversi. E’ quindi sbagliato illudersi che HTML5 possa risolvere tutti i problemi di sviluppo cross-platform. Chi ha scommesso su soluzioni di questo tipo ne sta pagando il prezzo: ancora una volta l’errore sta nella interpretazione delle nuove specifiche, dovuta all’eccessivo entusiasmo.

Applicazioni 3D

In questo caso parte della responsabilità riguarda gli aspetti tecnici, perché le tanto attese librerie WebGL, che avrebbero dovuto spalancare le porte alle applicazioni 3D con HTML5, non sono ancora mature. Inoltre, se teniamo conto della velocità di connessione media dei mobile, circa 900 volte più lenta di quella delle postazioni fisse, si capisce che una pagina Web piena dei contenuti necessari per far girare un’applicazione 3D risulta lenta sul mobile. Per questo motivo è ancora vantaggioso, da parte dell’utente, scaricare e installare applicazioni specifiche. Notiamo però che il “fallimento” delle applicazioni 3D va attribuito al ritardo delle librerie WebGL e alla tecnologia di connessione dei dispositivi mobile. Anche in questo caso è quindi scorretto dare la colpa ad HTML5, che non ha nulla a che fare con questi aspetti (al più dipende da essi).

Abitudini degli utenti

Qui la conclusione è addirittura lampante. Se gli utenti del mondo mobile sono abituati a scaricare e installare applicazioni piuttosto che navigare le pagine HTML5 che forniscono lo stesso servizio, la colpa non è in alcun modo attribuibile alla tecnologia, ma unicamente agli aspetti culturali. È ben noto che la mente umana presenta un’inerzia cognitiva, ovvero preferisce tendenzialmente percorrere la strada vecchia piuttosto che provare quella nuova. Attribuire ad HTML5 la responsabilità del mancato cambiamento nelle abitudini degli utenti è un po’ forzato, soprattutto se teniamo conto del fatto che mancano ancora due anni al rilascio delle nuove specifiche.

La conclusione è che dobbiamo aver fiducia nelle promesse di HTML5, senza crearci l’illusione che il nuovo linguaggio markup possa risolvere da solo tutti i problemi della progettazione Web. Il modo migliore di evitare errori di interpretazione è quello di farsi un’idea, almeno a grandi linee, di quelle che sono le novità tecniche promesse dal nuovo paradigma. Piuttosto che farsi un’opinione guardando video pieni di slogan entusiastici a volte è meglio leggere un articolo un po’ più tecnico, senza pretendere di capire tutti i dettagli, ma cercando di cogliere gli aspetti essenziali della nuova tecnologia.