Un CMS, o Content Management System, è un software in grado di gestire la stesura e l’organizzazione dei contenuti di un sito web. Ad esempio WordPress è un CMS focalizzato sui blog, MediaWiki è un CMS focalizzato sui wiki, Drupal è un CMS focalizzato sui portali.

Le fondamenta di un CMS sono spesso molto simili, in quanto il tipo di contenuti da gestire sono sempre gli stessi: testo, immagini, video, audio, files vari. Anche la struttura logica non differisce sensibilmente.
La focalizzazione su uno scopo rispetto ad un altro significa che per quell’utilizzo lo strumento è molto più indicato e richiede molte meno modifiche per poter essere utilizzato in modo ottimale. Ad esempio un blog richiede in primo luogo di una ottima gestione di liste di post a cronologia inversa (dal più nuovo al più vecchio), un wiki sarà fondato sulle pagine modificabili da chiunque e sulla loro interrelazione, un portale avrà una maggiore necessità di struttura con sezioni, sottosezioni e strumenti di varia natura.

Da qui può nascere la domanda: perché allora utilizzare WordPress come CMS generico? La domanda mi è stata fatta dal vivo all’IWordCamp ed in effetti è l’unica cosa importante che sott’intendevo nella presentazione:

1. WordPress: il software di WP è oggi molto evoluto e ricco di funzionalità che spaziano anche molto oltre ai limiti di un CMS dedicato ai blog. Anche se è famoso per questo, come piattaforma è molto flessibile anche per altri utilizzi, praticamente disponibili già out-of-the-box.
2. Ecosistema: ci sono moltissime persone che ci lavorano o lo conoscono e quindi è facile trovare qualcuno a cui chiedere una mano o reperire informazioni (documentazione ufficiale a parte, un po’ carente).
3. Persone: se ci sono nel proprio team molte persone già competenti su WordPress, può essere una scelta migliore sviluppare su questo rispetto a dover imparare un altro strumento.

Come fare quindi?

WordPress Structures •

La cosa interessante è che quindi WP è utilizzabile come CMS per siti generici andando a creare semplicemente un template ad-hoc, strutturato come “portale” invece che come “blog”. Qualche settaggio nel pannello di controllo e poi si è già pronti: non è necessario alcun hacking del codice, che comprometterebbe aggiornamenti futuri della piattaforma. Fosse necessario: create un plugin.

Gli elementi necessari per lavorare sono:

1. Pagine, come contenuti strutturati in una gerarchia
2. Posts, come gestione dei flussi ordinati per data
3. Categorie, nell’accezione ristretta, escludendo quindi i tag
4. Templates, intesi sia come theme su cui lavoreremo, sia come template di pagina singola.

WordPress Mappings • •

Le strutture tecniche ci sono, bisogna iniziare a mapparle:

1. L’architettura informativa (navigazione) progettata per il sito deve essere mappata sulle pagine, più o meno 1:1: vi sarà una home page, sotto questa si aggiungeranno altre pagine e si costruirà così tutta l’alberatura del sito.
2. Le categorie si mappano sui template di pagina. Il template ci permette di definire il layout delle pagine del sito, decidendo quale contenuto va posizionato e dove. Costruendo template a blocchi si può definire che in una posizione viene estratta una specifica categoria, in un’altra una seconda e così via. Si realizza così una pagina singola che estrae contenuti da più parti diverse.
3. Il template associato alle pagine è in grado di concludere la logica descritta sopra: associando dinamicamente categorie a template e template a pagine, si costruisce una struttura semplice in grado di estrarre i contenuti.
   La logica è questa: una pagina ha un nome e uno “slug” (o “nicename”), quello usato per l’URL. La categoria verrà definita con lo stesso “slug” della pagina. In questo modo aprendo la pagina X si caricherà dinamicamente la categoria omonima X (se disponibile). E’ un metodo semplice ed intuitivo, anche perché le categorie come le pagine sono anch’esse una gerarchia.
4. L’ultimo passaggio è nativo in WordPress: i post sono associati a una o più categorie. Pensando a questo punto alle categorie come degli slot di spazio entro cui fare apparire contenuti, visualizzati tramite i template nelle pagine desiderate, si può quindi scrivere un post e decidere in quali e quanti punti del sito farlo apparire.

