semioticmonkey

Commentaries on "The Law of Simplicity n°2"

2009-10-05T18:17:00.000+02:00

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.

CVS su Mac. Un esercizio di pazienza.

2009-09-12T18:54:00.000+02:00

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:

Installare i Developers Tools

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:

3 PPC

1 Universal

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?

Eclipse (e parentela)

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.

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

2008-07-15T15:54:00.005+02:00

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.

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

2008-07-02T10:55:00.007+02:00

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?

2008-07-02T09:31:00.005+02:00

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?

Adobe vs Apple. No Flash per una iPhone UI consistente

2008-06-18T11:31:00.005+02:00

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

Accessibilità nel Car Design

2008-06-15T17:31:00.003+02:00

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).

Andy Clarke, tempo di lettura e web layout

2008-06-14T18:13:00.006+02:00

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.

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

2008-06-13T15:16:00.006+02:00

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

Opera 9.5 UI. Come sprecare spazio prezioso

2008-06-13T14:03:00.006+02:00

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.

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

2008-06-11T00:31:00.008+02:00

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.

Per una accessibilità fallibile. Invito al dialogo

2008-06-07T13:28:00.010+02:00

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?

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

2008-06-06T19:03:00.017+02:00

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.

Touch User Interface. Uno sguardo al laboratorio di culturedcode

2008-06-03T21:36:00.004+02:00

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.

Conway's Law

2008-05-25T23:08:00.002+02:00

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

Wikipedia link

Flow. Ovvero l'UI Design non é semplice belletto

2008-05-25T14:20:00.002+02:00

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à.

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.

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.

La metamorfosi disegnata da Peter Kuper

2008-05-24T15:59:00.001+02:00

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?

2008-05-24T12:12:00.002+02:00

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'?

Account forzato. Usabilità del checkout

2008-05-23T15:53:00.002+02:00

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

Al contrario, il solito BOL

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.

BOL e IBS. E-Commerce da rifare.

2008-05-22T20:06:00.002+02:00

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

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.

Qualcosa non va. L'usabilità dei messaggi di errore

2008-05-22T12:24:00.005+02:00

Vi é modo e modo per comunicare con i propri utenti. Anche quando qualcosa non va come dovrebbe andare.
Questo é il modo migliore.

E' inconsistente curare solo il lato del normale funzionamento e poi perdersi, come spesso vedo accadere, nei dettagli dei messaggi di errore. Come accade nella programmazione dove uno degli elementi più importanti é il try catch e cioè la gestione degli errori cui qualsiasi dev dedica giustamente il suo tempo, anche nella costruzione di UI occorre prendersi cura del momento, che arriva sempre, nel quale qualcosa non va.
Ed invece vedo sempre più arzigogoli nella UI a cui fanno da triste controcanto messaggi di errore laconici lasciati alla web application di turno senza personalizzazione né spiegazione, quando necessaria, di quello che é accaduto.

Lasciare l'utente inebetito di fronte una pagina che gli comunica qualcosa in un gergo a lui sconosciuto, spesso accompagnato da un layout completamente diverso da quello che fino a qualche secondo fa stava osservando, non é il modo migliore per curare la usabilità di un web site.

I Web Standards limitano che?!

2008-05-21T10:59:00.011+02:00

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.

In-car Internet. Sarà usabile?

2008-05-20T21:28:00.008+02:00

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.

Piena accessibilità al problema della Accessibilità

2008-05-19T23:51:00.005+02:00

Cosa volete farci? Come un bravo cane di Pavlov, non resisto e quando parlano di accessibilità-usabilità mi infervoro e comincio a salivare (divento anche un tantinello rosso in volto. Non proprio questa bellezza a vedersi).
Se poi ad aprire le danze è semplicemente il caro* Semplice Mente, allora come si fa a resistere?

Prologo semiserio a parte, é necessario che ci si confronti con queste tematiche, che si veicoli il sapere riguardo queste, che si porti queste esigenze nel proprio flusso di lavoro quotidiano fatto non solo di codice, belletto e mappatura relazionale ma di percezioni, segni, aspettative dell'utente, finalità dello stesso, background semiotico-cognitivo, efficacia della GUI.

