Blog - Pagina 16 di 41 - TomStardust.com

Italia.it è tornato

Un’analisi approfondita della nuova versione del portale del turismo italiano.

Ho trattato più volte su questo sito l’argomento italia.it, il portale del turismo italiano che da anni cerca di decollare senza riuscirci. Non potevo così trattenermi dall’analizzare la nuova versione, presentata al grande pubblico il 17 Luglio scorso.

Premetto che questo articolo non vuole essere una critica fine a se stessa, ma un modo per analizzare lo stato attuale del portale e suggerire possibili miglioramenti. Ho intenzione di segnalarlo anche tramite la pagina “Collabora” di italia.it, soprattutto se vorrete aggiungere i vostri commenti.

Un sito accessibile?

Le pubbliche amministrazioni come noto sono sottoposte alla legge Stanca, che definisce i requisiti obbligatori per l’accessibilità dei siti realizzati. Nel footer di italia.it viene linkata una pagina con una dichiarazione di accessibilità che afferma:

La home page e le altre pagine del sito promozionale turistico sono state realizzate cercando di rispettare tutti i 22 requisiti tecnici contenuti nel Decreto del Ministro per l’Innovazione e le Tecnologie dell’8 luglio 2005, approvato conformemente a quanto previsto nella Legge n. 4 del 9 gennaio 2004 recante “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici” (Legge Stanca) [..]

Quel “cercando di rispettare” non promette niente di buono, ma una verifica è comunque d’obbligo. Tralasciando tour virtuali e mappe, che vengono a priori segnalati come non accessibili, mi sono limitato ad esaminare l’homepage del sito.

Il problema principale è l’organizzazione dei titoli: c’è un tag H1, ma è usato per la frase “Benvenuti in Italia” e non per il titolo del sito. Manca poi totalmente il tag H2, e si salta all’H3 delle sottosezioni.

Confonde non poco la presenza di link nel menu principale che si aprono in nuove tab del browser. Non è stato usato l’attributo deprecato target=”_blank”, ma una soluzione JavaScript: stratagemma valido dal punto di vista formale, ma poco logico se si considera che nello stesso menu ci sono pagine che si aprono normalmente ed altre che portano su siti esterni.

Disabilitando JavaScript, vengono visualizzati comunque nella pagina elementi come le frecce di scorrimento dei vari carousel. Problema comune a molti siti: JavaScript è stato utilizzato in maniera intrusiva, senza usare il progressive enhancement.

Con le immagini disabilitate il sito mostra tutte le sue debolezze: la home risulta praticamente vuota.

Validazione del codice

Per quanto riguarda la validità dell’HTML ad una prima occhiata i risultati potrebbero sembrare buoni: almeno in homepage manca solo l’attributo alt sull’immagine di testa. Il problema è che la validazione non dovrebbe fermarsi solo alla home, che molto spesso (e soprattutto qui) è una semplice vetrina. Molti contenuti sono nelle pagine interne e sul fantomatico dominio visual-italy.it: i problemi sono tutti lì.

Sul sito “parallelo”, raggiungibile dal menu principale, non mancano infatti le sorprese:

tag non chiusi
doctype che passa misteriosamente da XHTML 1.0 Strict a HTML 4.01 a seconda della pagina visitata
ID ripetuti
attributi inesistenti per la doctype dichiarata

Risultato quindi apparentemente buono per italia.it, ma è una validità solo di facciata, che crolla non appena si naviga qualche pagina in più.

SEO – Search Engine Optimization

Alcuni degli aspetti che ho analizzato influiscono pesantemente anche sull’ottimizzazione dei motori di ricerca, a cominciare dall’uso dei titoli.

A questo si aggiungono:

La totale assenza di title su misura per le varie pagine del sito
La mancanza di meta keywords e description
La scarsità di contenuti testuali, spesso inutili quando presenti

Un sito come questo non ha problemi ad essere indicizzato per via del clamore che solleva, ma le pagine interne se resteranno così rimarranno in un inutile limbo, proprio perchè carenti di contenuti. Se poi anche le regioni vengono scambiate tra loro, il quadro diventa ridicolo.

