La morte di Foursquare

Vabbè, scrivo questo post in un venerdì non molto vivace di Agosto. Dunque mood negativo, avvertiti.

Dopo aver vissuto lo split fra Foursquare e Swarm con una certa repulsione e sfiducia, ieri ho provato il nuovo Foursquare ufficialmente ridisegnato in versione 8.0

Andiamo con ordine, anche dopo aver letto il post di Vincos, sempre molto attento e competente in materia.

La geolocalizzazione è morta, viva la geolocalizzazione: Chi si ricorda di Brightkite, Gowalla, ecc? Quasi nessuno. Ma potrei proseguire con l’italianissimo Mobenotes! Ve li ricordate i servizi ‘location-based‘?
Bene, tutto ciò aveva un senso (e forse oggi non lo ha più), perchè quasi tutti i servizi web-mobili attuali, ma non solo, aggiungono le funzionalità di geolocalizzazione e spesso di social chekin embedded. Ovvero fanno diventare prassi l’abitudine di far sapere ai propri fun/follower dove ci si trova.

Dunque l’esclusività e il vantaggio competitivo è finito e la funzionalità è diventata trasversale a tutte le piattaforme. Google e Facebook in primis.

Gaming, prize e engagement: Foursquare aveva capito per primo che l’incentivo all’azione (check-in, tip, commento, ecc.) dovevano essere premiate. Prima con i badge di cui bullarsi (mayorship per capirsi) e poi con i prize messi a disposizione dagli advertiser, ovvero sconti, promozioni e veri e propri regali.

Che abbia funzionato, sembra proprio di no, anche perchè uno dei motivi che ha indotto Foursquare allo split sembra sia proprio la diminuzione dei check-in. A tal proposito val la pena leggere un post del Maggio scorso proprio sul blog ufficiale di Foursquare:

Back in 2009 when we had 50,000 people using Foursquare, they were awesome. But as our community grew from 50,000 people to over 50,000,000 today, our game mechanics started to break down:

  • Points became arbitrary and less reflective of real-world achievement, because a check-in at a concert in Istanbul is really different than one at a dog park in New York (and the thousands of types of check-ins in between).
  • We created hundreds and hundreds of badges to appeal to different people around the world. Some of you want more, though we hear more often that badges stopped feeling special a long time ago.
  • Mayors were great when Foursquare was small and you were competing against your friends to rule the neighborhood coffee shop, but as more people signed up, earning a mayor crown became impossible.

Dunque questo meccanismo non paga più e viene demandato, con altre aggiunte (sticker in primis) alla nuova social app chiamata SWARM! Sarà un successo? Io credo di no, e spero di essere smentito, ma avrà vita breve.

Forse ai tamarri piace addobbarsi di adesivi da condividere con gli amici, ma la cosa mi lascia perplesso.

GPS rulez: Entrambe le nuove app, ovvero Foursquare 8.0 e Swarm fanno ampio uso del servizio di passive location sharingIn pratica GPS always on and shared! Da paura, vero?

2014-08-07 12.58.18

Insomma, mica tanto direi. Molti nuovi servizi prevedono questa funzione di default. Pensate a tutti i sistemi wearable o alle app di traking (Runkeaper, Runtastic, Nike, Step counter, ecc.) e andando oltre (per begare subito con tutti i detrattori interessati alla privacy) riflettiamo sul fatto che i nuovi smartphone portano in dote un nuovo processore dedicato proprio a queste attività in movimento, come ad esempio il co-processore M7 dell’iPhone 5S.

Detto questo sono molto d’accordo con Vincos quando fa notare la scarsa attenzione alla privacy a discapito dell’opportunità indotta:

In pratica, anche se l’app non è attiva, collezionerà questi dati nei server di 4sq al fine di comprendere le abitudini dell’utente e anticiparne i desideri, ma anche per poter costruire una mole di informazioni utilizzabile, in forma aggregata, per la pubblicità.
Crowley pensa che questo tracciamento continuo verrà accettato dagli utenti perché lo vedranno trasformarsi in consigli utili. Resta il fatto che viene attivato automaticamente, senza un avviso. Una mossa azzardata nel momento in cui anche Facebook sta virando verso una maggiore attenzione alla privacy

