E’ stata rilasciata la versione beta 2 di WordPress 3.2, con alcune importanti novità. In attesa dell’uscita della release definitiva è stata inviata una comunicazione agli sviluppatori con l’invito a fare dei test: ci saranno infatti alcuni cambiamenti rilevanti, ed è bene che siano noti a tutti coloro che usano WordPress soprattutto in ambito lavorativo.

Requisiti minimi: PHP 5.2.4 e MySQL 5.0.15

Il primo fattore da considerare è il cambiamento dei requisiti minimi per l’installazione di WordPress. Dalla versione 3.2 in poi sarà necessario avere installati sul server PHP 5.2.4 e MySQL 5.0.15.

Questo potrebbe causare problemi con alcuni servizi hosting che utilizzano ancora la versione 4 di PHP: non è un caso così raro come si potrebbe pensare. Al momento di aggiornare a WordPress 3.2 ricordatevi di controllare la configurazione del vostro hosting in modo da evitare sorprese.

Aggiornamento a jQuery 1.6.1

Un’altra novità rilevante è l’aggiornamento della versione di jQuery inclusa in WordPress. Si passa da jQuery 1.4.4 alla 1.6.1, con un salto di ben due major release.

Tra le novità più importanti, la versione 1.5.0 e le successive non consentono più l’utilizzo di selettori del tipo [property=value], ma è necessario utilizzare la forma [property="value"].

Inoltre nel passaggio a jQuery 1.6.0 e versioni successive il metodo .attr() è stato sostituito da .prop(): in alcuni casi sarà quindi necessario modificare il codice, ed alcuni plugin potrebbero dare degli errori se non aggiornati di conseguenza.

Chi interessano queste novità?

Se siete tentati di sorvolare su queste novità, potreste avere delle brutte sorprese al momento dell’aggiornamento a WordPress 3.2, quando uscirà la versione finale. Ovviamente i diretti interessati a questo cambiamento sono gli sviluppatori di plugin e temi, ma anche se non siete dei programmatori e state semplicemente utilizzando WordPress per i vostri progetti, vi raccomando di provare ad installare in locale la beta 2 e controllare che tutto funzioni.

Per effettuare dei test sui vostri siti di sviluppo potete scaricare la versione beta 2 di WordPress 3.2 a questo indirizzo.

Ogni sito ormai dovrebbe avere una versione mobile: qualche tempo fa avevo suggerito MobilePress come soluzione per blog e siti basati su WordPress. Non sempre però un plugin può soddisfare tutte le necessità: in certi casi è necessario realizzare soluzioni su misura, con un modello di interazione differente dal classico punta e clicca. Basti pensare al numero enorme di smartphone touchscreen che sono in circolazione in questo momento: perché non sfruttare le potenzialità che offrono?

È anche per questo motivo che è nato Zepto.js, un framework JavaScript per dispositivi mobili basati su webkit. Integrandolo nella versione mobile (e solo su quella) potrete interagire con tutti i cellulari basati su iOs e Android, praticamente la maggior parte del mercato mobile.

Anche se il progetto è ancora in beta, si fa notare il peso della libreria: solo 2kb (nella versione compressa). Dieci volte meno rispetto a jQuery o Prototype, che devono preoccuparsi di funzionare anche su altri browser come Internet Explorer.  Siete ancora convinti di utilizzare gli altri framework per un sito mobile?

Tra le altre caratteristiche di Zepto.js:

• linguaggio compatibile con jQuery
• supporto Ajax
• riconoscimento di Tap, doppio Tap (pressione sullo schermo con un dito) e Swipe (scorrimento di un dito sullo schermo). Ad esempio:
• Open Source

Tap e Swipe possono essere usati semplicemente così:

$('selettore').tap(function(){...});
$('selettore').doubleTap(function(){...});
$('selettore').swipe(function(){...});

Potete scaricare zepto.js dal sito ufficiale. Se volete approfondire trovate su SlideShare anche le slide con cui Thomas Fuchs ha presentato la sua creazione.

