mercoledì 18 giugno 2008

Adobe vs Apple. No Flash per una iPhone UI consistente




Articolata posizione di Kontra sulle problematiche legate al mancato supporto a Flash Lite e Flash su iPhone.

Adobe’s interface strategy on the desktop has been to avoid using native UI controls on the deployed OS in favor of establishing and leveraging its own unique cross-platform UI paradigm that its runtime engine can deliver consistently on multiple platforms.

Unfortunately for Adobe though, Apple is in the process of establishing the first mass-market, multi-touch platform with the iPhone and has already migrated it partially to its notebooks. Clearly, Apple (which acquired FingerWorks and its patent portfolio in 2005) has greater ambitions in establishing a broader multi-touch gesture paradigm, likely to cover other devices as well

domenica 15 giugno 2008

Accessibilità nel Car Design



Una tuta speciale, studiata da Nissan, che aiuta a simulare (e registrare) il comportamento degli utenti della terza età nell'intento di migliorare la accessibilità dei nuovi modelli di auto in progettazione dalla casa giapponese.
E' chiaro l'intento di raccogliere frutti commerciali anche da questa fascia di utenti ma i dati raccolti saranno di aiuto nella ottimizzazione del Car Design nella sua globalità, andando ad impattare anche le altre fasce di età (e, dunque, di clienti potenziali).

sabato 14 giugno 2008

Andy Clarke, tempo di lettura e web layout


Andy Clarke on Web Layout from Jeffrey Zeldman on Vimeo.

