Ospitiamo con piacere un Guest post dal Team di Deejay.it sulla loro esperienza nello sviluppo con HTML5 del progetto Visual Player con cui hanno partecipato e vinto :) la scorsa primavera il primo premio della categoria Design UX del contest Developer Unplugged dedicato appunto ai nuovi Standard Web.
Gianluca Guarini, Marco Viganò e Lorenzo Pace, ci raccontano in questo post l'esperienza e le scelte di implementazione nel progetto. Ancora complimenti al Team di Deejay.it per la realizzazione e per il premio.
Buona lettura !!
La radio da guardare
Un player sì, ma perché visual? Con questo nome volevamo porre l'accento sul fatto che Radio Deejay ha ormai oltrepassato i confini del media radiofonico affacciandosi dapprima sul web con deejay.it e sbarcando poi nel palinsesto televisivo con Deejay TV (canale 9 del digitale terrestre). Con il sito web, Deejay ha acquisito multimedialità avvicinandosi così al concetto di “player” di contenuti, mentre con la televisione ha dato immagine alla propria voce diventando sempre di più una “radio da guardare”, valore trasmesso appunto dall'aggettivo “visual”.
Questa sintesi avviene maggiormente con il programma Deejay chiama Italia che, oltre ad essere ascoltabile attraverso la radio nella sua versione più istituzionale, può essere anche seguito su Deejay TV in versione reality, interamente fruibile nei suoi momenti sia in onda che fuori onda.
Proprio per questo Deejay si conferma come un brand multimediale a 360° e il suo logo roton
do che ben rappresenta questo valore è stato assunto come modulo per il design di tutta l'interfaccia della nostra web app proprio per comunicare anche attraverso le forme lo stesso concetto.
Un player grande... con contenuti piccoli
La sfida del Visual Player era quella di mostrare i medesimi contenuti pubblicati sul sito Deejay.it, proponendo però una UX molto più accattivante che sfruttasse le nuove opportunità offerte dall'emergente HTML5. Per quest'applicazione ci siamo subito orientati verso un'interfaccia fluida in fullscreen, che si adattasse alle varie risoluzioni video, e allo stesso tempo molto essenziale nei suoi elementi, in modo da non prevaricare la fruizione dei contenuti stessi. A nostro svantaggio però il formato dei contenuti a disposizione sembrava precludere la realizzazione di questo tipo di soluzione poiché sia le foto che i video erano stati realizzati con dimensioni ridotte, tali da rispettare la griglia del sito web.
Abbiamo pensato quindi di introdurre un elemento in overlay al player con una retinatura ottenuta utilizzando come background un'immagine di 2 x 2 px trasparente con 1px nero, ripetuta su entrambi gli assi.
In questo modo siamo riusciti ad ingrandire foto e video mantenedo una qualità apparente dell'immagine più che soddisfacente, tenuto conto soprattutto delle dimensioni dei file di partenza: i pixel neri della retinatura introducono discontinuità tra i punti che compongono l'immagine rendendo meno riconoscibili le distorsioni dovute alle varie compressioni di foto e video, ancora più visibili purtroppo a causa del resize a fullscreen. Inoltre la retinatura risulta praticamente impercettibile all'utente, in quanto l'occhio umano è in grado di interpolare i punti mancanti percependo comunque continuità d'immagine: l'effetto finale è sicuramente meno luminoso, ma molto più nitido.
La gestione degli eventi di oggetti multimediali con jQuery
Una volta definiti gli step attraverso i quali i contenuti della nostra app sarebbero stati mostrati la parte più difficile è stata la concatenazione degli eventi multimediali. Infatti nelle specifiche HTML5 sono stati introdotti nuovi eventi javascript che permettono di controllare i flussi video e audio: nel nostro caso ci serviva sapere quando il video o l'audio erano in playing in modo da stoppare gli eventi associati alle sezioni che non erano ancora mostrate o erano nascoste.
A complicare la situazione sicuramente si aggiungeva il problema della gestione degli eventi legati al ridimensionamento della finestra del browser, poiché essendo il 'Visual Player' un'app in full screen, questi ultimi dovevano essere associati esclusivamente agli elementi visualizzati nella sezione corrente, in modo da evitare il sovraccarico della CPU che avrebbe
mandato i browser crash.
Fortunatamente la scelta di jQuery ha semplificato il tutto permettendoci sia di gestire le animazioni che di personalizzare gli eventi.
La nostra soluzione quindi è stata quella di gestire tutto tramite l'hash del browser ed è proprio tramite i parametri passati in questo modo agli script che le sezioni sono navigabili: i contenuti multimediali (eccetto le immagini) vengono inniettati nel DOM solo dopo che l'hash viene letta dagli script riducendo in questo modo i tempi di carimento dell'app sino al 83%.
Altro punto cruciale dell'app è stato quello di mandare in sincrono l'audio con le lyrics, ma in questo caso il plugin jquery.srt (http://v2v.cc/~j/jquery.srt/) ha velocizzato di molto i tempi di sviluppo e con poche modifiche allo script siamo riusciti ad integrarlo nella nostro 'Visual Player'. A posteriori facendo una stima delle tempistiche possiamo tranquillamente ammettere che l'utilizzo di jQuery ha dimezzato i tempi di realizzazione dell'app permettendoci di concentrarci su aspetti dell'interfaccia che generalmente vengono trascurati e infatti questa cosa è stata premiata dalla giuria del 'DEVUNPLUGGED'.
Strategie indolori per superare i problemi cross browser
La filosofia che abbiamo adottato per superare le problematiche del crossbrowsing è stata quella del 'progressive enhancement 'ovvero di garantire
la visualizzazione dei contenuti per i browser moderni aggirando i bachi degli stessi sulle specifiche HTML5 più sperimentali. La sezione dedicata alle lyrics di ciascun singolo artista utilizza un canvas per mostrare degli effetti particellari mentre l'audio e le lyrics sono in play. L'animazione delle particelle sul canvas viene effettuata utilizzando ls nuova API javascript requestAnimationFrame (http://paulirish.com/2011/requestanimationframe-for-smart-animating/) che consente di eseguire un loop su uno script ottenendo prestazioni migliori (60FPS) del metodo setInterval().Purtroppo l'animazione su firefox generava degli errori facendolo crashare a causa di un baco ben noto agli sviluppatori mozilla (http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/10ff69b04b88e06f/c24326fb2c7be624?pli=1), quindi abbiamo dovuto fornire una versione alternativa delle particelle esclusivamente per firefox. Con grande sorpesa abbiamo potuto notare invece che la velocità di IE9 nel rendering sul canvas è davvero impressionante anche se però buoni risultati siamo riusciti ad ottenerli anche con Chrome e Safari.
read full article
MSDN
.