il tuo browser non ha i requisiti necessari per visualizzare questo contenuto

Questo testo però è decisamente poco interessante per l’utente, ed ancora meno utile dal punto di vista dell’accessibilità.

Utilizzare noscript

Il modo migliore per sfruttare questo tag è inserire al suo interno un contenuto realmente alternativo.

Nel caso di una mappa interattiva con dei punti di interesse, all’interno del noscript sarebbe sufficiente elencare questi punti senza troppe complicazioni:

<script type="text/javascript">
// mappa interattiva
[...]
</script>
<noscript>
<ul>
   <li><a href="...">Punto di interesse 1</a></li>
   <li><a href="...">Punto di interesse 2</a></li>
   [...]
</ul>
</noscript>

evitando messaggi come:

<noscript>Il tuo browser non supporta JavaScript!</noscript>

Progressive enhancement

C’è però un’alternativa migliore al tag noscript, ed è l’utilizzo del progressive enhancement. Fornire un contenuto alternativo può essere una soluzione valida intervenendo su un sito esistente, ma se state realizzando un progetto da zero, è molto più utile pensare fin da subito a certe problematiche.

E’ necessario pensare ad HTML e JavaScript come due livelli distinti, da tenere ben separati. Il procedimento migliore è infatti inserire tutti i contenuti HTML, e solo successivamente usare JavaScript per aggiungere effetti grafici e animazioni.

In questo modo anche con JavaScript non disponibile i contenuti resteranno accessibili, e soprattutto non dovrete preoccuparvi di realizzare delle versioni alternative.

Sulla separazione di HTML e Javascript c’è un interessante articolo di A List Apart del 2006: Behavioral Separation, scritto da Jeremy Keith.

Ha ancora senso usare noscript?

Se utilizzate JavaScript in maniera non intrusiva potete benissimo dimenticarvi di noscript. Il tag però rimane ancora valido (ed è riconosciuto anche in HTML5) per garantire la retrocompatibilità.

Ci sono poi situazioni in cui l’utilizzo del noscript è insostituibile: basti pensare a tutti i casi in cui il codice JavaScript viene fornito da un sito esterno e non è modificabile.

E voi cosa ne pensate? Nel panorama italiano parlare di progressive enhancement è ancora un’utopia?

• diminuito il peso del codice, per una maggiore velocità di caricamento: da 25kb a 11kb
• implementata la navigazione da tastiera
• controllo sui link errati, che non fermano lo script ma visualizzano un’immagine di avviso
• riposizionamento automatico delle immagini durante lo scroll della pagina
• png fix per Explorer 6

Tutto questo si aggiunge all’ottimo lavoro che Diego aveva già fatto. Sono notevoli anche le opzioni di personalizzazione: tre skin sono già pronte (nera, bianca e trasparente), e c’è la possibilità tramite alcuni parametri di decidere la posizione delle frecce di scorrimento nelle gallerie di immagini (alla base dell’immagine o ai lati della pagina).

Se nel vostro prossimo progetto avete bisogno di uno script simile a Lightbox per mostrare anteprime di immagini, provate Pirobox. Alcuni dettagli come la navigazione da tastiera possono fare la differenza, e l’implementazione non richiede tag aggiuntivi nel codice: è sufficiente una classe html per abilitare lo script, in modo semplice e pulito.

Per vedere le demo e le caratteristiche di questo plugin in dettaglio vi rimando alla pagina ufficiale di Pirobox.

La soluzione che ho utilizzato nel mio progetto GdR Players si chiama GeoRSS: è un formato standard supportato anche da Google Maps, che consente con poche righe di codice di creare delle mappe complete.

Il formato GeoRSS

Per funzionare, la prima cosa necessaria è un file xml che segua questo standard. La struttura del documento deve essere simile a questa:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml">
<title>Titolo feed</title>
<entry>
<title>Primo elemento</title>
<link href="http://..."/>
<summary>descrizione</summary>
<georss:where>
<gml:Point>
<gml:pos>41.8 12.6</gml:pos>
</gml:Point>
</georss:where>
</entry>
<entry>
<title>Secondo elemento</title>
<link href="http://..."/>
<summary>descrizione</summary>
<georss:where>
<gml:Point>
<gml:pos>43.8 11.3</gml:pos>
</gml:Point>
</georss:where>
</entry>
</feed>