La lingua e le traduzioni

Una nota finale è d’obbligo sulla lingua. Siamo sicuri che il target principale di un sito del genere siano gli italiani? Come mai molti siti esteri equivalenti presentano di default la versione inglese? Lo stesso dubbio viene sollevato anche da Massimo Mantellini nel suo Contrappunti, su Punto Informatico.

A questo si aggiungono delle strane scelte, come quella di utilizzare per tutte le lingue un titolo di sezione come “Italia Much More”. Perchè?

Conclusioni

Per considerando lo stato di beta dichiarato dal ministro Brambilla per l’attuale versione di italia.it, ci sono poche speranze che le cose possano cambiare con il rilascio definitivo previsto in autunno. Il problema è l’idea alla base: un sito del genere non serve a nessuno, nè ai turisti stranieri, nè tantomeno agli italiani, che non possono trovare alcuna utilità in un portale vetrina.

Un turista deve poter conoscere le indicazioni dei visitatori che sono stati in un posto prima di lui, oltre a vedere i prezzi degli alberghi e programmare ogni spostamento. Sapere che i principali aereoporti italiani sono Malpensa e Fiumicino e che l’offerta di voli “è ampia e copre un vasto numero di destinazioni” non serve a nessuno.

Sono tutti soldi pubblici spesi inutilmente per un sito che non offre alcun motivo per ritornare dopo la prima visita. I 45 milioni di euro stanziati per il primo progetto sembrano ormai un lontano ricordo (ma quanti ne furono comunque spesi?), ma l’investimento su questo secondo tentativo sarà inutile se non cambierà l’idea alla base. E’ incomprensibile una spesa di 10 milioni, anche considerando gli sviluppi futuri e le attività promozionali in programma.

Il mio suggerimento? Coinvolgere sviluppatori realmente competenti e web designer interessati all’usabilità dei propri lavori, ricordando di garantire a tutti l’accesso alle risorse della rete. La collaborazione è la chiave, non solo dietro le quinte: coinvolgere gli utenti è il modo migliore per ottenere dei risultati, rendendoli parte attiva del progetto.

Classi HTML: buone pratiche ed errori comuni

Google pubblica l’analisi di un miliardo di pagine web: le classi HTML più usate mostrano dati interessanti ed errori da evitare.

Esistono numerosi studi sulle pratiche più diffuse nel web design, ma spesso queste analisi vengono effettuate su un campione ristretto, non attendibile. Google ha pubblicato uno studio che fa luce su alcuni aspetti: pur non essendo troppo approfondito, può contare su un campione di più di un miliardo di pagine web. Abbastanza per fermarsi ad osservare i dati provando a trarne qualche conclusione.

Tra gli argomenti dello studio voglio considerare soprattutto le classi HTML, per capire anche quante speranze esistano di avvicinarsi alla nascita di un web semantico.

I risultati dello studio di Google sulle classi HTML

Prima di tutto, è necessario analizzare un aspetto: la maggior parte delle pagine web non utilizza alcuna classe. E’ un dato che potrebbe sorprendere, ma ricordate che stiamo parlando di una rete dove regnano ancora incontrastate le pagine con codice non valido, generate da software inefficaci, dove le tabelle vengono usate ancora per il layout.

La classifica delle classi più utilizzate è la seguente:

footer
menu
title
small
text
content
header
nav
copyright
button
main
search
msonormal
date
smalltext
body
style1
top
white
link

Alcune sono comuni, come header e footer, l’utilizzo di altre invece è totalmente errato.

Gli errori più comuni

Tra le classi di questa top 20, sono senza dubbio da evitare tutte quelle con un nome senza significato come msonormal o style1. Tra l’altro MsoNormal è una classe generata da Office esportando un documento come pagina web. Il fatto che sia presente tra le più utilizzate è indicativo della qualità media della rete e di come vengano realizzati molti siti: che sia un problema irrisolvibile?

Sono poi usate in maniera sbagliata le classi con un nome collegato all’aspetto presentazionale, come white.

Una guida da seguire