Andy Clarke shows how comic book artists use panel size to indicate how much time a reader is supposed to spend on a particular chunk of content. He argues that web layouts can work the same way. (Later in this talk, he'll show how.)

Andy Clarke: How often do we consider the space and the time that somebody is supposed to spend, or we want somebody to spend, looking at a particular panel. So if we look at something like this, there's a conversation going on at the bottom here. 'Actually, she turned out to be quite sweet. I actually took her out a few times.' 'Seriously?' 'No.' And it carries on. So those panels are smaller because we're supposed to take less time reading them. It's this flow and this rhythm. And this is something that comic books have done for a very, very long time. And it's something that potentially we can bring into the layouts that we make for the web.

venerdì 13 giugno 2008

Mac OS X Jaguar (10.2) accessibility model. Anno Domini 2002





Documentazione Ufficiale sul Model/Object in Cocoa/Carbon Applications.

Opera 9.5 UI. Come sprecare spazio prezioso




Nuova UI per Opera. Stessi problemi di sempre.
L'ingombro verticale supera, sia nella toolbar che nella status bar, abbondantemente quella dei rivali a parità di funzionalità attivate.
Opera 9.5: 100px di toolbar e 21px di status bar.
Firefox 3: 80px di toolbar e 17px di status bar.
Safari 3: 75px di toolbar e 15px di status bar.
Se qualcuno in possesso di IE 7 volesse prestarsi alla comparazione, avremmo un quadro ancora più completo.

Se prendiamo in conto i dati di vendita dei monitors e dei computers, la situazione diventa alquanto preoccupante. Si diffondono sempre più gli schermi widescreen (e come monitors a se stanti e come parte dei notebooks che stanno soppiantando i desktop) che favoriscono l'ingombro orizzontale contro quello verticale mentre Opera va in controtendenza favorendo l'ingombro verticale contro quello orizzontale.

Su Mac, al solito (per quanto riguarda Opera), le inconsistenze abbondano. Se le icone della toolbar possono andar benissimo su Vista (per le quali sono state studiate evidentemente) su Leopard fanno a cazzotti non solo col resto della UI dell'OS ma anche, cosa più grave, con il resto della UI di Opera stesso. Né lo schema colore né lo stile sono consistenti.
Da notare in particolar modo la dissonanza tra le icone sulla toolbar laterale che, giustamente, si presentano in grigio 75% e la toolbar principale.
Troppa fretta della release? Forse.
I problemi di UI di Opera persistono comunque.

mercoledì 11 giugno 2008

Requisiti Accessibilità for dummies. Ma solo se lavorano nelle PA.

Ultimo episodio, per quanto mi riguarda, della telenovela 'Un posto accessibile al sole'.

Innanzitutto una premessa.
Fallibilità del precedente post si riferiva ad uno dei concetti fondamentali della Scienza del XX° secolo. Mi scuso se ho presupposto un background culturale comune che, con tutta evidenza, é assente.
Il titolo del precedente post non solo quindi é consistente con le argomentazioni ma anche, a giudicare dalle risposte, con il problema in oggetto.

Nella risposta andrò a ritroso in quanto mi preme, in conclusione di questa discussione in open space, tirare le fila di quanto si é perso per strada.

Io sono uno terra terra. Per me l’importante è che il designer Flash si preoccupi una volta tanto dell’accessibilità dei suoi prodotti. Quello che desidero è che il designer sviluppi animazioni Flash applicando tutti i criteri e le tecniche di accessibilità che la sua piattaforma gli consente. Il resto verrà col tempo.


E, dato che la 'piattaforma' non esiste come un tutto unico ma ha diverse funzionalità a seconda dell'OS si cui gira, dovremmo parlare non più di Flash in modo generico ma di Flash Player su Windows (su Mac, su Linux) e chiarire questa differenza.
Ciò non é discussione oziosa ma impatta sul lavoro quotidiano e sull'output. Inutile dare il via libera ai Devs (e qui parlo da Project Manager) sull'uso di una tecnologia sicuri della sua aderenza agli standards della accessibilità se poi, a conti fatti, è accessibile solo su di un OS. Sarebbe come dare il via libera sull'uso delle specifiche del CSS 3 che sono disponibili solo su Safari. Bello, certo. Peccato che solo gli utenti su Safari potrebbero vedere il tutto. Il resto? Si fottano.

Quindi, si é ritornati, come avvertivo, al vecchio e caro IE Required sotto nuova forma. Flash Player 9 for Windows required. Bella accessibilità, davvero.
Stiamo parlando di standards o mi sono perso qualche cosa? Che standard é qualcosa che funziona solo su di un OS?
Personalmente non ho dato né darò, stando così le cose, l'assenso all'uso di tale tecnologia andando a raccontare al Cliente la balla della accessibilità garantita. Questione di onestà professionale.


E’ vero che il tiro al Bill Gates è sempre stato, e spesso a ragione, lo sport nazionale. Ma non si dovrebbe dimenticare che Microsoft, in materia di accessibilità delle applicazioni, si è mossa per prima e che solo recentemente Apple e Mozilla hanno migliorato i loro prodotti nel senso dell’accessibilità (consentendo, per esempio, agli screen reader Jaws e Window-Eyes di utilizzare Firefox). Quindi i rimproveri, se ci sono, andrebbero indirizzati ai competitors di Microsoft.


Ma vi peritate di usare tutti i sistemi operativi di cui pure discorrete oppure questo vezzo é solo a carico dei GUI designers?

VoiceOver é presente su Mac OS X da Tiger, id est dal 2005 (non proprio 'recentemente' quindi). Già che siete sul quella pagina date una occhiata a tutto ciò che OS X offre in materia di accessibilità.
VoiceOver fu sviluppato in House di gran carriera proprio per sopperire all'abbandono del mercato Mac da parte dell'unico screen reader dedicato allora disponibile. Nel Giugno 2003 ALVA Access Group annunciò la sua volontà di abbandono del software in questione. Nel Novembre 2003 Apple si mise in moto assumendo ingegneri specializzati per la costruzione di una soluzione in house.
Panther (OS X 10.3) era appena stato lanciato sul mercato (Fine Ottobre 2003).
In altre parole, la versione immediatamente successiva, Tiger appunto, aveva VoiceOver e tutto il resto nel sistema integrato.
Se ci si peritasse di documentarsi su piattaforme diverse dalla propria staremmo tutti un pò meglio, informaticamente parlando.
La posizione di Bertoni circa la accessibilità su Mac é palesemente non informata dei fatti.

Ma, oltre quanto sopra affermato, vi é poi un altro bel problema. L'assunto che dovrebbe essere il Sistema Operativo a consentire

..., per esempio, agli screen reader Jaws e Window-Eyes di utilizzare Firefox


é quantomeno peregrino.
Un OS espone delle API sulle quali i produttori di SW/HW si basano per costruire le loro applicazioni. Le API di OS X sono a disposizione di chiunque dato che la iscrizione alla Apple Developer Connection é gratuita. Apple non ha da permettere alcunché dato che é tutto a disposizione.
Ogni software per OS X può accedere a VoiceOver per il semplice fatto che VoiceOver é un servizio di sistema sempre attivo nel menu 'Servizi'.
Manca all'appello solo la volontà di Devs terze parti. Dove sono quelli di Jaws?

Jaws for Windows (il suo nome completo. Da non dimenticare). Jaws non funziona su Mac se non attraverso ambiente di virtualizzazione (80€ di software di virtualizzazione + Licenza Windows XP + 1GB RAM aggiuntiva per far funzionare in modo fluido la macchina di virtualizzazione. Somma: 240€). Perché Jaws tratta i diversamente abili su Mac come cittadini di infima categoria? Forse perché non investono in una piattaforma con il 12% di market share ritenendola, giustamente, non profittevole? Si sta forse dicendo che i diversamente abili devono essere considerati cittadini a tutti gli effetti ma solo se usano Windows? Insomma, tutti sono uguali ma alcuni sono più uguali degli altri.

(nota: il web site Jaws é quanto di più inusabile possa capitare sul web)


Il fatto che tu continui ad affermare che “Un pixel di differenziazione basta ed avanza” mi fa pensare, non te la prendere, che tu non abbia grandi esperienze concrete con persone con disabilità motorie. Anche se affermi il contrario, continui a dimenticare l’oggetto dell’accessibilità: il disabile. Ti propongo un esperimento: prova ad attivare un normale pulsante di un form (posto ad un pixel di distanza da un altro) con l’emulatore di mouse, le mani dietro la schiena e usando la bocca (con una matita o una bacchetta qualsiasi) per interagire con la tastiera. Non dico che non ci riuscirai, ma forse ti sarà più chiaro il perché le associazioni di disabili motori hanno chiesto di incrementare queste distanze.


Prima, due concetti due dell'ABC del GUI Design.
Hotspot: La porzione del cursore che deve essere posizionata su di un screen object prima che il click del mouse abbia un qualche effetto, a prescindere dal trigger (onMouseOver, onClick a così via) dell'evento.

Hot Zone: Gli screen objects hanno delle hot zones che sono le aree nelle quali l'hot spost del cursore deve entrare per poter ottenere una registrazione di un evento sulla GUI.



la prima immagine mostra una mini navbar con due bottoni così come viene visualizzata dall'utente. 1 solo px divide visivamente i bottoni.





La seconda immagine mostra le hot zones pronte a catturare gli onMouse Events. Ogni button ha i suoi margini sull'asse orizzontale settati a 10px. L'effetto é semplice da realizzare con un pò di CSS padding e margin sul tag a della ul.
Abbiamo ben 20 pixels di spazio di errore in orizzontale. L'esempio mostra come anche lo scostamento diagonale, tipico del non pieno controllo degli arti motori, sia preso in considerazione. Infatti il padding sul tag a si spinge a coprire l'intero ingombro verticale del button invece di accontentarsi di circondare con padding regolare su tutti i lati del rettangolo il link.




La terza immagine é la stessa mini navbar come verrebbe visualizzata se seguissimo le tavole delle leggi da Bertoni indicate.

Le differenze sono sostanziali. In questo ultimo caso abbiamo una perdita di consistenza della UI con autostrade a separare i buttons e conseguente griglia irrimediabilmente persa.

Ciò detto vale anche, ad esempio, per l'ergonomia di uno strumento che usiamo ogni giorno al comupter. La tastiera.

Ciò che più ci preme, in tutto questo, é che la UI rimane usabilissima e consistente (oltre che gradevole alla percezione) per entrambe le tipologie di utenti. Non si sacrifica alcuno sull'altare dell'altro. Questa é al mio paese, diverso a quanto pare da altri, uguaglianza di trattamento. Troppo facile distruggere la usabilità di una tipologia di Utenti per favorirne un'altra. Soluzione sommaria e per nulla aderente ai principi base del buon UI Design.
Se ti fa male un braccio, taglia anche l'altro! Pare dirci questa attitudine.
Che ne direste di usare direttamente Lynx?

Per inciso. Avevo contestato la affermazione riguardo i collegamenti della regola 4. Bertoni cambia le carte e propone come esempio un form button che non é un collegamento.
Il form button deve avere padding maggiore di un tool in quanto é usato in contesti dove si richiede all'Utente una scelta precisa foriera di risultati non recuperabili. Il tipico esempio é la finestra di dialogo della installazione di un software. Sono due contesti di interazione Uomo-Macchina diversi che prevedono diversi approcci all'UI Design.


Sarà certamente che io manchi di esperienza pratica con persone con disabilità motoria ma dall'altra parte non é che si stia meglio in UI Design. Sia detto senza offesa. Ad ognuno il suo campo, per carità!


Torniamo, finalmente!, alla questione fondamentale e alle domande da me poste.
Le risposte date hanno, c.v.d., dimostrato, come se ce ne fosse bisogno, che le norme sulla accessibilità sono state pensate ad uso e consumo delle PA e, in ultima istanza, non devono essere prese in considerazione dal settore business perché le norme non prendono in considerazione quest'ultimo come fattore.
Ma, e questo é il punto, non si va raccontando e sbandierando la necessità di considerare i diversamente abili come cittadini di prima classe al pari degli altri? E, domando, i cittadini di prima classe vanno in giro solo per i siti delle pubbliche amministrazioni? Non avranno anche essi altri desideri, curiosità, insomma necessità simili a quelle degli altri utenti? Oppure si immagina la loro vita relegata tra casa e PA?
Dietro la retorica del terziario avanzato si cela, come spesso accade, un giro di parole che, almeno a me, pare più offensivo del silenzio in materia.
Considerali come uguali, con le opportune specificità, non significa considerare il flusso reale della loro vita in rete e non quella da laboratorio?

La mia domanda mirava appunto a rendere reale la applicazione delle norme sulla accessibilità. Per far questo vi é però bisogno di partire da due esigenze:

  • Le esigenze reali degli utenti diversamente abili in rete

  • Le esigenze del business in rete


Trovare un punto di incontro tra le due. Questo richiedevo, inutilmente purtroppo.

Modificare le norme e renderle meno fondamentaliste tenendo conto di entrambi i fattori non invoglierebbe quei Project Managers di cui abbiamo discorso (se non i commerciali) a portare i blocchi di codice su standards accessibili? Ora come ora essere accessibile significa morire commercialmente per una web application che fa del business la sua raison d'etre. Tra un 'inutile pensare alla accessibilità tanto questo prodotto non sarà mai accessibile a meno di aderire a norme draconiane' a 'facciamolo! costerà fatica ma immagina consegnare un prodotto business oriented che sia anche accessibile!' mi sa che passa una bella differenza. Almeno ai miei occhi.

Questo e solo questo ho richiesto.
Compreso che si é interessati solo alla propria parrocchia (che fornisce il pane ed il companatico e quindi da difendere, per entrambi) e che i miei presupposti sono, purtroppo, esatti, torno ai miei sollazzi personali.


ps. delle ventidue regole comunque sono baggianate quelle in questa sede dimostrate tali. Sarebbe onesto riscriverle cambiando, già che ci siamo, il titolo del post originale.

sabato 7 giugno 2008

Per una accessibilità fallibile. Invito al dialogo

Mi accingo a rispondere ai commenti fatti da Marco Bertoni non per spirito di polemica, che ritengo inutile, ma per cercare, attraverso la dialettica, di circoscrivere un background comune in grado portarci oltre le affermazioni assolute nel territorio della fattibilità.

Una premessa é doverosa. Non mi ritengo 'rivale' di alcuno perché non combatto per primeggiare. Mi limito ad argomentare. Se la discussione si rivelerà proficua, tanto meglio. Altrimenti si tornerà tutti alle proprie attività.

Ribadire la necessità di scrivere codice sintatticamente e semanticamente corretto è utile e propedeutico proprio perché è un atto d’accusa contro chi non lo fa. Quello che tu consideri un “non requisito”, un’ovvietà come la necessità della diagnosi prima del farmaco, per me è il requisito per eccellenza, quello che in se contiene tutti gli altri. Quello più necessario, perché così i medici prima o poi lo capiranno che i farmaci non si prescrivono senza prima visitare il paziente. Certi medici, senza regole e controllo, sono letali. La corretta strutturazione e la semantica del contenuto sono la chiave dell’accessibilità del Web, non si può in alcun modo rinunciarvi.


Mi spiace ma continuo a dissentire e per lo stesso motivo che ci ha visto concordare in altri non remoti tempi.
Mi pare controproducente insistere sugli effetti cercando di correggere questi ultimi invece di intervenire sulle cause. Queste ultime sono da ricercarsi in una commistione di forma mentis ed interessi economici che occorrerebbe almeno identificare per poter poi cercare di mirare nel processo comunicativo e legislativo. Un problema ben posto contiene in sé la sua soluzione, diceva qualcuno ad inizio secolo scorso. Spirito scientifico, certo. Ma é chiedere molto adottare un criterio scientifico in un atto legislativo?
Così come si propone, la norma prende i classici fischi per fiaschi. Ignoro l'analisi del contesto e mi rivolgo agli operatori singoli invece di intervenire a monte sul contesto economico e professionale che genera l'effetto.
Continuiamo a guardare il dito invece di rivolgere lo sguardo a colui che indica, allora. Del resto, scusate la digressione in campi altri, mi pare siamo maestri nel non affrontare mai le cause dei problemi ma limitarci solo alla spazzatura del momento.
Meglio gli inceneritori a valle oppure intervenire a monte sugli interessi nascosti in alto loco e sul substrato culturale dei singoli con opportuna educazione allo smaltimento rifiuti?

Ripetiamo. La adesione agli standard non é opzionale ma é fondamento del mestiere che si sta svolgendo. É l'esame di ammissione alla professione.
Ma come fare a discernere la pigrizia ed il pessimo professionista dalle esigenze commerciali e di Project Management che prediligono frameworks custom-made di migliaia e migliaia di righe di codice alla base di prodotti, passati presenti e futuri, forniti a grosse aziende?

Rimane quindi, come soundtrack inascoltata, il problema economico del porting di blocchi consistenti di codice. Cui prodest?
(Il commerciale si accontenta del bollino blu che basta ed avanza a vendere il prodotto. Non ci raccontiamo favole)


Un’azienda privata può decidere se perseguire o meno una politica di responsabilità sociale (che, detto per inciso, offre un ritorno di immagine che piace anche ai famigerati commerciali). Nessuno di noi può sindacare le scelte di costoro. Ma per una pubblica amministrazione il discorso cambia. Se siamo d’accordo che le amministrazioni pubbliche esistono per servire tutti i cittadini, e se concordiamo sul fatto che un disabile è a tutti gli effetti un cittadino come gli altri, allora non mi “fermo a riflettere”. Se Google vuole usare iframe come se piovesse, nessun problema: perderà una percentuale di utenti non vedenti. Peggio per Google. Ma se un’amministrazione discrimina un gruppo di utenti utilizzando una tecnologia non accessibile, questo è inaccettabile.


La risposta conferma la mia obiezione senza darlo a vedere.
La argomentazone primaria é infatti data dal caso delle Aziende di Servizi Pubblici che, come da me affermato, sono giustamente costrette a rispettare queste norme.
La mia obiezione, ripeto, dà voce a tutt'altra categoria, business, che ha tutt'altri criteri per operare. Qui i campi ove entrambi lavoriamo influenzano, ovvio, le nostre prospettive sul tema. Infatti, ciò che vien detto circa la perdita di percentuale cliente non tiene conto di una regola basilare del business. Un cliente smette di essere profittevole quando lo sforzo per accontentare le sue richieste supera il ROI che da questi ci si attende. Insomma, dove é il margine?
Sarebbe peggio per Google inseguire questa nicchia. Sarebbe un suicidio commerciale.
Dovunque, non solo in rete, si può osservare questo semplice criterio all'opera. Dirigetevi in qualsiasi libreria della GDO (Feltrinelli, FNAC etc) e date una occhiata al catalogo (sia quello verticale sia quello orizzontale) ed al comportamento dei commessi istruiti ad hoc.

Brutalmente, mettersi ad annichilire un servizio innovativo capace di ingenerare effetto halo e, dunque, di operare un lock-in cognitivo al brand con la applicazione della Legge di Metcalfe e conseguenti ricadute positive sugli introiti pubblicitari, mi pare non irreale ma una emerita sciocchezza se, come pare lapalissiano, siamo ancora nel regime chiamato capitalismo.

Continuo a credere che si parta da due posizioni differenti (non divergenti a priori, sia bene inteso). Una prospettiva business oriented ed un'altra public service oriented. Invito al dialogo su queste differenze che personalmente rispetto e riconosco nella loro specificità. Non so quanto valga la contraria.

Ma certo. E’ evidente che la sottolineatura dei collegamenti è utile esclusivamente nei blocchi di testo. Anche il daltonico conosce le convenzioni di design (i menu ecc.). E’ una cosa che, onestamente, davo per scontata. Nessun esperto di accessibilità sano di mente chiede un’orgia di sottolineature.


Bon. Le note però non parlavano dei blocchi di testo ma di generici collegamenti. Io so a cosa si riferisce il tutto ma i lettori dei tuoi requisiti lo sanno? A giudicare dai posts nei forum e nei blogs pieni di zeloti che invitano all'underline dovunque, alla accessibilità confusa con la usabilità (yep. qualcuno confonde i temi della accessibilità con quelli della ottimizzazione delle risorse in caricamento...) etc, mi sa che é meglio esser chiari su questo punto. Si rischia di generare eserciti della salvezza bravi ad obbedire ai decaloghi ma male attrezzati nel pensiero autonomo.


Le ricerche di eyetracking dimostrano che finestre pop-up, banner lampeggianti, colonne di advertising ecc. sono bellamente e sistematicamente ignorati dagli utenti. Lo stesso Nielsen propone un approccio non etico: “making the ad look like content”.

Ma non capisco cosa tu veda di male nella sacrosanta regola che impone di evitare un attacco di epilessia al prossimo. Il requisito cinque dice solo questo, non proibisce banner o pubblicità. Attenzione a non fare il solito terrorismo sui requisiti.

Comunque abbiamo capito che le argomentazioni a favore della pubblicità lampeggiante e “esplosiva” sono inesistenti. Ci si chiede perché si continui a produrla. Un amico che lavora in pubblicità mi ha confessato che spesso a chiedere pop-up, animazioni e banner sono i clienti “ignoranti” e loro si adeguano. Perché contraddire un idiota che paga?


A dirla tutta non abbiamo visto un bel niente circa la insesistenza delle argomentazioni a favore della pubblicità, anzi (a giudicare dal suo uso effettivo). Né mi pare che dalla risposta si evinca una argomentazione contraria con opportune proposte alternative scalabili a livello di business se non la mera constatazione di quanto da me già affermato e cioè il fenomeno dell'ad-blindness.

Siamo ancora in attesa di trovare un modo alternativo per guadagnare dindi attraverso la pubblicità. Se coloro che bollano la pubblicità 'esplosiva' hanno trovato il Santo Graal del nuovo advertising Microsoft è in loro attesa con assegno in bianco firmato.
In attesa del mito ci dobbiamo accontentare di solo tre possibilità. Banners tradizionali, Ad-sense e in-context-ad camuffato che è peggio ancora del male che vorrebbe curare (come Bertoni giustamente annota) in quanto renderebbe di fatto inusabile la intera mole di informazioni di internet propagando rumore misto a contenuto.

Battutacce a parte, continuo a ribadire il mio invito a tener conto di fattori diversi e, spesso, contrastanti. Se si bolla come non esistente una delle due posizioni come si giungerà ad una strategia capace di essere, insieme, efficace e rispettosa delle esigenze di tutti gli attori?


Nessuna requisitoria da parte mia, si tratta di interpretare le richieste di un requisito di legge. Personalmente non ho nulla contro i layout fissi


Devi usare un layout liquido (elastico).

Non mi pare una interpretazione. É piuttosto, in termini di linguistica, una normativa segnalata con tanto di imperativo.
Un invito alla interpretazione sarebbe stata qualcosa di simile a
Si dovrebbe usare, considerate le problematiche tecniche, la aderenza alla piena compatibilità cui qualsiasi web site deve obbedire e la analisi della usabilità, un fixed layout.

Questo è un modo decente per comunicare una esigenza lasciando spazio all'atto interpretativo constestualizzato.

Secondo me esageri a scomodare Platone. Questi requisiti non chiedono nulla di impossibile e non sono nella direzione sbagliata, sono solo perfettibili come ogni cosa umana. Io scelgo di provare a migliorare le cose dall’interno.


Non ho mai detto che siano impossibili (l'iperuranio non é impossibile, solamente ideale. Un type logico assoluto). Dico che applicano ciò che va bene per una parte al tutto. Pars pro toto. Questo si chiama assolutismo che é ciò che sto invitando ad evitare.
Ho lodato Bertoni e continuo a farlo per il suo impegno nel cercare di migliorare, nella sua sfera di influenza, la situazione attuale sulla quale, come si può leggere altrove, siamo in perfetto accordo.
Le mie note sono, appunto, a margine in quanto tendono a segnalare la esistenza di alcune problematiche e non vogliono essere se non una 'critica' nel senso classico del termine, una analisi, una proposta. 'Critica' non è invito allo sbarramento unilaterale ma la voce dell'altro. In questo caso, di esigenze altre.

Questo non è più vero con il Flash Player 9. Attenzione a non dare informazioni inesatte ;).
Comunque, come ho detto in altra sede, è sbagliato confondere l’accessibilità del filmato Flash in sé con i limiti dell’implementazione cross-platform e cross-browser dei plug-in.


ahem.

Chiedo scusa ma sono utente Mac e Linux (debian) ed uso Windows quotidianamente per double-check. I miei problemi sono pratici e richiedono risposte concrete non Adobe PR.
Seguo con attenzione gli sviluppi multipiattaforma senza cedere alla via facile del numero.



Confondere l'output con il framework che rende possibile il delivering dell'output è sbagliato?
Come si conta di visualizzare un swf senza il player che lo rende visualizzabile?
Come si ha un bicchiere d'acqua dal rubinetto senza la rete idrica?
Senza una lingua esistono le parole?
Possiamo scrivere una funzione senza un sintassi formale di programmazione?
E così via.

Andiamo.

Il requisito ventuno è, credo, l’unico che è stato richiesto a gran voce da chi rappresentava i disabili motori. Niente “bignami frettoloso”, quindi, ma attento ascolto delle istanze degli utenti disabili. Non dimentichiamo mai chi sono i destinatari dei benefici arrecati da questi requisiti. Le persone disabili. Ti assicuro che un pixel di distanza tra un pulsante e un altro per chi ha scarso controllo del sistema di puntamento è una cosa delinquenziale. Qui non si tratta solo di percezione visiva delle differenze, ma di destrezza manuale.

Se vogliamo parlare insieme di accessibilità dobbiamo sempre porci dalla parte del disabile, e cercare di capire le peculiarità di ogni disabilità.


Nope. Esiste un concetto vecchio come il bacucco (lo trovi nelle prime Apple HIG - Human Interface Guidelines) che si chiama Hotspot. Un pixel di differenziazione basta ed avanza se si ha cura del layout degli hotspot. Se poi il designer dorme e cazzeggia allegramente con i tutorials sul css, le regolette del SEO etcetera invece di studiare l'abc del GUI design, il problema non é del pixel ma del designer. Diamo una svegliata ai designer e tutto verrà di conseguenza. Limitiamo il 'designer' ai corsi regionali e scuole dove si limitano ad insegnare a cliccare bottoni in Dreamweaver e Fireworks ed ecco che abbiamo questi risultati. Ancora una volta problemi di formazione e forma mentis.
Che poi occorra mettersi nei panni del'utente in questione, é assolutamente fuori discussione. Non saremmo neanche qui a discutere di tutto questo altrimenti.

Se, notizia di ieri, il sito dei carabinieri vince un premio come miglior design usabile ed accessibile mi sa che vi è qualcosa che non va nella struttura, altro che aderenza agli standards. Se posso aderire agli standards del codice e, nel contempo, produrre un flusso interattivo da calci in culo agli utenti, possiamo dire che la aderenza agli standards da sola non basta ad assicurare un bel nulla?

venerdì 6 giugno 2008

L'Accessibilità dell'iperuranio. A quando quella reale?

Colgo la occasione di un divertente articolo di Marco Bertoni per affrontare alcuni temi a me cari riguardanti la 'Legge Stanca' e il problema della Accessibilitá così come si é andato configurando.
Bertoni, nell'articolo citato, parafrasa i punti salienti della Accessibilitá e mi permetterá l'uso delle sue parafrasi per apporre loro alcune note a margine alla 'Legge Stanca' indirizzate.

Come esergo vorrei dire che concordo con la intenzione di Marco Bertoni ma avrei preferito una chiara prefazione alle 'regole' in grado di chiarire che ciò di cui si discorre è necessario analizzarlo caso per caso e, su tutto, non perfettamente applicabile a tutti gli ambiti del Web UI Design ma solo al campo preso di mira maggiormente dalla 'Legge Stanca' e nel quale maggiormente lavora l'autore dell'articolo, cioè le Pubbliche Amministrazioni che, per fortuna, non sono l'intero web.

Questo requisito ti chiede di scrivere codice pulito, senza errori sintattici e semanticamente corretto. Che significa? Significa che bisogna finirla con il codice spazzatura ;).