Le entry ovviamente possono essere molteplici, gli elementi come link e summary sono facoltativi ed appariranno solamente se inseriti. Per alleggerire il codice, potreste decidere anche di utilizzare il formato GeoRSS-Simple, dove il codice

<georss:where>
<gml:Point>
<gml:pos>41.8 12.6</gml:pos>
</gml:Point>
</georss:where>

diventerà

<georss:point>41.8 12.6</georss:point>

Non mi soffermerò sul metodo di creazione di questo file: su GdR Players viene generato dinamicamente, ma se avete una mappa con dei contenuti predefiniti niente vieta di scrivere l’xml manualmente.

Creazione della mappa

Se avete già familiarità con Google Maps, sono sufficienti un paio di righe di codice per includere tutti i marker presenti nell’xml:

var geoXml = new GGeoXml("http://www.url.com/feed.xml");
map.addOverlay(geoXml);

L’indirizzo specificato dovrà corrispondere alla posizione del file xml.

Il codice JavaScript completo, che utilizzo sul mio progetto con poche opzioni in più, è il seguente:

function load() {
if (GBrowserIsCompatible()) {
var geoXml = new GGeoXml("http://www.url.com/feed.xml");
var map = new GMap2(document.getElementById("map_canvas"));
if (geoXml.loadedCorrectly()) {
geoXml.gotoDefaultViewport(map);
}
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.addOverlay(geoXml);
}
}

Le funzioni gotoDefaultViewport e addControl specificate servono rispettivamente per:

• centrare la mappa e definire il livello di zoom automaticamente, in base ai marker presenti
• aggiungere i controlli per spostarsi e zoomare

L’ultima riga è quella fondamentale, che aggiunge alla mappa i marcatori.

Per quanto riguarda il codice html, è sufficiente avere nella pagina:

<div id="map_canvas"></div>

che farà da contenitore. Dovrete poi richiamare la funzione load al caricamento, inserendo:

<body onload="load();" onunload="GUnload()">

Ricordatevi infine che per utilizzare le API di Google Maps dovrete registrarvi, ottenere una API Key gratuita ed inserire il codice che vi verrà indicato nel vostro template.

La cosa fantastica di questo metodo è che segue uno standard, ed ha già delle azioni predefinite che verranno aggiunte alla mappa. Cliccando sui marcatori verranno visualizzate le informazioni correlate, il titolo di ogni entry e la sua descrizione, così come eventuali immagini o link.

Perchè utilizzare GeoRSS?

Consiglio l’uso di questo formato e della classe GGeoXml quando avete numerosi marker da mostrare su una mappa. La maggior parte dei tutorial in rete infatti utilizzano un principio diverso, inviando per ogni indirizzo una richiesta di geocoding a Google per ottenere le coordinate in tempo reale. Questo va bene per pochi marcatori, ma se ne avete più di una decina inizierete ad avere dei problemi: oltre questo numero anche io ho dovuto cambiare strada, rendendomi conto che la cosa non funzionava.

L’unica soluzione è ricavare a priori le coordinate (seguendo questa guida), inserirle in un file xml e visualizzarlo con la classe GGeoXml come vi ho mostrato. Seguendo questo metodo GdR Players attualmente mostra la posizione di 130 utenti, senza avere particolari problemi al caricamento della pagina.

Aggiornamento: dopo un anno di test posso affermare che questa tecnica funziona con più di 1000 segnalini contemporaneamente sulla mappa, la consiglio caldamente.

Tra le varie possibilità, jQuery e MooTools sono due tra i migliori framework da considerare. Per facilitarvi, consiglio la lettura di questa pagina, che vuole aiutare a trovare una risposta alla domanda: “quale scelgo?”.

