laboratorio caffeina

I hate whitespace in html code: if I need them I'll use css rules.

so that's a simple plugin edited from this one.
if you need both merge them

download, rename to .php, upload to plugin folder and activate

(tested on 2.5)

Condividi

dopo la terza puntata di easy clear mi sono accorto che non sempre funziona su ie6.

dramma e panico.
non vi preoccupate ho la soluzione:

la 3 prevedeva di mettere nel contenitore dei float il seguente codice

se non funziona su ie6 provate questo.

any feedback?

Condividi

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

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

• Stock Exchange
• Morguefile
• Image After
• Free Photos Bank
• OpenPhoto
• BigFoto
• USDA
• NASA
• NOAA
• NPS
• Earth from Space
• FWS1
• FWS2
• Picture Station
• Geek Philosopher
• Free Images
• Pixel Perfect Digital
• FreeFoto
• Image Base
• Cepolina
• Amazing Textures
• Texture Warehouse
• PDPhoto
• Image Blowout
• Piotrpix
• Mandragora
• Fotogenica
• Mayang
• Free Photo Station
• Cromavista
• Afflict
• Creativity 103
• The Photo Repository
• Aarin Free Photo
• Stockvault
• Designpacks
• Unprofound
• Four Bees
• Insect Images
• Free media Goo
• Burning Well
• A digital Dreamer
• Freestockphotos.com
• Freewebpics
• Lightmatter
• Majestic Imagery
• Triparalbum
• Demny Onink
• Twice Pix
• AboutPixel
• Woophy
• Pixelquelle
• Litetek
• PIX
• tOfz
• Fontplay
• Orangetrash
• ArtFavor
• ImageTemple
• LogoDesignweb
• Fotodatebank
• Bajstock
• Pixelbag
• NWYH Stock Images
• PhotoCase
• NPS Digital Image Index
• Gimp-Savy
• DeviantArt

Condividi

Sto arrovellandomi per trovare, tra le tante soluzioni, quale sia la più elegante per risolvere il problema della validazione dei form.

Il problema è sempre lo stesso. Come indicare che un campo è obbligatorio, oppure deve contenere un numero intero, oppure una textarea deve avere al massimo un certo numero di caratteri?

Be' se fossimo in un mondo perfetto la soluzione ci sarebbe già, e si chiamerebbe HTML 5. Guardate ad esempio cosa hanno pensato bene quelli del WHATWG nella specifica Web Forms 2.0 sull'argomento validazione. Però in un mondo perfetto non siamo...

Ad esempio per specificare un campo obbligatorio cosa c'è di meglio di un attributo "required"? Poi basterebbe l'utilizzo di una semplice funzione JavaScript per controllarne la correttezza, come descritto per esempio nell'articolo JavaScript triggers di Peter-Paul Koch.

E allora il problema qual'è? La soluzione sembra già a portata di mano. Ebbene il problema è il seguente: la specifica HTML attuale, con l'ausilio dei famigerati DTD HTML, non permettono l'introduzione di attributi "alieni" all'interno di un elemento HTML.

Questo si guardi bene potrebbe essere contestato. Che fastidio potrebbe dare un attributo in più se gli attributi necessari fossero già presenti? Semplicemente il browser che non ne capisca il significato potrebbe scartare l'attributo, come già fanno adesso tutti i browser creati fino a questo momento!

Però il problema rimane. Una buona soluzione deve funzionare anche in caso di necessità di validazione HTML. Bisognerebbe trovare una soluzione di classe... che dico di classe, di "class"!

Vediamo come potremmo fare:

Vi sembra brutto? Voi mi direte: l'attributo "class" serve ad altro, non è corretto utilizzarlo in questo modo. E invece io dico: cosa vuol dire "appartenere ad una classe"? Non significa che questa classe debba avere soltanto delle implicazioni sul modo in cui l'elemento viene visualizzato. Anzi è consigliato che il nome della classe ne sappresenti il significato e non l'aspetto. Ad esempio classe "errore" e non classe "rosso", perché magari un errore sarà sempre mostrato in rosso ma la classe ne deve indicare il significato e non l'aspetto, che devono rimanere indipendenti.

E qui volevo arrivare! Utilizzare una classe per indicare una caratteristica strutturale dell'elemento non va in conflitto con il fatto di specificare come quell'elemento deve essere visualizzato. Ad esempio io potrei volere che tutti i campi obbligatori abbiamo lo sfondo giallo, mentre tutti i campi interi abbiano un bordo rosso:

E nello stesso tempo una funzione JavaScript potrebbe controllarne la validazione:

Si veda bene che questo codice non vuol essere lo script migliore che si possa scrivere per gestire la validazione di un campo, ma solo un esempio su come semplice possa essere l'utilizzo di questo sistema. E le soluzione più semplici (a volte) sono le migliori:-) Questa come vi pare?

Naturalmente questo è solo l'inizio...

Condividi