Il primo requisito è un non requisito dato che scrivere codice senza errori sintattici fa parte delle best practices. E' come dire ad un dottore che deve visitare un paziente prima di prescrivere un qualsivoglia farmaco. É norma deontologica che non abbisogna di essere ribadita. Il fatto che accada il contrario non toglie la validità formale e logicamente antecedente della norma. In poche parole, la norma enuncia non un requisito ma una requisitoria. Un atto di accusa verso coloro, tanti, che hanno una formazione non al passo coi tempi.
In questo ultimo caso, si sta parlando al vento in quanto chi non cura la sua formazione sua sponte o per esigenze di mercato non coglierà a maggior ragione nemmeno questo invito dall'alto imposto. In breve, a chi si rivolge questa requisitoria?

Ma, ed è questo il punto che svilupperò più approfonditamente in altro post, non è sempre colpa del coder il risultato che vediamo. Spesso, molto spesso, viene ordinato di riusare porzioni di codice per ottimizzare sul tempo e quindi sul margine di guadagno. Il problema é quindi non di chi scrive il codice ma delle sezioni commerciali che obbligano a tempistiche strettissime promettendo mari e monti nei canonici 7 giorni della Creazione. Solo quando si sarà parlato non ai coders ma ai 'Commerciali' si riuscirà ad ottenere qualcosa. Ma, si sa, il 'Commerciale' conosce solo una lingua. La domanda è quindi, quale vantaggio economico può portare migrare consistenti blocchi di codice verso la accessibilità?
In breve, il punto in questione è un falso problema che non individua precisamente il suo target. Da rifare.

