![\"flash](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2010\/03\/html5.png\" "\\"flash")
<\/p>\n<\/p>\n
Probabilmente saprete della recente presentazione di iPad da parte di Apple. L’assenza di un player Flash su questo device sembra aver risvegliato il dibattito HTML5 vs. Flash. A quanto pare, si tratta dell’ultimo chiodo nella bara di Flash.<\/p>\n
Le argomentazioni sono ampie, forti e legittime per entrambe gli schieramenti. Il CEO<\/abbr> di Apple Steve Jobs afferma che il Flash Player \u00e8 pieno di bachi<\/a>. John Gruber di Daring Fireball ritiene che Apple voglia mantenere il proprio ecosistema<\/a> \u2014 una formula nella quale Adobe non entra facilmente. D’altro canto, il CTO<\/abbr> di Adobe, Kevin Lynch sostiene che Flash sia un grande veicolo per la trasmissione dei contenuti.<\/a> Mike Chambers, Principal Product Manager per le relazioni con gli sviluppatori della piattaforma Flash di Adobe, esprime le sue preoccupazioni sulle piattaforme chiuse<\/a>. Grant Skinner, interactive developer, scrive delle riflessioni sui vantaggi di Flash<\/a>.<\/p>\n Comunque, la questione \u00e8 pi\u00f9 grande dello stabilire chi sia il migliore. Riguarda le preferenze e la politica. E’ una corsa agli armamenti. Questa \u00e8 la Guerra Fredda del Web.<\/p>\n Sia la comunit\u00e0 degli standard web sia la comunit\u00e0 di Flash sono molto brave a scambiarsi conoscenze e supporto all’interno dei rispettivi gruppi. Tuttavia, la relazione tra<\/em> le due comunit\u00e0 \u00e8 al limite della cortesia. Stanno succedendo sostanzialmente due cose: o le persone all’interno di ciascun gruppo stanno nel loro gruppo, oppure si lanciano insulti ignoranti da un gruppo all’altro.<\/p>\n Non appena una nuova tecnologia vede la luce, il numero dei suoi fan \u00e8 naturalmente piccolo. Un’efficace incitazione alla guerra consiste nel trovare \u2014o creare\u2014 un nemico comune. Progetti enormi come il re-design di Wired da parte di Doug Bowman<\/a>, CSS Zen Garden<\/a> di Dave Shea, e Designing With Web Standards<\/a><\/cite> di Jeffrey Zeldman hanno avuto un’influenza significativa non solo nella comunit\u00e0 degli standard, ma sull’intera industria del web design, collocando gli standard web come un’alternativa ai siti in Flash e ai siti basati sulle tabelle, per\u00f2 non in conflitto con questi. Tuttavia, dei “seguaci” di Flash poco perspicaci hanno male interpretato gli esempi di questi campioni degli standard web come un primo assalto. Nelle parole di John Nack, Adobe Photoshop Principal Product Manager: \u201cle persone vogliono una certa narrativa piena di \u2018killer\u2019<\/a>.\u201d.<\/p>\n La stessa cosa sta succedendo oggi. Quelli che stanno portando avanti la specifica di HTML5, come Ian Hickson<\/a>, Jeremy Keith<\/a>, ed il gruppo dei geek di NYC<\/abbr><\/a>, la propongono come una nuova alternativa con dei grandi vantaggi rispetto alle tecnologie esistenti. Tuttavia, ancora una volta, qualcuno la vede come la “precorritrice della rovina di Flash”.<\/p>\n La natura agonistica di questo dibattito sta distruggendo l’industria: i designers ed i developers sprecano il loro tempo giocando al gioco del \u201cvantaggio\u201d, di quale tecnologia sia migliore, quando invece dovrebbero collaborare tra loro. La specializzazione ha i suoi vantaggi, ma solo come un sottoinsieme di un tutto pi\u00f9 grande. Jamie Kosoy, un mio collega ed Associate Technical Director presso Big Spaceship<\/a>, lo dice chiaramente<\/a>:<\/p>\n Non c’\u00e8 un solo Flash developer in Big Spaceship. Infatti, noi facciamo una smorfia a titoli del genere.\u2026Noi siamo bravi con Flash (e lo amiamo), ma succede anche che siamo bravi (ed amiamo) un paio di miliardi di altre tecnologie..\u2026 Crediamo nel pensiero strategico, nel grande design e nello spostare i limiti un po’ pi\u00f9 in l\u00e0. Da nessuna parte diremo mai che una certa cosa debba essere fatta con la tecnologia X o con il linguaggio di programmazione Y per far s\u00ec che sia un nostro progetto sia di successo ed attraente, e non crediamo che gli utenti che sono sedotti dai progetti che pubblichiamo lo pensino.<\/p>\n<\/blockquote>\n<\/div>\n Il problema delle \u201cchiamate alle armi\u201d che stanno dietro ad una tecnologia \u00e8 che ci intrappolano nei confini dei loro vincoli. Facilmente trasformiamo i \u201cnon so\u201d ed i \u201cnon sono sicuro\u201d in \u201cnon si pu\u00f2\u201d e \u201cnon va fatto\u201d: la creativit\u00e0 subisce le imposizioni dei linguaggi di programmazione. Che tristezza!<\/p>\n Le tecnologie non sono intrinsecamente buone o cattive: sono solo appropriate o inappropriate a seconda delle circostanze. Sono un mezzo per raggiungere l’obiettivo, non una soluzione di per s\u00e9. Ciascuna \u00e8 potente nel suo diritto di raggiungere un certo risultato. La responsabilit\u00e0 sulla scelta di un’appropriata tecnologia \u00e8 di chi fa la scelta. Sfortunatamente, abbiamo scambiato lo sviluppo irresponsabile con la tecnologia inadeguata.<\/p>\n Prendiamo ad esempio il: caricamento (Loading). Flash fornisce dei metodi potenti per tenere traccia del progresso del download di ogni minuscolo elemento. E cosa abbiamo deciso di farne? Carichiamo tutto insieme e facciamo patire l’utente per minuti durante la sequenza di caricamento, invece che caricare gli assets progressivamente quando vengono richiesti. La piattaforma Flash non si merita il biasimo per siti web sproporzionati ed eccessivi: \u2014gli sviluppatori che hanno preso queste pessime decisioni devono essere biasimati.<\/p>\n Fintanto che non realizzeremo la pazzia della fede nella tecnologia, vedremo lo stesso ciclo ripetersi.<\/p>\n<\/div>\n La popolarit\u00e0 di JavaScript \u00e8 cresciuta esponenzialmente di recente, soprattutto grazie a librerie facili da usare come jQuery<\/a> e alla riscoperta dell’utilit\u00e0 di Ajax. I siti usano sempre di pi\u00f9 JavaScript per fornire grandi funzionalit\u00e0 alle persone che li visitano. Inoltre, molti esperimenti come il sito di Scott Schiller<\/a> e Browser Ball<\/a> spingono un po’ pi\u00f9 in l\u00e0 i confini degli usi tipici di JavaScript. Lo stesso vale per HTML5, con i suoi siti-esposizione come 9Elements\u2019 HTML5 Canvas and Audio Experiment<\/a> o il pi\u00f9 pratico SublimeVideo player<\/a> di Jilion.<\/p>\n Queste nuove possibilit\u00e0 portano domande interessanti, molte relative alla user experience. Se una feature richiede molto codice o molta grafica per essere alimentata, dobbiamo fornire all’utente un indicatore di progresso (leggi, preloader) del tempo che occorre prima di poterla usare? Una volta che useremo i video di HTML5 per interagire con altro video, testo e grafica avremo bisogno dei blending modes in HTML6<\/a> per creare degli ambienti online pi\u00f9 scorrevoli? Gli sviluppatori JavaScript realizzeranno il valore che il suono porta all’esperienza online e creeranno modi per gestire l’audio? Avremo bisogno di un editor visuale cos\u00ec che i designers che non sanno programmare potranno avvantaggiarsi dell’uso di E’ giusto che questo vi suoni familiare. Queste sono le questioni che la comunit\u00e0 Flash ha dovuto esplorare durante i suoi primi anni. A prescindere dalle vostre opinioni su Flash, \u00e8 difficile negare la formidabile<\/a> crescita<\/a> di cui \u00e8 stato protagonista e, ancora di pi\u00f9, la piattaforma Flash si \u00e8 espansa esponenzialmente per rispondere alle necessit\u00e0 dei suoi utenti\u2014le persone che la usano per creare e<\/em> le persone che usano il prodotto finale. In meglio o in peggio, Flash ha plasmato il modo in cui le persone fruiscono il contenuto online.<\/p>\n Adesso abbiamo il vantaggio di poter imparare da quel viaggio e ne stiamo gi\u00e0 raccogliendo i frutti. Ad esempio, qualunque modello di interazione che modifichi il refresh dell’intera pagina, fa decadere la funzionalit\u00e0 del pulsante “Indietro” del browser. Mentre ci sono voluti otto anni dall’inizio di Flash alla nascita di una soluzione come SWFAddress<\/a>, gli sviluppatori JavaScript godono dei benefici dati dal senno di poi e sono stati capaci di implementare una soluzione simile per le applicazioni basate su JavaScript<\/a> molto pi\u00f9 velocemente.<\/p>\n Mi spinger\u00f2 oltre dichiarando che la maggior parte degli sviluppi tecnologici sono nati da qualcosa che serve alle persone che usano queste tecnologie. Quando mettiamo troppa speranza nella tecnologia e cerchiamo di essere creativi per amore della creativit\u00e0, ripetiamo quasi sempre i nostri errori. Invece, quando cerchiamo di risolvere i problemi, ci costringiamo a prestare attenzione alle necessit\u00e0. L’innovazione \u00e8 un effetto collaterale naturale.<\/p>\n<\/div>\n Ma noi siamo orgogliosi delle nostre tecnologie, Ma se non combatto per il mio ranking come guru di un particolare linguaggio di programmazione o di uno stile di design, che cosa importa realmente? L’ho suggerito per tutto l’articolo, ma lasciate che lo renda dolorosamente ovvio.<\/p>\n Le persone.<\/p>\n Le persone sono importanti, non gli utenti. Le persone. Un utente \u00e8 un’entit\u00e0 senza volto che porta a termine dei task in maniera “robotica”, in modo che noi possiamo testare questi task ed ottimizzarli. Una persona vive, ride, piange, ama, odia e usa i siti e le applicazioni che noi creiamo. Mia mamma. Tuo figlio di cinque anni. Suo nonno. La sua migliore amica. Il loro corso di scienze. Non ci dicono quanto apprezzino il nostro “progressive enhancement” o come usiamo quella API per disegnare o il nostro impeccabile uso dei selettori degli attributi (attribute selectors). Le persone dicono solamente che un sito web creava confusione o che era difficile da leggere o che \u00e8 stato divertente giocarci. Questa<\/em> \u00e8 la motivazione reale che ci porta all’eccellenza: portare facilit\u00e0 d’uso, gioia e divertimento alle persone che ci circondano.<\/p>\n Dovremmo arrivare a un punto in cui le persone non saranno in grado di dire come sia stato costruito un sito. Io adoro imbattermi in un sito dove non \u00e8 chiaro fin da subito il modo in cui \u00e8 stato creato. Questo \u00e8 come dovrebbe essere: creare qualcosa di eccellente in cui la tecnologia sia trasparente e permetta solo ai curiosi di guardare sotto la superficie per vedere come funziona. JavaScript, Flash, HTML5, tabelle, Shockwave, Unity\u2014nessuno si preoccupa che le persone che usano un sito siano in grado di fare quello che si suppone debbano fare. Quando qualcosa non funziona\u2014 sia essa la funzionalit\u00e0 o la user experience\u2014quello \u00e8 il momento in cui sentirai le lamentele riguardanti la piattaforma. Create una grande esperienza per gli utenti e quello sar\u00e0 il momento in cui riceverete dovuti elogi, indipendentemente dalla tecnologia usata.<\/p>\n<\/div>\n La disputa sta invecchiando. Ecco cosa possiamo fare noi.<\/p>\n Cominciamo col supportare le iniziative invece che andargli contro. Pensate che Flash faccia schifo? Non scrivete un’invettiva sul vostro blog indirizzata ad Adobe: contattate direttamente il team Adobe<\/a> e ditegli che cosa secondo voi deve essere migliorato. Pensate che HTML5 sia uno scherzo? Allora datevi da fare con il working group<\/a> per rendere la specifica HTML5 migliore. Avete un problema con un sito dovuto al modo in cui \u00e8 stato creato? Rivolgetevi ai suoi creatori spiegando i vostri dubbi e dando suggerimenti in privato e con umilt\u00e0.<\/p>\n Se avete una web agency: smettetela di scrivere annunci di ricerca di designer HTML5 o guru di ActionScript. State solo alimentando le fiamme. Al contrario, investite in persone creative che sanno fare le cose in molti modi diversi; privilegiate le persone che danno priorit\u00e0 all’apprendimento di nuovi tool per risolvere un problema rispetto ad affinare le proprie nozioni. Non vendete (o scoraggiate la vendita) di Flash o degli standard ai vostri clienti: piuttosto, vendete delle estensioni creative del brand, del contenuto accessibile, delle esperienze gradevoli e un mantenimento semplice.<\/p>\n Lasciate che le tecnologie compiano il loro ciclo vitale da sole. Macromedia Director non \u00e8 pi\u00f9 popolare perch\u00e9 la sua utilit\u00e0 \u00e8 andata scemando, non perch\u00e9 l’abbiamo crocifisso. La vecchia maniera di scrivere JavaScript si sta esaurendo da sola perch\u00e9 noi supportiamo metodi non invasivi<\/a> e DOM-based<\/a>.<\/p>\n Insegnate. Prendete contatti con l’universit\u00e0 locale o con le scuole superiori (Teach me the web<\/a>, negli USA) che hanno programmi riguardanti il web design e offritevi come insegnanti per la nuova generazione di web designers e developers. L’istruzione nel campo del web design \u00e8 stagnante: ci vogliono persone con passione che hanno voglia di cambiare lo status quo per uscire da questa situazione. Impegnatevi con il meraviglioso lavoro che si sta facendo nell’area dell’educazione al web design, come quello svolto dal programma WaSP InterAct<\/a>, o l’Opera Web Standards curriculum<\/a>, o ancora Adobe Education Technologies<\/a>.<\/p>\n Per finire, ricordatevi cosa importa veramente: le Persone. Per il bene di tutti, \u00e8 ora che cominciamo ad andare d’accordo<\/a>.<\/p>\n<\/div>\n\nCessate il fuoco!<\/h2>\n
\n
\nUn riga nella sabbia<\/h2>\n
\nCondannati a rivivere il passato<\/h2>\n
<canvas><\/code>? Le applicazioni web piene di script metteranno a dura prova i processori?<\/p>\n\nVale la pena combattere<\/h2>\n
\nWe want you<\/h2>\n