Guerrilla web project management

Le slide con l’audio della mia presentazione a Better Software dello scorso giugno. Come può evolvere la professione del web project management in un mondo complesso?

Dietro le quinte di un progetto

Il blog della BBC è una ricca miniera per imparare da casi concreti il design e redesign di un progetto web.

Progettare con la carta

La creazione di bozzetti di carta è un approccio quantitativo che permette di valutare e migliorare in poco tempo diverse soluzioni per la progettazione di un servizio.

Checklist e web project management

Cosa hanno in comune un chirurgo e un web project manager? L’uso delle checklist per ridurre la probabilità di errore.

A ogni cosa il suo nome

figo.psd e che_palle.zip: quando è il caso di definire una nomenclatura condivisa.

Interventi correlati

• Checklist e web project management
  Cosa hanno in comune un chirurgo e un web project manager? L'uso delle checklist per ridurre la probabilità di errore. Continua a leggere →...
• Domande e risposte sul web project management (FAQ)
  Ho raccolto in questo articolo le domande che più di frequente ricevo riguardo al web project management, con l’intenzione di proporre un seguito a quanto ho già riportato in Introduzione al web project management. É un punto di partenza. Chiunque … Continua a leggere →...
• Checklist per l’ultimo miglio
  Una lista di verifiche che può aiutare nella messa online di un sito Continua a leggere →...
