Tuesday, March 06, 2007 

Fighting the Useless Computer

I've been dealing a lot with user interface design in the past few weeks (briefly, while discussing some industrial automation systems, and quite deeply, while redesigning the human-computer interaction of a web-based PLM application).
As usual, the most difficult part is keeping the system out of the way while we try to understand the real users' needs. As I've argued before, there is often a difference between what the users are asking for and their realneeds. Like everybody else, users have an hard time separating their current practice from their fundamental tasks (or problems to be solved). Blindly implementing users' requests often results in a sub-optimal solution to their real problems, to the point that many have argued that IT does not really improve productivity.

There is, in fact, a very common syndrome, that I call "the useless computer". It's when a computer is used as a file cabinet on steroids. Indeed, the most common sign of the useless computer syndrome is a GUI centered around a multi-column grid where information has to be selected, filtered, ordered by the user. That usually happens because the computer doesn't know the last thing about what the user wants to do with that information, so it can't help at all.

Interestingly, the grid is a popular shortcut among programmers. I've heard countless stories about how users are actually requesting a grid. In facts, I believe the grid is a popular compromise based on mutual frustration: users who have given up on the idea that someone could really care about their needs, software developers who find users unavailable, illogical, fuzzy, contradictory, never satisfied.

Unfortunately, the tools we use are not helping us much either. I've never been a big fan of use cases, because they bring in the system way too soon. By analyzing and documenting "requirements" as a conversation between the user and the system, the focus is soon shifted away from the fundamental problem and toward a possible solution. Sure, rushing into implementation can be even worse, but use cases are a very unbalanced tool. Task descriptions, although quite similar, can be more effective. The KAOS approach, with its concept of goal and softgoal, can be quite effective too. Unfortunately, use cases have marginalized most other approaches: they're relatively easy for the software guys yet give almost-decent results. Most companies are fine with that, as they don't pursue excellence in solving the real users' needs.

As usual, it could be useful to take whatever it's widely used and improve it just a little bit, maybe by transplanting some idea from better approaches. A simple, neat idea that I've recently read about in a paper by Neil Maiden is to decorate the use case prose with attributes like [ENABLE] (or, I would say, [REINFORCE], and so on) followed by the name/id of a fundamental users' goal. This is very similar to what we do in KAOS, except that in KAOS the focus is on the goal themselves, while they play a marginal role here. Still, it's simple, is effective, and can be a small step in the right direction.
Comments:
La nostra storia

Abbiamo un prodotto software veramente datato: nato nel 1992 sotto DOS, migrato nel 1997 a WIN32.

E' cresciuto nel tempo arricchendosi di tante funzionalità introdotte per risolvere specifiche esigenze della clientela a scapito dell'interfaccia utente divenuta caotica, dispersiva e spesso poco funzionale.

Il marketing ha sollevato l'esigenza di un prodotto software connotato da un'interfaccia utente più razionale, dotato di minori funzionalità in altre parole più facile da usare.

Il prodotto nuovo è stato realizzato da tempo, ma pare che la clientela non stia impazzendo per esso.

Paura del nuovo? Troppa confidenza con le idiosincrasie del vecchio prodotto?

A proposito come sta andando/andrà con Office 2007 & Windows Vista?
 
Ohhh, finalmente un post su cui ci sia qualcosa da dire da parte nostra... :-)
E che post succulento! Entro subito a gamba tesa per avviare un po' di discussione.

1) Il problema dell'interfaccia utente e' vecchio come i programmatori. Ovvero da sempre i programmatori si intendono poco di interfaccia utente e producono robe inutili, brutte e macchinose. E c'e' da disperarsi, perche' i programmatori non sanno nemmeno valutare la bonta' delle UI. Questione di forma mentis che manca: la UI si impara, ma nessuno la studia.

2) Le UI progettate dai programmatori si annusano da un chilometro di distanza. L'odorino non e' dei migliori. Pensate a MS Visual Studio, per esempio: un campione di stupidita'. Ha un pannello di ricerca dei file cretinissimo. In troppi casi ci sono elementi non ridimensionabili che rendono una pena lavorare con stringhe lunghe. Avete mai provato a lanciare il debugger quando molti(ssimi) progetti richiedono un rebuild? La finestra che appare e' talmente alta che finisce fuori dallo schermo.

3) Le aziende spesso incaricano le persone sbagliate del compito di disegnare la UI. In generale non c'e' la cultura della UI. E si vedono i risultati... quanti sw inguardabili e inusabili. Ascoltare chi ha un minimo di senso estetico sembra un'eresia.

4) Parliamo di Word: e' semplicemente orrendo. Sono sbagliate le posizioni degli elementi, le proporzioni tra essi, i modi d'uso che il programma suggerisce sono astrusi e non intuibili. I vari help, wizard, cavoletti vari che dovrebbero aiutare occupano spazio utile e confondono. I menu che si estendono su richiesta? Ma dai, sono una cosa mostruosa!
Purtroppo Word viene pure preso come riferimento "standard", e cosi' le UI farlocche proliferano.

5) Parliamo di Windows Vista: a parte che ha copiato (male) Mac OS X, mamma mia quanto e' malfatto.
La cosina delle finestre in 3D e' semplicemente inutile: l'utente distingue soltanto la finestra in primo piano. In pratica e' un alt-tab con la preview della finestra, nulla di piu'. Pero' 3D, wow.
Odiosi tooltip che saltano fuori da tutte le parti. "Play": grazie, perche' il triangolo verso destra mi era oscuro. "Close": ah, ecco come si chiude una finestra. Dopo averlo visto due volte pero' ho imparato... e magari gia' lo sapevo prima.
E' proprio lo spirito con cui approcciano il design della UI che non va bene.

