Call to Action, cosa sono e qual è la loro importanza.

Le “call to action” sono inviti a compiere un’azione. Nel Web design e soprattutto, nel campo della usability, le Call to Action sono appunto elementi, distinguibili, che sollecitano il navigatore a compiere un’azione. Ovviamente, questi elementi, nelle interfacce web, proprio pensando al concetto di usabilità, diventano di enorme importanza e devono essere considerati con estrema precisione.

Normalmente, le Call To Actions, nelle interfacce web, assumono l’aspetto di bottoni attivi, che una volta cliccati rimandano il navigatore a concludere un’azione ben precisa (un pagameno, l’inserimento di dati in un form, una procedura d’acquisto, ecc…)

Data la delicatezza della questione, esistono regole precise per far rendere le Call To Actions in modo ottimale e con successo. Alcuni interessantissimi suggerimenti, vengono dati dal sito SMASHING MAGAZINE, che fa un’illustrazione piuttsoto ampia e dettagliata con esempi reali.

Per tutti i webdesigner quindi, sia esperti che non, è molto importante valutare gli aspetti che possono influenzare positivamente o negativamente una Cll To Action. E così, finiamo di nuovo  parlare di accessibilità e usabilità. Termini che ultimamente stanno cadendo un po’ nel dimenticatoio e non capisco il perchè.

Il (giusto) copywriting per siti web e social network

La Call To Action però non si ferma solo all’aspetto grafico:

essendo un elemento importante del marketing persuasivo, è chiaro che essa dovrà essere valutata anche in termini di contenuti. Cioè, cosa sta dietro ad una Call to Action e perchè il navigatore deve cliccare proprio lì e non altrove.

La Call To Action è una vera chiamata all’azione, quell’azione che dovete indurre o che volete venga fatta e rientra nell’alveo della comunicazione persuasiva perchè una volta che l’utente è giunto sul nostro sito, non dobbiamo permettergli di andare via, anzi, dobbiamo convincerlo addirittura a fare qualcosa che possa diventare un vantaggio per entrambi, cioè per noi e per l’utente. Sono dell’idea, anzi, diciamoci la verità, lo so con certezza, che 10.000 visite giornaliere con un bounce rate (frequenza di rimbalzo) del 99% sono meno utili di 500 con bounce rate del 10% e un tasso di conversione del 5 o addirittura del 10%.

Sappiamo bene che il rendimento del sito in termini di numero di visitatori e frequenza di rimbalzo dipende anche dal tipo di sito ma è anche vero che un sito web aziendale è fatto per “fare business” e non per pettinare le bambole e quindi è fondamentale che il visitatore rimanga “a casa nostra” o meglio sul sito per più di 30 secondi compiendo azioni che noi abbiamo cercato di indurre a compiere. Altrimenti, di che stiamo a parlare?

Ad esempio nel caso di siti aziendali è importantissimo stabilire un contatto con il visitatore, nel caso di siti di eCommerce bisogna vendere prodotti, nel caso di siti di informazione è necessario catalizzare l’attenzione richiedendo eventualmente un commento finale; c’è anche l’eventualità di voler unicamente fare brand, e la cosa può richiedere molto meno tempo, ma questo è un altro discorso.

La call to action è parte integrante del persuasive copywriting: bisogna spazzar via tutti i dubbi del potenziale cliente per spingerlo all’azione. Non sto dicendo di ingannarlo, sia chiaro, ma di riuscire a fagli comprendere il vero valore del prodotto (o del servizio) che si sta vendendo e soprattutto l’effettiva necessità, a volte inespressa.

L’accessibilità delle call to actions è strettamente legata a due aspetti: la semantica delle etichette usate per identificare un’azione e il modo con cui tale azione viene eseguita.

La semantica delle call to actions dovrebbe essere autoesplicativa. Un bottone, un link, dovrebbero avere un’etichetta che identifichi esattamente l’azione che l’utente andrà ad eseguire. Recentemente ho visto i cambiamenti apportati da alcuni social networks e CMS nelle call to actions degli upload di immagini: sostanzialmente ora abbiamo due pulsanti che recitano “Seleziona immagine”. Incredibilmente, manca un pulsante che dica “Carica foto”. Questo genera confusione negli utenti, tenendo anche presente che chi naviga con un lettore di schermo ha una visione seriale della pagina, ossia gli manca il colpo d’occhio globale che è tipico degli utenti che navigano con un browser visuale.

Occorre evitare etichette vaghe, generiche o poco chiare. Un’etichetta che va assolutamente evitata è “Clicca qui”. Se navigate una pagina che presenta delle call to actions con una simile etichettatura con un lettore di schermo, sentirete una serie interminabile di “(link) Clicca qui” che non vi forniranno nessuna informazione utile sulla natura della action che andrete ad attivare.

Un’altra cosa da evitare è l’abuso dell’attributo title dei link. Se usato con discrezione, questo attributo può fornire preziose informazioni contestuali sulla action da eseguire, ma se abusato, trasforma la navigazione della pagina in un calvario. Infatti i lettori di schermo associano a ciascun link il proprio titolo e lo leggono prima del contenuto dell’elemento.

Da un punto di vista grafico, e tenendo presente le esigenze degli utenti ipovedenti, quegli elementi che richiamano una action dovrebbero essere ben evidenti ed in rilievo, con caratteri sufficientemente grandi da poter permettere una lettura agevole. Soprattutto, si dovrebbero usare delle accortezze a livello di CSS per permettere a tali elementi di adattarsi ai cambiamenti nelle dimensioni dei font che un utente ipovedente può apportare alla pagina. Non da ultimo, dovrebbero presentare un adeguato constrasto di colore tra testo e sfondo, al fine di evitare problemi con chi è affetto da cecità ai colori.

