jblog » Usabilità

jConfirmAction: finestre di dialogo “confirm” comode e personalizzate

Giacomo — Mon, 17 May 2010 13:12:14 +0000

jConfirmAction è un ottimo plugin jQuery che permette di inserire facilmente delle dialog box di tipo “confirm” (quelle con i 2 pulsanti “ok” e “annulla”) molto più gradevoli di quelle di default e molto più comode per l’utente.

Leggero. Il plugin è molto leggero: ha una dimensione di 1,21 kb (non compresso).

Accessibile. Uno dei maggiori vantaggi è che funziona anche in caso di javascript disabilitato. Questo perché al tag viene comunque impostato l’attributo href ma il plugin si occupa di bloccarne il comportamento di default con la funzione preventDefault(). A proposito dell’accessibilità con javascript ti consiglio di leggere questo articolo.

Migliora l’esperienza dell’utente. Una classica finestra di dialogo di tipo “confirm” appare sempre al centro della pagina. Questo comportamento potrebbe infastidire l’utente a causa del continuo via vai del mouse tra il link cliccato e il centro della pagina per cliccare “ok” o “annulla”. Il plugin jConfirmAction fa apparire la dialog box sopra il link cliccato, quindi con uno spostamento di pochi pixel l’utente arriva sui due pulsanti della dialog box. Se ciò ti sembra ininfluente pensa a una situazione in cui l’utente deve rispondere continuamente a più di una dialog box…

Semplice per il web designer. L’utilizzo di base del plugin richiede solo un paio di minuti per sistemare il link allo script, le righe di codice css e le immagini all’interno dei file e delle directory del sito.

Personalizzabile. Un aspetto che ho particolarmente apprezzato è la semplicità nella personalizzazione totale del plugin. Praticamente, in pochi passi, è possibile adattare alle proprie esigenze tutte le caratteristiche e i comportamenti del plugin: testi, immagini, css, html del box, codice javascript del plugin jquery.

La classica finestra “confirm”

Per valutare meglio il plugin è utile mostrare la classica dialog box “confirm” e il codice (javascript e jquery) per implementarla.

e link


   Delete me

La dialog box “confirm” con jquery

Demo e download

Per provare lo script: http://test.jblog.it/basicconfirm/

Per scaricare lo script: http://download.jblog.it/basicconfirm.zip

Il plugin jConfirmAction

e link (uguale a quello per la classica “confirm”)


   Delete me

Implementazione base di jConfirmAction

<-- CSS per la formattazione della finestra di dialogo -->

Demo e download

Anche se sul sito del plugin c’é una pagina dimostrativa ho voluto creare una demo svuotata di tutte le cose superflue in modo da evidenziare meglio il funzionamento del plugin.

Per provare lo script: http://test.jblog.it/jconfirmaction/

Per scaricare lo script: http://download.jblog.it/jconfirmaction.zip

Grafica

Per visualizzare correttamente il “fumetto” della dialog box abbiamo bisogno di almeno 2 componenti grafici:

contenitore del testo e dei pulsanti “ok” e “annulla”
sfondo del singolo pulsante

CSS

Questo plugin ha bisogno di alcune righe di codice css che naturalmente possiamo sistemare in un apposito file o incollare nel principale file .css del nostro sito (consiglio quest’ultima pratica per evitare la richiesta http dovuta al singolo file .css per il plugin).

CONFLITTUALITA’. Il problema è che i nomi delle classi sono abbastanza comuni e potremmo averli già utilizzati per altre classi. La soluzione è quella di andare a modificare direttamente il codice html della dialog box che si trova all’interno del file .js del plugin, come vedremo in seguito.

/* CONTENITORE PRINCIPALE */
.question {
	position: absolute;
	display: inline;
	text-align: center;
	width: 174px;
	height: 78px;
	font-size: 13px;
	line-height: 1.5em;
	/* immagine del contenitore del "fumetto" */
	background: url('images/bubble.png') left top no-repeat;
	padding: 10px 0 0 0;
	text-shadow: 0px 1px 0px #fff;
	margin-left: -7em;
	margin-top: -6em;
	opacity: 0;
}

/* PULSANTI */
.yes, .cancel {
	margin-top: .5em;
	margin-right: .5em;
	cursor: pointer;
	display: inline-block;
	width: 63px;
	height: 21px;
	color: #fff;
	text-shadow: 0px 1px 0px #000;
	/* immagine del pulsante */
	background: url('images/button.png') left top no-repeat;
}

HTML

L’html relativa al box del “fumetto” è molto semplice, quindi non credo che avrai grossi problemi se andrai a modificare la struttura del box.

Un buon motivo per modificare l’html è quello di evitare le possibili conflittualità con le classi del css, modificando i nomi delle classi associate ai div in nomi meno generici.

Nel file del plugin la parte relativa al codice html del box è questa:

$(this).after(
''+theOptions.question+'

     '+theOptions.yesAnswer+'
     '+theOptions.cancelAnswer+'
');

Un plugin alternativo

Una valida alternativa è il plugin jQuery Confirm sviluppato da Nadia Alramli.

La caratteristica che lo distingue da jConfirmAction è che quando si clicca sul link scompare il link e appare la domanda (con relativi link “ok” e “annulla”).

Sicuramente è molto più leggero di jConfirmAction in quanto non richiede immagini e codice css. Inoltre ha moltissime opzioni che consentono di adattarlo al meglio alle esigenze del sito.

Fra i due plugin (che sostanzialmente fanno la stesse cose) io continuo a preferire jConfirmAction perché esteticamente il fumetto è più bello!

Come riciclare inutili “listoni” in titoli e contenuti più usabili

Giacomo — Mon, 10 May 2010 05:00:01 +0000

Scorrendo i feed con Google Reader mi capita di leggere dei titoli abbastanza assurdi. Risultato: non leggo il post! Ti spiego perché…

Per iniziare ti faccio un po’ di esempi:

“30 best icon tutorials”
“100+ web designer resources”
“the big list of html5, javascript and css3″
“ultimate collection of photoshop tutorials”
“top 60 wordpress resources”

A primo impatto potresti pensare: “sei pazzo! con tutta quella roba che ti promettono non ci dai un’occhiata?!”.

Perché dovrei perder tempo a leggere un post enorme (pieno di link e di immagini da caricare) in cui potrei trovarci tutto e niente?

Questo è il punto di vista di chi segue più di 100 feed al giorno: in una situazione del genere è naturale che per non perdere tempo bisogna essere molto selettivi per beccare i post migliori.

In generale, quando scorro i feed leggo solo i titoli dei post e successivamente vado a leggerli. Quindi il titolo ha un’importanza fondamentale per decidere se leggere o meno il post, soprattutto se per leggerlo bisogna andare direttamente nel sito (o nel blog)! Fai così anche tu?

Alla cieca. Quando leggo un titolo del tipo “100+ web designer resources” mi chiedo “risorse riguardo cosa? software? script? grafica?” e finisco con un “boh… vabbè, andiamo avanti…”. Questo succede soprattutto perché una persona ha fretta di leggere solo le cose che le interessano e non andare all’esplorazione di qualcosa che non si conosce bene.

Lettura faticosa. In questi tipi di post (aka “mega-liste” ) ci sono talmente tante cose che risulta difficile guardarle tutte, conservarle e catalogarle nei preferiti, taggarle nei social bookmarks, condividerle su facebook o su twitter, ecc.

Lunghezza eccessiva. Hai idea di quanto sia lungo un post con 30 immagini e link!? E’ un po’ come per il “post definitivo” che viene spesso criticato a causa della sua lunghezza dato che non tutti hanno il tempo e la voglia di leggere un post di oltre 10 pagine.

Dare un titolo a un post del genere è veramente dura! Come si fa scrivere un titolo completo per un post che ha dei contenuti molto diversi fra loro?

Ecco le 2 strade che seguo per evitare una situazione simile.

Alternativa 1: post grande, focalizzato su un particolare argomento

Photo by Momentary Glimpse | http://www.flickr.com/photos/momentaryglimpse/25…

Tempo fa ho scritto un post-lista su dei pacchetti di icone che fossero abbastanza completi da soddisfare tutte le esigenze di un cms o di un sito medio-grande. Il post era abbastanza lungo ma nel titolo ho cercato di chiarire l’idea scrivendo “pacchetti di icone completi e definitivi”. (Spero di esserci riuscito…)

Se proprio vuoi pubblicare un post lungo:

focalizzati su un particolare settore o argomento
spendi 5 minuti in più per scrivere un buon titolo che fornisca una chiara presentazione dei contenuti

Un esempio? “Link Checker Tools & Broken Link Checking Software Mega List”: dalle parole “mega list” si capisce che non è un post da 2 righe, però è chiaro come i contenuti siano estremamente focalizzati sull’argomento “link checking”.

Alternativa 2: dividilo in post più piccoli

Photo by Chapendra | http://www.flickr.com/photos/chaparral/2714646118/

Per esempio, prendiamo il post “the big list of html5, javascript and css3″. Leggendo un titolo del genere mi immagino un’insalata di codici, tutorial, immagini, librerie, script, ecc. Perché dovrei stressarmi fra decine e decine di link?!

Divisione per argomenti. A una prima occhiata il post “the big list of html5, javascript and css3″ potresti dividerlo in 3 post riguardanti gli argomenti principali che si leggono dal titolo: html5, javascript, css3. Tuttavia, la divisione per argomenti è un po’ “ignorante”, nel senso che si limita solo a “spezzettare il post”.

Divisione per idee e soluzioni. Se i contenuti lo permettono, puoi effettuare una divisione trasversale del post, cioé dividerlo in post più piccoli rielaborando addirittura il senso di tutto quell’ammasso di roba. Ad esempio, dal post “the big list of html5, javascript and css3″ potresti ricavarne un altro sui “menù di navigazione” e il titolo diventerebbe “navigation menu with html5, javascript and css3″.

Dividere un post molto lungo in post più piccoli ha almeno 3 vantaggi:

scrittura immediata di titoli più dettagliati
molti post da pubblicare in più giorni senza “bruciare” un post molto grande in un solo giorno
maggiore probabilità che gli articoli vengano letti per intero

Conclusione

So benissimo che dietro la scrittura di un titolo (e di un post) ci sono tanti altri fattori: marketing, seo, scrittura web, ecc. Questo è solo un piccolo tassello di un enorme puzzle di linee guida sulla scrittura di post.

Quando leggi i feed, quanto sono importanti per te i titoli? Secondo te il “listone” inteso come “ammasso di contenuti” resta comunque un ottimo post? Pensi sia un bene il fatto di dividere e ottimizzare i “listoni”?

10 formati di banner e annunci da evitare

Giacomo — Fri, 19 Jun 2009 02:48:17 +0000

Se stai considerando l’idea di inserire un po’ di banner e annunci sul tuo sito ti consiglio di leggere questo interessante articolo pubblicato su Business Insider in cui vengono classificati i formati più odiati dagli utenti.

L’articolo è stato strutturato molto bene in quanto descrive i 10 formati incriminati fornendo lo screenshot del sito che lo utilizza, il tutto all’interno di una bellissima slide-show.

1. Banner sotto l’header

Spacca in due la pagina e sposta più in basso il suo vero contenuto.

2. Annunci simili al contenuto

Sono ingannevoli e causano l’abbandono involontario del sito da parte dell’utente.

3. Annunci animati

Provoca distrazione e, poiché sono di bassa qualità, riduce la credibilità del sito.

4. Annuncio espandibile al centro della pagina

Obbliga l’utente a cliccare sul pulsante “chiudi”, interrompendo fastidiosamente la navigazione.

5. Banner vicini al logo

Anche se ha il vantaggio di non interferire sulla struttura della pagina e, quindi, di non trascinare ulteriormente in basso il contenuto, riduce lo spazio riservato al logo diminuendo la chiarezza e la visibilità del brand.

6. Banner ampio in alto a sinistra

In molti casi, con un banner di questo tipo gli utenti si accorgono subito che non fa parte del reale contenuto della pagina.

7. Google Ads testuali

Interrompono il contenuto della pagina. Naturalmente il gestore del sito spera che vengano confusi con il contenuto e che, di conseguenza, vengano cliccati.

8. Pulsante “chiudi” nascosto

Spesso nei banner graficamente carini e animati si cerca di camuffare il pulsante “chiudi” o di ritardarne la sua apparizione. In questo caso gli utenti sono costretti a perdere tempo a cercarlo o a sorbirsi tutta l’animazione che generalmente è una sgradevole interruzione della navigazione.

9. Banner “a tutto schermo”

Questo tipo di banner occupa tutta l’area della pagina e obbliga l’utente a cliccare su “continua” (o qualcosa di simile) per accedere ai contenuti desiderati. Abbastanza “violenta” come soluzione.

10. Annunci appariscenti e ben amalgamati

Quando un banner o un annuncio assomiglia graficamente al sito e al suo contenuto tende a fondersi con la pagina risultando indistinguibile agli occhi dell’utente. In questo caso l’utente rimane disorientato, soprattutto se è un assiduo visitatore abituato al normale layout del sito.

Questa è solo una sintesi. Per leggere l’articolo originale e osservare i 10 screenshot dei siti che utilizzano questi formati vai su http://www.businessinsider.com/10-online-ad-formats-people-hate-most-2009-6.

Che ne pensi di questa lista? Secondo te è completa o avresti altri esempi negativi da aggiungere?

Come utilizzare Ajax: librerie, framework, ottimizzazione, caching, usabilità

Giacomo — Sat, 02 May 2009 09:39:15 +0000

Ajax è una tecnica di programmazione (non un linguaggio) che ti permette di sviluppare applicazioni web interattive. In pratica, grazie ad Ajax puoi aggiornare alcuni dati della pagina senza ricaricare completamente la pagina, migliorando le prestazioni del tuo sito.

In questo articolo: effettuare le richieste e gestire le risposte, formati per lo scambio dati, utilizzare librerie e framework javascript, memorizzare Ajax in cache, evitare risposte duplicate, migliorare l’usabilità delle applicazioni ajax.

Il termine “Ajax” è l’acronimo di Asynchronous JavaScript and XML.

Vedremo che, nonostante la tecnica Ajax preveda l’utilizzo di XML, si potranno utilizzare altri formati per lo scambio dati.

Il termine “Ajax” è stato coniato da Jesse James Garret nel post “Ajax: A New Approach to Web Applications“, il 18 febbraio 2005.

Cosa succede con e senza Ajax

Supponiamo di avere una pagina con un form composto da tre campi di testo: nome, cognome e telefono. Lo script lato-server deve ricevere i tre dati, cercarli nel database e stampare l’indirizzo associato.

Importante. Generalmente, lo script utilizzato con una chiamata Ajax è diverso da quello utilizzato per l’esecuzione senza javascript.

L’esecuzione standard dello script

N.B. i rettangoli tratteggiati indicano cosa viene caricato.

Prima fase. Si carica la pagina html, si scrivono i dati nel form e si inviano al server premendo il pulsante “invia”. Oltre a quelle dei dati, il server riceverà le richieste http degli altri componenti della pagina che dovranno essere ricaricati.

Seconda fase. Il server cerca l’indirizzo nel database, e il browser ricarica completamente la pagina con i nuovi dati o con un messaggio di errore (es. “indirizzo non trovato”).

L’esecuzione dello script utilizzando Ajax

Prima fase. Si carica la pagina html, si scrivono i dati nel form e si inviano al server premendo il pulsante “invia”. Al server arriva solo una richiesta http: quella dei dati inviati. Inoltre vengono stampati i componenti da mostrare successivamente (“tutto ok!”, “i dati … correttamente”, ecc.) nascondendoli con le regole dei css.

Seconda fase. Il server cerca l’indirizzo nel database e, una volta trovato, viene rispedito al browser che aggiornerà il componente riservato all’indirizzo. Gli altri contenuti stampati precedentemente (“tutto ok!”, “i dati … correttamente”, ecc.), vengono resi visibili, mentre i componenti relativi al form vengono nascosti. Per nascondere e mostrare i componenti si utilizzano le regole dei css.

Framework e librerie javascript

Un framework javascript è un insieme di librerie che facilita la scrittura di codice e applicazioni javascript.

Perché utilizzare un framework?

Ti permette di scrivere in poche righe quello che in javascript “puro” richiderebbe centinaia di righe
Elimina il problema della compatibilità browser-javascript eseguendo istruzioni diverse a seconda del browser che si sta utilizzando

Ecco i framework più famosi.

Prototype

Prototype is a JavaScript Framework that aims to ease development of dynamic web applications.

http://www.prototypejs.org/

jQuery

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.

http://jquery.com/

MooTools

MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.

http://mootools.net/

Dojo

Solve problems faster. Create better user experiences. Liberally licensed. Everything you need, all in one place.

http://dojotoolkit.org/

Ajax, jQuery e Php all’opera

Generalmente un’applicazione Ajax è composta dalla pagina html e dallo script lato-server da richiamare successivamente via javascript.

Il framework che utilizzo è jQuery, soprattutto perché, nel complesso, è molto più leggero e veloce rispetto agli altri.

Analizziamo ora il codice dell’applicazione Ajax di cui ho parlato prima.

Requisiti. Php 5.2, MySql 5, jQuery 1.3.

Demo dell’applicazione. Puoi provare l’applicazione Ajax qui.

Pagina html e codice javascript

Questa pagina si può dividere in due parti.

codice html
codice javascript per la gestione delle chiamate ajax e del codice html

Puoi vedere il file completo qui.

Html

All’interno del tag si possono distinguere due

. Il primo (id=”form_panel”) ospita il form e un

per la scrittura degli errori (id=”errors”); il secondo (id=”address_panel”) ospita un

(id=”the_address”) in cui si scriverà l’indirizzo trovato.


	
	
		INSERISCI I DATI
		
		
			
				
Nome (solo lettere)
				
				
			
			
				
Cognome (solo lettere)
				
				
			
			
				
Telefono (numeri, trattino "-", parentesi "(" e ")", spazio " ")
				
				
			
			
		
	

	
	
		INDIRIZZO
		

		< indietro

Javascript

Il codice javascript viene scritto direttamente nel codice html, ma potrebbe essere scritto in un file esterno (.js).

Vengono specificate 3 funzioni e 3 variabili.

$(document).ready(function(){ … }). In realtà, questa non è una funzione, ma un metodo di jQuery che, al posto dei “…”, consente di specificare il codice javascript da eseguire quando la pagina ha completato il caricamento.

function form_check(). Esegue dei controlli sui valori dei campi e restituisce “true” se non ci sono errori, altrimenti “false”.

function form_ajax_send(). Invia i dati del form allo script “myscript.php”, attende e gestisce la risposta.

var form_msgs = new Array(…). Array degli errori relativi al form (es. “dati non corretti”).

var error_msgs = new Array(…). Array degli errori relativi all’invio e alla risposta dei dati (es. “errore del db”).

var regexps = new Array(…). Espressioni regolari utilizzate in form_check() per controllare i caratteri dei dati inseriti.

L’oggetto XMLHttpRequest

Per inviare richieste http dinamiche bisogna utilizzare l’oggetto XMLHttpRequest. Questo oggetto ha una serie di proprietà e metodi.

Uno dei principali svantaggi legati all’utilizzo di questo oggetto sta nel fatto che non è standardizzato, quindi non è riconosciuto universalmente da tutti i browser. Infatti, Internet Explorer 6 e precedenti lo vedono come un ActiveX da richiamare in maniera diversa rispetto ai browser Mozilla.

La soluzione è quella di utilizzare un framework e lasciare che sia lui a occuparsi di effettuare i controlli di compatibilità e differenziare la chiamata e il funzionamento dell’oggetto XMLHttpRequest.

Per conoscere meglio l’oggetto XMLHttpRequest puoi consultare la pagina ufficiale del w3c (in inglese) oppure la pagina su Wikipedia.

Per approfondire la gestione di Ajax con jQuery puoi leggere la pagina della documentazione ufficiale di jQuery relativa ad Ajax: http://docs.jquery.com/Ajax.

Ajax

Analizziamo le righe di codice javascript relative alla gestione della richiesta e della risposta asincrona.

$.get("myscript.php",{firstname_get:firstname,lastname_get:lastname,phone_get:phone},
	// funzione "callback", cioé eseguita quando vengono restituiti i dati dallo script "myscript.php"
	function(data,status)
	{
		if(status=="success") { ... }
		else { ... } // status=="failure"
	}
);

$.get. Questa funzione effettua una richiesta GET. Alternativamente si poteva utilizzare $.post. A seconda del tipo di richiesta, nell0 script lato server bisogna utilizzare gli array $_GET e $_POST per ottenere i dati inviati.

“myscript.php”. Il primo argomento della funzione $.get. Specifica lo script da utilizzare.

{firstname_get:firstname,lastname_get:lastname,phone_get:phone}. Il secondo argomento della funzione $.get. Questo è un tipo di dati chiamato “Map”, dove “firstname”, “lastname” e “phone” sono le variabili riempite con i valori del form, e “firstname_get”, “lastname_get” e “phone_get” sono i nomi delle variabili passate allo script. Quindi, in myscript.php per leggere il cognome non utilizzeremo $_GET['lastname'] ma $_GET['lastname_get'].

function(data,status). Il terzo argomento della funzione $.get. Rappresenta la funzione “callback”, ovvero la funzione da utilizzare quando si riceve la risposta. Poiché la risposta è asincrona, cioé avviene in un secondo momento rispetto all’invio dei dati, non possiamo scrivere:

if(form_check())
{
	ajax_invia_dati();
	ajax_gestisci_risposta();
}

poiché, quando verrà chiamata la funzione ajax_gestisci_risposta() sicuramente la risposta non sarà ancora arrivata.

Per questo motivo è necessario specificare la cosiddetta funzione “callback” che verrà eseguita non appena ajax fornirà una risposta. Questa funzione ha due parametri: data (dati ricevuti), status (stato della risposta). Se status è “success” significa che tutto è andato a buon fine, altrimenti status sarà “failure”.

Come ottenere l’oggetto XMLHttpRequest. Le funzioni $.get, $.post, ecc. restituiscono l’oggetto XMLHttpRequest che potrà essere utilizzato con tutti i suoi metodi e le sue proprietà.

Script lato server (php)

Effettua una connessione al database
Esegue la query con i dati ricevuti
Stampa una stringa fra queste: “db error”, “no data”, o l’indirizzo trovato

Puoi vedere il file completo qui.

query("
	SELECT	`Address`
	FROM	`info`
	WHERE	`Lastname`='".$_GET['lastname_get']."' AND
		`Firstname`='".$_GET['firstname_get']."' AND
		`Phone`='".$_GET['phone_get']."'		;");

	// controlla quanti record sono stati trovati (se 0: indirizzo non trovato)
	if($mydb->affected_rows==0)	{ echo 'no data'; }

	// indirizzo trovato
	else
	{
		$address = $result->fetch_array(MYSQLI_NUM);
		echo $address[0];
	}
}
?>

Dati restituiti dallo script

“db error”, se si verifica un errore relativo al database (in fase di connessione)
“no data”, se non viene trovato l’indirizzo
stringa dell’indirizzo, se viene trovato l’indirizzo

Come impostare lo script per i test

Se vuoi testare lo script è necessario effettuare alcune semplici operazioni.

All’interno di myscript.php individua la riga $mydb = @new mysqli(‘localhost’, ‘root’, ‘root’, ‘mydb’); e sostituisci i valori del tuo database: host, username, password, database.
Crea la tabella “info” nel tuo database. Nello script c’è una query (CREATE TABLE … ) da copiare e far eseguire subito dal tuo dbms (es. phpMyAdmin). Se la crei manualmente è necessario creare 5 campi chiamati ID, Lastname, Firstname, Phone, Address.
Infine, inserisci un paio di record in modo che l’applicazione Ajax possa trovare qualc0sa nella tabella.

Formati di scambio dati

Per i dati da inviare come risposta possono essere utilizzati vari formati: testo semplice, html, xml, json, ebml.

Lo script dell’esempio precedente stampa testo semplice.

Testo semplice e html

Preferibile se si devono sviluppare applicazioni semplici che non richiedono massicci scambi di dati e complesse elaborazioni.

Il maggior vantaggio sta nel fatto che testo semplice e codice html non richiedono ulteriori elaborazioni per rendere i dati rappresentabili all’interno di una pagina xhtml o html.

Json

Json, acronimo di JavaScript Object Notation, è un ottimo formato per lo scambio dati.

Si possono rappresentare oggetti e array:

var object = { name : "Giacomo", phone: "123456789", object2: { msg: "Ciao" } };
var array = ["mystring", 100, { msg: "Ciao" }, object, 5*2, 0.134];

Per processare una risposta in formato Json, anziché $.get è necessario utilizzare$.getJson. Questa funzion processa automaticamente una risposta in formato Json in modo da poter utilizzare subito i dati.

Ad esempio, se la risposta è:

var object = { name : "Giacomo", phone: "123456789", object2: { msg: "Ciao" } };
var array = ["mystring", 100, { msg: "Ciao" }, object, 5*2, 0.134];

all’interno della funzione “callback” potremmo utilizzare le due variabili scrivendo semplicemente:

object.name.length; // per ottenere la lunghezza della stringa "Giacomo"
alert(object.object2.msg); // per stampare un alertbox con il messaggio "Ciao"
newvar = array[4] + 3; // per assegnare alla variabile newvar il valore (5*2)+3, cioé 13

Per saperne di più vai alla pagina ufficiale di Json: http://json.org/.

XML

XML, acronimo di eXtensible Markup Language, è un metalinguaggio di markup che permette di definire tag personalizzare per strutturare documenti complessi. Una volta ottenuta una risposta formattata in XML è necessario elaborarla per poterla gestire.

La lettura e l’elaborazione di un testo XML consiste nello scorrere la struttura del documento per recuperare i dati contenuti nei tag XML. Per scorrere la struttura del documento esistono librerie javascript che consentono di farlo semplicemente.

Utilizzare questo formato è vantaggioso nel caso in cui ci siano molti dati da ricevere, mentre è sconsigliabile nel caso in cui ricevano pochi dati in quanto i caratteri per i tag XML potrebbero superare quelli per i dati effettivi.

Memorizza le risposte Ajax in cache per evitare richieste duplicate

Come detto prima, le risposte Ajax non sono altro che risposte HTTP e, come in tutte le risposte HTTP, possono essere inviati gli header.

Naturalmente, gli header devono essere inviati dallo script lato server, prima di qualsiasi output.

Per memorizzare le risposte Ajax nella cache si possono utilizzare i campi di intestazione Cache-Control, Expires, Pragma, ETag. Nei casi in cui non si possa utilizzare la cache del browser ricorreremo a una tecnica javascript.

Per approfondire la gestione della cache dai uno sguardo al post precedente: http://jblog.it/2009/04/24/ridurre-richieste-http-come-utilizzare-cache-browser_124.html.

Richieste GET e POST: come si comporta il browser

Nell’esempio, utiliziamo un solo script lato server che restituisce 3 output diversi a seconda dell’esito dell’operazione: “db error” per l’errore del database, “no data” se non è stato trovato l’indirizzo, e la stringa dell’indirizzo trovato nel database.

Ti consiglio di leggere questo interessante articolo (in inglese) del w3c: URI, indirizzabilità, e l’uso di GET e POST.

Il comportamento del browser cambia in base al tipo di richiesta (GET e POST) e agli header inviati dallo script lato server. Analizziamo alcuni casi più da vicino.

Le richieste GET

L’indirizzo di una richiesta GET ha la forma:

http://localhost/ajax_phone/myscript.php?par1=ciao&par2=hello

Il comportamento di default del browser consiste nell’inviare sempre una nuova richiesta.

Tuttavia, se vogliamo che il browser memorizzi per 1 ora la risposta dello script lato server, inviamo i seguenti header:

header('Expires:Sun, 03 May 2009 23:18:45 GMT');
header('Cache-Control:public,max-age=3600');
header('Pragma:public');

In questo caso, quando l’applicazione Ajax invia la prima richiesta, il browser legge lo script e lo memorizza in cache. La volta successiva possono verificarsi due casi:

se si inviano dei dati diversi (ad es., se invece di “par2=hello” inviamo “par2=welcome”) il browser effettua una nuova richiesta e la memorizza in cache
se si inviano gli stessi dati, il browser si accorge che l’indirizzo della richiesta è uguale, quindi legge i dati dalla cache evitando di effettuare una nuova richiesta

Differenziare gli header. Se alcune richieste non devono essere memorizzate in cache, puoi inviare degli header diversi a seconda dell’ouput generato dallo script (prima di stampare qualsiasi output). Ad esempio:

if($output!="error")
{
	header('Expires:Sun, 03 May 2009 23:18:45 GMT');
	header('Cache-Control:public,max-age=3600');
	header('Pragma:public');
}
else
{
	header('Expires:Sun, 01 Jan 1970 02:00:00 GMT');
	header('Cache-Control:no-cache');
	header('Pragma:no-cache');
}

Forzare la richiesta. Per fare in modo che il browser effettui una nuova richiesta, anche se questa è già presente nella cache, basta inviare un ulteriore parametro con un valore variabile, ad esempio un numero casuale.

$.get("myscript.php",{firstname_get:firstname,lastname_get:lastname,phone_get:phone,random:Math.random()},
	function(data,status){...});

Le richieste POST

L’indirizzo di una richiesta POST ha la forma:

http://localhost/ajax_phone/myscript.php

E i parametri? Vengono inviati tramite protocollo HTTP, ma non sono visibili al browser.

Le richieste POST non possono essere memorizzate in cache.

Come evitare le richieste duplicate

Abbiamo visto che le richieste POST non possono essere memorizzate in cache.

Tuttavia è possibile evitare le richieste duplicate grazie a qualche riga di javascript.

Questa tecnica consiste nel memorizzare i dati inviati e ricevuti in un array, in modo che, prima di inviare una richiesta, si controlla se i dati da inviare sono già presenti nell’array. Se sono presenti, si leggono i dati ricevuti in corrispondenza dei dati richiesti e si procede con l’esecuzione dell’applicazione.

var my_array() = new Array();

/* Una volta riempito l'array avrà questo aspetto
myarray = Array(
	Array( Array('Mario','Rossi',3429752370), 'no data' ),
	Array( Array('Giacomo','Ratta',4325233), 'Via Beethoven, 21' ),
);
*/

Ogni elemento dell’array è un array di due elementi. Il primo è l’array dei dati inviati; il secondo è la stringa dell’output restituito.

// Esegue le operazioni con i dati ricevuti
function esegui_le_operazioni(data) { ... }

if(form_check())
{
	// Leggo i valori dei 3 campi del form
	firstname = $('#firstname').val();
	lastname = $('#lastname').val();
	phone = $('#phone').val();

	// Indica se sono state trovate i dati da inviare
	// Contiene l'indice dell'elemento contenente dati inviati e dati ricevuti
	found = -1;

	// Cerco i dati nell'array
	for(i=0;i=0)
	{
		esegui_le_operazioni(my_array[found][1]);
	}

	// Dati non trovati: nuova richiesta
	else {
		$.get("myscript.php",{firstname_get:firstname,lastname_get:lastname,phone_get:phone},
		// funzione "callback", cioé eseguita quando vengono restituiti i dati dallo script "myscript.php"
		function(data,status)
		{
			if(status=="success")
			{
				// Inserisco dati inviati e dati ricevuti nell'array
				// riga da adattare in base alle proprie esigenze)
				my_array.push(new Array(new Array(firstname,lastname,phone), data));

				esegui_le_operazioni(data);
			}
			else { ... } // status=="failure"

		}); //end-callback

	} //end-if
}

Quando utilizzare GET e quando POST

Il metodo GET è da preferire quando si devono inviare dati per il normale funzionamento della pagina e degli script
Il metodo POST si deve utilizzare quando quelli da scambiare sono dei dati sensibili (username, password, telefono)

Migliorare l’usabilità e l’accessibilità delle applicazioni Ajax

Spesso nella progettazione delle applicazioni Ajax l’usabilità lascia un po’ a desiderare: nessun messaggio di successo/errore, caricamenti infiniti senza segni di vita, ecc.

Certo, l’usabilità è un tema complesso e progettare siti e applicazioni usabili richiede tempo e buone competenze.

Tuttavia, ci sono alcune cose che devono essere fatte e che, fortunatamente, non richiedono troppo tempo.

Potrai vedere queste modifiche nello script di esempio.

Errori e messaggi

Ogni campo di input deve avere la relativa area dedicata ai messaggi di errore (“dati obbligatori”, “caratteri non validi”, ecc.)
La pagina deve avere un’area destinata ad ospitare i messaggi relativi all’esecuzione dello script (“ricerca eseguita con successo”, “errore dell’applicazione”, “errore del database”, ecc.)

Barra di caricamento

Nella maggior parte della applicazioni, per motivi tecnici, non è possibile inserire una barra di caricamento che rilevi la percentuale reale dei dati caricati fino a quel momento.

Generalmente, si preferisce mostrare un’immagine gif che può essere una barra di caricamento o un’animazione generica in modo che faccia sapere all’utente che l’applicazione sta lavorando.

Svantaggio. Durante il caricamento dei dati si potrebbe verificare un malfunzionamento che non blocca la richiesta. In questo caso il caricamento sarebbe infinito provocando l’abbandono del sito da parte dell’utente.

Soluzione 1. Puoi inserire un pulsante da far premere all’utente per fermare la richiesta http.

Soluzione 2. Analizza il tuo script e prevedi un tempo massimo entro cui restituire l’output, e, con javascript, impostare un timer che faccia fermare la richiesta Ajax una volta trascorso il tempo previsto.

// esegue la funzione stopAjaxRequest() dopo 10 secondi
setTimeout(stopAjaxRequest(),10000);

Come creare la funzione stopAjaxRequest().

L’oggetto XMLHttpRequest ha il metodo abort() che permette di fermare una richiesta http.
Le funzioni $.ajax, $.get, $.post, $.getScript, $.getJSON di jquery restituiscono un oggetto XMLHttpRequest.

1. Creiamo una variabile globale per l’oggetto XMLHttpRequest, che chiamiamo XHR

var XHR;

2. Creiamo la funzione stopAjaxRequest() che richiama XHR ed esegue il metodo abort()

function stopAjaxRequest() { XHR.abort(); }

3. Assegnamo a XHR l’oggetto restituito dalla funzione $.get che utilizziamo per inviare i dati

XHR = $.get("myscript.php",{firstname_get:firstname,lastname_get:lastname,phone_get:phone},
	function(data,status) { ... });

Se javascript è disabilitato…

Purtroppo, ancora oggi ci sono utenti che utilizzano browser che non eseguono codice javascript, che hanno scarsa compatibilità oppure con javascript disattivato.

La soluzione è quella di progettare applicazioni che funzionino sia con javascript che senza.

Questo potrebbe andare bene per la piccola applicazione Ajax realizzata per questo post. Tuttavia, se le applicazioni sono di un certo livello, il carico di lavoro aumenta notevolmente. Quindi progettare applicazioni ibride ha senso solo quando le applicazioni da realizzare devono offrire il massimo della compatibilità con i browser usati dagli utenti (ad es. siti governativi, pubblica amministrazione, ecc.)

Secondo me, data la piccola percentuale di browser non compatibili e di utenti che disattivano (erroneamente) javascript, e la presenza di siti importanti come ebay, microsoft, youtube che non offrono l’alternativa “no javascript”, si può benissimo sviluppare un sito senza preoccuparsi degli utenti che non potranno eseguire javascript.

Nel tag

Svantaggi di Ajax

Le chiamate effettuate non vengono registrate nella cronologia, a differenza di quanto avviene utilizzando iframe nascosti

I pulsanti “avanti” e “dietro” non sono utilizzabili poiché le chiamate Ajax non vengono memorizzate nella cronologia

L’utilizzo esclusivo di javascript viola il requisito 15 della legge Stanca: “la pagina deve essere fruibile anche in assenza di script”

L’oggetto XMLHttpRequest non è compatibile con tutti i browser. Internet Explorer 6 e precedenti lo vedono come oggetto ActiveX, e il browser potrebbe essere impostato a un livello di sicurezza tale da non permettere l’esecuzione di controlli ActiveX

L’oggetto XMLHttpRequest può comunicare solo all’interno del dominio. Se la destinazione è esterna al dominio bisogna creare un proxy lato server per poter comunicare all’esterno.

Poiché i motori di ricerca non eseguono codice javascript, essi non possono indicizzare i contenuti generati dinamicamente con javascript e Ajax

Libri e risorse utili

Ajax. Guida per lo sviluppatore. Seconda edizione. Hoepli (2007).

Con Ajax guida per lo sviluppatore scoprirete come sfidare le regole tradizionali di quello che può accadere sul Web e come liberarvi del consueto approccio “click and wait”, approfondendo le tecniche, i pattern e i casi di utilizzo di Ajax, così da crearvi un’esperienza d’uso senza precedenti nelle vostre applicazioni.

Link: http://www.hoepli.it/editore/visbook.asp?id=978-88-203-3923-4.

Ajax e Php. Sviluppare applicazioni web dinamiche. Hoepli (2007)

AJAX e PHP. Sviluppare applicazioni web dinamiche è la risorsa più pratica ed efficiente che possiate utilizzare per entrare nell’entusiasmante mondo di AJAX. Questo libro vi spiegherà infatti come creare applicazioni web in PHP che sfruttino al massimo le tecnologie Ajax.

Link: http://www.hoepli.it/libro/ajax-php.asp

Siti e pagine

Ajax: A New Approach to Web Applications

W3C: The XMLHttpRequest Object

Wikipedia: l’oggetto XMLHttpRequest

jQuery: Ajax

JSON.org

Ridurre le richieste HTTP (parte 1): come utilizzare la cache del browser

W3C: URIs, Addressability, and the use of HTTP GET and POST