6) Carlo, dici che "the tools we use are not helping us much either". Non so bene a cosa ti riferisci, ma sono convinto che gli strumenti servono a poco se non si ha l'occhio allenato.

Ciao a tutti
 
La nostra storia - Post scriptum

L'interfaccia utente del nuovo prodotto è stata pensata da un utente evoluto non programmatore.
 
Citrullo a motore ha detto...
Ohhh, finalmente un post su cui ci sia qualcosa da dire da parte nostra... :-)

Detto questo il mio senso di frustrazione è minore. Mal comune... mezzo gaudio.

Carlo, vai pure per la tua strada. Non rinunciare alle tue speculazioni :-) Sta al maestro indicare la via e all'allievo seguirla (se gli va).
 
Si potrebbe avere qualche link a questo approccio KAOS? ho provato a cercare qualcosina, ma pare esistono parecchie ditte di design (non software :) con quel nome!! A hand is needed, please! A proposito delle grid, ricordo in quel vecchio post dicevi qualcosa tipo: "show the workflow" se non ricordo male. Credi che un approccio come quello proposto da microsoft con WF possa essere un passo nella direzione giusta?
 
In attesa di dire anch'io la mia sull'argomento e che Carlo mi fischi la punizione per la gamba tesa di Citrullo :-) posto il link per KAOS:
http://www.objectiver.com/en/documentation/

Nella pagina indicata, oltre ad altro materiale c'è il file KAOSTutorial.pdf
 
Grazie a michele per il Link! Questo blog ha da insegnare qualcosa al digitale terrestre in quanto ad interattività :))))
 
Scuri Romano ha detto...

Carlo, vai pure per la tua strada. Non rinunciare alle tue speculazioni :-) Sta al maestro indicare la via e all'allievo seguirla (se gli va).

Rileggendo a distanza mi rendo conto che traspare un certo tono denigratorio che non era nelle intenzioni. Scusa.
(Le parole sono pietre, alterazione percettiva... ricordi?)
 
Romano: qualche riflessione ispirata da quanto scrivi, che al solito rappresenta una buona opportunita' per chiarire meglio alcuni pensieri.

Ad un certo punto dici "più razionale, dotato di minori funzionalità in altre parole più facile da usare". Io parlo raramente di "facile da usare", perche' preferisco una interfaccia uomo-macchina mirata allo scopo ad una che raggiunge la facilita' d'uso attraverso [non sto implicando che sia questo il vostro caso :-)] minori funzionalità. Se mi serve una troncatrice radiale a movimento assiale (comprata qualche settimana fa, mi mancava :-) e tu mi dai un seghetto, questo sara' anche piu' facile da usare ma non mi serve. Pero' voglio uno strumento adatto al compito che voglio svolgere, non a qualunque altra cosa che non mi serve. Come dico spesso, quando una persona fa partire un programma [torno sulla cosa rispondendo poi al citrullo] ha un problema da risolvere o un obiettivo da portare in fondo. Tutto cio' che vorrebbe vedere e' un pulsante che fa tutto e solo quello che serve in quel momento :-).

In informatica, si rinuncia troppo spesso all'orientamento al task, perche' questo richiede piu' sforzo di analisi ed anche piu' sforzo di realizzazione. Si scarica tutto sull'utente, che si ritrova con uno strumento universale che deve saper gestire, configurare, ecc ecc. Si fondono in un unico strumento, a volte nella stessa schermata, informazioni e interazioni pensate per utenti totalmente diversi, per momenti totalmente diversi, ecc ecc.

Le ragioni sono tante, ed una di queste (che tangenzialmente citava anche il citrullo) e' la generale carenza di professionalita' specifiche. Ora, a differenza di Cooper (di cui ho parlato in altri post relativi a HMI) io non credo che il programmatore sia insanabilmente incapace di progettare una buona GUI (d'altra parte anche Cooper ha un background di sviluppo, non si capisce perche' lui debba essere capace e noi no :-). Pero' e' certo che senza studi specifici, e senza esperienza pratica, non si va molto lontano.

Giusto per completare il quadro, io sono altrettanto scettico sul fatto che un power user, se non e' a sua volta passato attraverso studi ed esperienze, sia in grado di progettare una buona GUI. Anzi, sin troppo spesso non fara' che forzare il proprio modo di lavorare, le proprie idiosincrasie, ecc su tutti i futuri utenti. Che e' la ragione per cui lo stesso Cooper di cui sopra propone di progettare l'interazione sulla base di utenti realistici ma non reali, consiglio che puo' sembrare un po' inusuale, ma se l'azienda riesce ad applicare una sana suspension of disbelief abbastanza a lungo da provare ad usarlo, nelle giuste situazioni puo' dare ottimi risultati...
 
Citrullo: sei uno dei migliori provocatori in circolazione :-)

