Expo hall – Web 2.0 Expo Berlin

Of all the speakers (among them Tim O’Reilly and Martin Varsavsky) the only panel to note was the one by Leisa Reichelt, “Redesigning drupal.org”.

Drupal.org is the community site of the opensource CMS and social networking software Drupal. The site has 720.000 unique visitors, 300.000 users, 300 new users per day.

The discussion focused on how to redesign the home of such an active, engaged community and, in general, how do we design in an open source way.

Design by and with the community

  • recruiting participation with Google Apps forms
  • openly blogging the process and asking questions
  • engaging with existing community infrastructure
  • crowdsourcing design (wireframes) – eg a flickr group where to put wireframes
  • online card sorting (information architecture)
  • recruit more participation (search.twitter.com)
  • lightweight communication with community via twitter
  • knowledge sharing and empowering – wiki – crowdsourcing usability testing
  • rapid, iterative, rapid prototyiping

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.

Report gratuiti sui CMS dal Rockley Group

Il Rockley Group è famoso per occuparsi da qualche anno di problematiche relative ai sistemi di gestione dei contenuti, o CMS (di CMS ne abbiamo parlato tempo fa e da allora abbiamo pubblicato diversi altri articoli).

Rockley Group pubblica da tempo anche una serie di interessanti report, almeno a leggerne i titoli, visto che per consultarli era necessario essere iscritti.

Non più dal primo Marzo 2006: tutti i report pubblicati in questi anni sono gratuitamente a disposizione dei lettori:

Written and edited by practitioners who work in the trenches, The Rockley Report features content management case studies, best practices, and lessons-learned designed to help readers demystify some confusing concepts and avoid making the costly mistakes made by others.

Ho dato un’occhiata veloce ai diversi contenuti, e ce ne sono diversi di ghiotti, tra cui vi segnalo:

Se notate, il menù sulla sinistra vi dà la possibilità di scaricare i report anche in formato Pdf. L’archivio dei contenuti è inoltre organizzato per report o per categoria. Buono studio!