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.

sabato 12 settembre 2009

CVS su Mac. Un esercizio di pazienza.

La questione CVS su piattaforma Mac è quantomeno problematica, sempre che facciate parte di coloro che desiderano un livello medio di personalizzazione e di scelta e occupiate il tempo a lavorare ( o divertirvi) invece di far funzionare gli strumenti che dovrebbero farvi lavorare (o divertirvi). Coloro che si divertono a smanettare per il gusto di smanettare non sono tra questi per cui è inutile che continuino la lettura di quanto segue.

Hi! I’m a Mac!
E devo installare un client CVS sul mio OS X 10.5 aka Leopard.
Dopo estenuante ricerca sono giunto ad un bivio consistente di due opzioni:
Supponiamo che un Mac Guy debba installare il client cvs su OS X.
Avrebbe due opzioni:


  1. Installare i Developers Tools

  2. Usare un client self contained



La prima opzione costringe alla installazione di un pacco dono di 1GB (versione personalizzata della installazione. Altrimenti sono 3GB e passa) con un mare di (in)utilities per testare la applicazione in Cocoa che non scriverete mai. Assieme al pacco dono di cui sopra, verranno installati anche il server ed il client cvs, certo.
Questa opzione, è palese, obbliga l’utente ad installare software, compilatori e strumentini vari di cui non avrà mai necessità.
Si obietta da più parti che ‘tanto con quello che costa un HD al giorno d’oggi…’ ma non è questo il problema. Non è infatti il costo il maggior deterrente a questa opzione. Non è la mera occupazione di spazio su disco che potrebbe essere usato chessò per la vostra libreria iTunes, I vostri progetti personali, le vostre foto, le immagini a 300dpi e quelle a 72dpi per lavorare, MySQL e I database con tanti bei files php in fila come piccoli indiani, il software che usate ogni santo giorno per lavorare, comunicare, divertirvi insomma tutte queste cosucce inutili. No, non è questo.
Costringere l’utente ad installare un mare di inutilità per 3mb (tanto ‘pesa’ cvs) che gli occorrono è non dare scelta. Non avere scelta. O il pacco dono, o il nulla. Questo è qui che fa problema.
Se optate per la via maestra come Apple ve la indica, allora installate il pacco dono e morta là. Avrete il vostro client cvs.

Potreste optare, si fa per dire, anche per darwinport, macports oppure fink ma, guarda caso, tutte e tre le opzioni richiedono I Dev Tools installati quindi tanto vale ignorarli ed installare cvs direttamente con I Dev Tools.

A questo punto della nostra storia dobbiamo introdurre altri due personaggi:
La Differenza e La Unione.
Dovrete settare il vostro client per discorrere amichevolmente con il server cvs, fare una working copy sul vostro HD (si, sempre quello pieno di 3GB di roba inutile per voi). Come farlo senza aprire il santo terminale?
Cercate su macupdate quello che fa per voi.
Trovate su macupdate 5 software di cui:


  1. 3 PPC

  2. 1 Universal

  3. 1 versione freeware/pro a pagamento



Scartiamo, essendo come siamo avvezzi alla potenza di rosetta che più che stele è supplizio, I software ppc e ci dirottiamo sugli unici 2 (due) universal.
Il primo, richiede cvs già installato e vi permette le più comuni operazioni. Almeno sembra ad una prima occhiata.
Ad un uso più articolato, diciamo di 5 minuti, troviamo che non è possibile usare un diff-merge software di nostra scelta, quello che già di norma usiamo. O usiamo filemerge (contenuto nel pacco dono di cui sopra) oppure il vecchio e santo diff. Bene. E se volessi usare TextWrangler o qualsiasi altro? L’help tace e noi con lui.

Spendiamo due parole sul tanto decantato filemerge. Due parole di nome e di fatto. Non serve. Chiunque abbia usato winmerge (freeware) si ritroverà con volto basito di fronte a questa finestra dalla quale non si può fare direttamente alcuna operazione sui file in comparazione, i quali comandi sono messi in un comodissimo menu a tendina perché, ci hanno comunicato, gli icon designer di apple erano al momento in vacanza e non hanno avuto il tempo di preparare alcunché da pigiare ed i programmatori, per protesta contro le vacanze, a loro dire, inique di questi ultimi, hanno scioperato proprio nel momento in cui dovevano implementare il menu contestuale.

