laboratorio caffeina

Ci sono mille motivi per cui capita, ma spesso in rete ci si ritrova davanti ad una pagina di errore 404. Il 404 è un codice di risposta dello standard HTTP che indica che il cliente è in grado di comunicare con il server, ma il server non ha trovato la risorsa richiesta.

Troppi siti non si preoccupano di cambiare la pagina predefinita di errore 404, queste schermate disorientano l’utente e spesso sono causa di un suo abbandono del sito. Nelle situazioni critiche, ovvero in caso di errore, la compilazione di una form o i moduli di ricerca, bisognerebbe progettare e implementare con ancora maggiore rigore e attezione l’usabilità dell’interfaccia Web.

La pagina di errore 404 di default non ha lo stesso layout del sito e non spiega nulla dell’errore ma fornisce solo un messaggio tecnico, quindi disorienta e non lo aiuta in alcun modo.

Quindi primo punto è ricreare un design simile al resto del sito o almeno includere il logo. Ricreando il design del sito facciamo attenzione ad evidenziare il fatto che ci si trova su una pagina di errore, quindi viene il momento delle spiegazioni e suggerimenti, evitando tecnicismi dobbiamo:

• spiegare il perchè viene visualizzata la pagina di errore;
• elencare le cause più comuni;
• dare delle alternative, ovvero link alla homepage, motore di ricerca o meglio ancora qualcosa tipo “forse cercavi” di Google;
• infine un indirizzo email per riferire del problema.

Sengalo come esempio positivo il sito Apple ,per le note folcloristiche e non il 404 Research Lab, invece per maggiori dettagli tecnici fate riferimento al solito ListApart.

Condividi

Argomenti trattati :

# Stack
# Chiamate di procedure
# Ricorsione

Conoscenze minime :

# Un pò di C
# Concetti di programmazione

Inizio :

Come sappiamo,un programma in C per essere eseguito deve essere prima compilato,cioè tradotto in linguaggio macchina equivalente. Oggi voglio accennarvi brevemente ( per ora ) al modo in cui vengono gestite dal compilatore le chiamate di procedure,in tal modo capiremo meglio i problemi da affrontare e come sia vitale per la soluzione l'utilizzo di una struttura dati,lo stack.

Supponiamo che un a procedura Main chiami a un certo punto una procedura A1,la quale chiama a sua volta A2, la quale infine chiama A3. Possiamo schematizzare la situazione come segue :

Quando A3 termina la sua esecuzione l'istruzione che deve essere eseguita è quella,nella procedura A2, successiva alla chiamata A3 e di indirizzo t. Quando A2 termina,l'istruzione successiva deve essere quella di indirizzo s, e infine quando A1 termina va eseguita l'istruzione di indirizzo r.

I ritorni avvengono dunque in ordine inverso alle chiamate.

E' perciò importante che quando vengono chiamate le procedure gli indirizzi di ritorno vengono salvati in un recipiente da cui verranno prelevati in ordine inverso a quello di inserimento. Questo recipiente prende il nome di stack ed è una struttura dati cioè un oggetto su cui sono lecite operazioni particolari.

Uno stack viene anche detto una struttura LIFO ( Last In First Out ) in quanto l'ultimo elemento inserito nello stack è il primo ad uscire. Inizialmente lo stack è vuoto,quando la procedura Main chiama A1,l'indirizzo di ritorno r viene inserito ( push ) nello stack,quando A1 chiama A2 push dell'indirizzo s,quando A2 chiama A3 push di t. Lo stack durante l'esecuzione di A3 è il seguente :

Nel momento in cui A3 termina viene prelevato ( pop ) dallo stack l'indirizzo che sta in cima ( top ) e va in esecuzione l'istruzione di indirizzo t. Quando A2 termina,pop di nuovo e va in esecuzione l'istruzione di indirizzo s,quando termina A1,pop ancora e va in esecuzione l'istruzione r.

Ogni volta che va effettuato un return,l'indirizzo a cui tornare si trova al top dello stack.

Ora passiamo ai progammi ricorsivi. Un programma è detto ricorsivo diretto se viene chiamato all'interno del programma stesso. Un programma F1 è detto ricorsivo indiretto se chiama un programma F2,che chiama a sua volta F3,e così via,finchè Fk chiama F1. Spesso si pensa che è più semplice programmare senza la ricorsione ( infatti molti linguaggi di programmazione non la permettono ) ed è vero in MOLTI casi. Spesso però la versione ricorsiva di un programma è più compatta e facile da capire. Il motivo più importante per usare la ricorsione è che vi sono problemi che sono più facilmente risolvibili utilizzandola.

Per farvi capire meglio,vi mostrerò forse il programma ricorsivo per eccellenza : Il fattoriale.

Possiamo scrivere una semplice funzione C di fattoriale in questo modo :

