Archivi tag: wordpress

L’usabilità dei progetti opensource

Pubblicato il da

Un intervento sul blog di Experientia lamenta, non senza ragione, le problematiche di usabilità di molti progetti opensource. L’occasione per farlo è un comunicato stampa in cui Canonical, lo sponsor commerciale di Ubuntu, cerca consulenti di usabilità per i propri progetti, competenza evidentemente non presente in azienda.

Fino a qualche anno fa potevamo giustificare le lacune in ambito di usabilità e più in generale di user experience del software opensource. Erano progetti nati grazie a team focalizzati sulla progettazione e stesura di codice e usati da una ristretta minoranza di early adopters.

Le aspettative oggi sono diverse. Alcuni prodotti, come Open Office e WordPress, si rivolgono a un pubblico variegato, grazie anche a procedure di installazione semplificate e, nel caso di prodotti web, a metodi di fruizione ASP.

In questo contesto le problematiche tecniche, seppur importanti, passano in secondo piano. Il software deve essere facile da utilizzare, ma ancora di più deve proporre interfacce coerenti. Risultati che non si raggiungono per caso o con un po’ di buon senso, ma con l’introduzione di specifiche competenze professionali. Competenze che difficilmente si prendono in prestito.

Mi stupisce perciò l’iniziativa del team di WordPress che apre due questionari pubblici su questioni legate alla nuova interfaccia di amministrazione:

  • l’attuale interfaccia è il risultato di una già recente riprogettazione che ha richiesto agli utenti un nuovo approccio all’uso del software. Frequenti variazioni, per quanto si propongano di migliorare il lavoro di tutti, sono destabilizzanti;
  • ridurre la progettazione di una interfaccia grafica a un questionario sminuisce l’importanza e il ruolo di questa disciplina, anche quando gran parte delle decisioni sembrano prese;
  • il questionario si prefigge di raccogliere 5000 risposte. Ma il design di interfaccia non è un approccio democratico, quanto una disciplina che si prefigge di capire quale è la soluzione migliore per il pubblico di riferimento. Sono convinto che la maggior parte dei partecipanti al sondaggio sono sviluppatori, non necessariamente il target principale a cui si rivolge WordPress.

Ho avuto modo di provare per qualche minuto una versione, sicuramente non definitiva, della futura amministrazione di WordPress e ne sono rimasto sconcertato, soprattutto nel notare che quasi ogni azione richiede, diversamente dall’attuale, un primo click per aprire il menù e un secondo per selezionare la voce voluta. Le premesse non mi sembrano delle migliori.

Qualcosa comunque sembra muoversi nel verso giusto, anche se a un maggiore livello di astrazione. Il team di Mozilla promuove Concept Series, un insieme di idee, wireframe e prototipi a partecipazione pubblica per definire la visione dei futuri prodotti opensource. Nulla a che vedere con l’usabilità, ma qualcosa che potrebbe aiutare a raccogliere attorno ai progetti opensource una comunità con competenze non solo tecniche, ma anche di design e di user experience.

Aggiornamento serale: il blog di WordPress presenta una prima versione dei wireframe realizzati per progettare la nuova interfaccia di amministrazione. Visto che non è facile trovare in rete documenti che riportano wireframe completi e documentati, vale sicuramente la pena darci un occhio.

WordPress per un blog aziendale

Pubblicato il da

Che la gestione di un blog aziendale richieda competenze e accorgimenti diversi da quelli per un blog a carattere personale è evidente e la documentazione in questo senso non manca (ne ho parlato a proposito dei suggerimenti di lettura per il 2007; un’altra fonte è l’intervento consigli a un giovane blogger aziendale).

Lo stesso discorso vale anche per il software: non è sufficiente l’installazione standard di una piattaforma di blogging per gestire un blog aziendale, soprattutto perché questi strumenti sono pensati prima di tutto per esigenze personali.

Negli ultimi mesi ho fatto un po’ di esperienza con progetti di startup per blog aziendali, in particolare gestiti con WordPress (nella versione 2.2 e 2.3), esperienza che vorrei condividere in qualche dettaglio.

Template personalizzato

Potete decidere di utilizzare un template di WordPress scaricato dalla rete e variarne pochi elementi, come per esempio il logo e i colori. Ma non farete una grande figura. La scelta migliore è quella di personalizzare il blog secondo i canoni del sito aziendale. Questo non vuol dire che la grafica del blog debba essere identica a quella del sito corporate, ma sarebbe bene che alcuni elementi, come per esempio i font, le scelte cromatiche e i rimandi alle sezioni del sito adottassero lo stesso stile.