Questo requisito ti proibisce di utilizzare i frame.

Diciamolo: i frame sono brutti. Fanno tanto web anni novanta. E rompono le scatole agli screen reader. Roba vecchia e dannosa insomma. E cosa dire dei frame in linea (gli iframe)?...


Gmail usa un mare di iframe. Perchè? Perchè sono necessari al funzionamento della web application e constribuiscono a diminuire i tempi di attesa aumentando, conseguentemente, la usabilità globale della stessa. Aderire, senza residuo, alla norma porterebbe una usabilità minore e a funzionalità problematiche da implementare e fornire.
Certo, possiamo ben usare noi il DOM traversal+Ajax e ottenere quanto é da ottenere con divs ma, nondimeno, non mi sentirei di escludere apriori gli iframes quando possono dare una mano a gestire dei servizi risolvendo problematiche di HTTP request.
Se per aderire ad una regola frettolosa devo rinunciare ad offrire una piena usabilità della web application mi sa che occorre fermarsi a riflettere.

Se elimini la sottolineatura per i collegamenti e li differenzi dal testo normale solo grazie al colore, puoi creare notevoli problemi a chi è affetto da cecità ai colori, che non sarà in grado di distinguerli. Questo è un esempio per chiarire che non devi usare solo il colore per assegnare significato all’informazione.


