HTML5 e la geolocalizzazione

Una delle novità introdotte in HTML5 è la GeoLocation, ovvero la possibilità di ottenere dal browser le informazioni sulla posizione geografica dell’utente.

Funzionamento

In breve, come funziona: lo standard (per cui vi rimando alla pagina del W3C)  prevede che il browser possa esporre le coordinate geografiche dell’utente fornitegli dal sistema operativo su cui è installato, qualora quest’ultimo consenta di determinare la posizione geografica mediante antenna GPS o WiFi.

Pertanto, affinché un’applicazione web ottenga la posizione geografica, è necessario che il sistema operativo ed il browser supportino tale funzionalità.

C’è da dire, inoltre, che la richiesta della posizione geografica, da parte dell’applicazione web in questione, è sempre preceduta da una richieste esplicita fatta all’utente pertanto, sulla questione privacy, è l’utente a dover accettare esplicitamente di voler fornire al browser questo dato.

Sul discorso compatibilità dei browser: Safari e Chrome supportano pienamente le API per questa funzionalità (aggiunta di recente al draft di HTML5), altri browser potrebbero supportarla, magari con l’utilizzo di Modernizr , sull’uso di alcune istruzioni del CSS3) per cui vi rimando su diveintohtml5 (sito dalla grafica molto grunge ma pieno di spunti per avvicinarsi all’HTML5).

In realtà eseguendo l’esempio che riporterò a breve, potrete verificare direttamente se la vostra versione del browser supporta la geolocalizzazione.

Come utilizzarlo

Ma tornando sul pezzo: come facciamo ad utilizzare le api di HTML5 relative alla geolocation ?

Premesso che per le API applicative HTML5 richiedono l’uso di Javascript, per verificare la compatibilità del vostro browser relativamente a geolocation basterà inserire in una pagina il seguente script:

[sourcecode language=’js’]

[/sourcecode]

In questo esempio memorizzo in due variabili globali (latitudine e longitudine) i rispettivi valori mediante una callback.

Le API di GeoLocation non si limitano alla latitudine ed alla longitudine – nel momento in cui vi scrivo, infatti, sono previste le seguenti proprietà:

  • latitude
  • longitude
  • altitude (optional)
  • accuracy
  • altitudeAccuracy (optional)
  • heading (optional)
  • speed (optional)
  • timestamp

L’accuracy, ad esempio, si rivela molto utile per stimare il grado di precisione della lettura dei parametri latitudine e longitudine: se pensate di integrare sulla vostra web app la geolocalizzazione, con l’accuracy, ad esempio sarebbe utile riportare tale valore dato che, soprattutto in assenza di una antenna gps, la lettura della posizione potrebbe avere degli scarti anche dell’ordine di centinaia di metri.

Mentre scrivevo questo articolo mi sono, ovviamente, divertito a creare uno script leggermente più complesso, che visualizzi una Google Map con un marker sulla posizione rilevata dal browser.

Potete vedere qui lo script in azione 😉

Un dettaglio sul codice dell’esempio: nell’inclusione del javascript per la mappa di Google, ho disabilitato il sensor (che era un metodo alternativo di geolocalizzazione basato su Gears).

Inoltre, ho utilizzato tutti i parametri che è possibile passare alla funzione navigator.geolocation.getCurrentPosition:

  • la callback in caso di esito positivo della lettura della posizione
  • la funzione per l’esito negativo
  • l’array di opzioni (io ne ho inserite due: timeout della richiesta e flag sull’accuratezza della lettura)

Considerazioni

Non vi nascondo che sono sempre stato scettico sul fornire ad una web app la posizione geografica e, come me, gran parte degli utenti potrebbero avere delle remore a fornire queste informazioni durante la navigazione di un sito web.

In realtà esistono svariati contesti in cui la geolocation si rivela molto utile e, secondo me, è in quegli ambiti che può trovare applicazione:

Come raggiungerci

Pensate ad esempio alla classica pagina “Dove siamo/Come raggiungerci” di siti relativi ad esercizi commerciali – leggendo la posizione dell’utente gli si può presentare una mappa con il percorso per raggiungere in auto la vostra sede, cosa sicuramente più evoluta rispetto alla classica mappa.

Geotagging