Le caratteristiche dei due framework

jQuery – sito ufficiale

• dimensione della libreria (solo Core): 55.9kb
• centinaia di plugin disponibili su plugins.jquery.com, più innumerevoli altri disponibili in rete
  
• community diffusa e molto frequentata
• facilità di apprendimento

MooTools – sito ufficiale

• dimensione della libreria (solo Core): 64.3kb
• qualche decina di plugin ufficiali su mootools.net/more, più altri non ufficiali (meno rispetto a jQuery) disponibili in rete
  
• miglior mantenibilità del codice
• facilità di riutilizzo

Quale utilizzare?

La scelta può essere sintetizzata in una frase:

jQuery focuses on expressiveness, quick and easy coding, and the DOM while MooTools focuses on extension, inheritance, legibility, reuse, and maintainability.

E’ questa la giusta chiave di lettura per iniziare a lavorare con uno dei due framework. jQuery è probabilmente più facile da imparare ed è semplice da gestire, ma potrebbe presentare qualche problema di troppo per il riutilizzo del codice ed il suo mantenimento. MooTools ha meno difficoltà da questo punto di vista, ma è più complesso da imparare.

Alcuni esempi pratici

Per avere un’idea non solo teorica dei due framework, questi sono alcuni siti che utilizzano l’uno o l’altro. Sono presenti slider, carousel, accordion e menu con navigazione a tab: i risultati sono in ogni caso ottimi.

Web Designer Wall – jQuery

Marius Roosendaal – Mootools

Viget Labs – jQuery

Vimeo – Mootools

Komodo Media – jQuery

Macheist – Mootools

Per quanto mi riguarda su tomstardust.com utilizzo MooTools, ma per altri progetti ho sfruttato anche jQuery, soprattutto per i numerosi plugin a disposizione. Sono entrambe due ottime librerie: a questo punto la scelta dipende solo dalle vostre necessità.

• Le voci devono avere un’area estesa, comodamente selezionabile, per consentire una navigazione facile. Sono sconsigliate le etichette di testo troppo lunghe.
  
• E’ utile un ritardo di qualche frazione di secondo su apertura e chiusura del menu, per evitare attivazioni involontarie spostando il mouse
• Il menu deve potersi riposizionare a seconda delle dimensioni della finestra del browser, spostandosi in un’area visibile quando si trova vicino ai margini della stessa. Un classico errore è mostrato nell’immagine:
  
• All’apertura della tendina, l’utente deve vedere tutte le voci insieme, senza necessità di effettuare scroll della pagina
• I link di primo livello devono avere una destinazione, che sarà utilizzata anche se il menu non è accessibile (ad esempio JavaScript disabilitato)
• Un menu a tendina non è una mappa del sito, è inutile e dannoso elencare tutte le pagine
• Le voci selezionate dall’utente all’interno del menu dovrebbero rimanere evidenti
  
• Il menu dovrebbe essere perfettamente navigabile anche da tastiera
• I menu realizzati esclusivamente con i CSS spesso sono poco usabili: a volte è meglio evitarli. Senza JavaScript infatti non è possibile gestire alcuni aspetti come il ritardo sull’apertura e sulla chiusura.
• Con JavaScript disabilitato il sito deve essere comunque navigabile
• Le voci dei sottomenu è bene che siano accessibili agli screen reader senza nasconderle con display: none (ma con position: absolute)

Queste regole andrebbero rispettate in ogni occasione: per alcune potrebbe essere concessa qualche eccezione a seconda delle circostanze, ma alcuni requisiti come l’usabilità sono fondamentali. Un menu a tendina deve essere facile da utilizzare, perchè è il mezzo principale per far navigare gli utenti nel vostro sito. In certi casi conviene mantenere un menu classico, se l’alternativa deve essere poco usabile.

Esempi di menu a tendina

Esistono diverse risorse disponibili per realizzare un menu a tendina senza troppi problemi. Non tutte però seguono i principi elencati: ve ne segnalo un paio. Potete usarle come un ottimo punto di partenza per i vostri siti:

• Free CSS DropDown menu Framework: una soluzione modulare, con diversi temi grafici già pronti
• MenuMatic: un plugin per la libreria Mootools che trasforma una lista di link HTML in un menu a tendina

Se conoscete altre risorse interessanti segnalatele pure nei commenti, le aggiungerò a questa lista.

Ha deciso di avventurarsi in questo contesto un Web Designer italiano, Diego Valobra, che sfruttando un framework diffuso come jQuery ha realizzato un plugin pronto all’uso.

La sua creazione si chiama Pirobox: sul sito potete trovare alcuni semplici esempi, in due varianti di colore (bianco e nero). Mantenendo tutte le caratteristiche dei suoi predecessori, a mio parere è interessante la possibilità di avere i controlli per scorrere avanti e indietro posizionati esternamente rispetto alle immagini, un dettaglio che può fare la differenza.

Se volete saperne di più sul suo creatore, ho chiesto a Diego i motivi che l’hanno spinto a realizzare un clone di Lightbox, questa è stata la sua risposta:

Qualche mese fa ho iniziato ad interessarmi al framework jQuery, non tanto per sfruttare il “già fatto”,visto che di plugin come sai è piena la rete, quanto per creare effetti su misura ai siti su cui lavoro.

Credo fermamente che la creatività di un web designer non debba limitarsi al creare un layout in psd, tagliarlo, montarlo e farne il debug, ma debba spaziare attraverso il web developing il più possibile. Con questo intendo dire che i codici usati per rendere visibile ciò che si è creato in Photoshop o in Illustrator, devono stare al web designer come la grammatica sta ad uno scrittore. Mi è sembrato quindi inevitabile fare una full immersion nel mondo di ajax, e Pirobox ne è il frutto.

Voglio aggiungere che non sono un programmatore, ma essenzialmente un web designer, per questo nel creare Pirobox ho dovuto supplire alla mancanza di nozioni javascript con la mia creatività. Faccio un’esempio.
Per creare la navigazione nella gallery, quindi i tasti next e previous, tutti… e dico tutti quelli che prima di me hanno creato una qualsiasi tipo di image gallery hanno usato un array con conseguente ciclo for, incremento o decremento dei numeri relativi alle immagini. Io ho semplicemete aggirato l’ostacolo in maniera creativa, senza voler copiare nessuno (sarebbe stato troppo facile), ho  trovato un escamotage che consiste nell’aggiungere nell’html, in fase iniziale di script, due elementi lista:

<li class="begin"></li>
<li class="end"></li>

uno all’inizio della lista che uso per il set di immagini e l’altro alla fine. Questo permette il controllo sulla lista di immagini evitando di usare un array.

Per l’incremento e il decremento ho usato un altro trucco che consiste nell’aggiungere agli elementi lista della gallery adiacenti all’immagine selezionata due classi start e back, che servono per la navigazione. Ovviamente ci sono anche dei controlli sul primo e sull’ultimo elemento della lista grazie ai due <li></li> aggiunti in precedenza, così una volta arrivati all’ultima immagine il tasto next sparisce, stessa cosa per il tasto prev.

L’unico inconveniente, se così possiamo dire visto che il risultato è semanticamente giusto, è che il set di immagini con Pirobox funziona solo se viene usata una lista.

Creare Pirobox è stato stimolante, istruttivo e cosa più importante molto divertente.

Potete vedere il portfolio di Diego su Pirolab.it, e tra i suoi vari lavori troverete anche DiegoValobra.com, un sito che avevo già notato in passato viste le numerose segnalazioni su diverse Web Gallery.

In questo articolo troverete una selezione di alcuni effetti che consentono di creare gallerie di immagini accessibili: non intrusivi, degradano nel modo giusto se JavaScript è disabilitato, e si appoggiano a framework già collaudati come jQuery e Mootools. Potrebbero essere migliorati ulteriormente, ma sono un’ottima base di partenza.

SmoothGallery