L'informazione è data, in un layout, dalla differenziazione all'interno della griglia. In altre parole, il posizionamento fornisce informazione sulla funzionalità. Basta osservare una qualsiasi GUI su windows o Mac o Linux o Symbian o... per rendersi conto che gli strumenti sono suddivisi e posizionati in modo consistente per fornire una differenziazione percettiva immediata in base alla loro localizzazione. La stessa consistenza che occorre raggiungere, al livello di usabilità, anche sul web. Quindi sarebbe più opportuno dire di non giocherellare con il posizionamento degli elementi della User Interface e seguire le convenzioni come prima regola. Il resto viene come ridondanza. Una pagina piena di links ove il menu si confonda con il contenuto della pagina, anche se fosse pieno zeppo di underline non verrebbe immediatamente percepito nella sua funzione primaria. Con buona pace delle buone intenzioni.

Questa norma fomenta la lettura delle regole come mero elenco da spuntare di cui ho già scritto in precedenza. La verità è che il buon vecchio Web Designer deve essere innanzitutto un designer e conoscere a menadito le regole del buon design che non è cazzeggiare col Photoshop (o Fireworks o altro) ma studio degli spazi, analisi comunicativa, ridondanza accorta, canale di trasmissione, percezione, semiotica etc. Solo quando i 'web designers' si attrezzeranno con le competenze che ogni designer da per scontato varrà insistere su queste minuzie, ma allora sarà inutile perchè il problema non sussisterà .
Prima la struttura poi il dettaglio. Il dettaglio senza struttura informativa è sempre rumore. Rumore sottolineato ma pur sempre rumore.

