Ambient Findability – Intervista a Peter Morville

Ho avuto modo qualche mese fa di leggere “Ambient Findability” di Peter Morville, famoso per chi si occupa di Information Architecture in quanto co-autore di “Information Architecture for the World Wide Web” (ho avuto anche modo di intervistare a questo proposito entrambi gli autori).

Leggendo Ambient Findability (che ho recensito per Mytech) mi sono sorte alcune domande che ho condiviso con Morville, che ha gentilmente accettato di rispondere.

Ambient Findability seems in part the answer to the preface written by Jakob Nielsen to the second edition of Information Architecture for the World Wide Web. In it Nielsen talks about the need to teach information architecture at school…Do you agree? How will our children’s lives change in this sense?

In the polar bear book, we focused on enterprise information architecture because large institutions tend to have interesting challenges and the resources required to address them. But I agree with Jakob that from individual and societal perspectives, personal information architecture is perhaps more important.

The lemur book provided an opportunity to explore how the convergence of the Internet and ubiquitous computing will raise the stakes, making information literacy a prerequisite for success in the 21st century. Our children will need to be intelligent consumers and producers of information in an increasingly complex mediascape, and hopefully our schools will help them to keep up.

What is the difference between an information architect and a findability engineer?

The required skills and professional responsibilities of an information architect are fairly well defined. In a wide variety of environments, information architects collaborate with designers, developers, and authors to produce web sites, applications, and experiences.

The number of practicing information architects is significant and growing, and I see that as a real success for the field. In contrast, very few findability engineers exist today, and I’m not sure that should or will change tomorrow. I would prefer that architects, authors, designers, and developers recognize the vital importance and cross-disciplinary nature of findability.

That said, in some organizations, an entrepreneurial findability engineer can make a real positive impact by focusing attention on findability and serving as a bridge between disciplines.

Isn’t Ambient Findability too broad of a term? It spans from finding people to finding internet resources…it seems to me similar to the definition of web 2.0.

Ambient Findability describes a world, at the crossroads of ubiquitous computing and the Internet, in which we can find anyone or anything from anywhere at anytime. In this new reality, the lines between wayfinding and retrieval begin to blur as we use similar interfaces and algorithms for finding information, objects, people, and places. So, while ambient findability is certainly a big picture vision, it’s not difficult to define or imagine.

Some parts of the book seems based on 1984 by Orwell. What if I really don’t want to be found?

GPS, RFID, and other location-sensing technologies raise serious questions about privacy. However, they also promise a wealth of useful services that may save time, money, and lives. My guess is that we will sacrifice some privacy in the coming years, and those who would prefer to stay hidden may find themselves without much choice.

You say that folksonomies and taxonomies are like leaves and trees, but also that they are not mutually exclusive. How can a company use both to build a better product? Are folksonomies useful only in the short period? And are they useful on situations where you are working with a shoestring budget?

From a navigation perspective, it’s quite easy to imagine taxonomies (trees) and tags (leaves) complementing one another. Publisher-defined taxonomies can provide a useful foundation and starting point while user-defined tags can enable the emergence of novel discovery paths and rich cross-linking.

The hard part is creating a context that manages image and incentive. Most large companies are afraid of letting users tag their products. They fear that tags like “thisproductsucks” may harm their image. And it’s unclear how many companies could enlist a critical mass of user participation. So far, Amazon’s foray into tagging has returned disappointing results.

How is the lemur book related to the polar bear book? Are they complementary or not? Do you suggest a specific order in which they have to be read?

The polar bear book provides a practical, in-depth introduction to information architecture. It’s appropriate for aspiring information architects and anyone involved in web development and user experience design. The lemur book offers a conceptual overview of the future of the Internet and ubiquitous computing through the lens of findability. They’re very different books. I suggest reading the last one first. It’s shorter.

In a recent interview you said that the Google search isn’t without bias, even if it’s difficult to see it. Why?

Google is a great company that has made a wonderful contribution to society by making the world’s information more findable. However, like any other company, Google is largely motivated by profit. So, in cases where the needs of users and advertisers differ, it’s likely that Google will favor the paying advertiser. Along these lines, I believe that Google’s moves into personalization are more about targeted advertising than improving relevance.

Potete trovare altre interviste a Morville a proposito di Ambient Findability su Boxes and Arrows ,Aiga e Business Week.

Da Yahoo! pattern e librerie per il web 2.0

Yahoo! ha deciso di rendere pubblici alcuni pattern utilizzati dai propri designer per costruire interfacce che sfruttino Ajax e simili (cosa siano i pattern ho già avuto modo di dirlo recensendo l’ottimo testo The Design of Sites).

E quella di Yahoo! è una bella idea, perché il tipo di interattività reso possibile da questa tipologia di interfacce (rich client) ha cambiato le regole a disposizione di chi si occupa di progettare le applicazioni web.

Alcuni dei pattern illustrati sono molto Yahoo!-centrici, e forse non li utilizzerete mai (recensire un prodotto, votare un oggetto), altri invece si prestano bene a illustrare come un’interfaccia “web 2.0” si avvicini (ancora però con diversi limiti), a quella di un’applicazione “desktop” (come ad esempio il drag&drop).

Ma quelli di Yahoo! hanno anche deciso di fornire il codice sorgente di alcune librerie da loro impiegate. Stupisce, oltre alla varietà degli esempi (animazioni, calendari, treeview, slider, ecc.) l’ordine con il quale è stata organizzata la documentazione che li accompagna.

E se tutto questo non vi basta è anche possibile leggere un nuovo blog, sempre di Yahoo!, dedicato alle problematiche di interfaccia utente e dove potrete trovare i prossimi aggiornamenti per le librerie e i pattern.