E’ bene che il template ricordi il sito aziendale, ma non realizzatelo identico: l’utente che naviga le due realtà potrebbe non orientarsi, per esempio non capendo cosa cliccare per tornare alla home del weblog rispetto alla homepage del sito.

Se decidete comunque di partire da un template di base su cui lavorare – scelta consigliabile soprattutto per chi è alle prime armi – impiegate del tempo per analizzare con pazienza il codice. Al di là delle possibilità di localizzazione di WordPress in italiano con l’impiego di opportuni file, per esempio, è quasi certo che alcuni template contengano, cablati nel codice, richiami in lingua inglese. Varrebbe la pena sostituirli.

Non fatevi poi tentare ed eliminare i credits verso il sito di WordPress. Se volete (e l’avete concordato con il cliente) aggiungete la vostra paternità al template, ma non sostituitevi ai creatori della piattaforma di blogging.

Il dominio

La soluzione migliore, potendo gestire un dominio di terzo livello, è che il weblog sia ospitato a un indirizzo del tipo blog.azienda.it. In alternativa, in dipendenza comunque dell’infrastruttura aziendale, è accettabile un percorso del tipo azienda.it/blog.

Weblog multiautore e moderazione

Non è consigliabile, soprattutto nei primi mesi che seguono la messa online del weblog, dare a ogni autore la possibilità di pubblicare in autonomia i propri interventi nel blog. Una soluzione efficace, almeno per il primo periodo, è quella di permettere agli autori la sola possibilità di salvare l’intervento tra le bozze, per poi lasciare a una figura di moderatore o amministratore la facoltà di portare online i diversi interventi. Questo atteggiamento a prima vista dispotico è in realtà prezioso in molti modi:

  • per correggere, nelle prime fasi, contenuti ambigue o dai risvolti potenzialmente pericolosi
  • per dare alle diverse voci del weblog uno stile e direzioni comuni
  • per programmare la pubblicazione dei diversi interventi, così che a periodi di intensa attività non ne seguano altri senza alcun intervento. In aziende che lavorano “a commessa” questa situazione è abbastanza comune, per cui vale la pena di preparare alcuni interventi evergreen da usare in questi casi

Per limitare gli autori all’inserimento di contenuti in bozza è consigliabile assegnarli al ruolo Contributor. Così facendo l’autore ha la possibilità di salvare l’intervento, ma non di pubblicarlo online. Con WordPress 2.3, inoltre, il Contributor può scegliere, oltre a salvare l’intervento nelle bozze, di richiederne la “valutazione per revisione” (potete trovare una descrizione di questa funzionalità nel mio intervento Uno sguardo a WordPress 2.3). In questo modo l’amministrazione ha la possibilità di distinguere quelle che sono normali bozze dagli interventi che sono in attesa di essere pubblicati.

Assegnare il ruolo di Contributor sembra quindi un’ottima soluzione, ma così facendo il redattore perde una funzionalità permessa solo agli amministratori e agli autori, ovvero la possibilità di caricare immagini, foto e documenti tramite il modulo di upload di WordPress.

L’architettura dei ruoli e delle capacità degli utenti in WordPress 2.2 è fortunatamente estensibile e configurabile in ogni dettaglio, caratteristica sfruttata da alcuni interessanti plugin. Tra questi vale la pena segnalare Role Manager, che permette di assegnare a ogni gruppo di utenti specifiche capacità.

Il plugin Role Manager in azione

Ora ogni autore ha tutto quello che serve per realizzare in autonomia un proprio intervento da salvare nelle bozze (o di cui richiedere approvazione).

Se l’amministratore non si collega a WordPress, però, non ne verrà mai al corrente.

Anche in questo caso può essere di aiuto un plugin, Draft Notification, che permette di ricevere alla casella di posta elettronica definita in WordPress un messaggio contenente il titolo e l’autore dell’intervento ogniqualvolta ne venga inserito uno. La soluzione non è però ottimale, perché viene inviata un’email anche a ogni salvataggio (incluso quelli automatici) dell’intervento, generando anche 5/10 email per ogni intervento inserito. Non resta che sperare in un aggiornamento del plugin, configurando nella contingenza una regola del proprio programma di posta per eliminare i messaggi di aggiornamento, che sono contrassegnati da un diverso oggetto.

A questo punto WordPress è opportunamente configurato per permettere a più autori di lavorare e un amministratore di moderare i diversi interventi. Tenete comunque conto che gli autori possono leggere il titolo degli interventi degli altri, anche se questi non sono ancora pubblicati. Questo avviene sia nella bacheca dell’utente, sia nella lista degli articoli pubblicati. Come è però facile immaginare, anche qui c’è da tempo un plugin, IWG Hide Dashboard, che nasconde agli autori la bacheca di Worpress.

