Di recente Google ha attivato per gli Stati Uniti ed il Giappone Recipe View , un filtro di ricerca specifico per le ricette con il quale sarà possibile cercare non solo per ingrediente ma anche per tipo di portata, tempi di preparazione e calorie.
Le ricette adeguatamente marcate saranno presentate con uno rich snippet completo di foto e dati di preparazione.
Comodissimo!


Il microformato di riferimento per Google è basato in parte su Hrecipes ma utilizza anche altre opzioni aggiuntive come descritto ampiamente nella comoda documentazione.
Oltre ai microformati, Recipe View supporta anche le definizioni in RDFa o microdati ma, personalmente, trovo che i microformati siamo decisamente più pratici ed economici da applicare, essendo basati sulle comuni classi. Si prendono due piccioni con una fava: si predispone una struttura semantica ed insieme a quella una base per l’applicazione degli stili CSS.

WordPress plugin

WordPress dispone già di diversi plugin per integrare i microformati nelle ricette. Io ho testato hRecipe e RecipeSEO.

hRecipe predispone nell’editor dei post una maschera per l’inserimento della ricetta. Le opzioni da inserire sono numerose e vanno dai dati essenziali (ingredienti, tempi, istruzioni, porzioni) a quelli più particolareggiati (tradizione culinaria, variazioni etc.).
In questo plugin ho riscontrato alcune debolezze:

• è obbligatorio specificare un titolo per la ricetta ma spesso questo è ridondante rispetto al titolo del post,
• le quantità sono specificate unitamente agli ingredienti,
• le immagini non sono gestite,
• una volta inserita la ricetta, per modificarla non è più possibile usare la maschera ma è necessario intervenire sul codice

RecipeSEO ha una maschera di inserimento graficamente più accattivante. Aggiunge al DB delle tabelle ove viene archiviata la ricetta, così è possibile in un secondo momento tornare a modificarla senza mettere mano al codice. Rispetto a HRecipes include meno dati ma distingue le quantità dagli ingredienti. Anche RecipeSEO non gestisce le foto.
Dentro l’editor la ricetta non è visibile: viene predisposto un logo con due pulsanti per l’editing o la cancellazione. Per vedere l’esito dell’inserimento è necessario visualizzare l’anteprima del post.

Personalmente ho scelto hRecipes perché offriva maggiore completezza dei dati. Per mie esigenze grafiche ho modificato il plugin in modo da gestire separatamente ingredienti e quantità. Sto attualmente lavorando per la gestione delle immagini. Il plugin dispone di una localizzazione in italiano ma è veramente povera ed incompleta: per mia comodità ho modificato anche questo aspetto (ma non con i file di localizzazione, il che è sbagliato ma andavo di fretta…)

Vedremo se questo accorgimento semantico riuscirà a valorizzare le mie ricette. Spero poi che anche in Italia verrà reso disponibile il filtro Recipe View perché per le mie serate “stasera che cosa preparo?” sarebbe una vera manna.

No related posts.

Due registrazioni identiche, due login differenziate

Il sito in questione offre due servizi riservati agli utenti registrati: la possibilità di commentare gli articoli e la possibilità di fruire di contenuti speciali. Per ciascuno di questi servizi è stata richiesta la creazione di una base dati, di un form di registrazione e di una pagina di login distinte.
Questa impostazione potrebbe essere ragionevole se le policy dei due servizi fossero differenti ma sono le stesse! Stessi dati di registrazione, stesse norme sulla privacy e condizioni di utilizzo. L’utente si trova nella situazione scomoda e assurda di dover fornire due volte gli stessi dati. Peggio: deve gestire due diversi profili sullo stesso sito.
L’interfaccia non aiuta a risolvere questa ambiguità: proprio sopra il logo del sito compare il bottone “Accedi/Registrati” per la login/registrazione ai commenti mentre un’icona accanto al logo porta alla sezione dei contenuti speciali, che si apre con una nuova pagina di login/registrazione dedicata. Stessi dati, impaginazione differente.

A due giorni dal rilascio del nuovo sito la committenza festeggiava il picco di richieste di registrazione.
A partire dal terzo giorno si è trovata ad affrontare una valanga di email di protesta e richiesta di supporto: gli utenti non riuscivano ad accedere ai contenuti speciali.

Debug delle lamentele degli utenti

In generale, gli utenti non sono in grado di analizzare correttamente una problematica: quale problema si verifica, in quali condizioni e in seguito a quali azioni. Di solito si limitano ad osservare, ansiosi ed arrabbiati: “Non funziona niente!”. A quel punto la risoluzione del problema si dilata del tempo necessario ad interpretare la segnalazione di malfunzionamento.

Nello specifico la segnalazione che abbiamo ricevuto dal committente è stata “Non funziona la registrazione”, problema che non riuscivamo a replicare in quanto entrambe le registrazioni funzionavano correttamente così come le login.
Quello che non riuscivamo a replicare è stata la confusione generata dall’interfaccia: gli utenti cercavano di accedere all’area dei contenuti speciali con il profilo dei commenti. Il bottone “Accedi/Registrati” sopra il logo risultava più evidente agli utenti che quindi si registravano lì e non capivano perché registrarsi nuovamente nella pagina dei contenuti speciali. Tentavano la login con il profilo sbagliato e non si capacitavano del “malfunzionamento” o della necessità di ripetere la registrazione appena conclusa.

