Archivio della categoria: Strumenti

Una newsletter è per sempre

Pubblicato il da
2

Steve Jobs was originally obsessed with typography.

No, non si tratta dell’ennesimo tweet in ricordo di Steve Jobs, ma l’oggetto di una newsletter che AppSumo ha inviato lo scorso 6 ottobre, a poche ore dalla morte del CEO Apple.

Non ci sarebbe nulla di strano a cavalcare l’onda di santificazione che si è scatenata, se non fosse che in questo caso la passione di Steve Jobs è stata usata in maniera fin troppo esplicita per proporre l’abbonamento a un servizio di font.

Quando ho ricevuto l’email mi sono limitato a storcere il naso, ma a giudicare da quanto ho letto sull’utente Twitter di AppSumo, si è scatenata una piccola rivoluzione tra gli utenti del servizio che hanno trovato l’oggetto decisamente di cattivo gusto.

Noah Kagan di AppSumo è corso ai ripari informando che la newsletter era stata preparata giorni prima e che si sono dimenticati di intervenire in tempo per modificare l’oggetto. Non sta a me stabilire se questo sia vero (rimane comunque il fatto che Steve Jobs era gravemente malato da tempo, sicuramente prima che l’oggetto venisse scritto), ma lo trovo comunque un esempio significativo per sottolineare l’attenzione che va posta nel realizzare una newsletter.

La newsletter è uno strumento inviato nella casella di posta del destinatario e come tale assume un carattere personale, come se fosse stata forgiata esplicitamente per chi la sta leggendo, anche se così non è. Inoltre, quanto è stata inviata non c’è nulla più nulla da fare: non si può correggere il refuso scoperto nel frattempo, non si può allineare meglio l’immagine, non si può modificare il codice per sistemare la visualizzazione in quel particolare programma di posta. I giochi sono fatti.

Mi capita invece molto spesso di ricevere newsletter che sono evidentemente create troppo in fretta, con oggetti di dubbia utilità, ma anche con link di approfondimento che non funzionano, o che rimandano genericamente alla homepage del sito. E lasciamo stare l’argomento “annullamento iscrizione”, che quando c’è non è detto che effettivamente annulli.

La preparazione di newsletter è, invece, un’attività che va pensata con attenzione, proprio perché state in qualche modo invadendo la spazio privato della casella di posta elettronica di chi la riceverà.

E, giusto per non rimanere nel vago, ecco un esempio meno eclatante di quello di AppSumo che evidenzia come anche una newsletter a prima vista trasparente possa creare un po’ di malcontento in chi la riceve.

Qualche settimana fa insieme a un’agenzia con cui collaboro abbiamo deciso di inviare una newsletter agli iscritti invitandoli a ripensare la propria presenza online. Dopo aver valutato internamente alcune proposte, abbiamo scelto l’oggetto “Il tuo sito è per sempre?”.

Nel corpo dell’email è presente una bella immagine e il messaggio “Non hai sposato il tuo sito. Cambialo.”

Le statistiche hanno riportato un risultato molto buono: il 50% dei destinatari ha aperto la newsletter e di questi un altro 50% ha cliccato sul link per avere maggiori informazioni.

Eppure un paio di iscritti, i classici clienti “con cui si ha più confidenza”, hanno risposto di non aver apprezzato in pieno lo stile del messaggio. Forse non gli è piaciuto l’accostamento del matrimonio a un sito? O, più probabilmente, il fatto di averli in qualche modo invitati a divorziare da qualcosa? O forse ancora si sono domandati perché gli stiamo suggerendo di rottamare il sito: forse pensiamo che faccia schifo?

A posteriori avremmo forse cercato una frase meno ambigua. Ma non lo possiamo più fare: una newsletter è per sempre.

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.

Il ruolo delle agenzie nei progetti e-Commerce

Pubblicato il da
2

È uscito in questi giorni per i tipi di Hoepli “e-Commerce, Progettare e realizzare un negozio online di successo“, un manuale scritto da Daniele Vietri e Giovanni Cappellotto.

Il libro contiene anche alcune interviste, tra cui una al sottoscritto, che riporto qui sotto.

Quali caratteristiche deve avere un’agenzia per realizzare al meglio un sito di e-Commerce?

È importante individuare un partner che sia in grado di accompagnare l’azienda non solo nella fase di avvio e di primo rilascio del progetto, ma anche durante i successivi miglioramenti e integrazioni del prodotto che inevitabilmente verranno richiesti. L’agenzia, dopo i primi feedback forniti dalle analisi su utenti e vendite, dovrebbe essere in grado di recepire queste indicazioni e suggerire dei piani di intervento sia nel breve, sia nel medio termine, per esempio con sessioni di test multi-variabile. Molto importante è anche verificare l’esperienza che l’agenzia ha nella progettazione di siti di e-Commerce del proprio settore.