Se avete dubbi su come scrivere il codice HTML, utilizzando ID e classi nel modo corretto, trovate alcune indicazioni utili in un articolo che ho pubblicato qualche mese fa: “Guida all’utilizzo di ID e classi nel codice HTML”. L’argomento è sempre valido, per questo ci tengo a segnalarlo.

Il codice dovrebbe essere scritto sempre in maniera comprensibile, trovando il giusto equilibrio tra sintesi e leggibilità, senza dimenticare di usare nomi legati alla funzione di un elemento e non al suo aspetto.

Nel caso aveste delle aggiunte da segnalare o qualche suggerimento da farmi, lasciateli come sempre nei commenti e provvederò ad integrare la guida: il vostro contributo è sempre prezioso.

Google Chrome OS: nuovi scenari per l’usabilità dei sistemi operativi

Google si prepara a lanciare il suo sistema operativo web based: cosa aspettarsi?

L’annuncio di Google ha fatto il giro della rete: nel 2010 vedremo la nascita di un nuovo sistema operativo, che prenderà il nome da Chrome.

C’era già il sospetto che il browser di Google potesse essere solo un primo passo per arrivare a qualcosa di più importante, ed infatti le previsioni si sono rivelate fondate. Per i dettagli vi rimando all’annuncio sul blog ufficiale, che ha un passaggio interessante:

People want to get to their email instantly, without wasting time waiting for their computers to boot and browsers to start up. They want their computers to always run as fast as when they first bought them. They want their data to be accessible to them wherever they are and not have to worry about losing their computer or forgetting to back up files. Even more importantly, they don’t want to spend hours configuring their computers to work with every new piece of hardware, or have to worry about constant software updates.

Sarà proprio l’usabilità del nuovo Google OS a decretarne l’eventuale successo, la stessa citata in questo estratto: gli utenti vogliono computer veloci, che non impieghino troppo tempo ad avviarsi, con la possibilità di accedere ai propri dati ovunque, senza bisogno di eseguire dei backup.

Un sistema operativo usabile

Queste caratteristiche saranno possibili solo se Chrome OS sarà un sistema operativo ridotto al minimo essenziale, con un cuore web based. Inevitabilmente tutto girerà intorno alle applicazioni web di Google: Gmail, Calendar, Docs, Reader, YouTube, Maps… l’elenco potrebbe continuare a lungo.

Se da un lato questa scelta porta dei vantaggi, in un paese come l’Italia dove la connessione non arriva ovunque ed il wi-fi è spesso una chimera per problemi burocratici, potrebbe esserci qualche problema di troppo. Non sono ostacoli insormontabili, ma è ovvio che lo scenario americano è ben diverso, e Google mira prima di tutto a quel mondo. La società di Mountain View ha già sviluppato un sistema operativo come Android, ma questo pur rimanendo open-source sarà un OS rivolto prima di tutto ai netbook, che solo successivamente potrebbe vedere una propria applicazione sui sistemi desktop. Per come è stato presentato lo vedo comunque un passo più lontano, perchè le esigenze dell’utente casalingo sono diverse da quelle di chi è in movimento.

Parlando anche di backup, sarebbe bello se con la nascita di Chrome Os venisse lanciato un servizio di storage online made in Google, magari efficiente come Dropbox ma con più spazio a disposizione. Non so però quanto un’ipotesi del genere possa essere verosimile: se Google avesse voluto aprire un servizio del genere l’avrebbe fatto già da tempo, considerando che Gmail mette già a disposizione diversi Gb.

A questo punto non resta che attendere entro fine anno il rilascio del codice del nuovo sistema operativo per saperne di più. Per noi consumatori l’entrata di un nuovo concorrente sul mercato può significare solo grandi vantaggi: se Chrome OS avrà successo, sarà dovuto al mantenimento delle promesse fatte da Google ed al supporto dei produttori di netbook.

Il W3C abbandona XHTML, il futuro è HTML 5

La presa di posizione del W3C: stop allo sviluppo di XHTML 2 per portare avanti solo HTML 5.

Il W3C ha chiarito la sua posizione sul futuro della specifica XHTML: con una news pubblicata il 3 Luglio ha chiuso lo sviluppo di XHTML 2, per dedicare tutte le risorse al futuro HTML 5.

