Archivio tag: migrazione

Così non va Delicious

Pubblicato il da
Risposta

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)

Pubblicato il da
6

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

Pubblicato il da
1

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.

Sbrigati o ti cancello il blog

Pubblicato il da
2

Due recenti messaggi che riguardano la cessazione di servizi, il primo trovato in Kataweb, il secondo ricevuto via email da Yahoo!.

Un estratto condensato del primo:

Kataweb Blog al momento è un servizio basato sulla piattaforma TypePad.
Kataweb ha deciso di non utilizzare più la piattaforma di TypePad a partire da mercoledì 25 luglio 2007.

Ricevuta la mail dovrai scegliere, entro e non oltre la mezzanotte del 22 luglio 2007, una tra le seguenti due opzioni:

  1. Trasferire il tuo Blog sulla nuova piattaforma di Kataweb
  2. Rimanere TypePad e abbonarti alla loro versione a pagamento

Se entro la mezzanotte del 22 luglio 2007, non avrai scelto alcuna delle due opzioni, il tuo Blog verrà disattivato e tutti i contenuti saranno cancellati definitivamente.

e della email di Yahoo!

Dear Yahoo! Photos user,

For some time now, we’ve supported two great photo sharing services: Yahoo! Photos and Flickr. But even good things come to an end, and we’ve decided to close Yahoo! Photos to focus all our efforts on Flickr — the award-winning photo sharing community that TIME Magazine has called “completely addictive.”

We will officially close Yahoo! Photos on Thursday, September 20, 2007, at 9 p.m. PDT.

Please give us your decision by Thursday, September 20, 2007, at 9 p.m. PDT. After that time, any photos remaining in Yahoo! Photos will be deleted.

Due messaggi apparentemente simili, anche se si riferiscono a servizi diversi. Apparentemente:

  1. Kataweb, non è un po’ tardi avvisarmi i primi di Luglio per dirmi che mi cancelli il 22 di Luglio? Metti che abbia la fortuna di passarmi 3 settimane in vacanza. Al ritorno cosa faccio quando mi vedo il blog annientato? Yahoo! da’ un bel po’ di tempo in più, il giusto per poter fare qualcosa
  2. Non mi piace quel “Kataweb ha deciso di non utilizzare più la piattaforma di TypePad”. Sa troppo di rimprovero verso un fornitore di servizi di cui non si è contenti
  3. Perché, visto che se clicco un tasto mi porti sulla nuova piattaforma blog, non lo fai automaticamente se non dico nulla? Vuoi forse risparmiare qualche centesimo di spazio disco non migrando i blog abbandonati? Ma portali tutti di là! (La stessa cosa vale comunque anche per Yahoo!, anche se in questo caso potrebbero forse cambiare i termini di privacy con cui sono condivise le foto in Flickr).
[tags]yahoo!, flickr, kataweb, email, migrazione, weblog[/tags]

Riprogettazione di applicazioni web

Pubblicato il da
1

Riprogettare un’applicazione web nel nome di una migliore usabilità, oltre che per arricchirne le funzionalità, è un’operazione lodevole e che si verifica molto spesso in un ambito così concorrenziale come internet.

Ma attenzione a stravolgere un’applicazione, anche se con i propositi più meritevoli.

E’ vero che riprogettare un’applicazione web la può notevolmente migliorare, ma è anche vero che gli utenti affezionati al servizio, soprattutto quelli meno esperti, si trovano a dover reimparare l’uso di un’interfaccia che conoscevano alla perfezione (sia i suoi pregi, sia i suoi difetti). Rendetevi conto che state chiedendo a questi utenti, che vi hanno dato fiducia, di fare del lavoro non richiesto.

Non esistono delle regole da applicare a propri che spieghino come comportarsi. Vale la pena prima di tutto coinvolgere gli utenti, e questo si può fare ancora prima di riprogettare l’applicazione, chiedendo il loro parere sui limiti della versione attuale e sulle funzionalità di cui il prodotto manca.

Le statistiche, insieme ai dati delle registrazioni, sono un ottimo metodo per distinguere la percentuale di utenti consolidati rispetto a chi entra e fugge, e vi può aiutare a capire a quanti utenti state arrecando piccoli o grandi disagi. Quest’analisi, in realtà, andrebbe fatta indipendentemente dalla riprogettazione del servizio.

Nella maggioranza dei casi quello che emerge è che piuttosto di considerare l’applicazione come una tabula rasa su cui ripartire da zero, è meglio procedere con passi incrementali, ben documentati.

Introdurre una nuova funzionalità, sottolineare i cambiamenti nell’interfaccia, attendere un feedback, introdurre una nuova funzionalità, e così via.

E’ quello che succede con prodotti come Flickr e Gmail che vengono considerati in “beta perpetua”. Questo permette al team di sviluppo di rilasciare costantemente nuove funzionalità secondo i principi della programmazione agile, ma evita anche agli utenti di essere sommersi da nuove caratteristiche da digerire tutte in un colpo.

Capita a volte che questo procedimento non sia perseguibile, perché la riprogettazione dell’applicazione si discosta talmente tanto dalla versione precedente da rendere impossibile il rilascio incrementale.

Anche in questo caso si può, in alcuni casi, fare qualcosa. E’ quello che è successo ad esempio con Google Reader. In questo caso la vecchia versione del prodotto è stata completamente riscritta, senza stazioni intermedie.

Ogni utente ha però la possibilità di tornare, se non è soddisfatto della nuova versione, a quella precedente, dovesse mai preferirla, per un periodo limitato, e sottoporre anche un commento. Si tratta comunque di un processo altamente dispendioso, perché vi trovate a gestire contemporaneamente due prodotti diversi.