In un certo senso, la decisione della committenza di partire con un ristretto numero di articoli aperti ai commenti ha gettato benzina sul fuoco: non capivano a cosa servisse la prima registrazione.

Contenimento del problema: i messaggi che nessuno legge

Per cercare di rendere più chiara la differenza tra le due login (non è stato possibile unificarle per ragioni interne) è stato applicato un messaggio esplicativo sopra il form: “Registrati qui per commentare e registrati là per vedere i contenuti speciali”.
Gli utenti non hanno mostrato di cogliere il segnale: a distanza di un mese dal rilascio arrivano ancora mail di lamentele.
In seconda battuta è stata cambiata l’icona dell’area dei contenuti speciali: non mi è chiaro in questo caso lo scopo, dato che nessun riferimento alla modalità di registrazione e login veniva veicolato da quell’icona.

Contando sullo spirito di adattamento dei loro utenti, la committenza ha lasciato la situazione così com’era.

La soluzione usabile

La situazione ottima desiderabile richiederebbe un’unica registrazione ed una login unificata per tutti i servizi con la possibilità di definire “gradi di accesso” diversificati.

Data la situazione concreta, diverse potevano essere le strade per agevolare l’utente:
1) prevedere che l’area dei contenuti speciali fosse accessibile anche con il profilo dei commenti;
2) inserire esplicitamente nella pagina di registrazione oltre che in quella di login la spiegazione di quale servizio si stava sottoscrivendo;
3) togliere il bottone “Accedi/Registrati” e consentire la login soltanto dalla pagine dei commenti o da quella dei contenuti speciali. La prossimità con l’area di utilizzo avrebbe dovuto suggerire qualcosa all’utente, tuttavia si tratta sempre di una soluzione che lascia troppo all’intuito.

No related posts.

<article>
   <a href="story.html">
      <img src="img/immagini.gif"/>
         <header><h1>Titolo</h1></header>
   </a>
</article>

Ufficiosamente questo comportamento è già supportato dai principali browser, con Firebug però si verificano dei problemi di visualizzazione quando l’elemento <a> contiene uno dei nuovi tag strutturali di HTML5 (ad es <header>): l’intera struttura HTML del blocco viene modificata, chiudendo anticipatamente gli elementi strutturali e spostando le <a> dentro il successivo elemento block-level. Ai tag <a> spostati viene aggiunto ed l’attributo “_moz-rs-heading”.

   
      


   

       Torta alla ricotta con scaglie di cioccolato
   

Una possibile via per risolvere questo problema è aggiungere un <div> dentro il tag <a> per racchiudere i contenuti. Questa soluzione effettivamente risolve il problema ma – a mio parere- vanifica la pulizia semantica che HTML5 sta sforzandosi di recuperare.
Altra soluzione potrebbe essere il ricorso a uno script JQuery ma la vedo come un’operazione macchinosa: perché gravare la mia pagina con un ulteriore script quando il problema è limitato ad un solo browser? (anche se si tratta del mio browser preferito)

Personalmente, nell’attesa della risoluzione del bug, preferisco continuare con il “vecchio sistema”.

   

Torta alla ricotta con scaglie di cioccolato

No related posts.

Oggi finalmente sono stata chiamata a partecipare ad uno di questi test: mi è stato richiesto di navigare un menù alla ricerca di determinate informazioni. Non avevo a disposizione contenuti per valutare la correttezza delle pagine selezionate, avevo a disposizione solo le etichette e la gerarchia delle voci di menù. Insomma, ho partecipato ad un test per valutare la bontà dell’architettura informativa di un sito, probabilmente quello di un ente/società che si occupa di ricerca scientifica.
10 task in 10 minuti: rapido per lo sviluppatore, divertente per il soggetto di test e sicuramente economico per il cliente finale.
Nel caso voleste partecipare anche voi, ecco la pagina di reclutamento.

Immedesimarsi nell’utente

Mi sono iscritta all’iniziativa di Usabile.it perché mi interesso di usabilità ma non ho occasione di lavorare sul campo perciò in questo modo posso

• acquisire esperienza con le forme e le tecnologie utilizzate;
• acquisire familiarità con le “sensazioni” che può provare un soggetto di test;
• cercare di indovinare le finalità nascoste del test: quali aspetti stanno cercando di testare? Perché sono problematici? Io come li affronterei?

Penso sia un buon modo per tenermi aggiornata e per “premiare” quelli che diffondono il verbo dello user testing, nonché un incentivo per i clienti finali che, spendendo poco, possono contare su una rilevante quantità di dati.