• Guerrilla web project management
  Il web project management è caratterizzato da peculiarità che lo differenziano dal classico software project management, come la continua e variegata evoluzione tecnologica e la gestione concorrente di progetti di piccole, medie ed elevate dimensioni (ne ho parlato a proposito … Continua a leggere →...
• Project manager: leader o ragioniere?
  Interessante l’intervento dal titolo Are you a leader or a tracker? scritto da Scott Berkun, già autore del testo The Art of Project Management. Berkun si riferisce al termine project manager, spesso utilizzato per descrivere figure professionali che project manager … Continua a leggere →...

Questa volta tocca all’applicazione iPhone del player che permette di rivedere i programmi trasmessi dall’emittente britannica.

E come sempre gli spunti non mancano, soprattutto perché non è presentato unicamente il risultato finale, ma anche le scelte che hanno portato alle diverse scelte progettuali, con particolare riferimento a quello che funziona meglio in ambito mobile:

• non condensare troppe funzionalità in ogni schermata
• tenere in considerazione i problemi di banda che possono verificarsi durante lo streaming
• sfruttare la possibilità di presentare interfacce e funzionalità diverse in portrait e landscape

Interventi correlati

• Progettare e sviluppare per dispositivi mobile
  Per lavoro mi sono trovato a dover studiare i principi base dello sviluppo di applicazioni per dispositivi mobili. Ma più che la tecnica, il linguaggio di programmazione, l’aspetto più complesso per chi proviene dal mondo “desktop” è sicuramente la definizione … Continua a leggere →...
• 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 … Continua a leggere →...
• Usabilità per dispositivi mobile
  Per chi fosse interessato ad approfondire le tematiche di design e usabilità per dispositivi portatili, come i cellulari, consiglio di provare la versione mobile di Gmail. Vi si può accedere con un dispositivo portatile all’indirizzo http://m.gmail.com, ma anche le ultime … Continua a leggere →...
• Progettare con la carta
  Da qualche mese sto sperimentando con soddisfazione uno strumento diverso per quella fase di progettazione che segue la definizione della strategia online e precede la creazione di prototipi. Prendo un foglio di carta e realizzo a mano bozzetti che possono … Continua a leggere →...
• Progettare una presentazione
  Aggiornamento del 5 Giugno 2009: ho scritto presentazioni che funzionano dopo l’esperienza a Better Software Aggiornamento del 10 Maggio 2009: ho caricato le slide e l’audio del mio intervento a Better Software Il 6 e 7 maggio sarò a Firenze … Continua a leggere →...

The Messy Art Of UX Sketching di Smashing Magazine si spinge nel dettaglio, illustrando le principali tecniche. Tra gli strumenti da portarsi a casa ci sono sicuramente:

• il colore per evidenziare l’importanza di alcune sezioni
• i post-it nella creazione di tool-tip, popup e finestre modali
• le fotocopie per realizzare bozzetti (processo generativo)

4 ways to prototype faster raccoglie in un breve articolo quello che mi sentirei di suggerire su questo tema:

• iniziate a lavorare con la carta
• adottate un solo software per creare i prototipi, non una selezione (keynote + photoshop + balsamiq + dreamweaver)
• cercate, tra le diverse soluzioni, quella che vi permetta di produrre anche la documentazione funzionale
• utilizzate strumenti che vi aiutino a condividere il lavoro

5 Sketching Secrets of Leonardo Da Vinci indica qualche suggerimento per migliorare la creazione dei bozzetti, prendendo spunto dai lavori di Leonardo da Vinci. Il paragone è forse azzardato, i consigli meno:

• quello dei bozzetti è un processo generativo, che mira a creare diverse prospettive dello stesso concetto
• oltre all’interfaccia, il bozzetto può essere completato da note a margine, per chiarire il contesto e gli elementi non facilmente deducibili dalla sola interfaccia
• scopo dei bozzetti è di essere criticati costruttivamente; il processo è collaborativo
• la soluzione a una problematica può arrivare da campi diversi
• imparare a catalogare i lavori realizzati, così da avere una banca dati di soluzioni alternative

Interventi correlati

• Ancora su Ajax e usabilità
  Anche le prime ore di vita di Google Calendar non sono state esaltanti. Ho perduto modifiche che ero convinto di aver salvato e soprattutto ero spaesato perché spesso non capivo se a una mia azione seguiva un riscontro del software. … Continua a leggere →...

Ma non lo faccio.

Non lo faccio non perché voglia tenermi ben stretto tutto quello che ho imparato in questi 15 anni di lavoro.

Non lo faccio perché non posso.

Non posso perché a monte della mia attività di consulenza (e, in passato, di dipendente) c’è quasi sempre un accordo di riservatezza: non posso parlare dei dettagli del mio lavoro.

Non giudico se quella di far firmare clausole del genere sia una strategia efficace, ma mi dispiace non poter condividere esperienze o casi di studio pratici che difficilmente trovano posto nei libri. La realtà è spesso diversa da quella che si legge nei testi accademici.

Quello degli accordi di riservatezza è però un vizio che si propaga con una certa velocità. Se fino a ieri interessava le aziende di grandi dimensioni, mi capita sempre più spesso di sentire amici e colleghi che si trovano a firmare un accordo di questo tipo anche per progetti di poche migliaia di euro.

Ma non è di questo che volevo discutere oggi (segnalazioni riguardo la vostra esperienza nei commenti sono comunque molto bene accette, se non altro per capire l’entità del fenomeno).

C’è infatti chi per fortuna non ha problemi a condividere nel dettaglio la propria esperienza, come nel caso della BBC.

Un esempio su tutti è il redesign del meteo, che è stato descritto magistralmente dal team di lavoro in BBC Weather: Design Refresh in Pictures. Perché magistralmente?

• Perché indicano l’intero processo di progettazione e non solo una parte
• Perché presentano grafici e diagrammi (come quello relativo alle 5W – Who, When, Why, Where, What) che si aprono a tutto schermo, così da leggere per intero quello che c’è scritto, senza segreti
• Perché elencano le parti del sito precedente a cui hanno rinunciato, e il motivo
• Perché non si vergognano di far vedere che tutto prende vita dai bozzetti su carta (ne scrivevo giusto qualche settimana fa)
• Perché indicano chiaramente la vision e come ogni professionista al lavoro sfrutti le proprie competenze per raggiungere gli obiettivi
• Perché sottolineano l’importanza delle icone e della infografica (quella fatta bene) in un progetto di questo tipo.
• Perché sapevano che descrivere nel dettaglio la complessa macchina del redesign avrebbe attirato le (inevitabili) critiche di chi si trovava meglio con la versione precedente (vedi i commenti 12 e 13)
• Perché scrivono nero su bianco il nome delle agenzie e dei partner che li hanno aiutati nella progettazione del sito, invece di tenerli nascosti (magari facendo firmare un documento di riservatezza, giusto per ritornare al tema iniziale)

La possibilità di condividere così nel dettaglio la propria esperienza deriva probabilmente anche dal fatto che la BBC è pagata dalle tasse dei contribuenti e questo è un modo di far capire come sono impiegati questi soldi e di ritornare un po’ della conoscenza maturata.

Sarebbe allora bello che la Rai facesse lo stesso, ma vista la qualità dei progetti che mettono online forse sono ancora nella fase precedente, quella in cui devono ancora imparare come si fa a realizzarlo, un sito.

Interventi correlati

• Dietro le quinte del nuovo template di Fucinaweb
  Temi per WordPress ne troviamo a vagoni nel web, una ricerca con google dei termini “worpress theme” ritorna più di 78 milioni di pagine e devo dire che parecchi sono anche molto belli. Se li guardiamo per il blog del … Continua a leggere →...

È bello, interessante e istruttivo lavorare per un e-commerce, perché il sito non è fine a sé stesso, ma a supporto della vendita e non solo deve funzionare, ma deve funzionare bene, benissimo.

Per chi lavora nel campo della user experience un sito di e-commerce presenta anche delle opportunità uniche per proporre e mettere in cantiere dei miglioramenti e verificarne immediatamente il risultato.

Tra le diverse aree di un sito di e-commerce mi piace mettermi al lavoro sul processo di checkout perché rappresenta una vera e propria sfida dove ogni testo, etichetta, bottone deve essere limato e lucidato per bene. Il processo di checkout è infatti composto da funzionalità che svolgono il duplice scopo di proporre al cliente (o, almeno, si spera lo diventi!) delle precise informazioni sulle operazioni che sta per compiere e di ricevere informazioni su come desidera concludere l’acquisto.

Avere la possibilità di compiere sessioni di multivariate testing a un processo di checkout penso sia un’esperienza che ogni specialista di user experience dovrebbe provare.

In più di un’occasione mi sarebbe piaciuto parlarne in un intervento, ma l’argomento è complesso e un articolo di pochi paragrafi, ma anche il capitolo di un libro rischiano di banalizzare o non far apprezzare l’attenzione e le strategie necessarie per la progettazione e verifica di un processo di checkout che funzioni in tutti i suoi aspetti.

Anche la stesura di una o più checklist di riferimento (di cui sono innamorato) ha poco senso, se non con un documento di dettaglio a corredo.

Ecco perché preferisco consigliarvi due interessanti report che si concentrano sul processo di acquisto approfondendone ogni dettaglio.

Il primo è E-Commerce Checkout Usability, scritto da Jamie Appleseed e Christian Holst del Baymard Institute. Si basa su sessioni di usability test che hanno coinvolto 10 utenti durante la navigazione di 15 siti di e-commerce: 1-800-Flowers, AllPosters, American Apparel, Amnesty Shop, Apple, HobbyTron, Levi’s, NewEgg, Nordstrom, Oakley, Perfume.com, PetSmart, Thomann, Walmart e Zappos.

Il risultato sono 63 linee guida raggruppate in 6 categorie (data input, copywriting, layout, navigation, flow, focus) che in 140 pagine affrontano con ricchezza di esempi, positivi e negativi, il processo di checkout. Alcune indicazioni sono sicuramente note a chi si occupa di user experience (come la progettazione dei form, argomento tra l’altro molto ben affrontato da Luke Wroblewski in Web Form Design), altre sono forse meno scontate.

Peccato che tra i molti esempi presentati pochi siano dedicati alla pagina del carrello, visto che logicamente è strettamente e strategicamente correlata al processo di checkout ed è forse la più importante dell’intero processo.

Interessante invece l’inclusione in appendice di 4 pagine di una checklist pronta da stampare.

Il report costa 78 dollari.

Il secondo studio che vi voglio presentare è E-commerce User Experience, vol. 4: Shopping Cart, Checkout and Registration realizzato da Amy Schade e Jakob Nielsen per il Nielsen Norman Group (e, quindi, non c’è bisogno di molte presentazioni). Il report fa parte di una serie di altri 13 report dedicati all’e-commerce, ma è comunque acquistabile singolarmente per 98 dollari.

E si tratta comunque di soldi ben spesi, perché gli autori non lesinano linee guida e esempi, tanto che il report di estende per più di 300 pagine ricche di screenshot, tabelle di approfondimento e best practices.

In questo caso il report nasce da una versione precedente del 2000 (di cui sono rimaste alcune linee guida) a cui sono stati aggiunti in questa nuova versione i risultati di user testing e eye tracking di utenti in più città europee, americane e asiatiche.

Rispetto al report del Baymard Institute, quello del Nielsen Norman Group risulta più approfondito e quindi richiede sicuramente un certo impegno per essere studiato in tutte le sue parti anche perché spesso le indicazioni più interessanti non stanno tanto nella linea guida in sé, ma nei dettagli presentati nel testo.

Non si può comunque definire un report noioso da leggere, visto che gli autori citano spesso le espressioni degli utenti sottoposti al test (giusto per fare un esempio: “That’s really a pain in the ass”).

Quale dei due report acquistare? Se non vi spaventa studiare più di 300 pagine, il report del Nielsen Norman group è sicuramente approfondito e dettagliato, ma se vi interessa un report comunque ricco di esempi, e con una comoda checklist pronta da stampare ed applicare, il report del del Baymard Institute rappresenta un’ottima alternativa, che vi permette anche di risparmiare qualche dollaro.

Nulla di nuovo o che non avessi mai provato, ma che avevo abbandonato troppo frettolosamente ritenendola una pratica poco professionale.

Mi hanno aiutato a cambiare idea due letture: Paper Prototyping di Carolyn Snyder e il più recente Prototyping scritto da Todd Zaki Warfel per i tipi di Rosenfeld Media. Entrambi i testi forniscono ottimi suggerimenti su come realizzare prototipi con la carta e il libro di Carolyn Snyder arriva anche a spiegare come utilizzare questi prototipi in veri e proprie sessioni di test di usabilità con gli utenti.

Non mi spingo quasi mai, con la carta, fino alla fase di creazione dei prototipi. La carta mi aiuta a fissare sottoforma di bozzetti (sketch) diverse idee di interfaccia e interazione che possono poi essere valutate, scartate, scelte insieme al team UX. Si tratta quindi di un approccio quantitativo, che mira a produrre in tempi molto brevi diversi bozzetti che possano poi essere analizzati dal team e soprattutto criticati senza la paura di aver mandato all’aria ore o giorni di lavoro. Ogni bozzetto non dovrebbe richiedere più di mezz’ora per la stesura.

Trovo l’uso della carta efficace anche lavorando con team remoti: basta uno scanner e in pochi minuti il bozzetto è condivisibile con il resto del mondo.

Normalmente non uso un foglio di carta bianca, ma mi faccio aiutare stampando dei semplici template che includono l’interfaccia del browser e qualche guida di supporto (per esempio le risoluzione più diffuse). In internet è possibile trovarne decine: personalmente mi trovo molto bene con il lavoro svolto da UIStencil (il template è disponibile in formato PDF).

I diversi bozzetti sono poi criticati insieme al resto del team UX, solitamente fissandoli a una parete o a una lavagna.

Zaki Warfel in Prototyping riassume bene come dovrebbe svolgersi questo processo.

Si tratta, come è facile vedere nello schema, di un processo iterativo.

Lo sketching (creazione dei bozzetti) è la parte generativa del processo, il cui obiettivo è proporre diverse idee senza prestare attenzione ai dettagli o alle inconsistenze (fast and furious).

Lo scopo della critica dei bozzetti è quello di trovare, tra le tante idee, la migliore. Chi ha realizzato il bozzetto ne elenca i punti di forza, i colleghi del team UX evidenziano lacune e richiedono approfondimenti. Questa fase dovrebbe durare pochi minuti, perché il dettaglio della proposta avviene nella fase di creazione dei prototipi vera e propria.

A questo punto, cioè per la creazione dei prototipi e per i testi di usabilità con gli utenti abbandono la carta. Preferisco infatti farmi aiutare da strumenti che permettano di simulare un po’ più nel dettaglio le transizioni tipiche di una pagina web, come le interazioni Ajax. In questo senso il mio strumento preferito è Axure RP: costoso, ma che permette di realizzare veri e propri prototipi piuttosto che wireframe, sui quali la carta vince ancora.

Interventi correlati

• Ancora su bozzetti di carta e prototipi
  Dopo “Progettare con la carta” in cui presento il metodo che uso per creare i prototipi con l’aiuto di bozzetti di carta, sono stati pubblicati in rete alcuni articoli che approfondiscono l’argomento. The Messy Art Of UX Sketching di Smashing Magazine … Continua a leggere →...
• Progettare e sviluppare per dispositivi mobile
  Per lavoro mi sono trovato a dover studiare i principi base dello sviluppo di applicazioni per dispositivi mobili. Ma più che la tecnica, il linguaggio di programmazione, l’aspetto più complesso per chi proviene dal mondo “desktop” è sicuramente la definizione … Continua a leggere →...
• Buone pratiche per progettare i form
  Segnalo tre ottime risorse che si propongono di aiutare nella progettazione di maschere di inserimento dati (form). Operazione solo a prima vista facile e spesso sottovalutata, ma piena di insidie e trabocchetti. La prima, e sicuramente la migliore, è la … Continua a leggere →...
• L’usabilità dei progetti opensource
  I progetti opensource soffrono di problemi di usabilità. E non è coinvolgendo l'utente finale, come fa il team di Wordpress, che la situazione migliorerà. Continua a leggere →...
• Progettare applicazioni mobile
  Non si ferma la pubblicazione nel blog Internet della BBC, già tema di un mio precedente intervento, di articoli che spiegano nel dettaglio il processo di progettazione di siti e servizi. Questa volta tocca all’applicazione iPhone del player che permette … Continua a leggere →...

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.

Non ho nessuna intenzione di andare a Smau (ho fortunatamente di meglio da fare) e non ho neppure richiesto alcun aggiornamento via email. Ho commesso però la leggerezza di presenziare un paio di anni fa e, da quando sono finito nel loro database, non riesco più a uscirne. Che sia Smau a Milano, Smau Business a Padova o Smau e-Academy è un continuo invio.

La pubblicità di Smau fa il verso alle scarse competenze di alcuni operatori informatici – cose del tipo “Il server è collassato”, “Oh, cielo, si è fatto male?”, tanto per intenderci –  ma mi sembra che neppure loro dimostrino tutta questa professionalità con degli invii selvaggi alla stregua del peggiore spam.

Avessero fatto le cose come si deve, in fondo a ogni email ci sarebbe almeno un link per togliere la propria iscrizione. Ma non c’è.

Ho provato a effettuare un login nel sito, ma non si capisce dove si trovino le newsletter. Come se non bastasse, uno degli indirizzi di posta a cui ricevo comunicazioni sembra non essere abilitato.

Potrei creare un filtro di posta, ma è una questione di principio.

Stamattina ho allora telefonato alla segreteria Smau (02 283131) per capire come procedere. La signora che ha risposto non ha capito neppure di cosa parlassi, ma alla fine mi ha passato una collega.  Questa, un po’ spaesata, mi ha suggerito di inviare un’email a un’altra collega. Avvertendomi però che in questo momento è in fiera (“sa com’è”) e che – probabilmente tra 4/5 giorni – darà un’occhiata alla mia email.

Da almeno 10 anni Smau non ha più ragione di esistere, se poi le competenze messe in campo sono queste…

Ecco cosa ho scritto: attendo fiducioso (?) una risposta:

From: "Antonio Volpon"
To: nadia.mazzola@smau.it
Subject: Cancellazione mailing SMAU
Buongiorno.
Da qualche settimana ricevo ogni giorno diverse email non desiderate
da Smau, in particolare dall'indirizzo noreply@smau.it  verso i miei
indirizzi
antonio@volpon.com
scoazze@volpon.com
Poiché nel corpo del messaggio non è presente alcun link per
rimuovermi dalla lista di invio, mi sono recato nella homepage del
sito Smau.
Ho quindi provato a autenticarmi per capire se avrei potuto procedere
da lì alla rimozione, ma non sembra possibile.
L'indirizzo scoazze@volpon.com non viene inoltre riconosciuto come utente
valido, quindi non posso procedere.
Ho quindi telefonato al numero presente in fondo alla email e dopo
qualche passaggio di telefonate mi è stato comunicato il suo indirizzo
di posta.
Vorrei cortesemente sapere se potete procedere al più presto alla
cancellazione dei sopracitati indirizzi di posta dal vostro mailing.
In attesa di un riscontro saluto cordialmente,
Antonio Volpon

Interventi correlati

• Una newsletter è per sempre
  Spesso le newsletter sono progettate in fretta, senza verifiche prima dell'invio. Ma i destinatati non perdonano, e annullano l'iscrizione. Continua a leggere →...

Fino a qualche anno fa potevamo giustificare le lacune in ambito di usabilità e più in generale di user experience del software opensource. Erano progetti nati grazie a team focalizzati sulla progettazione e stesura di codice e usati da una ristretta minoranza di early adopters.

Le aspettative oggi sono diverse. Alcuni prodotti, come Open Office e WordPress, si rivolgono a un pubblico variegato, grazie anche a procedure di installazione semplificate e, nel caso di prodotti web, a metodi di fruizione ASP.

In questo contesto le problematiche tecniche, seppur importanti, passano in secondo piano. Il software deve essere facile da utilizzare, ma ancora di più deve proporre interfacce coerenti. Risultati che non si raggiungono per caso o con un po’ di buon senso, ma con l’introduzione di specifiche competenze professionali. Competenze che difficilmente si prendono in prestito.

Mi stupisce perciò l’iniziativa del team di WordPress che apre due questionari pubblici su questioni legate alla nuova interfaccia di amministrazione:

• l’attuale interfaccia è il risultato di una già recente riprogettazione che ha richiesto agli utenti un nuovo approccio all’uso del software. Frequenti variazioni, per quanto si propongano di migliorare il lavoro di tutti, sono destabilizzanti;
• ridurre la progettazione di una interfaccia grafica a un questionario sminuisce l’importanza e il ruolo di questa disciplina, anche quando gran parte delle decisioni sembrano prese;
• il questionario si prefigge di raccogliere 5000 risposte. Ma il design di interfaccia non è un approccio democratico, quanto una disciplina che si prefigge di capire quale è la soluzione migliore per il pubblico di riferimento. Sono convinto che la maggior parte dei partecipanti al sondaggio sono sviluppatori, non necessariamente il target principale a cui si rivolge WordPress.

Ho avuto modo di provare per qualche minuto una versione, sicuramente non definitiva, della futura amministrazione di WordPress e ne sono rimasto sconcertato, soprattutto nel notare che quasi ogni azione richiede, diversamente dall’attuale, un primo click per aprire il menù e un secondo per selezionare la voce voluta. Le premesse non mi sembrano delle migliori.

Qualcosa comunque sembra muoversi nel verso giusto, anche se a un maggiore livello di astrazione. Il team di Mozilla promuove Concept Series, un insieme di idee, wireframe e prototipi a partecipazione pubblica per definire la visione dei futuri prodotti opensource. Nulla a che vedere con l’usabilità, ma qualcosa che potrebbe aiutare a raccogliere attorno ai progetti opensource una comunità con competenze non solo tecniche, ma anche di design e di user experience.

Aggiornamento serale: il blog di WordPress presenta una prima versione dei wireframe realizzati per progettare la nuova interfaccia di amministrazione. Visto che non è facile trovare in rete documenti che riportano wireframe completi e documentati, vale sicuramente la pena darci un occhio.

Interventi correlati

• L’usabilità degli URL
  Il sistema di protezione dallo spam di WordPress si chiama Akismet. Un nome un po’ infelice, difficile da ricordare e, per un italiano almeno, anche da scrivere. Se ne devono essere accorti anche quelli di WordPress, perché il sito è … Continua a leggere →...
• WordPress 2.3 l’ho sviluppato anche io
  Il bello del software opensource è che chiunque, a vario titolo, può contribuirne alla creazione, allo sviluppo, al test o alla diffusione. Il bello del software opensource è anche che, a fronte di un problema, è molto probabile trovare in … Continua a leggere →...
• Aspettando WordPress 2.3
  Il 24 Settembre è previsto il rilascio della versione 2.3 di WordPress che dovrebbe come al solito contenere importanti novità, tra cui l’inclusione nel pacchetto standard delle funzionalità di tagging (che fino a oggi richiedevano l’uso di plugin, come per … Continua a leggere →...
• Fucinaweb come Jeffrey Zeldman
  No, guai paragonarsi a quello che a ragione (o, come penso io, a torto) è considerato uno dei migliori designer web di questi anni. Ma su una cosa sono d’accordo con lui, cioè i motivi che hanno spinto Jeffrey Zeldman … Continua a leggere →...
• Compatibilità plugin e WordPress 2.3
  Visti i numerosi interventi che sto dedicando in questi giorni a WordPress 2.3, non è difficile capire che mi stia attrezzando per la migrazione di Fucinaweb. Avevo addirittura pensato di uscire con il nuovo volto di Fucinaweb già usando una … Continua a leggere →...

La causa è stata il carico dei server oppure qualcosa che non ha funzionato nel software di verifica del sito. Sarebbe bene che situazioni come questa non accadessero mai, ma sono convinto che per quanti test vengano compiuti, la realtà sia sempre più complessa.

Mi lascia però perplesso la superficialità con cui spesso vengono gestite le condizioni di errore. Il messaggio restituito a video era:

Non posso completare la richiesta ITunes Store. Si è verificato un errore sconosciuto (-9838).

Una risposta come questa è inaccettabile, perché

• non permette all’utente di capire se il problema è nell’Iphone o nel processo di attivazione
• non indica se si tratti di un problema momentaneo (il server è troppo carico) o permanente
• è inutile sotto ogni punto di vista (sconosciuto? -9838 ?)

Interventi correlati

• Risparmiare sui messaggi di errore
  L’intervento di Jared Spool su User Interface Engineering sottolinea, se ancora ce ne fosse bisogno, la necessità di progettare form che siano (realmente) usabili. E’ frequente trovarsi di fronte a form, come quello riportato da Spool, in cui sia possibile … Continua a leggere →...