Al di là dell’interesse nei pattern e nelle librerie, vedere come Google organizza il proprio codice e i propri pattern aiuta anche a capire che – come per molti lavori – anche per lo sviluppo web (inteso nell’accezione più ampia) è fondamentale essere ordinati e dotarsi di propri standard, indipendentemente dalla dimensione del team di lavoro. Per condividere i successi, ma anche gli errori più comuni.

Accessibilità web, lo stato dell’arte per gli screen reader

Questo articolo è un aggiornamento e approfondimento di Screen reader, display braille e browser vocali, pubblicato a fine Novembre 2002.

Screen reader

Gli screen reader stanno evolvendo enormemente, cercando di rispettare gli standard dettati dal W3C, in particolare le User Agent Accessibility Guidelines.

Oggi tutti gli screen reader in commercio riconoscono la lingua principale di una pagina web, sia che sia dichiarata nel tag HTML sia che sia dichiarata nel meta tag LANGUAGE. Nelle pagine scritte in XHTML vengono onorati i tag xml:lang e lang. Anche il tag SPAN LANG viene gestito in maniera appropriata.

Pertanto diventa importante definire correttamente sia la lingua principale della pagina sia, eventualmente, la lingua nativa di una espressione straniera. Naturalmente l’utente può sempre disattivare l’interpretazione di questi tag da parte dello screen reader. In questo caso la sintesi vocale leggerà il testo in lingua italiana così come appare scritto.

Anche i tag ACRONYM e ABBR vengono gestiti da tutti gli screen reader, ma normalmente la relativa funzione è disabilitata. Pertanto sarà l’utente a dover impostare il proprio screen reader affinché legga gli acronimi e le abbreviazioni per esteso anziché il testo che appare sullo schermo.

Attualmente gli screen reader venduti in Italia sono:

OutSpoken non è più in commercio già dal 2003.

Negli ultimi anni Hal ha colmato il divario che lo separava dagli altri due screen reader. Ora anche Hal consente di scorrere le pagine web come se si trattassero di normali documenti, utilizzando un cursore virtuale; annuncia e gestisce correttamente le tabelle; identifica il tag LABEL in modalità interattiva.

Display Braille

In questo settore le novità riguardano soprattutto i sistemi di collegamento del display al pc. Oggi in commercio si trovano molti display con connessione USB ed anche qualche display che sfrutta la tecnologia Bluetooth.

Compatibilità degli screen reader con i browser

Per molti anni i non vedenti sono stati costretti ad utilizzare Microsoft Internet Explorer, in quanto gli screen reader riuscivano ad interagire propriamente con le pagine web solo tramite la libreria MSAA utilizzata da questo browser. Ora, però, si aprono nuove possibilità.

La versione 7.0 di Jaws, infatti, è compatibile anche con Mozilla Firefox, il browser opensource che si sta ritagliando una cospicua fetta di mercato nel panorama dei browser alternativi a quello del monopolista Microsoft. Non è azzardato prevedere che in futuro anche gli altri screen reader riusciranno ad interagire con Firefox.

Internet in mobilità

L’accesso al web tramite dispositivi mobili (smartphone e pc palmari) non è più un argomento di discussione accademica. Anche per i non vedenti esistono soluzioni di accessibilità per questo tipo di dispositivi. In particolare Dolphin Computer Access ha sviluppato una versione di Hal per Pocket PC, non ancora distribuita in Italia, mentre Code Factory ha realizzato Mobile Speak, il primo screen reader per sistema operativo Windows Mobile venduto in Italia.

Il rispetto degli standard W3C e delle linee guida sull’accessibilità dovrebbero garantire la piena compatibilità dei siti web anche con questo tipo di dispositivi, che sicuramente avranno una certa diffusione tra i non vedenti, dato che comprendono anche funzioni tipiche di un telefono cellulare completamente accessibili.

Le nuove sfide

Come detto, ormai tutti gli screen reader sono in grado di gestire gli standard HTML e XHTML. Jaws riesce anche ad interagire con i fogli di stile per recuperare le informazioni relative al font ed al colore del testo, quando si utilizza l’apposito comando che fa pronunciare alla sintesi vocale tali informazioni.

Anche nel campo delle tecnologie non HTML legate al web, in particolare i formati Adobe PDF e Macromedia Flash, si è raggiunto un buon livello di accessibilità. Adobe e Macromedia, infatti, hanno pubblicato delle linee guida per rendere il materiale prodotto con i relativi strumenti di publishing accessibile agli screen reader. Purtroppo sono ancora pochi gli sviluppatori che conoscono e seguono queste linee guida, ma è probabile che in futuro vi sarà una maggiore sensibilità anche su questi aspetti.

La nuova sfida si chiama Ajax, un linguaggio che consente di creare effetti dinamici. Attualmente nessuno screen reader è in grado di interpretare questo tipo di codice. Il risultato è che tutte le funzioni gestite in questo modo vengono ignorate dallo screen reader. Per un non vedente è come se le parti di pagina web che utilizzano questa nuova tecnologia non esistessero (ne abbiamo già parlato in un articolo dedicato). Ancora una volta si ripropone il tema dell’inseguimento tra nuove soluzioni tecnologiche e strumenti assistivi.

In attesa che le case produttrici di screen reader trovino il modo di interagire con questi nuovi linguaggi, si consiglia di non farne un uso massiccio, ovvero di predisporre una interfaccia alternativa costruita utilizzando unicamente gli standard del W3C, come ha fatto ad es. Google per la sua webmail, peraltro solo nella versione americana.