Insomma, non tiriamo neppure in ballo nomi illustri come Araxis e quant’altro in compagnia di filemerge. Lasciamo laddove si trova (nella cartella Dev/Application) e non ci pensiamo più.
Il secondo, di cui parleremo meglio dopo, va già molto meglio (dopo filemerge il mondo pare sorriderci e gli augelli far festa).
Che non vi venga in mente però di usare spaces con smartcvs. Che non vi venga in mente di usare la keyboard per switchare applicazioni. Un bug nel software lo rende inutilizzabile ogni volta che lo richiamate dal command+tab a partire da uno space diverso da quello ove lui si trovi.
Quindi, in summa, o non usate spaces oppure vi preparate a spostarvi di volta in volta da uno spazio all’alto alla ricerca del nostro (NonTanto)SmartCVS.
Dimenticavamo di aggiungere che la versione pro costa $80 (bug incluso, of course. E’ terminato il tempo nel quale acquistando un software avevi diritto all’uso normale di quest’ultimo).

Seconda opzione: usare un self contained client
Quali sono I candidati?


  1. Eclipse (e parentela)

  2. Il già visto (NonTanto)SmartCVS.




Entrambi in java per cui non attendetevi UI spettacolari, effetti speciali, riflessioni, eyecandy, yadayada (questo non è per forza di cose un male) e prestazioni al fulmicotone (questo è male).

Eclipse: download base con cvs client, diff e merge integrato. Nulla di più. 134MB e vi togliete il pensiero.
Affrontate le bizze del workspace (idiosincrasia di eclipse), fate il setup del repo, procedete al check out, attendete nel mentre che i vari dialoghi di eclipse si susseguono informandovi che sta presentandosi al server cvs e facendo I convenevoli del caso e, infine, molto in fine, avrete la vostra working copy.
A questo punto mica vorreste lavorare al vostro progetto con eclipse? Naaaaaa!
Fate partire il vostro fido TextMate ed iniziate a lavorare.
Dopo modifiche intensive vorreste procedere al commit. Ignari dello splendido isolamento nel quale eclipse vive e vegeta pensando che tutto ciò che non accade nel suo workspace semplicemente non è mai esistito e mai esisterà, vi accingete alla operazione tranne poi notare che eclipse non ha rilevato alcuna modifica effettuata nei files del progetto dato che sono state effettuate non con il suo editor.
Niente paura. Dovrete solo svegliare eclipse con un bel command+r perché si accorga di quanto è accaduto. Dopodiché, switchate modulo e procedete al commit. Andate a questo punto a prepararvi un bel caffè perché di tempo eclipse, tra connessione, recupero dell’indice dal repo e quant’altro, ce ne mette per questa operazione.

Hi! I’m a PC.
Equivalente di tutto ciò in Windows?
Installare TortoiseCVS (Freeware) 15MB
Installate Winmerge (Freeware) 2.90MB
Indicate a Tortoisecvs, con segno di spunta nelle preferenze, che volete usare winmerge per le operazioni di diff/merge.
Lavorate.

Windows, in questi contesti, è lontano. Altrove. Quasi nelle sfere celesti.

martedì 15 luglio 2008

SEO e Flash? Un amore impossibile (checché Mamma Adobe e Papà Google vogliano farvi credere)

Qualcun altro é concorde con quanto da me affermato qui e qui circa la tanto strombazzata indicizzazione dei contenuti Flash.

Testing Crawlability with Hope
That's what you're doing with Flash content for SEO - hoping. Google's Flash-crawling technology is proprietary, and while we all know and can test what search engines see from a content and link perspective in HTML, there's no "test my site's Flash file crawlability" feature that I'm aware of, leaving us very much in the dark about exactly how the engine's going to parse your material.

mercoledì 2 luglio 2008

Adobe Flash accessibile ai motori di ricerca. Oltre l'hype cosa c'è?

Oltre ai problemi già citati occorre opporre qualche altra barriera di madrigali alla fanfara da parata messa in moto da Adobe sulla accessibilità del Flash content ai motori di ricerca.

Prima di tutto, il crawler del motore di ricerca non indicizzerà gli swf. incorporati via JavaScript (sapete quello stratagemma per evitare il 'clicca per attivare' di IE? Bene. Lui).

