Visualizzazione post con etichetta UI. Mostra tutti i post
Visualizzazione post con etichetta UI. Mostra tutti i post

lunedì 5 ottobre 2009

Commentaries on "The Law of Simplicity n°2"

What follows is the first of a series of commentaries on Maeda's "Laws Of Simplicities".

I hope to make some Maeda's misunderstandings about "organization", "simplicity", "meaning" and "context" clear raising some questions, suggesting different research paths and, when and if the case, agreeing with him.

I ask clemency for my bad english in advance.

2 - Organization makes a system of many appear fewer


Yep. It is true, in a meaning. False in another.
Organized systems are inclined to behave as a whole, where all the inner differences are annihilated for the profit of a constant (the organization rules). Look at totalitarisms and dictatorships for an example on how true it is this. Star Trek's Borgs are media examples of the same principle.

Ants are inclined to behave as a whole. Every ant has a precise role in the march. They do very specific tasks, and only these. Everyday. For the whole life.

Tick's life is simple. Wait for the host. Jump upon it. Store eggs in it. Die. Organized and simple, of course¹.

But, there is a "but", the more intermediate levels (links between the parts of the system) the system has, the more structured is, the more noise it produces and so it becomes less and less effective and more bureaucratic. In this sense, organized systems are noisy systems. Byzantine system. 2nd Thermodynamic theorem still applies.

Cybernetics teaches us that a message just emitted is already attacked by noises. The more distance it travels the more noise it attracts. I say to you "hi there". You say to a 3d "hi". The 3d says to a 4th "buh!". The message is noise now. Humans are not abstract machines (ok, i concede some *cough couch* societies do hope and work to makes them so) so they do not pass on the message as it arrived. Every intermediate level stops the message, makes something with it, tends to stabilize itself as an hub and only then (if) release it on bail.


As everyone can see in everyday life, every strictly organized enterprise lacks speed, adaptability, innovation and becomes a bureaucratic pyramid making money only by means of managed assets, acquisitions or monopoly position.
By contrast, small, disorganized but active startups innovate.
Take 3 people, each one with its strengths but willing to help each other to reach the goal and you'll have a more vital enterprise than organized system with its accounting, project manager, art director, UX Designer, IxD, web marketing guru and so on.

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

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

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.

domenica 25 maggio 2008

Flow. Ovvero l'UI Design non é semplice belletto

Dopo anni ed anni di hype, attese, rinvii, closed beta, é giunto finalmente il tanto a-priori decantato Flow. Client FTP, si diceva, destinato a dare una svegliata alla nicchia di mercato in questione.

Le reazioni degli utenti sono state immediatamente divise tra coloro che subito se ne sono innamorati, tessendo le lodi della GUI e dei suoi dettagli curati, e coloro che, invece, hanno cominciato ad indicare in direzione dei suoi innumerevoli bugs e del marketing hype attorno alla applicazione spingendosi fino alla posa pseudo-geek della esaltazione vuota della mera funzionalità a scapito dei dettagli grafici della GUI.

Diciamo subito che ingenerare hype non è ipso facto male se a questo segue un prodotto degno del battage pubblicitario. Non concordo, né mai concorderò, con coloro che, per spirito di illusorio elitarismo, tendono a denigrare senza fondamento un prodotto, qualsiasi prodotto, solo in base ai riscontri di marketing.

Non é poi affatto male considerare una applicazione anche dal punto di vista di mera cura dei dettagli grafici. E' un elemento fondamentale nella User Experience e non va mai tralasciato (come spesso vedo fare, su Windows soprattutto).

Il problema qui è che a tutto questo hype e alla innegabile cura dei particolari non corrisponde un prodotto all'altezza. Questo, sia bene inteso, non per gli innumerevoli bugs che affliggono l'applicazione (siamo oramai abituati ad essere beta testers paganti) ma per una scelta ben precisa di Interface Design che, pretendendo di innovare, butta nel cestino la usabilità.

flow.png

L'approccio mono-window che Flow persegue non si adatta al task per il quale si propone che é non la semplice esplorazione e manipolazione di cartelle in remoto ma la interazione tra la copia locale e quella in remoto degli stessi files.

