CROWDSOURCING MOBILE: UNA VALUTAZIONE SPERIMENTALE

Transcript

1 UNIVERSITÀ DEGLI STUDI DI UDINE Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Magistrale in Comunicazione multimediale e tecnologie dell informazione Tesi di Laurea CROWDSOURCING MOBILE: UNA VALUTAZIONE SPERIMENTALE Relatore: Prof. STEFANO MIZZARO Laureando: EDDY MADDALENA ANNO ACCADEMICO

2

3 It finally happened (Freddie Mercury, I m Going Slightly Mad, 1991)

4

5 Indice 1 Introduzione Obiettivi della tesi Struttura della tesi Crowdsourcing Un nuovo modello di business Nascita e difficoltà nel trovare una definizione formale Il finanziamento collettivo La creazione collettiva La votazione collettiva James Surowiecki e la saggezza delle folle Critiche al crowdsourcing Problemi aperti Negoziazione del prezzo Onestà dei worker Controllo delle prestazioni Crowdsourcing su web Wikipedia Amazon Mechanical Turk Captcha e recaptcha Conclusioni Obbiettivi Motivazioni dello studio L obbiettivo generale Obbiettivo 1: Analisi delle piattaforme di crowdsourcing esistenti Obbiettivo 2: Quali piattaforme sono adatte a dispositivi mobili? Obbiettivo 3: Quali tipologie di task sono adatte a dispositivi mobili? v

6 vi INDICE 3.3 Conclusioni Piattaforme e Task Piattaforme Piattaforme esistenti Criteri di scelta Le piattaforme scelte Task Conclusioni Esperimento Uno: Predittivo Introduzione La scelta dei task Disegno sperimentale I gruppi sperimentali Infrastruttura Attività preliminari Risultati Risultati preliminari Risultati numerici Analisi Conclusioni Esperimento Due: Operativo Introduzione Categorie di task Categorization Moderation of an Image Sentiment Tagging of an Image Transcription from an Image Writing I task Categorization Moderation of an Image Sentiment Tagging of an Image Transcription from an Image Writing Gruppi sperimentali L infrastruttura

7 INDICE vii 6.6 I layout Attività preliminari Risultati Risultati preliminari Risultati numerici Analisi Conclusioni Conclusioni e sviluppi futuri Conclusioni Sviluppi futuri Apprendimento automatico sui risultati Studio delle modalità di offerta dei task Crowdsourcing e CAB Riproposizione esperimenti in scenari reali Bibliografia 99

8 viii INDICE

9 Capitolo 1 Introduzione Questa tesi si colloca nell ambito del crowdsourcing, ovvero una tipologia di attività online partecipative nelle quali una persona, un organizzazione o un azienda propone ad un gruppo di individui la realizzazione libera e volontaria di un compito specifico. In particolare, ci si è occupati dei marketplace, ovvero quelle piattaforme web che offrono ricompense in denaro per lo svolgimento delle attività richieste. Attualmente tale approccio viene proposto esclusivamente ad utenti desktop. L utilizzo di tali piattaforme da dispositivi mobili comporta una serie di problematiche, spesso critiche, che ne pregiudicano usabilità e user-experiance. Questo sta diventando un vero problema anche alla luce dei trend che prevedono un sorpasso nella diffusione dei sistemi mobili rispetto a quelli desktop già nel 2014[24]. É quindi importante affrontare tale cambiamento ripensando ed estendendo le attuali piattaforme verso un comodo ed agevole utilizzo anche da dispositivi come smartphone e tablet. Con questa tesi si vuole effettuare un esplorazione delle attuali piattaforme di crowdsourcing al fine di scoprire quanto ognuna di esse si presti ad un utilizzo da mobile. Successivamente, si cerca di individuare le caratteristiche delle piattaforme e dei compiti assegnati, che risultino essere fattori di successo o di fallimento nelle risoluzioni da mobile. In questo capitolo vengono illustrati gli obiettivi (paragrafo 1.1) e la struttura della tesi (paragrafo 1.2). 1.1 Obiettivi della tesi Il lavoro di tesi consiste in una valutazione sperimentale dell efficacia del crowdsourcing effettuato da dispositivi mobili. Nel fare questo si è deciso di perseguire tre obbiettivi: 1

10 2 Introduzione analizzare le piattaforme di crowdsourcing esistenti; individuare quali piattaforme siano più adatte a dispositivi mobili; scoprire quali tipologie di task siano più adatte a dispositivi mobili. Il raggiungimento di tali obbiettivi permetterebbe di fare luce sulla possibilità concreta di estendere il mondo del crowdsourcing con le peculiarità esclusive dei dispositivi mobili come la portabilità, il dinamismo e le informazioni rilevate dai vari sensori. Così facendo, non solo si aumenterebbe il numero di utenti disponibili, ma sarebbe plausibile immaginare un estensione della gamma delle tipologie di task offerte. 1.2 Struttura della tesi La parte iniziale della tesi presenta le nozioni generali, fondamentali per la comprensione del lavoro svolto. Successivamente vengono presentati gli obbiettivi e le motivazioni che ci si è posti. Viene poi discusso di come si è operato nel cercare di soddisfare tali obbiettivi attraverso due esperimenti con volontari. Di seguito viene descritta la suddivisione di tali argomenti in capitoli: Il capitolo 2 è prettamente introduttivo; vengono discussi i concetti base, lo stato dell arte e l attuale diffusione del crowdsourcing. Nel capitolo 3 sono presentate le motivazioni che giustificano la scelta di approfondire il crowdsourcing mobile. In seguito vengono discussi in dettaglio gli obbiettivi che si è deciso di perseguire. Nel capitolo 4 si discute dei problemi che affliggono le piattaforme di crowdsourcing esistenti. Sono presentate le quattro piattaforme su cui si è deciso di concentrarsi per l esecuzione degli esperimenti ed i criteri decisionali con i quali sono state selezionate. Successivamente, si discute della costruzione di un data-set di task attraverso un attività di data mining nelle piattaforme selezionate, effettuata da un software costruito ad hoc. Il capitolo 5 descrive il primo esperimento con volontari nel quale viene richiesto a sedici partecipanti di prevedere le difficoltà nell esecuzione di alcuni task, sia utilizzando un dispositivo desktop che uno mobile. Tali task sono suddivisi in cinque diverse sorgenti: le prime quattro sono formate da un sottoinsieme di 12 task estratti casualmente dalle categorie del data-set precedentemente creato; la quinta è formata da 12 task creati ad hoc con l intento di risultare semplici nello svolgimento da mobile. La somministrazione di tali task è stata accuratamente pensata al fine di ridurre eventuali bias. Con questo

11 1.2 Struttura della tesi 3 esperimento si vuole verificare quali tra le cinque sorgenti si prestino maggiormente al mobile. Nella parte finale del capitolo sono presentati i risultati e le relative analisi. Nel capitolo 6 viene presentato il secondo esperimento con volontari. Questo prevede l identificazione di sei categorie e la costruzione di 4 task per ognuna di esse. L esperimento prevede che ogni partecipante debba svolgere due task per ogni categoria, uno da desktop ed uno da mobile, monitorandone i risultati: questi permettono di identificare quali categorie offrano migliori risultati nello svolgimento da mobile rispetto allo svolgimento da desktop. Vengono poi presentate l infrastruttura e le scelte implementative. Infine vengono discussi i risultati sia preliminari che numerici e le relative analisi. Nel capitolo 7 sono presentate le conclusioni e gli sviluppi futuri.

12 4 Introduzione

13 Capitolo 2 Crowdsourcing Il progresso tecnologico iniziato alla fine dello scorso secolo e continuato all inizio del secolo attuale ha visto una diffusione sempre maggiore di tecnologie informatiche. Le principali conseguenze di questo fenomeno si sono potute riscontrare in un globale incremento di alfabetizzazione tecnologica. In particolare, il crescente utilizzo di sistemi connessi ad internet ha portato l avvicinamento alle nuove tecnologie da parte di un vasto numero di nuovi utenti, formato sia da tutte quelle persone che fino ad allora non si potevano collegare per motivi geografici ed infrastrutturali, sia da quella molteplicità di persone che, pur avendone l opportunità, non utilizzavano le tecnologie per motivi come pigrizia, scarsa motivazione o semplicemente la non consapevolezza dei benefici che questa avrebbe apportato. Di pari passo allo sviluppo culturale si sono riscontrati continui miglioramenti e perfezionamenti sia tecnici che funzionali, in termini sia di prestazioni dei dispositivi, sia di semplicità ed accessibilità di utilizzo degli stessi. Questo doppio processo evolutivo, tecnico e sociale, ha portato alla nascita di una serie di servizi ed opportunità sconosciuti ed inimmaginabili solamente una decina d anni fa. In pochi anni si è data la possibilità agli utenti di comunicare, collaborare, ricercare e produrre informazioni, effettuare acquisti virtuali, lavorare e svolgere altre numerose attività in modo estremamente agevole, veloce ed economico. Le tecnologie informatiche sono entrate nella quotidianità delle persone tanto da essere percepite come una grave mancanza non appena vengono meno. L evoluzione che ha coinvolto i singoli individui si è spontaneamente propagata anche alle comunità che gli stessi formano aggregandosi. Oggigiorno, qualunque organizzazione o azienda è presente attivamente o passivamente su web, potendo così beneficiare di tutti i vantaggi che questo comporta. Le organizzazioni che credono maggiormente nelle potenzialità della rete possono così decidere di farsi coinvolgere da questa tecnologia, tanto da 5

14 6 Crowdsourcing utilizzarla per molteplici scopi come il marketing, la ricerca e lo sviluppo, o la richiesta e svolgimento di semplici attività, chiamate task. Proprio per quest ultima possibilità negli ultimi anni ha visto la luce il crowdsourcing, un nuovo modo di fare impresa in modo collaborativo che sfrutta le possibilità offerte dal web per permettere ad imprese ed organizzazione di beneficiare di vantaggi unici a costi irrisori. 2.1 Un nuovo modello di business L apertura alle nuove tecnologie, incentivata dalle possibilità sempre più concrete che queste possano portare profitto, ha spinto molte organizzazioni ad investire tempo e risorse nella ricerca e nell adozione di strategie d impresa innovative. Risulta dunque fondamentale uscire da paradigmi e preconcetti che hanno caratterizzato il modo di fare mercato prima dell avvento del web e riconsiderarsi anche in funzione alle nuove possibilità che esso offre. Una delle possibili strade da adottare per cogliere tali opportunità è data dal paradigma del crowdsourcing: nato come modello di business innovativo, permette ad organizzazioni, aziende o semplici comunità di delegare parti del proprio lavoro ad una massa distribuita di persone non definita a priori. Un organizzazione che decide di adottare questa strategia intravede la possibilità di ricavare grossi benefici dall intelligenza collettiva che, a detta di molti, offre vantaggi maggiori rispetto all intelligenza dei singoli individui. Le collaborazioni tra le risorse interne ed esterne all organizzazione permettono la nascita delle Open Enterprise, cioè di quelle imprese aperte che negli ultimi anni, grazie all avvento della rete, si stanno affermando sempre più. L adozione di un simile approccio porta reali benefici qualora, internamente all impresa, risieda la consapevolezza che i vantaggi dati dall apertura verso l esterno possano essere maggiori non solamente in termini di profitto, ma anche in termini di conoscenza, di esperienza e di tutti i benefici che il lavoro collaborativo comporta. Il crowdsourcing trova terreno fertile nel web: sempre più imprese e lavoratori freelance decidono di collaborare attraverso la rete. Negli ultimi anni questo fenomeno ha portato alla nascita di siti dove agli utenti viene data la possibilità di offrire o svolgere attività di ogni genere; non tutti questi servizi offrono ricompense per il lavoro svolto. Le comunity online di persone solitamente sono formate da volontari che svolgono le loro attività in modo gratuito e senza pretendere una ricompensa, se non la propria gratificazione personale. Altri servizi invece prevedono una ricompensa che può consistere in crediti virtuali da usufruire su web fino alle ricompense in denaro.

15 2.2 Nascita e difficoltà nel trovare una definizione formale Nascita e difficoltà nel trovare una definizione formale Il termine crowdsourcing nasce nel 2006 quando Jeff Howe pubblica per la rivista Wired un articolo intitolato Rise of Crowdsourcing [1]. La parola è formata dall unione dei termini crowd (folla) e outsourcing (esternalizzazione di alcune delle proprie attività). Gli attori fondamentali del crowsourcing sono identificabili in due entità principali: i requestor (richiedenti) e i worker (risolutori) di semplici task (attività). Quello che differenzia il crowdsourcing da una normale collaborazione lavorativa è la non conoscenza da parte del richiedente dell identità della persona incaricata ad adempiere alla prestazione. Howe, nel suo articolo, tratta il tema del graduale aumento del crowdsourcing tra le organizzazioni che utilizzano le nuove tecnologie, in particolare quelle più dinamiche che sfruttano i servizi offerti dal web. La nascita spontanea dislocata e non ben collocabile nel tempo di questo fenomeno ne complica la ricerca di una definizione formale che ne descriva le caratteristiche in modo chiaro e condiviso. La definizione comunemente accettata è quella data nel 2012 da Estellés e González [6], stilata dopo aver studiato e analizzato più di quaranta definizioni esistenti: Il crowdsourcing è una tipologia di attività online partecipativa nella quale una persona, istituzione, organizzazione non a scopo di lucro o azienda propone ad un gruppo di individui, mediante un annuncio aperto e flessibile, la realizzazione libera e volontaria di un compito specifico. La realizzazione di tale compito, di complessità e modularità variabile, e nella quale il gruppo di riferimento deve partecipare apportando lavoro, denaro, conoscenze e/o esperienza, implica sempre un beneficio per entrambe le parti. L utente otterrà, in cambio della sua partecipazione, il soddisfacimento di una concreta necessità, economica, di riconoscimento sociale, di autostima, o di sviluppo di capacità personali; il crowdsourcer 1 d altro canto, otterrà e utilizzerà a proprio beneficio il contributo offerto dall utente, la cui forma dipenderà dal tipo di attività realizzata. La definizione data dai due autori non soddisfa la totalità dei punti di vista ma indubbiamente riesce a trasmettere la filosofia di pensiero del fenomeno. Nonostante tale definizione mi trovi abbastanza d accordo, preferisco pensare al crowdsourcing come un paradigma non necessariamente legato al web, ma un qualcosa di più generale, che viene legato al web perché è proprio nella rete 1 Il crowdsourcer è colui che richiede il task.