Due esempi online di siti che ho realizzato con questa logica sono uno Key-One.it (l’azienda dove lavoravo tempo fa), mentre l’altro è un progetto che seguo da alcuni anni, Good50x70, un contest per tentare di dare una spinta a designer, grafici, fotografi e creativi per sensibilizzarli su tematiche sociali.
Il primo evidenzia bene la flessibilità di struttura che si può ottenere, mentre il secondo dimostra come si può realizzare un sito anche semplice tenendo tutti i vantaggi di modificabilità dettati dall’uso di WordPress.

WordPress Portal • • •

Per questo genere di progetti ho realizzato una libreria chiamata WordPress Portal, pubblicata sul sito Argilla, che è il mio contenitore per tutti quei progetti più legati all’aspetto di sviluppo e codice. Insomma, per sviluppatori.

La libreria è un insieme di funzionalità (riunite all’interno del namespace wpp) che ritengo utili e ho quindi raggruppato in questo strumento. Il nome prende spunto da questo utilizzo “generico” di WordPress come CMS, orientato quindi ai più generici “portali”. L’idea iniziale era di farne un plugin, ma per ora non è ancora successo perché ci sono troppi aspetti che necessitano di un programmatore e quindi non sono astraibili a livello utente.
Per ora comunque si può comunque aggiungere la libreria come un plugin in modo da rendere più semplice l’aggiornamento (se il template include una versione vecchia, basta aggiungee quella nuova come plugin) o per estendere un template che non ne fa uso.

Fra le varie funzionalità, la più interessante e comoda in assoluto è wpp::foreach_post(), che permette di creare altri The Loop oltre a quello principale, estraendo una singola categoria, una singola pagina o altre tipologie di contenuti (supporta la sintassi WHERE SQL, oltre ad alcune shortcut).
Il vantaggio è che internamente a questa chiamata si possono utilizzare tutte le funzionalità native di WordPress create apposta per The Loop. Mooooolto comodo.

Ci sono anche altre funzionalità, come ad esempio wpp::get_post_custom() che permette in modo semplice di estrarre i campi personalizzati associati ad un post.

Il progetto è ovviamente opensource, quindi sono benvenute critiche e suggerimenti (oltre che collaboratori).

WordPress Performance • • • •

Una delle più grosse critiche a WordPress sono le sue pessime performance. Seppure questo sia vero, ci sono molte cose che si possono fare per ottimizzare il suo funzionamento.

La prima, la più semplice in assoluto, utile per siti con più di 1000 pageview (stima mia), è utilizzare WP Cache o WP Super Cache. Questi sono due strumenti di caching che permettono di velocizzare notevolmente la visualizzazione della maggior parte delle pagine di un sito WordPress.

Ci sono alcuni test ma nessun benchmark esauriente (nel caso, fate qualche ricerca su Google). Un dato abbastanza recente è quello di Laughingsquid.com, che ha subito un picco di oltre 200.000 visite uniche e, grazie a WP Super Cache, non ha battuto ciglio, su una macchina che è un Dual Xeon 3.2 Ghz. Non poco, ma un investimento marginale nella maggior parte dei casi che possono richiedere di poter reggere oltre 200.000 visite.

Per l’ottimizzazione, vi rimando all’ottima presentazione di Fullo in merito.

Closing • • • • •

Insomma, WordPress è già un ottimo CMS generalista, che non soddisfa tutte le necessità ma è in grado di soddisfare molti requisiti differenti.

A mio avviso è importante non scartarla a priori come piattaforma solo perchè “è per i blog”: ha una struttura molto flessibile, efficace e comoda e con gli opportuni accorgimenti regge anche sensibili carichi di lavoro.

Non vi sto ovviamente consigliando WP in qualunque caso: in rapporto alle necessità, al team di lavoro, ai requisiti, ai vincoli tecnici e progettuali, alle persone che ci dovranno lavorare sia come utenti che come integratori, la scelta varia sensibilmente e quindi WP può – o non può – soddisfare le vostre esigenze. Fate sempre una scelta oculata.

La sessione con Matt è molto orientata a domande e risposte, libera. Lui è estremamente informale e diretto, mi da una ottima impressione.
Interessante nota: WP Cache nativa nelle prossime versioni, supportata dal Google Summer of Code 2008. Molto interessante, anche in virtù della doppia presentazione di oggi mia e di Fullo.

Degli uccellini stanno causando un momento bucolico durante le domande piuttosto interessante. Uno si stava appoggiando al notebook di Simbul.

[12:09] Data abstraction layer? Difficile, aggiunge molto come overhead di sviluppo… ma SQLite? Già interessante. Google Gears? Sarebbe molto interessante, dice. Permetterebbe di velocizzare tutte le operazioni in locale, ovviamente anche offline. “When?” – “Soon”.