Ma andando oltre, veniamo alle mie considerazioni e perplessità che manifestavo su Facebook dibattendo con diversi amici:

A) Yelp rulez. Per chi come me ha frequentato diverse volte Stati Uniti e Inghilterra sa che Yelp sta correndo alla grande e l’accordo con Apple (consigli di Yelp sulle mappe) , e non solo, la sta portando a diventare l’app più utilizzata di sempre nell’ambito delle ‘raccomandazioni’.

2014-08-08 10.30.40

Il recommendation engine di Yelp è il preferito (anche se in Italia ancora stenta) e i motivi sono questi:

In a nutshell, that’s how Yelp works. Every day our automated software goes through the more than 47 million reviews that have been submitted to Yelp to select the most useful and reliable ones to help you find the business that’s right for you. Unlike many other sites, our stance is quality over quantity when it comes to reviews. As a result, we only recommend about three-quarters of the reviews we get. More often than not, these reviews come from active members of the Yelp community, and from those we’ve come to know and trust.


B) No pay no play: Il gaming associato al prize dava un senso alla partecipazione su Foursquare, dovrebbe darla anche su Swarm? Secondo me no, perchè non incentiva il business, ma solo una competizione fra friends, fine a se stessa.

C) Le competenze di cui bullarsi in un network asimetrico come il nuovo Foursquare (more tips more competence) non credo paghino, anche perchè lo sforzo richiesto dovrebbe generare anche qui una forma di gratificazione reale che non può essere solo un profilo più ricco e posizionato o delle menzioni sulla scheda del locale censito. Mi sbaglierò, ma non paga.

D) Quale sorte per le API? A me piaceva molto giocare con Foursquare, specialmente per lo storitelling., Guardate un po’ come mi divertivo: http://www.tripline.net/gigicogo

Detto questo, spero di essere smentito dai ragazzi di Foursquare, ma la vedo nera. Dunque che fare, che alternative usare per chi, come me, sta pensando di andare oltre?

Non lo so, ma mi sa che Zuck ne trarrà notevoli vantaggi.

Opera quarta

Il quarto papello del bloggante, scritto a 4 mani con l’amico Simone Favaro è ora disponibile per l’acquisto.

Potete pensarlo come un bel regalo di Natale :)


Oltre all’editore che un’altra volta ha creduto in me/noi, un particolare ringraziamento a Mauro Lupi, prefattore e agli amici Barbara Bonaventura, Mafe De Baggis, Vincenzo Cosenza, Gianluca Diegoli, Marco Massarotto, Alberto D’Ottavi, Robin Good e Giorgio Soffiato che hanno contribuito alla parte interattiva del libro contenuta nel capitolo: ‘I protagonisti’

Civic hackers cercasi

Oggi è un giorno tristissimo, soprattutto per le mie presentazioni e i miei speaeh che si sono sempre alimentati di: http://www.mybikelane.com/ e del modello che questo sito di civic hacking rappresentava.

Scopro che dal 15 di Novembre il servizio ha chiuso. Spero che qualche hacker civico (o gruppo di hacker civici) prenda il testimone e sviluppi qualcosa di analogo al più presto.

 

Save the date

Il giorno 18 Maggio alle ore 13.00, a Roma presso la sala conferenze stampa di ForumPA (Padiglione SC3), si terrà la presentazione del mio ultimo libro: I social Network nella PA

Dopo i due comunicati stampa di ForumPA e Egov, ho aperto un gruppo su Facebook: https://www.facebook.com/SocialNetworkPa dove vi aspetto non solo per un Like :-)

Cliccano qui, invece, potete farmi sapere se venite :-)

Bastone o carota?

Ormai lo sapete I’M FALLING IN LOVE! Si, mi sono innamorato dei Design principles britannici sui SERVIZI PUBBLICI DIGITALI e mi accingo a commentarne qualcuno, frustrandomi, tafaziandomi e anche incazzandomi non poco.