Dalle notizie della settimana appena conclusa infatti è possibile leggere:

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML.

Una decisione sicuramente importante per il futuro di chi sviluppa sul web, ma non così sorprendente come potrebbe sembrare. Ammetto di avere sperato in XHTML 2, ma i segnali colti fino ad ora non sono mai stati rassicuranti. Quest’ultima notizia è solo la conferma della strada fortemente voluta e consigliata (in modo più o meno forzato) da Google e dai vari sviluppatori di browser, che da tempo stanno spingendo per la specifica HTML 5.

Alla luce di quanto accaduto la decisione di Dave Shea, sviluppatore americano, che ha deciso di abbandonare XHTML da qualche tempo, non appare così sbagliata. Ne avevo parlato nel post “Abbandonare XHTML?”, ma in ogni caso non c’è alcun motivo di avere fretta di cambiare. Per quanto mi riguarda resto fermo sulla mia posizione: finchè HTML 5 non sarà pienamente supportato, XHTML 1.0 resterà la mia scelta principale; è semplicemente arrivato il momento di approfondire lo studio della nuova specifica per chi non l’avesse ancora presa in considerazione, visto che tra qualche tempo sarà largamente diffusa.

Come punto di partenza vi segnalo le Faq del W3C sul futuro di XHTML, ed il post “HTML 5: approfondimenti ed evoluzioni future”, dove troverete diversi link utili.

A proposito di tempi: quanto ci vorrà per vedere HTML 5 supportato da tutti i principali browser? Sicuramente qualche anno, ma la data potrebbe non essere così lontana. In alcuni casi certe funzionalità sono già ben supportate, e questo indica che gli stessi produttori hanno interesse a seguire la specifica. Non sarà comunque un cambiamento improvviso: c’è tutto il tempo per documentarsi ed approfondire.

La funzione body_class() di WordPress 2.8

Guida alla personalizzazione delle singole pagine di un blog Wordpress, con una semplice funzione php.

La versione 2.8 di WordPress introduce una novità molto utile per chi sviluppa dei temi. E’ stata infatti creata una nuova funzione php, chiamata body_class().

Utilizzandola nel template è possibile avere delle classi differenti sul tag HTML body, a seconda della pagina visualizzata. Questo consente di personalizzarne l’aspetto esclusivamente tramite CSS, senza bisogno di creare template su misura.

Per utilizzarla è sufficiente aggiungerla nel tag body, che di solito è nel template header.php, in questo modo:

<body <?php body_class(); ?>>

Il risultato sulla homepage del blog sarà:

<body class="home blog">

mentre su un singolo articolo (ad esempio con ID 23):

<body class="single postid-23">

E’ possibile anche aggiungere una o più classi personalizzate a piacere, che appariranno insieme alle altre:

<body <?php body_class('nome-classe'); ?>>

Una funzione php analoga, relativa però ai singoli post, è chiamata post_class(): ne ho parlato in passato, trovate la relativa guida a questo indirizzo.

Le potenzialità di queste funzioni sono notevoli, ma credo sia bene utilizzarle solo se veramente necessario. Soprattutto nel caso di body_class(), il rischio è quello di trovarsi il codice inutilmente appesantito. L’elenco completo delle classi stampate dalla nuova funzione è in questo post di WPEngineer.

Check My Colours: come analizzare il contrasto dei colori di un sito

E’ nata una nuova applicazione per analizzare i colori di una pagina web. Ecco qualche domanda a chi l’ha sviluppata.

La scelta dei colori di una pagina web è uno degli elementi da considerare per avere un sito accessibile. Non è sufficiente tenere conto di alcune problematiche come il daltonismo o altri disturbi della percezione dei colori: esistono infatti numerose circostanze per le quali alcune scelte sbagliate potrebbero rendere un sito inaccessibile.

Basti pensare alla visualizzazione di una pagina senza CSS o con le immagini disabilitate: non avere dichiarato alcuni colori potrebbe rendere illeggibili alcuni testi.

In queste situazioni può tornare utile l’utilizzo di strumenti automatici: Check My Colours è un tool ancora in beta, realizzato dall’italiano Giovanni Scala, che promette molto bene.