Cosa possono fare i clienti che chiedono un sito e-Commerce per agevolare il lavoro dell’agenzia?

Una delle difficoltà più grandi per il cliente è quella di saper illustrare le proprie esigenze. Alla domanda “qual è l’obiettivo del sito?” può succedere che il cliente risponda passando in rassegna un insieme sparso di componenti che ha notato navigando altri siti, soprattutto quelli dei competitor. Ci si trova allora in riunioni in cui viene chiesto di realizzare la scheda prodotto prendendola da un sito, il carrello da un altro, il risultato ricerca da un altro ancora. In questo contesto è fondamentale il ruolo dell’agenzia nell’aiutare il cliente a individuare in modo corretto e completo i veri requisiti del progetto, così da poter circoscrivere le funzionalità che verranno realizzare per la prima uscita del prodotto e quelle per i rilasci successivi, senza paura di sottolineare le difficoltà e le proprie opinioni in merito. Si fa presto, per esempio, a dire che un sito deve essere accessibile in più lingue, più difficile è gestire le spedizione di prodotto all’estero e risolvere le diverse problematiche di fatturazione o addirittura culturali dei diversi paesi.

Quali sono gli aspetti di un e-Commerce che i clienti trascurano con maggior frequenza?

Spesso gli aspetti più trascurati non riguardano il sito in sé. È certamente importante che il sito sia usabile, veloce, attraente, ma altrettanto importante e forse ancor più importante, è il servizio reso al cliente finale. Come si prevede di gestire la politica di reso? II cliente finale viene guidato in questa procedura o è lasciato in balia di se stesso? Quale potrà essere il tempo medio per la spedizione di un ordine? Esiste un numero verde o un indirizzo mail e quali sono i tempi medi di risposta da parte dell’operatore? Chi si occupa delle foto prodotto e quale è la qualità attesa? Sono domande spesso trascurate, ma che determinano il successo o il fallimento dell’esperienza utente complessiva, di cui quella web è solo una parte.

Quali sono le criticità che sorgono durante la realizzazione tecnica di un e-Commerce?

Le problematiche in ambito tecnico nascono quasi sempre da errori di valutazione in fase di analisi. E i punti dell’analisi che sono più soggetti a errori di valutazione riguardano l’integrazione e la comunicazione con servizi di terze parti e i dettagli della procedura di acquisto, dal momento in cui il cliente finale ha aggiunto un prodotto al carrello fino alla conferma dell’ordine. Se i tempi sono stretti e l’analisi deve essere realizzata in tempi brevi, concentratevi almeno su questi punti.

Nell’ottica di massimizzare le vendite, consiglieresti una piattaforma già pronta o una sviluppata su misura?

La scelta va fatta caso per caso in base ai requisiti del progetto. Se, a fronte dell’analisi dei requisiti e della vendor selection, le modifiche alla piattaforma risultano comunque significative, allora molto probabilmente la direzione corretta è quella della soluzione su misura. Le piattaforme disponibili oggi, sia commerciali sia open source, permettono un livello di personalizzazione tale che possono essere impiegate nella maggioranza dei casi.

Quanto è importante il rapporto con l’agenzia anche dopo la pubblicazione del sito?

È fondamentale, poiché se ogni sito web è una realtà in continua evoluzione, questo vale ancora di più per un sito di e-Commerce, dove è immediata la verifica del successo o del fallimento rispetto ai risultati attesi. Una soluzione di rapporto con l’agenzia potrebbe prevedere la stipula di un contratto di manutenzione annuale che copra la normale assistenza e un certo numero di micro interventi (stimabili per esempio in un monte ore a scalare), lasciando invece sviluppi più corposi a contratti separati.

Fucinaweb diventa testata giornalistica

Pubblicato il da

Da qualche settimana questo sito è registrato in tribunale come testata giornalistica online.

L’ho fatto perché ho qualche idea, ancora da focalizzare con chiarezza, riguardo il futuro di Fucinaweb. Ma anche per curiosità, per capire se e quanto sarebbe stato semplice, e a che costo.

Non ho avuto troppe sorprese rispetto alle mie supposizioni. Ho incontrato persone disponibili, ma davvero poco preparate sull’argomento internet e sulle peculiarità di un sito rispetto a una rivista cartacea. Ho pazientato mesi, passati tra il comune, il tribunale e le sale d’aspetto in attesa in una firma. Ho speso, tra marche da bollo e tasse di iscrizione, più di quanto pensassi.

Iscrivere un sito come testata giornalistica online

Una testata giornalistica ha sempre tre riferimenti:

  • un proprietario, persona fisica o giuridica
  • un editore, anch’esso persona fisica o giuridica
  • un direttore responsabile