[12.18] Non passiamo a PHP5 completamente per motivi di compatibilità, ma le funzionalità di PHP5 sono già utilizzate dove possibile per velocizzare le operazioni.

[12:40] “WordPress is not a democracy”, una ulteriore conferma sulla gestione efficiente dei progetti opensource. Ha aggiunto che solitamente lui si inserisce nelle questioni solamente quando c’è una scelta difficile da fare… cercando di evitare di inimicarsi la fazione che non viene scelta.

[...] Beh ehm, ho potuto aggiornare poco perché fra pranzo, poi mia presentazione (“WordPress come CMS”), poi persone con cui mi son fermato a chiaccherare ho avuto poco tempo.

Come al solito in conclusione faccio qualche appunto organizzativo:

1. Mancavano i badge con i nomi. Questo è stato il mio problema maggiore, perché ho incontrato troppe nuove persone e ho difficoltà a ricordarli.
2. Il WiFi era presente e forniva il minimo essenziale, però era un poco lento. Per questo credo che non si possa dire nulla all’organizzazione, che invece ha gestito tutto molto bene, con anche registrazione nominativa degli account.

Nonostante questo, la location si è prestata molto bene, seppure fuori dai canoni di riferimento. Gli spazi, uno interno ed uno esterno valorizzavano bene gli interventi. Soprattutto quello esterno che è stato disposto ad anfiteatro è stato notevole come efficacia.

Tutto si è svolto senza intoppi, in modo molto fluido e leggero – la giornata soleggiata e il parco han sicuramente contribuito. Anche il problema dell’assenza di una pausa pranzo è stato aggirato visto che le persone sono andate a mangiare in periodi diversi, in modo che ci fosse sempre presenza agli speech (non è bello parlare davanti a nessuno…).

Visto che ho avuto molte richieste, farò un post a parte con la spiegazione della mia presentazione, che però è già disponibile su SlideShare, come sempre.

Nota a margine: i bagni dell’Old Fashion sono terrificanti. Non come gusto, eh, quelli non li discuto. Terrificanti come utilizzo. Primo: davanti agli orinatoi ci sono dei cellulari Tre incassati, che trasmettono tutti la stessa trasmissione, ma fuori tempo l’uno rispetto all’altro, con una cacofonia piuttosto atroce. Secondo: i lavandini ti costringono a chinarti e allungare le mani, perché la testa è bloccata dal muro, a specchio. Terzo: i getti di aria sono sopra dei divanetti, che quindi si bagnano. Quarto: si, ho detto divanetti. In bagno.

[update|2008.05.11] Mi accorgo di non aver ringraziato molte persone che ho avuto il piacere di reincontrare e incontrare. Segnalo quindi il post di Simbul, che l’ha fatto meglio di me…

Cosa? Niente di elaborato, questa volta. Più che altro perché non è coinciso con nessuna novità rilevante, lo ammetto. Così ho ripiegato su una cosa che mi ero chiesto qualche tempo prima: qual è la forma minima indispensabile di un form di registrazione funzionante?

Banale, forse. Sicuramente, rispetto ad alcune presentazioni… Bru ha presentato una prospettiva interessante e lungimirante partendo come base su OpenID e OAuth, per esempio. Oppure, Daniela&Dario hanno presentato uno splendido parallelo recitato (Daniela) e mimato (Dario) sull’esperienza d’uso dei negozi online vs e-commerce online.

Si, scusate. La mia presentazione, “Register Here” è questa, come sempre disponibile su SlideShare:

Noterete una ultima slide piuttosto strana. L’ho aggiunta all’ultimo momento, perché durante la giornata mi è tornata fuori quella domanda ricorrente (“Bad Design Wins?”) e così ho pensato di chiedere anche il parere dei presenti. Credo ritornerò su questo argomento prima o poi, comunque.

Fra le altre presentazioni vi erano quella introduttiva di Luca e Dafne sull’affordance delle banane, che è stata in grado di avviare nel modo giusto il BarCamp. Quella di Donata sull’esperienza d’uso dell’iPod Touch che ha generato interessanti discussioni anche a carattere psicologico e sociale. Quella di Dafne, che ha colto forse tutti in contropiede parlando di mucche. Quella di Nicola Mattina che ha portato alcune riflessioni su 10domande. Quella… er… ok, non posso citarle tutte che la memoria rischia di farmi fare gaffe, soprattutto sui nomi, mi scuso in anticipo e… commentate magari. Vi linko comunque qualche post in merito: Luca, Donata, Gian.

