ZUI, Ma Anche No

Constato adesso il fatto di non aver mai menzionato le ZUI (Zooming User Interface) su questo blog, ma ora, dopo la lettura di The Humane Interface, mi e' inevitabile.
Nel suo pluri-osannato saggio, il fu' Raskin dedica ampio spazio alla descrizione di interfacce per sistemi general purpose incentrate sul fatto di poter navigare sostanzialmente in tre dimensioni le informazioni, distribuite non gia' all'interno di un albero bidimensionale (la ben famigliare gerarchia a cartelle) ma su una serie potenzialmente infinita di piani "trasparenti" cui accedere zoomando una data porzione dello schermo fintantoche' ci sia qualcosa da zoomare. A tale sistema viene attribuita la capacita' di mostrare moli importanti di dati in un unico colpo d'occhio, una migliore intuitivita' nell'interazione, e l'implicita' possibilita' di embeddare nella stessa interfaccia funzionalita' complesse che, ai fatti, possono sostituire le canoniche applicazioni cui siamo abituati con un agglomerato onnipotente ed onnipresente ben piu' omogeneo.
Personalmente, non sono particolarmente favorevole al paradigma suggerito dalla ZUI. Certamente sono propenso all'ultima nozione di eliminazione delle singole applicazioni (del resto, buona parte del Progetto Lobotomy si basa su tale concetto), ma non posso essere d'accordo in merito all'effettiva efficienza sul trattamento delle informazioni.
In primis: seppur tridimensionale anziche' bidimensionale, pur sempre di una gerarchia si tratta. Gli elementi a video sono sempre raggruppati tra loro secondo un unico criterio arbitrario e non riproducibile o prevedibile definito dall'utente: laddove nell'albero a cartelle i files si trovano nelle directory scelte (spesso malamente) dall'utilizzatore qui vanno posizionati all'interno dello spazio, ma comunque sempre in una qualche "zona" la cui reperibilita' e' sempre delegata alla (fragile) memoria del povero tapino che sta dall'altra parte del monitor. Anzi, in uno spazio tridimensionale si aggiunge una ennesima dimensione entro cui potersi perdere: nel momento in cui sto cercando un documento non devo ricordarmi solo in quale gruppo di documenti l'ho messo, ma potrei benissimo non rintracciarlo essendo esso visibile solo ad un livello di zoom minore o maggiore rispetto a quello attuale.
Per estensione, anche il vantaggio della quantita' di dati visualizzati in un colpo solo viene minato appunto dalla mancanza di conoscenza a priori del giusto livello di zoom entro cui un dato si trova: quel che sto cercando potrebbe benissimo essere stato piazzato in uno strato "superiore", e dunque essere identificabile solo "allargando" la visuale e perdendo la percezione di quel che si trova negli strati "inferiori".
Nel tomo del Raskin viene illustrato l'esempio di una ZUI usata per descrivere l'organizzazione di una serie di cliniche: certamente un impiego del genere sarebbe ben piu' appropriato di un sistema "general purpose", in quanto le informazioni da maneggiare sono gia' distribuite entro una gerarchia nota che si vuole riprodurre metaforicamente (le cliniche, ovvero gli edifici, composti da piani, composti da stanze, popolate da letti in cui stanno i pazienti), ma il problema della navigabilita' rimane: per accedere ai dettagli relativi ad una persona devo sapere a priori dove essa si trova (quale edificio, quale piano, quale stanza, quale letto), e per quanto una funzione di ricerca full-text possa essere facilmente innestata in modo che dato un nome l'interfaccia possa zoomare da sola dove richiesto non e' chiaro quale dovrebbe essere il comportamento in caso di risultati multipli (schermo splittato, ove ogni parte visualizza la porzione corretta dello schema completo???).
Numerosi altri punti sono altrettanto mai risolti, in particolar modo a riguardo del comportamento da adottare con contenuti non testuali: se ho una immagine, mi sposto a destra, ingrandisco finche' non vedo piu' nessuna parte di suddetta immagine, e mi sposto a sinistra, cosa succede? Ho girato dietro l'immagine, e dunque vedo uno spazio bianco? Vedo la stessa immagine zommata? Se creo li' un documento, esso dove andra' a finire? Sotto l'immagine? Dentro l'immagine? Tornando indietro e zommando l'immagine, essa diverra' prima o dopo "trasparente" e mi permettera' di accedere a quello che c'e' sotto o dovro' sempre aggirarla? A tutte queste domande puo' dare una risposta l'eventuale implementatore, e gia' ho visto diverse implementazioni piu' o meno abbozzate di tale meccanismo, ma personalmente credo che almeno per i quesiti qui sopra esposti non esista nessuna soluzione che al tempo stesso permetta una aderenza stretta al paradigma e una sufficiente facilita' di utilizzo: da una parte lo zoom infinito su di una fotografia e' fondamentalmente inutile ed implica di perdere totalmente l'accesso a tutta la parte di spazio che vi sta sotto ma viene richiesto dalla specifica, dall'altra la possibilita' di considerare i contenuti troppo allargati come "saltati" aggiunge una complessita' non da poco alle operazioni di esplorazione dello spazio (di cui alcune parti sono occasionalmente nascoste e pressoche' impossibili da trovare senza premeditazione).
Piu' in generale, ribadisco che per quanto certamente migliore della suddivisione a cartelle anche questa forma spaziale rappresenta pur sempre una gerarchia la cui organizzazione e' lasciata alla cura (o, meglio, alla noncuranza) dell'utente, ed e' dunque destinata a fallire trovando il suo punto critico proprio nell'elemento meno affidabile di tutto il percorso di interazione uomo-macchina. Per quanto mi concerne continuo a preferire di gran lunga la possibilita' di "trovare" piu' che di "cercare", e non sono l'unico.