per capire però bene il meccanismo di ricorsione scriviamo la funzione in modo meno compatto,utilizzando un'altra variabile. I passaggi risultano in tal modo più chiari:

ed ecco cosa succede eseguendo l'istruzione fattor=fact(3) :

Per effetto della chiamata,si entra per la prima volta nella funzione,n vale 3: poichè n non vale 1, la funzione viene chiamata una seconda volta con l'istruzione fact(n-1). Il parametro attuale vale (3-1)=2 per cui,quando entro nella funzione,n vale 2. Chiamo pertanto per la terza volta la funzione con l'istruzione fact(n-1), questa volta il parametro attuale vale (2-1) = 1. Riassumendo,le tre chiamate sono :

prima : fattor = fact(3);
seconda : k = fact(n-1) ( n vale 3 per cui (n-1)=2)
terza : k = fact(n-1) ( n vale 2 per cui (n-1)=1)

quando entro per la terza volta in fact,n vale 1 per cui esco subito dalla funzione restituendo il valore 1,torno all'ultima chiamata fatta,cioè la terza, e il valore 1 viene assegnato a k. Nel contempo,n automaticamente riassume il valore che aveva all'atto della terza chiamata(2).

Va quindi in esecuzione l'istruzione return n*k e viene restituito il valore 2*1=2. Si torna ora all'ultima chiamata fatta,cioè la seconda,k assume il valore 2 e n automaticamente riassume il valore 3. Va ora in esecuzione return n*k e viene restituito il valore 3*2=6. Si torna all'ultima chiamata fatta,questa volta è la prima,fattor = fact(3),e il valore 6 viene assegnato a fattor.

Vi ho mostrato la gestione delle chiamate di procedure mediante stack. Nel momento in cui abbiamo programmi ricorsivi le cose si complicano grandemente : infatti all'atto della chiamata ricorsiva oltre all'indirizzo di ritorno vanno salvati tutti i valori dei parametri in quel momento,e tali valori ripristinati al momento del return.

Per questo,anche se a volte sembra che ci " convenga " usare la ricorsione,dobbiamo stare attenti.

Programmi ricorsivi complessi richiedono il salvataggio di tutto un set di parametri per un numero di volte che dipende dal numero di livelli di ricorsione,questo complica molto il lavoro del compilatore per cui molti linguaggi di programmazione,come già detto,hanno " risolto " il problema alla radice non consentendo l'uso della ricorsione.

Questo è solo una prima parte,alla prossima,ciao !

Condividi

Per chi è già ampiamente convinto della utilità delle linee guida salti la premessa.

Premessa sociodemopolitica

Spesso leggendo le linee guida proposte nei testi di usability, viene da pensare che siano banalità pensate per agevolare gli utenti disabili. Evitando ogni discorso etico/morale ma parlando in maniera volutamente politicamente scorretta, non conosco disabili e perciò non li considero possibili utenti del mio "business". Generalmente sviluppo siti rivolti per un pubblico di professionisti, ma il nostro popolo è uno dei più vecchi, anche i manger delle aziende italiane e così il nostro parlamento.

Per esperienza personale la maggior parte delle persone oltre i 40/45 anni, pur usando il computer quotidianamente, fatica sia a capirne i concetti base come icone e utilizzo delle finestre, sia ha notevoli problemi con i sistemi di puntamento, insomma muovere il mouse e il doppio click sembrano metterli in difficoltà. Questa mia premessa non vuole essere una campagna per l'adozione di un anziano, ma è una aperta riflessione sul fatto che i nostri potenziali clienti sono informaticamente parlando, per la maggior parte disabili.

1. Inibire il tasto "Indietro"

Ancora oggi molti siti in maniera volontaria o involontaria inibiscono il funzionamento del tasto "Indietro":

• aprendo i documenti in nuove finestre
• siti a tutto schermo
• reindirizzamento forzato
• utilizzo del tag META di "refresh"

Mediamente il tasto "Indietro" è percepito dall'utente come un "Undo/Annulla", insomma un'ancora di salvezza. Oltretutto mi sembra evidente che bloccare una qualsiasi funzionalità del browser sia una violazione della libertà dell'utente che proverà solo una grande frustrazione.

2. Aprire nuove finestre

Finalmente mi tolgo questo sassolino dalla scarpa, anche io un tempo, per i link che puntavano all'esterno preferivo aprire nuove finestre, pensando di mantenere l'utente rilegato al mio sito.

Questo è un errore grave: poichè deludiamo le aspettative dell'utente che si attende di vedere aperto il documento nella medesima finestra, come accade normalmente per ogni link. Anche se fosse un utente esperto saprebbe aprire da solo il documento in una nuova finestra o tab, perchè rischiare di contraddirlo? In questo modo inoltre si vanifica l'utilizzo del tasto "Indietro", oltre ad incrementare il prolificare delle finestre sullo schermo dell'utente.

3. I link che non cambiano colore

