I danni che il maltempo delle ultime settimane ha causato alle nostre strade sono sotto agli occhi (e alle ruote) di tutti! Occorre mobilitare gli automobilisti e gli autotrasportatori per creare una mappa oggettiva dello stato delle strade e pianificare gli interventi da attuare tempestivamente.

L’Università di Urbino mette a disposizione di tutti l’applicazione SmartRoadSense, che usa gli accelerometri dei cellulari per rilevare automaticamente la qualità del manto stradale su cui si sta viaggiando. I dati raccolti vengono comunicati in modo anonimo ad un server che li aggrega e li rende disponibili in formato aperto nell’arco di poche ore sul sito web http://smartroadsense.it/.

I dati già in possesso dei server consentiranno anche di confrontare lo stato attuale delle strade con quello precedente agli eventi atmosferici delle ultime settimane, fornendo utili indicazioni sulle conseguenze del maltempo.

L’utilizzo di SmartRoadSense (disponibile per Android e iOS) è semplicissimo e automatico. Questo video ne illustra il funzionamento:

SmartRoadSense è sviluppato dall’Università di Urbino in collaborazione con i partner del progetto europeo Crowd4roads, tra i quali la Regione Marche, la Regione Abruzzo e Bla Bla Car.

“Ci sono casi in cui occorre fare appello al senso civico individuale per dare vita ad una forma di intelligenza collettiva utile a tutti. – dice Alessandro Bogliolo, coordinatore del progetto – La tecnologia ci offre solo nuovi strumenti per farlo.”

Nell’edizione 2017 a Valencia sono stati trattati diversi temi attuali, come la crescente proliferazione di cosiddetti MOOC (Massive Open Online Course) e delle modalità con cui vengono preparati e svolti, l’insegnamento del “coding” o del pensiero computazionale per giovani ed adulti, approcci innovativi alla didattica, robotica, realtà virtuale e tanti altri temi.

Durante la sessione iniziale, il dirompente Bryan Alexander (dirompente anche in termini di barba) ha più volte ripetuto l’importanza di lasciarsi ispirare da tecnologie attuali e future, sfruttarne le potenzialità in qualità di strumenti di comunicazione ed educativi, in modo da trasformare l’insegnamento in un processo attivo e collaborativo. Gli studenti stessi diventano parte attiva: creatori, non consumatori, del processo educativo.

“The future is not given to you. […] You are world creators.” ~ @BryanAlexander #INTED2017 pic.twitter.com/faKgTrQu0v

— Lorenz Klopfenstein (@LorenzCK) March 6, 2017

Diversi interventi si sono incentrati sulle difficoltà dei (nuovi) docenti nell’approcciarsi in maniera efficace all’insegnamento, quando il loro ruolo accademico risulta distribuito tra ricerca, insegnamento e compiti amministrativi. La formazione dei docenti come processo e priorità delle istituzioni accademiche è stato un tema ripreso da diverse punti di vista, anche nella declinazione orientata ai MOOC, dove i docenti si scontrano con nuove tecnologie e forme di insegnamento.

Alcune sessioni erano dedicate in particolare alla gestione di lezioni in streaming video, discutendo i meriti di questo strumento, le difficoltà solitamente incontrate, configurazioni e strumenti utilizzabili, incluse delle modalità di annotazione e di aggiunta di elementi interattivi (ad esempio domande a scelta multipla), per renderne più interessante la visione. Un interessante studio di Markus Westner metteva in correlazione la pubblicazione di lezioni in streaming ed i risultati ottenuti dalla classe. In particolare, la disponibilità di video-lezioni, negli esempi riportati, conduceva ad un calo di oltre il 33% nel numero di studenti presenti in classe, con un 56% di studenti in media che visualizzavano tutti i video. Tuttavia, la disponibilità di queste risorse non ha avuto un impatto statisticamente significativo sul risultato finale. D’altro canto, la frequenza delle lezioni in presenza è correlata positivamente con il voto all’esame.

Anche sul fronte della cosiddetta “digital literacy”, della diffusione delle conoscenze digitali nelle scuole primarie e secondarie, diversi interventi si sono incentrati su collaborazione internazionale e su tecniche e modalità di insegnamento innovative. Ad esempio “CaRoMtE”, un progetto europeo condotto da una partnership Belga, Italiana e Spagnola per l’introduzione dei concetti di coding e robotica basati su strategia e linguaggio comune. Oppure “Scratching the Surface”, un progetto pilota sovvenzionato da Google che ha coinvolto alcune scuole medie del South Carolina per l’insegnamento dei concetti fondanti della programmazione tramite Scratch.

Durante la conferenza sono stati inoltre presentati due lavori sviluppati nell’egida del Corso di Laurea in Informatica Applicata. Il gioco di carte “unplugged” CodyRoby è stato riadattato in un’esperienza di realtà aumentata, grazie al lavoro del laureando Andiy Fedosyeyev, che ha condotto alla realizzazione dell’applicazione mobile per Android “CodyRobyAR”. L’app trasforma un gioco con requisiti bassissimi in un’esperienza interattiva di apprendimento che si basa su strumenti quotidiani ed alla portata di tutti come uno smartphone ed alcune stampe su carta. Inoltre, sono stati presentati anche gli esperimenti basati sul collegamento di marker temporali o fisici con dei bot su piattaforme di messaggistica online, che hanno portato alla realizzazione di eventi come la caccia al tesoro guidata da bot a Urbino.

All’interno di CodeMOOC, un massive open online course (corso aperto online su larga scala) offerto dall’Università di Urbino ed incentrato sul pensiero computazionale ed il coding, si è pianificato per il 20 ottobre lo svolgimento di un quiz di coding su larga scala. Utilizzando soltanto un client Telegram ed uno scanner di codici QR, i partecipanti hanno avuto la possibilità di partecipare al gioco e di sfidare oltre 900 gruppi di varie località d’Italia.

I partecipanti si potevano registrare ad un canale Telegram, sul quale sono state pubblicate le istruzioni del gioco poco prima dell’evento. All’inizio del gioco è stato pubblicato il collegamento ad uno stream live su Youtube, attraverso il quale venivano diffuse ulteriori istruzioni e le domande del quiz.

Per ogni quiz assegnato durante il gioco, il bot Telegram pubblicava un collegamento speciale sul canale pubblico. Questo collegamento conduceva ad una conversazione privata tra partecipante e bot, sfruttando il cosiddetto deep linking di Telegram. Siccome ogni quiz del gioco era identificato da un particolare codice unico, il deep link, dopo aver condotto il partecipante alla conversazione privata, inviava anche un comando nascosto:

/start IY4

(Dove il codice IY4 identifica il 4° quiz dell’evento.)

I partecipanti potevano partecipare ai quiz anche scansionando direttamente un codice QR mostrato nello stream Youtube, che a sua volta conteneva il medesimo deep link.

Una volta attivato tramite il collegamento, il bot chiedeva all’utente di fornire la risposta al quiz.
Appena l’amministratore del quiz chiudeva la domanda (semplicemente scrivendo la risposta corretta al bot tramite una conversazione privata), il bot classificava tutte le risposte corrette ricevute in base al timestamp di ricezione e le rendeva pubbliche sul canale. Le prime 3 risposte corrette venivano premiate con l’assegnazione di alcune, inestimabili, medaglie emoji. ?

Gestione dei messaggi

Un totale di 974 partecipanti (intesi come singoli utenti Telegram) hanno partecipato all’evento. Siccome ogni utente poteva registrarsi per conto di un gruppo di persone (rappresentandolo come capogruppo), il conteggio sale ad un totale di 9689 persone di partecipanti. 14 domande sono state poste durante il gioco, raccogliendo un totale di 7004 risposte dai partecipanti, durante circa un’ora e mezza di gioco.

In altre parole: un sacco di messaggi sono stati scambiati con il nostro bot nell’arco di pochissimo tempo.

Telegram supporta due diverse modalità di ricezione dei messaggi: pull e push.

Modalità Pull

In modalità Pull, il bot si collega periodicamente ad un end-point HTTP dei server Telegram e scarica tutti o parte dei messaggi in coda per la consegna. Il meccanismo di consegna può essere personalizzato, ad esempio scaricando una sequenza di messaggi in un unico collegamento oppure utilizzando l’opzione di long polling per rendere bloccante la richiesta ed attendere che vi siano dati disponibili lato server.

Sulla carta questa modalità assicura maggiore efficienza: le richieste sono controllate dal server che ospita il bot, possono essere gestite con più facilità ed un gran numero di messaggi può essere trasferito all’interno della stessa comunicazione HTTP.

Tuttavia, operazioni pull sono, per natura, sincrone. Le API di Telegram non permettono più di una richiesta concorrente (visto che, ovviamente, le singole richieste pull operano sequenzialmente sulla stessa coda di messaggi). Mentre trasferire un singolo grande payload di messaggi e processarli in un unico passo di decodifica JSON è potenzialmente più efficiente, quello che accade in effetti è che in questa modalità il tempo medio di risposta aumenta. Inoltre, dopo la fase di scaricamento e di decodifica, il parallelismo è interamente compito dello sviluppatore. La gestione dei messaggi su diversi processi o thread paralleli può essere più o meno difficile in base al proprio ambiente di programmazione: in Go si può invocare una goroutine per ogni messaggio, mentre la stessa cosa può essere fatta usando dei task async su .NET.

Modalità Push

Questa modalità—che per inciso è l’unica modalità disponibile su diverse altre piattaforme di messaggistica—baratta la fase di un singolo trasferimento dati molto efficiente per una moltitudine di operationi di gestione messaggi che avvengono in parallelo.

Invece di aspettare che il bot contatti il server Telegram per ottenere nuovi messaggi, eventuali aggiornamenti sono inviati direttamente al server web del bot attraverso un end-point ad un URL definito dallo sviluppatore (Telegram richiede una connessione HTTPS, un dominio ed un certificato valido). Invece di doversi occupare dei dettagli implementativi della gestione parallela dei messaggi, questa modalità permette di sfruttare i punti di forza intrinseci di un server web: la gestione di un grande numero di connessioni in ingresso e la loro gestione efficiente.

Risultati

In base ai nostri log, ben 7,414,458 messaggi sono stati inviati al nostro bot tramite Telegram, durante circa 80 minuti di gioco.

In media il bot ha ricevuto oltre 380 messaggi per minuti, con un picco di circa 1200. Guardando attentamente il grafico è possibile intuire quando sono state poste le 14 domande del quiz.

Inizialmente il nostro bot era stato configurato per operare in modalità pull, con una gestione sincrona dei messaggi in ingresso, visto che questa modalità permette di sviluppare e fare debug in maniera molto comoda. Tuttavia, appena l’evento ha avuto inizio, abbiamo subito scoperto che la coda dei messaggi in ingresso stava crescendo a dismisura e il nostro bot semplicemente non riusciva a tenere il passo dei giocatori.
Siamo riusciti a passare rapidamente alla modalità push. Dopo un paio di minuti il bot è riuscito a mettersi in paro con i messaggi, dopodiché non si sono verificati altri problemi di responsività nella comunicazione con i partecipanti.

Il bot era installato su una macchina quad-core a 2.6 GHz, con 2 GB di RAM.

Concludendo, la modalità pull è perfettamente adatta per lo sviluppo dei bot, visto che permette agli sviluppatori di controllare il flusso di messaggi in ingresso e di effettuare un attento debugging del codice. Tuttavia, probabilmente non vale la pena implementare un metodo efficiente (e corretto) di gestione dei messaggi tramite modalità pull. Come già suggerito da altri, è molto più sensato affidarsi ad un server web per la gestione efficiente di richieste parallele invece di provare a reinventare la ruota.

Più generalmente—e questo è molto importante nel contesto della recente attenzione ai bot come rimpiazzo delle applicazioni mobili—l’utilizzo di un bot al posto di un sito web o altro ci ha dato un fondamentale vantaggio. La piattaforma di messagistica, Telegram in questo caso, funge da “load balancer” estremamente scalabile tra gli utenti ed il proprio servizio. La piattaforma gestisce la coda dei messaggi, l’invio, la consegna e la notifica degli utenti—in sostanza Telegram offre una incredibile infrastruttura molto sofisticata ad un costo nullo. Questo permette agli sviluppatori di bot di concentrarsi sullo sviluppo del servizio invece di doversi occupare dei fondamenti.

Questo evento dello Europe Code Week è stato un’ottima opportunità per valutare gli effetti di un carico di lavoro inusuale su un bot (per quanto ci riguarda). Altri eventi di questa natura verranno organizzati in futuro e ci aspettiamo di poter valutare altri aspetti legati alle prestazioni ed alla scalabilità in maggiore dettaglio.

Il codice utilizzato durante l’evento è disponibile su Github.

Il gioco è stato sviluppato durante la settimana precedente l’evento e l’intero team alle spalle della caccia al tesoro ha impiegato i concitati minuti appena prima dell’inizio sistemando gli ultimi bug. (Beh, la maggior parte di essi.)

La summer school, rivolta agli insegnanti di tutte le classi, ha avuto come obiettivo principale quello di portare il coding nelle scuole, cercando di coinvolgere sia gli insegnanti che i giovani studenti. Pertanto, era logico che la stessa caccia al tesoro, chiamata “Urbino Code Hunting”, si basasse su giochi di coding.

Ciò che ha reso interessante la caccia al tesoro è che l’intero processo di registrazione, l’effettiva caccia, la soluzione degli indovinelli e le altre meccaniche di gioco erano gestite direttamente da un bot Telegram. Chiunque avesse un account Telegram poteva facilmente registrarsi nei 4 giorni precedenti il gioco semplicemente iniziando una conversazione con lo stesso.

Le registrazioni al gioco erano gestite da una comune conversazione con il bot.

Il bot chiedeva agli utenti di risolvere un gioco “preliminare” (per preparare i giocatori a ciò che sarebbe venuto dopo e lavorare a un qualche tipo di captcha), da quanti altri partecipanti sarebbe stata composta la squadra oltre al capogruppo, e il nome del gruppo.

Solitamente una caccia al tesoro chiede ai giocatori di trovare oggetti nascosti o raggiungere posti segreti basandosi su indizi, più o meno vaghi. Nel nostro caso, il gioco effettivo era costruito attorno indovinelli di coding assegnati dal bot, ma non sul riconoscere i posti grazie agli indovinelli, sia perché il tema del gioco era il coding, sia perché molti dei partecipanti non conoscevano bene la città. Dunque le postazioni da raggiungere erano indicate esplicitamente dal bot.

Il gioco vero e proprio era così strutturato:

• 1) Ogni gruppo ha una postazione casuale da raggiungere (un’ubicazione geografica precisa che corrisponde a un punto sulla mappa).
• 2) Raggiunto il posto assegnato, il gruppo scatta un selfie e lo invia al bot.
• 3) Il bot sceglie uno degli indovinelli di coding e aspetta la risposta della squadra. Il bot obbliga ad un’attesa di 1 minuto tra un tentativo e l’altro.
• 4) Se la soluzione è corretta, si ottiene dal bot un nuovo indizio per l’enigma finale.
• 5) Andare al punto 1.

Abbiamo identificato 30 postazioni ben distribuite nella città, contrassegnate da una descrizione, una precisa posizione GPS, un ID numerico, e un codice segreto (16 caratteri alfanumerici casuali).

Ogni posto aveva il suo codice segreto di 16 caratteri.

Come faceva il bot ad accertarsi che il gruppo avesse raggiunto la propria destinazione? Semplice. Avevamo stampato 30 cartelli di carta (su fogli A4), uno per ogni postazione, con uno speciale QR Code collegato a un URL che seguiva questo schema:

https://telegram.me/treasurehuntbot?start=0123456789ABCDEF

Questo link utilizza la funzione Telegram di deep linking: dopo aver aperto l’URL attraverso la scansione del QR Code, il telefono avvia automaticamente il client Telegram e invia la sequenza “/start 0123456789ABCDEF” al nostro bot, senza mostrarla effettivamente all’interno della conversazione. Dato che ogni QR Code conteneva il codice segreto di 16 caratteri della postazione all’interno dell’URL, il bot sapeva con certezza quale codice il gruppo aveva scansionato e dunque la postazione raggiunta.

Il bot guidava ciascun gruppo lungo la propria strada attraverso una sequenza di 12 posizioni. Per assicurarsi che le squadre non si seguissero fra loro e che non si radunassero nella stessa area, tale sequenza è stata scelta casualmente per ogni team.

Al fine di assicurare il massimo della correttezza, le sequenze di postazioni sono state generate in anticipo con un limite alla lunghezza massima (e minima).

Gli enigmi, che erano erogati non appena un gruppo raggiungeva una postazione ed aveva inviato un selfie di conferma, erano basati sui quiz CodyRoby. Questi semplici giochi di logica utilizzano convenzioni condivise, come i blocchi colorati di pseudo-codice Blockly usati in Code.org e le carte coding CodyRoby.

Esempio di domanda.

Tutti gli indovinelli richiedevano almeno un paio di minuti per essere risolti e la risposta poteva essere data con un semplice messaggio di testo, solitamente una singola lettera o un singolo numero. Le risposte venivano accettate in modo magnanimo, con spazi bianchi, in maiuscolo o minuscolo, e in varie formattazioni. Le risposte sbagliate obbligavano ad un’attesa forzata di 60 secondi prima del tentativo successivo.

Le risposte corrette, invece, non soltanto permettevano al gruppo di proseguire, ma lo premiavano anche con un importante indizio che sarebbe poi servito per risolvere l’ultimo rebus: non appena una squadra raggiungeva l’ultima posizione (che ci siamo assicurati fosse la stessa per tutti i gruppi), le veniva consegnata una mappa (una vera, tangibile, autentica mappa di carta) da usare per scovare il posto esatto in cui era nascosto l’ambito premio.

Il primo gruppo che lo avesse raggiunto, avrebbe vinto il premio e ricevuto un altro meraviglioso QR Code. (E comunque, chi è che non ama i QR Code?) Quest’ultimo codice segnalava la fine del gioco per tutti i partecipanti.

Un canale Telegram era usato per trasmettere informazioni, condividere i selfie, e rendere il gioco più coinvolgente.

Il canale Telegram Urbino Code Hunting è stato creato il giorno del gioco e tutti i partecipanti sono stati invitati ad aderirvi. I principali progressi dei gruppi erano trasmessi nel canale, insieme a tutti i selfie scattati dalle varie postazioni. Il canale permetteva ai partecipanti e a noi di monitorare lo stato del gioco, e dunque di renderlo più coinvolgente mano a mano che i gruppi raggiungevano la loro destinazione finale.

Una parte di tutti i selfie collezionati dal bot.

Il bot è stato gestito da un programma PHP e da un database MySQL, assemblati in meno di una settimana. Il codice sorgente è stato pubblicato su Github sotto licenza MIT, se volete dare un’occhiata. Attualmente, installare il bot per una caccia al tesoro nel vostro giardino potrebbe non essere tra i compiti più facili, ma stiamo già lavorando per renderlo riutilizzabile per tutti.
(E abbiamo altri piani significativi—e spaventosi?—per il futuro…)

Avendo fatto tesoro di quanto ascoltato durante le lezioni di “Piattaforme Digitali per la Gestione del Territorio”, io e gli altri miei amici e colleghi ci siamo cimentati nella realizzazione di bot per Telegram, impiegati come tecnologia abilitante per la realizzazione delle nostre piattaforme digitali che abbiamo successivamente consegnato come progetti per poter sostenere l’esame.

“MeteOvunque” è il bot da me realizzato, uno di quelli che sono stati valutati nel mese di giugno, la cui realizzazione ha richiesto circa un mese e mezzo di sviluppo per la versione d’esame. Dal nome è facile comprendere che si tratta di un bot che fornisce previsioni meteorologiche; ma perché scegliere la meteorologia come argomento di interesse principale?

Prima di iniziare il suo sviluppo nel mese di Maggio, diedi un’occhiata su Telegram ai bot già presenti e funzionanti e mi accorsi che quelli relativi alle previsioni meteo erano pochi, piuttosto scarni, poco “intelligenti”, con poche funzionalità e addirittura con scarso supporto alla lingua italiana. Ne avevo trovato uno che parlava in parte in italiano e in parte in inglese, nonostante avessi selezionato la bandiera italiana nel menù delle impostazioni!

A parte ciò, la mia scelta sullo sviluppo di una piattaforma di questo tipo è ricaduta sulla meteorologia perché:

• Quasi tutti, in singolo o in gruppo, richiedono le condizioni meteorologiche del posto in cui ci si ritrova o in cui si andrà;
• Il territorio di interesse per un servizio di informazione meteorologica è potenzialmente l’intero pianeta Terra.

Avendo fra le mani una tipologia di richiesta, un’utenza e un territorio di portata mondiale, non è stato così difficile capire che tutto ciò avrebbe rappresentato un ottimo esempio applicativo per il mio progetto universitario sulle piattaforme digitali.

Dopo aver sostenuto l’esame, presi la decisione di continuare a sostenere lo sviluppo del bot, semplificando l’approccio con gli utenti ed arricchendolo di nuove funzionalità. Dall’inizio del suo sviluppo sono trascorsi già 4 mesi!

Cito qui alcune delle sue funzionalità che lo rendono interessante, oltreché utile e versatile:

• Include Program-O, un’interprete PHP per intelligenze artificiali (IA) che interpreta i messaggi di testo in italiano che riceve dagli utenti e fornisce loro una risposta sulla base di ciò che è presente nel suo “frasario”;
• Dà la possibilità di consultare le previsioni su mappa come siamo abituati a vedere in tv dopo il telegiornale;
• Fornisce una lista di 5 località preferite gestibile e personalizzabile da ogni singolo utente a seconda delle specifiche esigenze;
• Gestisce un sistema di advertising (sarà attivo prossimamente) tramite il quale può inviare gif animate di sponsor locali che vogliono comparire nella piattaforma, sulla base della città di interesse in cui sono collocati;
• Possiede una tastiera accessoria che compare in chat dal layout intuitivo e risponde con messaggi esplicativi e facili da comprendere grazie alle emoticons;
• È in grado di registrare la segnalazione di guasti e di consigli sulla piattaforma direttamente all’interno delle chat con gli utenti;
• Permette agli utenti di impostare le notifiche, il livello di dettaglio delle info meteorologiche e il proprio livello di protezione della privacy;
• Salva le foto e i video che gli utenti possono inviargli per poterli condividere con gli altri utenti della piattaforma e per poterli pubblicare sulla pagina Facebook e sul profilo Instagram di “MeteOvunque”;
• Fornisce le proprie funzionalità anche all’interno di chat di gruppo e mediante l’uso di richieste inline-mode di Telegram.

Da pochi giorni è presente anche la lingua inglese!

Invito tutti a dare un’occhiata a quanto è stato realizzato, augurandomi che possiate apprezzare il lavoro compiuto fino ad oggi.

INFO E LINKS UTILI:

– Username Telegram: @meteovunque_bot
– Telegram: https://telegram.me/meteovunque_bot

– Pagina Facebook: https://www.facebook.com/meteovunque/
– Profilo Instagram: https://www.instagram.com/meteovunque/

– Email: jonathan.maiori@libero.it

Come descritto precedentemente, per l’occasione dell’evento ConvComp2016 del 24 giugno, abbiamo realizzato un semplice Bot che permettesse di raccogliere pensieri, emozioni e stati d’animo geolocalizzati, in modo da dare un’idea del sentimento generale in un’area. Il Bot è online su Telegram come @wordcloud_bot ed è possibile utilizzarlo da subito per vederlo in azione.

Strumenti semplici ed aperti per realizzare il proprio Bot.

La semplicità e la rapidità con cui si sono diffusi le svariate piattaforme di messaggistica ed i loro Bot sono, in buona parte, il frutto di anni di software e livelli di astrazione che rendono, oggigiorno, la programmazione di un’applicazione o di un sistema di comunicazione sorprendentemente facile. Alla stessa maniera, l’esistenza di immani “spalle di giganti” su cui basarsi fa sì che—almeno per quanto riguarda l’implementazione di un semplice Bot—ci siano già tutti i pezzi LEGO di cui abbiamo bisogno e che combinarli per raggiungere il nostro risultato spesso possa anche essere divertente.

In questo esempio faremo uso del software che viene utilizzato come supporto didattico nel corso di “Piattaforme Digitali per la Gestione del Territorio” del Corso di Laurea in Informatica Applicata dell’Università di Urbino, che viene offerto anche come MOOC online sulla piattaforma EMMA. Il software in questione è disponibile liberamente anche su Github.

Foto di The.Comedian, via Flickr.

Quattro semplici pezzi LEGO per comporre un Bot.

La piattaforma di base per il nostro Bot è Telegram, che mette a disposizione un’interfaccia molto ricca per l’implementazione degli stessi. Una volta collegato con Telegram, la logica interna del Bot è implementata con uno script PHP, che sfrutta un database MySQL per memorizzare le informazioni fornite dagli utenti, la loro posizione geografica ed altri dati accessori.

Se finora le tecnologie utilizzate non mostrano particolare creatività—del resto sono le medesime su cui si basa la maggior parte dei siti web o blog degli ultimi anni—è nel rendere la conversazione del nostro Bot più credibile che possiamo sfruttare un ulteriore blocco “pronto all’uso”: Program O, un interprete basato sulle specifiche di ALICE e che permette di sviluppare velocemente dei Bot che conversano in maniera (più o meno) naturale sulla base di codice dichiarativo (una variante di XML).

La libreria d’esempio su Github mette a disposizione diverse funzioni già implementate per l’interazione con Telegram, MySQL e Program O.

Le potenzialità del remix: piattaforme, dati aperti, software libero…

Non finisce di certo qui. Riprendiamo il motto di “Everything is a Remix” per asserire che qualsiasi idea—piccola o grande che sia—e qualsiasi pezzo di software, che è possibile realizzare anche senza conoscenze di programmazione, può essere visto come il culmine di anni di astrazioni—i blocchetti del LEGO—a noi liberamente disponibili. Il prodotto dei tre fondamentali passi delineati qui sotto.

Piattaforme, dati aperti, software libero e tanti altri blocchi a portata di mano possono essere ricombinati a piacimento per creare innovazione, opportunità e conoscenza. Le interfacce conversazionali rappresentate dai Bot sono una di queste piattaforme.

Il codice di @wordcloud_bot è disponibile liberamente su Github sotto licenza MIT. Se vi viene in mente qualche brillante idea per un Bot—magari ispirato ai principi dell’intelligenza collettiva—siamo curiosi di sentirla!

L’interesse per i Bot e le interfacce conversazionali sfruttati all’interno delle applicazioni di messaggistica testimoniano in qualche modo la naturale tendenza a non re-inventare la ruota: in presenza di un sistema esistente e con un grande valore dato dalla presenza di utenti e servizi—come può esserlo una piattaforma di messaggistica—vale sempre la pena sfruttarla per costruirci qualcosa sopra.

L’interesse per i Bot è testimone della convergenza su interfacce di livello sempre più alto.

L’intelligenza collettiva è il principio per cui una massa di persone può acquisire una consapevolezza o una conoscenza emergente, grazie alle interazioni dei propri membri, che la massa nella sua interezza percepisce, ma che non è possibile avere individualmente.
Wikipedia ne è l’esempio più classico, ma la presenza massiccia di utenti e la loro libera interazione grazie alla rete rende tutte le piattaforme online particolarmente indicate per esempi di intelligenza collettiva.

Intelligenza collettiva è la consapevolezza emergente dalle interazioni di una massa di persone, che non dipende e non è ottenibile dai singoli individui.

Foto di mbeo, via Flickr.

Applicando gli stessi principi alla manutenzione dell’infrastruttura stradale, mentre i singoli automobilisti sono consci della qualità della strada sulla quale stanno guidando, se ci fosse un modo per registrare la qualità delle strade in maniera oggettiva, trasmetterla, metterla insieme e tenerla aggiornata senza oneri, allora conosceremmo lo stato di tutte le strade—sulla base di un fenomeno osservabile dai singoli individui, ma non generalizzabile in automatico.

Questa applicazione esiste e si chiama SmartRoadSense. È stata sviluppata presso l’Università di Urbino e permette di tener traccia della qualità delle strade in maniera automatica, per comporre una mappa nazionale (e in futuro, globale) della qualità delle infrastrutture.
SmartRoadSense è, per ragioni tecniche, un’applicazione, ma nulla toglie che anche i Bot possano giocare una parte in un sistema di intelligenza collettiva.

Usare Bot per raccogliere informazioni, piuttosto che diffonderle.

Raccogliere dati, creare informazioni, fare domande e semplificare l’interazione con gli utenti sono tutte abilità per le quali i Bot sono nati. Invece che funzionare solo da assistenti o (per il momento) innaturali sorgenti di informazione, i Bot possono raccogliere dati e quindi creare informazioni aggregate che non esisterebbero senza la partecipazione degli utenti.

Un esempio: raccogliere dei pensieri geolocalizzati.

Per l’evento ConvComp2016 del 24 giugno, abbiamo realizzato un semplice bot che permettesse di raccogliere pensieri, emozioni e stati d’animo geolocalizzati, in modo da dare un’idea del sentimento generale in un’area. Il Bot è online su Telegram come @wordcloud_bot ed è possibile utilizzarlo da subito. (Questa frase tradisce chiaramente la troppa fiducia nelle nostre capacità di programmazione.)

È un’idea semplice, realizzata in poco più di una mattinata, ma che esemplifica ciò che già da ora è possibile realizzare con strumenti molto semplici: Bot che raccolgono informazioni, integrano dati, interagiscono con utenti, legando le informazioni raccolte col territorio. Gli utenti, invece, da fruitori passivi diventano fornitori di informazioni, parti di un’intelligenza che viene raccolta, ricombinata e resa di nuovo fruibile, in maniera potenziata.

Negli altri articoli dedicati al ConvComp2016 si parla di Bot come piattaforma e della loro implementazione.

Nell’ultimo periodo le interfacce conversazionali, in particolare quelle usate da Bot ed agenti automatici che sfruttano canali di conversazione prevalentemente testuali nell’interagire con utenti umani, stanno suscitando sempre più interesse e sono sempre più al centro di sviluppo ed innovazione.

Tuttavia, i Bot rappresentano in realtà un tuffo nel passato: rispetto alle interfacce più comuni che troviamo oggi per interagire con i servizi, siti web, interfacce touchscreen, e applicazioni mobili, dialogare in maniera testuale con un computer che simula una personalità umana ricorda il futuro ipotetico che ci si prefigurava nei film degli ultimi anni ’80.

Foto di Matthew Hurst, via Flickr.

L’evoluzione che ci porta ai Bot conversazionali odierni ha moltissimi paralleli con l’evoluzione di tutte le maggior piattaforme, incluso Internet. Alla base della madre di tutte le reti si trovano infatti vari protocolli di comunicazione elettronica, stratificati. Ognuno di essi con un proprio scopo e delle peculiarità, che formano una piattaforma che può essere sfruttata da protocolli superiori ed applicazioni. L’applicazione, basata su questi protocolli alla base di Internet, che esplode in termini di popolarità è proprio il web.

Il World Wide Web: la piattaforma globale, dinamica e flessibile.

L’accesso al web tramite browser ed i succitati protocolli diventa fondamentale e guadagna di diffusione: presto il web diventa esso stesso la piattaforma per altre applicazioni. Applicazioni che facevano già parte di Internet, ma non del web, e che sfruttavano un protocollo di “pari” dignità—come ad esempio l’e-mail con l’avvento delle webmail—migrano e diventano sempre più popolari attraverso il web stesso.

Il web è la piattaforma dominante: l’interfaccia più flessibile, dove tutta l’utenza è già presente.

La piattaforma più di basso livello offerta è quella del computer in quanto macchina, la piattaforma hardware, sulla quale si costruisce la piattaforma software, il sistema operativo, che fa da piattaforma alle applicazioni. Applicazioni tra le quali il web browser è sicuramente dominante. L’importanza del web browser era già visibile nel successo dell’iPhone del 2007, dove le capacità della piattaforma non erano date dalla possibilità di installare applicazioni—ancora assenti—ma da quella di disporre di un browser moderno, compatibile con tutto il web.

“Instant messaging”: la piattaforma cross-platform.

Nel campo dello smartphone si è vista un’evoluzione simile: da un sistema in cui l’esperienza d’uso degli utenti era dominata dal sistema operativo stesso, con l’apertura ad applicazioni di terze parti, sono le applicazioni stesse a determinare il modo in cui gli utenti sfruttano il dispositivo. Applicazioni mobili che sono disponibili su diverse piattaforme offrono spesso un’esperienza d’uso cross-platform, che diventa propria e distinta da quella offerta dal sistema. Offrendo dei servizi per sviluppatori, l’app diventa a sua volta una piattaforma.

Le app di messaggistica offrono l’esperienza d’uso alla quale gli utenti sono già abituati.

Le app di messaggistica offrono un’esperienza d’uso, dei servizi e—soprattutto—una ricchezza di utenti già attivi. Come il web ed il browser hanno vinto contro le applicazioni native, semplicemente offrendo un mondo più comodo, senza barriere all’ingresso, così le piattaforme di messaggistica possono avere successo. I Bot e gli altri servizi messi a disposizione da questi servizi si appropriano semplicemente dell’esperienza d’uso che gli utenti hanno già scelto da tempo.

Foto di Jan Persiel, via Flickr.

Negli altri articoli dedicati al ConvComp2016 si parla di Bot, intelligenza collettiva, e della loro implementazione.

Esistono app per ogni scopo, ne usiamo decine diverse, con interfacce e funzionamento diversi, ogni giorno, nelle situazioni più disparate. Alcune sono semplici e piacevoli da usare, altre meno. E questo è uno degli aspetti principali che può determinare il successo di un’app rispetto ad un altro: l’usabilità di un’app incide fortemente sulla sua diffusione.

Per sviluppare un’app che sia ‘usabile’ si possono seguire delle linee guida che vengono redatte in base a studi condotti insieme agli utenti. Queste linee guida però, non sono fisse, ma cambiano a seconda della tecnologia e dell’evoluzione dell’utilizzo dei nostri device.

Nell’ambito del mio progetto di Dottorato abbiamo deciso di contribuire alla definizione di linee guida per interfacce multitouch, valutando la raggiungibilità delle varie zone dello schermo dei dispositivi mobili. Per farlo abbiamo pensato di sviluppare un semplice gioco per piattaforma Android, Usability game, che ci permetta di raccogliere dati sull’usabilità delle interfacce delle app in modo più divertente per gli utenti.

Nel primo dei giochi proposti avete 30 secondi per cliccare il maggior numero possibile dei cerchi che compaiono in posizioni a caso dello schermo. Ad ogni click ricevete dei punti, a seconda del livello che avete giocato: ci sono infatti 5 livelli di difficoltà crescente, con cerchi via via più piccoli e difficili da cliccare.

Il gioco ha 4 versioni diverse tra loro: nella prima, al click di un cerchio ne compare subito un altro; nella seconda, la comparsa del cerchio successivo è ritardata; nella terza invece i cerchi restano visibili solo per un certo ammontare di tempo e poi scompaiono se non cliccati; nella quarta si devono usare il doppio click o il swipe per far scomparire i cerchi.

A seconda del vostro punteggio totale, vi vengono assegnate delle medaglie e guadagnate posizioni nella classifica generale: potete utilizzare sia uno username, registrandovi e facendo login all’apertura dell’app, per sapere sempre in che posizione della classifica siete, oppure giocare in forma anonima.

Per guadagnare più punti poi, alla fine di ogni livello, se pensate di aver giocato bene, potete confrontare i vostri risultati con quelli medi degli altri utenti e se i vostri tempi medi di reazione sono più bassi della media, guadagnate punti extra, ma se avete fatto peggio, li perdete.

Ogni volta che giocate poi vi viene chiesto di indicare come impugnate il vostro smartphone: questa informazione è utile solo per controllare la coerenza dei dati raccolti, ma non influisce sul vostro punteggio.

I vostri dati di gioco vengono salvati sul vostro smartphone e sono poi inviati in forma anonima ad un server, che li elabora e li visualizza su un grafico colorato, indicando con colori diversi le aree a seconda del tempo medio di click (calcolato valutando i dati prodotti da tutti gli utenti) in quell’area. Inizialmente il grafico ha 5 righe e 5 colonne, ma potete scegliere di aumentare i riquadri o filtrare i dati in base a uno dei criteri a disposizione: grandezza del monitor, tipo di impugnatura utilizzata, livello ecc…

Potete vedere qui i risultati dei dati raccolti fino ad ora.

Quando avremo una quantità di dati sufficiente saremo in grado di ragionare sulle linee guida per l’usabilità e potremo capire meglio come sviluppare app sempre più piacevoli da usare.

Quindi cosa aspettate? Giocando potrete anche migliorare i vostri riflessi e passare qualche minuto di relax tra una pagina da studiare e l’altra, oltre ad aiutarci nel nostro progetto.

Potete scaricare il gioco dal Google Play store: https://play.google.com/store/apps/details?id=com.sissy.game1

Silvia

Quest’anno l’evento si è svolto nell’imponente centro conferenze Lingotto a Torino, illuminato da un piacevole clima sereno e solare a differenza dell’anno scorso.

Saverio e Lorenz dopo il ritiro dei badge. Come vedete, badge = felicità.

Il DroidCon dell’anno scorso si era presentato subito con un’epidemia incontrollata di vari modelli di Google Glass, indossati da una buona percentuale degli speaker, l’edizione 2015 si è rivelata ugualmente modaiola con lo spostamento abbastanza massiccio dagli imbarazzanti occhiali ai più discreti orologi basati su Android Wear. Un chiaro passo in avanti sul fronte della classe.

In virtù di questo, ugualmente marcata era la presenza di Android Wear e Android Auto, le due nuove frontiere del robottino verde, come tema principale di diversi talk tenuti durante le due intense giornate di conferenza. Interessanti pure i temi legati all’intersezione tra Android ed Internet of Things, con interessanti presentazioni come quella sullo sfruttamento di iBeacon e (sconfortanti) esperimenti sulle tecniche di monitoraggio della prossimità di Matteo Gazzurelli.

Oltre allo sviluppo software, uno dei maggiori temi trattati era la cura per l’esperienza utente (la cosiddetta “UX”): Lydia Selimalhigazi e Roberto Orgiu hanno presentato come designer e sviluppatori devono necessariamente collaborare per ottenere un risultato di successo. Il tema, dal punto di vista del branding, è stato trattato poi anche in una stimolante presentazione di Marie Schweiz proprio sull’influenza di elementi caratterizzanti di un marchio sull’esperienza d’uso e la percezione di un app da parte degli utilizzatori.

Sempre sul fronte “user experience”, ma da un punto di vista totalmente diverso: Kentaro Takiguchi nella sua presentazione “Improving UX through Performance” ha dato un’idea molto approfondita e viva di tutte le piccole ottimizzazioni che si possono introdurre, sia sul lato app che sul lato server, per rendere l’utilizzo di un’applicazione più fluido, affidabile e responsivo, dovendo fare i conti con risorse limitate e connettività lenta o spesso assente. Molti trucchi interessanti, per uno scenario in cui anche tagliare 4 KB di trasferimento dati può avere conseguenze drastiche.

Come ci ha ricordati puntualmente Benjamin Augustin nel suo talk “RxFy All The Things!”, sviluppare codice può essere spesso una sofferenza infernale. Ma proprio per alleviare le pene dello sviluppatore ci sono sempre più librerie e strumenti che vale la pena sperimentare e conoscere: uno di questi è appunto RxJava, la versione Java delle Reactive extensions concepite su .NET, un modo molto interessante per “invertire” l’approccio delle applicazioni, che adottano quindi un paradigma “reattivo” che molto bene si adatta per l’interazione tra interfaccia grafica e un backend lento o inaffidabile (come ad esempio delle richieste remote).

Alla stessa maniera Maciej Górski ha presentato una varietà di sistemi interessanti per ridurre, soprattutto grazie all’utilizzo di plug-in per Gradle (il nuovo sistema di build utilizzato da Android Studio), la necessità di scrivere molto codice “boilerplate”, ossia ripetitivo senza alcun effettivo valore (come ad esempio metodi getter e setter per le proprie classi Java). Molto interessante anche la sessione “Holy Sync!” di Eugenio Marletti, sui metodi di sincronizzazione cross-platform dei dati, in questo caso utilizzando CouchBase.

“Test, test, test!” questo è stato uno dei mantra più ripetuti in quasi tutte le sessioni di questa edizione e, in particorale, sono stati i due sempre spumeggianti Ali Derbane e Wiebe Elsinga (non provate neanche a pronunciare il suo nome, fallireste) che con il talk “The hitchhiker’s guide to functional testing” hanno fatto una panoramica sui principali strumenti per il testing funzionale delle nostre app. Mentre Stephan Linzner ha mostrato le meraviglie dei nuovi strumenti cucinati con amore da mamma Google per i suoi sviluppatori mobile.

Inoltre, a mezzogiorno del primo giorno, sospinto più dal desiderio di raggiungere il buffet che altro, Lorenz ha presentato “The love child of Android and .NET: using Xamarin for app development” facendo riferimento alle nostre esperienze di sviluppo Android utilizzando la piattaforma Xamarin durante lo scorso anno, con tutti i vantaggi e problemi del caso. Le slide presentate possono essere scaricate in formato PPTX.

Ci ha energizzati durante le sessioni: la bevanda preferita di Amedeo Avogadro!

Dopo due giornate intense siamo ripartiti da Torino esausti per l’incessante successione di presentazioni, ma stimolati da tante nuove cose da sperimentare, tecnologie da esplorare e dettagli da tenere a mente durante lo sviluppo per Android (e non solo)!