Archivi tag: usability

L’usabilità delle newsletter

Pubblicato il da

Si parla tanto di usabilità dei siti, ma anche le newsletter inviate ai propri iscritti devono essere progettate con attenzione. Anzi, si potrebbe quasi dire che in questo caso l’operazione è ancora più importante: dopo i molti sforzi fatti per invitare l’utente a registrarsi, è bene a questo punto fare di tutto per non perderlo.

Se dovessi giudicare le newsletter che ricevo, però, mi verrebbe da dire che poco è stato fatto per migliorarne l’usabilità.

Una delle newsletter che aspetto con impazienza è per esempio quella della biblioteca civica di Belluno, che come spesso succede fa bene alcune cose, male molte altre.

Male

  • E’ rigosoramente aperiodica: qualche mese ne vengono spedite 5, altri mesi un paio. Questo non sarebbe un problema [dello stesso problema, a dire il vero, soffre pure la newsletter di Fucinaweb]
  • Il subject dell’email non dice nulla sul contenuto: “Messaggio n. 27/2006”
  • La newsletter è composta solo da un elenco un po’ troppo sterile di avvenimenti, che riguardano eventi futuri anche di 2/3 mesi
  • A poco serve l’alternanza di colori tra i diversi eventi, se non a sottilineare il carattere artigianale della newsletter

Bene

  • Riporta correttamente gli estremi per contattare la biblioteca
  • Indica esplicitamente come annullare la propria iscrizione
  • Contiene, dove possibile, dei link di approfondimento verso il sito o altre risorse
  • Contiene testo, non immagini o inutili abbellimenti. Si potrebbe fare ancora di più: spedirla in formato esclusivamente testuale

La Rai e l’Information Architecture

Pubblicato il da

Se dovessi spiegare a una corso cosa si intende per Information Architecture, chiederei ai corsisti come prima cosa di fare una ricerca in uno dei siti della Rai.

Quasi tutti i siti della Rai sono infatti perfetti esempi di come NON deve essere strutturato un sito.

Mi sono trovato la scorsa sera a cercare lo streaming di un programma che mi sono perso, e che mi sarebbe piaciuto rivedere.

Il mio primo problema è stato innanzitutto capire su quale sito del network Rai andare. Ce ne sono infatti almeno tre che ipoteticamente mi potevano andare bene:

Dopo qualche minuto di navigazione ho scartato il sito delle Teche perché sembra ospitare contenuti d’annata, non troppo recenti, o quasi.

Sono allora passato al sito di RaiClick, che sembrava promettere bene. Dico sembrava, perché in effetti sull’homepage c’era una puntata, quella più recente, del programma che mi interessava. Ho allora pensato di compiere una ricerca con il box in alto, che mi ha portato a una pagina completamente slegata dal sito, che cerca contenuti in tutto il network Rai.

Deluso, ho provato a muovermi con l’uso della navigazione contestuale al sito, cioè scorrendo le diverse categorie “Fiction”, “Spettacolo”, “Notizie”, che si trovano in alto nella pagina.

Ma anche qui, dopo averle passate (e ripassate) tutte, non c’era l’ombra della puntata di mio interesse.

Stessa sorte per il terzo sito, quello di Radio Media. Ma in qualche modo, dopo qualche tentativo con Google, sono finalmente riuscito nella mia impresa.

Che realizzare un’architettura di sito con molti contenuti non sia un’impresa facile è certo, ma che nei portali Rai sia stato fatto di tutto per rendere dura la vita al navigatore è un dato di fatto.

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

Pubblicato il da

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.