In particolare trovo utile lo scambio di ruolo: da osservatore a soggetto di test. Nei -purtroppo pochi – test che ho condotto fin’ora mi trovavo nella scomoda situazione di essere il designer/sviluppatore di quanto oggetto di test. Il fallimento dei miei utenti nel completamento dei task mi lasciava a) irritata b) stupita perchè avendo disegnato il quadro generale della situazione non riuscivo ad uscire dal ruolo, emotivamente coinvolto, del creatore e calarmi in quello distaccato dell’osservatore o in quello frustrato dell’utente.
Partecipare come utente invece mi consente di familiarizzare con la sensazione di sentirsi stupidi o incapaci dinanzi alla difficoltà nel concludere un compito: il soggetto di test presuppone che se gli viene chiesto di fare la cosa X è perchè è possibile fare la cosa X sul sito e allora “perchè mai io – accidenti – non ci riesco?”. Dipende molto dalla self confidence di un individuo reagire accusando il sito o se stesso, in ogni caso è una situazione spiacevole, che immagino crei tanto più disagio in presenza di un osservatore “tecnico”.

Test online: pro e contro

Lo user testing si svolge normalmente in presenza di un osservatore che, discretamente, osserva il soggetto di test alle prese con il sito rilevando non solo le sue reazioni manifeste (thinking aloud) ma anche quelle inconsapevoli (sbuffa, si gratta la testa, guarda l’osservatore con aria imbarazzata o tira il mouse contro lo schermo? qualcosa non sta andando nel verso giusto….)

Lo user testing online si svolge da remoto: può essere moderato, ossia l’osservatore è indirettamente presente – tramite strumenti di videoconferenza ad esempio – oppure può essere non moderato ed in questo caso non c’è osservatore umano ma un software che registra i movimenti del mouse e le risposte dell’utente e organizza i dati raccolti per una più agevole lettura.

Lo user testing online è sicuramente meno informativo di quello in presenza ma certamente più economico e rapido. Gli ambiti di applicazione dei test in presenza ed online sono – a mio giudizio – diversi pertanto non si propongono come strumenti alternativi ma come come complementari.
Un articolo che approfondisce bene la tematica è Unmoderated, Remote Usability Testing: Good or Evil? di UxMatters.

No related posts.

Mimesi:

imitazione della realtà e della natura che è il fondamento, secondo l’estetica classica, della creazione artistica.

Metafora

figura retorica che implica un trasferimento di significato. Si ha quando ad un termine se ne sostituisce un altro, operando un trasferimento di senso capace di creare immagini di forte carica espressiva.

Entrambe sono utili nella realizzazione di interfacce utente ma con potenzialità e limiti differenti. La mimesi, infatti, riproducendo la realtà non ne consente il superamento mentre la metafora, con la sua potenza creativa, è in grado di suggerire nuove interpretazioni per situazioni note ovvero è in grado di “portare” l’esperienza da un campo all’altro.

Il ricorso alla metafora è una pratica consolidata nel design delle interfacce grafiche in ambito informatico: dal desktop al cestino, dalla scrollbar agli sliders. Elementi del mondo reale vengono riprodotti graficamente a suggerire modalità di interazione note con concetti spaziali e fisici nuovi. Il mapping è reso possibile proprio dalla disponibilità di una rappresentazione grafica e dalla possibilità di manipolare direttamente tali rappresentazioni tramite il paradigma “punta e clicca” (che è a sua volta una metafora della manualità concreta).
La mimesi trova applicazione prevalentemente in campo ludico, per la simulazione di realtà immersive. Proprio la forte rassomiglianza col mondo reale la rende inadatta per l’utilizzo in campi diversi da quelli che le sono propri.

Periodicamente ritorna tra i professionisti il dibattito relativo all’impiego di mimesi e metafora nelle GUI: è utile o dannoso? Alcuni sostengono che sia utile per facilitare l’accesso ai newbie dell’informatica, altri ritengono sia dannoso perché tende a nascondere le maggiori capacità dello strumento informatico rispetto a quello reale cui è assimilato. Entrambi i filoni di pensiero hanno le loro ragioni: in ogni caso la metafora si attende un superamento per poter essere compresa, pertanto se pure è utile nella fase iniziale dell’apprendimento deve poter essere accantonata nella fase esperta per godere appieno delle potenzialità dello strumento.

Dove sta la metafora?

Le tendenze del design 2010 secondo SmashingMagazine vedono un revival dell’utilizzo delle metafore del mondo reale in ambito web. A ben vedere l’articolo (pur ricchissimo di spunti interessanti) dedica poco spazio al tema specifico della metafora e – a mio giudizio – riporta esempi o già consolidati (bottoni ed interruttori) o sbagliati . Nello specifico:

• Fred Perry: la metafora discussa è poster come catalogo prodotti. Visivamente accattivante ma non è una metafora: quale esperienza o significato possono essere portati dall’ambito poster o a quello del catalogo? E’ anzi una situazione riduttiva poiché il catalogo ha maggiori possibilità di interazione rispetto al poster.
• C. L. Holloway: la metafora discussa è una galleria d’arte per….un’esposizione di quadri! Si tratta di una mimesi più che di una metafora, per altro non viene sfruttata la potenzialità del mezzo (ad es. illustrando per ogni tela dei dati di dettaglio).
• Dripping in Fat la metafora discussa è uno stendibiancheria come catalogo prodotti. L’idea è simpatica, pertinente rispetto alla merce in vendita ma non consente alcuno scambio di significato od esperienza. E’ una mimesi nel senso evidente poichè l’imitazione del reale genera una forma artistica.
• Gowalla in questo caso non si può proprio parlare di metafora e anche la mimesi è inappropriata. Uno storyboard viene utilizzato per illustrare le funzionalità di un prodotto ma senza legenda sotto l’immagine non sarebbe possibile fare alcun mapping.
• XHTML Cafe in questo caso si ricerca una metafora spaziale, è un tentativo di creare una corrispondenza tra le posizioni convenzionali degli elementi nel prototipico café e le voci del menù. Un tipo di metafora vecchio stile, ormai desueta e poco informativa rispetto allo specifico tema del sito.

L’unico esempio coerente di metafora è quello di CulturedCode: Status in base alla quale il flusso di sviluppo è visualizzato tramite una tabella oraria aeroportuale. In questo caso è possibile fare un mapping tra lo stato di sviluppo e lo stato di viaggio, la versione e il codice di volo, la destinazione ed il nome di progetto. La familiarità con la lettura della tabella oraria può essere trasferita nella comprensione del workflow di sviluppo.

La mimesi non necessaria

Gabriele Romanato nel suo Form sperimentali con i CSS si domanda se

Non sarebbe interessante avere dei form che assomiglino in tutto e per tutto al loro originale cartaceo?

Perchè mai, dico io? Ecco un esempio di mimesi non necessaria e limitante: molti moduli cartacei sono brutti e difficili da usare in partenza, duplicarli in digitale corrisponde ad un’immotivata perdita di tempo. Oltretutto, la presenza di banche dati consente di velocizzare notevolmente la compilazione dei moduli: dati anagrafici, dati fiscali, dati geografici etc. non dovrebbero più essere compilati dall’utente ma dovrebbero essere presi in carico dal sistema.

La quadrettatura dei campi nel tipico bollettino postale è funzionale alla lettura nei dispositivi elettronici, riprodurla in un modulo web sarebbe puro manierismo. Invece di cercare un’inutile mimesi nel tentativo di avvicinare il web al reale, bisognerebbe concentrarsi su quelle metafore che consentono sì di mantenere la familiarità del reale ma anche di andare oltre, approfittare della potenza del mezzo ed acquisire così un reale beneficio nell’utilizzo delle procedure digitali.

No related posts.

Usabilità del banner

Se si limitassero a delle semplici gif saremmo tutti più felici: sviluppatori ed utenti. Minore complessità e minor peso delle pagine, maggiore pulizia del codice.
L’ordinario del banner invece è il formato flash, con tutte le implicazioni che ne conseguono in termini di peso, accessibilità, intrusività.
Se si aggiunge a questo che la gestione dei banner solitamente è affidata al javascript si profila ben presto un quadro di accessibilità precaria. Non che la mancata fruizione del banner possa danneggiare l’esperienza dell’utente disabile, semmai in questo caso i problemi sono per tutti – disabili o meno – e derivano dalla presenza di aree di pagina compromesse da plugin mancanti o da javascript corrotti o mal eseguiti che possono arrivare a bloccare il browser in loop infiniti.
Per gli utenti avanzati l’utilizzo di javascript e Flash possono rivelarsi aspetti positivi: basta disporre di plugin per Firefox come AdBlock plus; Noscript, FlashBlock per liberarsi definitivamente dalla scocciatura dei banner. Per tutti gli altri invece se non sono problemi sono quantomeno seccature.

Lasciando gli aspetti tecnici per parlare di forme, è indubitabile come la presenza del banner sia a corredo dell’articolo e non indispensabile al suo significato e contenuto. Nella fruizione di un quotidiano lo scopo primario è la consultazione delle news pertanto tutti gli ostacoli a questo obiettivo dovrebbero essere ferocemente perseguiti e sterminati. E’ bizzarro come, nel caso dei banner, questo principio venga contraddetto: più intrusivi sono meglio è. La pubblicità deve essere vista altrimenti non porta contribuiti al giornale. Pertanto è valido forzare la mano all’utente impedendogli di accedere al contenuto fino a quando non ha guardato anche il banner che poi sarà anche bello, dinamico, musicale grazie a Flash.
Volendo fare un campionario dei banner peggiori della mia esperienza 2009 potrei citare:

• La campagna Danacol: Little Tony ci ricorda che il colesterolo uccide con l’implacabile refrain di Cuore matto con tanto di tum tum e banner che va a tutto schermo non appena ci passi sopra il mouse. Ed il banner stava proprio nell’angolo destro, vicino alla scrollbar dove non potevi mancarlo.
• La campagna di una compagnia aerea con pop-up a centro pagina e bottone chiudi che non chiude ma linka al sito del vettore.
• La campagna di un film horror nella testata della pagina che – al movimento del mouse – fa partire una colonna sonora modello “unghie su lavagna” che non si può fermare se non cambiando sito o aspettando la chiusura automatica del banner.
• La campagna di UPS, con il suo testimonial alieno che muove un braccino artritico in un improbabile saluto. Da brivido.