Pensate a tutte le applicazioni di ugc (user generate content) dove pubblicare contenuti corredati di una posizione geografica può fare la differenza – geolocalizzare il contenuto o l’azione di pubblicazione del contenuto consente di sviluppare web app come quelle di Flickr e Twitter che basano alcune delle loro funzionalità sulla posizione geografica dei contenuti e che in questo caso verrebbero valorizzate senza ulteriore intervento da parte dell’utente.

Around me

Citando il nome di una famosissima app su iPhone, sfruttando la posizione geografica si potrebbero suggerire contenuti, servizi, esercizi commerciali e tutto quanto ci viene in mente, da quelli più vicini alla posizione dell’utente.

…provate a immaginare il tipo di applicazioni che potremo sviluppare quando a questa funzionalità si va ad aggiungere la ricerca semantica dei contenuti: potrei, ad esempio, cercare il negozio più vicino che vende un libro con un dato codice ISBN!!!

…incredibile, no ?! 🙂

HTML5 cheat sheet: eccone una molto carina, pronta per essere stampata

Se avete intenzione di iniziare ad utilizzare i tag dell’HTML 5, può essere utile avere un documento, magari stampato, che riporti tutti i tag introdotti dalla nuova codifica.

Gironzolando in rete si trovano molte cheat sheet su HTML5, quella che vi propongo mi è piaciuta molto ed è disponibile in due versioni (bianco su nero e viceversa).

Il link è il seguente: http://woork.blogspot.com/2009/09/html-5-visual-cheat-sheet-by-woork.html

happy HTML5 coding 😉

HTML5, una rapida panoramica sulle novità

HTML5 ormai è alle porte e le novità che porta questa versione “aggiornata” dell’hypertext markup language vanno ben oltre il tag video (che, anche su questo sito, ha suscitato interessanti diatribe).

HTML5, infatti, per chi (come me) considera il web un ambiente dove sviluppare applicazioni, fornisce supporto a tantissime tecnologie e strutture dati che, formalmente inserite mediante i rispetti tag, consentono di rendere i contenuti online sempre più orientati al web semantico.

Ad esempio, è possibile definire un menu con l’apposito tag (<menu>) o altri elementi di layout delle pagine quali header (<header>) e footer (<footer>, ovviamente 🙂 ).

Ciò consente, innanzitutto, di superare i limiti dei classici tag <div> e <p> nella organizzazione della rilevanza dei contenuti in una pagina…un esempio ? Attualmente, dal punto di vista del DOM, una lista di voci all’interno di un paragrafo del contenuto principale e una lista di voci di un menu in un altro paragrafo della stessa pagina, hanno la stessa “dignità”…questo in quanto il browser, a meno di un markup molto “pulito” non ha modo di interpretare né di distinguere elementi il cui contenuto è più informativo rispetto agli altri elementi della pagina.

…a dirla tutta, i browser attuali non hanno una reale necessità di discernere i contenuti dagli elementi accessori alla pagina…(l’ho scritta malissimo ma spero renda l’idea 🙂 ), il discorso però cambia se si vogliono estrarre contenuti da pagine con layout molto complessi, ad esempio per una lettura più agevole.

In tal senso, alcuni browser (come Safari) si stanno “portando avanti” integrando soluzioni di estrazione del contenuto principale (quindi, presumibilmente quello più informativo)…nello specifico, Safari usa Readability, un progetto open source.

Piccola parentesi: di recente il discorso della readability è un tema molto sentito…iBooks vi dice nulla ?! 🙂

Ma questa è solo una delle novità introdotte da HTML 5, in realtà una delle più evidenti è presente anche su questo sito…ed è visibile nel logo: il mio logo, infatti, è realizzato utilizzando non più un’immagine bensì dei canvas (che per ora vengono generati da un javascript) ma che sono pienamente supportati da HTML 5

Senza contare tutte le novità relative ai tag <audio> e <video> e ai già citati risvolti relativi all’introduzione di quest’ultimo tag 🙂

Nei prossimi giorni pubblicherò un articolo con tutte le novità di HTML5 relativamente ai form, alle tecnologie come la geolocalizzazione, l’offline storage e tutto quanto permette di apprezzare la vera potenza di questo linguaggio, decisamente più orientato alle web application.