Tutto inizia con una premessa: These principles are intended to be ‘carrot not stick’. They’re not a list of bad things to be avoided, they’re a set of principles to inspire you, accompanied by examples which explain things further and code and resources which will make the principles easier to follow.
We’d love to know what you think — will these principles and examples be useful for you? Please let us know via govuk-feedback@digital.cabinet-office.gov.uk.

Sinteticamente: ‘NON SIAMO QUI PER BASTONARE NESSUNO, NON ENUNCIAMO QUESTI PRINCIPI PER AFFERMARE CHE TUTTO FA SCHIFO, MA SIAMO QUI PER PORTARE QUALCHE ESEMPIO ISPIRATORE E RENDERE LE COSE PIU’ FACILI. CI PIACEREBBE SAPERE CHE NE PENSATE, DUNQUE FATECELO SAPERE

Crowdsoucing, co-costruzione, ascolto, analisi dei fabbisogni???? Non lo so, ma mi sembra così chiaro e semplice che rispetto ai nostri pistolotti è già anni luce avanti. E continua la frustazione. Carry on!

Ed eccoci ai 10 comandamenti (in origine erano 7)

The 7 GDS digital principles

1) Start with needs (PARTIRE DAI BISOGNI) *quelli degli utenti, non quelli della Pubblica Amministrazione

The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need.

LA PROGETTAZIONE DEVE BASARSI SULLE ESIGENZE REALI DEGLI UTENTI. TUTTA LA PROGETTAZIONE VA FATTA ATTORNO ALL’UTENTE  (user centric design ……che bel termine ignorato beatamente nell’italico paese ). BISOGNA CAPIRE I BISOGNI ANALIZZANDOLI IN PROFONDITA’ E NON CADERE NEL SOLITO ERRORE DI FARE DELLE SUPPOSIZIONI (io direi non arrogandoci la boria di sapere cosa i cittadini vogliono). SENZA DIMENTICARE CHE CIO’ CHE CHIEDONO NON RAPPRESENTA SEMPRE UN BISOGNO.

Esempi in Italia? Citofanate nei commenti, perchè io non ne vedo.

2) Do less (FARE MENO) e qui parte la ola, perchè questo articolo letteralmente mi arrappa.

Government should only do what only government can do. If someone else is doing it — link to it. If we can provide resources (like APIs) that will help other people build things — do that. We should concentrate on the irreducible core.

LA PUBBLICA AMMINISTRAZIONE DOVREBBE FARE SOLO QUELLO CHE LA PUBBLICA AMMINISTRAZIONE PUO’ FARE (sostituirei ‘dovrebbe’ con ‘deve’). SE QUALCUNO SA FARLO MEGLIO FATECELO SAPERE E GLI OFFRIAMO TUTTI GLI STRUMENTI PER POTER SVILUPPARE AL MEGLIO LE SOLUZIONI. NEL CONTEMPO NOI CI CONCENTREREMO (meglio) SULLA NOSTRA MISSIONE E SUGLI ASSET IRRINUNCIABILI.

E dopo l’applauso? Citofonate esempi.

3) Design with data (PROGETTARE CON I DATI)

Normally, we’re not starting from scratch — users are already using our services. This means we can learn from real world behaviour. We should do this, but we should make sure we continue this into the build and development process — prototyping and testing with real users on the live web. We should understand the desire paths of how we are designing with data and use them in our designs.

SOLITAMENTE NON PARTIAMO DA ZERO QUANDO SIAMO CHIAMATI A PROGETTARE SERVIZI. ALLORA IMPARIAMO DA CIO’ CHE SUCCEDE NEL MONDO E DA QUELLO CHE STA SUCCEDENDO SUL WEB PER DISEGNARNE DI MIGLIORI. DOVREMMO CONCENTRARCI DI PIU’ SUI PERCORSI CHE SONO CREATI DAI COMPORTAMENTI DELLE PERSONE E DA COME LORO UTILIZZANO I DATI. (Gli inglesi son fantastici, usano il ‘desire path’, che figurativamente rappresenta il solco della bicicletta che devia dal percorso che gli è stato preconfigurato, per esaltare l’alternativa, la scorciatoia, la creatività e il fai da te……ecco perchè il Civic Hacking è nato da loro…..sospirone)