16 8 Crowdsourcing che trova l ambiente ideale per essere sfruttato al meglio. Ritengo tuttavia che un annuncio cartaceo in una bacheca pubblica, dove si richiedono informazioni rispetto un oggetto smarrito, possa essere un valido esempio di crowdsourcing in un contesto non strettamente legato ad una particolare tecnologia. Tale situazione comporta la creazione del task nella fase di scrittura del biglietto, la pubblicazione formale in una bacheca, la scelta del task da parte dei visitatori della bacheca e l eventuale adempimento del compito da parte di volontari. Howe [1] identifica quattro tipologie di crowdsourcing, analizzate nei prossimi quattro sottoparagrafi: Crowdfunding (finanziamento collettivo); Crowdcreation (creazione collettiva); Crowdvoting (votazione collettiva); Crowd wisdom (saggezza della folla) Il finanziamento collettivo Il finanziamento collettivo permette ad organizzazioni, artisti, creativi, imprenditori ed artigiani di coinvolgere quanti più possibili piccoli finanziatori nel partecipare alla nascita di nuovi progetti semplicemente offrendo un iniziale sostegno economico. Questa modalità di finanziamento, molto più diffusa all estero che in Italia, venne adottata nel 2012 anche dal noto sviluppatore di videogames statunitense Tim Schafer. Necessitando di fondi per la creazione ed il lancio di un nuovo videogioco decise di rivolgersi a Kickstarter [32], una piattaforma web per Crowdfunding dove è possibile presentare un idea di progetto e richiedere dei finanziamenti volontari. Schafer inizialmente sperava di riuscire a raccogliere dollari; ci riuscì in sole 7 ore, e già dopo 24 ore la cifra raccolta raggiunse il milione di dollari. Oggi la raccolta di Shafer può vantare una cifra che supera i 3,3 milioni di dollari, raccolti grazie al contributo di più di sostenitori. Anche la console open source Ouya [31], il cui lancio è stato previsto per aprile 2013, è frutto di una raccolta fondi avvenuta attraverso Crowdfoundig, al quale hanno partecipato oltre sostenitori per un ammontare che ad oggi supera gli 8,5 milioni di dollari.

17 2.2 Nascita e difficoltà nel trovare una definizione formale 9 Figura 2.1: Confronto tra collaborazione classica mail e collaborazione in ambiente wiki La creazione collettiva La creazione collettiva presuppone il coinvolgimento di più entità nella partecipazione ad un unico progetto. I presupposti fondamentali affinché la creazione collettiva possa avvenire con successo sono lo scambio e la centralizzazione delle informazioni. I mezzi tradizionali di scambio di informazioni come mail o sms si rivelano essere non ottimali nel supportare la condivisione di progetti ed idee all interno di un gruppo di lavoro. Per far fronte a queste lacune, negli ultimi anni sono nati nuovi strumenti che permettono una cooperazione più agevole, migliorando di gran lunga sia la soddisfazione derivata dall utilizzo sia la produttività in termini di risultato finale. I responsabili principali di questa rivoluzione sono i Wiki, ovvero delle collezioni di pagine e di documenti opportunamente condivisi tra i collaboratori. La navigazione all interno delle pagine non avviene in modo lineare. I contenuti sono ipertestuali, dunque vengono uniti semanticamente attraverso una serie di collegamenti, grazie ai quali l utilizzatore può navigare tra le pagine ed ottenere le informazioni richieste. Queste piattaforme offrono sistemi evoluti di gestione degli utenti al fine di permettere, attraverso l assegnazione di specifici privilegi, il

18 10 Crowdsourcing controllo sui contenuti delle pagine e sulle relative modifiche. I partecipanti ad un determinato lavoro in possesso di adeguati permessi possono aggiungere, visualizzare, modificare o rimuovere le relative pagine wiki. Il sistema si serve di un meccanismo di storico che tiene traccia di tutte le informazioni riguardanti le modifiche fatte dagli utenti, permettendo a chiunque di monitorare l evoluzione dei contenuti. Dall idea iniziale di wiki sono nate varianti sempre più evolute allo scopo di fornire strumenti sempre più specifici per le singole attività. Un esempio di questo tipo di strumento è Trac[29], un progetto open source atto a supportare sviluppatori software nella gestione di progetti collaborativi attraverso strumenti evoluti per l organizzazione della conoscenza e delle informazioni. La piattaforma adotta un sistema di markup semplice ed intuivo, così da consentire un agile utilizzo anche per utenti meno esperti. A differenza di un wiki tradizionale, Trac offre una serie di strumenti come la gestione di parti di lavoro dette tiket, la gestione di repository, come ad esempio SVN, oppure il controllo ed il monitoraggio degli obbiettivi di progetto. Figura 2.2: Trac in azione nella gestione di un progetto. (da [29])

19 2.2 Nascita e difficoltà nel trovare una definizione formale La votazione collettiva La votazione collettiva (crowdvoting) è un meccanismo che permette ad una folla di persone di esprimere delle preferenze rispetto una decisione finale da intraprendere. Ad esempio, in un sistema ideale di votazione collettiva, il peso del voto di ogni singolo individuo è esattamente uguale a quello di un qualsiasi altro individuo. Se questo vincolo viene rispettato, possiamo ritrovare nel crowdvoting gli stessi principi che caratterizzano una democrazia, nel senso più puro del termine. La votazione collettiva trova maggiori consensi in settori dove l opinione della massa è fondamentale. In ambito industriale, ad esempio, capita spesso che prima del lancio di un prodotto di successo avvenga una fase di analisi di mercato, dove l opinione comune della massa dei possibili futuri utilizzatori viene presa in seria considerazione, tanto da giocare un ruolo fondamentale nelle decisioni di investimenti, produzione e distribuzione del prodotto stesso. Tuttavia, abbiamo esempi molto più tangibili di crowdvoting quando andiamo in qualsiasi sito di social web. Un semplice apprezzamento ad un contenuto di un social network può essere visto come un voto, tanto che il sito potrebbe anche decidere di utilizzare i voti degli utenti per catalogare ed organizzare i contenuti, dando ai singoli voti non solo valore informativo ma anche funzionale. Esistono inoltre delle piattaforme nate allo scopo di permettere ai propri partecipanti di esprimere la propria votazione su diverse tematiche. Un esempio è la piattaforma web Popularise [30]: gli iscritti al sito possono votare alcune idee di riqualificazione di edifici in disuso di quattro città americane e di una australiana. Ad esempio, un abitante di Seattle potrebbe voler esprimere un voto (o un opinione) su come riconvertire una vecchia caserma dismessa, decidendo se adibire l edificio a museo, a pub o a qualsiasi altro scopo. L idea del sito potrebbe essere ripresa ed ampliata in un futuro che vede tutti i cittadini impegnati nella vita politica del proprio territorio, esprimendo le proprie opinioni non solo nel momento della scelta dei propri rappresentati, ma nel quotidiano in modo semplice, propositivo, collaborativo ma sopratutto democratico James Surowiecki e la saggezza delle folle La mancata definizione iniziale dell insieme delle persone atte allo svolgimento di un singolo compito trova d accordo lo scrittore e giornalista statunitense James Surowiecki. Egli nel suo libro La saggezza della folla [19] mette in discussione alcune idee socialmente diffuse e accettate. Surowiecki critica in particolar modo l opinione comune secondo cui si tende a ritenere che le decisioni riguardanti un certo tema, debbano essere prese solamente

20 12 Crowdsourcing Figura 2.3: Gli abitanti di Seattle possono decidere su nove idee di possibili riqualificazioni di una caserma dismessa dei vigili del fuoco. (da [30])

21 2.2 Nascita e difficoltà nel trovare una definizione formale 13 da esperti di quel tema per minimizzare le probabilità che queste si rivelino sbagliate. L autore assume una posizione diametralmente opposta rispetto al pensiero comune, tanto da ritenere che in molte situazioni il parere di una folla di molti inesperti possa essere qualitativamente migliore del parere di pochi esperti. Per giustificare le sue affermazioni, Surowiecki analizza noti successi e fallimenti umani, giustificandone gli esiti attraverso l avvenuta o la mancata partecipazione della folla nelle decisioni. Uno degli esempi che lo scrittore cita per giustificare le sue convinzioni è quello della democrazia, dove le cose vanno molto meglio rispetto ad una dittatura, proprio perché non è una sola persona a decidere per tutti. Partendo da esempi generali di questo tipo, passando attraverso l analisi di situazioni più complesse, Surowiecki identifica quattro requisiti necessari affinché la sua teoria possa definirsi valida. Il primo di questi consiste nel garantire la diversità tra i soggetti che devono svolgere un certo compito, prerogativa che spesso viene meno nei team di poche persone, dato che questi tendono a ragionare attraverso stereotipi. Quando i decisori hanno idee e soluzioni troppo simili tra loro, tendono a diventare dipendenti dal gruppo, si convincono che il gruppo abbia sempre ragione e tendono ad escludere a priori posizioni contrarie. Ogni talvolta che un idea contraria viene messa a tacere, rafforza inevitabilmente la convinzione iniziale del gruppo, aumentando il fenomeno. In alcune situazione diviene più facile cambiare la propria idea ed allinearsi al gruppo piuttosto che sfidarlo andando incontro ad indesiderate conseguenze. L indipendenza è il secondo requisito necessario affinché le opinioni e le idee espresse dai singoli soggetti assumano maggiore importanza; questa contribuisce ad impedire che l errore si diffonda, grazie alla diversità di informazioni note ai singoli soggetti. La vera indipendenza è molto difficile da ottenere perché a livello sociale chiunque è influenzabile e gli individui, condividendo le stesse opinioni, tendono a commettere gli stessi errori. Uno dei fenomeni che si verifica in presenza di mancata indipendenza è la cosiddetta cascata di informazioni, riscontrabile nelle situazioni in cui tutti gli individui seguono una stessa moda, conformandosi ad abitudini socialmente diffuse perché convinti di imparare qualcosa di importante nell esempio altrui. Questo comportamento, risultato fondamentale nell evoluzione umana, rischia di rivelarsi deleterio in situazioni in cui si ritiene strettamente necessario garantire l indipendenza nel pensiero degli individui. Il vero problema sorge quando gli individui smettono di pensare con le proprie informazioni ed iniziano a seguire irrazionalmente i pensieri ed i comportamenti ritenuti più autorevoli, facendosi così condizionare tanto da far prevalere l emotività alla ragione. Così facendo la cascata avanza

22 14 Crowdsourcing e le persone tendono ad attribuire sempre più peso alle azioni altrui. Tutto questo si verifica perché all interno del gruppo ci sono elementi più influenti di altri che riescono attraverso abilità come persuasione o carisma a diffondere e valorizzare con efficacia le proprie idee ed opinioni. Questo meccanismo trova facilmente riscontro quando si pensa a come nelle dittature del 900 le folli idee di pochi leader carismatici siano state comunemente prima accettate e poi sostenute da una grossa parte della società. Nonostante tutto, le cascate di informazioni, se effettuate in modo intelligente, potrebbero rivelarsi un arma vincente che giova e porta benefici a tutti i componenti del gruppo. Il terzo requisito è il decentramento delle informazioni. Questo consiste nel diffondere la conoscenza a tutti i membri di un gruppo al fine di evitare che il potere sia completamente centralizzato. Molto spesso capita che decisioni importanti vengano prese da singoli individui sulla base di loro conoscenze private e specifiche. In un sistema accuratamente decentrato non esiste la figura di un pianificatore onnisciente, dunque viene favorita la specializzazione e vengono aumentate sia la gamma che la diversità delle opinioni e delle informazioni di cui dispone il sistema. Il punto di forza di un gruppo accuratamente decentrato è rappresentato dalla conoscenza implicita dei singoli individui fortemente legata alle singole esperienze non condivisibili. Un esempio positivo dove il decentramento ha giocato un ruolo fondamentale è l evoluzione del sistema operativo Linux. Il sistema essendo privo di proprietari è stato costruito con l aiuto di volontari che fin dall inizio hanno decentralizzato le informazioni al fine di favorire il contributo di tutti. Il decentramento da solo non basta. Un sistema decentrato produrrà risultati veramente intelligenti solo se esiste un meccanismo che consente di riunire tutte le informazioni di tutti. L aggregazione (quarto requisito) risulta fondamentale per il successo del decentramento. Diviene dunque necessaria la figura di qualcuno che aggreghi le opinioni dei vari membri, altrimenti la soluzione migliore continuerebbe ad essere quella del singolo. L importanza dell aggregazione è riscontrabile in qualsiasi organizzazione che per svolgere al meglio il proprio lavoro, decida di optare per l adozione di sistemi informativi al fine di favorire la dislocazione della conoscenza. Le teorie di Surowiecki rafforzano e danno credito al modello utilizzato nel crowdsourcing. In un sistema globalizzato, come quello del web, i quattro requisiti posti come vincolo dall autore, sono molto facili da raggiungere e soddisfare. Quello che emerge dagli studi di Surowiecki porta a pensare che l impiego della folla in un processo decisionale, come nella risoluzione di un

23 2.3 Critiche al crowdsourcing 15 compito possa essere una strada sensata equivalente a quella data dall utilizzo di esperti. 2.3 Critiche al crowdsourcing La più o meno condivisibile opinione di Surowiecki rispetto alle folle è stata storicamente messa in discussione più volte. Quella che l autore ritiene essere un entità in grado di prendere decisioni intelligenti ed assumere comportamenti cooperativi che portano a benefici oggettivi è stata spesso associata ad idee diametralmente opposte: La folla si dirige verso il palazzo del vicario. Quest ultimo, aiutato dai servi, riesce a barricarsi in casa e a nascondersi in uno stanzino. Alcuni rivoltosi tentano di scardinare e smurare la porta del vicario per catturarlo e ucciderlo e ciò sotto gli occhi dei soldati spagnoli, i quali non osano intervenire. Renzo, al centro del tumulto, è tra coloro che si oppongono a una giustizia sommaria. Per questo, dopo aver reagito con sdegno alle proposte sanguinarie di un vecchio, rischia il linciaggio. [22] Alessandro Manzoni nei Promessi Sposi descrive la folla come una massa amorfa, senz anima, mossa dall istinto della conservazione, un entità incapace di compiere scelte razionali; capace solo di atti violenti, vogliosa di sangue, meschina e totalmente priva di valori nobili. Un pensiero simile venne successivamente espresso dall antropologo, psicologo e sociologo francese Gustave Le Bon. Nella sua opera Psicologia delle folle [21] del 1895, l autore attribuisce alle folle un grande potere distruttivo accompagnato da una scarsa capacità costruttiva. L antropologo fu tra i primi a studiare scientificamente il comportamento delle folle, cercando di isolarne i tratti peculiari e proponendo tecniche e strategie atte a controllarle. L opera venne successivamente letta, assorbita ed utilizzata dai dittatori totalitari del novecento, che l adottarono come un vangelo per poter avere il controllo delle masse. Più recentemente Andrew Keen nel suo libro The Cult of the Amateur [20] critica fortemente il WEB 2.0. L autore ritiene che la nascita di siti di social network ed enciclopedie libere, non ha fatto altro che spostare gli incauti fruitori di informazione da siti giornalistici rinomati e specializzati a fonti di dubbia professionalità. Tutto ciò danneggerebbe le testate serie, che troverebbero difficoltà a combattere contro i contenuti liberi, anche se questi risultano scadenti: quelli che sanno di più possono essere soffocati da quelli che sanno di meno