Per noi designer è prevalentemente una questione estetica, quel blu elettrico o quel color prugna secca sono proprio un pugno in un occhio! Ma per gli utenti è una questione di praticità, cercano qualcosa e la vogliono trovare senza perdersi, quindi diventa indispensabile che sia evidente dove un utente si trova, dove può andare dal punto in cui si trova e dove è già stato.

Conclusioni

I libri e le linee guida sull'usabilità sembrano sempre delle acide paternali, quindi superflue e irritanti ma osservate questo sito in cui sono incappatto l'altra sera. Un layout davvero attraente, per di più i link sottolineati rispettando le linee guida e la leggera discontinuità l'originalità del layout. Peccato che persone tanto illuminate abbiano tralasciato un dettaglio, secondo me grave, ovvero :

• 
• 
• 
• 

Informazioni fondamentali come numeri di telefono, indirizzo ed email dovrebbero sempre essere scritte con testo, in modo che l'utente possa fare copia-incolla agilmente annotandosi queste informazioni. L'argomento immagini al posto del testo è molto delicato in quanto ad accessibilità ma questo è un altro discorso.

Condividi

Usability, ecco uno di quei termini che nel Web spesso scatena polemiche e discussioni, eppure si tratta di una disciplina nemmeno tanto giovane che affonda le sue radici nell'interazione uomo-macchina e che in generale, concettualmente parlando, non ha apportato grandi novità.

Il mondo reale
Donald Norman¹ nei suoi numerosi saggi ha trattato gli orrori di usabilità applicata al design di oggetti comuni, pensiamo alle porte a vetri dei grandi edifici pubblici, migliaia di persone le attraversano ogni giorno, ma spesso non sono progettate in modo che giunti in prossimità si intuisca se si debba spingere o tirare per aprirle, anche quando ci fosse la classica etichetta adesiva a suggerirci la soluzione si puo' porre un ulteriore problema, sono a doppia "anta" e l'una blocca l'altra, quale delle due devo scegliere? La grossa differenza nel Web è che gli utenti se non riescono a capire come funziona "la porta" di un sito volgono altrove, nel mondo reale solitamente hanno più pazienza perchè non hanno questa rapida via di uscita.

Definizione
È doveroso cercare una definizione rigorosa dell'oggetto di studio, e per prima cosa rivolgo la mia attenzione al lavoro di Jakob Nielsen².

L'usabilità è un indicatore di qualità che ci dice quanto una determinata cosa è semplice da usare. Più precisamente ci dice quanto è necessario per imparare a usare quella cosa, con quanta efficienza la si usa poi, quanto si riesce a tenerne a mente il funzionamento, quanto alta è la probabilità di fare errori quando la si usa, e quanto è piacevole usarla.

Qualcosa stride in questa definizione, quindi nell'ottica in cui si pone Nielsen, per questo concordo con la critica mossa da Franco Carlini³ che non digerisce la riduzione ad un valore numerico, un punteggio, del concetto di soddisfacibilità dell'utente. Questa definizione sottende l'esistenza di un algoritmo per il calcolo di questo punteggio, ma leggendo l'opera di Nielsen non si trova la ricetta miracolosa ma un insieme di linee guida da seguire basate su

osservazioni empiriche provenienti da test compiuti su 716 siti web e 2136 utenti di tutto il mondo.

Contando che a stessa detta di Nielsen il web conta più di 80 milioni di siti e che almeno potenzialmente gli utenti del Web sono qualche miliardo, possiamo dire che l'ingrediente segreto proposto da Nielsen in realtà è tanta attenzione verso ilcliente ed esperienza nel conoscere le sue esigenze.

Inoltre come evidenzia Michele Visciola⁴ non si tratta solo di semplicità d'uso, nel caso del web un elemento fondante è l'informazione, quindi il bisogno dell'utente di reperire un informazione coerente alla sua richiesta.

Conclusione
La mia conclusione è che dall'esperienza altrui c'è sempre da imparare quindi un buon designer deve tenere ben a mente le linee guida frutto delle ricerche di Nielsen e i maggiori studi in materia di usabilità (guardate la bibliografia), per poi saperle rielaborare grazie alla propria esperienza e conoscenza degli utenti del sito che si sta progettando.
Quindi se l'esperienza verrà con il tempo agevoliamola in ogni modo stimolando gli utenti dei nostri lavori a fornirci un continuo feedback e quando possibile provando a reclutare utenti per sottoporli a test.

Mi riprometto entro fine settembre di sottoporvi qualche interessante linea guida e approfondire l'argomento dei test di usabilità

Bibliografia

1. "Emotional Design: Why we love (or hate) everyday things" di Donald Norman (2004).
2. "Web Usability 2.0. L'usabilità che conta" di Jakob Nielsen (2006).
3. "Parole di carta e di web. Ecologia della comunicazione" di Franco Carlini (2004).
4. "Usabilità dei siti web" di Michele Visciola (2000).

Condividi