In poco più di due anni mi sto avvicinando ai cento articoli, e ormai credo di aver sviluppato un modo consolidato di procedere: prima nasce l'idea, viene definita meglio, poi sviluppo gli esempi, una buona fase di test e in ultimo scrivo l'articolo o la serie. A volte capita che nella fase di definizione e
valutazione di un'idea, questa venga abbandonata ancora prima della codifica HTML, CSS e Javascript.
Difficilmente mi è capitato di abbandonare un articolo dopo la fase di codifica e soprattutto superati i test di compatibilità con i browser. C'è stato un caso recentissimo però, e parlarne è un buon modo per riallacciarmi a questo post di Marco Casario sull'usabilità di AJAX che condivido pienamente.
Devo ammetterlo: non mi sono mai interessato molto a sviluppare con AJAX, ma l'affascinante semplicità di AHAH mi ha offerto lo spunto per dare un seguito, con la quinta parte, ad una delle serie più impegnative che ho scritto, ovvero il template con PHP e CSS in quattro parti (ecco i link alla prima,seconda, terza e quarta parte).
Il template in PHP offre una possibilità comodissima: svincolare i contenuti centrali di un sito dalle sezioni invariabili (ovvero header, navigazione e footer), così da consentire un modo semplice di separare struttura e contenuti effettivi. Per come è stato implementato si presta benissimo a una trasformazione verso AJAX con AHAH.
Un requisito essenziale che ho stabilito da subito è l'accessibilità ai contenuti a utenti e motori di ricerca: ho pensato così di mantenere i link effettivi della versione originale.
Uno script composto da una funzione non-intrusiva, dopo aver verificato il supporto del DOM e dell'oggetto XMLHttpRequest procede quindi a trasformare le inclusioni PHP della index in inclusioni AHAH: appena 15 righe. Includo lo script e la mini-libreria di AHAH nell'head del template e il gioco è fatto.
Perfetto, mi dico: è davvero semplice e funziona. E in caso non ci sia supporto per il DOM e/o AJAX il sito resta totalmente navigabile grazie ai link alla pagina PHP in chiaro. Pronti per scrivere allora! Poi penso al vantaggio fondamentale: il caricamento delle pagine è molto più veloce e consente un notevole risparmio di banda dato che vengono richiesti e trasferiti solo i contenuti centrali invece delle pagine per intero. Ma...ci sono solo due piccoli-grandi però: l'url
del sito resta lo stesso qualunque sia la pagina visualizzata e il tasto indietro non funziona. L'accessibilità ai contenuti è garantita, i tempi di accesso sono ridotti ma si annullano due modalità di interazione essenziali dell'utente.
Diciamola tutta: dal punto di vista dei link e dell'utente, una soluzione simile si presenta ancora peggio di un sito fatto con i frame o con Flash. Quindi, sono giunto alla conclusione che per soluzioni basate su Ajax le cose da considerare sono (almeno) due:
- una graceful degradation nel caso Javascript o XMLHttpRequest non possano girare;
- modalità di interazione non peggiori in caso contrario.
Abbiamo la tendenza a considerare subito il primo punto, ma altrettanto fondamentale è il secondo punto: quello che mi ha trattenuto dallo scrivere l'articolo, che per ora rimarrà nel cassetto. Finchè magari non mi deciderà a implementare una soluzione tipo
Fixing the Back Button and Enabling Bookmarking for AJAX Apps.
In conclusione volevo aggiungere che AJAX, secondo me, è perfetto per applicazioni tipo Dark Eye o Gmail, ma forse davvero non è indicato per meccanismi di template o per emulare semplici inclusioni lato server su un intero sito.