In seconda istanza, e maggiormente importante, il crawler non indicizzerà swf dinamicamente caricati come risorse esterne nè XML.
Ora, chiunque abbia un pò di esperienza in Sviluppo Flash sa benissimo che, per non impazzire con quel casino della timeline di Flash e per ottimizzare al massimo i tempi di caricamento (e per una marea di altre esigenze), é regola procedere per caricamento dinamico delle sezioni del website. A quanto io ne sappia la maggioranza dei Flash sites adotta giustamente questi approccio. Quanto più il sito é complesso tanto più si rende necessaria questa modalità. Spesso si carica in prima istanza solamente il framework generale (la UI standard) per poi, dietro input utente, caricare il resto.
Bene, allo stato dei fatti solamente questa prima parte verrà indicizzata dal crawler. Id est, un bel nulla. La presunta Home Page e poi il vuoto.
In altre parole nessuna moderna RIA verrebbe indicizzata, checché ne dica Adobe, a meno di non caricare l'impossibile in prima istanza.
Forse Adobe sta pensando come modello di RIA ai fulgidi esempi di Flash RIA di cui si é resa portabandiera con Acrobat.com che ci mette 5 minuti buoni (su di una fibra ottica) per caricare la UI?
Per quale tipologia di Flash site va bene questa presunta indicizzazione? Per i Flash sitarelli self contained. Detto altrimenti, coloro che meno avrebbero bisogno di essere indicizzati.

E se poi adottate un loader con caricamento dinamico via Actionscript di risorse esterne? Oh beh! quanto siete difficili!

Quanto rumore per nulla!

Adobe Flash accessibile ai motori di ricerca! Sicuri?

Il contenuto di Flash sites finalmente disponibile agli spiders dei motori di ricerca. Così dicono.
Rullo di tamburi. Strombazzamenti vari. Urla di giubilo. E nessuno che si sia peritato di leggere tra le righe del marketingese del comunicato di Adobe.

Adobe is providing optimized Adobe Flash Player technology to Google and Yahoo! to enhance search engine indexing of the Flash file format (SWF) and uncover information that is currently undiscoverable by search engines.


Fuori del giro dei fatti in 80 parole del PR Adobe, quello che abbiamo é:

  • Nessuna specifica aperta a tutti gli sviluppatori interessati ma solamente delle indicazioni chiuse per ottimizzare gli spiders.

  • Queste indicazioni sono solo a vantaggio di Google e Yahoo!. Gli altri? Se lo prendono in saccoccia.



Per fare un paragone non ortodosso, é come se le specifiche ottimizzate dell'HTML 5 fossero date solamente ad un gruppo ristretto di webdevs lasciando gli altri con il fondoschiena nell'acqua ed andare poi sbandierando la notiziona della release di HTML 5 ai quattro venti su tutti i canali possibili per ostentare il 'proprio commitment' e risollevare le sorti di una tecnologia affossata dalle critiche (giustificate).
Gli altri webdevs avrebbero le solite specifiche mentre alcuni, privilegiati, avrebbero un vantaggio competitivo su questi ultimi.
Tutti sono uguali ma alcuni sono più uguali di altri.

Il tutto condito con tanto di giustificazione di quanto finora accaduto mettendo artificialmente nello stesso calderone tutti gli altri in modo da distinguersi in positivo con l'annuncio. Prima affermo stronzate tirando nella mia propria situazione tutte le altre tecnologie e poi mostro che io, a differenza delle altre tecnologie, sto facendo qualcosa per combattere la situazione di cui sopra.

RIAs and dynamic Web content have been generally difficult to fully expose to search engines because of their changing states — a problem also inherent in other RIA technologies


Bullshit.
E' falsa la prima posizione (le altre tecnologie non hanno tutti i problemi di Adobe Flash) ed é quindi falsa la conseguente (Adobe non sta facendo nient'altro che cercare di recuperare terreno sulle altre tecnologie).
Lezione di PR: come trasformare uno svantaggio in vantaggio con un semplice giro di parole.

Di sicuro una bella operazione di marketing ed un grande sforzo di PR. I fatti tralasciati sono che la concorrenza va a farsi benedire come anche la possibilità per i Social Networks (il che vuol dire la marea montante in Internet) di usare Adobe Flash in modo consistente e mantenere la possibilità di operare ricerche interne.
Nel campo che più mi preme, inoltre, continua ad essere impossibile usare Adobe Flash su RIA Business (Web Applications Intranet e comunque chiuse) ove occorre poi andare a ricercare un contenuto specifico.

A quando una apertura totale di questo pacchetto regalo, Adobe?

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.

domenica 25 maggio 2008

Conway's Law

“Any piece of software reflects the organizational structure that produced it.”


Wikipedia link

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.

sabato 24 maggio 2008

La metamorfosi disegnata da Peter Kuper

kupergrande.jpg

metamorfosi_interno.jpg

Ispirato, più che nel tratto nella intenzione, dal quel genio del fumetto di Winsor McCay, arriva sugli scaffali delle librerie italiane per i tipi di Guanda la trasposizione in Graphic Novel, a cura di Peter Kuper, di uno dei capolavori della Letteratura.