Alcune domande all’autore

Per approfondire questa segnalazione ho voluto fare un paio di domande al suo creatore, anche per comprendere le ragioni della nascita di Check My Colours.

Come mai hai voluto creare un’applicazione di questo tipo pur esistendo già altre alternative simili?

Sin da quando ho iniziato a sviluppare siti ho sempre cercato di rendere i miei lavori pienamente accessibili per chiunque, sia dal punto di vista tecnico che umano. Quindi ho pensato che un’applicazione simile sarebbe stata d’aiuto.

Sì, è vero, esistono diversi tool simili, ma ad ognuno di questi manca “qualcosa”:

Quasi sempre permettono di verificare solamente il CSS esterno. CheckMyColours verifica i colori di ogni singolo elemento del DOM, siano essi definiti in un foglio di stile esterno o all’interno della pagina HTML. Questo approccio oltre ad essere più completo, permette di avere un rapido quadro della situazione della propria pagina (una sola scelta errata dei colori nel css può rendere illegibile centinaia di links… Gli altri “validatori” segnalerebbero comunque un solo errore…)

Non tutti gli strumenti attualmente online utilizzano gli algoritmi ufficialmente suggeriti dal consorzio W3C.

Alcuni tools richiedono l’installazione locale, e quindi sono utilizzabili solamente su determinati sistemi operativi

Gli obiettivi principali di questa applicazione sin dall’inizio sono stati:

avere come target principale i web designers. Fare una sola cosa, farla bene.

facilitare le operazioni di controllo di una pagina già online

ottenere risultati semplici da consultare

fornire mezzi per la scelta dei colori in fase di sviluppo (il color picker)

renderla utilizzabile su qualsiasi sistema operativo

renderla utilizzabile su qualsiasi browser

Prevedi degli aggiornamenti per il futuro? Stai lavorando già a delle modifiche?

Ovviamente questo è solo l’inizio. L’attuale versione online è ancora in fase beta. Sto ricevendo diverse mail di segnalazioni, proposte, consigli, e certamente ne terrò conto. Una bozza di roadmap creata al volo potrebbe essere:

correggere gli eventuali problemi della versione beta

stilare delle FAQ

migliorare il color picker

creare un’area blog per aggiornamenti sull’applicazione e

discussioni legate all’accessibilità.

ottimizzare l’utilizzo su iPhone e altri dispositivi mobili

permettere il salvataggio su pdf del report

Potete provare subito Check My Colours, tenendo presente che è in costante sviluppo. Se avete dei suggerimenti o delle proposte da fare, non esitate a contattare l’autore dal sito dell’applicazione.

Usabilità e User Experience

L’usabilità è solo uno dei fattori che contribuiscono ad una buona esperienza di navigazione.

Spesso si sente parlare di usabilità dei siti internet, ma le idee sulla definizione precisa si confondono e si sovrappongono, arrivando a spiegazioni anche molto diverse. In linea generale l’usabilità può essere definita come la facilità di interazione tra una persona e lo strumento che utilizza.

Riferendosi ad internet, il rapporto da considerare è quello tra un utente ed il sito che sta navigando.

Cos’è la User Experience?

Qualcuno potrebbe pensare che l’esperienza dell’utente (in inglese user experience o UX) sia la stessa cosa, ma in realtà non è così. L’usabilità è solo uno dei fattori che servono a raggiungere una buona user experience: sono poi da considerare accessibilità, architettura delle informazioni, user interface design ed interaction design.

L’esperienza dell’utente è il risultato della combinazione di tutti questi aspetti: riguarda emozioni, sensazioni e comportamenti, non solo l’efficienza con cui vengono raggiunti determinati obiettivi.

Buona Usabilità non significa sempre buona User Experience

Un sito usabile non assicura quindi sempre un riscontro positivo da parte degli utenti. Sicuramente aiuta, ma da sola l’usabilità non è sufficiente.

Pensate ad un blog con le categorie bene organizzate, titolo della pagina corrente ben in evidenza, menu e testi leggibili ed anche una ricerca funzionale. Sembrerebbe tutto perfetto, ma se i contenuti dei post fossero incompleti o avessero evidenti errori grammaticali?