Gli spunti che hai portato sono tantissimi. Alcuni li salto a pie' pari perche' sono troppo vaghi (quali elementi sono di posizione/proporzione sbagliata in Word, in quale versione, in base a quale ragionamento? Magari e' verissimo ma detto cosi' e' difficile valutare), ma alcuni sono davvero interessanti.

Qualche citazione sparsa:

E c'e' da disperarsi, perche' i programmatori non sanno nemmeno valutare la bonta' delle UI
Vero, ed in realta' ho visto lo stesso problema anche in molti self-made usability "experts". Non che sia facile, ovviamente. La cosa relativamente triste e' che pochissimi conoscono anche strumenti oggettivi come il modello GOMS (goals, operators, methods, and selection rules), definito negli anni 80 in The Psychology of Human-Computer Interaction di Card, Moran e Newell, e ripreso poi da Jef Raskin (che essendo uno dei creatori originali della gui del MAC dovrebbe esserti particolarmente simpatico).

In molti punti parli di senso estetico. Che ovviamente e' importante, ma che non deve e non puo' dominare sullo studio dell'interazione. Ho visto tante applicazioni (soprattutto web) studiate da grafici e poi passate ai programmatori. Molto carine da vedere, tremende da usare, perche' mettere tutte le scritte in tahoma corpo 8 thin, colore grigio chiaro su uno sfondo bianco ghiaccio fa tanto cool :-) ma fa anche colare gli occhi.
Lo studio dell'interazione e' il nucleo. L'implementazione da un lato, ed una buona grafica dall'altro (che include ad es. un opportuno studio delle proporzioni [che tuttavia hanno un significato che va ben al di la' dell'estetica e che vanno quindi considerate anche in altri termini], dei colori [stesso ragionamento], delle bitmap [con le giuste valutazioni in termini cross-cultural], ecc ecc) completano il processo. Le posizioni, tuttavia, fanno gia' in larga misura parte dello studio dell'interazione, e non dovrebbero essere sacrificate [troppo] all'estetica.
Ci sono anche altri fattori dove l'estetica entra in gioco, ad es. la differenza tra usabilita' reale e percepita (per un semplice esempio: Apparent Usability vs. Inherent Usability di Masaaki Kurosu e Kaori Kashimura).
Tuttavia l'estetica, lo ripeto, non deve guidare lo studio dell'interazione, ma solo informarlo.


Purtroppo Word viene pure preso come riferimento "standard", e cosi' le UI farlocche proliferano.
Premesso che forse io non disprezzo cosi' tanto Word, anche se non lo prendo come un esempio, approfitto invece di quanto dici per sottolineare un aspetto importante.
Esistono molte classificazioni delle applicazioni. Una che ho trovato molto comoda in alcuni casi e' "Tattica Vs. Strategica". Un'altra, che mi e' servita giusto nelle scorse settimane, e' "Creativa Vs. Burocratica".
Alcune applicazioni sono inerentemente creative. Se apro Word, PowerPoint, ma anche un CAD ed in larghissima misura anche un IDE, cio' che voglio fare e' spesso dare forma ad un'idea solo vagamente specificata. Mi serve una GUI che mi sostenga nel farlo [non che mediamente lo facciano benissimo].
Altre applicazioni sono inerentemente burocratiche. Se voglio pubblicare la nuova versione di un documento, o registrare una operazione di sportello, far partire una lavorazione programmata su una macchina utensile, ho bisogno di una interfaccia che mi guidi nel farlo nel modo piu' rapido e corretto possibile, senza tante divagazioni e senza lasciarmi li' ad improvvisare una strada creativa per ottenere cio' che voglio.
Purtroppo, molti sviluppatori (ma anche molti grafici) sono piu' abituati ad usare applicazioni "creative". E le prendono come riferimento unico, anche quando realizzano applicativi "burocratici". Non di rado [e qui mi ricongiungo con il post originale] tirando in ballo la flessibilita', gli utenti confusi, ecc ecc.

Parlando di strumenti, mi riferivo [ovviamente? :-)] agli use case come strumenti di analisi del problema. Che viene ancora prima dello studio dell'interazione (al solito, con un po' di iterazioni). Anche qui l'occhio allenato serve, ma non sugli aspetti estetici, quando sul vedere l'utente che fa qualcosa e capire dove finisce il problema vero ed iniziano soluzioni, come dici tu, "farlocche" :-).
 
Grazie per il "provocatore"... e' un complimento vero? ;-)

Una precisazione al volo:
Jef Raskin (che essendo uno dei creatori originali della gui del MAC dovrebbe esserti particolarmente simpatico).

Ahi ahi sei male informato! Tratto da un bellissimo sito, Folklore.org:

There's no doubt that Jef was the creator of the Macintosh project at Apple, and that his articulate vision of an exceptionally easy to use, low cost, high volume appliance computer got the ball rolling, and remained near the heart of the project long after Jef left the company.
[...]
But there is also no escaping the fact that the Macintosh that we know and love is very different than the computer that Jef wanted to build, so much so that he is much more like an eccentric great uncle than the Macintosh's father.
Jef did not want to incorporate what became the two most definitive aspects of Macintosh technology - the Motorola 68000 microprocessor and the mouse pointing device. Jef preferred the 6809, a cheaper but weaker processor which only had 16 bits of address space and would have been obsolete in just a year or two, since it couldn't address more than 64Kbytes. He was dead set against the mouse as well, preferring dedicated meta-keys to do the pointing.
[...]
Bill Atkinson [...] was almost singlehandedly responsible for the breakthrough user interface, graphics software and killer application that distinguished the Mac.


Interessante notare che il primo (tra le altre attivita') fu "author of over 300 articles on interface design, mathematics, science, computer science, and other subjects", mentre il secondo si e' dedicato a tempo pieno a fotografare la natura.

Chiusa la precisazione al volo, appena riesco elaboro una risposta.
 
provocatore in senso positivo, assolutamente...

forse varrebbe la pena leggere anche i commenti (alcuni un po' risentiti dello stesso Raskin :-) nel sito che citi (http://www.folklore.org/StoryView.py?project=Macintosh&story=The_Father_of_The_Macintosh.txt&characters=Jef+Raskin&showcomments=1#comments)

Non essendo un grande mac-fan, personalmente non mi dispiacerebbe molto se non fosse una totale creazione di Raskin (anzi :-)). Anche perche' se dici che Vista ha copiato MacOs, quanti si ricordano della workstation Star di Xerox (http://www.catb.org/~esr/writings/taouu/html/ch02s05.html, ma anche http://en.wikipedia.org/wiki/Xerox_Star) che ha ispirato cosi' tanto Lisa e successivamente il Mac? :-)
 
Dico la mia su un po' di argomenti sparsi che ho avuto modo di leggere nei commenti precedenti.

Quello che mi ha lasciato abbastanza sorpreso è che viene dato per scontato che un programmatore o un generico lavoratore IT debba avere una buona conoscenza di user interface. Sinceramente io non credo che questo sia vero; la UI rappresenta
soprattutto un problema di comunicazione e come tale andrebbe degnamente affrontato da esperti in tal campo. L'ultimo software che ho contribuito a realizzare per la sola parte dei colori si affidava ad uno studio da parte di una società specializzata, studio precedentemente fatto su misura per il nostro comune cliente. E via via con cose sempre più specifiche, per fare un esempio, gli stessi nomi dei menù sono stati sottoposti ad attenta revisione (una su tutte, ad un certo livello ci è stato chiesto di aggiungere l'articolo dinanzi ai vari nomi).
Tutto questo per dire che, a mio avviso, per interfacce complesse è necessario avvalersi di esperti di tale campo che non sono necessariamente esperti di IT. Come giustificare tali costi è un altro (terribile) problema :-)

Sul discorso del power user sono completamente d'accordo con Carlo. Il power user, in genere bravissimo ed utilissimo nel trovare i punti deboli della soluzione proposta, porta troppo spesso a suggerire soluzioni customizzate sul proprio modo di lavorare, oscurando la soluzione più interessante dal punto di vista generale.
A tal proposito, a mio avviso una soluzione che riscuote un certo successo in maniera trasversale nelle varie tipologie di utenti è, dove possibile applicarla, la UI a wizard; pochi semplici passi per arrivare in un certo stato (con un certa possibilità di "divagazione" su opzioni avanzate).

Vorrei infine chiedere a Carlo, se a proposito dei vari problemi della UI, anche lui ha rilevato quello della differenza temporale fra l'emissione dei requisiti funzionali e la stessa UI. Cerco di spiegarmi meglio; in genere i requisiti cambiano, mentre si è impossibilitati (per varie ragioni, ad es. apprendimento della UI da parte degli utenti) a modificare
sostanzialmente la UI. O ancora, si devono aggiungere nuove informazioni e si cerca il modo di farle star dentro schermate
preesistenti per evitare un aggravio di tempo/costi. Insomma, la mia domanda è: che approccio usi per rendere l'interfaccia
quanto più resiliente ai cambiamenti che possono incorrere nel tempo? Hai qualche lettura in proposito da consigliare?
 
Michele, sollevi due punti di estremo interesse (come sempre :-).

Riguardo la tua prima osservazione, distinguerei almeno tra le seguenti situazioni:

1) l'azienda assume che un qualunque programmatore sia un ragionevole "esperto" di usability, e/o non ha alcuna sensibilita' verso l'argomento, per cui ogni programmatore che venga a contatto con la GUI viene, di fatto, ritenuto il responsabile dell'interazione [per il suo sottosistema]. Questo fenomeno era molto diffuso, in alcuni settori lo e' ancora, anche per la dimensione artigianale a cui il software e' ancora ancorato. In genere, concordo con te, non da' grandi risultati.

2) come sopra, ma sostituiamo "programmatore" con "analista" o "progettista". Questa la lascio un attimo in sospeso, perche' merita un approfondimento a parte (tra poco).

3) l'azienda ha individuato una o piu' figure interne che pur avendo una competenza di software engineering, si occupano esplicitamente (per cultura e mandato) di user interaction. Eventualmente ha anche creato uno usability lab interno, ecc. Anche questo lo lascio un attimo in sospeso.

4) l'azienda si rivolge all'esterno per questi servizi, come citavi. Qui si puo' pensare di rivolgersi a figure con competenza di software engineering (siamo vicini al punto 3, e lo tratterei insieme) oppure di psicologia cognitiva e compagni, oppure di industrial design, o di grafica, ecc, ma non di software.
Qui purtroppo ho visto problemi non banali. Quando ci si rivolge con una richiesta molto ben delineata (es. scelta di colori ed icone per uniformare il branding di un insieme di soluzioni) la cosa va in genere in porto con facilita'. Quando ci si sposta verso un vero e proprio design dell'interazione, trovo in genere due grossi problemi:

a) occorre trasferire una grossa quantita' di informazioni sul business. L'interazione non si progetta nel vuoto, occorre mettersi nei panni di un utente che ha un problema [quale?] e si siede davanti al pc per risolverlo [come? cosa si puo' realmente fare e cosa no? quante di queste considerazioni riesco a fare senza una competenza di software engineering?]. Lascio da parte l'aderenza a normative, che e' comunque un aspetto di conoscenza del business (ricordo GUI carine che non aderivano alle norme della Food And Drugs Administration, ho visto innumerevoli casi dove una conoscenza anche parziale delle ISO 9241 sarebbe stata una manna, ecc).

b) [e questo mi porta a riprendere i punti 3/4 ma anche quanto dicevo nel post originale sugli use case] sempre piu', la frontiera dell'efficienza e dell'innovazione consiste nel riuscire a fondere insieme, durante la concezione del prodotto, le competenze del marketing [serio], della progettazione dell'interazione, della progettazione del software e degli altri eventuali componenti (hardware, infrastrutture, processi, ecc). Le persone coinvolte devono avere in parte competenze sovrapposte. I tempi in cui il marketing sognava cosa impossibili sono residui del passato, e' troppo inefficiente lavorare cosi'. Ecc. In quest'ottica, vedo male un esperto di "usability" che non capisce di software engineering, a meno che non sia in grado di lavorare in grandissima sinergia con chi ha queste competenze.

Faccio un salto verso gli use case: purtroppo, essendo uno strumento che porta a definire un dialogo (per quanto, volendo, di alto livello) tra uomo e macchina, e non a focalizzarci sui problemi / goal utente separati dal sistema, gli use case introducono sin dall'inizio elementi di interazione [abbastanza ovvio, visto che sono "casi di uso" di un sistema]. Questo e' particolarmente sbagliato, perche' il design dell'interazione e' una cosa ben distinta dall'analisi dei requisiti (o dei problemi/goal). A questo punto, se passo gli use case ad un designer dell'interazione che a sua volta non e' addentro al business, all'ingegneria del software, ad eventuali altre parti con cui il sistema di deve integrare, tipicamente ottengo qualcosa che quando va in mano al progettista software vero e proprio ha gia' assunto una forma totalmente inefficiente dal punto di vista dell'economia di sviluppo, e con buona probabilita' dell'economia di utilizzo. Avrei degli esempi concreti un po' lunghi da raccontare, magari una volta gli dedico un post specifico.

Detto ancora meglio [forse :-)], la progettazione e' ormai tutt'uno con la concezione del prodotto. Posso "subappaltare" parti minori (i colori che citavi) ma il resto va fatto da un team multidisciplinare ma ben addentro al business ed alle problematiche del sofware. Da questo punto di vista, le soluzioni (2) e (3) sono migliori, a mio avviso, se trovo le persone giuste [cosa non semplice, ovviamente]. In particolare, per quanto riguarda il punto (2) e' ovvio che non si puo' piu' pensare ad un analista o progettista "qualunque" e/o "fai da te", ma come gia' dicevo in risposta ad altri commenti, servono persone con studi ed esperienze mirate.

Se ci pensi, quanto sopra e' fortemente legato a quanto dicevi nella tua seconda osservazione. Lo scollamento tra requisiti e GUI e' la conseguenza netta di un partizionamento di competenze che porta a vuoti di efficienza. Poi possiamo metterci delle pezze tecnologiche: purtroppo non ho una letteratura da suggerire riguardo al problema interessante che proponi. Anzi, devo dire che le soluzioni comunemente adottate (finestre con tab multiple, procedure con sequenze di schermate, menu contestuali inerentemente estendibili, ecc) non e' che mi facciano impazzire di gioia :-), ed in effetti queste attivita' di refactoring le affronto sempre in modo molto custom, ovvero guidato dal business, dal problema, dalla singola schermata... e non di rado sono il primo a dire che pazienza, la schermata va cambiata radicalmente, e pazienza, anche gli utenti se ne faranno una ragione (affermazione molto impopolare :-). Quello che pero' posso dire per esperienza diretta e' che quando il prodotto viene concepito come accennavo sopra, questo tipo di problemi si riduce moltissimo.

Provocazione: le schermate in cui ogni utente vuole un pulsante in piu', un dato in piu', uno in meno, ed uno spostato, sono sempre quelle con una griglia al centro :-)))).
 
Rispondo alla loffia provocazione di qualche post fa... :-)

I commenti risentiti di Raskin (link sbagliato?) non mi sembrano confutare quanto detto sul suo contributo alla UI del futuro Mac.

Non essendo un grande mac-fan, personalmente non mi dispiacerebbe molto se non fosse una totale creazione di Raskin (anzi :-))
Questa proprio non la capisco. Che vuoi dire? Che non ti piaceva la UI del Mac? - Infatti per te hanno fatto il DOS e Windows 3.11, te li sei goduti eh! ;-)

Anche perche' se dici che Vista ha copiato MacOs - qualcuno afferma il contrario? - quanti si ricordano della workstation Star di Xerox che ha ispirato cosi' tanto Lisa e successivamente il Mac?
Quindi Vista ha copiato dalla Star, certo! :-)
Io me la ricordo benissimo. La visita di Jobs alla Xerox non e' un mistero, essendo stata pagata a peso d'oro dalle casse di Apple, e ampiamente evocata in libri e siti. Ma non facciamoci trascinare in un lunghissimo discorso su chi ha fatto cosa piu' di 20 anni fa... Se no, poveri lettori del blog!

Comunque vengono fuori spunti interessanti anche da questo richiamo della Star. Gia' alla fine degli anni '70 i ricercatori della Xerox avevano capito che ci vuole "Good graphic design. Screen graphics designed by computer programmers will not satisfy customers. The Star designers recognized their limitations in this regard and hired the right people for the job."
http://www.guidebookgallery.org/articles/thexeroxstararetrospective
Molto istruttivo e' seguire le evoluzioni del disegno delle icone, i diversi font bitmap, lo studio di proporzioni e dimensioni. Ci sono anche altre immagini sul web ma ora non le trovo.

La qualita' della UI si misura anche e soprattutto in cio' che l'occhio ingenuo classifica come pura estetica, senza valore reale. Certo, il font chiarissimo su fondo chiaro forse fa cool, ma non c'entra nulla con una buona UI. Guardiamo la pulizia della UI del Mac del 1984 e confrontiamola con le altre UI del tempo. Sulla carta facevano le stesse cose, ma poi in pratica... erano peggiori.

Tornando ad oggi, e letti gli spunti degli ultimi post, deduco che:
1) allora e' proprio vero che i programmatori sono inesperti di UI, ed e' vero che la questione della UI e' quasi sempre mal gestita dalle aziende;
2) per costruire una UI eccellente non c'e' strumento o metodo che tenga, e' un'arte (anche programmare bene e' un'arte, questo si sa).

PS: non capisco del tutto la frase di Carlo "la progettazione e' ormai tutt'uno con la concezione del prodotto". Non e' sempre stato cosi'?
 
L'ultima parte del precedente post di Citrullo non mi trova affatto d'accordo.

Il punto 1) mi lascia perplesso, poichè al di là di esempi negativi che tutti noi potremmo citare (ricordo un sito Interface Hall of Shame, probabilmente non più aggiornato) mi sembra che sull'argomento nelle aziende si stiano facendo notevoli passi avanti e credo si farà sempre meglio. D'altra parte la problematica è abbastanza recente e la scienza vuole i suoi tempi.

E quanto sopra mi porta al secondo punto. Spero che non si cada nei meandri di una polemica etimologica (arte fra le varie definizioni è anche metodo o maestria nell'operare secondo certe regole). Ma il nostro lavoro non è arte, ma scienza (sistema di cognizioni acquisite con lo studio).
E, Citrullo, non mi dire di no, altrimenti quando trovo codice di colleghi tanto tanto "artisti" ti chiedo di correggerlo al mio posto :-)
 
Citrullo, rispondo solo al tuo "Non e' sempre stato cosi'?".

La risposta e' no, ed in molte aziende (inefficienti) non e' cosi' neanche oggi.

Anche in molte aziende di puro software, non di rado la concezione del prodotto avviene a livello marketing, e lo spazio dei progettisti e' piccolo e/o si risolve in una negoziazione, anziche' in una partecipazione attiva alla concezione del prodotto. Con perdite di efficienza incredibili.

In aziende dove il software e' visto (a volte per ragioni storiche) come una attivita' collaterale al core business (es. molto del settore industriale) la situazione e' di gran lunga peggiore: il software e' in fondo ad una catena lunghissima, dove anche tutto il resto della progettazione ha gia' avuto luogo (meccanica, elettronica, ecc).

Ma le aziende che non dormono se ne stanno via via accorgendo, grazie anche ad un po' di ricambio generazionale nel management, e le cose stanno cambiando (in meglio).
 
Michele: "la problematica è abbastanza recente e la scienza vuole i suoi tempi".
E' da 20 anni che si fanno GUI... chi le fa meglio, chi le fa peggio.

"Ma il nostro lavoro non è arte, ma scienza (sistema di cognizioni acquisite con lo studio)."
Lungi dal voler affrontare la discussione etimologica, non temere! :-)
Non saprei se il nostro lavoro nella sua globalita' e' arte o scienza, forse per la maggior parte e' banale tecnica (come tanti altri lavori).
Di sicuro il metodo e' quello scientifico, non quello artistico, e fin qui siamo tutti d'accordo. E intimamente mi sento scienziato, senza dubbio. Pero' parlavo precisamente della programmazione, non del nostro lavoro in generale.

Da Wikipedia: "Per scienza si intende un complesso organico di conoscenze ottenuto con un processo sistematico di acquisizione delle stesse allo scopo di giungere ad una descrizione precisa della realtà fattuale delle cose, e in ultima analisi di una verità universalmente condivisa."
Giungere a una verita' universalmente condivisa: mah... Prendiamo un po' di righe di codice scritte da un altro. L'unica sentenza "scientifica" ammissibile e' se il codice risponde ai requisiti (cioe' se funziona). Poi si puo' discutere all'infinito su tutto il resto: e' indentato bene? Usa i giusti nomi per le variabili? E' il "miglior" codice possibile?
Tutta roba che mi aspetterei fosse universalmente condivisibile, ma sappiamo bene che non e' cosi'.

"L'arte, nel suo significato più ampio, comprende ogni attività umana - svolta singolarmente o collettivamente - che, poggiando su accorgimenti tecnici e norme comportamentali derivanti dallo studio e dall'esperienza, porta a forme creative di espressione estetica."
Questo mi sembra molto piu' appropriato! Studio ed esperienza, quello che facciamo tutti i giorni. Forme creative (altrimenti il computer potrebbe programmare in nostra vece) di espressione estetica (ma quanto e' estetico il codice... :-).
"L'arte può essere considerata anche sotto l'aspetto di una professione di antica tradizione svolta nell'osservanza di alcuni canoni codificati nel tempo."
Questa frase e' veramente azzeccata: pensiamo alle numerose consuetudini che ci guidano nella scrittura del codice, come cambiano da periodo a periodo; pensiamo ai pattern!

Sia chiaro che cerco solo spiegare meglio il perche' della mia affermazione, non di far passare per assoluta una convinzione personale.
 
Gia' che siamo in tema di UI propongo questo link (poi la smetto lo giuro):
http://www.pfeifferreport.com/
trends/trend_vistauif.html

Parla di UIF, User Interface Friction, ovvero quanto e' fluida e responsiva una UI.
Al di la' dei risultati, che relegano Vista in fondo alla classifica, credo sia un bello spunto che fa riflettere su aspetti normalmente non considerati (e sul tipo di lavoro a monte di certi risultati).
 
Approfitto del link che ci hai fornito per aggiungere qualche considerazione.

- in effetti la precisione del mouse sotto Windows lascia a desiderare. Siccome pochi post fa parlavi del DOS, devo dire che in effetti il programma che, negli anni, mi ha dato la massima sensazione di "precisione" (intesa come corrispondenza tra cio' che volevo fare e cio' che succedeva sul video) era un vecchio programma DOS (Dr. Halo, qualcuno magari lo ricorda). Va anche detto, e qui anticipo qualcosa sul prossimo punto, che all'epoca la risoluzione dello schermo era bassa, il mouse non veniva tipicamente utilizzato in modalita' balistica, ed era pressoche' totalmente sotto controllo delle applicazioni.

- io mi sono letto sia il report striminzito (html) che quello piu' "dettagliato" (pdf) che un altro pdf dove parla in generale di friction e spiega un po' meglio cosa misura (es. di quali menu sta parlando) e come. Visto che sempre in questo post parlavate di scienza, quando ne hai voglia fai un bell'esercizio di metodo scientifico :-) e rileggili con occhio neutro. Troverei scortese nei confronti degli autori elencare tutti gli errori metodologici in cui sono incorsi, la mancanza di dati oggettivi forniti (es. quante persone hanno fatto il test di precisione? come sono state scelte? che mouse hanno usato? un ottico? un touchpad? :-> ecc ecc). Poi sicuramente il mouse medio sotto Windows e' poco preciso. Ma in quei report si sfiora il ridicolo (sulla storia dei menu decisamente di piu').

Piccola coda: un bravo progettista deve leggere con occhio critico, senza fidarsi di qualcosa solo perche' conferma le sue idee. Un mio vecchio su temi analoghi:
www.eptacom.net/blog/2005/07/trust-and-beliefs.html

Poi nei giorni scorsi ho ricevuto alcune email che "filtrano" nello stesso modo, stavolta citando fonti Microsoft... scienza, arte o ... religione? :-))))
 
Ullalla' come vai sul pesante... mi dai del "religioso" scientifico, peggio che "artista"! :-)
Allora mi obblighi a rispondere, con probabile ulteriore tedio degli altri lettori.
L'ho letto tutto quanto l'articolo del pdf (prima di citare il link, pensa un po'!) e non mi sembrava cosi' scandaloso: e' una chiacchierata con un po' di numerini presi col cronometro, senza chissa' quali pretese, e non fa conclusioni cosi' campate in aria...
Sara' che ne ho letti gia' tanti di report analoghi, e che non li considero affatto "scientifici", bensi' ispirati dal buonsenso e dall'esperienza pratica, difficilmente misurabile, ma soprattutto non li considero tali perche' studiano qualcosa che dipende da premesse inevitabilmente soggettive (o di parte, se ti piace di piu').
Come fai a pretendere scientificita' da una affermazione del genere: "User Interface Friction has been defined by Pfeiffer Consulting to define and quantify the user experience and efficiency of operating systems, siftware and digital devices"?
A parte l'errore ortografico che butta giu' parecchio, le parole "consulting" e "define and quantify" la dicono lunga! ;-)

Ma comunque chi se ne importa dei risultati, a me interessava dare un riferimento per un argomento come spunto di riflessione, senza stare a scrivere un post lungo. Adesso dicci cosa ne pensi: sono argomenti senza valore, poco tangibili, o meritano un po' di attenzione?
 
In realta' il religioso non era diretto in modo specifico verso di te :-), poi lo sai che ripongo in te grandi speranze...

sono argomenti senza valore, poco tangibili, o meritano un po' di attenzione?
Temo che la storia diventi rapidamente molto piu' lunga del dovuto, ma dico comunque qualcosina:

Purtroppo le critiche quantitative fatte male sono particolarmente deleterie: molto meglio una critica qualitativa mediocre. Anche perche' le persone hanno la tendenza a "credere" ai numeri in modo acritico.

Nello specifico, come dicevo, e' piuttosto evidente che Windows abbia seri problemi di precisione nel puntamento con il mouse.
Una analisi un minimo seria, pero', non puo' non documentare:
- i mouse scelti
- quanti utenti scelti
- come scelti
- come usati: ruotati tra i diversi computer, in che ordine, ecc
- la DEVIAZIONE STANDARD e non solo la media.
- meglio magari provare con piu' di un software, chi dice che e' proprio colpa del mouse [lo so a livello qualitativo, non posso permettermi queste cose a livello quantitativo].
Ad es. non giurerei che con un ottimo mouse le cose cambino.

