Una soluzione che è piaciuta a molti è questa specie di “foto comparativa” con la quale è possibile confrontare due foto scattate dal satellite sulla stessa zona ma in due diversi momenti, prima e dopo la catastrofe.
Trascinando il cursore (che nell’immagine qua sotto vedete in blu, proprio al centro) si scopre la foto del “prima” e si copre allo stesso tempo la foto del “dopo”, e viceversa. In questo modo si possono confrontare facilmente le due immagini e rendersi conto della devastazione che quei luoghi hanno subito.

Il New York Times ne pubblica otto, una dietro l’altra, in questa pagina: Satellite Photos of Japan, Before and After the Quake and Tsunami.
Troviamo lo stesso tool su Der Spiegel (con l’aggiunta di un menu per muoversi tra le varie foto disponibili): Tsunami-Satellitenbilder: Der Tod kam aus dem Meer, sul Guardian: Japan tsunami – before and after pictures e sull’Herald Sun Before-and-after interactive photos from the Japan earthquake and tsunami.
Alcune sono fatte in flash, altre in html+javascript.

Venendo in Italia, anche il Corriere.it ne fa una gallery: Prima e dopo il sisma, le foto interattive, e rispetto agli altri – a parte la solita tremenda pratica di aprire la pagina in una popup – troviamo un dettaglio in più: in ogni visualizzazione ci sono due link che permettono di passare da una foto all’altra e viceversa molto rapidamente, senza dover fare drag’n'drop, amplificando l’efficacia del confronto tra le due foto.
È una scelta azzeccata, perché la velocità e la naturalezza della transizione è fondamentale per rendere l’idea del cambiamento. Mi viene in mente un’altra foto interattiva, Signs of Occupation, nella quale per dare risalto alle conseguenze dell’occupazione USA di Baghdad, Maps of war aveva optato semplicemente per una dissolvenza incrociata comandata da un pulsante “change view”, puntando tutto sull’immediatezza della transizione per aumentare il contrasto tra le due immagini.

Miller Medeiros pubblica un post dal titolo “iPad is the new IE6″. Secondo Medeiros i designer si aspettano molto da HTML5, ma i browser (in particolare Safari iOS, quello dell’iPad) non lo supportano perfettamente e sono pieni di bug. Sta passando l’idea che HTML5 può sostituire completamente FLASH, ma per contenuti multimediali complessi (“heavily interactive/multimedia content”) Flash sarebbe ancora la strada migliore. “chi dice che FLASH è pieno di bug, non ha mai provato a fare nulla di ‘complesso’ con l’elemento video di html5 su iPad”.

Il succo del post è che il designer che realizza contenuti interattivi sofisticati in html5 dovrà perdere molte ore per risolvere problemi inaspettati, proprio come per anni è avvenuto con ie6. Il mal di testa è più forte se c’è di mezzo iPad, per due motivi fondamentali: la frequenza delle nuove release di iOS che aggiungono o modificano regole, oppure aggiungono nuove funzionalità proprietarie; e in secondo luogo non è così facile trovare su blog e forum le risposte che si cercano.

“Se non mi credete provate a cercare su stackoverflow”, dice Miller Medeiros che conclude “più ti avvicini al limite, maggiori sono i problemi”.

Ecco il link: IPAD IS THE NEW IE6