Il direttore responsabile, in particolare, è una persona iscritta all’ordine dei giornalisti. Per Fucinaweb il direttore responsabile sono io, in quanto giornalista iscritto all’ordine del Veneto. Nel caso più semplice, il mio, direttore responsabile, editore e proprietario sono la medesima persona.

L’iscrizione della testata avviene per autocertificazione del proprietario e del direttore responsabile, compilando due moduli da presentare in carta bollata alla cancelleria del tribunale presso cui si vuole iscrivere il sito. Per quanto mi riguarda, impersonando sia il ruolo del proprietario sia quello di direttore responsabile, è stata sufficiente una sola richiesta.

Oltre alle complete generalità dei 3 soggetti la domanda deve includere

  • titolo, url, contenuto e periodicità della testata
  • ragione sociale e partita iva del service provider, nonché gli estremi del decreto di autorizzazione del decreto del Ministero delle Comunicazioni 

Prestate attenzione che potrebbe essere necessario, come nel mio caso, richiedere il permesso al service provider presso cui gestite il dominio prima di iniziare le procedure di richiesta di iscrizione. E’ sufficiente inviare una email di richiesta indicando l’argomento trattato dal sito. 

Poiché sono richiesti gli estremi del decreto del Ministero delle Comunicazioni, sulla cui presenza il tribunale – ho potuto verificare – si è dimostrato molto sensibile, c’è da chiedersi se sia possibile iscrivere comunque il sito come testata giornalistica se il service provider non è italiano. Nutro qualche dubbio in proposito, anche se non ho esperienza diretta in tal senso.

Chi fosse interessato a un modulo già pronto da compilare, può scaricare una versione che ho realizzato in formato RTF.

La spesa complessiva, tra tasse di iscrizione e marche da bollo, supera i 200 euro da versare una tantum.

WordPress per un blog aziendale

Pubblicato il da
8

Che la gestione di un blog aziendale richieda competenze e accorgimenti diversi da quelli per un blog a carattere personale è evidente e la documentazione in questo senso non manca (ne ho parlato a proposito dei suggerimenti di lettura per il 2007; un’altra fonte è l’intervento consigli a un giovane blogger aziendale).

Lo stesso discorso vale anche per il software: non è sufficiente l’installazione standard di una piattaforma di blogging per gestire un blog aziendale, soprattutto perché questi strumenti sono pensati prima di tutto per esigenze personali.

Negli ultimi mesi ho fatto un po’ di esperienza con progetti di startup per blog aziendali, in particolare gestiti con WordPress (nella versione 2.2 e 2.3), esperienza che vorrei condividere in qualche dettaglio.

Template personalizzato

Potete decidere di utilizzare un template di WordPress scaricato dalla rete e variarne pochi elementi, come per esempio il logo e i colori. Ma non farete una grande figura. La scelta migliore è quella di personalizzare il blog secondo i canoni del sito aziendale. Questo non vuol dire che la grafica del blog debba essere identica a quella del sito corporate, ma sarebbe bene che alcuni elementi, come per esempio i font, le scelte cromatiche e i rimandi alle sezioni del sito adottassero lo stesso stile.

E’ bene che il template ricordi il sito aziendale, ma non realizzatelo identico: l’utente che naviga le due realtà potrebbe non orientarsi, per esempio non capendo cosa cliccare per tornare alla home del weblog rispetto alla homepage del sito.

Se decidete comunque di partire da un template di base su cui lavorare – scelta consigliabile soprattutto per chi è alle prime armi – impiegate del tempo per analizzare con pazienza il codice. Al di là delle possibilità di localizzazione di WordPress in italiano con l’impiego di opportuni file, per esempio, è quasi certo che alcuni template contengano, cablati nel codice, richiami in lingua inglese. Varrebbe la pena sostituirli.

Non fatevi poi tentare ed eliminare i credits verso il sito di WordPress. Se volete (e l’avete concordato con il cliente) aggiungete la vostra paternità al template, ma non sostituitevi ai creatori della piattaforma di blogging.

Il dominio

La soluzione migliore, potendo gestire un dominio di terzo livello, è che il weblog sia ospitato a un indirizzo del tipo blog.azienda.it. In alternativa, in dipendenza comunque dell’infrastruttura aziendale, è accettabile un percorso del tipo azienda.it/blog.

Weblog multiautore e moderazione