24 16 Crowdsourcing Le convinzioni dell autore risultano diametralmente opposte ai principi del crowdsourcing, dove la folla viene vista come una risorsa attiva che collaborando rende possibili eccellenti risultati. 2.4 Problemi aperti A causa della sua natura dinamica e distribuita, il crowdsourcing è un fenomeno complesso che nasconde una serie di problematiche interessanti da approfondire. Tra le più note si ritrovano le seguenti: concordare il giusto prezzo tra requestor e worker; verificare l onesta dei worker; mantenere un elevato standard di qualità del lavoro. Tali aspetti vengono analizzati nel dettaglio nei prossimi 3 paragrafi Negoziazione del prezzo Come per ogni prestazione lavorativa tradizionale, anche nel crowdsourcing è necessario un accordo tra chi richiede la prestazione e chi si incaricherà di svolgerla. Quest attività normalmente viene effettuata senza particolari problemi; nel caso delle piattaforme di crowdsourcing esistono aspetti da tenere in considerazione. Tradizionalmente le retribuzioni vengono assegnate a tempo; nel crowdsourcing invece le retribuzioni sono associate ai singoli task: è dunque importante stimare quanto tempo richieda lo svolgimento di ogni singolo task al fine di stabilire l ammontare della retribuzione. Se ad un task è assegnata una retribuzione troppo bassa, allora è destinato a non essere adempito da nessuno. Questo potrebbe voler significare che lo sforzo impiegato per la creazione dello stesso non venga poi ripagato con i risultati; tali task vengono chiamati starved HITs (task morti di fame). Analogamente anche l offerta di retribuzioni troppo elevate conduce ad una serie di problematiche come l inutile spreco di risorse per servizi che sarebbero potuti costare meno, oppure l aumento di appeal da parte di spammer verso task sovra-retribuiti. John J. Horton e Richard J. Zeckhauser nel loro articolo Algorithmic Wage Negotiations: Applications to Paid Crowdsourcing [8] propongono di creare un BOT 2 chiamato hagglebot (bot negoziatore) che si occupi della fase di contrattazione del prezzo. Questo dovrebbe attraverso un interfaccia 2 In informatica i BOT sono delle applicazioni che accedono alla rete con scopi legati all automazione di compiti che sarebbero troppo gravosi o complessi per gli utenti umani.

25 2.4 Problemi aperti 17 simile ad una chat fare delle domande e delle proposte ai worker, al fine di contrattare il prezzo delle prestazioni in maniera similare a quello che avviene nelle negoziazioni della vita di tutti i giorni. S. Faridani, B. Hartmann e P. G. Ipeirotis nel loro articolo What s the Right Price? Pricing Tasks for Finishing on Time [7] propongono un algoritmo per l assegnazione dei prezzi basandosi su un analisi della sopravvivenza 3 dei task. Gli autori hanno osservato che l arrivo dei lavorati in un marketplace può essere modellato con una distribuzione di Poisson non omogenea (NHPP). Basandosi su tale osservazione propongono un modello matematico astratto che cattura le dinamiche del mercato, prevede i tempi di risoluzione dei task e realizza politiche di tariffazione sia per privati che per folle di persone Onestà dei worker Molte istituzioni e sistemi sociali hanno bisogno di un certo grado di onestà per funzionare bene. Ad esempio, il sistema giuridico necessita di testimonianze oneste per essere efficace. Allo stesso modo, se in uno Stato tutti fossero onesti e pagassero le tasse, la pressione fiscale diminuirebbe per tutti. L onestà è dunque il valore che sta alla base del funzionamento o del fallimento di questi sistemi. Lo stesso principio vale anche per i marketplace online: affinché il sistema funzioni è necessario che tra worker è requestor ci sia un forte grado di fiducia, reso possibile solamente da un elevata onestà dei soggetti. Diventa dunque necessario trovare dei metodi che garantiscano la lealtà di tutti i soggetti coinvolti. S. Suri, D. G. Goldstein e W. A. Mason trattano il tema dell onestà nel loro articolo Honesty in an Online Labor Market [9]. Gli autori effettuano tre esperimenti con 175 partecipanti (93 dagli USA e 82 dall India) al fine di misurare il grado di onestà dei worker di Amazon Mechanical Turk. Nel primo esperimento è stato chiesto ai worker di lanciare un dato a 6 facce e riportare i risultati. Se il worker non fosse stato in possesso di un dado avrebbe potuto usare un dado virtuale offerto dal sito org. Per questo task sono stati offerti 0.25$ per l accettazione del task e 0.25$ per il lancio del dato. Se tutti i worker fossero stati onesti la media dei lanci sarebbe risultata 3.5. Tuttavia, la media è risultata di Questo indica che c è stata uno sbilanciamento anomalo verso valori alti del dado (5 e 6). Questo evidenzia un elevata disonestà da parte dei worker. Con il secondo esperimento si è voluto capire se un minore importo guadagnato dal lancio del dado avesse potuto far aumentare la disonestà dei worker. 3 La sopravvivenza di un task è il tempo che intercorre tra la sua creazione e la sua risoluzione. É consigliabile che tale valore sia basso, in quanto task molto longevi implicherebbero peggioramento delle performance del sistema.

26 18 Crowdsourcing Quindo si è deciso di tenere un payoff medio simile a quello dell esperimento precedente ma si è ridotta la varianza offrendo 1.00$ per l accettazione del task e 0.05$ per ogni lancio del dato. I risultati non differivano statisticamente rispetto a quelli dell esperimento precedente; questo suggerisce che la varianza del payoff non è il fattore principale di disonestà dei worker. Con il terzo esperimento si è cercato di capire se la rilevabilità dell inganno avesse potuto modificare il comportamento dei worker. Con un singolo lancio di dado è impossibile stabilire se un worker sia stato disonesto. Pertanto è stato chiesto ai worker di effettuare 30 lanci di dado e di inserire tutti i risultati, in modo da individuare eventuali inganni palesi. Si è deciso di pagare 0,01$ per ogni lancio di dado. L esperimento ha riportato una media dei lanci di 3.57, molto più vicina al valore atteso 3.5, rispetto ai lanci precedenti. Questo evidenzia che nell esperimento il livello di onestà è stato maggiore rispetto i precedenti esperimenti, nonostante si fosse ridotto notevolmente il payoff. Con tale esperimento si è dimostrato che l elevato grado di onestà nei worker viene garantito non dall alta retribuzione offerta quanto dal timore degli stessi di essere scoperti in atteggiamenti disonesti e quindi vedersi rifiutare il proprio lavoro. Infine gli autori dichiarano di non aver riscontrato nessuna correlazione rilevante tra la disonestà dei worker e la relativa distribuzione demografica Controllo delle prestazioni L onestà dei worker è un requisito fondamentale per la riuscita del crowdsourcing; questa da sola non basta: utenti onesti, ma impreparati oppure distratti potrebbero offrire delle prestazioni scadenti compromettendo la credibilità dell intero sistema. Diviene dunque importante capire quali siano le cause di prestazioni scadenti. Jeffrey M. Rzeszotarski e Aniket Kittur nel loro articolo Instrumenting the crowd: Using implicit behavioral measures to predict task performance [18] propongono una tecnica per catturare il comportamento dei worker al fine di creare delle interfacce (fingerprint) contenenti i dati relativi alle loro prestazioni. Decidono dunque di spostare il focus dell attenzione sul comportamento dei worker rispetto ai risultati che essi producono. Gli autori dimostrano che è possibile analizzare e generalizzare il lavoro di un worker al fine di creare un registro contenente eventi e statistiche comportamentali. Rzeszotarski e Kittur ritengono di essere in grado di prevedere i risultati relativi all accuratezza del lavoro, alla qualità dei contenuti ed alla comprensione degli stessi. Gli autori dispongono di un prototipo che monitora le attività degli utenti su Amazon Mechanical Turk tenendo traccia del log al fine di raccogliere informazioni statistiche. Queste, attraverso modelli di machine learning, permettono la stima sulle future performance dei worker.

27 2.5 Crowdsourcing su web Crowdsourcing su web Negli ultimi anni, grazie a caratteristiche del web come globalità, velocità e costi ridotti, il crowdsourcing si è potuto affermare come vero e proprio modello di business in rete. Inizialmente, venne utilizzato solamente da volontari che dedicavano il loro tempo libero alla nascita di community open source più o meno di nicchia. Successivamente, l aumentare degli interessi economici attorno al mondo della rete, ha fatto si che anche il crowdsourcing venisse considerato sempre più una vera e propria opportunità di collaborazione lavorativa tra imprese sempre più aperte e lavoratori freelance. Questa visione così globale di collaborazione rende possibili interazioni tra entità molto diverse per nazione, lingua e cultura. Per gli esecutori dei task, eventuali informazioni sull identità di chi ha commissionato il task risultano superflue, dato che il loro lavoro consiste solo nello svolgimento del task nel modo più corretto possibile per poter così ricevere la dovuta ricompensa Wikipedia Un noto esempio di crowdsourcing su web è l enciclopedia libera Wikipedia. Nata nel 2000, deve il suo successo ad una comunità vastissima di volontari sparsi in tutto il mondo che dedicano il loro tempo a condividere gratuitamente la loro conoscenza. Le pagine di Wikipedia possono essere modificate da chiunque in ogni momento. I volontari iscritti sono invitati ad essere il più possibile oggettivi, dato che non esiste un comitato di redazione atto al controllo preventivo sul materiale inviato. Anche la stesura dei regolamenti interni è lasciata libera agli utenti che possono così esercitare un organizzazione autonoma. Chiunque può scrivere una pagina, indipendentemente dalle proprie competenze e dalle proprie qualifiche. Ogni autore è consapevole che i propri contributi possono essere redistribuiti, modificati o cancellati da chiunque, nei termini della licenza e delle linee guida interne a Wikipedia. Tutte le voci inserite sono sottoposte a controlli della comunità con il supporto di un comitato di amministratori e le eventuali decisioni sulla modifica di qualche contenuto vengono generalmente prese per consenso o per votazione. Questo modello di gestione autonoma può portare a dei disaccordi tra gli utenti; spesso queste differenze di vedute si risolvono in modo veloce e questo accade quando vengono pubblicate voci inutili, palesemente sbagliate, non oggettive o con contenuti che potrebbero essere considerati offensivi. In questi casi, la quasi totalità della comunità si trova d accordo nel modificare o rimuovere una voce; in altri casi le discussioni possono prolungarsi e la difficoltà nel trovare l accordo per la stesura di una voce può portare a continue modi-

28 20 Crowdsourcing fiche o cancellazioni della voce stessa. Generalmente queste difficoltà sorgono quando si trattano temi in cui è difficile accettare altri punti di vista, come in ambito religioso o politico, oppure quando mancano prove sufficienti per poter scrivere una voce con assoluta certezza. Un esempio di questi diverbi è quello della teoria del complotto lunare: questa tesi viene sostenuta da più persone le quali, ritenendo che l uomo non sia mai atterrato sulla luna, si trovano dunque in totale disaccordo con la pagina dell enciclopedia che afferma che lo sbarco lunare avvenne nel Tuttavia, il modello di Wikipedia non è esente da critiche. I critici ritengono che non sia una cosa sensata dare la possibilità a chiunque di scrivere un articolo, perché gli autori potrebbero non essere esperti dell argomento di cui scrivono e quindi l enciclopedia diventerebbe inaffidabile. Una critica analoga viene fatta dall editore esecutivo dell Enciclopedia Britannica, Ted Pappas, il quale afferma che non è dimostrabile che il continuo miglioramento apportato a Wikipedia possa portare alla perfezione [23] Amazon Mechanical Turk Il 2 novembre del 2005, la compagnia statunitense Amazon lanciò in rete la prima versione di un marketplace chiamato Amazon Mechanical Turk 4. La scelta del nome non fu casuale: il mechanical turk (turco meccanico) era un automa di legno creato nel 1769 dall inventore Ungherese Wolfgang von Kempelen; questa macchina dalle sembianze umane era situata sopra una sedia, dietro ad un tavolo dove poggiava una scacchiera. I tratti del volto, i vestiti che indossava e la postura la facevano apparire come una persona di chiare origini mediorientali, comodamente seduta ed in attesa di accettare una sfida a scacchi. Chiunque poteva sedersi davanti all automa e sfidarlo; il giocatore, forse ingannato dal rumore di una serie di ingranaggi che giravano sotto al tavolo, era realmente convinto di giocare contro una macchina. Quello che il giocatore ignorava è che all interno del tavolo, esattamente sotto la scacchiera, c era una persona in carne ed ossa che controllava i movimenti dell automa, consentendone le mosse. Questa modalità di interazione tra una persona ed una macchina, che maschera la presenza di un altra persona, è molto simile a quella adottata da Amazon in mturk. Il servizio consiste in una piattaforma web dove i partecipanti possono decidere di assumere ruoli di richiedenti o fornitori di una certa prestazione. In seguito alla scelta effettuata il sistema fornisce interfacce ben distinte a seconda che si abbia la necessità di creare oppure di svolgere dei task. I requestor, tipicamente sono dei programmatori informatici che decidono di affidarsi al 4 Amazon Mechanical Turk è anche noto con il nome mturk.

29 2.5 Crowdsourcing su web 21 Figura 2.4: Il turco meccanico (da [25]) crowdsourcing per dotare le loro applicazioni di specifiche funzionalità avanzate. Queste risultano molto semplici se svolte da una persona, mentre si rivelano impossibili nella risoluzione da parte di intelligenze diverse da quella umana: compiti come la descrizione di una fotografia o l espressione di un opinione personale richiedono capacità riscontrabili solo da individui dotati di intelletto. Allo stato attuale nessuna macchina è in grado di risolvere questi due compiti. Dunque, se ad esempio uno sviluppatore web necessitasse di catalogare alcune fotografie in modo veloce e poco costoso potrebbe decidere di appoggiarsi ad un servizio come mturk, andando a creare appositi task, descrivendo nel dettaglio le modalità di catalogazione richieste. In poco tempo (qualche ora), riceverebbe il risultato del lavoro ottenuto con una spesa quantificabile in qualche dollaro. Questi compiti vengono detti HIT (Human Intelligence Task) e possono essere molto diversi tra loro, come etichettare delle immagini, categorizzare dei termini, effettuare una recensione o mettere un apprezzamento su un social network. Le linee guida e le regole d ingaggio di ogni singolo task vengono stabilite da Requestor al momento della creazione del task stesso. Ad ogni task viene associata una pagina contenente le istruzioni, le modalità, i passi e dei consigli su come il task deve essere svolto. È compito del Requestor anche stabilire la ricompensa economica per l effettuazione del task ed il numero di volte che deve essere proposto.

30 22 Crowdsourcing Gli HIT vengono visti e svolti da chiunque sia iscritto in qualità di worker nel servizio. Per supportare i vari worker nella scelta adeguata dei task da svolgere, il sistema mostra un elenco di possibili attività opportunamente filtrate ed ordinate: per ognuna di esse vengono visualizzate una serie di informazioni funzionali tra cui la somma offerta per lo svolgimento del task, una stima del tempo che ciò richiederà, il numero di volte che quel task può essere svolto ed il tempo trascorso dalla sua pubblicazione. Alcuni task richiedono delle competenze maggiori di altri, tant è che mturk prevede il conseguimento di abilitazioni specifiche per task particolarmente complessi. Per ogni task, ogni worker guadagna una cifra che va da un centesimo a qualche dollaro. Le ricompense che possono sembrare basse se rapportate ad uno stipendio occidentale, assumono tutt altra dimensione quando vengono pensate per worker residenti in Paesi in via di sviluppo, dove i salari sono mediamente bassi ed il lavoro su mturk può diventare una vera e propria opportunità di reddito. In uno studio del 2012 [17], si è cercato di capire se mturk potesse essere sfruttato per il reclutamento di soggetti per esperimenti di scienze sociali. Lo studio prevede la creazione di specifici task da proporre sulla piattaforma di Amazon, per poi ottenere maggiori informazioni sugli utenti del sistema. Si è scoperto che nonostante il campione degli intervistati fosse diverso per caratteristiche rispetto alla popolazione degli Stati Uniti (dunque teoricamente poco rappresentativo a livello nazionale), presentava comunque degli aspetti vantaggiosi che, in certe condizioni permettono al sistema di ottenere risultati addirittura migliori dei sistemi di reclutamento classici. La conclusione alla quale si è giunti è che mturk funziona molto bene quando si desidera avere un campione uniforme della popolazione, mentre offre risultati peggiori quando si necessita di un campionamento in un dominio definito con maggior precisione. Il campione analizzato è risultato essere composto per il 60% da donne, per l 87% da utenti di carnagione chiara con un età media di 32,2 anni e 14,9 anni di istruzione alle spalle. Un altro vantaggio emerso dallo studio riguarda la retribuzione offerta agli intervistati fissata a 0,50 dollari per 5 minuti di intervista (per un ammontare orario di 6 dollari), mentre gli stessi ricercatori dichiarano che per il reclutamento di soggetti in esperimenti precedenti sono stati spesi da un minimo di 5 ad un massimo di 30 dollari per ogni ora di intervista. In conclusione, il sistema di Amazon risulta essere molto indicato nell arruolamento di soggetti per esperimenti sociali, quando non ci sono specifici vincoli nel campionamento; tutto ciò garantendo ottimi risultati ad una cifra abbastanza esigua.