Un post interessante perché evidenzia alcuni dei problemi principali chesi trova ad affrontare chi oggi sviluppa applicazioni complesse, ma anche opinabile per molti aspetti: innanzitutto una certa confusione nella critica (di che stiamo parlando, di html5? oppure di webkit? di safari mobile? di ipad? HTML5, poi, non è ancora uno standard, ma una draft, uno standard in fase di definizione e sta muovendo i suoi primi passi, è normale che i browser – soprattutto in casi “estremi” come quelli che ipotizza l’autore del post – possano comportarsi in maniera inaspettata o rivelare dei bug.
Inoltre Safari iOS integra funzionalità proprietarie (anche) per supportare al meglio i controlli touch di iPad/iphone.

Tutto questo ha poco a che vedere – se non le ore spese a cercare di aggirare un bug, e relativo “mal di testa” – con un software che anche maturo (se così si può dire) ci ha fatto impazzire violando standard condivisi per anni.

Eric Holter pubblica un post su Agency Critique dal titolo abbastanza esplicito: Agency Website Gaffes: #3. Flash. Già in passato su questo blog avevo espresso le mie perplessità sulla validità di Flash per realizzare interi siti internet, soprattutto dal punto di vista SEO. Ovviamente la difficoltà con cui i motori di ricerca indicizzano i contenuti flash è anche al centro del post di Holter, ma questa volta, tra i tanti svantaggi che Ageny Critique ricorda mi preme sottolineare l’aspetto del content management e dell’aggiornamento delle pagine:

Flash a volte viene utilizzato non perchè è la migliore piattaforma per il sito, ma perchè è lo strumento che il designer padroneggia meglio. Cosa che si traduce presumbilmente in un CMS povero, e quindi in meno update sui contenuti.

Ed in effetti – aggiungo io – molte volte chi si ritrova un mirabolante sito in flash è orgoglioso del suo sito, ma capita anche che qualcuno si lamenti della difficoltà con cui riesce ad aggiornarlo.
Il post di Holter continua ipotizzando le ragioni per cui le webagency preferiscono proporre Flash ai loro clienti, vale la pena leggerlo: Agency Website Gaffes: #3. Flash

(A questo punto devo dirlo: se c’è qualcosa che non sopporto nella vita sono i blog in flash).

È di qualche giorno fa la notizia che Google finalmente indicizza i contenuti Flash. Una notizia che a differenza di molti, ho accolto con qualche freddezza, anche se la cosa che più mi spinge a non apprezzare flash come strumento per il web, è proprio il fatto che praticamente viene ignorato dai motori di ricerca. La diffidenza iniziale ha poi trovato conforto in articoli come questo: Flash and SEO – Compelling Reasons Why Search Engines & Flash Still Don’t Mix, pubblicato su Seomoz, e che vi consiglio di leggere se siete interessati all’argomento.

Ecco le mie prinicipali perplessità…

Innanzitutto, stando a quanto dichiarato su Webmastercentral, l’algoritmo creato da Google indicizza solo i contenuti testuali presenti all’interno dei filmati swf. Sono escluse quindi le immagini, e se i pulsanti non contengono testo non viene considerato alcun anchor text (mentre vengono seguiti i link che si trovano nell’swf, che, se testuali, ricevono lo stesso trattamento e considerazione dei link html).

Nella ricerca dei contenuti, ancora una volta Google si comporta come un umano, per il momento un umano con javascript disabilitato: dovrebbe essere in arrivo un importante update, ma per ora tutte le volte in cui il filmato flash viene caricato nella pagina con javascript (attraverso SWFobject per esempio), esso sfuggirà al motore di ricerca. Una casistica non tanto limitata, se si pensa che javascript è il modo più semplice per inserire swf nella pagina e restare crosswbroser, evitando gli errori di visualizzazioni di Internet Explorer.

Fondamentalmente, con qualche (importante) eccezione, da qualche giorno Google riesce a navigare nei contenuti flash e quindi leggere e indicizzare il testo in maniera più efficace di quanto riusciva a fare già in passato.

Prima di correre a realizzare interi siti in Flash, quindi sarà meglio considerare che uno dei maggiori limiti di questa tecnologia – la quasi impossibilità con cui i motori di ricerca riescono ad addentrarsi nei contenuti swf – non è affatto superato.

Le carenze strutturali di Flash rispetto ai motori di ricerca rimarranno fino a quando questi ultimi avranno bisogno del markup, per capire cosa è importante all’interno di una pagina; e dei link per capire quali pagine sono importanti: fare un sito interamente in flash significa praticamente rinunciare a molti link in ingresso, poichè a contenuti specifici non corrispondono url specifici.

Ma evidentemente link e markup non sono cose a cui è possibile rinunciare…

Per come la vedo io, Google fa, sempre egregiamente, il suo lavoro: e accresce le proprie capacità di sondare la rete, potenziando in qualche modo il suo bot dove naturalmente è più debole, migliorando di conseguenza il servizio.

Noi, operatori del web, dobbiamo continuare a fare il nostro: flash andrebbe usato per realizzare piccole parti animate all’interno di un sito, o pagine altamente spettacolari, talmente spettacolari che essere perfettamente indicizzati può rappresentare un’esigenza secondaria. In tutti gli altri casi, quando i nostri clienti devono assolutamente esserci sui motori di ricerca, cioè nella maggior parte dei casi, Flash è dannoso.

(E ciò non vuol dire che dobbiamo rinunciare allo spettacolo: per questo esistono jQuery, Prototype o Mootools…)

Flv è il formato standard di fatto per la distribuzione dei video su internet. Il convertitore flv più diffuso è molto probabilmentie Riva encoder. Si tratta però di un software per Windows e non è disponibile la versione per Mac.
Gli utenti della Mela hanno però a disposizione diverse soluzioni per convertire i più svariati formati video, come MOV, MP4, AVI in filmati FLV.

Tra i software più avanzati troviamo sicuramente Sorenson Squeeze. Si tratta di convertitore universale di cui però è disponibile una versione dedicata ai formati Flash. Sorenson Squeeze for Flash, converte quindi in SWF e in FLV. Permette di definire il file di Output fin nei minimi dettagli o programmare un batch di esportazioni.
Il massimo probabilmente per chi ha bisogno di un convertitore professionale. L’unico aspetto negativo è che costa 200 dollari.

Un’alternativa a sorenson Squeeze è Visual-Hub, un software non pensato esclusivamente per le conversioni in flv: si tratta piuttosto di un convertitore universale che accetta una serie di formati per l’input e l’output. Tra questi ultimi anche FLV. Dimensioni del frame, bitrate, frame rate, qualità audio sono tutti pArametri che potremo definire prima di iniziare l’esportazione. Il costo è abbordabile: 15,72 euro.

La soluzione gratuita ed open source è invece FFmpegX. Siamo ancora una volta di fronte ad un convertitore universale che prevede una serie di formati di output, tra i quali FLV, con un discreto controllo sulle caratteristiche del filmato finale.

I video che vediamo sulle piattaforme di video sharing, e che troviamo nella maggior parte dei siti web, sono video in formato FLV.
FLV è un formato proprietario Adobe, ed è di fatto lo standard per la distribuzione dei video sul web.
Per poter inserire questo tipo di video all’interno di una pagina web è necessario un player SWF.
SWF è il formato dei video interattivi prodotti utilizzando Adobe Flash. In questo caso la tecnologia SWF serve a creare un contenitore in grado di riprodurre e controllare il flusso video FLV. Per creare un player quini per video FLV è necessario utilizzare Adobe Flash, mentre in rete non mancano anche player già pronti ed open source.

La visualizzazione del filmato FLV su un qualsiasi browser dipende quindi innanzitutto dalla possibilità di visualiizare il player SWF. Per poter visualizzare un qualsiasi file SWF su un browser, è necessario che sia installato il plugin Flash Player di Adobe. A seconda della versione di Flash utilizzata per creare il filmato SWF e delle caratteristiche del file, è necessario aver installato una versione più o meno recente del (plugin) Flash Player.

Ricapitolando: il video (FLV) viene riprodotto da un player (SWF) all’interno di un browser in cui è installato il giusto plugin (Adobe Flash player). Ma non è finita.

Il video FLV è un flusso di informazioni ovviamente codificate. La codifica originaria dei video FLV era una variante di H.263, realizzata da Sorenson. Da qualche mese i video FLV possono essere codificati anche con la potente H.264 (mpeg-4 parte 2). Quindi è possibile trovare file FLV codificati in maniera diversa. Si tratta di una differenza non da poco: incide ovviamente sulla qualità e sul bitrate del video da riprodurre, ma anche sui requisiti di sistema necessari a riprodurre il video. Se la codifica Sorenson è supportata da flash player a partire dalla versione 6, la codifica H.264 è supportata solo nelle ultime release della versione 9.

In rete quindi, oltre alle applicazioni desktop per riprodurre i video offline, possiamo trovare:

• Player swf realizzati allo scopo di riprodurre video flv. [post]
• Script per una corretta visualizzazione dei filmati Swf. [Post qui e qui]
• E infine encoder per convertire video in altri formati proprio in FLV [post].

<script type="text/javascript" src="swfobject.js"></script>

A questo punto, come nel caso di UFO, si imposta il div contenitore: il testo presente all’interno di quest’ultimo sarà visualizzato in tutti i casi in cui, per qualsiasi motivo, javascript non sarà in grado di inserire il player, ma possiamo essere abbastanza sicuri che ciò avverrà solo se non è installato il plugin. Proprio per questo motivo il testo che inseriremo in questo div farà riferimento al plugin mancante:

<div id="swfcontent">
Non è possibile visualizzare il filmato.<br/>
Potrebbe essere necessario installare il plugin flash.<br/>
Puoi scaricarlo <a href="http://www.adobe.com/shockwave/download/download.cgi">qui</a>
</div>

A questo punto possiamo ordinare a SWF Object di sostituire il contenuto del div “swfcontent” con il filmato che noi specificheremo, in questo modo:

<script type="text/javascript">
   var so = new SWFObject("mymovie.swf", "mymovie", "400", "200", "8", "#336699");
   so.write("swfcontent");
</script>

Evidentemente anche SWFOBJECT prevede parametri obbligatori: il percorso del file swf, l’ID univoco da assegnare all’oggetto multimediale che verrà creato, larghezza e altezza, la versione di flash player necessaria per visualizzare il file swf, e il colore di sfondo del filmato.

Ovviamente è possibile passare al file swf variabili flashvars, in questo modo:

so.addVariable("variable1", "value1");

Mentre la funzione getQueryParamValue permette inoltre di passare al filmato flash il contenuto di una variabile presente nell’url:

so.addVariable("varName2", getQueryParamValue("GetVarName"));

Per concludere ecco il codice completo per pubblicare contenuto flash utilizzando SWFOBJECT, supponendo che il file .swf si trovi nella stessa cartella del file html,:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>SWFobject | pagina esempio</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript" src="swfobject.js"></script>
</head>
  <body>
    <div id="swfcontent">
Non è possibile visualizzare il filmato. Potrebbe essere necessario installare il plugin flash, puoi scaricarlo <a href="http://www.adobe.com/shockwave/download/download.cgi">qui</a>
    </div>

<script type="text/javascript">
   var so = new SWFObject("mymovie.swf", "swfcontent", "400", "200", "8", "#336699");
// aggiungiamo righe come la seguente se vogliamo passare variabili al file swf
   so.addVariable("varName", "Var Content"); 
// aggiungiamo righe come la seguente per utilizzare variabili presenti nell'url
   so.addVariable("varName2", getQueryParamValue("GetVarName")); 
   so.write("flashcontent");
</script>


  </body>
</html>

Link:
La pagina di SWFobject

<object width="425" height="355">
<param name="movie" 
value="http://www.youtube.com/v/KvA0nmAhTfk&rel=1"></param>
<param name="wmode" value="transparent"></param>
<embed src="http://www.youtube.com/v/KvA0nmAhTfk&rel=1" 
type="application/x-shockwave-flash" wmode="transparent"
width="425" height="355"></embed></object>

L’utilizzo di OBJECT ed EMBED pone però una serie di problemi non di poco conto: innanzitutto la pagina non è standard-compliant. Inoltre, sulle versioni meno recenti di internet explorer il filmato flash è circondato da un fatidioso riquadro che indica che il file swf non è ancora attivo: bisognerà attivarlo facendo click sul filmato.

Per risolvere questi problemi sarà necessario ricorrere al DOM (Document Object Model). Faremo così: creeremo un elemento div nella pagina html; il contenuto di questo div sarà rimpiazzato (per mezzo di javascript) con del codice in grado di visualizzare correttamente il filmato swf.

A questo scopo è possibile utilizzare due diverse library javascript: Unobtrusive Flash Objects oppure SWFObject. In questo tutorial utilizzeremo la prima, nota come UFO. Vedremo in un altro post tutte le istruzioni per SWF object

Il primo passo da compiere è quindi il download di UFO.js.
A questo punto copiamo il file ufo.js nella cartella del nostro sito e lo richiamiamo nell’HEAD della pagina web in cui il filmato swf deve essere visualizzato:

<script type="text/javascript" src="ufo.js"></script>

Nel BODY della pagina invece creeremo un DIV, che avrà quindi ID univoco. Tutto il codice contenuto all’interno di questo DIV sarà sostituito da UFO con il filmato swf.

<div id="swfcontent">Non è possibile visualizzare il filmato. Potrebbe essere necessario installare il plugin flash, puoi scaricarlo <a href="http://www.adobe.com/shockwave/download/download.cgi">qui</a></div>

Se il contenuto del div deve essere sostituito, perchè abbiamo inserito, all’interno di swfcontent, un link alla pagina del plugin flash? La risposta è semplice. Se il plugin non è installato sul browser dell’utente, UFO non riuscirà a sostituire il contenuto del div con un filmato: in questo caso l’utente visualizzerà il contenuto del div, cioè un messaggio di errore che invita ad installare il plugin.
Dobbiamo comunque tenere bene a mente che teoricamente questo messaggio di errore viene visualizzato in tutti i casi in cui UFO non può funzionare: quindi anche quando il plugin è installato e tuttavia si verifica un errore che impedisce la sostituzione del contenuto del div. In realtà, se il codice è corretto, non dovrebbero verificarsi errori e il messaggio dovrebbe apparire solo se il plugin non è installato. In ogni caso, UFO rivela qui un altro vantaggio: la possibilità di inserire un contenuto alternativo che sarà visibile a tutti quelli che per un motivo o per l’altro non potranno vedere il filmato.

Andiamo avanti: torniamo nell’HEAD e ordiniamo a UFO di creare il contenuto flash, specificando il nome del div in cui inserirlo e un array contentente i parametri necessari alla riproduzione del filmato: nome del file swf, larghezza e altezza del filmato, majorversion (va bene la versione utilizzata per creare il filmato) e buildversion del plugin flash necessario a visualizzare il filmato.

<script type="text/javascript">
// innanzitutto impostiamo i parametri necessari
var FO = {movie:"nomedelfile.swf", width:"300", height:"120", majorversion:"6", build:"40" };
// quindi richiamiamo ufo, inviando i parametri contenuti in FO,
// e specificando l'elemento swfcontent 
UFO.create(FO, "swfcontent");
</script>

Per tutti i parametri opzionali consiglio di guardare la documentazione di UFO. Ricordo che utilizzando il parametro opzionale “flashvars” possiamo inviare variabili al filmato flash:

var FO = {movie:"nomedelfile.swf", width:"300", height:"120", majorversion:"6", build:"40", flashvars:"firstvar=daniele&secondvar=2" };

Supponendo che ufo.js si trovi nella stessa cartella della pagina html, e invece il filmato flash sia all’interno della cartella, “swf” il codice completo per visualizzare il filmato sarà questo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>UFO | pagina esempio</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript" src="ufo.js"></script>
<script type="text/javascript">
var FO = { movie:"swf/nomedelfile.swf", width:"300", height:"120", majorversion:"6", build:"40" };
UFO.create(FO, "swfcontent");
</script>
</head>
  <body>
    <div id="swfcontent">
Non è possibile visualizzare il filmato. Potrebbe essere necessario installare il plugin flash, puoi scaricarlo <a href="http://www.adobe.com/shockwave/download/download.cgi">qui</a
    </div>
  </body>
</html>

Link utili:
La guida ad SWFobject
Download UFO.js
Pagina web di UFO
Pagina web di SWFObject
DOM