Se ti piacciono le gif animate e le scritte lampeggianti… beh… ecco… contento tu… Ma stai molto attento alla frequenza di lampeggiamento, altrimenti rischi di danneggiare seriamente chi soffre di epilessia fotosensibile. Oltre ad infastidire tutti noi.


E il pane a coloro che lavorano per la web application chi lo paga senza la pubblicità?
Insomma, questa è una delle regole da prendere cum grano salis. Si adatta benissimo ad alcune tipologie di web site (modello 'si ma chi siamo, si ma quanti ne siamo, si ma poi che facciamo? Ci scrivi una letterina?') ma di certo non a tutte. Potrebbe andar bene in un mondo ideale ma nel mondo reale il business primario è la Pubblicità. Piaccia o meno è così. Amen.

Norma quindi da scartare se non in presenza di Siti Istituzionali, Portfolio Web Site e siti personali. Il resto continuerà ad ignorarla per il semplice motivo di cui sopra. Se i propugnatori della Legge Stanca firmassero assegno mensile a carico di questi ultimi a compenso delle perdite economiche subite dalla eliminazione dei banners potremmo vedere qualche risultato. Per ora l'unica speranza di vedere diminuire le animazioncelle nei banners è data dalla constatazione che gli utenti sono diventati ad-blinds. Se vedremo quindi un tendenza contraria sarà dovuta non al rispetto delle regole della accessibilità ma alla sostituzione dei banners con qualcosa di più efficace in termini di raggiungimento degli obiettivi economici.