Storicamente questo approccio ha un genitore che possiamo vedere in azione in qualsiasi software destinato alla operazione di diff/merge su files.

Apple FileMerge, ad esempio.

filemerge.png

Qui il file viene comparato linea per linea con il proprio antecedente o conseguente in cerca di variazioni che si andranno opportunamente a incorporare nella versione che andremo a considerare definitiva.

Il task che viene associato ad un client FTP è proprio quello della navigazione sincronizzata, un primo controllo delle versioni tra locale e remoto, l'upload ed il download di files verso e da remoto. In altre parole, la interazione tra locale e remoto. Per questa semplice ragione, Flow fallisce il suo compito in quanto costringe l'utente ad avere un'altra applicazione esterna aperta ed attiva per portare a termine con successo quello che dovrebbe essere il suo fine primario.
Occorre infatti avere una finestra del Finder in supporto altrimenti l'utente sarà impossibilitato a fare nient'altro che operazioni sulle cartella in remoto a partire dalla cartella in remoto, in modo chiuso ed esclusivo.
L'utente quindi si trova intrappolato nella applicazione e per trovare una via efficace di uscita dall'impasse deve ricorrere ad ancore di salvataggio esterne.

Questo è cattivo Interface Design in quanto una cosa è cercare appoggio in applicazioni specifiche per task specifici che esulano dal compito primario della applicazione (aprire un file testuale per modificarlo dal client ftp stesso, ad esempio), un'altra é ricorrere ad aiuti esterni per portare a termine la operazione primaria per il quale un client ftp esiste.

Scrivo questo dopo aver tenuto Flow in test per tutto il periodo di prova e ciò che salta immediatamente all'occhio é confermato nell'uso quotidiano.

Innovare nell'Interface Design non é 'famolo strano' né prendere, come in questo caso, un paradigma da una applicazione (in questo caso il Finder stesso, le iApps etc) e trasportarlo senza residui su di un task diverso.
La contaminazione, quando possibile, occorre filtrarla e tirar fuori solo quello che può essere utile rigettando ciò che, a livello di usabilità, ingenera disfunzioni nella efficacia della UI.

Ben venga dunque la cura dei particolari della UI ma che venga dopo un attento studio sul pattern comportamentale dell'utente della propria applicazione e sul task e sub-task che occorre portare a termine.

Molto rumore per meno che nulla, potremmo dire.

mercoledì 21 maggio 2008

I Web Standards limitano che?!

Ora, non so se dettata da non informazione, da incomprensione della storia del WSG
oppure da fallacia logica ma sento sempre più spesso dire che la 'adesione totale agli standards limita la 'creatività* del web designer'.


Sia detto senza mezzi termini. Questa è una sciocchezza inaudita.

Addossare la colpa di dover ricorrere a fix vari per visualizzare .png con canali alpha a quel bug ambulante chiamato IE, rendendo di fatto non valido il codice, é confondere la causa con l'effetto.Non è che usando gli standards il web site ha problemi di visualizzazione in IE ergo gli standards 'limitano' il nostro lavoro ma siamo costretti ad usare fix perché Microsoft non aderisce agli standards.

Se non si é capaci di implementare una Web UI senza strafare e non tenendo conto delle limitazioni del software che andrà a renderizzare la UI, non é di certo colpa del WSG ma di chi crede che il web design sia 'graficare' e non costruire un framework comunicativo basato su la diffusione di determinate tecnologie con i propri limiti ove il contenuto possa essere valorizzato ed usato. Ed anche, certo, delle software house che se ne fregano di standards condivisi perché cercano il lock-in e, quindi, tentano di limitare quanto più possibile il medium all'uso delle proprie tecnologie.

Si può costruire benissimo una forchetta con manico distorto. Sarà di certo 'originale'. Ma poi sarà usabile nel contesto appropriato? Questo é quanto si cercava di dire altrove riguardo la forma mentis e la progettualità. La usabilità é il fondamento del web design in quanto prende in considerazione, sin da subito, il medium nel quale questo design andrà a vivere.