I classici plugin e qualcosa in più

Nel progettare l’installazione e configurazione di un blog aziendale tornano utili anche plugin impiegati per i blog personali. Tra questi meritano un accenno sicuramente Akismet per quanto riguarda la protezione da commenti e trackback di spam (già incluso nell’installazione base di WordPress) e il plugin di Feedburner per la gestione e verifica degli iscritti ai propri feed Rss. Se avete la possibilità di creare un dominio di terzo livello, può valere la pena configurare Feedburner con le preferenze di MyBrand, così da poter disporre di un indirizzo proprietario per i feed (ad esempio nella forma feed.azienda.it), piuttosto che di un generico http://feeds.feedburner.com/azienda. In questo caso vi garantite la possibilità di abbandonare in futuro Feedburner, magari a favore di qualche nuovo servizio che dovesse nascere, senza rischiare di perdere i visitatori già iscritti ai feed e doverli informare della variazione.

Ci sono poi altri plugin che permettono di aumentare ancora più il livello di personalizzazione di WordPress. Non è questa la sede adatta per parlarne, ma chi fosse interessato può dare un’occhiata a I migliori (o quasi) plugin per WordPress.

Sicurezza

Trattandosi di un blog aziendale vale la pena porre qualche cautela per evitare che i contenuti vengano compromessi o che persone non autorizzate possano autenticarsi. Di sicurezza delle piattaforme di blogging si potrebbe scrivere pagine e pagine. Non l’ho farò io qui, visto che il Worpress Security Whitepaper contiene un’ottima introduzione all’argomento.

Categorie e tag, ricette e ingredienti

Pubblicato il da

Con il rilascio della versione 2.3 di WordPress la gestione dei tag associati a un intervento è ormai una caratteristica nativa della piattaforma. A volte però non è così chiaro, per chi si trova a gestire il sito, quando sia preferibile utilizzare i tag e quando invece le categorie. WordPress 2.3 permette perfino di convertire le categorie in tag, così da aumentare l’indecisione.

La domanda che ci si pone è più o meno questa: “Meglio abbandonare del tutto le categorie, non usare proprio i tag o in qualche modo dare a ognuno dei due il proprio ruolo?”.

Può aiutare a rispondere un intervento di Lorelle di qualche mese fa, Are Tags Working For You?. L’articolo affronta anche altri temi, ma mi limito a riportare questa breve considerazione:

Le categorie sono il sommario del blog. I tag sono le parole presenti nell’indice.

La categorie sono quindi usate per definire il contesto in cui “si muove” l’intervento, l’argomento generale di cui si occupa. I tag invece sono definiti dopo un’analisi del testo e dei termini principali che lo compongono, che è poi lo stesso procedimento usato per realizzare l’indice di un libro.

Io solitamente uso un un altro esempio, quello delle ricette e degli ingredienti. Le categorie sono per me le tipologie di piatto della ricetta, quindi primi, secondi, verdura, dolce. I tag sono invece paragonabili agli ingredienti che compongono la ricetta, fragole, farina, uova, lievito.

In questo modo sottolineo anche un’altra differenza tra categorie e tag: le tipologie di piatto, sono in numero limitato o – meglio ancora – sono definite a priori. Lo stesso dovrebbe succedere per le categorie di un blog. Se vi trovate ogni giorno ad aggiungere una nuova categoria, i casi sono due: non le state usando come si deve o non avete ancora capito di cosa parlerà il vostro blog. In entrambi i casi c’è qualcosa che non funziona come dovrebbe.

Gli ingredienti, invece, sono in numero molto variabile, non infinito, ma in un’altra scala rispetto alle tipologie di piatto. Proprio come i tag.

Per me la selezione della categoria di appartenenza di un intervento è un’operazione che quasi sempre avviene prima della scrittura dello stesso intervento. So già quali sono gli argomenti di cui parlerò, per cui la scelta della categoria è una logica conseguenza. Aggiungo invece i tag dopo aver scritto l’intervento, ma anche dopo averlo riletto, adattato e modificato. Scorrendo la lettura evidenzio le parole significative presenti nell’intervento e le riporto nella casella dei tag, avendo l’accortezza di seguire qualche linea guida come per esempio l’uso – dove possibile – della lingua italiana, e del singolare.

Poiché i tag sono parte di un indice ipertestuale, cerco inoltre di sfruttarne questa potenzialità. Al Future of Web Apps di Londra dello scorso anno, per esempio, ho inserito in coda a ogni intervento un link di rimando a tutti gli articoli contenenti il tag fowa2007. I tag possono quindi essere impiegati anche per aggregare tra loro tutti gli interventi che trattino lo stesso micro-argomento.