Devi fare in modo che il testo possa essere ridimensionato (ingrandito). Anche con Internet Explorer 6 e precedenti (menu Visualizza > Carattere).
Quando il carattere è ingrandito non deve esserci sovrapposizione tra le diverse parti della pagina. Anche ridimensionando la finestra.
Devi usare un layout liquido (elastico).


Alla requisitoria contro il fixed layout rispondo con tre obiezioni:

  • Problemi tecnici (per chi non lo conoscesse, il Visual Design Lead di Google).

  • Controllo del Layout da parte del Designer.

  • Problemi di leggibilità della informazione


Le norme sulla Accessibilità dovrebbero essere studiate in base alla situazione reale e non al mondo dell'iperuranio. Perchè il legislatore non mette un pò del suo zelo nello scrivere una lettera ufficiale a Microsoft invitandola a rispettare gli standards invece di legiferare a vuoto in direzione sbagliata?

Un liquid layout non è ipso facto accessibile (perchè mai dovrebbe esserlo?) e spesso si preferisce, per le tre obiezioni di cui sopra, optare per una soluzione fixed che è vantaggiosa in termini strettamente economici e di controllo del layout. Affermare che il fixed layout è da scartare a priori è quanto meno affrettata come proposizione (voglio esser buono e non pensar male circa le competenze nel campo del supporto browser agli standards dei consulenti interpellati in vista della Legge).
Per inciso, lo stesso ALA usa un fixed layout e nemmeno centrato. Se Zeldman in persona opta per questa via qualche dubbio da parte del 'legislatore' ce lo possiamo attendere. O no?

Immaginiamo poi un bel caso di un layout liquido a due colonne ove le colonne di testo della content area si estenderanno per il 90% della viewport. Dobbiamo ricordare l'abc della usabilità circa il numero di caratteri massimo su di una riga visualizzabile a video dall'occhio umano?
Immaginate lo stesso caso su di un monitor a risoluzione 1600px orizzontali.
Una catastrofe della usabilità

Un bel po’ di gente naviga con gli script disabilitati. Devi fartene una ragione. Quindi devi garantire che le tue pagine siano utilizzabili anche da chi ha disabilitato gli script, gli applet o altra robaccia 2.0.