Per il tutorialino su Photoshop ed il bordino dashed 1px ci sarà sempre tempo.

*mi perdonerai la confidenza

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

2008-05-18T13:57:00.015+02:00

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?

Generation Y. Il marketing e il trono vuoto

2008-05-16T18:15:00.007+02:00

Dopo la Generazione X, la Generazione Y è pronta per sedere sul trono del Target.
Almeno così ci dice Business Week.

Cosa differenzia, dal punto di vista sociologico e di analisi marketing, questa generazione da quelle che l'hanno preceduta?
Potremmo riassumere con Socialmente Connessi.

Sono connessi digitalmente. Sempre. E questa suona come una ovvietà, tanto la rete è pervasiva.

La Televisione non la fa più da padrone ma ha il suo dominio attaccato da altre periferiche. Computers, certo ma non solo. iPod, telefoni cellulari, periferiche di terza generazione, periferiche di convergenza etc.

Sono consci di essere sotto l'attacco del marketing. La pubblicità viene vista sempre più con sospetto quando non con la derisione di chi si rede conto di essere il bersaglio ma vede, nel contempo, che chi mira non mira neanche tanto bene (non avendo compreso bene il target) e non ha scelto bene le sue cartucce (il codice comunicativo adeguato, non avendo compreso il target).

La pressione dei pari ha maggior valore del messaggio pubblicitario diretto. Questo è logica conseguenza del punto appena enunciato in quanto si tende ad avere fiducia in coloro che usano, bene, lo stesso codice comunicativo che manca, per ora, agli Advertisers.

Il lavoro non è il loro orizzonte unico di vita. Ciò non vuol dire che non lavoreranno. Vuol dire più semplicemente che hanno a cuore anche altri valori e non si identificano con il lavoro che svolgono.
(questo punto, ovvio, non si adatta alla realtà lavorativa italiana. Le analisi sociali 'grossolane' non tengono mai in conto le variabili, giustamente)
Ciò conduce ad una diversa prospettiva nella relazione lavorativa e orizzontale (con i colleghi) e verticale (con i superiori). Sono meno malleabili per paura di 'perder il posto di lavoro' (anche questo pare non esser cucito sul giovane italiano medio) e più attenti alle relazioni interpersonali (non il 'collega' ma un possibile amico).

Cosa cambia per il marketing?
Che la rete portasse ad una minore fidelizzazione al brand, è cosa prevista ma che l'esser connessi costringesse ad una rimodulazione dei codici comunicativi e della metodologia stessa forse non era stato messo in preventivo*. Questo è quanto accade ora con i Social Networks e la stizza degli advertisers che si stanno scervellando per trovare un modo per capitalizzare su questo numero altissimo di clienti possibili che, però, son diventati ad-blinds.
Come procedere?

Forse, come da più parti suggerito, abbandonando il concetto di target e mirare ai segments of one (che vanificano il concetto stesso di target come usato nel marketing tradizionale).
Ma questo è più facile a dirsi che a farsi.

ps. Ma questa Gen Y esiste solo oltre oceano?

*forse. Kotler aveva già annusato il problema, da par suo.

La concorrenza in rete

2008-05-16T17:34:00.006+02:00

Si fa fatica a fare entrare nelle teste degli imprenditori italiani che la concorrenza in rete è ben altra cosa che quella cui sono abituati nel settore bricks&mortars con la sua dinamica di concorrenza diretta sul prodotto.

In rete, essa si manifesta in forma trasversale.
I produttori di informazioni rilevanti per i propri clienti target possono anche non essere nel proprio settore o nella propria nicchia.

Molti website di infomediari, ad esempio, colpiscono proprio questo punto offrendo informazioni che potrebbero (e dovrebbero) essere trattate nella nicchia di appartenenza. Ciò vuol dire che immettersi sul mercato in rete vuol dire concorrere anche con questi infomediari oltre che con i competitors diretti.

Un website specifico di un franchising per la casa, ad esempio, si troverebbe a competere non solo con altri franchising che offrono la stessa tipologia di prodotto sotto brand diverso ma anche con portali generalisti che trattano il settore in questione oltre tutto il resto ma che possono offrire un parco maggiore di offerte in quanto non sono limitati al catalogo orizzontale e verticale del franchising.