In tutti e quattro questi casi la fruizione degli articoli è disturbata dalla presenza pubblicitaria: non si può ignorarla ma la si ricorda in termini negativi, il che mi pare non sia esattamente lo scopo primario di un banner.

Sostenibilità dei banner

A meno di voler pagare la lettura del quotidiano on line in denaro corrente, la pubblicità è il prezzo da pagare. Pertanto ben venga ma fintanto che è sostenibile:

• non mi interrompe, non mi distrae mentro leggo un articolo;
• non mi provoca malessere, fastidio, spavento con effetti visivi o sonori esagerati o inattesi;
• non agisce al di là del mio controllo: non si attiva da sola, mi consente di interromperla;
• non blocca il mio sistema, non mi costringe all’installazione di plugin;
• non costituisce l’elemento predominante della pagina;
• non si annida subdolamente tra i contenuti fingendosi parte di essi.

L’ultimo punto fa riferimento ad una forma di inserzione pubblicitaria che per dimensioni ed aspetto non è intrusiva ma che ha un comportamento subdolo che la rende tale: si tratta di script che si applicano automaticamente a parole del testo rendendole dei link verso contenuti pubblicitari. Questa pratica deforma il significato di approfondimento di un link ipertestuale e non consente all’utente di fare distinzione tra pubblicità e link reale, produce una sorta di inganno molto spiacevole.

Dagli esiti della ricerca appare chiaro che l’efficacia di un banner non è tanto legata alla sua multimedialità, prominenza o intrusività quanto alla sua capacità di proporsi all’utente in momenti in cui è disponibile a cogliere il messaggio pubblicitario: durante la navigazione esplorativa, accanto ai risultati di una ricerca. E’ legata alla disposizione del layout e al compito dell’utente, alla pertinenza con i contenuti.
E nonostante questo la sfida sembra ancora essere a “chi grida più forte”, contravvenendo ad una delle regole auree della costruzione di pagine web: quando tutti urlano diminuiscono per tutti le probabilità di essere ascoltati.

No related posts.

Riflessioni sulla comunicazione

I manifesti della campagna LILT si fanno notare sul metro, per strada. Sono colorati, spiritosi e tutto ad un tratto il tono leggero si fa serio: “ e contro il cancro, cosa hai fatto?“. Richiama all’azione: pensaci, prenota una visita, agisci per tempo. Non è uno scherzo.
Sul web non ho notato la stessa visibilità per la campagna.
Ne parlano diversi siti ma è difficile trovare un’immagine decente, il sito della sezione milanese è solo quinto nei risultati della ricerca (con una chiave molto specifica: “lilt contro il cancro cosa hai fatto”), terzo se si specifica “lilt milano”. Onestamente però, io che il manifesto l’ho guardato con attenzione, non avevo capito che la campagna è promossa dalla sezione milanese e credevo fosse nazionale.
Sul sito LILT nazionale trovare il riferimento alla campagna è arduo: già altrove ho sottolineato come la struttura di navigazione sia terribilmente complessa, manca un motore di ricerca interno e ci sono molti errori 404. Frustrante, purtroppo. Ho provato con Google (site: http://www.legatumori.it/ “contro il cancro cosa hai fatto”) ma niente perciò sono tentata di concludere che la notizia sul sito nazionale non è proprio passata.
Infine, il sito della TBWA\Italia – curatrice del progetto – è fatto interamente in flash perciò l’indicizzazione in Google non è delle migliori. In ogni caso difficile che il target medio della campagna cerchi informazioni a partire dall’agenzia che firma il manifesto…

Questa mancanza di visibilità web è proprio un peccato perché riduce le possibilità di approfondimento per l’utente.
Possiamo immaginare uno scenario simile a quello che ho realmente vissuto io: una mattina come le altre corro per prendere i mezzi in metrò, mezza addormentata. Scendo e una nota di colore mi colpisce in mezzo al grigiore della stazione: il manifesto LILT. Conosco l’organizzazione, mi soffermo per una scorsa rapida e corro a lavoro.
Più tardi cerco informazioni sul web ma non è che mi sia segnata il link o altro: chiedo a Google e cosa trovo? Già, dipende dalla mia buona memoria a) ricordarmi il testo del manifesto e b) notare che la campagna è promossa dalla LILT Milano per riuscire a trovare dei riferimenti .
A mio giudizio questo è molto negativo, se la comunicazione sui siti istituzionali fosse stata meglio concertata la visibilità ne avrebbe giovato e con essa la possibilità per più persone di approfondire il messaggio mettendo in atto l’invito a contattare i centri per la prevenzione (elenco degli ambulatori di Milano e nazionali).

No related posts.

Lunedì 30 novembre si svolgerà la terza edizione del “Blue Beanie Day” ossia il giorno in cui i professionisti del web indossano un cappellino blu a significare il loro impegno per il supporto degli standard web.
Sul sito del promotore dell’iniziativa Jeffrey Zeldman si può trovare il PSD per creare la propria fotografia col cappellino blu da usare per unirsi al gruppo di Facebook o a quello su Flickr.