L'opera che, nel corso degli anni (chi di voi ricorda le prime battaglie nel lontano 1998. Gasp! Son proprio vecchietto), il WSG e tutti noi abbiamo svolto costituendo vari gruppi di pressione, alzando polveroni, chiamando le software houses a rispondere delle loro mancanze è di fondamentale importanza e non solo per il ristretto nugolo degli operatori del settore.

E' di capitale Interesse anche per il cliente. Usabilità, accessibilità, aderenza agli standards assicurano che ciò che si vuole comunicare, il prodotto che si vuole vendere, giunga a quanti più potenziali clienti possibile e che il medium che permette questa trasmissione sia pienamente godibile. Un cliente che chiude la finestra del browser perché non é riuscito ad orientarsi nel web site é un cliente perso. Un cliente perso é un cliente in meno sul libro contabile di fine anno.

Il web é business non galleria d'arte. Il business si nutre di clienti. I clienti sono, con varie periferiche, alla ricerca di informazioni. Le informazioni devono essere trovate dai clienti e presentate, su tutte le periferiche usate dai potenziali clienti, nel modo più usabile in modo da passare alla vie di fatto dell'acquisto (on line o off line, non importa).

Fino a prova contraria questo è quanto colui che commissiona un web site vuole sopra ogni cosa. Il belletto serve solo per attirare le allodole.

Questo è uno degli scopi del WSG. Invece di lasciarci limitare da lock-in non sistemici, far pressione su chi di dovere perché eliminino i limiti posticci (quelli sistemici essendo ineliminabili). Diffondere la cultura del medium e non il far west del 'cane sciolto'. Aumentare la consapevolezza di un ecosistema complesso e destinato ad influenzare profondamente il nostro modo di esperire la vita.

Come si pretende di affermare la propria professionalità se si vede nel web design solo il lato belletto senza interrogarsi sul medium stesso, le sue finalità, la sua storia, i suoi limiti e le sue potenzialità?

Ma al cliente cosa gliene importa? Ci si potrebbe domandare.

Ma allora come pretendete di affermare una professionalità diversa dal semplice cliccare i bottoni, come il cliente tipico del freelancer vede questa figura, se non mostrate che il vostro lavoro è in diretta e fondamentale relazione con il business del cliente e non semplice accessorio, rispondo.

Se non glielo dite voi, come fa a venirne a conoscenza? Come fate a definirvi esperti della comunicazione (nel web) se poi non sapete comunicare la vostra professionalità?
Come pretendete di vendere i vostri servigi se non comunicate quello che essi possono fare per il potenziale cliente? Insomma, questo è l'abc del marketing!

Quel che più mi meraviglia di tutto ciò é che, spesso, viene da coloro che da poco sono entrati nel business, dai freelancers 'di primo pelo' (nessuna offesa né giudizio di valore ma semplice riferimento agli 'anni di servizio' e alle dinamiche di mercato) e che, dunque, avrebbero tutto l'interesse ad affermare la specificità di questo mestiere, la profonda conoscenza delle dinamiche del web, della comunicazione nel medium in oggetto. Quelli di noi la cui professionalità non abbisogna di essere ribadita e che lavorano con target clienti che queste cose ben sanno non avrebbero alcuna necessità di difendere queste motivazioni.

Eppure siamo qui a farlo.



*lasciamo perdere una definizione di 'creatività' ma mi sarà permesso arguire che, in fase di studio prima ancora che di realizzazione del mockup, non ci vuole molto per trovare vie alternative che, spesso, risultano originali. Del resto, come sanno bene i matematici, la risoluzione di un problema è spesso più creativa del semplice andare a briglia sciolta. Spesso. nel cercare di superare un ostacolo, si trovano sentieri inesplorati.

martedì 20 maggio 2008

In-car Internet. Sarà usabile?

Ne sentivamo discutere da un bel pò. Sempre in stadio prototipale a dar mostra di sé e mai realizzato in un prodotto destinato al consumo.

Infine ecco giungere In-Car Internet, Internet in Auto.

BMW, Chrysler ed altri ancora sono già in linea di produzione.