Occorre in questo caso competere sulle informazioni erogate, che devono andare oltre il semplice annuncio, e sui servizi offerti, che devono andar oltre la semplice esposizione del prodotto.

Un piano di web marketing che non parta da questo assunto avrà seri problemi ad ottennere un ritorno sull'investimento.

A. N. Whitehead. Simbolismo e percezione

2008-05-15T11:28:00.008+02:00

"La mente umana opera sul piano simbolico quando alcuni componenti della sua esperienza suscitano consapevolezza, credenze, emozioni ed abitudini, in rapporto ad altre componenti della sua esperienza."

A. N. Whitehead

Adobe installers. Are You User Experienced?

2008-04-03T23:16:00.005+02:00

Splendido articolo di Jens Alfke sulla User Experience partendo da un troppo spesso ignorato step: la installazione.
Un viaggio allucinante, e allucinato, nella routine di installazione Adobe.
Questa volta si parla del nuovissimo Adobe Photoshop Elements 6 ma lo stesso può dirsi di tutta la Creative Suite (1,2,3 che sia).
A mia memoria solo Avid e Autodesk sono riusciti a fare peggio nella gara a chi produce la peggiore esperienza utente.

"First things first: After inserting the disc, I had no idea how to start the installation. I can’t remember the last time that’s happened."

Detto da un Developer questo non suona affatto come un complimento. Se poi pensiamo al target di Photoshop Elements, il fotografo 'amatoriale' che coincide in parte con quanto di più lontano dal tipico smanettone si possa immaginare, non possiamo fare a meno di credere che, in qualche parte molto in alto negli uffici Adobe, ci sia qualcuno che manca della più piccola traccia di senso comune e rispetto dell'utente.
Questo è ciò che si ottiene con i monopoli. Non ci resta che sperare nella vecchia e sana concorrenza. Ce ne fosse.

Outspring Email. Il client di cui nessuno sentiva il bisogno.

2008-04-02T14:35:00.020+02:00

Un nuovo client email per OS X, sorto dalle ceneri di una vecchia gloria, ha goduto delle luci della ribalta in questi giorni. E, forse, sarebbe stato meglio per lui il contrario.

Premettiamo il costo di questo nuovo 'giocattolo': 99$.
In altre parole, quasi il costo di Contactizer Pro Edition, quasi il doppio di Contactizer Express Edition, quasi il costo della intera Suite Office in versione Home e Student (e quindi con Entourage come PIM), pericolosamente vicino a Merlin.
Certo, alcuni dei software sopra elencati non sono Client Email ma si integrano perfettamente con mail.app permettendo una gestione della posta molto articolata.

Cosa offre Outspring Email che altri non offrano per giustificare simile scelta nel pricing?

Al primo avvio Outspring ci presenta un wizard per importare mail e setup da mail.app. Il setup è ottimo e veloce, anche e sopratutto a livello di presentazione lato GUI e semplicità.

L'applicazione si presenta negli shots curata ma fa un effetto meno piacevole in presa diretta. Molti particolari denotano scarsa attenzione ai dettagli.
Segnaliamo:
Icona dell'applicazione la cui qualità lascia molto a desiderare

Icone delle mailboxes stile OS9 che poco o nulla hanno a che fare con lo stile di Leopard (o Tiger) e danno un tocco cartoonish al tutto con buona pace del prezzo 'pro'.

Icone sulla sort toolbar che sono, se possibile, anche peggiori di quelle delle mailbox (in quanto pur essendo consistenti con queste ultime, a scala ridotta hanno una resa molto inferiore).

Su questo ultimo punto riaffermo la mia profonda antipatia per coloro che devono sempre reinventare la ruota. Se mail.app, Entourage et al seguono la stessa convenzione e usano icone in scala di grigi o testo nero per dare indicazioni all'utente sulla colonna, perchè mai alcuni developers si ostinano a metter su queste chiazze colorate che risultano illegibili a quelle dimensioni?
Sarebbe il caso di darsi una lettura alle Apple HIG.

Outspring Email non offre, al contrario di mail.app, alcuna possibilità di registrare l'allegato direttamente dal viewer pane nè una preview veloce. Dunque nessun 'registra tutti' . Occorre fare right click e selezionare un non meglio identificato 'download image'. Perchè poi occorra scaricare una immagine che è già sull'HD non mi risulta chiaro.

