Archivio mensile:dicembre 2010

Spam Spam Spamming

Pubblicità non gradita

Oggi, tra gli internauti, è molto diffuso l’utilizzo della parola SPAM per indicare un insistente invio di messaggi pubblicitari in posta senza aver chiesto autorizzazione.

Ma quanti sanno da dove deriva e cosa significa?

Per questo ringrazio mio cognato Canio (una mente ultraterrena) che, una domenica, mentre eravamo a tavola a gustare un piatto di lasagne, mi rivela l’origine del termine, e così ho cominciato a fare ricerche ed ho trovato interessanti notizie anche su wikipedia.

Spam è stato usato, nel modo che conosciamo, per la prima volta, in uno sketch comico del Monty Python’s Flying Circus ambientato in un locale nel quale ogni pietanza proposta dalla cameriera era a base di SPAM (un tipo di carne in scatola).

Spam_with_cans.jpg

Nello sketch comico la cameriera insiste nel proporre piatti con “spam”:

uova e spam, uova pancetta e spam, salsicce e spam e così via…

Praticamente i Monty Python prendevano in giro la carne in scatola “Spam” per l’assidua pubblicità che la marca era solita condurre alla fine della Seconda Guerra Mondiale.

Per questo, oggi, lo Spamming è usato, soprattutto, quando arrivano “con insistenza” messaggi pubblicitari indesiderati nella nostra posta elettronica.

Un altro termine coniato, per queste tipologie di e-mail, è junk-mail cioè posta spazzatura.

 

Guarda lo sketch

http://www.youtube.com/watch?v=ELGApKx5RO8&feature=pl…

 

Matteo Foschi

Annunci

Il web accessibile e il progetto ARIA

Chi sviluppa siti web con particolari vincoli riguardo l’accessibilità e le tecnologie assistive è perfettamente conscio di una cosa: l’HTML non è stato originariamente progettato per creare applicazioni web. Esso si basa su una struttura ben precisa di marcatura di linguaggio, con elementi che hanno una loro specifica identificazione e funzione, e con interazioni client-server che nella maggior parte dei casi sono di natura sequenziale. Questa linearità, logica e chiarezza di struttura fa sì che, se utilizzato con criterio, l’HTML possa sopperire alle difficoltà che molti utenti disabili potrebbero incontrare nell’utilizzo e nella comprensione delle pagine web.

Utilizzare gli elementi di codice e i tags secondo la funzione per cui sono nati è sempre stato il miglior consiglio, e forse l’unico realmente valido, che i corsi sull’accessibilità e lo stesso W3C abbiano potuto dare alla comunità di sviluppatori e web designers. Perché mai utilizzare un elemento di testo, come può essere un tag <p>, formattato attraverso fogli di stile per farlo apparire come un titolo di una pagina, quando esiste un elemento ben preciso per raffigurare un titolo? Questo è solo un banalissimo esempio di come il non corretto uso semantico del codice possa provocare disagi a chi fa uso di tecnologia assistive nella consultazione del web. Nel caso specifico, se a consultare la pagina fosse un cieco che utilizza uno screen reader, leggerebbe comunque quel titolo come un paragrafo, in quanto il mezzo che si utilizza, a prescindere dalla componente visuale che l’autore avrebbe voluto dare alla pagina e al testo, riconosce la funzione specifica dei tags. Si può immaginare quindi che tipo di confusione tutto ciò possa generare nell’utente, il quale si troverebbe e cercare di comprendere un testo senza logica, proprio come se un paragrafo di un libro fosse stato scritto al rovescio.

Purtroppo però la buona regola della semanticità e sequenzialità del codice viene spesso infranta per poter utilizzare le applicazioni web di nuova generazione, quelle che cercano di arricchire l’esperienza dell’utente medio nella consultazione delle pagine web e che sono state foriere del web 2.0. La maggior parte di esse sono composte da librerie di codice JavaScript (AJAX, JQuery, Dojo ecc.) che hanno la capacità di scatenare eventi all’interno dei documenti web secondo una logica di casua-effetto. Grazie ad esse è possibile creare interazioni ed effetti di animazione intercettando gli elementi di una pagina ed associando ad essi un determinato comportamento. Il problema è che molto spesso queste librerie vanno a snaturare la funzione originaria di alcuni elementi ma soprattutto il loro funzionamento è totalmente sconosciuto alle varie tecnologie assistive utilizzate da utenti disabili.

Un sito web che propone nella sua homepage uno slide accattivante di immagini apparirà ad uno screen reader come una pagina che al suo interno ha una serie di immagini in sequenza; un menu che si apre a tendina tramite uno script in JavaScript apparirà come una semplice lista di link. In tutti questi casi se non si chiarisce nel codice che la sequenza di immagini in realtà è uno slide fotografico o che la lista dei link fa parte di un menu di navigazione, l’utente rimarrà sempre disorientato, e questi esempi forse sono quelli di natura più ottimistica.

Per far fronte a questo tipo di problema il W3C sta elaborando un progetto che prende il nome di WAI-ARIA. Il progetto non è ancora una raccomandazione ma è nello status di working draft (bozza), nonostante ciò le sue funzioni possono essere già utilizzate. In sostanza ARIA prevede l’implementazione nei browser di un sistema di parsing capace di riconoscere determinati attributi associati agli elementi HTML di una pagina web i quali hanno il compito di “spiegare” alle tecnologie assistive i ruoli e le funzioni che gli vengono associati tramite le librerie JavaScript, in modo da rendere chiaro il contenuto della pagina a chi non è capace di avere un riscontro visuale dei loro effetti. Gli ambiti di utilizzo possono variare dal semplice layout di una pagina ai particolari utilizzi dei form in essa contenuti piuttosto che alle chiamate asincrone che vanno a modificare il contenuto di una pagina altrimenti non visibile da un non vedente.