Dopo le periferiche di convergenza, palmari e compagnia, nuove sfide per i Web UI Designer si profilano all'orizzonte. Come progettare, implementare Interfacce Utente destinate all' In-Car Internet?

Cominciamo col dire che la stessa locuzione 'Internet in Auto' nasconde un 'inganno' in quanto lascia credere che Internet, così come lo conosciamo e come siamo abituati ad usarlo, sia lo stesso che, senza residuo alcuno, andremo ad usare in Auto.

Così non é.

La navigazione in auto, ovvio, è una esperienza per nulla simile a quella dedicata cui siamo abituati.Quando siamo dinanzi ad un computer la nostra attenzione ha un focus ben preciso e l'attenzione é tutta su questo focus (escluse, ovvio, le 'normali' attività collaterali della percezione).

In auto, invece, ci ritroviamo con una campo percettivo principalmente occupato dal main task (guidare) cui occorre affiancare almeno due ulteriori sub-task (navigare in Internet e consultare i contenuti) quanto più possibile usabili ed usabili in due sensi ben distinti:


  • usabili in quanto non molto differenti da ciò che l'utente si attende, dal suo background cognitivo.

  • usabili in quanto la dashboard non è di certo un computer ed ha la sua specificità cui la Web UI dovrà adattarsi.

Quindi una UI modificata, come richiesta dalle specifiche del nuovo medium, ma non troppo da spiazzare le aspettative dell'utente.

Come progettare queste UI in modo che il layout, gli strumenti, le funzionalità siano contenute negli schermi delle dashboard senza sacrificarne l'usabilità che, nel caso specifico, sarebbe oltre che sconveniente dal punto di vista del rispetto dell'utente e suicida dal punto di vista commerciale anche pericoloso dal punto di vista primario della sicurezza?

E ancora, quali standards saranno da adottare?

Queste domande frullano anche per la testa dei produttori stessi che, infatti, stanno spingendo per stilare delle specifiche, ottenere assicurazioni, insomma si preoccupano che il loro contenitore abbia poi un contenuto effettivo da mostrare e che lo mostri come l'utente si attende dalla propria esperienza pregressa.

Problematiche di usabilità ed accessibilità, troppo spesso confinate nel minuscolo spazio che Istituzioni e Business affermati dedicano ai diversamente abili (giammai confessarlo!), acquistano maggior valenza in quanto le tecnologie text-to-speech sono a disposizione come veicolo di diffusione nell'In-car Internet. Il binomio usabilità-accessibilità dunque si profila anche in questo caso come strada principale per condurre i contenuti disponibili in Internet alla fruizione degli utenti in nuove condizioni ambientali.

In-car Internet sarà un successo? Secondo gli analisti, si. Ma solo quando la Generazione Y sarà ascesa al trono.

domenica 18 maggio 2008

Accessibilità. Tra il dire e il fare vi é di mezzo...la burocrazia

Come commentavo qualche giorno fa, tutta questa enfasi su Legge Stanca, accessibilità, usabilità pare essersi risolta in Italia, al solito, in un burocraticismo di secondo livello che si ostina a confermare un bel detto di un mio caro amico psicanalista.
Quest'ultimo é uso ripetere, riferendosi ad un concetto fondamentale della psicanalisi lacaniana, che 'tra il dire ed il fare vi è di mezzo pur sempre il dire e per nulla il mare', intendendo con questo enunciato che tra la espressione della intenzione ed il passaggio all'atto vi è una soglia che è mero simbolo soddisfatto di se, autoreferenzialità che solleva dall'attuazione di quanto enunciato. Campo del rimando a segno.

Ricordo ancora la domanda più frequente che mi veniva posta da studenti all’immediato polverone alzato dalla legge Stanca. ‘Quali campi dobbiamo riempire e quali pulsanti cliccare in Dreamwever per rendere il sito usabile ed accessibile?’.
La domanda, per niente banale, rivelava un modus operandi, un approccio al problema, di cui la legge Stanca era semplicemente un segno posteriore, diffuso. Gli ‘operatori del settore’ pare abbiano confuso, insomma, i temi della accessibilità e della usabilità con la mera tecnicalia di title tag, links blu e quant’altro. Qualcosa da curare a website già implementato oppure, al massimo, di cui preoccuparsi in modo generico limitandosi alla verifica tecnica finale.