Da segnalare la pessima idea di piazzare di default questo footer su tutti i messaggi inviati.

Come volevasi dimostrare, questo footer non può essere modificato nè cancellato. Credevate il contrario?
Non posso dire se, una volta registrato, Outspring Email si degnerà di darci il controllo su cosa ci va e cosa non ci va nelle mail da noi inviate.

Fastidioso oltremodo è che ad ogni avvio Outspring Email non ricordi lo stato precedente nè per quanto riguarda le cartelle e l'utima mail selezionata nè per quanto riguarda i task aperti nel task pane (mailboxes in non collapsed state, cartelle selezionate e così via)

Non ho avuto finora la gioia di vedere all'opera il famigerato The Brain che è la feature più strombazzata di Outspring Email per cui non spenderò parola al riguardo.

Per quanto mi sia sforzato cercando in lungo ed in largo per le preferenze, non ho scovato alcuna possibilità di settare un check automatico delle caselle di posta ad intervalli scelti dall'utente. Outspring Email sembra fare il check di continuo ad intervalli brevissimi e scelti a priori (dagli sviluppatori che non si curano degli utenti cui pure vorrebbero vendere il loro software), con divertimento del server di posta del vostro provider.

Ottima la configurazione in contesto degli stili di visualizzazione degli header, delle colonne e del task pane.

