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.

Aggiornare a WordPress 2.3 (e vivere felici)

Giovedì ho aggiornato Fucinaweb all’ultima versione di WordPress, la 2.3. L’operazione mi ha richiesto circa 15 minuti. E’ poco ma, come si suol dire, “mi sono preso in anticipo” e nelle scorse settimane ho provato alcune beta e candidate release prima dell’aggiornamento definitivo.

Riporto qui qualche suggerimento che spero possa tornare utile a chi è indeciso sul da farsi e desideri qualche indicazione per poter pianificare la migrazione con animo sereno. Prima di procedere può essere di aiuto un’introduzione ai cambiamenti introdotti in WordPress 2.3, di cui ho scritto in Uno sguardo a WordPress 2.3.

Un buon backup

Introduzione d’obbligo: il database di WordPress 2.3 non è compatibile con le versioni precedenti. Detto in altre parole, se aggiornate a WordPress 2.3 non potete più tornare indietro: siete su un percorso a senso unico. Questa operazione dovrebbe essere l’ultima cosa che fate prima di sovrascrivere i file della versione precedente.

Uno sguardo ai plugin

La migrazione a WordPress 2.3 procederà con tutta probabilità nel migliore dei modi se la vostra installazione di WordPress non è “farcita” di plugin. In caso contrario, soprattutto se fate uso plugin che cambiano radicalmente il comportamento di WordPress o delle categorie, dovrete come minimo aggiornarli alle versioni più recenti. Come dicevo in Compatibilità plugin e WordPress 2.3 esiste una pagina del codex di WordPress che si preoccupa di elencare le compatibilità dei plugin. Se comunque siete in questa situazione mi permetto di consigliarvi, per evitare brutte sorprese, un’installazione di prova di WordPress 2.3. Non ve ne pentirete. Istruzioni sul come procedere le trovate in testa all’intervento Uno sguardo a WordPress 2.3. Ricordatevi di disabilitare tutti i plugin prima di sovrascrivere la vostra installazione (questa è la penultima operazione da fare, prima del backup del database).

I plugin che uso senza problemi nell’installazione di WordPress 2.3 di Fucinaweb sono:

Il tema WordPress: anticipate i cambiamenti

Quando sono migrato a WordPress 2.3 non ho cambiato di una virgola il tema, neppure dopo aver importato i tag di Ultimate Tag Warrior (UTW) nella nuova tassonomia di WordPress. Eppure l’inclusione dei tag nativi di WordPress richiede nei template una funzione diversa (the_tags), rispetto a quella di UTW (UTW_ShowTagsForCurrentPost).

L’aveto già fatto in precedenza. Ho infatti modificato il template così che venga controllata la presenza della funzione the_tags (indice che è installata la versione 2.3 di WordPress), piuttosto che la presenza della funzione relativa a UTW.

Il codice che ne è uscito è questo:

<div class="tags">

  <?php if (function_exists('the_tags')): ?>

    <?php the_tags('Tag: ', ', ', '');?>

  <?php elseif (function_exists('UTW_ShowTagsForCurrentPost')) : ?>

    <?php echo "Tag: " ; UTW_ShowTagsForCurrentPost("commalist");?>

  <?php endif;?>

</div>

Con questo semplice accorgimento il template di Fucinaweb è in grado di funzionare sia con WordPress 2.2 e UTW, sia con WordPress 2.3. Anche se non usate UTW, vi sarà quasi sicuramente sufficiente apportare una piccola modifica al codice per adattarlo alle vostre esigenze.

Se disponete di una pagina dedicata per i tag (per esempio tag.php), e volete visualizzare in testa all’elenco degli interventi una scritta del tipo “Risultati per tag nome_tag“, il codice sarà simile al precedente:

<div class="archive">Risultati per tag

  <?php if (function_exists('single_tag_title')): ?>

    <?php single_tag_title(); ?>

  <?php elseif (function_exists('UTW_ShowCurrentTagSet')) : ?>

    <?php UTW_ShowCurrentTagSet("tagsetsimplelist");?>

  <?php endif;?>

</div>

Tenete presente che le modifiche hanno senso se UTW non è configurato per inserire automaticamente in fondo ai vostri interventi l’elenco dei tag. Dovete averne la completa gestione.

La maschera dei widget in wordpress 2.3La versione 2.3 di WordPress integra anche una tagcloud – l’elenco dei tag in dimensioni crescenti a seconda della loro frequenza. Se il vostro tema utilizza i widget potete trascinare l’elemento nella spalla del vostro template come se fosse uno qualsiasi degli elementi già previsti da WordPress (testo, elenco delle categorie, commenti, ecc.).

Il codice prodotto da questo elemento, quello su cui con tutta probabilità dovrete intervenire personalizzando i fogli di stile, è simile a:

<li id="tag_cloud" class="widget widget_tag_cloud">

  <h2 class="widgettitle">Tag Cloud</h2>

  <a href='url' class='tag-link-2' title='el1' rel="tag" style='font-size:xxpt;'>Tag1</a>

  <a href='url' class='tag-link-2' title='el2' rel="tag" style='font-size:xxpt;'>Tag2</a>

</li>

Conclusione

Quanto sarà traumatica la vostra migrazione a WordPress 2.3? Dipende da quanto avete portato WordPress a fare quello per cui non è pensato. Se la vostra installazione è standard potete procedere senza grossi problemi, altrimenti il consiglio è quello di provare, prima di procedere, un’installazione parallela su una copia del database.

Stai leggendo uno di una serie di interventi dedicati a WordPress 2.3.

Vecchie versioni che ritornano

Succede che si crei una cartella new nel server per ospitare la nuova versione del sito. Si copiano i file e si fanno le prove per vedere che il tutto funzioni correttamente.

Succede poi che si modifichi il file index nella cartella principale del server in modo che ridiriga alla cartella new. A questo punto tutti i visitatori possono apprezzare la nuova versione.

Succede che ci si dimentichi a questo punto di cancellare i vecchi file e le vecchie cartelle perché, tanto, non le vede più nessuno.

Succede che qualcuno cerchi il sito con Google e capiti nella vecchia versione invece che in quella “new”.

Succede, per esempio, con il sito della cittadina di Anghiari. Il primo risultato restituito da Google fino a oggi è la vecchia versione in inglese.

Succede per tanti, tantissimi altri siti.