In verità, progettare un sito accessibile (ed usabile) richiede sforzo ed impegno sin dalle prime fasi del progetto. Inizia con i primi colloqui con il cliente. Prosegue nelle prime fasi delle bozze e continua, passo dopo passo, fino alla pubblicazione del sito on line. È una forma mentis, non posticcia attitudine tecnica. Un fatto ‘culturale’, una ‘vision’ più che regolette da seguire a menadito spuntandole dalla lista. Seguire ciecamente queste ‘regole’ (o linee guida che dir si voglia) non assicura la buona riuscita del progetto come seguire per filo e per segno una ricetta non ci rende cuochi provetti e la conoscenza a menadito del dizionario di una lingua non ci garantisce di saperla poi parlare.

La cura dei dettagli, la passione per l’oggetto culturale preso in esame (l’intero suo campo semantico), la identificazione con bisogni altri da quelli di cui siamo portatori (un esercizio in umiltà), un attento studio del comportamento degli utenti target del sito, queste sono le pratiche da apprendere, diligentemente, ma, su tutto, da cui farci permeare.
Un designer è una spugna. Inessenziale, è ricettacolo di minuti dettagli che ad altri (i non designers) sfuggono.

Come già accaduto con la ISO 9000 e tutta la retorica sul controllo qualità, anche per quanto riguarda la accessibilità ciò che è rimasto dai discorsi, seminari e paroloni è un nugolo di terziario avanzato e bollini ad attestare l'aderenza ad una legge.

Ora, come sa qualsiasi sociologo anche di primo pelo, una cosa è la imposizione di una legge su di un assembramento sociale, un'altra e ben diversa é la aderenza culturale, la permeabilità sua sponte dell'assembramento al contenuto ed al frame culturale della legge in questione.

Ciò che é accaduto è che 'sito accessibile' é semplicemente sinonimo di bollino blu appiccicato sulla pagina, qualche test condotto alla bene e meglio e, su tutto, nessuna comprensione profonda delle dinamiche culturali di cui l'accessibilità è solo un segno e per nulla il fine.

Tipico esempio del malcostume italiano di limitarsi alla lettera e mai comprendere e far propri i motivi è il sito vesuviana.it.

Per chi, i molti, non fossero a conoscenza del cosa sia questa vesuviana, diamo due parole due di background.
Semplicemente il mezzo più usato per spostarsi da Napoli a tutta la provincia sull'asse che conduce alla penisola sorrentina. Mezzo, si intuisce, tra i più usati e dai locali e, cosa importante, dai turisti.

Nel footer del sito da bella mostra di se una dicitura sponsorizzata che recita letteralmente
Realizzato con la piattaforma per siti accessibili Nebula 2 di CRISMA Srl
Un veloce check mostra quanto la accessibilità tanto sponsorizzata sia solo slogan e non corrisponda minimamente ai fatti.



Vesto I panni dell’utente tipo in cerca di informazioni (panni verissimi in quanto sono alla ricerca di info riguardo gli orari e le linee) e procedo.

La homepage presenta già segni della forma mentis con la quale l’utente si troverà a combattere lungo il vettore che lo divide dal fine che vuole raggiungere.



A che pro quel ‘[C]Cerca nel sito’?
E perché mai così poco spazio a disposizione del campo di ricerca quando tutta la testata è là ad occupare spazio con alcunché al suo interno?
I vezzi, le trovate, sarebbe meglio lasciarle per il proprio sito personale, ove si può tranquillamente giocare ai “creativi”. In un sito istituzionale, che fa della fornitura di servizi la propria raison d’etre, è necessario che tutto ciò che vien presentato all’utente sia funzionale alle motivazioni che hanno spinto quest’ultimo a visitare il sito.
La eccessiva ridondanza per cui sono presenti un ‘cerca nel sito’ ed un ‘vai’ non fa altro che aumentare il rumore percettivo. Il campo viene identificato, in quella posizione, come campo di ricerca. Non vi è alcun bisogno di aggiungere ulteriori informazioni. Invece di un ‘vai’ (dove, poi?) usare il pulsante per sottolineare l’azione che l’utente andrà a compiere. In breve:

  • Campo di ricerca
  • Pulsante con dicitura ‘cerca’.

