Laboratorio avanzato di Progettazione Siti Web

Gruppo formato da: Casonato Riccardo, Giacchetto Yuri, Paro Stefano

Sei in: Home [h] sovrasezione di valutazione euristica Toscana

Introduzione alla valutazione euristica

Valutazione euristica dell'usabilità del sito della regione Toscana (www.regionetoscana.it [s]) rispetto ad un utente qualsiasi che si rivolge all'ente con un browser grafico (Mozilla 1.7.6) con risoluzione 1024x768 da un personal computer di casa con sistema operativo Linux.

Pagine considerate

Scenario:
un utente qualsiasi che si rivolge all'ente con un browser grafico dal PC di casa
Euristiche utilizzate:
sono state utilizzate le euristiche proposte da J. Nielsen e riviste e leggermente annotate dal Prof.Giorgio Brajnik [e]

Stato iniziale del sito

Il sito www.regione.toscana.it preso da noi in considerazione presenta in home page una ventina di collegamenti di cui tutti tranne due, se aperti, inizializzano una nuova finestra di navigazione creando nell'utente un sostanziale disorientamento. Purtroppo questo tipo di difetto si ripete continuamente se si visita il sito in profonditá e rende molto difficoltosa la ricerca di informazioni da parte di qualsiasi persona che ne abbia bisogno. Visitando la pagina contenente la mappa si deduce che l'obiettivo dei progettisti era quello di dividere il sito in tre grandi aree: la rete dei servizi, la comunicazione istituzionale e le aree tematiche dedicate all'approfondimento. Questo, dalla home page, è poco deducibile anche a causa delle etichette poco informative usate per i collegamenti ipertestuali. Altra causa di disorientamento è dovuta al fatto che molte pagine hanno layout e/o colori diversi tra loro. Infatti anche i link non sono sempre percepibili alla stessa maniera, perchè a volte sono sottolineati e a volte no, non fanno eccezione i colori che risultano disomogenei. Le due aree principali (comunicazione istituzionale e rete dei servizi) non sono coerenti tra di loro per quanto riguarda il layout, ad esempio il menù in alto nell'area di comunicazione è stato realizzato con una mappa, mentre quello dell'altra sezione è stato realizzato con una tabella ed una serie di link. Per concludere questa breve descrizione iniziale dello stato del sito sottolineiamo la mancanza del nome degli autori del sito e la data dell'ultimo aggiornamento.

Sommario dei problemi riscontrati

Problemi catastrofici
Problemi importanti
Problemi minori

Buoni esempi

Indice sinottico

Svolgimento Analisi

Visibilità dello stato del sistema

il sistema deve costantemente informare l'utente su ciò che sta succedendo, fornendo appropriato feedback in tempi ragionevoli.
Architettura
Contenuto

Torna all'indice [t]torna all'indice

Corrispondenza tra il mondo del sistema e quello reale

Il sistema dovrebbe usare lo stesso linguaggio dell'utente, con parole, frasi e concetti familiari all'utente, piuttosto di termini che sono orientati al sistema. Seguire le convenzioni del mondo reale, facendo sí che le informazioni appaiano in ordine naturale e logico.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Controllo da parte dell'utente e sua libertà

Gli utenti spesso invocano delle funzioni del sistema per errore e abbisognano delle uscite di emergenza chiaramente indicate in modo da abbandonare degli stati del sistema indesiderati senza dover passare attraverso un lungo dialogo. Si supportino azioni di undo/redo.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Consistenza e standard

Gli utenti non devono chiedersi se parole, situazioni o azioni diverse fanno riferimento alle stesse cose. Si seguano le convenzioni determinate dagli standard ufficiali o di fatto.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Prevenzione di errori

Ancora meglio che dei buoni messaggi di errore è un attento progetto che previene gli errori.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Riconoscimento piuttosto di memorizzazione

Rendere visibili gli oggetti, le azioni e le opzioni. L'utente non dovrebbe dover ricordarsi le informazioni relative ad una parte del dialogo nelle successive. Le istruzioni su come usare il sistema dovrebbero essere visibili o reperibili con facilità ogni volta che è appropriato.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Flessibilità e efficienza d'uso

Gli acceleratori da tastiera - non visibili da utenti principianti - spesso possono velocizzare l'interazione per utenti esperti, facendo sí che il sistema sia allo stesso tempo adatto agli uni e agli altri. Si permetta agli utenti di personalizzare le azioni più frequenti.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Estetica e design minimale

I dialoghi non dovrebbero contenere informazioni che sono irrilevanti o raramente usate. Ogni componente informativo in un dialogo compete con gli altri, e diminuisce la loro visibilità relativa.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Aiutare l'utente nel riconoscere, diagnosticare e rimediare dagli errori

I messaggi di errore devono essere espressi in un linguaggio semplice (non codici di errore), devono indicare con precisione l'errore, e suggerire in maniera costruttiva una soluzione.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Aiuto e documentazione

Anche se è meglio se il sistema può venir usato senza documentazione, può essere necessario fornire degli aiuti e documentazione di riferimento. Questo tipo di informazione deve essere semplice da ricercare, focalizzata sui compiti degli utenti, elencare i passi concreti da eseguire, e non essere troppo grande come dimensione.
Architettura
Contenuto
Presentazione

Torna all'indice [t]torna all'indice

Valid HTML 4.01! Valid CSS! Level Double-A conformance icon,W3C-WAI Web Content Accessibility Guidelines 1.0