Sbrigati o ti cancello il blog

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

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.

Migrare un sito alla nuova versione

Uno degli aspetti solitamente trascurati quando ci si trova a riprogettare un sito web dinamico è la stesura di un “piano” di migrazione, cioè la definizione di una serie di linee guida che portino la nuova versione del sito in sostituzione della precedente.

Solitamente si pensa che sia sufficiente sovrascrivere la vecchia versione, il motore CMS, le parti di codice, i template, il tutto senza tanti complimenti.

Seguire questo modo di procedere ha in realtà diversi aspetti negativi.

Per prima cosa, in caso di problemi, così facendo è molto difficile poter tornare alla versione precedente del sito, soprattutto se il sito ha un buon bacino di pubblico.

E’ bene accertarsi se il sito sia installato su più server bilanciati e compiere l’operazione prima su una delle macchine, testare il sito con una piccola percentuale di utenza, e poi ripetere la stessa operazione sugli altri server.

Ma la migrazione di un sito va pensata già in fase di progetto. Spesso ci si dimentica che una buona percentuale del traffico di un sito proviene dai motori di ricerca, e nel convertire contenuti e parte di codice alla nuova versione non vengono mantenuti gli stessi URL della versione precedente. Vi accorgerete presto di questa dimenticanza quando, analizzando il traffico del sito, noterete un crollo degli accessi. In un precedente intervento abbiamo visto come sia possibile evitare che questo succeda, presentando gli accorgimenti usati durante la migrazione di Fucinaweb.

In base al traffico e all’importanza del sito, la messa online potrebbe essere suddivisa in più passi incrementali. In questo fanno scuola i grandi, Google per primo. Nel rilasciare la nuova versione di Blogger, gli ingegneri di Google si sono preoccupati di limitare i traumi per chi gestisce il proprio weblog con la nuova piattaforma. Per prima cosa, ancora ad Agosto, hanno annunciato il rilascio del nuovo servizio, limitando gli inviti e integrando il login di Google Accounts (quella della registrazione, abbiamo visto qualche mese fa, è una delle operazioni più delicate da integrare). Nel corso delle settimane l’integrazione tra il vecchio servizio e il nuovo è via via aumentata, così come le nuove funzionalità: la beta è stata aggiornata, sono state migrate alcune importanti funzioni della vecchia versione, è stata migliorata la funzione di login, e via via, fino ad arrivare a Novembre, dove la migrazione è in stato avazato e non ancora conlusa.

Non dico che per i nostri progetti web dobbiamo prevedere mesi e mesi di migrazione, ma ricordate di non ragionare mai come se il sito dinamico attuale vada in completa sostituzione del precedente, come nello sovrascrivere un file. La procedura di aggiornamento va studiata caso per caso, e visto che partecipa ad aumentare i tempi di rilascio, va attentamente pianificata.