31 2.5 Crowdsourcing su web 23 AMT offre inoltre una serie di API che permettono l integrazione dei servizi offerti dalla piattaforma all interno di applicazioni sviluppate da terzi. Qualsiasi programmatore può dunque decidere di importare nei propri progetti le librerie contenenti i codici sorgenti di Amazon sfruttandone così vantaggi e peculiarità. Dal sito si possono scaricare le versioni aggiornate dell SDK per Java, PHP e.net. Come tutti i servizi della famiglia AWS (Amazon Web Services), anche per le API di mturk Amazon mette a disposizione nel proprio sito una serie di pagine contenenti informazioni utili a supportare gli sviluppatori nell utilizzo delle librerie. Il sito, oltre alle guide, mette a disposizioni una serie di esempi ed una dettagliata documentazione Captcha e recaptcha Nel 1997, Andrei Broder, uno degli sviluppatori di AltaVista, ideò una tecnica per impedire agli spider dei vari motori di ricerca di estrarre l elenco degli indirizzi web presenti tra le pagine del proprio sito. L idea di Broder fu quella di richiedere lo svolgimento di un semplice task preliminare ad utenti che desiderassero accedere alla propria pagina web. Il task consisteva nel far riprodurre in un campo di testo una serie di caratteri alfanumerici visibili in un immagine. Questo compito, apparentemente molto banale per un essere umano, si rivelò essere un ostacolo quasi insormontabile per un calcolatore. Broder riuscì così a discriminare gli utenti umani dai bot, impedendo così a sistemi automatizzati di sfruttare i link presenti nelle proprie pagine per indicizzarne i contenuti. Nel 2000 Luis von Ahn diede una definizione generale per sistemi che intendevano effettuare una distinzione automatica tra utenti umani e macchine. Venne dunque coniato il termine captcha (completely automated public Turing test to tell computers and humans apart) acronimo di Test di Turing pubblico e completamente automatico per distinguere computer ed umani [4]. Nella definizione si fa esplicitamente riferimento ad alcuni test che il matematico britannico Alan Turing propose per determinare se una macchina fosse in grado di pensare. La maggiore diffusione dei captcha si verificò quando l azienda statunitense Yahoo decise di adottarli per proteggere i contenuti delle proprie pagine. All aumentare della diffusione divenne necessario rendere i Captcha sempre più sofisticati, per garantire che continuassero ad essere considerati un problema insormontabile da parte di utenti intenzionati a fare spam o hacking con sistemi automatizzati. Per tentare di forzare i captcha si idearono svariate tecniche di reverse engineering, basate principalmente su algoritmi più o meno evoluti di intelligenza artificiale che sfruttavano tecniche come OCR (riconoscimento ottico dei caratteri) per digitalizzare il testo. Iniziò così un

32 24 Crowdsourcing lungo antagonismo tra chi si impegnava a rendere i captcha sempre più sofisticati e coloro che escogitavano tecniche sempre più innovative per aggirarli. Questa continua sfida ha reso i captcha sempre più complessi tanto che in alcuni casi risultavano essere un ostacolo di accessibilità anche per utenti umani, soprattutto se affetti da particolari problematiche o disabilità. Vennero così introdotti ulteriori test allo scopo di essere usati con o in sostituzione ai captcha originali. Alcuni di questi sistemi pongono domande o quesiti a cui solo utenti umani dovrebbero poter rispondere, mentre altri richiedono la trascrizione da parte dell utente di informazioni contenute in piccoli frammenti audio o video (problema ancora di difficile soluzione per sistemi automatizzati). Figura 2.5: Esempio di recaptcha L evoluzione più significativa dal punto di vista del crowdsourcing fu successiva: Luis von Ahn, intuì che i captcha potevano rappresentare non solo uno strumento passivo per la discriminazione agli accessi ad un sito, ma anche una risorsa utile a creare valore tangibile [3]. L intuizione fu di mantenere l idea originale, ma anziché generare digitalmente le immagini da somministrare all utente, prelevarle da archivi di immagini acquisite mediante scanner delle quali non si è riusciti ad effettuare una trascrizione automatica mediante software OCR. Nacque così il recaptcha: all utente venivano dunque mostrate due immagini, una nota al sistema e l altra no. L immagine nota al sistema permetteva di garantire che chi tentava di risolvere il captha fosse realmente umano; la seconda rappresentava la parola scansionata che doveva essere digitalizzata. All utente non veniva detto questo dettaglio, in modo tale che esso mettesse lo stesso impegno per entrambe le parole. Le trascrizioni dei desti delle parole scansionate venivano salvate su dei database e confrontate con quelle inserite da altri utenti. Questo fenomeno permise a milioni di utenti (spesso ignari) di contribuire concretamente alla digitalizzazione di migliaia di libri sparsi in tutto il pianeta. Ad ognuno di questi utenti è stato chiesto un piccolo sforzo gratuito, ma l unione degli sforzi di tutti ha reso possibile la nascita di un patrimonio culturale unico ed inestimabile.

33 2.6 Conclusioni 25 Un sistema simile ai captcha viene proposto da Otto Chrons e Sami Sundell. Nel loro articolo Digitalkoot: Making old archives accessible using crowdsourcing [14] decidono di sfruttare l impiego dell intelligenza umana per svolgere trascrizioni di immagini. A differenza dei captcha, tali scritte vengono proposte sotto forma di semplici giochi: questi sono pensati con l intento di coinvolgere l utente attraverso scenari sempre più avvincenti. Grazie a tale sistema anche persone inesperte riescono ad effettuare trascrizioni di testo, raggiungendo elevati livelli di performance. 2.6 Conclusioni In questo capitolo è presentato il crowdsourcing. Nel fare ciò si è partiti da una descrizione generale fino ad arrivare ad una definizione più dettagliata, frutto dell unione di più di quaranta definizioni esistenti. Successivamente si è discusso delle varie tipologie di crowdsourcing esistente e della saggezza delle folle come filosofia alla base dell intero sistema. Sono poi state discusse alcune critiche fatte al crowdsourcing ed alcuni problemi aperti ai quali il mondo scientifico cerca di trovare soluzione. Infine vengono presentati tre importati esempi di crowdsourcing su web.

34 26 Crowdsourcing

35 Capitolo 3 Obbiettivi In questo capitolo vengono descritti gli obbiettivi di questa tesi. Nella prima parte del capitolo (paragrafo 3.1) si introducono le motivazioni del lavoro. Successivamente viene descritto l obbiettivo generale (paragrafo 3.2). Infine vengono descritti tre obbiettivi specifici(paragrafi 3.2.1, 3.2.2, 3.2.3). 3.1 Motivazioni dello studio Le attuali piattaforme di crowdsourcing differiscono tra loro per svariati aspetti. Caratteristiche come le modalità di interazione, la complessità dei task offerti e la gestione dei propri utenti contraddistinguono tali servizi in modo evidente. Tuttavia c è una caratteristica che accomuna tutte queste: le piattaforme esistenti sono state pensate e progettate per essere utilizzate da utenti desktop. Si presuppone che i vari worker accedano alle piattaforme web da postazioni fisse con schermi grandi, in luoghi generalmente poco affollati e soprattutto interagendo con mouse e tastiera. Tuttavia questo vincolo sta diventando sempre più limitante specialmente alla luce dei cambiamenti delle modalità di accesso alla rete da parte di utenti internet. L esplosione della diffusione di dispositivi mobili (come smartphone e tablet) che si sta verificando degli ultimi anni, è talmente evidente che si commetterebbe un errore se si decidesse di trascurarla. Questo trend viene confermato anche dall agenzia statunitense ComScore, nota per effettuare ricerche e misurazioni sul comportamento degli utenti in rete. L azienda nel giugno del 2012 ha rilasciato i risultati di studi [24] effettuati su larga scala, allo scopo di ottenere informazioni sugli utenti ed in particolare sui dispositivi con i quali essi accedono al web. Come si evince dal grafico riassuntivo dello studio (in figura 3.1), il numero di utenti mobile cresce più velocemente del numero di utenti desktop. Questa 27

36 28 Obbiettivi Figura 3.1: Grafico dello studio di ComScore, sulla diffusione dei dispositivi desktop e mobile (da[24]) differenza di velocità farà si che nel 2014 il numero di utenti che utilizzeranno dispositivi come smartphone e tablet eguaglierà il numero di utenti che accederanno al web attraverso sistemi tradizionali come PC o notebook. È dunque ragionevole pensare che se dovesse essere confermato questo andamento, ci sarà un inversione di tendenza rispetto l attuale diffusione di dispositivi. Per fronteggiare questo inevitabile cambiamento, è importante che anche le piattaforme per crowdsourcing si adeguino e vengano reinventate per offrire un adeguato livello di user-experience, anche ad utenti di dispositivi mobili. Il fenomeno del mobile è talmente evidente che se si dovesse continuare a pensare al crowdsourcing come si è fatto finora si rischierebbe di ritrovarsi a privilegiare la categoria di utenti desktop, andando ad escludere la categoria di utenti mobile. Questo si ripercuoterebbe negativamente, non solo per la riduzione del numero di worker disponibili, ma soprattutto ci si precluderebbe la possibilità di sfruttare tutti quei benefici che solamente sistemi mobili possono offrire. I dispositivi mobili infatti permettono un dinamismo ed un immediatezza superiori rispetto ai dispositivi tradizionali. Queste caratteristiche potrebbero risultare vincenti in particolari situazioni e nello svolgimento di particolari task. Ad esempio possiamo immaginare uno scenario in cui un individuo munito

37 3.2 L obbiettivo generale 29 di tablet, con connessione 3G, ogni giorno debba attendere un mezzo pubblico per mezz ora. Ipotizziamo che egli possa voler impiegare quella mezzora nella risoluzione di task su una piattaforma web di crowdsourcing. Così facendo potrebbe non veder sprecato il suo tempo, ma bensì lo vedrebbe impiegato nello svolgimento di attività che lo tengano impegnato, magari fornendogli una retribuzione economica. Questo semplice scenario non è ancora possibile, proprio perché l esperienza di un utente mobile nella risoluzione di task di piattaforme pensate al web risulta frustrante e poco produttiva. La situazione appena descritta è solo una delle tante plausibili in cui un utente mobile potrebbe voler effettuare dei compiti che allo stato attuale risultano semplici solo per utenti desktop. Esistono infatti una serie di attività che sfruttano tutte quelle caratteristiche tipiche dei dispositivi mobili, che non vengono offerte dai dispositivi desktop, oppure che vengono offerte ma non si trova vantaggioso usare. Ad esempio, possibilità come la geo-localizzazione o il voice-to-text, che dagli smartphone vengono messe a disposizione in maniera nativa, potrebbero risultare delle armi vincenti su task che per la loro risoluzione richiedono informazioni localizzate o scrittura di testi lunghi. Ci si potrebbe dunque chiedere quali task, tra tutti quelli comunemente offerti nelle piattaforme esistenti, risulterebbero vantaggiosi in uno svolgimento da dispositivi mobile, oppure come migliorare i task attuali per renderli risolvibili in modo efficace anche da smartphone e tablet. 3.2 L obbiettivo generale Il lavoro di tesi consiste in una valutazione sperimentale dell efficacia del crowdsourcing effettuato da dispositivo mobile. Per raggiungere tale scopo è necessario innanzitutto avere una panoramica dettagliata delle piattaforme per crowdsourcing esistenti. Successivamente, attraverso un attività di analisi, si può verificare quali di esse si prestino meglio ad un adempimento anche da dispositivo mobile. Uno studio sulle piattaforme che offrono migliori risultati permette di isolare le caratteristiche positive che i task dovrebbero avere per una risoluzione agile anche da mondo mobile. L obbiettivo generale consiste dunque nel capire se e con quali risultati il crowdsourcing possa essere allargato anche al mondo mobile. Per raggiungere tale scopo si è deciso di perseguire tre obbiettivi: analisi delle piattaforme di crowdsourcing esistenti; verifica di quali piattaforme risultino efficienti in uno svolgimento da mobile;

38 30 Obbiettivi individuazione di tipologie di task che si prestino bene ad uno svolgimento da dispositivi mobili. Analizziamo nel dettaglio tali obbiettivi e quali risultati ci si aspetta di ottenere nel perseguirli Obbiettivo 1: Analisi delle piattaforme di crowdsourcing esistenti Prima di concentrarsi nel crowdsourcing mobile decidiamo di analizzare come ciò viene svolto nel mondo desktop. Vengono dunque analizzate quattro piattaforme largamente diffuse: Amazon Mechanical Turk Micro Workers Minute Workers Short Task Nel selezionare i quattro servizi si è ritenuto che essi siano pensati esclusivamente per un utilizzo da desktop. Risulta interessante capire quali siano i punti che accomunano tali piattaforme e quali siano gli aspetti che le differenziano. Ci si aspetta di ricavare tali informazioni, non solamente con un accurata osservazione di tali servizi, ma anche attraverso l impiego di sistemi automatizzati che permettano di estrarre le informazioni più interessanti. Nel far ciò ci si vuole concentrare maggiormente su aspetti concettuali/cognitivi piuttosto che su aspetti di UI/HCI 1. Questo ha fatto si che le analisi siano incentrate sui task e sulle categorizzazioni degli stessi piuttosto che sulle interazioni e le interfacce delle piattaforme Obbiettivo 2: Quali piattaforme sono adatte a dispositivi mobili? Il secondo obbiettivo della tesi consiste nel valutare se e quanto le piattaforme considerate possano essere usate con profitto anche da sistemi mobili. Questo risulta particolarmente interessante, perché con tali informazioni in possesso, diventa possibile ricercare le caratteristiche comuni alle piattaforme che offrono i risultati migliori. Simmetricamente si potrebbero ricercare i 1 L UI è il diminutivo di interfaccia utente. HCI è il diminutivo di interazione uomo/macchina

39 3.2 L obbiettivo generale 31 fattori critici nelle piattaforme ritenute meno utilizzabili. Tali aspetti servirebbero da linea guida per chiunque decidesse di realizzare una piattaforma per crowdsourcing rivolta al mondo mobile. A tale scopo si è deciso di effettuare delle misurazioni, che permettano di assegnare ad ogni piattaforma una stima sulla difficoltà di adempimento da dispositivo desktop e da dispositivo mobile; successivamente tali stime saranno confrontate. Così facendo, per ogni piattaforma si può ottenere il grado di miglioramento o peggioramento delle prestazioni a seconda che ci si acceda con l uno o con l altro dispositivo. Ci si aspetta che nelle piattaforme considerate tutti i possibili task siano ritenuti più difficili se svolti da dispositivo mobile; questo alla luce della natura orientata al mondo desktop delle stesse Obbiettivo 3: Quali tipologie di task sono adatte a dispositivi mobili? Il terzo obbiettivo che si vuole raggiungere con questo lavoro consiste nel ricercare caratteristiche dei task che li rendano particolarmente adatti al mondo mobile: concentrandosi su di essi, si è deciso di trascurare aspetti relativi all usabilità e allo user-experience. Personalmente ritengo che le maggiori criticità del sistema siano attribuibili all assenza di una strutturazione dei task e ad una forte disomogeneità nell offerta degli stessi. Tuttavia ritengo che soluzioni a tali problematiche permetterebbero di limitare i numerosi disagi a vicissitudini di minore impatto, risolvibili adottando soluzioni di HCI (interazione uomo macchina) già note in letteratura. Con le informazioni sull adeguatezza al mondo mobile delle singole tipologie di task si potrebbero ideare dei pattern da far adottare ai requestor in fase di creazione dei task, al fine di farli aderire a delle linee guida di base. Questo consentirebbe di disporre di task più strutturati e simili tra loro, così da renderli il più possibile uniformi agli occhi dei worker. Questi modelli potrebbero essere visti come limitanti o restrittivi per task particolarmente complessi, ma in tal caso sarebbe comunque consigliabile proporre tali task solamente ad utenti desktop. Ad esempio, si potrebbe pensare di predisporre un pattern per la categorizzazione di alcune immagini (tipologia di task ricorrente nella piattaforme analizzate). Ad ogni possibile richiedente che decidesse di adottare tale pattern verrebbero richieste solamente le immagini e i nomi delle categorie, non dovendosi così preoccupare di altri aspetti, come l interfaccia o la stima del tempo richiesto, dato che sarebbe il pattern a portare con se tali informazioni. Questi aspetti permetterebbero così di uniformare e strutturare tutte quelle fasi che ad oggi vengono ancora svolte manualmente ed in modo diverso da task a task e che concorrono ad aumentare i disagi e la

40 32 Obbiettivi frustrazione nei worker. Proprio questi ultimi sarebbero i principali beneficiari di tale perfezionamento, in quanto dopo una fase di ambientamento iniziale acquisirebbero familiarità con la maggiore organizzazione del nuovo sistema. Potrebbero dunque imparare a riconoscere i vari pattern, scegliendo tra essi quelli che garantiscono maggiori prestazioni, soddisfazioni e profitto. A tutto questo va aggiunto il vantaggio dato dal non dover leggere righe e righe di istruzioni per ogni task. Dopo un paio di attività svolte in un pattern questo sarebbe assimilato, rendendo naturale tutti gli adempimenti futuri a task di quel tipo. Infine, problemi di usabilità, prima frequentissimi, ora non sussisterebbero, perché basterebbe un interfaccia ben progettata per ogni pattern (preferibilmente personalizzabile) ad evitare tali inconvenienti. Questa potrebbe essere riusata infinite volte, mantenendo un livello di user-experience molto elevato. 3.3 Conclusioni In questo capitolo sono stati presentati gli obbiettivi della tesi. L obbiettivo più generale consiste in un esplorazione sperimentale che verifichi le possibilità offerte dalle tecnologie mobili nello svolgimento di attività di crowdsourcing. Allo stato attuale tale filosofia trova riscontro solamente nel mondo delle tecnologie desktop, come computer e notebook. Internamente a questo macro obbiettivo si è deciso di dedicarsi a tre obbiettivi specifici: il primo verte sull effettuare un analisi di 4 note piattaforme per crowdsourcing; con il secondo si cerca di capire qual è il grado di produttività delle attuali piattaforme, se utilizzate da dispositivi mobili; il terzo obbiettivo consiste nell indagare sulle proprietà dei task delle categorie maggiormente adatte a dispositivi mobili.

41 Capitolo 4 Piattaforme e Task Nel paragrafo 4.1 viene presentata la fase esplorativa atta ad individuare le piattaforme da prendere in analisi. Successivamente (paragrafo 4.1.2) vengono enunciati i criteri adottati nello scegliere tali piattaforme. Il paragrafo descrive nel dettaglio le 4 piattaforme scelte. Vengono poi descritti i relativi task (paragrafo 4.2) ed i principali attributi che li compongono. Infine nel paragrafo 4.2 viene discussa la creazione di un data-set di task, opportunamente estratti dalle piattaforme selezionate. 4.1 Piattaforme Su web esistono numerose piattaforme per crowdsourcing. Come descritto nel paragrafo 3.2.1, il primo obbiettivo di questa tesi consiste nel selezionarne quattro per sottoporle ad analisi. In particolare ci si è interessati di quelle che offrono una retribuzione per l adempimento di semplici task (queste sono anche chiamate marketplace). Queste piattaforme prevedono che al momento della creazione dei task, al requestor sia richiesto di specificare le seguenti voci: istruzioni del task; stima del tempo impiegato nello svolgimento; retribuzione offerta; numero di utenti al quale proporre il task; eventuali qualifiche o requisti richiesti al worker; prova da mandare per dimostrare l avvenuto adempimento. 33

42 34 Piattaforme e Task Ogni worker può esaminare tali informazioni al fine di individuare un task da adempiere. Dopo aver selezionato il task desiderato, il worker s impegna a svolgere le attività da esso richieste. Al momento della conclusione di tale compito il worker si preoccupa di inviare la prova dell avvenuto adempimento; solo a questo punto il requestor eroga il pagamento. Questo schema, comune a tutte le piattaforme, può funzionare benissimo anche su mobile. Preso atto di ciò, si può continuare la fase di ricerca di quelle piattaforme che meglio si potrebbero prestare per una risoluzione dei propri task da dispositivi mobili Piattaforme esistenti Nel web sono presenti una molteplicità di marketplace. Nella fase di ricerca ne sono stati individuati 7: Amazon Mechanical Turk BD Workers Free Labors Job Zen Micro Workers Minute Workers Short Task Criteri di scelta Durante la fase di rassegna si è riscontrato che tutte le piattaforme presentano problemi di usabilità, i quali sono risultati amplificati quando si è deciso di fruire dei servizi offerti dalle piattaforme attraverso dispositivi mobili. Nel dover individuare le piattaforme che possano garantire un elevato grado di efficienza anche da tali dispositivi si è dunque deciso di procedere per esclusione: l idea è quella di individuare le piattaforme affette da gravi problemi di usabilità ed escluderle. Quest attività si svolge in modo rapido ed agevole, in quanto alcune piattaforme osservate presentano difficoltà di gravità tale da rendere impossibile l utilizzo da dispositivi mobili. Le problematiche pù ricorrenti sono le seguenti: descrizioni dei task molto lunghe, la cui comprensione richiede molto tempo. In dispositivi con schemi ridotti è consigliabile usare testi brevi e diretti;

43 4.1 Piattaforme 35 difficoltà di carattere tecnico date dalla necessità di utilizzo di plugin di terzi (come Adobe Flash Player oppure Microsoft Silverlight ) per la riproduzione di contenuti multimediali; i task risultano essere poco strutturati e ciò porta ad un continuo disorientamento dell utente. Tale caratteristica si ripercuote in modo negativo nella user-experiance, in particolare nell utilizzo di sistemi mobili; impiego di attributi frame e iframe nelle pagine HTML, i quali non vengono supportati da tutti i dispositivi mobili. Inoltre risulta molto scomodo effettuare del panning (spostamenti della pagina contenuta all interno del frame) se si utilizzano schermi touch-screen, specialmente di dimensioni ridotte; i task presenti nelle attuali piattaforme sono pensati per uno svolgimento da dispositivi desktop. Questo comporta che il creatore del task effettui una stima del tempo necessario all adempimento solo da tali dispositivi. Dovendo ripensare alla piattaforma in ottica di impiego di dispositivi mobili, risulta importante predisporre la possibilità di specificare la stima del tempo in funzione del dispositivo usato; molti dei layout degli attuali sistemi richiedono l utilizzo di schermi con alte risoluzioni; questo potrebbe essere un problema per gli utenti di smartphone di fascia media. In ottica di piattaforme per crowdsourcing su mobile è consigliabile pensare a layout fluidi che si possano adattare alle dimensioni dello schermo, in modo da garantire un utilizzo ottimale anche su dispositivi dotati di schermi di dimensioni ridotte; la potenza di calcolo di smartphone e tablet, se pur in costante crescita, risulta ancora molto inferiore rispetto a quella dei dispositivi classici. Questo aspetto è di fondamentale importanza, soprattutto immaginando una piattaforma per crowdsourcing intesa come web application. Siti con troppe informazioni e troppi form potrebbero risultare lenti e scattosi, oltre che molto scomodi. In aggiunta a tali problemi di performance dell hardware si sommano problemi di tipo software, come le limitazioni presenti nei browser mobili, maggiormente presenti rispetto a quelle dei browser classici. Tali criticità, già evidenti in fase di utilizzo delle piattaforme attraverso PC e notebook, vengono inevitabilmente aggravate se si utilizzano dispositivi mobili, tanto da risultare delle vere e proprie barriere di usabilità.

44 36 Piattaforme e Task Le piattaforme scelte La scelta definitiva ricade dunque sulle seguenti quattro piattaforme: Amazon Mechanical Turk Micro Workers Minute Workers Short Task Amazon Mechanical Turk Amazon Mechanical Turk è il marketplace di crowdsourcing più diffuso. Proprio per questo motivo si è deciso di includerlo tra le piattaforme da valutare. Il servizio offre la possibilità ai propri utenti di proporre internamente alla piattaforma dei task situati in host esterni: la piattaforma non effettua nessun controllo su di essi. Questo implica che tali task siano strutturati in modo completamene differente l uno dall altro. Al requestor viene lasciata la libertà di definire sia i layout che le modalità di adempimento. La mancata uniformità in fase di offerta dei task potrebbe confondere l utente, risultando elemento di difficoltà in fase di svolgimento del task. In generale piattaforme poco strutturate potrebbero essere considerate più difficili. In figura 4.1 viene mostrata l homepage del servizio. Micro Workers MicroWorkers è un servizio per il crowdsourcing statunitense nato nel Mediamente offre 300 task giornalieri suddivisi in semplici categorie. I task di questa piattaforma richiedono sia lo svolgimento di semplici attività, come l inserimento di apprezzamenti su social network, sia l elaborazione di attività più complesse come la scrittura di articoli o recensioni. La piattaforma offre task in modo molto ordinato e strutturato. In figura 4.2 viene mostrata l homepage del servizio. Minute Workers Minute Workers è un marketplace per crowdsourcing contraddistinto da task brevi, schematici ed intuitivi. Nella stessa pagina si ritrovano istruzioni e prova richiesta. Il servizio desidera coinvolgere i propri utenti con un sistema di classifiche e livelli simile a quello dei videogames: gli aumenti di livello avvengono dopo il raggiungimento di specifiche quantità di task svolti. In figura 4.3 viene mostrata l homepage del servizio.

45 4.1 Piattaforme 37 Figura 4.1: Nell immagine uno screenshot della homepage di Amazon Mechanical Turk. (da [25])

46 38 Piattaforme e Task Figura 4.2: Nell immagine uno screenshot della homepage di Micro Workers. (da [26])

47 4.1 Piattaforme 39 Figura 4.3: Nell immagine uno screenshot della homepage di Minute Workers. (da [27])

48 40 Piattaforme e Task Short task Come si può immaginare dal nome, Short Task è una piattaforma che si popone di offrire task brevi e strutturati. Essa presenta mediamente 1000 task attivi. Il servizio è attivo dal febbraio del In figura 4.4 viene mostrata l homepage del servizio. Figura 4.4: Nell immagine uno screenshot della homepage di Short Task. (da [28]) 4.2 Task Dopo aver selezionato le piattaforme si passa ad analizzarne i task. Ognuno di essi presenta le seguenti informazioni: id - Identificativo univoco del task all interno della piattaforma; earn - Retribuzione offerta per l adempimento del task; timeneeded - Stima del tempo necessario per lo svolgimento del task;

49 4.2 Task 41 title - Titolo del task; requiredproof - Prova richiesta al worker al fine di dimostrare di aver svolto il task; idcreator - Identificativo univoco del creatore del task; description - Istruzioni delle attività da svolgere per risolvere il task. Volendo procedere all estrazione di tali task dalle piattaforme si è deciso di considerare strategiche tali informazioni. Popolazione di task Dopo aver selezionato 4 piattaforme ed averne analizzato la struttura dei task si è deciso di procedere all estrazione degli stessi al fine di costruirne un data-set. Si è optato per la costruzione di un software che estraesse in modo automatico e strutturato i task dalle piattaforme. L operazione di estrazione si è ripetuta quotidianamente dal 15 novembre 2012 al 30 novembre Ad operazione conclusa il data-set conta 2717 task prelevati, suddivisi in: 1154 task prelevati da Amazon Mechanical Turk ; 1302 task prelevati da Micro Workers ; 86 task prelevati da Minute Workers ; 175 task prelevati da Short Task. Infrastruttura Per rendere possibile tutto ciò si è optato per la costruzione di un software ad hoc, al quale è stato dato il nome di spider 1. Ad ogni avvio lo spider verifica se nelle piattaforme ci sono dei nuovi task che non siano ancora stati resi persistenti nel data-set. Se questi vengono trovati, l applicazione scarica il codice sorgente della pagina che li contiene, ne estrae le informazioni d interesse e le aggiunge alla collezione. Lo spider è stato interamente sviluppato in linguaggio Java, sfruttando le seguenti librerie esterne: il DBMS 2 di MySql, per permettere l accesso al database; 1 Gli spider sono dei software che analizzano i contenuti di una rete in un modo metodico e automatizzato al fine di estrarre informazioni da essi. 2 Il Database management system, detto anche motore di un database, è un sistema software progettato per consentire la creazione e la manipolazione di un database.

50 42 Piattaforme e Task le librerie Apache Commons, al fine di agevolare le operazioni di comunicazione e di autenticazione con le piattaforme; l ORM 3 Hibernate, per consentire una comoda mappatura tra gli oggetti di dominio dell applicazione e la relativa rappresentazione nelle tabelle del database; librerie JSoup ( contenenti un parser HTML che garantisce una pratica gestione del DOM 4 delle pagine. Tali librerie permettono di spostarsi agevolmente tra gli elementi della pagina. Questo consente di individuare ed estrarre rapidamente le informazioni desiderate. Ogni piattaforma struttura le pagine di proposta dei task in modo diverso dalle altre, per cui si è dovuto rendere il software il più modulare possibile. Nello specifico il software è formato da tre componenti principali: componente core contenente la logica applicativa comune a tutte le piattaforme. Afferiscono a tale insieme tutti gli oggetti e le classi di dominio; classi di repository, specifiche per ogni piattaforma, che offrono metodi per permettere il salvataggio dei task nel database; moduli di data mining, anche questi specifici per ogni piattaforma, i quali contengono le classi atte ad estrarre le informazioni d interesse contenute nelle pagine delle piattaforme. In figura 4.5 si può trovare uno schema dettagliato dell architettura adottata nella costruzione del software. In figura 4.6, viene mostrato un estratto del database contenente i dati strutturati. 4.3 Conclusioni Questo capitolo presenta le attività di esplorazione e di selezione delle piattaforme di crowdsourcing che hanno permesso di delineare nettamente il dominio dello studio. La fase di selezione dei marketplace ha permesso di far 3 L Object-Relational Mapping è una tecnica di programmazione che favorisce l integrazione di sistemi software aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS. 4 Il Document Object Model è una forma di rappresentazione dei documenti strutturati come modello orientato agli oggetti.

51 4.3 Conclusioni 43 Schema dell'architettura dello spider Task extractor + GUI Account configuration file Mecanical Turk data mining MicroWorkers data mining ShortTask data mining MinuteWorkers data mining core layer Task Domain Object domain layer Mecanical Turk Repository MicroWorkers Repository Short Task Repository MinuteWorkers Repository persistence layer DATASET_MECANICAL_TURK DATASET_MICROWORKERS DATASET_SHORTTASK DATASET_MINUTEWORKERS data layer Figura 4.5: Schema architetturale dello spider.

52 44 Piattaforme e Task Figura 4.6: Estratto del data-set contenenti i task di Short Task.

53 4.3 Conclusioni 45 emergere le criticità che deteriorano la user-experiance in fase di utilizzo delle piattaforme, specialmente da dispositivi mobili; la scelta è quindi ricaduta su quelle piattaforme che presentano il minor numero di tali problematiche. Successivamente sono state spiegate le motivazioni per cui si è deciso di concentrarci sulla qualità dei task, al fine di rendere il crowdsourcing un attività agevole anche per dispositivi mobili. Nella fase finale del capitolo viene descritta come si è svolta l attività di data mining; in particolare viene presentato lo spider che si è creato a tale scopo. Nel descrivere l applicazione vengono valutati sia aspetti funzionali che aspetti infrastrutturali. Il data-set formato attraverso l impiego dello spider sarà oggetto di studio nei prossimi capitoli.

54 46 Piattaforme e Task

55 Capitolo 5 Esperimento Uno: Predittivo In questo capitolo viene descritto il primo dei due esperimenti con volontari. Nel paragrafo 5.1 viene introdotto il lavoro che si intende svolgere. Viene quindi presentato il disegno sperimentale dell esperimento (paragrafo 5.3), contenente i dettagli delle attività organizzative e architetturali. In particolare nel paragrafo sono presentati i volontari che hanno accettato di partecipare all esperimento. Nel paragrafo viene descritta l infrastruttura costruita a supporto delle attività richieste. Vengono poi discusse le attività preliminari 5.4 dell esperimento. Nel paragrafo sono presentati i risultati dell esperimento con le relative analisi. 5.1 Introduzione Con il primo esperimento si vuole trovare risposta al secondo obbiettivo della tesi (paragrafo 3.2.2): verificare quanto le piattaforme selezionate nel capitolo precedente si prestino all utilizzo da dispositivi mobili. Nel perseguire tale obbiettivo, si è deciso di avvalersi della collaborazione di 16 volontari. Ai partecipanti viene richiesto di stimare le difficoltà immaginate nelle eventuali risoluzioni da desktop e da mobile rispetto 15 task ad essi assegnati. 5.2 La scelta dei task Per lo svolgimento dell esperimento si è deciso di procedere con la costruzione di un pool di 60 task provenienti da 5 diverse sorgenti. I task delle prime 4 sorgenti sono prelevati dal data-set precedentemente creato (paragrafo 4.2). 47

56 48 Esperimento Uno: Predittivo Figura 5.1: Primo esempio di task estratto da Amazon Mechanical Turk. (da [25]) Per ognuna delle 4 piattaforme sono prelevati in modo casuale 1 12 task. I rimanenti 12 task sono stati creati ad hoc, pensando ad una risoluzione da dispositivo mobile; per far ciò si è tenuto conto delle informazioni ricavate nella precedente fase di scelta delle piattaforme (paragrafo 4.1.2), dove sono emersi fattori critici per l usabilità, in particolare nelle risoluzioni da dispositivi mobili. Nella costruzione di tali task si sono evitati tutti quegli aspetti che rappresentano dei gravi ostacoli per le risoluzioni agevoli delle attività richieste dai singoli task; a quest ultima sorgente è stato dato il nome artificial. Nelle figure 5.1 e 5.2 vengono mostrati due esempi di task di Amazon Mechanical Turk ; nelle figure 5.3 e 5.4 si possono vedere due esempi di task prelevati da Micro Workers ; le figure 5.5 e 5.6 riportano due esempi di task prelevati da Minute Workers ; le figure 5.7 e 5.8 mostrano due task prelevati da Short Task ed infine nelle figure 5.9 e 5.10 sono visibili due esempi di task di tipo artificial. 1 Si è deciso di eliminare alcuni task che richiedevano lo svolgimento di comportamenti poco etici, come la creazione di caselle fittizie al solo scopo di generare spam.

57 5.2 La scelta dei task 49 Figura 5.2: Secondo esempio di task estratto da Amazon Mechanical Turk. (da [25]) Figura 5.3: Primo esempio di task estratto da Micro Workers. (da [26])

58 50 Esperimento Uno: Predittivo Figura 5.4: Secondo esempio di task estratto da Micro Workers. (da [26]) Figura 5.5: Primo esempio di task estratto da Minute Workers. (da [27]) Figura 5.6: Secondo esempio di task estratto da Minute Workers. (da [27])

59 5.2 La scelta dei task 51 Figura 5.7: Primo esempio di task estratto da Short Task. (da [28]) Figura 5.8: Secondo esempio di task estratto da Short Task. (da [28])

60 52 Esperimento Uno: Predittivo Figura 5.9: Primo esempio di task di tipo artificial. Figura 5.10: Secondo esempio di task di tipo artificial.

61 5.3 Disegno sperimentale Disegno sperimentale L idea di base dell esperimento è quella di richiedere ai volontari delle previsioni di difficoltà riguardanti dei possibili adempimenti dei task appartenenti al pool. Per ogni task mostrato, ad ogni partecipante si richiedono due previsioni: una per un eventuale adempimento da dispositivo mobile, l altra per uno desktop. Le valutazioni richiedono l inserimento delle stime nel sistema attraverso la scelta di uno tra sette valori predefiniti, distribuiti equamente in una scala di Likert bilanciata. Nel definire tali etichette si è cercato di rimanere il più possibile equidistanti nell intero range di valori, così da suddividere l intera scala in partizioni più simili possibili. Questa accortezza risulta importante, in quanto in seguito si dovranno convertire tali valori testuali in valori numerici, al fine di consentire l effettuazione del calcolo del valor medio tra le previsioni effettuate da più utenti. Valore Difficoltà 0 Banale 1 Molto facile 2 Facile 3 Media 4 Difficile 5 Molto difficile 6 Impossibile Tabella 5.1: Tabella delle associazioni tra valori numerici e previsioni di difficoltà selezionabili. Nella tabella 5.1 viene mostrato come è stata effettuata la mappatura tra i valori della scala di Likert usati per l inserimento delle previsioni ed i valori numerici usati per il calcolo delle medie. Immaginando una durata dell esperimento di 30 minuti, si è deciso di non richiedere ad ogni partecipante le previsioni di difficoltà di tutti i 60 task. Si è quindi optato per suddividere i volontari in 4 gruppi U a, U b, U c, U d, ciascuno da 4 partecipanti. Anche i task del pool sono stati divisi in 4 gruppi T a, T b, T c, T d, ciascuno composto da 15 task; tale suddivisione è fatta in modo tale che ogni gruppo contenga esattamente 3 diversi task per ognuna delle 5 sorgenti. Tale distribuzione viene esplicitata in figura Ai 4 utenti di ogni gruppo è stato chiesto di inserire la doppia stima di difficoltà solamente per uno dei quatto gruppi di task. Ad esempio, ai partecipanti di U a è stato richiesto di valutare i 15 task di T a. Dunque, per ognuno dei 60 task, si ha una coppia di previsioni (desktop e mobile) di 4 diversi utenti. I

62 54 Esperimento Uno: Predittivo mturk micro Workers minute Workers short Task artificial mt 1 mw 1 mw 1 st 1 at 1 T a mt 2 mw 2 mw 2 st 2 at 2 mt 3 mw 3 mw 3 st 3 at 3 mt 4 mw 4 mw 4 st 4 at 4 T b mt 5 mw 5 mw 5 st 5 at 5 mt 6 mw 6 mw 6 st 6 at 6 mt 7 mw 7 mw 7 st 7 at 7 T c mt 8 mw 8 mw 8 st 8 at 8 mt 9 mw 9 mw 9 st 9 at 9 mt 10 mw 10 mw 10 st 10 at 10 T d mt 11 mw 11 mw 11 st 11 at 11 mt 12 mw 12 mw 12 st 12 at 12 Figura 5.11: Rappresentazione grafica della modalità di suddivisione dei task in gruppi

63 5.3 Disegno sperimentale task sono stati presentati in ordine casuale: questa accortezza è stata presa al fine di garantire l assenza di errori, che si sarebbero potuti verificare, se ad ogni partecipante di un gruppo, fossero stati presentati gli stessi task nello stesso ordine. In tal caso, eventuali bias dovuti dall ordine di visualizzazione si sarebbero propagati per tutti e 4 i partecipanti, venendo notevolmente amplificati. Il mescolamento dell ordine serve proprio ad attenuare il più possibili tale fenomeno. Possiamo considerare l utente ua x U a. Indichiamo come P mobile (ua x, ta x ) la previsione di difficoltà con dispositivo mobile, data al task ta x T a dall utente ua x. In modo analogo ricaviamo P desktop (ua x, ta x ). Il task ta x, riceverà le previsioni dai quattro partecipanti di U a. Possiamo calcolare la media di queste quattro previsioni: P mobile (Ua, ta x ) = P desktop (Ua, ta x ) = 4 i=1 4 i=1 P mobile (ua i, ta x ) 4 P desktop (ua i, ta x ) 4 (5.1) (5.2) I valori appena calcolati indicano come sia stato valutato un task rispetto al gruppo di partecipanti ad esso assegnato. Avendo deciso di far valutare ogni task del gruppo T a esattamente ai soli 4 partecipanti del gruppo U a, possiamo considerare tale stima come definitiva, dunque: P mobile (ta x ) = P mobile (Ua, ta x ) (5.3) P desktop (ta x ) = P desktop (Ua, ta x ) (5.4) Dopo aver ripetuto tali operazioni per tutti i task, è possibile calcolare la difficoltà media dei task proposti da ogni sorgente (piattaforma). Per fare ciò si effettua un nuovo raggruppamento dei task, ma questa volta tenendo conto della piattaforma al quale appartengono. Supponiamo ad esempio di voler ricavare le difficoltà previste dai partecipanti nei 12 task offerti da Amazon Mechanical Turk (mturk). Tali task (mt 1 e mt 12 ) appartengono al gruppo mt urk: mt 1...mT 12 mt urk (5.5)

64 56 Esperimento Uno: Predittivo È sufficiente calcolare la media delle previsioni di tali task per avere la stima definitiva di difficoltà percepita per i task di Amazon Mechanical Turk: P mobile (mt urk) = 12 i=1 P mobile (mt i ) 12 (5.6) P desktop (mt urk) = 12 i=1 P desktop (mt i ) 12 (5.7) La differenza data da questi due valori equivale alla differenza sulla difficoltà percepita dei task di una certa piattaforma: mt urk = P mobile (mt urk) P desktop (mt urk) (5.8) Tale procedimento viene illustrato in figura Se mt urk > 0, allora i task proposti da mturk sono considerati più difficili in uno svolgimento da dispositivo mobile; all aumentare di tale valore la differenza percepita risulta maggiore. Analogamente se mt urk risulta essere un numero negativo, significa che i task sono ritenuti più semplici in uno svolgimento da mobile. Tuttavia questa situazione sembra improbabile, se si considera che i task sono stati prelevati da sorgenti rivolte a dispositivi desktop. Il calcolo del può essere fatto anche per i singoli task: questo può essere utile se si vuole analizzare quali siano all interno di una categoria i task con maggiore, cioè quelli da evitare di proporre ad utenti di dispositivi mobili. É possibile, dopo aver isolato tali task, confrontarli rispetto a tutti gli altri task della collezione. Si potrebbero dunque ricercare le caratteristiche che maggiormente accomunano i task con bassi e che allo stesso tempo differenziano tali task da quelli dell insieme complementare. Se tali attributi emergessero in modo evidente, sarebbero da considerare candidati importanti nell essere elementi di criticità per lo svolgimento di tali task da dispositivi mobili. I 15 task mostrati ad ogni utente sono suddivisi in gruppi da 3, ognuno contenente task prelevati da una diversa sorgente. Ai partecipanti viene richiesto di immaginare lo svolgimento di ognuno dei 15 task mostrati, sia da dispositivo desktop che da mobile. Nel far questo si sottolinea al volontario l importanza di immaginare, quanto più verosimilmente possibile, lo svolgimento di tutte le attività richieste dal task. Successivamente, al partecipante vengono richiesti gli inserimenti di due valori di stima, che riguardano il grado di difficoltà che il volontario immagina di ritrovare nello svolgimento del task sia da dispositivo desktop che da mobile. Ragionando sulla differenza delle due stime, è possibile sapere quanto più facile o difficile sia ritenuto un certo task, a seconda che venga svolto da desktop

65 5.3 Disegno sperimentale 57 Task estratti da mturk P mobile (mt 1 ) mt P desktop (mt 1 ) 1 P mobile (mt 2 ) mt P desktop (mt 2 ) 2 P mobile (mt 12 ) mt P desktop (mt 12 ) 12 P mobile (mturk) P desktop (mturk) (mturk) Figura 5.12: Figura esplicativa del calcolo di (mt urk)

66 58 Esperimento Uno: Predittivo o da mobile. Analizzando le stime effettuate per i task di una certa piattaforma, risulta dunque semplice ricavare dei valori di difficoltà medi che possano essere pensati come rappresentativi per la piattaforma stessa. Quest operazione permette di stilare delle classifiche di piattaforme, sia sulla base delle difficoltà percepite sia sulla base delle differenze di tali difficoltà. Queste classificazioni permettono di capire quali tra le piattaforme per crowdsourcing attualmente presenti nel mondo desktop possano essere utilizzate anche da mondo mobile, mantenendo alto il livello di produttività degli utenti. Un worker provvisto solamente di dispositivo mobile potrà dunque scegliere se procedere con l adempimento di compiti da piattaforme con task semplici, oppure optare per piattaforme che offrono task più complessi, ma che sarebbero complessi anche da desktop (tendenzialmente vengono maggiormente retribuiti) I gruppi sperimentali Per poter effettuare gli esperimenti sono stati selezionati 16 volontari, studenti di età compresa tra i 16 e i 30 anni. A queste persone si richiede un buon grado di dimestichezza sia con PC o notebook, sia con dispositivi di tipo mobile (in particolare smartphone). Il secondo requisito necessario per poter partecipare all esperimento è la conoscenza della lingua inglese, dato che tra le varie attività veniva anche richiesta la lettura e la comprensione di task reali, estratti da piattaforme in lingua inglese. Ai partecipanti, prima dell inizio dell esperimento, è stato richiesto di rispondere alle domande di un semplice questionario; le prime richiedono l inserimento di semplici informazioni personali come l età, il sesso e la conoscenza del significato della parola crowdsourcing. La seconda parte del questionario richiede l inserimento di alcune informazioni riguardo le abitudini di utilizzo delle tecnologie informatiche. In particolare ai volontari si richiede una stima del loro grado di abilità sia con dispositivi desktop che mobili. Successivamente per entrambe le tipologie di dispositivi si richiede una stima relativa al tempo di utilizzo giornaliero. Queste informazioni sono utili, oltre che per scopi statistici, anche per analizzare la coerenza dei valori inseriti con i risultati ottenuti dagli esperimenti Infrastruttura Per lo svolgimento dell esperimento si è deciso di optare per la costruzione di una piattaforma che faccia da supporto a tutte le fasi del lavoro. Attraverso di essa, i partecipanti devono poter visualizzare i task ed esprimere le loro previsioni di difficoltà. A tale scopo si è deciso di optare per GWT (Google

67 5.3 Disegno sperimentale 59 Figura 5.13: Interfaccia dell esperimento uno in seguito all inserimento di alcune previsioni. Gli indicatori verdi rappresentano i task già valutati. Web Toolkit), un framework molto potente per la creazione e la manutenzione di applicazioni web, anche complesse. Al fine di rendere comodo ed intuitivo l inserimento delle previsioni da parte dei volontari, la piattaforma è stata dotata dell interfaccia in figura L interfaccia permette la visualizzazione sequenziale dei task e l inserimento delle previsioni. Nel pensare ad una suddivisione dello schermo che permettesse di soddisfare tali requisiti si è deciso di riservare una grossa porzione dello spazio alla visualizzazione del frame contenente le istruzioni del task. Nel riquadro viene mostrata una delle pagine HTML, prelevate tra quelle selezionate dal dataset costruito in precedenza grazie allo spider. Da questa pagina sono stati eliminati i fogli di stile CSS e solo in alcuni casi sono state apportate lievi modifiche al layout, al fine di agevolare la fruizione dei contenuti da parte degli utenti. Questo è stato fatto per i task prelevati da piattaforme che offrono task visualizzati attraverso un layout non strutturato 2. Nella parte sottostante dello schermo, l interfaccia presenta la tabella nella quale gli utenti possono esprimere le proprie valutazioni sulle previsioni di difficoltà dei vari task. Al di sopra della tabella sono presenti quindici indicatori che mostrano quali task siano già stati valutati. In figura 5.15 si può notare come i task non anco- 2 In Amazon Mechanical Turk agli utenti è permesso non solo di caricare il proprio task all interno della piattaforma, ma anche di creare dei collegamenti verso l esterno. Questo comporta una serie di problematiche, come la mancata garanzia di uniformità dei layout.

68 60 Esperimento Uno: Predittivo Figura 5.14: Interfaccia dell esperimento uno al momento dell inizio dell esperimento

69 5.4 Attività preliminari 61 ra valutati siano rappresentati da un indicatore bianco, mentre per quelli già valutati è previsto un indicatore di colore verde. Infine l interfaccia offre due pulsanti che permettono lo scorrimento dei task. Figura 5.15: Interfaccia dell esperimento uno in seguito all inserimento di alcune previsioni. Gli indicatori verdi rappresentano i task già valutati. 5.4 Attività preliminari Prima dell inizio dell esperimento vero e proprio, ai partecipanti viene spiegato nel dettaglio cosa dovranno fare: in particolare si chiede loro di effettuare le personali previsioni, pensando esclusivamente alle difficoltà che le sequenze di attività necessarie allo svolgimento del task comportano. Questa direttiva viene data perché il partecipate potrebbe valutare le difficoltà dei task in base alla loro lunghezza o al loro layout. Tuttavia, spesso capita che task di qualche riga richiedano molto più tempo ed energie di task con descrizioni molto più lunghe.

70 62 Esperimento Uno: Predittivo Ai partecipanti viene chiesto di raccontare ciò che vedono e nello specifico di comunicare ciò che immaginano che il task richieda. Questo passaggio è fondamentale per avere la certezza che i volontari (non worker abituali) abbiano ben chiaro quali siano le istruzioni dei task. Così facendo, i volontari hanno la certezza di essere allineanti con le attività richieste e dunque possono preoccuparsi solamente di ragionare sulla difficoltà richiesta dai vari passi del task. I volontari vengono invitati a fare una carrellata di tutti i task da valutare prima di iniziare con le stime vere e proprie, in modo tale da avere una panoramica completa sulle difficoltà di tutti i possibili task, potendo così attribuire il giusto peso a tutti i valori della scala. Se questo non venisse fatto, si potrebbero verificare errori difficilmente controllabili. Ad esempio, se un partecipante valutasse banale il primo task visualizzato e poi passando a valutare il secondo lo reputasse più facile del primo, probabilmente etichetterebbe anch esso come banale. Questo comportamento comporterebbe una mancata discriminazione tra i due valori di difficoltà inseriti; tale perdita di informazioni si ripercuoterebbe negativamente sulla qualità delle misurazioni, introducendo degli inevitabili bias. Tutte queste raccomandazioni vengono fatte ai volontari tenendo conto dello stato psicologico che caratterizza un partecipante durante un esperimento: dunque si cerca di rassicurarlo, metterlo a proprio agio ed invitarlo a comunicare qualsiasi cosa che possa in qualche modo infastidirlo. Fattori esterni di questo tipo potrebbero alterare i risultati dell esperimento. 5.5 Risultati Risultati preliminari L esperimento si è svolto con successo. Nella quasi totalità dei volontari è prevalso uno spirito collaborativo mosso dalla curiosità suscitata dalle attività alle quali sono stati invitati a partecipare. I compiti richiesti dai task sono stati in larga misura compresi correttamente dai partecipanti. I volontari non hanno esitato a chiedere delucidazioni qualora non fossero risultate loro chiare le istruzioni del task. In alcune occasioni i partecipanti cercavano di capire quali fossero le motivazioni che spingono alcuni requestor a concedere delle retribuzioni per attività che a loro parere non avevano senso. Tali dubbi riguardavano anche i worker: alcuni partecipanti non si capacitavano di alcune basse retribuzioni offerte in cambio di prestazioni che richiedevano mezz ora o più. In tali circostanze, ai volontari è stato richiesto di continuare il test per non alterarne i risultati, posticipando tali spiegazioni a test concluso. Ad

71 5.5 Risultati 63 esempio, ad un partecipante è stato somministrato un task che richiedeva l inserimento di un apprezzamento in un social network, tutto ciò in cambio di qualche centesimo di dollaro. Il volontario trovando questo molto strano ha temporaneamente interrotto in test e mosso dalla sua curiosità ha richiesto spiegazioni. Il volontario è stato invitato a proseguire con il test con la promessa che appena sarebbe arrivato alla fine delle valutazioni avrebbe ricevuto una spiegazione convincente che giustificasse la retribuzione. Puntualmente a fine test, al partecipante è stata data una risposta frutto di ipotesi basate sulle esperienze personali e su studi presenti in letteratura [15, 16]. Tuttavia, un paio di volontari hanno affrontato il test con un atteggiamento difensivo. In entrambi i casi si è dovuto sollecitare la comunicazione con domande quanto più generiche, nel tentativo di mettere i partecipanti a proprio agio nel modo meno invasivo possibile, cercando di non influenzarli, così da mantenere valida l attendibilità del loro lavoro Risultati numerici Nelle figure 5.2, 5.3, 5.4, 5.5 vengono illustrate le tabelle con le previsioni effettuate dagli utenti dei gruppi A, B, C e D. I grafici 5.16 e 5.17 mostrano le previsioni di difficoltà sia da desktop che da mobile ottenute dai singoli gruppi. In tabella 5.6 vengono mostrati i risultati medi delle previsione di tutte le piattaforme. Piattaforma Diff. Desktop Diff. Mobile Amazon Mechanical Turk 2,75 3,92 Micro Worders 1,58 2,83 Minute Workers 1,42 2,58 Short Task 2,25 3,25 Artificial 0,33 1,17 Tabella 5.2: Previsioni medie di difficoltà per il gruppo A Analisi I grafici 5.16 e 5.17 confermano una buona omogeneità della distribuzione degli utenti e delle difficoltà dei task. Utenti di gruppi diversi hanno mediamente assegnato difficoltà simili alle piattaforme proposte. Fanno eccezione gli utenti del gruppo B che hanno valutato mediamente più facili i task delle

72 64 Esperimento Uno: Predittivo Figura 5.16: Grafico delle previsioni di difficoltà da desktop divise per gruppi. Figura 5.17: Grafico delle previsioni di difficoltà da mobile divise per gruppi.

73 5.5 Risultati 65 Figura 5.18: Grafico delle previsioni di difficoltà desktop e mobile divise per categoria. Figura 5.19: Grafico con le differenze tra previsioni mobili e previsioni desktop.

74 66 Esperimento Uno: Predittivo Piattaforma Diff. Desktop Diff. Mobile Amazon Mechanical Turk 2,42 3,83 Micro Worders 1,50 2,50 Minute Workers 0,67 1,58 Short Task 0,50 1,25 Artificial 0,33 0,50 Tabella 5.3: Previsioni medie di difficoltà per il gruppo B Piattaforma Diff. Desktop Diff. Mobile Amazon Mechanical Turk 2,83 4,00 Micro Worders 1,50 2,67 Minute Workers 1,67 2,58 Short Task 2,00 3,25 Artificial 0,42 1,17 Tabella 5.4: Previsioni medie di difficoltà per il gruppo C piattaforme Minute Workers, Short Task e artificial. La spiegazione di tali anomalie è da ricercarsi nella concomitanza delle seguenti cause: la selezione casuale dei task del gruppo B ha restituito task più semplici della media; gli utenti appartenenti al gruppo B sono particolarmente propensi a valutare più facili task che utenti di altri gruppi considerano più difficili. I grafici riassuntivi dell esperimento mostrano una situazione molto chiara. Il grafico 5.18 mostra le previsioni di difficoltà dei partecipanti per ogni piattaforma. Dal grafico si evince che Amazon Mechanical Turk è la piattaforma che offre i task più complessi. Tali task sono percepiti di difficoltà Piattaforma Diff. Desktop Diff. Mobile Amazon Mechanical Turk 2,83 3,75 Micro Worders 1,67 2,75 Minute Workers 1,50 2,75 Short Task 2,08 2,75 Artificial 0,42 0,75 Tabella 5.5: Previsioni medie di difficoltà per il gruppo D

75 5.5 Risultati 67 Piattaforma Diff. Desktop Diff. Mobile Amazon Mechanical Turk 2,71 3,88 1,17 Micro Worders 1,56 2,69 1,13 Minute Workers 1,31 2,38 1,07 Short Task 1,71 2, Artificial 0,38 0,90 0,52 Tabella 5.6: Previsioni di difficoltà e differenza ( ) delle stesse. media se svolti da dispositivo desktop e di difficoltà difficile se svolti da mobile. Le difficoltà previste dei task di Micro Workers, Minute Workers e Short Task risultano inferiori e simili tra loro. I task delle tre piattaforme sono immaginati molto facili e facili se svolti da dispositivi desktop e facili / medi se svolti da dispositivi mobile. Infine, i task artificiali da noi creati sono risultati quelli dal più semplice svolgimento previsto; questi sono considerati banali o facili sia che vengano svolti da desktop che da mobile. Questo primo grafico permette di dimostrare due importanti cose: 1. l assunzione (paragrafo 4.1.3) sull elevata difficoltà delle piattaforme non strutturate (come Amazon Mechanical Turk ) sembra corretta. Piattaforme offerenti task più strutturati sono percepite come più adatte al mondo mobile; 2. le ipotesi fatte nella creazione di task percepiti come più semplici sono risultate corrette; i task di tipo artificial sono risultati quelli con le previsioni di difficoltà più basse. Il grafico 5.19 mostra i tra le difficoltà previste da desktop e le difficoltà previste da mobile per ogni piattaforma. Le piattaforme in cui tale è basso sono quelle nelle quali è consigliato un adempimento da dispositivo mobile, in quanto la loro difficoltà prevista è superiore rispetto a quella da desktop solamente di una quantità minima. Il grafico mostra chiaramente che i task artificiali, creati appositamente per tale scopo, risultano molto più adatti ad essere proposti su dispositivi mobili rispetto a quelli delle piattaforme esistenti. Infine si può notare che l andamento del grafico 5.19 rispecchia l andamento del grafico 5.18; questo conferma che l aumento della difficoltà dei task incide maggiormente sui dispositivi mobili che su quelli desktop. Tuttavia, osservando le differenze tra Minute Workers e Short Task nei grafici 5.18 e 5.19 si può notare un dato in controtendenza rispetto all andamento generale: la prima piattaforma risulta essere tra le due quella che offre i task più difficili da svolgere sia da mobile che da desktop; tuttavia Short

76 68 Esperimento Uno: Predittivo Task offre un inferiore. Quindi, un utente mobile potrebbe decidere di svolgere task più semplici oppure task leggermente più difficili (Minute Workers), ma che lo sarebbero stati anche da desktop (Short Task). 5.6 Conclusioni In questo capitolo si è discusso dell esperimento predittivo con 16 volontari. Tale esperimento prevede la costruzione di un pool di 60 task. Di questi 48 sono accuratamente prelevati dal dataset precedentemente creato (paragrafo4.2) e 12 sono stati creati ad hoc, con l intento di aggirare le barriere di usabilità precedentemente riscontrate (paragrafo 4.1.2). Sia i volontari che il pool di task sono suddivisi in 4 gruppi. Agli utenti di ogni gruppo vengono richieste due previsioni di difficoltà per tutti i task del gruppo ad essi assegnato; queste riguardano le difficoltà immaginate in uno svolgimento del task con un dispositivo mobile e uno desktop. L insieme di tutte le previsioni consente di ricavare i valori medi delle difficoltà previste negli adempimenti dei task per ogni piattaforma; questi permettono di capire quali piattaforme offrono task meno difficoltosi sia da desktop che da mobile. Inoltre ragionando sulle differenze di tali valori è possibile scoprire in quali piattaforme vengano mantenute elevate performance anche da dispositivi mobili.

77 Capitolo 6 Esperimento Due: Operativo In questo capitolo viene descritto il secondo esperimento con utenti. Nel paragrafo 6.1 viene introdotto l esperimento. Nel paragrafo 6.2 vengono presentate le categorie di task di cui si richiede lo svolgimento da parte degli utenti. Successivamente (paragrafo 6.3) viene discusso di come sono creati i task. Nel paragrafo 6.4 sono presentati i gruppi sperimentali. Successivamente si discute dell infrastruttura (paragrafo 6.5) e dei layout (paragrafo 6.6) che hanno permesso lo svolgimento dell esperimento. Vengono poi discusse le attività preliminari (paragrafo 5.4). Infine sono presentati i risultati ottenuti e le relative analisi (paragrafo 5.5.2). 6.1 Introduzione Dopo aver effettuato il primo esperimento nel quale è stato richiesto ai partecipanti l inserimento delle personali previsioni di difficoltà, si passa allo svolgimento di attività meno valutative e più operative. Con il secondo esperimento si vogliono identificare 6 categorie di task sulla base di quelli comunemente richiesti dalle piattaforme di crowdsourcing. L esperimento vuole dare risposta alla domanda posta dal terzo obbiettivo (paragrafo 3.2.3): verificare quali categorie di task si prestino meglio da dispositivi mobili. Quest informazione risulterebbe molto utile se si dovesse decidere che tipologie di task offrire ad utenti mobili e quali tipologie continuare a proporre solamente ad utenti desktop. 6.2 Categorie di task Una delle prime problematiche che si deve affrontare consiste nella ricerca di categorie che possano risultare rappresentative delle attività comunemente 69

78 70 Esperimento Due: Operativo richieste dalle piattaforme di crowdsourcing. Tali categorie devono essere non solamente verosimili, ma anche discriminanti, in modo tale da semplificare la successiva attività di identificazione degli attributi che garantiscono il successo o il fallimento di una certa categoria. Dopo un accurata fase di ricerca di quali categorie potessero soddisfare tali requisiti, si è deciso di optare per un sottoinsieme delle categorie che Amazon Mechanical Turk suggerisce in fase di creazione dei task. Queste sono undici, ma avendo a disposizione solamente trenta minuti per effettuare l esperimento si è deciso di selezionarne sei, escludendo le categorie molto simili. Si è quindi cercato di offrire ai partecipanti task quanto più possibile diversi tra loro, in modo tale da rendere evidenti eventuali differenze di prestazioni. Le categorie selezionate sono le seguenti: categorization (categorizzazione di contenuti); moderation of an image (censura di immagini); sentiment (richiesta di opinioni); tagging of an image (etichettatura di immagini); transcription from an image (trascrizione di contenuti da immagini a testo); writing (scrittura di testi brevi) Categorization Nei task di tipo Categorization si mostrano ai worker una serie di immagini. Per ogni immagine è richiesto di specificarne la categoria selezionandola da una lista. Un esempio è il task di figura 6.1, in cui si richiede all utente di specificare da una lista, la stanza più adatta ad ospitare il mobile raffigurato. Tipicamente, i richiedenti di questo tipo di attività hanno la necessita di catalogare grosse collezioni di immagini, spesso reperite dal web o in modo artificiale Moderation of an Image Nella categoria Moderation of an Image si richiede un attività di censura su immagini. I task contenenti una galleria di immagini vengono mostrati agli utenti; essi devono individuare e contrassegnare le figure offensive, inopportune o lesive al buon costume. Il worker andrà quindi a fare un attività di censura sulla base del contesto richiesto. Ad esempio, se gli venisse richiesto di segnalare immagini sconvenienti ad essere mostrate ad un audience di bambini

79 6.2 Categorie di task 71 Figura 6.1: Esempio di task per la categoria categorization. (da [25]) potrebbe segnalare come non adatte, immagini che potrebbe valutare innocue ad un pubblico di adulti. Questa forma di censura è necessaria quando si vuole creare un filtro per collezioni di immagini di dubbia provenienza, come quelle reperite da web attraverso sistemi automatici, oppure caricate dagli utenti di social network. In figura 6.2 viene mostrato un esempio di task di questo tipo Sentiment Nella categoria Sentiment viene richiesto di specificare un personale grado d accordo rispetto ad una determinata affermazione. Questo genere di opinioni risulta molto utile in discipline come il marketing, in quanto sono dei metodi efficaci ed efficienti nel richiedere informazioni strategiche. Questi strumenti possono essere sfruttati per ottenere in breve tempo e con costi molto bassi informazioni come feedback di prodotti o opinioni su servizi. Ad esempio, una ditta manifatturiera potrebbe voler conoscere l opinione di una massa di persone rispetto un nuovo prodotto prima del definitivo lancio sul mercato. Un altra applicazione molto frequente nella richiesta di opinioni attraverso crowdsourcing è rappresentata dai sondaggi: in questo caso è consigliabile cautelarsi attraverso strumenti che permettano di avere un controllo maggiore su coloro che andranno a svolgere i compiti. Con il crowdsourcing puro si rischierebbe di non avere garanzia sul campionamento dei soggetti e questo avrebbe ripercussioni negative sulla qualità dei risultati dei test. In figura 6.3 è mostrato un esempio di un task in cui viene richiesta un opinione sul prezzo di un DVD e di un Blueray di una nota serie televisiva statunitense.

80 72 Esperimento Due: Operativo Figura 6.2: Esempio di task per la categoria moderation of an image. (da [25])

81 6.2 Categorie di task 73 Figura 6.3: Esempio di task per la categoria sentiment. (da [25])

82 74 Esperimento Due: Operativo Tagging of an Image L etichettatura di immagini è una delle attività più richieste nelle piattaforme di crowdsourcing. Lo scopo di tale attività è quello di assegnare dei tag 1 alle immagini. Questo permette a sistemi automatizzati di ordinare e catalogare le figure in base ai loro attributi. In figura 6.4 è mostrato un task in cui è richiesto l inserimento di tre tag che descrivano un immagine raffigurante una cupola di una chiesa. Figura 6.4: Esempio di task per la categoria image tagging. (da [25]) Transcription from an Image La categoria Transcription from an Image richiede di riportare in forma testuale alcune scritte presenti su immagini. Spesso questa attività viene richiesta per immagini che non è stato possibile trascrivere automaticamente attraverso scanner ottici. Anche i captcha appartengono a tale categoria. In figura 6.5 viene mostrato un esempio di un task in cui si richiede la trascrizione di alcune informazioni presenti su uno scontrino fiscale. 1 I tag sono delle brevi etichette assegnate alle immagini al fine di descriverne il contenuto.

83 6.3 I task 75 Figura 6.5: Esempio di task per la categoria image transcription. (da [25]) Writing I task della categoria Writing richiedono la scrittura di testi brevi. Questi possono essere recensioni di film o libri, esperienze d utilizzo di alcuni prodotti (ad esempio di alcuni farmaci), richiesta di risposte ad alcune domande o di soluzioni ad alcune problematiche. In genere è richiesta una lunghezza minima nelle risposte (qualche centinaio di caratteri). In figura 6.6 viene mostrato un task in cui si richiede l inserimento di una descrizione testuale di un sito web. 6.3 I task Dopo aver specificato le categorie alle quali i task devono appartenere, è possibile procedere alla creazione degli stessi. Come per l esperimento precedente, anche in questo caso la creazione dei task avviene tenendo conto delle criticità emerse in fase di selezione delle piattaforme Tuttavia, in questo esperimento la creazione dei task deve assicurare che questi aderiscano perfettamente a una categoria e che task della stessa categoria siano quanto più possibile simili tra loro. A tale scopo si è deciso di creare un pattern 2 per ciascuna categoria che. Tali pattern guidano la costruzione dei task. 2 Un pattern è un modello al quale ogni task creato deve aderire.

84 76 Esperimento Due: Operativo Figura 6.6: Esempio di task per la categoria writing. (da [25]) Categorization Il pattern per la categorizzazione di immagini prevede la visualizzazione di 8 immagini. Per ognuna di esse viene richiesto di specificare una categoria d appartenenza tra 5 disponibili. I 4 task riguardano 4 semplici tematiche: classi animali: anfibi, mammiferi, pesci, rettili, uccelli. continenti: Africa, America, Asia, Europa, Oceania. età di persone: neonati,

85 6.3 I task 77 bambini adolescenti, adulti, anziani. zone casa: bagno, camera, cucina, giardino, salotto. Dopo aver visualizzato un immagine, il partecipante deve specificare la categoria opportuna attraverso uno spinner. Figura 6.7: Mock-up dei task aderenti al pattern categorization

86 78 Esperimento Due: Operativo Moderation of an Image I task di tipo moderation of an image prevedono la visualizzazione di 8 immagini. Ai volontari viene richiesta un attività di censura di immagini. Essi devono segnalare attraverso due toggle button se ogni immagine è da ritenere consentita o offuscata, per una visualizzazione da parte di bambini. Figura 6.8: Mock-up dei task aderenti al pattern moderation Sentiment Il pattern sentiment prevede che al partecipante vengano mostrate 6 frasi. Per ognuna di esse è richiesto l inserimento del personale grado di accordo attraverso uno spinner. Il partecipante può scegliere tra: nulla; poco; mediamente; molto; completamente.

87 6.3 I task 79 Il pattern prevede che ogni task della categoria sentiment sia formato da 4 frasi e che ognuna di esse tratti una delle seguenti tematiche: attualità; internet; imprese umane; questioni etiche; servizi pubblici; politica. Questa accortezza è stata presa per cercare di uniformare le difficoltà dei task di tipo sentiment tra i vari gruppi di partecipanti. Figura 6.9: Mock-up dei task aderenti al pattern sentiment Tagging of an Image Il pattern tagging of an image prevede che al partecipante siano mostrate 4 immagini. Per ognuna di esse è richiesto l inserimento di 3 etichette che ne descrivano al meglio il contenuto.

88 80 Esperimento Due: Operativo Figura 6.10: Mock-up dei task aderenti al pattern image tagging Transcription from an Image Il pattern transcription from an image prevede che al partecipante vengano mostrate 4 immagini. Ognuna di esse contiene dei captcha o delle ricevute fiscali digitalizzate attraverso uno scanner. Nel primo caso al partecipante è richiesta la trascrizione delle scritte contenute nei captha, mentre nel secondo la trascrizione della data e dell importo presenti nello scontrino Writing Il pattern writing prevede che al partecipante siano mostrate 4 tematiche. Per ognuna di esse è richiesta la scrittura di un testo di almeno 100 caratteri. La tematiche sono: attualità; opinione su musica o cinema; accadimenti importanti; cucina.

89 6.4 Gruppi sperimentali 81 Figura 6.11: Mock-up dei task aderenti al pattern image transcription Nello svolgimento di questa tipologia di task da dispositivo mobile si è suggerito al partecipante di inserire il testo attraverso la funzione Speech to Text. 6.4 Gruppi sperimentali Per ognuna delle 6 categorie si è deciso di creare 4 task diversi per un totale di 24 task. Ogni task, internamente alla sua categoria, è etichettato con una lettera dalla A alla D. Anche i 16 partecipanti all esperimento (gli stessi che hanno preso parte all esperimento precedente) sono divisi in quattro gruppi numerati da 1 a 4. L esperimento si svolge in 4 sessioni consecutive, ognuna delle quali comprende lo svolgimento dell esperimento da parte di 4 partecipanti di gruppi diversi. Nelle sessioni dispari (prima e terza) le risoluzioni dei task iniziano da dispositivi desktop, mentre nelle sessioni pari (seconda e quarta) si inizia da dispositivo mobile. Per assicurare che ad ogni partecipante vengano proposti task diversi nelle risoluzioni desktop, rispetto a quelle da mobile si utilizza lo schema di proposizione in figura I task offerti nello svolgimento da dispositivi mobili per i partecipanti del gruppo 1 vengono offerti per lo svolgimento da desktop ai partecipanti del gruppo 2 e viceversa. Analogamente viene fatto per i partecipanti dei gruppo 3 e 4. Si

90 82 Esperimento Due: Operativo Figura 6.12: Mock-up dei task aderenti al pattern writing utilizza tale accorgimento al fine di non agevolare nessuna delle due tipologie di dispositivi. Si ritiene che una modalità di somministrazione dei task che non alteri l ordine del dispositivo adoperato per primo possa migliorare le prestazioni ottenute con esso. Ciò comporterebbe un inevitabile alterazione dei risultati dello studio. 6.5 L infrastruttura Per effettuate l esperimento si è deciso di optare per la costruzione di una piattaforma che consenta lo svolgimento dei task di ogni categoria, sia da dispositivo desktop che mobile. Come per l esperimento precedente si è deciso di adottare GWT per la realizzazione dell infrastruttura generale. Inizialmente si è pensato che la soluzione di far svolgere concretamente i task da browser fosse la scelta migliore, sia per i dispositivi mobili che per quelli desktop. Tale convinzione è andata scemando quando ci si è accorti che l interazione da dispositivo mobile, con il codice generato da GWT, nasconde una serie di problematiche in fase di utilizzo che non possono essere trascurate. Si è dunque deciso di optare per la creazione di un applicazione per Android (il sistema operativo dello smartphone che si è deciso di utilizzare per l esperimento), che

91 6.5 L infrastruttura 83 Sessioni 1 e 3 Gruppo utente Primo esperimento tipo dispositivo gruppo task Secondo esperimento tipo dispositivo gruppo task 1 mobile A desktop B 2 mobile B desktop A 3 mobile C desktop D 4 mobile D desktop C Sessioni 2 e 4 Gruppo utente Primo esperimento tipo dispositivo gruppo task Secondo esperimento tipo dispositivo gruppo task 1 desktop B mobile A 2 desktop A mobile B 3 desktop D mobile C 4 desktop C mobile D Figura 6.13: Assegnazione dei task a seconda delle sessioni e dei gruppi utente

92 84 Esperimento Due: Operativo permettesse di aggirare tali complicazioni. Lo scenario emerso vede dunque una piattaforma scritta in linguaggio Java in parte compilata in linguaggio Javascript. Queste sorgenti vengono eseguite su un web server Tomcat. I partecipanti accedono alle funzionalità della piattaforma attraverso le pagine generate in Javascript quando operano da dispositivo desktop e attraverso applicazione Android quando vi accedono da smartphone. Il server Java mette a disposizione i services che consentono la comunicazione asincrona attraverso RPC 3. Inoltre, il server contiene tutta la logica di business della piattaforma e le classi di repository che manipolano i dati da un database MySql attraverso l ORM(Object-relational mapping) Hibernate. Ai volontari è stato messo a disposizione il seguente hardware: Notebook Asus K95V, con display da 18 pollici (risoluzione 1920 per 1080 pixel), processore Intel Core i7-3610qm - 2.3GHz, 16G di memorie RAM e scheda video GEFORCE GT 630M 1GB. Il sistema operativo montato sulla macchina è Windows Seven Home Premium - 64bit e il browser dal quale si effettuano i test è Google Chrome Smartphone Samsung Galaxy Gio S5660, con display da 3,2 pollici (risoluzione 480 per 320 pixel), processore 800MHz MSM Turbo, 150MB di memoria RAM. Il sistema operativo montato sul dispositivo è Android Gingerbread. 6.6 I layout Nel voler pensare a una piattaforma orientata a due tipologie di dispositivi molto diverse, non è possibile trascurare le modalità di interazione e visualizzazione degli stessi. Si è dunque deciso di optare per due diversi layout che garantissero la miglior interazione possibili con entrambi i dispositivi. I layout sono pensati per essere dinamici e adattarsi alle dimensioni degli schermi nel quale vengono visualizzati. Quest accortezza richiede una particolare attenzione nella fase di sviluppo ma tale fatica verrà ripagata qualora si decidesse di riutilizzare la piattaforma in esperimenti futuri. Il layout desktop prevede la visualizzazione di tutte le attività dei task contemporaneamente. Questo può essere condivisibile o meno, in quanto sfruttare l intero schermo per visualizzare più informazioni possibili risulta comodo per avere una visione d insieme del task. Tuttavia questo potrebbe comportare un 3 Le Remote Procedure Call sono delle chiamate di procedure remote da parte di un programma presente su un computer diverso da quello in cui risiede la procedura.

93 6.6 I layout 85 calo della concentrazione nei partecipanti, in quanto i task mostrati potrebbero risultare elementi di disturbo. Inoltre Dana Chandler e John Horton nel loro articolo Labor Allocation in Paid Crowdsourcing: Experimental Evidence on Positioning, Nudges and Prices [13] evidenziano che gli esseri umani in presenza di una galleria di immagini presentano un forte orientamento a concentrarsi sulle immagini in alto a sinistra dello schermo; ciò potrebbe introdurre un bias che rischierebbe di compromettere i risultati. In figura 6.14 è mostrato un esempio del layout per dispositivi desktop. Figura 6.14: Versione desktop del layout della piattaforma. Il layout per mobile è sviluppato in verticale. I partecipanti possono passare da un task a quello successivo attraverso un azione di scrolling verticale. Ogni task è sempre visibile per intero nello schermo e gli inserimenti delle informazioni da parte dei volontari avvengono attraverso i widget standard di Android. In figura 6.15 è mostrato un esempio del layout per dispositivi mobili.

94 86 Esperimento Due: Operativo Figura 6.15: Versione mobile del layout della piattaforma.