Non è consigliabile, soprattutto nei primi mesi che seguono la messa online del weblog, dare a ogni autore la possibilità di pubblicare in autonomia i propri interventi nel blog. Una soluzione efficace, almeno per il primo periodo, è quella di permettere agli autori la sola possibilità di salvare l’intervento tra le bozze, per poi lasciare a una figura di moderatore o amministratore la facoltà di portare online i diversi interventi. Questo atteggiamento a prima vista dispotico è in realtà prezioso in molti modi:

  • per correggere, nelle prime fasi, contenuti ambigue o dai risvolti potenzialmente pericolosi
  • per dare alle diverse voci del weblog uno stile e direzioni comuni
  • per programmare la pubblicazione dei diversi interventi, così che a periodi di intensa attività non ne seguano altri senza alcun intervento. In aziende che lavorano “a commessa” questa situazione è abbastanza comune, per cui vale la pena di preparare alcuni interventi evergreen da usare in questi casi

Per limitare gli autori all’inserimento di contenuti in bozza è consigliabile assegnarli al ruolo Contributor. Così facendo l’autore ha la possibilità di salvare l’intervento, ma non di pubblicarlo online. Con WordPress 2.3, inoltre, il Contributor può scegliere, oltre a salvare l’intervento nelle bozze, di richiederne la “valutazione per revisione” (potete trovare una descrizione di questa funzionalità nel mio intervento Uno sguardo a WordPress 2.3). In questo modo l’amministrazione ha la possibilità di distinguere quelle che sono normali bozze dagli interventi che sono in attesa di essere pubblicati.

Assegnare il ruolo di Contributor sembra quindi un’ottima soluzione, ma così facendo il redattore perde una funzionalità permessa solo agli amministratori e agli autori, ovvero la possibilità di caricare immagini, foto e documenti tramite il modulo di upload di WordPress.

L’architettura dei ruoli e delle capacità degli utenti in WordPress 2.2 è fortunatamente estensibile e configurabile in ogni dettaglio, caratteristica sfruttata da alcuni interessanti plugin. Tra questi vale la pena segnalare Role Manager, che permette di assegnare a ogni gruppo di utenti specifiche capacità.

Il plugin Role Manager in azione

Ora ogni autore ha tutto quello che serve per realizzare in autonomia un proprio intervento da salvare nelle bozze (o di cui richiedere approvazione).

Se l’amministratore non si collega a WordPress, però, non ne verrà mai al corrente.

Anche in questo caso può essere di aiuto un plugin, Draft Notification, che permette di ricevere alla casella di posta elettronica definita in WordPress un messaggio contenente il titolo e l’autore dell’intervento ogniqualvolta ne venga inserito uno. La soluzione non è però ottimale, perché viene inviata un’email anche a ogni salvataggio (incluso quelli automatici) dell’intervento, generando anche 5/10 email per ogni intervento inserito. Non resta che sperare in un aggiornamento del plugin, configurando nella contingenza una regola del proprio programma di posta per eliminare i messaggi di aggiornamento, che sono contrassegnati da un diverso oggetto.

A questo punto WordPress è opportunamente configurato per permettere a più autori di lavorare e un amministratore di moderare i diversi interventi. Tenete comunque conto che gli autori possono leggere il titolo degli interventi degli altri, anche se questi non sono ancora pubblicati. Questo avviene sia nella bacheca dell’utente, sia nella lista degli articoli pubblicati. Come è però facile immaginare, anche qui c’è da tempo un plugin, IWG Hide Dashboard, che nasconde agli autori la bacheca di Worpress.

I classici plugin e qualcosa in più

Nel progettare l’installazione e configurazione di un blog aziendale tornano utili anche plugin impiegati per i blog personali. Tra questi meritano un accenno sicuramente Akismet per quanto riguarda la protezione da commenti e trackback di spam (già incluso nell’installazione base di WordPress) e il plugin di Feedburner per la gestione e verifica degli iscritti ai propri feed Rss. Se avete la possibilità di creare un dominio di terzo livello, può valere la pena configurare Feedburner con le preferenze di MyBrand, così da poter disporre di un indirizzo proprietario per i feed (ad esempio nella forma feed.azienda.it), piuttosto che di un generico http://feeds.feedburner.com/azienda. In questo caso vi garantite la possibilità di abbandonare in futuro Feedburner, magari a favore di qualche nuovo servizio che dovesse nascere, senza rischiare di perdere i visitatori già iscritti ai feed e doverli informare della variazione.

Ci sono poi altri plugin che permettono di aumentare ancora più il livello di personalizzazione di WordPress. Non è questa la sede adatta per parlarne, ma chi fosse interessato può dare un’occhiata a I migliori (o quasi) plugin per WordPress.

Sicurezza

Trattandosi di un blog aziendale vale la pena porre qualche cautela per evitare che i contenuti vengano compromessi o che persone non autorizzate possano autenticarsi. Di sicurezza delle piattaforme di blogging si potrebbe scrivere pagine e pagine. Non l’ho farò io qui, visto che il Worpress Security Whitepaper contiene un’ottima introduzione all’argomento.