La metamorfosi di Kafka, visionaria già di suo, non risulta sfigurata, come spesso accade nelle trasposizioni, dal disegno di Kuper che riesce a tenere il passo con alcune tavole, come la seconda immagine poco sopra, degne di nota. Qualche soluzione, non molte ma vi sono, un pò troppo azzardata nel lettering ne mina la piena godibilità.
La scelta, ovvia, del Bianco&Nero non fa che sottolineare l'ambientazione in molti passaggi notevolmente resa mentre qualche trucchetto da striscia di troppo poteva essere evitato tranquillamente.

Ottimo acquisto, costa veramente poco, per un ottimo libro. Non un capolavoro nel suo genere ma da avere senza ombra di dubbio.

Ergonomics anyone?

xyz-computer-desk_dWEfC_48.jpg

Non pratico. Ergonomia zero. Industrial Design al suo grado sottozero.

Come si suppone l'utente interagisca con tutto questo insieme?
Monitor troppo lontano dall'utente con alcuna possibilità di scostamento sull'asse z in grado di alleviare la scomodità di questa posizione.

Oltre ciò, dalla foto, possiamo dedurre un assurdo posizionamento di quest'ultimo rispetto alle porte e al CD Bay. L'utente é infatti costretto, dalla posizione del monitor, ad una determinata distanza dai lati del Desk che rende di fatto irraggiungibile il lato sinistro dove sono posizionate le porte, il pulsante di accensione ed il CD Bay a meno che non si sporga, abbandonando la posizione di lavoro, per raggiungere questo lato.

Taccio su altri problemi che, evidentemente, possono presentarsi (espandibilità, dissipazione del calore etc).
Infine, come dettaglio, uno slot loading invece del solito cassettino in un prodotto che vende se stesso come 'futuristico'?

venerdì 23 maggio 2008

Account forzato. Usabilità del checkout

Non é necessario costringere l'utente all'apertura di un account per acquistare un bene.

Rendete facile fare affari con voi. Tenete bene a mente questa regoletta.

Barnes & Noble, freschi di redesign, applica perfettamente questo principio.
L'utente può procedere al checkout senza creare nessun account ma immettendo, una tantum, solamente i dati che occorrono per portare a termine la procedura di acquisto

barnes.png

Al contrario, il solito BOL

bol.png

costringe l'utente alla apertura di un account per procedere alla transazione.

Il web marketing inizia ben prima di avere un web site già bello che finito e coinvolge direttamente l'UI Designer nelle primissime fasi di studio. La usabilità di questi steps cruciali in un e-commerce è, infatti, quantomeno imprescindibile e avrà ricadute considerevoli, in positivo come in negativo, sulla percezione del Cliente riguardo il servizio che si offre e, di conseguenza, il Brand.

La differenza tra un checkout usabile ed un calcio negli stinchi al cliente é tutta in queste immagini.

giovedì 22 maggio 2008

BOL e IBS. E-Commerce da rifare.

Si dice che una immagine valga di più di innumerevoli parole.
Ve ne propongo tre.

amazon.png


Immagine 3.png


Immagine 4.png

Notate differenze?

Dopo la scelta di un libro e la sua aggiunta al carrello abbiamo da una parte Amazon con i suoi consigli per ulteriori acquisti basati su ciò che potrebbe interessare, visto il bene messo in carrello.
Dall'altra parte IBS e BOL con...il carrello e basta.

Ora, E-Commerce sta per commercio elettronico il che vuol dire che vi é sempre la magica parolina 'commercio'.
Chiunque vada in una libreria, girovaga, leggiucchia, sceglie qualche testo, ne ripone qualcuno ed infine decide quale o quali acquistare e si dirige alla cassa.

Per BOL e IBS, invece, il commercio non é così.
Secondo il loro modello comportamentale, il cliente gira per la libreria digitale, sceglie un primo testo e subito si trova catapultato, come per magia, in cassa!
Tutto ottimo. Tutto studiato sul comportamento reale del cliente tipo che, secondo BOL e IBS sa già cosa vuole, sceglie in prima battuta e passa direttamente in cassa.

Ma anche se così fosse, rimane sempre la cara e vecchia 'vendita aggiuntiva' che o il libraio o la libreria stessa, come architettura, tenta fino all'ultimo. Basti pensare ai libri che sono sul tragitto che porta dallo scaffale, dove il libro é stato preso, alla cassa e che contengono possibili acquisti ulteriori e ai gadgets messi, in bella mostra, dinanzi alla cassa per tentare all'ultimo acquisto.

BOL e IBS non tentano neanche questo.
O sono troppo onesti e rispettosi del Cliente oppure chi ha progettato la UI non ha mai acquistato un libro in vita sua.

La seconda che hai detto.