I visitatori ricorderebbero molto più facilmente quest’ultimo aspetto, giudicando negativamente il sito senza altre possibilità di appello.

L’esperienza utente va oltre l’usabilità, perchè tiene anche conto di altri fattori:

Desiderabilità

Gli utenti devono avere un motivo per voler navigare il vostro sito. E’ bene che sia funzionale ed efficiente, ma deve essere in grado di offrire qualcosa di più per piacere. La chiave è invogliare i visitatori a tornare.

Credibilità

I testi sono attendibili? Questo aspetto vale per un blog come per un sito aziendale: i messaggi devono essere credibili, e questo ovviamente implica anche la correttezza grammaticale.

Personalità

La personalità di un sito è importante, soprattutto per quelli aziendali: il modo di rivolgersi al visitatore deve essere studiato senza improvvisare. In questo caso sono i dettagli che contano, dai messaggi di avviso alle etichette dei menu, passando per le indicazioni delle azioni da compiere.

Coerenza

Il messaggio trasmesso dal sito deve essere coerente in tutte le pagine. Il modo di rivolgersi al visitatore non può cambiare tra l’homepage ed una procedura di acquisto.

I vantaggi di una User Experience positiva

Ottenere un feedback positivo dai visitatori è fondamentale, e per farlo è sempre bene partire da un sito usabile ed accessibile. L’importante è ricordare come questo da solo non basti per raggiungere una buona user experience. L’utente soddisfatto, a cui piace interagire con il vostro sito, tornerà più spesso e vi porterà altre visite, cosa che non succederà con tutti coloro che avranno un’esperienza negativa.

Immagine: Paul Veugen

Nota: questo articolo è stato ispirato da Usability to the UX, su redant.co.uk.

Interagire con il Database di WordPress in php

Come sfruttare la classe $wpdb per leggere il Database di Wordpress.

Se avete mai realizzato un tema per WordPress, prima o poi avrete avuto la necessità di ricavare delle informazioni dal database non accessibili tramite i template tag di questo CMS. Non ci sono problemi ad ottenere il titolo del blog, di un post, l’elenco delle pagine o delle categorie esistenti, ma quando le necessità si fanno più specifiche diventa necessario scrivere qualche riga in php.

La realtà è molto più semplice di quello che può sembrare: esiste infatti una classe chiamata $wpdb che consente di andare a recuperare qualsiasi informazione dal database. Può essere sfruttata su qualsiasi tabella, anche quelle che non sono state create da WordPress, ma ad esempio da un plugin esterno.

Esempi pratici di utilizzo

Volete visualizzare sulla homepage del blog il numero di utenti registrati? Vi basta aggiungere questa funzione nel file functions.php:

function userCount() { global $wpdb; $user_count = $wpdb->get_var("SELECT COUNT(*) FROM $wpdb->users;"); echo $user_count; }

Dal template index.php basterà poi richiamare la funzione per visualizzare il risultato:

<p>Utenti registrati: <?php userCount(); ?></p>

E’ possibile eseguire anche query più complesse, ad esempio per ricavare un array di elementi da stampare, come l’elenco delle bozze ancora da pubblicare:

function showDrafts() { global $wpdb; $fivesdrafts = $wpdb->get_results("SELECT ID, post_title FROM $wpdb->posts WHERE post_status = 'draft' "); foreach ($fivesdrafts as $fivesdraft) { echo '<li>' . $fivesdraft->post_title . '</li>'; } }

Da visualizzare poi così:

<h3>Bozze in attesa di pubblicazione:</h3> <ul> <?php showDrafts(); ?> </ul>

Questo strumento è interessante, perchè con un minimo di conoscenza del database e delle query possibili, qualsiasi informazione può essere estratta senza difficoltà. C’è un’ottima documentazione a disposizione sul Codex ufficiale di WordPress, di cui trovate anche la traduzione in italiano su wordpress-it.it.