Prima di salutarvi, però, vi segnalo un link molto interessante, completo di tutorial su HTML 5 e su cheat sheet per avere sempre sott’occhio i tag del nuovo linguaggio: http://webdesignledger.com/tutorials/15-useful-html5-tutorials-and-cheat-sheets

ciao 🙂

PS: l’immagine abbinata a questo post è tratta da Smashingmagazine ed è un intero fumetto su HTML5, ecco il link.

HTML5 e tag video: l’inizio della fine per i player Flash ?

Ormai se ne parla un po’ ovunque: l’HTML 5 apporterà davvero tante novità, la maggior parte di queste, sicuramente diventeranno gioie e dolori per chi del web ne sviluppa le interfacce, chi realizza il markup…altri aspetti, altrettanto innovativi, danno origine a speculazioni di vario genere.

Ma prima di arrivare al punto, una piccola parentesi: dovete sapere che quando nel lontano 1996 Google non era ancora l’indice della Rete, una delle mie attività preferite sul web (oltre a scrivere un blog in inglese sulla realtà virtuale immersiva 🙂 ) consisteva nel praticare ore (notturne) di netsurfing selvaggio: semplicemente partendo da un sito che mi interessava, proseguivo senza alcun freno verso i link in uscita da quella pagina…questa attività, molto spesso, conduceva su pagine sperdute nella rete, dove mi ritrovavo a leggere di chissà quali argomenti.

Ebbene, nel corso degli anni (per motivi di facile comprensione), ho un po’ abbandonato questa pratica, ma capita che avendo sempre con me un “cellulare connesso alla rete” (se mi sentisse Steve Jobs… 🙂 ), di tanto in tanto riesco a riprovare questa esperienza.

Di recente, infatti, sono incappato in un sito dove il tema principale è l’approccio all’imminente html5 ( Dive Into HTML5 ) e, in particolare, mi ha colpito la completezza con cui vengono descritti i protocolli di codifica, le questioni di licenze annesse e connesse e le alternative open per realizzare e riprodurre contenuti video su pagine conformi al nuovo standard.

Di cosa si tratta: in poche parole, con l’avvento dell’HTML 5, sarà possibile inserire video all’interno delle pagine html utilizzando un tag (<video>, per l’appunto), esattamente come avviene ora per le immagini (mediante il tag <img>).
Attualmente, invece, l’inserimento di un contenuto video in una pagina html prevede l’inclusione di un oggetto (il player) preposto alla riproduzione dei video: negli ultimi anni, infatti, la diffusione di player video in Flash hanno fatto la fortuna di progetti com YouTube e Vimeo e, in virtù della loro notorietà, aumentato enormemente la diffusione di contenuti video in rete.

Di pari passo con la diffusione di player Flash per i video, è altrettanto diffuso proprio il formato di codifica dei video compatibile con Flash: l’FLV (FLash Video).

Attualmente, per inserire un player flash e riprodurre video flv in una pagina html, infatti:

  1. I video da riprodurre vanno convertiti (o transcodificati, come direbbe il mio prof di Elaborazione Numerica dei Segnali 🙂 ) nel formato FLV
  2. Il player (che di fatto è un programma flash, compilato, con estensione .swf) va reso disponibile sul server
  3. All’interno della pagina html dove inserire il video (ed il relativo player), vanno aggiunte le istruzioni di embed necessarie ad informare il browser che dovrà eseguire un programma, in flash, con determinati parametri (il percorso del file al punto 2 e, generalmente, anche il percorso del video .flv al punto 1)
  4. L’utente deve avere installato un plug-in per eseguire nel browser applicazioni flash (come le animazioni, i banner animati…i player flv)

…ed è proprio su quest’ultimo punto che vorrei soffermarmi: fermo restando che qualunque contenuto video, affinché sia “riproducibile”, in un modo o nell’altro, prima o poi, andrà transcodificato e che, anche sull’inserimento di tag nella pagina non ne possiamo fare a meno, ciò che attualmente è legato alla specifica tecnologia (di riproduzione) utilizzata, richiede:

  • L’esistenza di un player sul server
  • L’esistenza di un plug-in sul client

Questo è quanto accade ora, con Flash.