Short cut :)

Comunque, tema difficile perchè in Italia siamo alla fase uno, ovvero alla liberazione del dato, non ancora al suo utilizzo. Appsforitaly? http://www.appsforitaly.org/

4) Do the hard work to make it simple  (IMPEGNARSI PER SEMPLIFICARE LE COSE)

Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.

FARE QUALCOSA CHE SEMBRI SEMPLICE, È ABBASTANZA FACILE, FARE QUALCOSA DI SEMPLICE DA USARE È MOLTO PIÙ DIFFICILE – SOPRATTUTTO QUANDO I SISTEMI SOTTOSTANTI SONO COMPLESSI – MA QUESTO È QUELLO CHE DOVREMMO FARE.

A chi lo dite. Qui nemmeno le cose che appaiono semplici lo sono. Mi vengono in mente, anche se esco dal seminato, i siti dei provider di telefonia mobile ….. depressione.

5) Iterate. Then iterate again.  (RIPETERE, CON INSISTENZA)

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

Difficile da tradurre, perché è un modo di dire e di intendere il concetto di routine ripetitiva (loop), tipicamente anglosassone. PARTIRE DALLE PICCOLE COSE E RIPETERLE CON ENERGIA. PASSARE DALL’ALFA ALLA BETA E AGGIUNGERE CONTINUAMENTE FUNZIONALITA’ E MIGLIORAMENTI IN BASE AI FEEDBACK RACCOLTI

Si tratta della teoria (più volte enunciata su questo blog e nei miei scritti) della BETA PERPETUA. Inutile costruire cose complesse e ingestibili, meglio concentrarsi sulle piccole cose, tanto mutano in fretta e non son mai stabili. Mutare al mutare delle abitudini e degli stili. ….molto informatico :-)

6) Build for inclusion.  (COSTRUIRE SERVIZI ACCESSIBILI)

Accessible design is good design. We should build a product that’s as inclusive, legible and readable as possible. If we have to sacrifice elegance — so be it. We shouldn’t be afraid of the obvious, shouldn’t try to reinvent web design conventions and should set expectations clearly.

I servizi devono essere inclusivi, comprensibili e leggibili, pazienza se si deve sacrificare l’eleganza. Non dobbiamo avere paura dell’ ovvio, nemmeno di reinventare le convenzioni del web design e definire le aspettative in modo più chiaro.

7) Understand context. (CAPIRE IL CONTESTO)

We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?

Non stiamo realizzando servizi per il monitor del computer ma per le persone.Dobbiamo essere sicuri di aver capito da chi verrà utilizzato il servizio ed in quali circostanze. I nostri utenti stanno in una biblioteca? Usano un telefono? Son fidelizzati con  Facebook? Hanno mai usato il web prima?

8) Build digital services, not websites. (COSTRUIRE SERVIZI DIGITALI NON SITI WEB)

Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.

Attualmente il web è il miglior modo per distribuire i servizi,ma tutto può cambiare rapidamente. Inoltre i servizi debbono poter essere utilizzati anche fuori dal nostro spazio web.

9) Be consistent, not uniform. (ESSERE COERENTI, NON UNIFORMI)

Wherever possible we should use the same language and the same design patterns — this helps people get familiar with our services. But, when this isn’t possible, we should make sure our underlying approach is consistent. So our users will have a reasonable chance of guessing what they’re supposed to do.

Quando possibile bisognerebbe utilizzare lo stesso linguaggio e lo stesso format per i diversi servizi. L’importante è che la logica di fondo sia coerente.

10) Make things open: it makes things better. (FARE LE COSE OPEN: VENGONO MEGLIO)

We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers get spotted, better alternatives get pointed out, the bar gets raised.

