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.

Risorse di web project management

Ho inserito qualche nuovo elemento nella spalla destra di Fucinaweb.

Un box contiene ora un elenco di documenti, articoli e blog che trattano di project management e in particolare di web project management. Sono più di un centinaio di risorse che ho inserito in questi mesi in delicious, la maggior parte con un abstract di presentazione nel campo note. L’elenco completo si trova all’indirizzo delicious.com/TheBigFox/projectmanagement ed è accessibile anche in formato RSS per poterlo aggiungere al proprio lettore di feed.

Nel mio account delicious non si trovano solo risorse di project management, ma di altri argomenti trattati con regolarità qui su Fucinaweb, tra cui:

Ho introdotto un ulteriore box con l’elenco dei tag più utilizzati negli interventi. Prima di farlo ho cercato di inserire i tag anche per i contenuti meno recenti che ne erano privi. Fucinaweb ospita infatti articoli dal 2002, quando davvero pochi strumenti permettevano l’adozione di tag. Tag che ricordano – non è una sorpresa – quelli utilizzati in delicious:

Con i tag si riesce a spingersi oltre così da individuare, per esempio, tutte le recensioni pubblicate oppure i corsi online gratuiti di accessibilità, asp.net e web design.

Ho infine eliminato le categorie perché non rispecchiano l’evoluzione degli argomenti presentati nel sito. Nel farlo ho messo in pratica quanto ho scritto in Categorie e tag, ricette e ingredienti.

Se siete interessati alla totalità dei contenuti, sia per quanto riguarda gli articoli di Fucinaweb, sia per le risorse che segnalo su delicious, ma preferite non riempire il vostro lettore rss di diversi flussi, potete iscrivervi al mio profilo su friendfeed.

Oppure, se volete approfittare per aggiungermi anche nella vostra rubrica, vi consiglio di utilizzare il servizio di social networking professionale offerto da Plaxo, un’ottima soluzione per chiunque voglia gestire i contatti sia su piattaforma Mac, PC, che sul proprio cellulare.

Altri dettagli relativi alle modalità con cui contattarmi si trovano, come sempre, nel mio profilo.

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)