Lodevole iniziativa ma lavorando nel settore mi chiedo sempre più spesso se il tema dell’usabilità interessi mai a qualcuno, a parte i professionisti stessi…

No related posts.

Risorse

• SEO
  Davide Vasta – Apogeo – 2009
• Siti web ad alte prestazioni
  Steve Souders – Tecniche Nuove – 2009
• Ecologia dei siti web
  Maurizio Boscarol – Tecniche Nuove – 2003

Le pratiche di SEO, usabilità ed ottimizzazione del codice presentano numerose aree di convergenza. Questa convergenza è facile da immaginare poiché tutte e tre le discipline puntano all’ottimizzazione di un sito, quindi insieme concorrono a determinarne qualità e successo. Tuttavia SEO, usabilità e ottimizzazione del codice hanno differenti aree di applicazione ovvero – nell’ordine – motori di ricerca, esperienza utente e tecnologie. Da qui la presenza di conflittualità o meglio di indicazioni che non possono trovare simultanea applicazione e dunque implicano la selezione di priorità.
E’ in questi punti che si esercita la discrezionalità del team di sviluppo nel privilegiare determinati aspetti, discrezionalità che dovrebbe tener conto degli obiettivi prioritari di un sito.

Come guida nell’esplorazione di convergenze e compromessi tra le pratiche di SEO, usabilità ed ottimizzazione del codice possiamo prendere ad indice le 6 regole
d’oro SEO suggerite da Davide Vasta.

1) PROMINENZA

• SEO: le parole chiave in alto a sinistra
• USABILITA’: le parole/i concetti chiave ad inizio testo o inizio paragrafo
• PULIZIA DEL CODICE elimina il codice ridondante in cima alla pagina

Gli spider dei motori di ricerca, al pari degli utenti adottano il senso di lettura occidentale. I contenuti rilevanti vanno messi per primi. Allo stesso modo meno codice superfluo sta in cima al sorgente migliori saranno i tempi di risposta della pagina nelle sue parti cruciali.

2) PESO

• SEO: rapporto tra frequenza delle keyword e parole totali
• USABILITA’: pertinenza dei contenuti
• PULIZIA DEL CODICE: tempo di caricamento della pagina, peso dei suoi componenti

Quando l’utente arriva su una pagina da un motore di ricerca si aspetta di trovare contenuti pertinenti con quanto cercato. Uno dei criteri di pertinenza per i motori di ricerca è il rapporto tra parole chiave e totale delle parole del testo. L’aspetto tecnologico del peso è invece costituito dalle dimensioni e tempi di caricamento di una pagina, dato dall’insieme dei file in essa richiamati.

3) PRESENZA

• SEO: collegamento con altri siti, partecipazione di valore alla comunità
• USABILITA’: capacità di farsi trovare, autorevolezza
• PULIZIA DEL CODICE: pulizia, conformità agli standard

Farsi trovare, collegarsi con altri, offrire contenuti di valore, costruirsi una reputazione positiva sul web. Avere dei buoni contenuti non basta se non li si rende visibili e se non si opera per farli conoscere, viceversa partecipare agli ambienti “giusti” non serve a nulla se questa partecipazione è passiva e non porta valore alla comunità. La buona relazione non può essere disgiunta dal buon contenuto. In questo caso, codice pulito e conforme agli standard aiutano ad allargare la possibile audience garantendo una buona fruibilità del contenuto e della relazione stessi.

4) PROSSIMITA’

• SEO: vicinanza tra le keyword
• USABILITA’: organizzazione spaziale dei contenuti, “colpo d’occhio”
• PULIZIA DEL CODICE: riduzione degli spazi bianchi superflui, contenuti vicini alla cima del codice sorgente e vicini tra loro

Le persone analizzano le pagine cercando di suddividerla in aree semanticamente significative: testata, navigazione, contenuto… Tenere una suddivisione della pagina che agevola questa naturale tendenza dell’occhio umano facilità la scansione dei contenuti, essi stessi organizzati secondo un criterio che mantiene un concetto per paragrafo e concetti collegati vicini. Parole chiave vicine vengono privilegiate ed aumentano le probabilità di una pagina di rientrare nei risultati di una ricerca.
Gli spider fanno “meno fatica” ad analizzare una pagina se nel sorgente i contenuti sono vicini all’inizio della pagina e tra loro, tra l’altro questa pratica agevola la navigazione degli utenti che utilizzano tecnologie assistive.

5) PAGE RANK

• SEO: ottenre link da siti con Page Rank superire al proprio
• USABILITA’: referenziazione
• PULIZIA DEL CODICE: –

Il page Rank è uno dei criteri di posizionamento nelle pagine dei risultati di una ricerca: più è alto maggiori sono le chance di stare in prima pagina, più è elevato migliori sono i contenuti poiché il page rank è un indice costruito dal basso ovvero attraverso lo scambio di link. Più un sito riceve link, più sarà di qualità.
Il page rank si potrebbe considerare una sorta di referenza, una valutazione collettiva della qualità di un sito.