Bisogna condividere il più possibile le cose che stiamo facendo. Più occhi ci sono su un servizio, meglio potrà essere sviluppato.

E’ inutile, non avremo mai la capacità di sintesi degli anglosassoni che, per certi versi è devastante e  irragiungibile. Mi si perdoni per certe sbavature nella traduzione ma, spero, di aver rappresentato un po’ del loro modo di pensare.

Veniamo ora al tema che pone Salvatore nel suo ultimo post e al ‘problema’ dei linguaggi.
FARE LE COSE OPEN: VENGONO MEGLIOBisogna condividereil più possibile lecose che stiamofacendo. Più occhi cisono su un servizio,meglio potrà esseresviluppato.
Questa mia escursione nella perfida Albione vorrebbe far riflettere sul fatto che i vari linguaggi non sono un ostacolo se la cultura digitale è condivisa fra la PA e i cittadini. Enunciando i loro principi di design dei servizi pubblici, i britannici si rivolgono a operatori acculturati che possono velocemente correggere gli errori del passato. Da noi, invece, il problema è ancora quello del burocratese e dell’autoreferenza.
A mio modo di vedere l’Action Plan italiano è poco sexy, non tanto perchè non si allinea al linguaggio geek della rete (o meglio: non solo), ma perché è  difficile da digerire. E’ un lungo elenco dei TANTI problemi e delle POCHE cose fatte, che mal si adattano a un contesto di DIGITAL GOVERNMENT.
Esempio? Proviamo a leggere questa frase dell’Action Plan: ‘approvazione di un quadro normativo più efficace per la prevenzione e la lotta alla corruzione nella PA al fine di assicurare un miglioramento delle condizioni di mercato per la concorrenza e di favorire il contenimento della spesa pubblica. I provvedimenti all’esame prevedono l’obbligatorietà dell’adozione di piani anticorruzione a carico di tutte le PA, con il coordinamento del Dipartimento della funzione pubblica, l’individuazione di un responsabile della prevenzione della corruzione, la valorizzazione di una rete capillare sul territorio, quella dei Prefetti, nella forma di supporto tecnico e informativo agli enti locali e quali tramiti tra essi e l’Autorità nazionale anticorruzione.
Ma su che pianeta viviamo? Che lingua parliamo?
Capito ora perché mi son innamorato della perfida Albione?

2night 1st Programming Challenge

Martedì scorso, Simone Tomaello CEO di 2night.it ha presentato ai miei studenti il challange sulla geolocalizzazione dei locali pubblici: http://www.2night.it/contest/

Nell’occasione ha presentato la beta del nuovo sito: http://2night-beta.it/

A me sembra una bella idea quando un azienda di successo, social e innovativa utilizza il crowdsourcing.

GRAZIE PIERFERDI

Son passati 6 anni di Twitter e per me son stati 6 anni di convegni, conferenze, pubblicazioni, libri e molta formazione al personale della Pubblica Amministrazione.

Ho dovuto usare sempre esempi stranieri per illustrare il paradigma del governo 2.0. Molti mi hanno deriso, altri snobbato. Alcuni anche preso in giro e parlato male di me con il management, dandomi persino del pazzo visionario.

Fra qualche giorno uscirà il mio nuovo libro, e ci sarà tanto di Twitter. Tanto vissuto e tanta speranza.

Oggi posso ricordare il giorno in cui ho aperto il profilo di Twitter del mio Ente (era il 2008, credo) e il responsabile della comunicazione web mi disse: ‘quella puttanata dove scrivete anche che andate al cesso?‘.

Ho inghiottito il rospo, ho aspettato sulla riva del fiume, e poi il mio Ente ha iniziato a usare Twitter (a modo suo, in modalità broadcast che non condivido). Oggi posso levarmi il sassolino dalla scarpa e dire: GRAZIE PIERFERDI!

Lo spartiacque è segnato e la strada sarà un po’ in discesa anche per noi che ci occupiamo di Social Media nella Pubblica Amministrazione.