Quest'ultimo però rivela un default scelto non bene in quanto la apertura dell'HUD è, comunque vada, a partire dalla posizione del pulsante senza tener conto della posizione sullo schermo di quest'ultimo. Abbiamo dunque casi regolari (a meno di non avere la finestra perfettamente centrata sullo schermo oppure schermo ad alta risoluzione) di 'uscita dallo schermo'.
(il lato sinistro della immagine sotto è l'angolo sinistro dello schermo)

Il resto? Più o meno quello che ogni client email free ci offre di già.

A peggiorare la triste situazione si aggiunge anche un web site che è a dir poco sconsiderato in quanto a comunicazione ed in quanto a branding.

Stock Joomla! Theme tanto per cominciare. Per una azienda che vorrebbe vendere un prodotto pro destinato, quindi, all’utente attento ai dettagli con un costo non proprio accessibile, il meno che si possa fare è segnalare il proprio sforzo e la propria presenza come azienda in modo chiaro con un branding preciso e indirizzato agli utenti target. Ed invece…scarica Joomla!, copia incolla testo qualsiasi, metti su qualche immagine ed abbiamo il sito che si occuperà di promuovere e presentare il nostro software. Tutto giusto.

Si continua con una mera paginetta che dovrebbe convincere l’utente interessato ad almeno esser tentato a provare il software in questione. Screenshots esplicativi? Dimenticateveli. Screencasts? Tecnologia futuristica! Guided tour? Troppo sforzo.
Si trova in rete una mole di progetti OOSS con una capacità di comunicazione e coinvolgimento nel prodotto da cui i nostri potrebbero trarre insegnamento.

Viene il dubbio che costoro il software non lo vogliano vendere.

Conclusioni

Se usate mail.app o Entourage, è inutile che diate una occhiata al nostro wannabe. Niente di nuovo sotto il sole per voi. Passate oltre.

Se non siete contenti di mail.app, indirizzatevi altrove
Mailsmith
Powermail
meno costosi, meno luccicosi ma più funzionali.

In altre parole, risparmiatevi i 95$.

ps. Avrei molta curiosità circa la scelta della politica di pricing di questo client. In base a quali astruse categorie mentali avranno deciso questo prezzo dato ciò che offrono in cambio?

Oracle vs Usabilità. Ovvero il Web a misura dell'Azienda.

2008-03-17T15:11:00.035+01:00

Molto si è discusso e scritto sulla necessità di un website di essere usabile e ‘a misura di utente’, molto si è fatto perché ciò accadesse e molto ancora è da farsi.
Purtroppo a volte ho l’impressione che tutto questo impegno sia stato profuso in una sola direzione ed abbia avuto come target proprio coloro che ne avevano, per diverse ragioni, legate principalmente al bruto numero di utenti e al grado di visibilità di già conquistata, meno bisogno.

I grandi giocatori nell’arena del web, I siti istituzionali, grandi aziende, brand famigerati sono spesso, troppo spesso, proprio coloro più disinteressati all’argomento preferendo di gran lunga, nel migliore dei casi, pseudo Customer Care da manuale teorico all’effettivo sforzo di prendersi cura del cliente non come mere parole ma con lo studio, la progettazione e la implementazione di una interfaccia utente consistente a questi ultimi congeniale.
Oracle* è una di queste realtà.

Quel che segue è la cronistoria di un utente (me) in Oracle Land.

Alla ricerca di alternative al terminale per la gestione di database, mi sono avventurato nel labirinto del Website Oracle sulle tracce di Oracle SQL Developer.

La tipica pagina con una lista inline delle opzioni disponibili per le varie piattaforme senza alcun sommario/link in testa a sveltire la procedura mi accoglie ma tant'è, procedo e cerco con lo sguardo il link di interesse che ci fornisce, con carattere al limite dell'illeggibile, le info necessarie.

La pagina di download non da alcuna indicazione circa la necessità di loggarsi né di registrarsi per scaricare il software anzi si sforza di presentarsi di una semplicità disarmante arrivando persino a dare istruzioni sulla installazione allegate alle info sul file stesso. Se ne deduce, quindi, che si tratterà di operazione veloce, come è giusto che sia, e che potremo mantenere la pagina con le istruzioni in bella vista nel mentre procederemo alla installazione del software, nel caso ne avessimo bisogno (perché dare istruzioni all’utente se non per fare in modo che le segua?).

Gli oracoli sono però famosi dall' Antichità per il loro emettere segni non chiaramente decifrabili.
Ed infatti.
Faccio click sul link e mi trovo di botto catapultato in questo:

Trovo ad attendermi un layout completamente diverso dal main site Oracle. Non riesco a riconoscere alcun elemento di consistenza notando come persino il logo cambi.

Uno degli elementi basilari del buon design e della usabilità, la consistenza, viene bellamente ignorato catapultando, così, l'utente disorientato in un nuovo contesto di interazione in cerca di conferme nella barra degli indirizzi (id est. ma dove mai sarò capitato?).

Manca persino una qualche forma di menu in grado di portarmi altrove nel website Oracle. Insomma, o continui o non ti resta che chiudere la finestra pare dirmi il colosso dei database.
Come se ciò non bastasse, mi viene comunicato che occorre registrarsi per il download del software.
Quattro problemi qui:

Le previsioni dell’utente (incentivate dal website stesso) sono disattese. Vi è una condizione, cui non si è fatto cenno nella pagina di download, per procedere e raggiungere, così, il mio fine.
Effetto di straniamento dovuto al cambio di layout e grafica.
Nessun menu che permetta all’utente di uscire dalla trappola o, comunque, di andare altrove nel website Oracle.
Nessuna indicazione del dove l’utente si trovi. L’URL non è di aiuto in quanto non ‘pulito’ (e contiene l’IP dell’utente, tra le altre cose).

È buona regola della usabilità (e del Customer Care) indicare precisamente cosa l’utente dovrà attendersi e preparare un ambiente quanto più possibile privo di sorprese. Dare inoltre indicazioni del dove ci si trovi mi pare il minimo in un website così complesso ed articolato come quello Oracle. Vorrà pure il nostro mostrare ciò che può fare per noi ed il nostro business? Come può farlo se noi non possiamo vederlo?

Il warning spreca dunque una pagina (ed il mio tempo) per avvertirmi della necessità di registrarsi.
Il link piccolo che mi invita a registrarmi costringe l’utente (me) a leggere il tutto prima di poter decidere. Non sarebbe stato meglio una chiara indicazione delle due opzioni separate come spesso e giustamente vediamo fare?
Come se non bastasse, cliccando sul link che chiaramente indica If you do not have an account you can sign up now, mi ritrovo in un’altra pagina che si ostina a presentarmi il pannello di login nonostante sia chiaro, dal link che ho seguito, che non sono registrato (se non sono registrato come potrei effettuare il login? Perché mostrare all’utente una opzione che è impossibilitato ad usare?).

Altro cambio di layout e di grafica. Si ritorna allo stile del main site. Ricompaiono il top menu ed il footer.
Cambia anche la lingua con la quale Oracle cerca di comunicare con me. Viene usato l’italiano ove prima era l’inglese. Questo italiano però lascia molto a desiderare. Cosa diamine vuol dire in italiano ‘sign in’? Vado in cerca del Devoto-Oli per avere lumi.
Incuriosito, procedo e cerco di creare questo account sospirato ma...
Ancora un altro layout (notate il logo di dimensioni maggiori) mi attende. E siamo a 3.
La lingua ritorna ad essere Inglese. Di certo meglio l’inglese che un misto di italiano ed inglese, dal punto di vista dell’utente. Lo sforzo cognitivo è minore. Basta decidersi ed attenersi a quanto deciso.

La dicitura ‘you will be asked to sign in after you create your account’ lascia intendere che mi verrà richiesto un login successivo a completamento della procedura (come se non fosse di già abbastanza lunghetta).
Mi registro, sicuro che finalmente si sia giunti al termine della via crucis ed invece mi viene presentata una pagina di conferma dettagli.

Ora, tralasciando il fatto che è logicamente contraddittorio confermare qualcosa che prima non si sia affermato (per cui, invece di pagina di conferma, occorrerebbe un chiaro ‘immetti ulteriori dati’. Ricordate? Chiarezza e non ambiguità per raggiungere un livello ottimale di leggibilità dell'informazione e, quindi, maggiore usabilità), non posso fare a meno di notare che ciò che viene nascosto è che questa pagina è obbligatoria e richiede una mole di dati da compilare che vanno ben al di là di un processo di registrazione mostrando chiaramente che è una operazione aggressiva di client profiling.
‘Take a few moments’? Non direi proprio 'few'.

Telefono e indirizzo obbligatorio assieme ad altri dati non proprio necessari per il download di un software. Insomma, una vera e propria scheda personale. Manca solo che Oracle ci chieda notizie circa la prole e lo stato di famiglia.

Se mi ritrovo ad aver acquistato un prodotto che mi dovrà essere recapitato, è ben giusta e sacrosanta la richiesta dell’indirizzo, ma in questo caso? Quale è qui l'ovvio motivo per cui dovrei dare il mio indirizzo fisico, telefono di casa e quant’altro?
L’unica voce a giustificare questa richiesta è Oracle Printed Magazine il cui invio, è ovvio, richiederebbe l’indirizzo ma…non sono ancora arrivato a quella opzione (molto più giù nella pagina)! E comunque sarebbe giusto separare coloro che desiderano l’invio (e che quindi dovranno dare un indirizzo fisico) da coloro che non son interessati. Due tipologie di offerte, due procedure. Meglio sarebbe stato usare una opzione contestualizzata. Se e solo se l'utente ha scelto l'invio della rivista cartacea, attivare il textfield relativo all'indirizzo fisico.

Interessante la sezione subscribe nella quale trovo una lista di tutte le pubblicazioni in forma di newsletter di Oracle (non sarebbe il caso di compattare l'offerta su delle macrosezioni?).

Più giù, come ultima voce, compare invece un
Please unsubscribe me from future Oracle electronic communications & subscriptions.

Ora, qualora l’utente (sfigato. Sempre me) non avesse spuntato alcun checkbox significando così che non è affatto interessato ad alcuna delle pubblicazioni promosse ci troveremmo di fronte all'ennesima offesa all'abc della usabilità in quanto, senza l’esplicito gesto dell’unsubscribe, Oracle presuppone che l’utente debba per forza di cose aver scelto qualcosa e ci rimanderà alla pagina di errore per informarci di un loro errore logico imputato all'utente.
Occorre, in altre parole, selezionare esplicitamente la opzione unsubscribe anche se non ci si è ancora sottoscritti ad alcuna newsletter. In caso contrario, la selezione di una newsletter è obbligatoria.
Per gli esperti di usabilità Oracle, la pragmatica come branca della semiotica e, quindi, la contestualizzazione sono flatus vocis.
Se l'utente non ha esplicitamente selezionato alcunché vuol dire che non è interessato. Il default dovrebbe essere incentrato sull'utente e non su ciò che l'azienda pretende da esso.

Cliccando su ‘confirm’ mi ritrovo in una pagina che mi informa, casomai ce ne fosse bisogno, che i campi segnalati come obbligatori hanno da essere compilati.
Da notare che la prima voce segnata come obbligatoria è la newsletter. Il resto viene elencato dopo anche se, nella pagina del form, quelle voci erano poste prima della sezione della newsletter.

Dopo aver chiaramente espresso la nostra volontà di unsubscribe, mi tormenta con una pagina dedicata il cui unico scopo è convincermi che sto facendo la cosa sbagliata.

Occorre infine cliccare ancora una volta sul bottone submit (dopo aver selezionato il checkbox sulla pagina dei dettagli) per ottenere finalmente il risultato desiderato.
Ben due (2) click per confermare l’azione contravvenendo alle più banali regole di interazione uomo-macchina.
Il submit button sulla pagina è a dir poco estraneo all’azione che l’utente andrà ad eseguire. Il button ha il compito di unsubscribe e come tale deve essere identificato e non con un generico ‘submit’. Chiarezza semantica come prima scelta, quando si progettano interfacce utente. La chiarezza implica l’uso di un lessico direttamente correlato alla azione così come la identifica l’utente e non come la identifica la business logic della applicazione.

Finalmente un’altra pagina mi informa che l’unsubscribe è andato a buon fine.

A questo punto l’utente ha perso di vista quale era il task che stava svolgendo.
Sono giunto sul website Oracle per il download di un software. Mi sono ritrovato costretto in una subtask posta a condizione del download per poi trovarmi in una ulteriore subtask della precedente per esprimere la mia volontà di unsubscribe da una mailing list cui mai avevo dato l’assenso.
Dove eravamo rimasti?

In uno sforzo di Customer Care da manuale teorico, Oracle vuole sapere come può migliorare (dato che non siamo interessati alle sue profferte di newsletters vi deve essere qualcosa che non va. In me?).

Questa pagina mi da due indicazioni:

Nessuna notizia ancora sul processo di registrazione. Come se nulla fosse, l’atto principale, la registrazione, passa in secondo piano rispetto alla sottoscrizione alle mailing lists offerte.
Il customer care di cui Oracle fa sfoggio in questa pagina coincide con la pura e semplice rottura di scatole dell’utente e la insistenza a proporre i propri servizi (non richiesti) in linea con la Customer Satisfaction da manuale teorico che poco o nulla sa del cliente (con la ‘c’ minuscola in quanto non entità astratta ma ben individualizzata).

Mi ritrovo, nella stessa pagina di comunicazione dell’ avvenuto annullamento della sottoscrizione (mai sottoscritta) di fronte un ‘confirm’ che, a dir la verità, poco o nulla si comprende cosa debba oramai confermare. La registrazione?
Se si, perché nella stessa pagina adibita all’unsubscribe? Non sono due task differenti che richiedono due step distinti?
Il contesto è la sottoscrizione ma la conferma a cosa si riferisce?
Faccio click per scoprirlo e, finalmente, parte il download del software (urla di giubilo. E altri sintagmi non riferibili).

Deduco che la conferma era su tutto ciò che finora era stato fatto. La registrazione è andata a buon fine e Oracle, per non tradire la sua esperienza nel settore usability, non si perita di dirmelo dato che il download partito non coincide con alcun messaggio o atto. Nessun segno riguardo ciò che sarebbe accaduto cliccando il bottone di conferma e nessun segno di quello che è accaduto una volta cliccatolo, escluso il download.
La pagina rimane li. Nessun redirect a pagine di interesse o ad un semplice ringraziamento per la pazienza fin qui dimostrata dall’ottuso cliente o, cosa che è stata annunciata a pagina 3, un redirect sulla pagina di login.
Niente di niente.

6 pagine per il download di un software. Che fine avranno fatto le istruzioni per la installazione dello stesso con tanta premura messe a disposizione dell'utente?

Chiudo la finestra deciso ad avere a che fare con il website Oracle il meno possibile, d’ora in avanti.

Ps. Il software oggetto della caccia è stato cestinato dopo 2 minuti 2 dalla installazione. Meglio il terminale che una GUI progettata coi piedi.