…e qui arriva la mia speculazione: se HTML5, con l’avvento del tag <video> ed il relativo demand al browser della scelta del miglior player (disponibile dal sistema operativo), per riprodurre filmati non solo in flv ma anche (e, credo, soprattutto) in H.264, in un certo senso tenderà a “liberare” la questione dell’embed di video dai punti 2 e 4 dell’elenco di sopra,
è plausibile che il predominio di Flash, per la riproduzione di video, ne sarà influenzato ?

La mia risposta è: FORSE, soprattutto perché se è vero che convertire e riprodurre video in FLV non è esente da costi/condizioni di licenza a favore di Adobe, la situazione non è molto differente se, anziché usare Flash Video, si usa Windows Media, QuickTime e persino H.264 (come riporta quell’articolo su DiveIntoHtml5)…ovviamente esistono soluzioni open e questo scenario, magari, farà da cassa di risonanza proprio ai formati di codifica open source.

Ma la considerazione immediatamente successiva è quella relativa all’accesso dei dispositivi dotati di browser web, sinora sprovvisti di plug-in per Flash, a contenuti video su pagine conformi allo standard HTML5:

In questo momento, ad esempio, la versione di Safari per iPhone non supporta Flash in quanto Adobe non ha rilasciato un plug-in che consenta al gioiellino di casa Apple di riprodurre filmati Flash e, di conseguenza, player .flv qualora questi siano presenti nelle pagine…

Ma il motivo per cui sto spostando l’attenzione di questo post sul discorso mobile non è casuale 🙂

…vediamo se riesco a rendere l’idea:

  • Attualmente un Nokia N97, ad esempio, a differenza di altri palmari, può riprodurre contenuti Flash ed ha un supporto di terze parti (Adobe) a contenuti quali Flash e Pdf
  • Google, anni fa ormai, acquista YouTube: decisamente il più diffuso portale di video sul web…che sinora usava esclusivamente Flash
  • Ma Google sta sviluppando Android quindi, al pari di YouTube, potrebbe ritrovarsi a “dipendere” da una tecnologia proprietaria (non sua 🙂 ) per riprodurre filmati sul browser dei dispositivi dotati di Android

…e ora un po’ di domande:

  1. Che succede se YouTube inizia a sposare la causa dell’HTML 5 e, magari in poco tempo, iniziare a testare i video in HTML5 a scapito di Flash Video ?
  2. E’ un caso che Chrome (il browser di Big G, alla base anche del futuro Google OS) sia basato su WebKit, attualmente il framework per lo sviluppo di client web che meglio supporta HTML5…e che questo framework sia lo stesso su cui è basato Safari (sia su Mac che su iPhone) ?
  3. E’ un caso che su YouTube sia costantemente suggerito l’uso di Chrome ? (ovviamente, il primo motivo per farlo è quello di risicare quote di utenti a IE, Firefox ed altri…ma, secondo me, il motivo è più profondo…)
  4. Se Google (e tutti i progetti in suo possesso) ed Apple non avranno più necessità della tecnologia di Adobe, in virtù dell’alternativa derivante dall’utilizzo di HTML5 per il supporto del video sul web, chi ne trarrà i maggiori benefici ?

Personalmente piuttosto che addentrarmi nelle speculazioni su risvolti commerciali, mi piace concentrarmi sull’effetto che un simile ipotetico scenario avrà sui dispositivi che tutt’ora utilizziamo e che, ancora di più, avremo magari in tasca, in borsa, in ufficio e con cui accederemo alla rete nei prossimi mesi:

il mio MacBook Air non potrà che ringraziare se anziché stressare i due core del processore per far andare un player flash, demanderà l’esecuzione dei contenuti video, anche in HD, a Quartz e fratelli 🙂

Insomma, dal punto di vista dell’utente, io credo che i cambiamenti (soprattutto se nella direzione degli standard) non possano che produrre miglioramenti e, cosa piuttosto usuale sul web, favorire l’open source a scapito di tecnologie proprietarie…ma dov’è che l’utente davvero ci guadagna ?! sicuramente quando le aziende, man mano che prendono coscienza di tale processo, si staccano dal concetto di royalty a favore dei servizi da poter offrire: IMHO su questo Big G è davvero lungimirante,
staremo a vedere.