6) POPULARITY

• SEO: numero di link che contengono una certa keyword e puntano tutti alla medesima pagina
• USABILITA’ referenziazione, pertinenza, autorevolezza
• PULIZIA DEL CODICE –

La popularity è una metrica di pertinenza di una pagina rispetto ad un contenuto, anche in questo caso costruita dal basso ovvero dagli utenti che linkano un determinato contenuto con una determinata parola.

Compromessi

Le indicazioni di SEO e usabilità sono convergenti nella maggior parte dei casi: le tecniche SEO puntano a rendere maggiormente visibili dei contenuti pertanto, su dei buoni contenuti, le tecniche SEO non possono che essere migliorative. Maggiori problematiche comporta il confronto con le esigenze di ottimizzazione della pagina poiché il richiamo alla pulizia e “leggerezza” del codice implica il ripensamento di elementi grafici e dinamici che – sebbene non indispensabili – sono funzionali all’esperienza utente.

Preminenza

Volendo rispettare alla lettera le indicazioni sulla preminenza dovremmo iniziare le nostre pagine web direttamente dal contenuto, adottando un linguaggio fatto prevalentemente di sostantivi. Nella pratica il rispetto letterale di questa indicazione è impossibile, pertanto il compromesso più praticato è quello di ridurre il numero di righe in cima alla pagina e spostare il più possibile gli script in basso. Molto spesso questo implica minimizzare ed accorpare i css e gli script, col risultato di avere più chiamate server e file più grandi e quindi di ritrovarsi con pagine più lente e codice più difficile da manutenere. In questi casi il compromesso da stabilire è quello tra velocità di caricamento e velocità di manutenzione delle pagine, con risultati che nella maggior parte dei casi prediligono la seconda opzione.

Peso

Il peso della pagina in termini tecnologici è un concetto diverso dal suo peso semantico, anzi è l’opposto: da un lato si tratta di alleggerire le dimensioni, dall’altro di arricchire la significativà dei contenuti lavorando sul linguaggio. Nel primo caso si tratta di risparmiare sul superfluo e limare il necessario (numero di chiamate, peso delle immagini e degli script etc.), nel secondo di raffinare il linguaggio mantenendo saldo il contenuto.
Testi privi di sinonimi non sono compatibili con l’italiano e l’esagerata ripetizione dei termini viene penalizzata dagli stessi motori di ricerca (Overoptimization, keyword stuffing). Il compromesso è dato quindi dall’adozione di perifrasi e dall’utilizzo della marcatura semantica per link e immagini in modo da incrementare il conteggio complessivo delle occorrenze delle keywords sfruttando elementi che non interferiscono con la lettura del testo.

Presenza

In questo caso il SEO tende ad interferire con l’usabilità: contenuti costruiti apposta per ottenere link citando senza elaborazione altrui lavori, contenuti copiati dall’originale omettendo i riferimenti, commenti del tipo “sono d’accordo” o “interessante” o “bell’articolo!” che a null’altro servono se non a pubblicare il proprio link in coda ad un buon articolo. Queste sono le pratiche che distruggono la reputazione on line e privano di utilità i testi anche qualora riescano a comparire in cima ai risultati di una ricerca (es. doorway page).

Prossimità

Il principio di prossimità tra elementi simili è un buon principio organizzativo in quanto è parte integrante del sistema con cui la mente umana organizza la percezione (secondo le leggi della Gestalt: somiglianza e vicinanza). Dal punto di vista degli spider, prima e vicino è meglio poiché spesso la scansione è limitata ad un numero limitato di kbytes. Libertà espressiva e libertà grafica tendono però a contrastare con un criterio organizzativo che riconduce la struttura di pagina a pattern convenzionali (layout con testata, footer e due o tre colonne). Le indicazioni delle pratiche di ottimizzazione della pagina sono in questo caso coerenti pertanto il conflitto è esterno e riguarda scelte espressive ed estetiche del team di sviluppo.

Page rank e popularity

Anche in questo caso le indicazioni tra SEO, usabilità ed ottimizzazione del codice sono convergenti. Il compromesso è relativo ai tempi e modi di perseguimento degli obiettivi: lento e manuale attraverso la costruzione di una reputazione web basata sulla partecipazione attiva, veloce ed automatico attraverso l’acquisto di link e referenze presso siti ad alto traffico. In ogni caso il miglioramento degli indici di popularity e page rank è un’attività che richiede alcuni mesi perché se ne possano apprezzare gli effetti.Sta dunque al team di sviluppo valutare l’economicità dell’uno o l’altro approccio.

No related posts.

Per i suoi obiettivi l’usabilità non può essere la Cenerentola dello sviluppo web: per fare in modo che l’utente sia soddisfatto della sua esperienza bisogna in prima battuta chiedersi chi è l’utente?, cosa può fare sul nostro sito?, come possiamo agevolarlo?, come possiamo conciliare i suoi obiettivi con i fini del sito?
Se l’usabilità viene chiamata in causa a progetto finito, può soltanto valutare di quanto si è mancato l’obiettivo di un sito usabile e stimare i costi delle correzioni. Molto più sensato ed economico sarebbe invece tenerne conto dal principio della progettazione.

