In questa nuova serie, affrontiamo il tema della User eXperience con un taglio molto pratico. Attraverso il framework MEAN.io, creeremo un piccolo prototipo di servizio e lo sottoporremo a test per valutarne aspetti importanti della UX. Nel primo articolo presentiamo la problematica e diamo un’occhiata a MEAN.io, un utile framework full stack per lo sviluppo in JavaScript.
Introduzione
Iniziamo oggi una serie di articoli con la quale voglio accompagnarvi nella creazione di un piccolo prototipo di un fantomatico servizio, con il quale poter effettuare test e misurare importanti aspetti della User Experience.
Dal momento che utilizzeremo come base un diffuso framework JavaScript full stack, MEAN.io [1], una minima manualità nello scrivere codice JavaScript e HTML sarà necessaria.
Vedremo insieme quanto la capacità di saper scrivere codice, anche per operazioni triviali, possa migliorare di gran lunga la qualità del nostro lavoro e come la buona pratica di testare possa essere adottata indifferentemente da sviluppatori e designer con ottimi risultati.
Perche’ prototipare?
Perche’ lo sviluppatore non è l’utente, il cliente non è l’utente e il designer non è l’utente. Nessuno di noi è un campione significativo per rappresentare l’utente e l’errore più grave che possiamo commettere come progettisti è quello di trincerarci dietro a un “io lo userei”.
Prototipare e testare ci permettono di raccogliere dati reali, sui quale prendere decisioni che non siano guidate da assunti o preferenze personali.
Non importa quale mezzo scegliamo per creare i nostri prototipi: carta, Illustrator, Powerpoint/Keynote, Balsamiq, Axure… abbiamo oggi sul mercato una pletora di strumenti incredibili per produrre prototipi di ogni grado e fedeltà che meriterebbero, da soli, un articolo a parte… ma questi sono “solo” strumenti e gli strumenti sono esclusivamente il mezzo per raggiungere il fine, ossia mettere alla prova, confermare, rafforzare l’idea.
Se prototipiamo senza testare, anche a livello di mockup, per farci ad esempio validare un progetto, allora “lo stiamo facendo male”, ossia ne stiamo perdendo di vista il valore.
La protipazione deve essere a uso degli utenti, non degli stakeholder: dobbiamo cercare risposte, conoscere se il “sistema”, inteso come insieme delle funzionalità, è valido; dobbiamo sapere se stiamo fornendo i contenuti corretti, se la “storia” che vogliamo raccontare con il nostro servizio è intrigante, coinvolgente e ha un senso.
I prototipi possono essere inseriti in due grandi categorie: prototipi valutativi e esplorativi.
Prototipo valutativo
È la tipologia di prototipo più comune e conosciuta: l’idea del servizio è già assodata, il tipo di interazione pianificato e tutti gli step che determinano il “journey” dell’utente sono definiti in maniera più o meno dettagliata.
Il prototipo valutativo serve per rafforzare le assunzioni che sono state enunciate in fase di progetto e il grado di fedeltà, quantomeno alto, ci permette di testare le differenti configurazioni per raffinare la nostra proposta verso l’utente finale.
Siamo interessati a capire come le persone interagiranno con il nostro prodotto/servizio, come possiamo migliorare la loro esperienza e abbiamo la necessità di comprendere se ci siamo “scordati” dettagli importanti che possano avere un forte impatto positivo sull’utilizzo.
Prototipo esplorativo
Viene utilizzato quando non si hanno certezze sulle reali necessità degli utenti: non sappiamo come e se quello che andiamo a costruire verrà accettato dal mercato, non siamo certi che vi sia una reale necessità che ne spinga viralmente l’adozione e/o non siamo nemmeno sicuri che la nicchia di mercato che desideriamo colpire sia, effettivamente, la nicchia corretta e più profittevole
Lo scopo di questo tipo di prototipi è quello di raccogliere informazioni in grande quantità di qualsiasi tipo, in maniera tale da ridurre i gradi di incertezza in cui ci muoviamo e renderci capaci di prendere decisioni non legate esclusivamente all’intuizione o alla fede. Un prototipo esplorativo deve essere in grado di suggerire agli utenti l’idea presente dietro al servizio che vogliamo proporre, ma senza quella definizione e quella precisione che potrebbe sembrare immutabile.
Qual e’ il rischio? Un abbandono immediato da parte dell’utente che, avendo difficoltà a comprendere il servizio e sentendosi vincolato dalla sua specificità, non è in grado di costruirsi “modalità di impiego” alternative rispetto a quelli per cui il sistema è stato originariamente pensato.
Questi usi alternativi rappresentano le reali occasioni vitali di sopravvivenza e di successo per il nostro servizio: Twitter ad esempio fu ideato sul modello delle short conversation dei tassisti, una modalità di comunicazione “1 a molti” dove “molti” era rappresentato da una cerchia di collaboratori. Nella formulazione originale, “idea of an individual using an SMS service to communicate with a small group”, Twitter era in principio molto più simile a quello che poi oggi è diventato What’sApp.
Figura 1 – Evan Williams, uno dei fondatori di Twitter
L’esempio di Twitter
Ecco cosa diceva nel 2013 Evan Williams a proposito di Twitter: “Con Twitter, non era chiarissimo di cosa si trattasse. Chi lo definiva ‘social network’, chi lo definiva ‘piattaforma di microblogging’, ma era difficile da definire, poiche’ non aveva sostituito qualcos’altro. C’era però questo percorso di scoperta per cui, con il tempo, si scopre ciò che effettivamente è. A guardar bene, Twitter è cambiato rispetto a quello che noi pensavamo fosse all’inizio, quando lo descrivevamo in termini di aggiornamenti di stato e strumento ‘social’. È questo, in parte, ma l’analisi a cui siamo giunti alla fine è che Twitter fosse più una specie di ‘rete di informazione’ che non una ‘rete sociale’ in senso stretto.”
Oggi Twitter è un singolare strumento di comunicazione sociale difficilmente classificabile in una categoria precisa, ma che deve il suo successo alla flessibilità con la quale può essere declinato a diverse esigenze.
Un prototipo esplorativo deve avere dei costi di implementazione bassissimi puntando sul numero di tentativi più che sulla qualità finale del prototipo. Molto spesso si utilizzano addirittura dei pretotipi.
Pretotipi vs prototipi
Non tutti hanno familiarità con il termine pretotipo e soprattutto con l’approccio metodologico che esso rappresenta. Il termine pretotipo (“pretotype”, “pretend to have a prototype“) e la metodologia del pretotipare (pretotyping) indicano una modalità veloce e poco dispendiosa di testare le idee, creando una versione del prodotto e del servizio che aiutino a validare la teoria del “If we build it, they will use it” [2] (“se lo costruiamo allora lo useranno”).
La teoria di base è stata sviluppata da Alberto Savoia [3], Engineering Director e Innovation Agitator in Google dal 2008 al 2012, cercando di trovare una spiegazione al fatto che la maggior parte dei prodotti sul mercato fallivano non perche’ fossero costruiti o commercializzati male, ma perche’ semplicemente non erano “giusti”.
L’idea di base di un pretotipo è quella di validare l’idea di prodotto ancor prima di investire tempo e denaro nel costruire realmente un prototipo. Questa metodologia è assolutamente assimilabile al concetto di Minimum Viable Product espressa da Eric Ries nel suo movimento Lean Startup [4].
Vediamo alcune domande che ci si pongono nel pretotyping:
- le persone saranno interessate?
- le persone lo useranno come è stato progettato?
- le persone continueranno a usarlo?
- saranno disposte a pagare?
Ed ecco invece gli interrogativi che ci si pongono nella prototipazione:
- lo possiamo costruire?
- funzionerà come previsto?
- quanto spenderemo per costruirlo?
- in quanto tempo possiamo costruirlo?
Uno degli esempi classici di “pretotipo” che viene spesso rammentato è quello alla base della creazione del Palm Pilot, uno dei primi dispositivi portatili, di cui si narra che l’inventore, Jeff Hawkins, avesse realizzato inizialmente un modello in legno, solo per rendersi conto, durante la giornata, di quando e quanto avrebbe potuto utilizzare un dispositivo del genere [5].
Figura 2 – Esempio storico di pretotyping: Palm Pilot ad opera di Jeff Hawkins.
Ma ci sono anche esempi molto più recenti, come il caso dei Google Glass [6].
Figura 3 – Un esempio più recente: Tom Chi illustra la prototipazione rapida dei Google Glass.
Let’s rock: cosa andremo a prototipare?
Nella nostra serie, andremo a protipare e testare un’applicazione che ho chiamato EinkaufsListe (in tedesco, “lista della spesa”).
L’applicazione, la lista della spesa appunto, è tecnicamente abbastanza semplice, ma è inserita in un contesto abbastanza particolare: pensate a una lista della spesa che non compilate voi, ma che compila il vostro partner, la ragazza o la mamma.
Perche’ EinkaufsListe?
Dal punto di vista percettivo non è una semplice lista, ma una lista di “ordini” e di comandi, da cui il perentorio nome tedesco: volevo qualcosa che ricordasse l’autorità, l’enfasi del dogma. In breve, le cose che devo fare/comprare ordinate da mia moglie.
Andremo a protipare un’idea che è stata sviluppata a tavolino, senza dati reali: vogliamo capire come rapportarci con i nostri utenti, esplorare se vi siano informazioni o dati importanti da raccogliere per migliorare lo scopo del nostro servizio e anche la sua user experience. Come dicevamo sopra, vogliamo costruire un prototipo esplorativo.
Be MEAN!
Come anticipato, andremo a costruire un prototipo esplorativo utilizzando un framework full stack chiamato MEAN.io [7], dove MEAN non è altro che l’acronimo ottenuto con l’iniziale delle tecnologie che lo compongono:
- MongoDB, un database NOSQL document oriented che gestisce nativamente strutture JSON like;
- Express.JS, un framework minimal per costruire web application su piattaforma Node.JS;
- Angular.JS, un framework JavaScript frontend per lo sviluppo di single page application, mantenuto da Google e caratterizzato da una forte struttura MVC;
- Node.JS, piattaforma di sviluppo software per la creazione di applicazioni scalabili che utilizza JavaScript come linguaggio di programmazione.
Le caratteristiche di MEAN.io
Andiamo con ordine: perche’ MEAN?
Angular.JS è un framework frontend totalmente crossplatform che può essere utilizzato con diversi tipi di backend e diversi linguaggi, Ruby, Python, PHP.
Alla stessa maniera MongoDB, è un database totalmente crossplatform e anch’esso può essere accompagnato da una varietà di linguaggi e piattaforme.
Express.JS è un framework che introduce in ambiente Node.JS tutte quelle facility di scaffolding e gestione di rotte che negli altri linguaggi ci permettono di creare applicazioni CRUD based con una velocità e semplicità disarmante.
La verità è che tutte queste tecnologie, lavorano estremamente bene insieme, talmente bene che il numero di applicazioni basate sullo stack MEAN (MongoDB, Express.JS, Angular.JS, Node.JS) è aumentato vertiginosamente. MEAN.io non è altro che un boilerplate, ossia uno scheletro di applicazione MEAN based già pronta e configurata per poter essere utilizzata come punto di inizio per il nostro prototipo.
La velocità nella prototipazione è essenziale, perche’ perdere poco tempo sul singolo prototipo ci permette di produrne una quantità maggiore. La confidenza nel poter sperimentare ci deve essere data dagli strumenti che utilizziamo; in questo caso, muovendoci in un ambiente totalmente “JavaScript based”, non dobbiamo fare uno switch di contesto fra front-end e back-end development con diversi linguaggi. Il vantaggio di usare tecnologie moderne, inoltre, ci permette di usufruire degli hosting in cloud, ad esempio Heroku, che ci offrono gratuitamente anche il protocollo SSL, conditio sine qua non per poter impacchettare la nostra applicazione prototipo in una app Facebook.
Primi passi con MEAN.io
La prima cosa da fare è assicurarsi di avere Node.js installato: a seconda della piattaforma che si desidera usare è sufficiente seguire l’installazione presente sul sito ufficiale [8].
Installare Node.js
Se si utilizza Windows, sul sito è disponibile un comodo installer; c’è un pkg per utenti Linux based che possono, se lo desiderano, effettuare il build di Node dai sorgenti; per utenti MacOS, è sì presente un installer, ma è consigliabile utilizzare un package manager come Homebrew [9]. Per installare Homebrew da un terminale, il comando è il seguente:
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
Una volta conclusa questa procedura, l’installazione di Node.js sarà semplice quanto digitare:
brew install node
Se l’installazione avviene attraverso Homebrew, il path di installazione non sarà quello canonico, ma si troverà sotto la directory di lavoro di Homebrew:
/usr/local/Cellar/node/
La maggior parte dei problemi di installazione via brew è dovuta a installazioni o configurazioni pregresse; è sufficiente quindi assicurarsi che tutti i symlink puntino al path corretto.
Figura 4 – Verifichiamo che node sia installato correttamente, controllandone la versione.
L’installazione di Node comprende anche NPM, un package manager molto completo che molti considerano “il package manager che ha portato equilibrio nella forza”, ossia uno strumento che ha portato un po’ di ordine nell’universo caotico dello sviluppo JavaScript.
Installare MEAN.io
Abusiamo del nostro superpotere acquisito, per installare il framework MEAN, comodamente già disponibile come package NPM:
sudo npm install -g meanio
Installiamo con il parametro -g (global) perche’ il package di MEAN include un comodo comando shell mean che ci permette di fare lo scaffolding della nostra applicazione e vogliamo che questa utility sia disponibile a livello globale.
Non ci resta quindi che creare la struttura base di una applicazione MEAN, usando il comando
mean init
In questo caso vogliamo creare il nostro progetto EinkaufsListe:
mean init EinkaufsListe
Aspettiamo che MEAN cloni da github il boilerplate standard di progetto ed entriamo nella cartella di progetto. Possiamo procedere con un npm install.
cd EinkaufsListe && npm install
Figura 5 – La directory di progetto.
Che cosa è successo?
NPM ha letto il file di configurazione package.json, nel quale sono dichiarati in testa i metadati di progetto e in coda le dipendenze richieste. Ha quindi cercato i package nel repository di NPM e ha scaricato tutti i moduli necessari nella sottocartella node-modules.
Figura 6 – Package.json.
Modificate pure i metadati di progetto liberamente, ma ricordatevi che, se devono essere fatte variazioni alla lista di package, dovrete procedere nuovamente a un npm install, per la corretta installazione e la rimozione delle nuove dipendenze.
Questo sistema ci permette di ridistribuire il progetto senza il peso della cartella node-modules: sarà poi compito della macchina target scaricarsi tutte le dipendenze.
Bower e Grunt
Fra le dipendenze scaricate, ci sono due strumenti molto utili, Bower e Grunt.
Bower [10] è l’equivalente di NPM, ma per la parte frontend. Non lasciatevi ingannare dal fatto che usiamo JavaScript sia frontend che backend: le due parti sono e saranno ben distinte.
Bower ci permette di dichiarare le librerie JavaScript che vogliamo utilizzare localmente, nel file bower.json sotto forma di dipendenze. Richiamando Bower direttamente o attraverso un task manager, possiamo recuperarle nella versione desiderata in un path preciso.
FIgura 7 – File Bower.json.
Grunt [11] è il task manager o task runner che dir si voglia che farà da collante a tutti i singoli pezzi. Grunt non è l’unico task runner nell’ecosistema JavaScript: esistono dversi competitor, tra cui Gulp [12] che applicano filosofie leggermenti differenti; tuttavia tutti permettono di eseguire task, ossia automatizzare una serie di azioni per poter andare in test o in produzione senza grossi grattacapi.
Le tipologie di task sono veramente svariate:
- possono fare un jslint dei codici JavaScript;
- preprocessare i sass/less/stylus e creare i rispettivi CSS;
- concatenare CSS e JS;
- minificare;
- scalare la risoluzione delle risorse grafice per l’ambiente mobile;
- spostare file in certe directory a seconda dell’ambiente;
- lanciare la suite di test;
- …
I task di grunt sono essenzialmente concatenazioni di singoli subtask o azioni, possono essere invocati in maniera sequenziale e sono dichiarati nel file di configurazione gruntfile.js.
Figura 8 – Gruntfile.js, il file di configurazione.
Prendiamo ad esempio il task di default:
- controlla se la variabile d’ambiente NODE_ENV è settata a production;
- esegue un subtask di jshint;
- esegue un subtask di csshint;
- se siamo in produzione minifica con uglify;
- esegue un subtask concurrent che a sua volta esegue nodemon e watch.
Concettualmente è semplice, se siete già abituati a usare altri task runner come, ad esempio, maven o ant.
È giunta l’ora di dare uno spin a grunt e vedere finalmente MEAN all’opera. Apriamo una shell nella directory di lavoro del progetto e invochiamo grunt, senza parametri dal momento che il task di default ci è sufficiente:
grunt
Figura 9 – Mh… che succede?
Installare MongoDB
Vi ricordate per cosa sta la M in MEAN? Esatto: MongoDB. A modo suo, Node.js vi sta dicendo che non riesce a connettersi al DB.
Prima di poter avviare il demone di MongoDB, dobbiamo installarlo sulla nostra macchina. Andiamo sul sito ufficiale [13] e seguiamo la procedura di installazione per la nostra piattaforma. Se siamo su Mac OS e abbiamo seguito la procedura iniziale usando Homebrew, sarà sufficiente lanciare:
brew install mongodb
Una volta che il DB è stato correttamente installato, è sufficiente aprire in una shell pulita il processo di Mongo:
mongod
Figura 10 – MongoDB pronto a ricevere connessioni.
Se tutto va bene Il DB andrà up e sarà pronto a ricevere connessioni. Pensate a mongod come un server MongoDB locale: il demone deve essere lasciato in esecuzione per poter utilizzare il database.
Per testare che l’installazione sia andata a buon fine sarà sufficiente aprire un altro terminale e provare il database con il comando mongo test. Tutto ok?
Torniamo alla shell del progetto e lanciamo finalmente grunt.
Figura 11 – Node up and ready.
Per assicurarsi che tutto sia in esecuzione apriamo il browser e andiamo a vedere localhost:3000.
Figura 12 – Yay! Ce l’abbiamo fatta!
Conclusioni
In questo primo articolo della serie abbiamo brevemente introdotto il concetto di prototipazione di un prodotto o servizio, parlando anche delle pratiche definite pretotyping che arrivano ancora prima della prototipazione. Abbiamo messo in luce la differenza che c’è fra un prototivo valutativo e uno esplorativo.
Successivamente abbiamo spiegato come installare e configurare MEAN.io, un framework full stack che permette di realizzare in JavaScript semplici prototipi di servizi. In questo modo, al termine dell’articolo, abbiamo tutti gli strumenti pronti per poter cominciare.
Nel prossimo articolo cominceremo a pianificare e a creare le viste della nostra applicazione prendendo piena familarità con il framework MEAN.io.
Riferimenti
[1] La pagina del framework MEAN.io
[2] Pretotyping
[3] La genesi del concetto di “pretotipo”
http://www.pretotypelabs.com/who-we-are.html
[4] Lean Startup
[5] La storia del pretotipo del Palm Pilot
http://pretotyping.blogspot.it/2010/08/one-of-my-favorite-pretotype-stories.html
[6] Un video che riassume la prototipazione rapida dei Google Glass
https://www.youtube.com/watch?v=d5_h1VuwD6g
[7] MEAN.io, il framework JavaScript per la prototipazione
[8] Node.js
[9] Homebrew, package manager
[10] Bower, package manager
[11] Grunt, the JavaScript task runner
[12] Gulp.js
[13] MongoDB, database noSQL