Soluzione basata sulla libreria Mootools, consente di creare slideshow di immagini mettendo a disposizione vari parametri come lo scorrimento automatico ed il tempo riservato ad ogni fotografia. E’ possibile anche avere più set di immagini nella stessa galleria: funzione comoda per risparmiare spazio nella pagina.

In assenza di JavaScript, le immagini appaiono comunque precedute da titolo e descrizione. Il difetto riguarda i controlli, non è infatti possibile scorrere le foto da tastiera.

Slideshow 2

Un buon set di effetti a disposizione anche per questo script basato sul framework Mootools, che può essere a sua volta esteso con altre funzionalità, come l’anteprima delle immagini con Lightbox.

Notevole la realizzazione degli esempi: disabilitando JavaScript le funzionalità restano le stesse, spariranno semplicemente le transizioni. Ottimi anche i controlli, non c’è alcun problema a spostarsi tra le immagini utilizzando anche la tastiera.

Galleria

Probabilmente il migliore tra quelli presentati, questo script si basa su jQuery e pesa solamente 4kb. Non è intrusivo, degrada senza problemi in assenza di JavaScript o con i CSS disabilitati e può essere personalizzato facilmente anche nell’aspetto. Le immagini sono organizzate in una lista nel codice HTML: una soluzione ottimale.

Notevole anche l’efficienza dello slideshow, perchè le foto vengono caricate e mostrate solo quando disponibili, evitando attese nel momento dell’interazione.

Se conoscete altre soluzioni accessibili per la creazione di gallerie di immagini segnalatele nei commenti, è sempre utile conoscere le migliori risorse in questo ambito. Potete trovare altri script nel mio precedente post dedicato a Lightbox ed ai suoi cloni: se comunque volete uno slideshow accessibile il mio consiglio è di partire dagli script appena illustrati.

Con una semplice combinazione di tasti ( CTRL + spazio su Pc e ALT + spazio su Mac) è possibile aprire un riquadro all’interno della finestra attiva. Da questo riquadro scrivendo poche lettere si è in grado di fare praticamente qualsiasi cosa tramite un’interfaccia a riga di comando: cercare un termine su Google o Wikipedia, tradurre il contenuto di una pagina, cercare delle immagini su Flickr o un indirizzo su Googlemaps, non ci sono limiti alle operazioni possibili.

I comandi più immediati sono:

• g: ricerca su Google
• w: ricerca su Wikipedia
• f: ricerca su Flickr
• map: ricerca su Googlemaps di un indirizzo, se selezionate del testo Ubiquity cercherà direttamente quanto evidenziato
• translate: traduzione del testo evidenziato nella pagina da una qualsiasi lingua all’inglese, utilissima per lingue sconosciute come il cinese
• imdb: ricerca sull’Internet Movie Database
• twitter: aggiorna il proprio stato di Twitter

Fantastica è la possibilità di estendere i commenti presenti, importandoli da altri siti o scrivendoli autonomamente. Per maggiori informazioni vi rimando a quelli elencati sul sito ufficiale e su questo post dei Googlisti.

Creare comandi personalizzati

E’ possibile anche creare dei comandi personalizzati per Ubiquity, magari abbinando una parola chiave alla ricerca sul vostro sito web.

Seguendo questo tutorial potete realizzare in poche righe un comando che permette di effettuare la ricerca di qualsiasi termine. Una volta realizzato lo script, salvatelo in un file .js, caricatelo sul vostro server e collegatelo ad una pagina con il seguente codice da inserire tra i tag <head> e </head>:

<link rel="commands" href="http://percorso-del-file-js" name="Titolo" />

Potete provare il comando che ho realizzato per tomstardust.com andando su questa pagina dopo aver installato Ubiquity. Una volta autorizzato lo script, potrete utilizzare il comando tomstardust per cercare qualsiasi termine su questo sito.

Se a questo punto siete incuriositi da Ubiquity e non l’avete ancora installato, potete farlo dalla pagina ufficiale dei Mozilla Labs, dove trovate anche un video con una dimostrazione pratica.