Tra le funzioni a disposizione della classe, potrebbe servirvi $wpdb->show_errors, che visualizza gli errori MYSQL. L’ho trovata molto utile in fase di debug, e se non conoscete bene la sintassi da utilizzare vi sarà di grande aiuto.

Il mio consiglio comunque è di fare qualche test in locale per capire le potenzialità dello strumento: non è così difficile da imparare, anche se non siete dei programmatori. Dopo aver osservato la struttura del database (ad esempio con phpMyAdmin) per conoscere i nomi delle tabelle e dei campi, potrete fare qualsiasi cosa.

Librerie JavaScript: jQuery o MooTools?

Una guida alla scelta della migliore libreria JavaScript per il vostro sito.

Il primo problema da considerare per chi vuole sfruttare le potenzialità di JavaScript è la scelta del framework a cui appoggiarsi. Le soluzioni a disposizione sono tante: spesso può anche non servire sfruttare un’intera libreria, ma per progetti complessi a volte è la scelta più conveniente.

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à.

WordCamp 2009: il resoconto

La cronaca del secondo BarCamp italiano dedicato a Wordpress.

Sono appena rientrato dal secondo WordCamp italiano, che anche quest’anno si è rivelato un bell’evento. Un ospite importante, alcuni bei talk, ma soprattutto in questi incontri il vero valore aggiunto è rappresentato dalle conoscenze che si fanno: essere a contatto diretto con altri blogger e lavoratori del settore è un ottimo modo per approfondire i rapporti, e socializzare molto più facilmente che da dietro ad uno schermo.

Parlando di WordPress, la presenza più importante di questo BarCamp era senza dubbio quella di Andy Peatling, l’autore di BuddyPress. Si tratta di una vera e propria suite di plugin e temi che permettono di trasformare una qualsiasi installazione di WordPress MU in una community, con tutte le sue funzioni più importanti. Profili estesi degli utenti, messaggi diretti, amicizie, gruppi, forum: tutto ciò può essere implementato senza troppe difficoltà, con molta più libertà di gestione rispetto ad altri sistemi (ad esempio appoggiandosi a piattaforme esterne come Ning).

Vista la natura del progetto, è logico che sia una suite dedicata a WordPress MU piuttosto che ad una singola installazione di WordPress, ma lo stesso Wolly (che ringrazio ancora per aver organizzato il WordCamp) mi ha confermato che con qualche hack non è impossibile adattare BuddyPress anche ad un ambito più ristretto.

Per il resto, devo riconoscere che tra i talk in programma nella giornata di Sabato (il Venerdì non ero presente), avrei apprezzato qualche approfondimento tecnico in più su WordPress. Da questo punto di vista mi era piaciuto di più il WordCamp 2008: erano numerose le presentazioni sull’ottimizzazione della piattaforma e su come sfruttarla al meglio. Si è parlato di OpenOffice e della sua integrazione con WordPress, dell’esperienza della Fiat su internet, del manifesto di Marco Massarotto per le aziende che vogliono affacciarsi in rete, ma ho sentito comunque la mancanza di qualcosa.

Trovate alcune foto dell’evento sul mio account Flickr, nel set dedicato. Mi ha fatto molto piacere rivedere Tambu e conoscere Francesco Gavello, che ha confermato tutte le buone impressioni che avevo avuto su di lui e sono sicuro continuerà a far parlare di sè con il suo blog. Interessanti anche i discorsi fatti con Julius su BlogMagazine, che partito da zero sta avendo sempre più riconoscimenti: io stesso ero scettico sulle possibilità dell’iniziativa, ma vi consiglio di tenere d’occhio quello che succederà nei prossimi mesi, potreste rimanere sorpresi. Un applauso anche a Luca Sartoni per la bella presentazione (“WFT? Non funziona!”).

A questo punto il prossimo anno non avete scuse: se questo resoconto vi ha incuriosito, vi sarebbe sicuramente piaciuto essere presenti. Per il futuro sarà interessante vedere se si riusciranno ad organizzare WordCamp locali nelle varie città italiane, come auspicato anche dagli organizzatori. Sarebbe una bella occasione per coinvolgere tutte coloro che non hanno voglia di spostarsi, ma che possono dare il loro contributo alla causa di WordPress.