Spero si sia capito: è stato un gran bel BarCamp, che mi ha un po’ riportato allo spirito del BzaarCamp. Un’organizzazione eccellente, un numero di persone ridotto, ma di valore, senza egoici in cerca di platee. E soprattutto, discussioni interessanti: tutte le presentazioni han avuto un bel seguito di conversazioni e spunti… Luca, com’era quella dei tre assi del project management? (che detta così…)

Degna conclusione: un cordon bleu di dimensioni impressionanti. Credo si intraveda fra le foto…

Esiste una Guida per Organizzare un BarCamp, in italiano, sul wiki di Bzaar.net.

Non pretendo che si abbracci completamente l’idea e l’etica dei BarCamp, ma almeno evitare i più banali errori organizzativi. Che dite, proviamo ad evitarli nei prossimi?
E che qualcuno prenda in considerazione quella pagina e la linki – prima e dopo – agli organizzatori!

RItaliaCamp nasce dall’idea di Rifare il portale Italia.it creando un’alternativa che offra un servizio migliore e maggiormente generato/gestito dagli stessi cittadini italiani; il tutto ad un costo irrisorio grazie alla potenza dei servizi e delle tecnologie esistenti sul Web.

RItaliaCamp si propone come un incontro di una giornata dove utenti e professionisti del Web si confrontino con l’obiettivo di concepire e strutturare una proposta alternativa che verrà poi realizzata dai volonterosi che si presteranno all’iniziativa.

Per ora, non aggiungo altro, se non di seguire il wiki se interessati, ed eventualmente lo Swarm per una discussione più rapida.

Forse è passato ancora troppo poco tempo, ma provo ad esplicitare una riflessione che avevo in elaborazione in background dagli scorsi. I punti di riferimento sono fondamentalmente due:

1. Bru che fa riflettere più volte sulla necessità di un backchannel.
2. Io che vedo dagli scorsi BarCamp la fuoriuscita di al massimo uno/due argomenti.

Ora non conosco evidentemente la realtà dei fatti degli altri BarCamp al mondo, ma noto che l’immensa apertura che si percepisce quando si partecipa svanisce quasi completamente per chi è “fuori” e magari non è riuscito a seguire gli streaming.
Certo, può essere anche la mia sola percezione dell’evento perché ‘sbaglio’ a seguirlo, ma almeno dopo questo post saprò cosa sbaglio.
Come viene fatto notare da più e più partecipanti, oggi come nel passato, io incluso, il BarCamp è splendido per lo spirito di condivisione di idee che esiste, serendipità: chi sta proponendo un argomento è del tutto alla pari con gli altri.

Al contrario, all’esterno vi è pochissima esportazione. L’assenza di un backchannel condiviso impedisce a chi è al BarCamp di sincronizzarsi (qualcuno ho visto che l’ha notato) e contemporaneamente impedisce a chi è fuori di inserirsi nelle discussioni e di seguire, anche se in modo imperfetto, gli interventi.

Per i report è magari ancora presto, diamo il tempo alla gente di riposare, quindi il punto 2 potrebbe anche risultarsi falso nel caso di questo BarCamp.

Il punto comunque è piuttosto critico: dal BarCamp rischiano di uscire pochissimi argomenti, rispetto alla totalità degli interventi trattati. La mia stima del tutto ascientifica è che un solo tema esce da ciascun BarCamp italiano.
Per dire, i due precedenti per quel che ho percepito son stati:

1. Blogroll
2. Blogosfera (e lateralmente autoreferenzialità)

Dai primi post potrei stimare che da questo uscirà Twitter, ma non ci scommetterei niente io stesso.

Per risolvere questo problema pensavo prima ad una cosa piuttosto stupida: creare qualche domanda ad hoc che se ricevesse risposta da più persone potrebbe fornire una panoramica interessante dell’evento, dando più punti di vista e fornendo qualche spunto di riflessione in più.

Mi vengono in mente tre domande ora come ora:

1. Quali sono stati gli argomenti più interessati che sono usciti dalle discussioni? Citane almeno tre, non vorrei che per elogiare il primo sfuggisse qualche meme interessante.
2. Quali sono state, se ci son state, le persone più interessanti che hai visto?
3. Sia (1) che (2), perchè?

Qualche anima pia collabora al mio esperimento?

…provate a tirare uno scrollone alle foto. Consiglio una base musicale adeguata.
Se vi piace… potete avere il vostro.