nginx: un nuovo web server

JavaScript e il suo corretto utilizzo

Riguardo al modo con cui tali azioni vengono attivate, occorre fare una riflessione su JavaScript.

Ricordiamoci che JavaScript e accessibilità non sono incompatibili, a patto di rispettare alcune semplici best practices. Una di queste riguardano i link ed il modo di mantenerli accessibili anche con JavaScript disabilitato o non supportato. In tal senso occorre distinguere tra link effettivi (che conducono l’utente ad una nuova pagina o che comunque linkano a delle risorse) e link trigger, ossia link privi di contenuti effettivi ma che servono per “innescare” appunto delle azioni JavaScript.

Una pratica da evitare è quella dei link privi di valore per l’attributo href, come <a href="" id="trigger" >...</a>. Nei browser privi di supporto a JavaScript come Lynx, un link di questo genere avrà l’effetto di ricaricare interamente la pagina. Ovviamente possiamo interamente generare il trigger con JavaScript, ma poi il link non sarà disponibile qualora JavaScript non fosse supportato o disabilitato. Molti siti statici usano questa tecnica anche per generare i permanent link, in quanto il browser considererà la pagina corrente come valore mancante dell’attributo href.

Quindi occorre dare un valore a questo attributo, considerando anche il fatto che per le specifiche XHTML l’attributo href non può essere vuoto. Ma quale? Molti hanno scelto di usare il carattere cancelletto (#) come riempimento. Tuttavia, anche questa soluzione ha dei limiti, in quanto con JavaScript disabilitato o non supportato otterremo l’effetto di creare un riferimento ad un’ancora inesistente, il che può disorientare chi naviga il Web con una tecnologia assistiva non visuale.

La soluzione, ovviamente, è una via di mezzo: possiamo infatti creare un’ancora che punti a del contenuto effettivo presente sulla pagina. Nel caso di contenuto generato tramite JavaScript, possiamo usare un approccio di questo tipo:

<input type="text" name="email" id="email" />
  <span class="help"><a href="#email-help" id="trigger">Aiuto</a></span>

  <div id="email-help">
      L'email deve essere nel formato nomeutente@dominio.estensione
  </div>

Assegniamo degli stili al nostro div, che nasconderemo con JavaScript. Se JavaScript non è supportato o disbailitato, il nostro div resterà semplicemente visibile. Per nasconderlo, usiamo una classe CSS da linkare al momento del caricamento del documento:

.hidden {
position: absolute;
top: -1000em;
}

Sia jQuery che Prototype dispongono di metodi per nascondere un elemento, ma ricordiamo che essi fanno uso della dichiarazione display: none. Tale dichiarazione viene purtroppo interpretata dai lettori di schermo, che hanno un supporto parziale a JavaScript, impedendogli di leggere il contenuto di un elemento. A questo punto, se usiamo jQuery, possiamo scrivere:

$('#trigger').click(function() {

    $('#email-help').removeClass('hidden');

});

Ho volutamente evitato di inserire la dichiarazione return false; perchè alcuni lettori di schermo sono in grado di interpretare un evento click, equiparandolo in alcuni casi ad un evento da tastiera. Se avessi inserito tale dichiarazione, tali programmi non avrebbero seguito la destinazione del link e quindi non sarebbero stati in grado di leggere il contenuto del nostro div. L’unico effetto spiacevole per i normali browser è quello di vedere l’ancora aggiunta all’URL della pagina corrente, ma questo non inficia minimamente l’accessibilità e l’usabilità della stessa.

Con opportune modifiche, le stesse osservazioni si applicano anche ai bottoni, ovviamente tenendo presente le differenze nella casistica di eventi JavaScript disponibili.

Il primo principio di usabilità che si applica alle call to actions è l’identificabilità. Una call to action dovrebbe essere sempre immediatamente riconoscibile dall’utente e la sua funzione facilmente intuibile. Due sono gli aspetti coinvolti:

• layout della call to action
• etichettatura della call to action

Ciascun aspetto è indissolubilmente legato all’altro. Il layout di una call to action non dovrebbe mai pregiudicarne la riconoscibilità. Un bottone di un form, per quanto modificato tramite i CSS, dovrebbe sempre far pensare all’utente “Ora clicco qui”. Anzi, secondo quanto afferma Steve Krug, l’utente dovrebbe cliccare senza pensare se quello che vede è un bottone o no. L’azione dovrebbe essere immediata (nell’arco di 300 millisecondi o poco più, esattamente quanto stabilito da recenti ricerche sulla user experience).

Il secondo aspetto è legato invece al come una call to action viene definita testualmente. Le etichette dovrebbero essere semplici, chiare, autoesplicative. Un esempio è la traduzione della voce “Save” nel menu contestuale delle applicazioni Mac OS X: in lingua italiana, questa voce è stata resa come “Registra”, che certamente non è il massimo dal punto di vista della chiarezza. Quindi se un bottone deve lanciare un motore di ricerca, l’etichetta dovrà essere “Cerca” e così via. In questo caso la fantasia dovrebbe cedere il posto al buon senso: le convenzioni in questo caso sono utilissime.

E’ chiaro che sull’argomento ci sarebbe ancora tanto e tanto da scrivere ma lo scopo di questo lungo articolo è più che altro quello di far riflettere, di prendere coscienza su ciò che si sta facendo e soprattutto comprendere che un semplice bottone che dovrebbe indurre a contattarvi o a inviare una mail o una richiesta, non è una cosa così banale.

Design per aziende, Sketchin: “Partire sempre dal cambiamento…”