Così non va Delicious

Come tutti i web project manager degni di questo nome, ho incubi nei quali il progetto in corso si trasforma in una vera e propria odissea, spesso con le sembianze di una messa online in cui tutto quello che poteva è andato storto.

Questi incubi non si sono per fortuna mai del tutto trasformati in realtà (ho comunque commesso errori), ma purtroppo è quanto è accaduto con il rilascio del nuovo Delicious, il famoso sito di social boomarking di cui sono, o meglio ero, felice utente da anni.

Per i pochi che non lo sapessero, Delicious è un servizio acquisito nel 2005 da Yahoo! e, dopo anni di semi-abbandono, rilevato ad aprile di quest’anno da AVOS System, società dei fondatori di YouTube.

Già da tempo ero a conoscenza della cessione, avendo ricevuto e prontamente risposto a un’email che invitava ad accettare i termini del servizio e la politica di privacy del nuovo proprietario, pena la perdita di tutti i bookmark.

Quello che non mi sarei mai aspettato è di ritrovarmi, il 27 settembre, con un servizio completamente diverso da quello fino ad allora utilizzato, mancante delle caratteristiche basilari e pieno zeppo di errori di funzionamento tanto da sembrare, come ho scritto in Google +, una versione preliminare a uso interno.

Penso sia utile cercare di elencare gli errori principali commessi da AVOS nel proporre il servizio, perché questo tipo di supervisione è uno dei compiti principali del web project manager, anche nel caso di migrazione.

Errori di comunicazione

La prima cosa che mi sono chiesto, visto il risultato, è se fosse proprio necessario andare online con una nuova versione del servizio che stravolgeva la precedente. L’ho inizialmente vista come una mossa per dimostrare che quanto non è stato fatto da Yahoo! in 6 anni di proprietà per l’evoluzione del prodotto, la nuova società è stata in grado di farlo in pochi mesi.

Ho poi scoperto che non si è trattato di un vezzo, ma di una necessità, in quanto gran parte del codice di Delicious si basa su framework interni che Yahoo! non ha ceduto e questo ha richiesto una riscrittura significativa.

Mi sarebbe piaciuto saperlo in anticipo. Sono tornato per scrupolo a leggere l’email che invitava alla transizione, ma che si limita a recitare

To continue using Delicious, you must agree to let Yahoo! transfer your bookmarks and Delicious account information to AVOS

sottintendendo che l’operazione è immediata e si potrà continuare ad utilizzare Delicious, lo stesso Delicious di sempre.

Un po’ di trasparenza in più l’utente se la sarebbe meritata, magari anche solo per compiere un’esportazione di sicurezza, ma soprattutto per capire che avrebbe dovuto mettere in discussione la stabilità del prodotto (back to beta).

Errori di strategia

Siamo sicuri che gli utenti non aspettassero altro che l’introduzione degli “stack”, cioè una collezione di link costruita intorno a una tema comune? Ma, soprattutto, che a favore degli stack sacrificassero altre funzionalità prima presenti come i network di amici, i gruppi di tag, la cancellazione e la possibilità di rinominare i tag? La lista di funzionalità del vecchio sito ancora da migrare è parecchio corposa.

Errori di usabilità

Il problema di un sistema a folksonomy è che tende alla proliferazione di tag utilizzati poche volte. Per evitare in parte questa situazione è sufficiente che il tag venga completato dal sistema mentre si scrive, non fosse altro per evitare la generazione di termini sia al singolare sia al plurale. Ma questa semplice e ormai diffusa caratteristica non fa più parte del nuovo Delicious.

Nella vostra pagina compare l’elenco dei tag ordinati dai più utilizzati ai meno. Da qualche giorno è facile capirlo, perché a lato del tag è indicato il numero di volte che avete usato un tag, ma non era così al lancio. Ad aspettarvi c’era una lista, a prima vista disordinata, di tag, e per di più incompleta: non avevate modo di accedere ai tag meno usati.

Errori di programmazione

Dopo 5 minuti di navigazione nel nuovo sito mi sono accorto di un grave errore: mancava la navigazione su più pagine dei propri link una volta scelto un tag. Mi spiego meglio: se selezionavo “project management” tra i miei bookmark, il sistema mi restituiva la prima pagina con alcuni risultati… senza darmi modo di spostarmi ai meno recenti. Anche questa problematica è stata corretta dopo qualche giorno.

Ancora qualche giorno in più lo ha invece richiesto la correzione di problematiche sia relative alle API (impedendo, di fatto, a servizi terzi di accedere ai contenuti), sia agli RSS e alle procedure di esportazione. Trattandosi in tutti e 3 i casi di comunicazioni verso il mondo esterno, l’impressione di alcuni utenti è stata quella di trovarsi in una stanza in cui c’è un principio di incendio e le porte chiuse a chiave dall’esterno.

Errori di copywriting

Diversi utenti hanno scritto su Twitter di non riuscire più ad accedere alla lista dei propri bookmark. Dopo il panico iniziale, l’arcano è stato risolto. Nella nuova versione non si chiamano più “bookmark”, ma semplicemente “link”. Era necessario modificare questa convenzione?

P.S.: da qualche giorno Fucinaweb ha una pagina in Facebook, un esperimento, ma se avete modo passate per un saluto, vi trovate non solo l’elenco degli interventi di Fucinaweb quando sono pubblicati, ma anche link a risorse e articoli di interesse per chi si occupa di Project Management e User Experience.

Categorie e tag, ricette e ingredienti

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.

L’utilità dei tag

Luke Wroblewski ha presentato in un suo intervento un diagramma che evidenzia l’utilità dei sistemi di tagging per i singoli individui e per i gruppi di persone.

Con utilità personale si indica il valore che il sistema di tagging acquista per l’individuo che vuole ritrovare i propri tag, mentre con utilità pubblica si intende il valore che un insieme di tag acquista per un gruppo di persone.

Secondo Wroblewki l’impegno richiesto per marcare con tag il contenuto viene ripagato per i singoli quando non esistono sistemi di ricerca affidabili e la frequenza con si vuole recuperare un elemento è elevata.

Lo stesso per i gruppi, ma in questo caso il sistema rimane efficiente anche quando la frequenza di recupero è bassa, quando cioè gli utenti accedono ai tag occasionalmente.

L’interessante concusione di Wrobleski è che questo potrebbe partecipare a spiegare due fattori:

  • il fatto che i tag vengano usati soprattutto per marcare e successivamente recuperare fonti personali
  • l’uso dei sistemi di tag in aree dove solitamente la tradizionale ricerca si dimostra inefficace, come per esempio le foto (flickr) o i bookmark (del.icio.us)