In questo modo si sarebbe ottenuta maggiore pulizia con conseguente miglioramento della leggibilità della informazione presentata.

La domanda che immediatamente viene alla mente, osservando il primo row della testata, è ‘perché tutto così compresso quando vi è tutto questo spazio a disposizione?’

Il campo di ricerca è di dimensioni minuscole a maggior ragione se si pensa che la ricerca tipo del sito sarà di indicazioni circa orari e quant’altro che richiedono l’inserimento di almeno due termini (partenza - arrivo).
Avendo tutto lo spazio a disposizione perché non dare al campo di ricerca quelle 10 colonne in più che avrebbero dato all’utente la possibilità di vedere ciò che ha digitato diminuendo così le occorrenze di bad typos?

Abbiamo poi una ‘icona’ che sta a rappresentare un link alla mappa del sito. Questa pratica, diffusa in Italia, è giustificata con una presunta aumentata usabilità del sito in quanto l’utente può controllarne la mappa per orientarsi. In verità, il miglior design è quello che passa inosservato e non intralcia il task che l’utente sta svolgendo. Se un sito delle minuscole dimensioni di www.circumvesuviana.it abbisogna di una mappa vuol solo dire che il designer non ha lavorato abbastanza per rendere la struttura del website trasparente ed intuitiva (noi, infatti consultiamo una mappa quando ci vogliamo orientare in un luogo a noi ignoto di cui sappiamo solo il punto di partenza e quello di arrivo. Guarda caso non consultiamo la mappa dei luoghi abituali. Il punto in questione è proprio questo. Rendere un website talmente usabile e consistente con le aspettative e, dunque, le abitudini percettive dell’utente da eliminare del tutto il bisogno di una mappa con la quale orientarsi. Rendere il website familiare.)

Ora, dato la spazio a disposizione, perché usare una ‘icona’ (usiamo le virgolette per rispetto del lavoro degli icon designer che non apprezzerebbero l’accostamento del loro lavoro con questa ‘cosa’). Usare testo invece di una immagine avrebbe dato immediato feedback.
Abbiamo poi un ‘icona’ di ‘info’. Quest’ultima presenza è incomprensibile e segnala una gestione degli spazi confusa e non task oriented. Perché un link alla sezione ‘info’ nello spazio dedicato alla ricerca del sito? Dove è la consistenza della informazione? E' come se, sulla scatola dei biscotti, sotto la voce ingredienti trovaste le informazioni corporate del brand.

Stupisce poi la gestione degli spazi e delle pagine piene di landing che non fanno alcunché se non ribadire ciò che è già visibile nel menu.



Sorvoliamo su dettagli tecnici quali il non allineamento di alcuni elementi della pagina che segnalano il non completo test del sito su browser altri da IE6. Perché poi nel footer campeggi la solita iconetta di XHTML validation è un mistero.

Provando a fare una ricerca, ci ritroviamo il solito cambio di layout che è da addebitare alla pigrizia degli sviluppatori ed al fatto che, con tutta probabilità, il webdesigner era andato in ferie.




Notate il link 'nuova ricerca' in posizione astrusa.
Ma il colmo si ha con la pagina di 'caricamento risultati'.



Tutto sbagliato qui. Tutto. Da annotare la ironia della suddetta icona della validazione.
E non funziona neanche il loader, la cui persistenza dopo il caricamento dati è triste a vedersi e aumenta la confusione dell'insieme.



Altre appunti ancora sarebbero da muovere al sito in questione ma non è utile ad alcuno maramaldeggiare.

Accessibilità. Un'altro termine da mettere nella lista delle certificazioni da ottenere o dei bollini da appiccicare.
Accessibilità. Un'altro termine da spendere in modo ampolloso per circuire il cliente.
Accessibilità come distinto da usabilità.
Ma é possibile un sito accessibile che non sia in primo luogo usabile?