Per esempio ARIA può essere utilizzato per rendere esplicito il ruolo di alcuni contenitori che definiscono le sezioni di un documento web. Così un <div> che abbia come attributo “role=banner” renderebbe noto all’utente che quella sezione sia destinata alla pubblicità, un <div role=”navigation”> che quello spazio in realtà conterrebbe un menu di navigazione o ancora un <div role=”main”> raffigurerebbe il contenuto principale del documento. Tra gli altri attributi possibili indicati dalla bozza del W3C possono esserci anche i seguenti:  search, contentinfo, complementary, article ecc..

In un form sul quale si è costruito un effetto grafico di un misuratore di qualità, con animazione tipo lancetta di volume, ARIA può aiutare l’utente che non è in grado di vederla indicando lo specifico ruolo di ciascun tag  <input> utilizzato. Un <input aria-valuemin=”0”> puo’ indicare il valore minimo di voto da dare compreso tra sé e un <input aria-valuemax=”10”>. Attributi come “aria-labelledby” o “aria-valuetext” sono tutti finalizzati a rendere più chiaro il funzionamento del form che viene adattato per esigenze di applicazione web.

Ancora con ARIA si sarebbe finalmente capaci di far notare quale parte del contenuto di una pagina si sia modificato a seguito di un evento scatenato dall’utente che ha dato origine ad una chiamata asincrona al server . I moderni screen reader infatti, non sono capaci di riconoscere i contenuti di una pagina che si sono modificati all’interno della pagina stessa, ma danno aggiornamenti all’utente solo quando tramite link ipertestuale si va su di una nuova pagina, anche se dinamica. ARIA identifica le zone del documento che hanno contenuto variabile come “live regions” prevedendo una serie di attributi capaci di avvertire l’utente quando un contenuto di tali zone o di un menu si sia modificato “al volo”:  “aria-live” che avverte se una zona ha contenuto variabile; ”aria-atomic” che specifica se l’utente deve essere informato di tutta la parte del documento aggiornata o meno e via discorrendo.

Tutta la serie di proprietà e di attributi previsti è consultabile direttamente sulla bozza del W3C a questo indirizzo: http://www.w3.org/TR/wai-aria/

Come al solito però per poter usufruire degli effetti completi del progetto bisognerà aspettare che tutti i browser in circolazione implementino ARIA. A quanto pare al momento solo le versioni più recenti  la supportano, creando sempre problemi agli sviluppatori, i quali di fronte alle nuove norme sull’accessibilità dovranno continuare a fare salti mortali per implementare nuove soluzioni web con un compromesso di accessibilità.

Sarà inoltre interessante vedere come il progetto in questione si rapporterà al recente sviluppo dell ‘HTML 5, il quale già preve dei tag  a cui si è voluto dare un ruolo specifico di fronte all’esigenza di identificare contenuti multimediali all’interno del documento.

Marco Marasco

Fonti e documentazione:

Stallman: utilizzare il Cloud Computing è stupido

Non dev’essere facile, oggi, vivere da Richard Stallman. Quando passi una trentina d’anni a predicare che il software dev’essere libero per ragioni morali, che modificarlo è un diritto, e che se tutto ciò viene negato è la libertà personale stessa ad essere in pericolo, vedere che l’universo delle tecnologie sta andando in un’altra direzione, che il moltiplicarsi di strumenti dotati di programmi proprietari diradano il miraggio della libertà digitale, un certo disagio dovrebbe provocarlo.

Dopo aver fatto il punto sull’importanza di non cedere alla tentazione di contaminare il software libero, Richard M. Stallman si scaglia contro il Cloud Computing definendolo senza mezzi termini roba da stupidi. Il papà di GNU dice infatti che è stupido (questo termine l’ha usato molto spesso) affidare i propri dati in mani altrui, con i rischi che questo comporta per la privacy e per la stessa accessibilità ai propri documenti.

Stallman consiglia a tutti di tenere i propri dati al sicuro sui propri computer e di non credere a chi dice che il Cloud Computing è inevitabile: costoro non sarebbero altro che società con forti interessi affinché si accentui lo spostamento di dati e applicazioni dal controllo dell’utente ai lontani server di qualche società.

“Una ragione per non usare le web application è la perdita del controllo” prosegue Stallman: i dati fluiscono liberamente tra qualsiasi postazione o thin client in giro per il mondo e i datacenter, ma a scapito della capacità del legittimo proprietario di disporne a suo piacimento. Basti pensare a cosa accadrebbe nel caso in cui un account venisse sottratto al suo titolare: da quello stesso account potrebbe partire una reazione a catena, che coinvolgerebbe tutti gli altri servizi ad esso collegati, stravolgendo le attività personali e lavorative di quello stesso individuo.

In fondo Stallman fa da campanello di allarme, per evitare di accettare incondizionatamente tutto quello che ci viene proposto (o imposto!). I suoi toni drastici di sicuro catturano l’attenzione, certo magari l’allarme è un pò sproporzionato rispetto al pericolo…ma una cicca di sigaretta può distruggere un bosco…Meglio stare sempre vigili!

Antonio Monaco

%d blogger hanno fatto clic su Mi Piace per questo: