L’ottimo articolo del 24 settembre sulla storia di “Clippy the Paperclip” di Felice Pescatore ha ispirato in qualche modo quello che andrete a leggere di seguito. In questo articolo cercherò di esprimere la mia visione circa i problemi di interazione uomo computer. Tengo a specificare che non sono un esperto di HCI (anche se ho studiato qualcosa a riguardo durante la mia carriera universitaria) quindi quanto leggerete è principalmente frutto di una analisi empirica di ciò mi capita di osservare.
Come scritto da Felice nel suo articolo l’utilizzo di agenti è basato sulla teoria che i computer siano in qualche modo “attori sociali”. Per quanto si possa condividere questa visione è sotto agli occhi di tutti il fatto che non abbia portato i vantaggi immaginati.
Nella realtà delle cose chiunque abbia avuto a che fare con agenti software sofisticati ha in qualche modo finito per odiarli profondamente, confermando le basi della teoria (odiare un componente software è pur sempre un interazione sociale) e evidenziandone allo stesso tempo i limiti implementativi.
Il problema fondamentale però secondo me non risiede nell’implementazione degli agenti ma nelle applicazioni che ne fanno uso. Per far capire meglio il mio punto di vista provate a immaginare questa situazione:
Un preparatissimo istruttore di volo che spiega la funzione dei dispositivi di pilotaggio di un Airbus ad un passeggero preso a caso.
Per quanto l’istruttore possa essere preparato il passeggero difficilmente riuscirà a capire qualcosa vista l’enorme complessità del sistema. Prendete questa realtà e riversatela nel mondo dei computer, e vedrete che potete far combaciare l’istruttore di volo con un assistente virtuale, la plancia dell’aereo con l’editor di una suite d’ufficio, e il passeggero preso a caso con una persona non avvezza all’utilizzo di strumenti informatici.
Trova le differenze! :P
La differenza sostanziale è che tutti gli strumenti sulla plancia dell’airbus sono fondamentali per farlo volare in sicurezza mentre le funzioni esposte di una generica suite di ufficio sono per il 90% inutili all’utente medio. Inoltre la complessità del programma si riverserà con tutta la sua forza sull’assistente che in qualche modo dovrebbe avere una base di conoscenza praticamente infinita per rispondere in maniera opportuna a tutte le possibili combinazioni di eventi.
Ed a questo punto arrivo a esprimere la mia idea. In linea con uno dei pilastri della filosofia Unix credo che gli sviluppatori debbano entrare nella mentalità di sviluppare singoli programmi che facciano un solo compito e lo facciano bene. Se ci pensate bene gli strumenti di maggior successo nel mondo reale sono quelli estremamente semplici e mono-funzione.
Quale strumento utilizzereste per tagliare il pane?
Seguendo questo paradigma non solo si semplifica l’interazione con l’utente ma si riduce anche il campo di azione di un eventuale agente di supporto. Pensate per esempio a twitter. Se misurassimo le potenzialità di twitter con una analisi delle feature ne uscirebbe con le ossa rotte. La realtà è che la sua stessa natura l’ha reso appetibile ad una fascia amplissima di pubblico decretandone il successo. Il campo ristretto in cui opera ha permesso anche l’inserimento ben riuscito di “piccoli agenti software” dalle funzionalità limitate ( il servizio consiglia chi seguire in base alle mie informazione e ai miei conoscenti).
Un altro esempio che mi piace riportare è quello delle piccole o piccolissime applicazioni per smatphone. Per esperienza diretta so che vengono utilizzate con profitto anche da persone solitamente impacciate con l’uso del PC. Questa tendenza nel mondo mobile è stata dettata probabilmente dall’iniziale scarsezza di risorse dei dispositivi (schermo e capacità elaborative), ristrettezza che invece di affossare tali soluzioni ne ha decretato il successo su scala mondiale.
Concludendo, mi sento di poter affermare che prima di pensare alla lista delle feature bisogna decidere bene quale deve essere lo scopo fondamentale di una applicazione. In ottica di usabilità bisogna avere il buon senso di capire che non sempre togliere significa sminuire il valore di un progetto.
Se non vengono fatte scelte in questo senso nemmeno il migliore degli assistenti potrà mai rendere piacevole l’utilizzo di software.
Però, restando sul piano dei social network, facebook ha avuto un successo anche maggiore ed è al contrario un “multiuso”, con foto, chat, messaggi, video, giochi, etc etc
Anche l’approccio tutto-in-uno ha i suoi vantaggi.
Io ho sempre trovato clippy e compagnia fastidiosi perché apparivano mentre stavo lavorando, distraendomi da quello che stavo scrivendo o facendo senza che percepissi di avere bisogno del loro aiuto. Un po’ come guidare con qualcuno accanto che ti dice “rallenta! occhio al semaforo!” e cose del genere quando tu sei capacissimo di guidare.
Certo, il mio punto di vista non è quello dell’utente totalmente alieno all’uso del computer che fatica a usare word per scrivere una lettera, ma sono davvero quelli gli utenti che odiavano di più la dannata graffetta?
tar xzf Ice-3.4.0.tar.gz
Ricambio i complimenti per l’interessantissimo articolo.
In particolare l’aggancio alla filosofia Unix (dove ogni comando fa solo una cosa ben precisa ed è possibile concatenarli per operazioni più complesse) merita davvero attenzione.
Ritengo, però, che esista la spazio per le applicazioni “puntuali” e quelle “complesse”. Le prime sicuramente interessano oltre il 90% degli utenti che vogliono semplicità ed immediatezza, avendo sempre meno pazienza nell’uso delle tecnologie (si veda Windows Phone 7). Le applicazioni complesse sicuramente sono fondamentali in ambito professional dove gli investimenti sono importanti e spesso la necessità di avere ambienti di lavoro integrati con funzioni che si utilizzano anche solo pochissime volte è concreta (uno per tutti Visual Studio o Autocad)
Facebook ha guadagnato consenso quando era un semplice punto per rimanere in contatto e condividere eventi e foto in maniera estremamente semplice. Tutto il contorno è nato dopo. Quando ormai la massa critica (punto fondamentale in una rete sociale) era stata raggiunta.
Detto questo sono fermamente convinto che facebook sia il classico esempio di applicazione “bloated” che andrebbe ripensata in molti punti (e se ci fai caso l’interfaccia per le operazioni core è stata ripulita e stravolta spesso). Opera ovviamente molto difficile per via dell’abitudine dei milioni di utenti.
Sono straconvinto che gran parte degli utenti interagisca solo ed esclusivamente con la bacheca e ignori tutto quello che c’è “intorno”.
Questo non lo metto in discussione ma generalmente rende il processo di apprendimento più difficoltoso. Un utente non avvezzo alla tecnologia solo se motivato (se non usi facebook sei “out”) decide di investirci tempo. Altrimenti etichetterà la cosa come inutile e la scarterà senza troppi problemi.
La odiava chi sapeva già cosa fare (come giustamente hai detto tu) e chi non sapendo nemmeno cosa potesse fare con il programma si trovava consigli non adeguati.
@Cesare Di Mauro @Felice Pescatore
Da diverso tempo sto cercando di elaborare un concept che porti la semplicità e flessibilità dei comandi unix composti con il meccanismo delle pipe nel mondo delle interfacce grafiche. Per adesso ho qualche idea di fondo molto vaga e probabilmente malsana ma forse un giorno riuscirò a metterle su carta in maniera razionale. ;-)
OpenDoc!
http://en.wikipedia.org/wiki/OpenDoc
ottimo articolo, concordo in pieno con la filosofia di UNIX e dei sistemi mono uso, resta il fatto che la standardizzazione della sintassi dei comandi è qualcosa da tenere con grande attenzione…
Sono in parte d’accordo con la filosofia UNIX, ma più che a la UNIX propenderei per un modello a la iLife.
Una suite di programmi con finalità specifiche (con parziali sovrapposizioni in alcuni casi), ma strettamente integrati fra l’oro.
Ecco secondo me se si vuole premiare l’approccio con applicazioni distinte non si può però prescindere dall’integrazione fra le varie entità, altrimenti il flusso di lavorò sarà interrotto brutalmente e imho ciò aumenta la frustrazione dell’utente e diminuisce la produttività.
E’ anche vero però che nel caso di applicazioni tutto in uno, troppo spesso chi disegna l’interfaccia non si degna minimamente di curarla.
Per esempio analizzando quali funzionalità sono più utili/usate e presentando nella finestra solo quelle.
Molti invece si limitano all’approccio un’opzione/feature = un bottone e sbattono tutto nella GUI come nello screenshot parecchio azzeccato.
@Emanuele: però il tar xzf non usa pipe… :P
Comunque un’interfaccia “a pipe” non riesco nemmeno a immaginarla. :-/
@Cesare
Si, si, lo so… è che quando ho letto tar subito mi sono ricordato di essermi trovato qualche volta a utilizzare giochetti di questo tipo:
http://www.linuxquestions.org/questions/linux-software-2/tar-%7C-ssh-tar-tar-syntax-issues-510787/
E da li l’associazione mentale con il meccanismo delle pipe. :D
L’idea di una GUI “a pipe” mi ricorda quello che si fa con gli strumenti di BPM (es: jbpm) dove si concatena l’input e l’output di moduli grafico/funzionali.
@Emanuele Rampichini
Beh semplice:ogni microprogramma ha nella sua finestra 2 “aree”, quella a sinistra di input e quella a destra di output. Trascini l’output di un programma sull’input dell’altro e ti appare una bella freccia che indica la direzione dei dati :D
@Sam
Interessante… mi documenterò su openDoc
@alessiodp
Vero… d’altra parte sempre di interfaccia stiamo parlando.
@Massimo C
Non conosco iLife ma capisco cosa intendi e anche questa è una caratteristica che apprezzo molto.
@Andrea Del Bene
In generale è la visione dei workflow management system. Per una piccola tesina universitaria ho utilizzato Taverna http://www.taverna.org.uk/ . Come concetto “ci siamo” (workers, porte di input e porte di output) ma l’utilizzo richiede spesso una preparazione tecnica di livello troppo alto per l’ambito in cui stavo “fantasticando” io. Sono ancora convinto che il file sia una delle poche entità di facile comprensione per tutti e baserei su quelli l’interscambio.
Il discorso: “un’applicazione deve svolgere solo un compito e in modo corretto”, mi sembra che ultimamente non venga preso in considerazione. Sembra che oggi esista solo il browser e deve saper fare qualsiasi cosa: video player, grafica 3d, videoscrittura, addirittuta sistema operativo.
Come la vedete questa cosa?
@olivobestia
Ecco… il browser è il tipico caso particolare. Il browser “per se” serve a poco… possiamo considerarlo in un certo senso il “sistema operativo del web” quindi secondo me ha più senso considerare ciò che gira dentro al browser come applicazione. E in questo senso vedo molto di buon occhio il lavoro fatto da Google con Chrome e da MS con il nuovo ie9. Interfaccia essenziale, tanto spazio per i contenuti e attenzione puntata al 100% alle funzionalità centrali (motore di rendering, motore javascipt etc…).
Per dirti: per quanto consideri Opera un ottimo software, ottimamente scritto, innovativo e con mille idee interessanti trovo in qualche modo fastidioso il suo “voler far tutto”.
Uhm, l’idea degli “agenti intelligenti” interattivi come strumenti di ausilio nell’interazione tra utente e interfaccia grafica di un’applicazione mediamente complessa mi ha sempre lasciato un po’ con l’amaro in bocca.
Sono piuttosto perplesso circa l’opportunità del giustificare l’adozione di “agenti intelligenti” solo in virtù del fatto che un computer possa essere considerato come un “attore sociale”.
Riferendoci alla teoria sottostante, sicuramente possiamo considerare un computer moderno come un “attore sociale”, ma, a mio avviso, ciò non basta a giustificare la presenza di Clippy (o chi per esso) nel mio word processor.
Affinchè la presenza di Clippy sia giustificata, esso deve poter essere considerato come un effettivo “agente intelligente”, il che implicherebbe una certa raffinatezza ed evoluzione nell’intelligenza dimostrata da Clippy all’utente.
Ovvero, Clippy deve essere percepito come efficace, dall’utente umano.
Se l’utente è “scafato”, non ha certo bisogno di un Clippy che salta fuori ogni 2×3, vorrà invece lavorare in pace, e avere un accesso rapido a tutte le funzionalità presenti, ovviamente in particolare a quelle che effettivamente gli occorrono. Più spesso una funzionalità viene usata nel tempo e più sarà importante garantire un rapido accesso ad essa (inteso come numero di click o equivalenti per raggiungerla/attivarla).
Invece per la visibilità sono indeciso: una funzione che uso tantitssimo non occorre che sia molto più visibile delle altre, so già dove si trova (qui però si dovrebbe parlare dei menu, in particolare di quelli radiali, e adesso che ci sono i touch screen anche di nuovi modi di interfacciarsi [pensare a un’applicativo che ci permette di associare una funzione con un gesto tracciato con un dito a mo di simbolo]).
Questo discorso, dal mio punto di vista, va bene dal momento in cui l’utente è esperto e per applicativi con tante funzionalità e/o con un controllo della singola funzionalità molto fine.
Probabilmente si possono adotare delle strategie differenziate per gestire i due aspetti: dico, quello relativo alla quantità di singole funzionalità (mascheramento, presentazione basata sul profilo scelto dall’utente [utente con ruolo]), e quell’altro relativo al numero di opzioni di controllo della singola funzionalità (incapsulamento, convention over configuration per semplificare).
Se ad esempio l’utente è un novizio, l’interfaccia dovrebbe presentare una vista di default estremamente semplificata di se stessa (dove la visibilità e la velocità di accesso ad ogni funzionalità è decisa in base a criteri che mirano a soddisfare la casistica più ampia possibile di utenti, presupponendo una “scolarizzazione” degli stessi, informaticamente parlando, ragionevolmente bassa) dove molte funzionalità tranne le più essenziali sono nascoste, e la maggior parte delle opzioni per la singola funzionalità non richede un’esplicita configurazione da parte dell’utente (convention over configuration) essendo già preimpostata per coprire la casistica comune.
L’applicazione dovrebbe poter registrare e analizzare nel tempo l’uso che l’utente fa dell’interfaccia e la preferenza dello stesso circa le attvità portate a termine mediante le funzionalità esposte, e adattare la UI rispetto a un criterio che miri a ottimizzare visibilità e velocità d’accesso alle funzionalità e/o opzioni delle singole funzionalità sulla base dei dati di utilizzo raccolti.
@olivobestia
Beh, il browser è una bestia strana come detto da Emanuele. E’ chiaro che oggi le sue funzionalità si sono espanse ben oltre la sua vocazione naturale, ossia fare il parsing ed il rendering di un sorgente HTML. Il problema è che le funzionalità sono state aggiunte in maniera graduale da diversi attori che agivano per conto proprio ed alla fine ci siamo ritroviamo tante funzionalità senza uno strumento comune per orchestrarle.
In questo modo oggi se vogliamo fare un sito che permetta un minimo di interazione dobbiamo palleggiarci tra almeno 3 tecnologie diverse (HTML, JavaScript e il linguaggio server side).
Per questo penso che organismi come il W3C, con tutti i loro limiti e difetti, siano comunque da apprezzare perchè in qualche modo si sforzano di emanare degli standard per mettere un pò di ordine nell’ambito web.
Basta pensare all’HTML5 che cerca di fare sue funzionalità che oggi sono raggiungibili sono con altre tecnologie (JavaScript, Flash, ecc…)
Trovata la differenza: sulla console dell’aereo non c’è la funzione “undo” se si fa una ca***…
Lo so che quella dell'”undo” sull’aereo sembra una cavolata, ma è un piccolo spunto per introdurre un argomento molto poco affrontato quando si parla di GUI: il flusso di lavoro ha due sensi, fare e disfare.
Nella maggior parte dei casi il senso del workflow è fare, e disfare anche nel mondo digitale non è sempre possibile (inteso come ragionevolmente possibile).
Per questi motivi invertire passo passo, o funzione per funzione, il workflow è spessissimo un lato sottovalutato sia a livello procedurale che come integrazione nella GUI, spesso ridotto ad un generico undo che non mostra come nel lato “do” come e cosa si stia facendo.
E dato che la funzione è poco usata, ma quando si usa di solito è perchè si è veramente nei guai, spesso fa sudare freddo l’utente!
@banryu
Questo approccio potrebbe essere interessante ma secondo me porta a qualche “pericolo” ed ha dei limiti implementativi:
Il pericolo riguarda il fatto che un’interfaccia che si modifica può creare più problemi di quanti ne risolva (il fattore abitudine viene meno, eventuali manuali d’utilizzo sarebbero praticamente impossibili da fare). Il limite implementativo è che purtroppo si ha spesso a che fare con re-installazioni. Ti immagini lo scenario in cui le statistiche di utilizzo di un’applicazione andassero perdute? Sarebbe come regredire allo status iniziale con la conseguente frustrazione di sapere “come impostare l’ambiente di lavoro” ma dover aspettare che un algoritmo lo faccia per noi.
@Scolapasta
Pienamente d’accordo. L’undo, come d’altra parte il “ripristino della configurazione di default” sono caratteristiche fondamentali per aiutare l’utente a scoprire il funzionamento dell’interfaccia quindi andrebbero trattate con più cura.
leggendo dall’inizio alla fine articolo + commenti, trovo ne sia uscito un dibattito che dovrebbe essere preso veramente ad esempio. un’ottima quindicina di minuti di lettura. e bravo ad emanuele.
@Rampichini:
—
Questo approccio potrebbe essere interessante ma secondo me porta a qualche “pericolo” ed ha dei limiti implementativi:
Il pericolo riguarda il fatto che un’interfaccia che si modifica può creare più problemi di quanti ne risolva (il fattore abitudine viene meno, eventuali manuali d’utilizzo sarebbero praticamente impossibili da fare).
—
Per i manuali di utilizzo (che io adoro, quando fatti bene!) purtroppo so che non godono (parliamo dell’utente medio, non degli appassionati di informatica e/o programmatori) di grande popolarità tra la massa, percui…
E poi non è verò che sarebbero impossibili da fare: le funzioni e le opzioni ad esse relative quelle sono, e quelle andrebbero documentate (magari rese riconoscibili dalla costanza del simbolo che le rappresenta (simbolo che formerebbe il tratto costante nelle icone associate)) e non le “viste” possibili (basterebbe documentare quella di default).
Comunque la mia idea sarebbe quella di avere appunto più “viste” della stessa interfaccia; alcune standard e fisse e una “dinamica”: quest’ultima sarebbe quella che viene modficata sulla base dei dati d’uso del’utente.
—
Il limite implementativo è che purtroppo si ha spesso a che fare con re-installazioni. Ti immagini lo scenario in cui le statistiche di utilizzo di un’applicazione andassero perdute? Sarebbe come regredire allo status iniziale con la conseguente frustrazione di sapere “come impostare l’ambiente di lavoro” ma dover aspettare che un algoritmo lo faccia per noi.
—
Beh, le statistiche di utilizzo potrebbero essere salvate nella cartella utente, e la procedura di installazione dell’applicazione progettata per tenere conto di una eventuale loro presenza. Oppure si può fare in altri modi, basta pensarci.
Interessante. Però penso che si stiano mescolando due aspetti diversi: le esigenze dell’esperto e le esigenze del nuovo utente, che non saranno mai conciliabili.
La filosofia Unix è sicuramente un pregio per gli esperti, ma per il novizio è uno scoglio, per immaginare il risultato da ottenere deve capire quali comandi concatenare e con quali opzioni, quindi conoscerne tanti e con le loro varie opzioni. Questi piuttosto possono essere il “motore” per applicazioni più ad alto livello, meno generalizzabili ma molto mirate. Obbiettivo preciso, facilità d’uso. Passando dalla linea di comando all’interazione grafica vuol dire anche interagire con una sola applicazione invece che con tanti piccoli oggetti.
“Fare una sola cosa ma fatta bene” poi è un’espressione fuorviante, si può intendere il “tema” dell’applicazione, o “l’obbiettivo”: può essere interpetata ad esempio come “manipolare un flusso di testo, offrendo tutte le opzioni possibili immaginabili del dominio applicativo” (stile unix) o “raggiungere un ben determinato obbiettivo quali che siano le condizioni a contorno”. L’utente medio vorrebbe la seconda!
Facilitare l’interazione con la macchina, a far si che questa ti semplifichi davvero la vita, è un tema molto interessante e complesso, il più delle volte però vedo che l’errore è di ragionare da esperti per altri esperti, invece di calarsi nelle esigenze di un comune mortale. Un Airbus non potrà mai essere troppo semplice da pilotare e con poche opzioni, ma un’automobile può e deve esserlo, voler esporre più comendi e funzioni sarebbe un fallimento. Potrebbe anche averceli “sotto”, ma può solo essere la versione per uno “smanettone”, cioè un utente ormai esperto. Senza sollevare inutili polemiche, questa è una componente del successo di Apple, anch’io cito ad esempio la suite iLife, ma anche tutta la logica di interazione in generale.