Sulla storia dei menu siamo messi decisamente peggio. Intanto confonde cose che non c'entrano nulla (il menu "start" con i menu di excel o altri applicativi).
Ora, il menu start e' una idiozia per tante ragioni. E' un deciso passo indietro rispetto a Windows 3.1 :-).
Una buona critica qualitativa che mostri le alternative sarebbe piu' che interessante. Una critica quantitativa, di nuovo senza riportare la metodica, la deviazione standard, il numero di applicativi installati, ecc ecc e' del tutto priva di senso. Anche perche' poi molti utenti per le applicazioni che usano maggiormente usano la taskbar, o il desktop come area di lancio.

Per quanto riguarda i menu degli applicativi, trascurando che il tizio ignora tutta una serie di fattori (se il menu e' owner-drawn Windows c'entra solo in parte con la responsivita'), a parte i soliti problemi di metodo (con tempi medi cosi' vicini, per di piu' presi a manina, se non vedo la deviazione standard non concludo niente), ed a parte che i tempi che cita sono del tutto inverosimili almeno per il mio PC (ovvero ci sto MOLTO meno), di nuovo va capito quanto questo suo concetto di "friction" possa essere quantitativamente definito in quel modo, ovvero se le cose che misura hanno un impatto reale sulla vita dell'utente. Ad es. personalmente trovo le toolbar lente piu' fastidiose di un menu lento, anche perche' nel menu ci vado quando non so qualcosa, quindi in media sono lento io piu' del menu. Odio gli applicativi lenti su altre operazioni (selezioni, disegno, scroll: lo scroll in modo particolare credo che per certi applicativi si "senta" molto piu' della lentezza del menu), ecc ecc. Le sue definizioni mi sembrano molto pretestuose, a dire poco.

Cio' non toglie che misurare la velocita' dell'interazione in diverse situazioni sia molto interessante, bisogna pero' capire il modello dell'applicativo, come viene usato, ecc. Misure custom insomma, che ci aiutano a migliorarlo.

Misurare "Windows" (con che scheda grafica poi, impostata come, ecc ecc) piuttosto che un qualunque altro sistema operativo che gira su hardware "qualunque" (es. Linux con qualche toolkit grafico) mi pare invece un'idea piuttosto peregrina.
 
Ciao Carlo,
potresti chiarirmi un aspetto della metodologia KAOS, comparata con il più "tradizionale" (o forse dovrei dire diffuso) approccio a use-case? Mi sembra di capire che in KAOS i requisiti vengono descritti sostanzialmente come goal (a vario livello) riferiti agli stakeholder. I goal vengono tipicamente raggruppati in "generic patterns of requirements" da cui, ad esempio, poter raffinare "needs" sia di tipo funzionale, sia di tipo non funzionale. Per contro, gli use case descrivono aspetti tipicamente funzionali.

Mi sembra che i due approcci riferiscano in parte informazioni diverse e che comunque l'utilizzo dell'uno non escluda l'altro. (Non parlo di merging, come forse intendevi suggerendo l'uso di [REINFORCE] nella prosa dello use case, ma di far convivere due modelli distinti, che però dicono cose diverse). Mi spiego. Talvolta descrivere un'interazione in termini di conversazione tra utente e sistema può facilitare la comunicazione con gli stakeholder, nonostante il problema dello sbilanciamento verso la soluzione (in parte mitigato dall'utilizzo di un vocabolario di dominio orientato al problema (e ai goal :), vedi i suggerimenti di Cockburn). Viceversa, negli use case (e nonostate l'approccio "alla Cockburn") è talvolta davvero difficile distinguere - a basso carico cognitivo - informazioni al giusto livello d'astrazione per capire il goal sottostante, prima ancora dell'interazione, per non parlare dei goal non funzionali.

Mi rendo conto che far coesistere due modelli contemporaneamente è un problema (sincronizzazione, tempo, tools...), ma se devi tagliare un tronco e una siepe, usi per entrambi una cesoia o ti attrezzi diversamente? :-)

Assumo ovviamente che sia importante rappresentare in qualche modo sia i goal degli stakeholder (soprattutto quelli non funzionali), sia le funzionalità tipiche del sistema.

Che ne pensi?

Ciao,
Andrea Baruzzo
 
Andrea,
la risposta "teorica" e' semplice: certo che si puo' :-). E' anche in linea con la visione UML di usare modelli diversi per rappresentare concern diversi. Anzi, in quest'ottica, essendo UML molto debole nella modellazione dei goal, aggiungere un diagramma KAOS-like non farebbe neanche male (io ho usato con alterni risultati uno use case diagram "stiracchiato" a suon di stereotipi).

Nella pratica poi diventa un discreto problema, per le solite ragioni: cross-reference da tenere sincronizzati, poca abitudine di molte aziende a dedicare tempo alla analisi dei goal, ecc ecc.

A dirla proprio tutta, in molti casi concreti il beneficio degli use case + KAOS e' un po' piccolino. Dipende molto dal dominio applicativo, ed anche dalla strategia aziendale, ma in piu' occasioni ho visto che se siamo abbastanza furbi da modellare i goal, adottare la tecnica dei personaggi per modellare gli utenti, e il problema si presta, e' molto meglio usare KAOS + low-fidelity gui prototyping. Li trovo strumenti piu' creativi, mentre gli use case tendono ad irregimentare le idee molto presto (ovviamente, non sempre e' un male).
 
Post a Comment

<< Home