Nel mio lavoro di ogni giorno vedo che, mancando proprio una progettazione nella realizzazione dei prodotti per il web, il risultato è spesso lontano dall’essere usabile ma la cosa sembra proprio non turbare nessuno nella committenza. Quando un progetto parte da uno schema grafico con le sfumature e i bordi arrotondati ma senza pianificazione delle architetture informative, delle funzionalità, degli strumenti di orientamento e navigazione è persino difficile preoccuparsi dell’usabilità perché – dalla mia posizione attuale di sviluppatore forzato – la domanda più pressante è: “Sì, carino. Ma com’è che deve funzionare?”
In molti casi lo sviluppatore “inventa” il comportamento delle pagine con due risultati:

• il committente si lamenta “ma non è così che lo volevo!”
• l’utente si interroga “ma perché fa così? come lo devo usare?”

Immaginate da soli lo spreco di tempo, risorse economiche ed energie nervose.

Giusto per esemplificare ecco una storia tratta dal vero sulla realizzazione di un motore di ricerca interno al sito.

In principio era un campo di testo (ottobre)

Nella grafica del committente spicca in mezzo al menù un bel box etichettato “cerca” con accanto l’immagine di una lente di ingrandimento.
Lo sviluppatore prepara la query “Prendi tutti gli elementi che contengono la parola X” e traduce la grafica in codice con


< form method="post" action="***">
<label for="q">Cerca</label>
<input type="text" id="q"/>
<input type="image" src="***" />


e ritiene di aver finito.

Poi divenne la ricerca sul web (novembre)

La committenza si lamenta che con il campo così realizzato non è possibile cercare con Google.

Lo sviluppatore non può contestare le richieste della committenza per cui modifica il form aggiungendo dei radio button per distinguere tra ricerca interna e ricerca sul web ed aggiunge del javascript per dirigere la query sull’una e sull’altra.

Poi vennero i contenuti video e audio e i blog (gennaio)

Viene terminata la realizzazione della sezione multimedia.

Lo sviluppatore aggiunge alla query la ricerca sui due elementi nuovi e si inventa una resa “grafica” per la pagina dei risultati. Fortunatamente alla committenza piace ma….

Lo sviluppatore Crea un nuovo box di ricerca dedicato ed una query apposita.

Poi tornò il grafico (febbraio)

La pagina dei risultati non piace più: viene inviato un nuovo pdf con la grafica desiderata.
Notare: PDF non file grafico così è necessario “indovinare” font e colori e ritagliare alla bell’e meglio gli elementi grafici. Passano oltre due settimane per avere le informazioni mancanti e i PSD.

Poi venne la performance (maggio)

L’utente si lamenta del fatto che per la parola chiave del sito la ricerca produce soltanto 200 risultati.

Ma lo sviluppatore cosa ne sa della pazienza dell’utente? Innalza la soglia della query a 1000 risultati

Poi venne la ricerca temporale (giugno)

Viene richiesta la realizzazione di un modulo di ricerca per data da apporsi nella pagina delle ricerche. La grafica segue di una settimana la richiesta e presenta un campo di testo, due campi data “da” e “a” e la solita icona a lente per la ricerca. Lo sviluppatore realizza in Ajax il form con i calendari.

Lo sviluppatore adatta il modulo vincolando i valori dei campi in modo che automaticamente limitino sia la scelta da calendario sia l’inserimento manuale. Predispone i messaggi di errore (anche quello inutile poiché la query restituisce al massimo 1000 risultati mai di più).

Nonostante le incoerenze viene apportata la modifica.
2 giorni dopo segue mail:

C: forse era meglio prima. Rimettiamo la ricerca di base su uno span temporale da oggi meno un anno”.

Conclusione della storia

Lo sviluppatore potrebbe ghignare e dire “te l’avevo detto” ma più che altro si arrabbia perché sta perdendo tempo e pazienza.
Se invece di inventare pezzi di interfaccia ed interazione secondo l’estro del momento, senza riflettere su come si inseriscono nel sistema complessivo, se servono all’utente e su come verranno usati, si fosse spesa mezza giornata ad inizio progetto per definire i requisiti del motore di ricerca interno la realizzazione avrebbe richiesto meno tempo e meno soldi.
Oltrettutto: tutte le modifiche sono avvenute a prodotto attivo ossia mentre gli utenti usavano il sito e il suo motore di ricerca.
Immaginate quanto possano avere apprezzato un servizio che nell’arco di pochi mesi ha cambiato molte volte il suo comportamento in modo pressoché invisibile. Immaginate come si siano trovati a loro agio.

Dunque mi chiedo: cosa ho studiato usabilità a fare? Se la norma della realizzazione di progetti web è questa conviene diventare tutti programmatori perché ne serviranno molti per poter continuare a mettere pezze al sistema.

No related posts.