Ma il legislatore non è folle. Se per motivi religiosi ('grassetto nostro) non puoi fare a meno dei tuoi script inaccessibili, allora dai una spiegazione testuale della funzionalità (che il 15% degli utenti si perderà ) e, come impone il requisito Tre, fornisci un’alternativa testuale equivalente.

Hai voluto lo script? E ora pedala.

Gli script però non sono il demonio. Basta leggere PPK per capire che con un po’ di competenza si può fare tutto ciò che si vuole.


Di certo gli 'script' (ma poi che vuol dire 'script'? Anche php, ruby, python sono scripts e necessitano di stare dove stanno. Nel corpo del DOM) non sono il demonio. Altrettanto certo è che questo è un problema da affrontare con molta attenzione e parsimonia di giudizi sommari da caccia alle streghe visto il vettore che sta portando le web applications (o RIA che dir si voglia) ad essere papabili sostituti delle Desktop Applications. Il libello citato è importante (non il migliore in materia) e pieno di indicazioni utili ma in applicazioni complesse (tipo Yahoo Mail) vi è poco da accusare di religiosità fondamentalista in modo aprioristico e generico. Il codice JavaScript è in line perchè ha da essere inline. Se a questo punto le strade tra usabilitá ed accessibilitá divergono occorre affrontare il problema con occhio attento al rispetto di entrambe le necessitá e non sacrificare la usabilità sull'altare della accessibilità.

Devi garantire che le funzionalità (per esempio un menu) e le informazioni (il testo) presenti negli script, negli applet, nelle animazioni Flash siano direttamente accessibili alle tecnologie assistive.

Questo significa che devi installare uno screen reader e provare a navigare all’interno della tua animazione Flash. Se qualche “esperto” ti ha detto che Flash non puà essere accessibile, mandalo al diavolo e digli di leggersi la letteratura in merito e questi articoli.


Ironia della sorte, il famigerato articolo linkato è in Flash e non supporta il mouse scroll risultando quindi non usabile dagli utenti 'normali'. Vi è poi scritto a chiare lettere che Accessibilità con Flash è sinonimo di accessibilità con Flash su Windows.

All accessible Flash content must be tested on the Microsoft Windows platform.
While there have been recent improvements to the Apple Macintosh OS 10.4
release (Tiger), includinga built in screen reader called VoiceOver, the Flash
Player does not support this screen reader.


In altre parole, su Mac e Linux ce lo si prende in saccoccia. Ora, una tecnologia si dice aderente agli standards quando aderisce, in tutti gli ambiti in cui si usa, a questi ultimi. Flash può, con molto lavoro, essere accessibile ma solo su Windows per cui non può definirsi accessibile tout court a meno di non tornare al vecchio 'IE Required' sotto mentite spoglie. Un rispetto dell'utente un attimino di parte e, cosa che non guasta, sulla piattaforma che più ignora volutamente e bellamente gli standards che non siano i suoi. Meglio JavaScript inline compatibile su tutte le piattaforme che Flash solo su Windows. Checchè ne dicano gli 'esperti'.

Ah. Questo ਠil mio preferito. Ho pure contribuito a correggere un errore presente nella prima versione dell’enunciato.

Devi sempre considerare il fatto che per chi ha difficoltà nel controllo dei dispositivi di puntamento ਠmolto difficile selezionare il collegamento o il pulsante giusto se sono troppo ravvicinati. Immagina la frustrazione quando dopo uno sforzo enorme ti scappa il clic sul pulsante sbagliato. Quando ti fischiano le orecchie, pensa alle maledizioni che ti mandano gli utenti per questa mania di appiccicare tutto. Saranno per caso carenze affettive?

La soluzione ਠsemplice: distanziare in modo adeguato pulsanti dei moduli, campi dei moduli, liste di collegamenti e, in generale, tutti gli oggetti attivi all’interno della pagina.

Io aggiungo che anche un’interlinea superiore a quella predefinita ਠmeglio. Ma so che non tutti sono d’accordo: evidentemente c’ਠchi ama i muri di testo che si vedono cosà spesso negli orribili portali di molte aziende e pubbliche amministrazioni italiane.


Differenziazione percettiva e non allargare gli spazi all'infinito. Qui é il problema.



Se analizziamo la GUI del Finder di Mac OS X, come esempio illustre, vedremo che tra una icona ed un'altra della toolbar vi è 1px di spazio ma il tutto é visivamente ben differenziato. Non occorre una spazio che costringa l'utente a fare viaggi con il mouse per spostarsi da un tool ad un altro con il risultato di diminuire la sua produttività e sminuire la usabilità del tutto, occorre invece una rimarcata differenziazione.
Amazon, dal canto suo, usa un 1px solid border con una freccia a fare da ridondanza.



Esempi classici per mostrare quanto le regole siano distanti da una effettiva presa sul reale.

É in questa attitudine al bignami frettoloso che la Legge Stanca rappresenta che dobbiamo poi ricercare le cause della accessibilità come mero bollino e elenco di comandamenti da osservare.

Mi ripeto invitando ad un mutamento di forma mentis che, solo, può assicurare un proficuo avanzamento negli studi in questo settore tanto controverso. Collaborazione e dialogo da parte di tutti i professionisti interessati e non la torre di avorio degli 'specialisti'.
Non decaloghi ma discussioni.

martedì 3 giugno 2008

Touch User Interface. Uno sguardo al laboratorio di culturedcode

Primi passi della versione per iPhone di Things, ottima applicazione GTD per OS X.
Primi passi nel mondo del Touch User Interface Design. Molti problemi, diverse soluzioni.



Le prime impressioni di culturedcode sulle difficoltà di sviluppo di una applicazione che interagisca secondo patterns comportamentali diversi dalle più tradizionali Desktop Applications e che, nondimeno, si propone di non far rimpiangere la 'comodità' di queste ultime.