Pattern e ricerca

Di pattern nel design web ho già parlato in altre occasioni. I pattern sono soluzioni a problematiche ricorrenti, raggruppati in categorie per facilitare la consultazione.

Peter Morville ha raccolto un buon numero di pattern relativi alle ricerche e ai risultati, attingendo da siti più o meno famosi, e li ha pubblicati nel proprio account Flickr, commentando ogni schermata.

Un lavoro certosino che offre una dettagliata panoramica dello stato dell’arte a disposizione di chi si occupa della progettazione e sviluppo di ricerche.

E’ sempre comodo avere qualche riferimento a cui ritornare in caso di necessità. Qualche anno fa ho avuto modo di parlare di The Design of Sites, un manuale che non posso dire di lasciare per più di qualche giorno sullo scaffale.

Google Reader aggiunge la ricerca, ma non solo

Che Google Reader abbia aggiunto la possibilità di compiere ricerche tra gli interventi, lo avrete sentito un po’ dappertutto.

Una novità trascurata da molti – presente in questo aggiornamento – e che mi sta particolarmente a cuore, è la rimozione del limite per il conteggio degli interventi ancora da leggere. Fino ad oggi chi usava pesantemente Google Reader o partiva per le ferie, si trovava un laconico 100+ a indicare che gli interventi da leggere superavano il centinaio.

Da questo aggiornamento il limite sembra essere stato tolto, o almeno variato.

image

Tornando per un attimo alla ricerca, caratteristica da benedire, avrei gradito la possibilità di salvarne i risultati “dinamici”, magari come feed Rss da condividere. E’ quello che fanno alcuni feedreader desktop, come per esempio FeedDemon. E si tratta di una funzionalità molto comoda per tenere sotto controllo termini o argomenti che spaziano tra più sottoscrizioni.

Il ciclo di vita dell’accessibilità web (seconda parte)

Presentiamo una versione rivista e ampliata dell’articolo “The Lifecycle of Web Accessibility” pubblicata dall’autore su evolt.org in inglese nel dicembre 2002

Nella scorsa puntata di questa mini serie abbiamo parlato di analisi dei requisiti e di come anche in questa fase iniziale sia importante tenere conto degli aspetti legati all’accessibilità del sito che andremo a costruire.

Affrontiamo ora la parte di progettazione concettuale, la vera a propria definizione di struttura e contenuto.

Progettazione concettuale

Cosa troviamo in questa fase

In questa fase avete bisogno di definire i flussi di funzionamento e disabilità cognitive, ad esempio, potrebbe incontrare delle difficoltà ad afferrare completamente il significato delle voci che avete utilizzato per un menu, soprattutto se queste sono in gergo (o, magari per risparmiare spazio, avete fatto largo uso di acronimi). Per la stessa ragione, cercate di limitare il numero di elementi in una lista e di mantenere la lunghezza della pagina entro limiti accettabili, eventualmente dividendola in più pagine.

Un cieco, invece, potrebbe utilizzare uno screen reader per accedere alla pagina, e in questo modo non dispone subito una visione completa della pagina che si trova di fronte. Prediligete allora una visualizzazione dei contenti che preveda di inserire, all’inizio del testo, un sommario che condensi quello di cui tratterà l’articolo. In questo modo sarà molto semplice saltare l’articolo, se non è di interesse.

Anche una efficace funzionalità di ricerca, presente in ogni pagina, è molto importante in questo senso, perché un cieco (come tutti, del resto) potrebbe non aver tempo da perdere e voler arrivare subito al contentuo di interesse. Per saperne di più potete scaricare l’ottimo capitolo sulla ricerca messo a disposizione da O’Reilly a proposito della seconda edizione di “Information Architecture for the World Wide Web” di Peter Morville e Louis Rosenfeld. Maggiori dettagli li trovate in fondo alla recensione scritta a suo tempo su Fucinaweb.

Da quello che è stato detto finora vi accorgerete che tener conto di questi elementi non aiuta solo i disabili che fruiscono il nostro sito, ma in realtà qualunque utente. Una ragione in più per fare le cose come si deve.

Per finire questa seconda parte voglio spendere qualche parola per i pochi che pensano sia meglio progettare per i disabili una versione alternativa, solo testo, del sito. Non si fa: i disabili non sono cittadini di seconda classe; possono e hanno il diritto di usufruire della pagina allo stesso modo di tutti gli altri utenti. Non dimenticatevi che l’accessibilità è un processo additivo; dovete aggiungere elementi e caratteristiche (come tag, descrizioni e attributi) piuttosto che eliminarli. Potete approfondire questi concetti in un interessante articolo di Usability Infocentre.

E se proprio secondo voi non c’è alternativa alla creazione di diverse versioni del sito, cercate prima di tutto di capire se potete ottenere lo stesso beneficio semplicemente realizzando diversi fogli di stile da applicare alla pagina, che è una strada praticabile e solitamente poco costosa.

Potreste pensare che, disponendo di un Cms, la strada sia spianata per realizzare versioni parallele. Ma chiedetevi quanto vi costerà e se non sarebbe meglio investire questa cifra nel migliorare usabilità ed accessibilità dell’unico, vero sito.

L’unico caso in cui potete (anzi, dovete) realizzare una versione parallela di sito, si verifica quando a cambiare non è solo la rappresentazione del contenuto, ma il contenuto stesso. Pensate per esempio a un telefonino, dove è improponibile usare la stessa quantità di contenuto normalmente visualizzata in una pagina web. Nella prossima puntata, dedicata ai prototipi e alla messa in produzione, vedremo quali standard possono essere utilizzati in casi come questo. Anche qui c’entra l’accessibilità web.