I will never use the word: “smartwatch” (after this post)

4 Apr

It seems silly to be excited by one of the most interesting news from the CES 2014: “Pebble comes in a metal case”. The silly part: level of appeal of the news is close to zero. The interesting part: everyone will have a smartwatch in 10 years from now. 10 years is a long time, as this wave seems will take longer than smartphones and tablets. But be sure: we will drop our watches for new devices… that will not be actual watches. sketch-concept

Smartphones are not phones, smartglasses are not glasses, nor smartphones and smartwatches are not wrist-mini-smartphones!

The fact that they will be anchored to your wrist is just misleading. The name is deceiving too, pointing to smart, as in smart-phone, and watch; we are in presence of another clueless name we give technology that we still cannot fully understand as we develop it.

Those devices will be a lot of things and they might even tell you the time (as smartphones can do calls, although it is the least used feature for most of us).

The Pebble is a very nice device, taking stocks of early adopters, and Samsung Gear was successful only in convincing us that a smartwatch should not be a mini-smartphone. A plethora of new products is getting ready to hit the stores, and there will be a market for most of them, but soon enough most of them look like the Nokia 7110 (released in 1999) or a Blackberry Pearl (2006) compared to an iPhone.

So how will this “iPhone” of smartwatches look like? Here are the three most promising areas, to me:

1) Health/fitness

FitbitFlexThe obvious, has an incredible amount of good cases, huge markets, huge money. That is a serious, ready to explode market. A space that ranges from cheap, always on health tracking for patients to hi-performing athletes… and everyone in between!

The hottest in this space has been FitBit for a while, now it is likely the new Samsung Gear Fit, and a lot is going on already including the rumored iWatch from Apple. But I look forward to Google too (Google Wear), hoping that, in their vision, they will put health before all other use cases (see Why Google Has the Best Shot at Making the Killer Smartwatch).

2) Identity/Authentication

The second most interesting area of development, apparently not yet in the main players plans is that of identity, and authentication. This is the case where our shiny device will allow us to enter the building where we we work, our home, unlock our phone and our computer, exchange contact information with an handshake, etc.). Maybe this could be the good response from Google to the iPhone fingerprint scanner authentication. Bionym, with their Nymi product seems to be already quite far in this game.

3) Payments

Isn’t payment the Holy Grail all the big names in tech are looking for? Can we continue to use credit/debit cards and RFID cards as we are using them now?

As soon as the previous Identity/Authentication area is mature, payments will follow. With cards we got rid of our wallet, with bracelets allowing for payments we can get rid of cards too, and we will (almost) never forget or lose them, since they are securely attached to our body.

From the experience perspective the possibility of paying for a coffee, a bus ride and a parking just by putting our wrist next to the payment sensor seems very appealing to me and actually the idea has been around for several years, but the recent progress in digital banking make me believe we are getting close. Let’s just hope the approach will be to build a pluggable system: nobody feels the need to carry N bracelets: one for the metro, one for the VISA, one for the parking, etc. Finally, in considering the experience, I hope the devices receiving the payment will also get a some love from designers.

Connecting the dots

Combine the features above a lot of possibilities open up: possibilities to dramatically improve our experience around our own health, identity and payments. At this point we also expect those devices to be highly pluggable and extendable with “apps”.

Looking at the characteristics of this device-we-have-around-our-wrist, what does it offers:

  • can be always with us

  • can be securely attached to our body

  • can detect movement, heart rate and more about our body

  • can be always on, day and night

  • can be used in almost any context: while doing almost any sport, dancing, in a meeting, …

  • can be used without looking to it, just but pointing, dropping it on a surface, shaking a hand, …

All in a really small device, offering space for a small screen or display. A device you do not want to recharge, because you do not want to remove it from your body. Ever.

Many manufacturers will try the right combination, there will be more failed experiments, more acquisitions, a lot more buzz, but its all coming our way and I really hope to see, very soon, a product with all four of the above: a single wristband (as you can see I am not using the “s word” anymore) that combines, with an app system, the following:

1) Health and fitness tracking

2) Authentication

3) Payments

Will the iWatch get there first, or maybe, and hopefully, will we see a new player lead this market?

 

Google Wow, an experience that amazes for real.

6 Feb

What if there were more artists working alongside engineers at Google? I think many products will be different, and better.

Why Google?

  1. Google is the most amazing company out there, building forward looking products like Google Now, and investing in crazy projects we all love to talk about (mostly coming from Google X), that will change our lives, and we hope for the better.
  2. Google strengths is, and has always been in its software engineers. I am myself more an engineer than an artist, for sure, but isn’t the combination of art and engineering the most explosive one? Leonardo da Vinci was born 69.2 km from my hometown (according to Google Maps), and I have always been obsessed by his all-encompassing genius.
A Google doodle

Engineering+Art in a Google doodle.

Today, I was watching again the Google 2013 I/O keynote when a phrase resonated in my mind: “We want you to build the most amazing, delightful experiences for your users…”. I closed the video, and closed the office, those word buzzing in my head: “I am all in for this, dear Google”.

As I was exiting the office I pull out my phone and magic happened again: Google Now is giving me, for the 4th time this week, my commute time, as if I was driving home. Problem is I do not drive home, I do not even have a car and, frankly, I find extremely annoying to know in advance if I will home be 15 minutes earlier or 15 minutes later than usual. What if, instead, I was late home, but for a good reason?

Google Now shows more cards: temperature and forecast. Boring. I am outside, I can feel the heat, and I look at the sky. Looking at the sky delights me, the Google card… not at all.

Finally, the last card, is telling me of the latest package arriving from Amazon: Google is parsing my emails, something powerful and scary: the end result is that I receive a notification, a text message, an email for my package… and Now, also got a nice card. Annoying. Seriously.

Nonetheless I do believe Now is the future of search, a beginning for a new interface, a great product already and it is constantly being improved.

But, what if there were more artists working alongside engineers at Google? Art is beauty, surprise, emotions, and also uselessness:  let’s take a different approach to Google Now: instead of trying to predict my next search, my usual need given the context, it could try to predict what will amaze and delight me! A very appropriate name for it would be Google Wow.

a Google card

A cool, surprising card, since I just arrived in Jamaica!

How would the cards look like?

I really like music, and discovering new artists, so a music card would, from time to time, push some new music at me, an album to discover, but not when I necessarily expect it.

And I really like good food. Google might know or not my tastes (and it probably does) in any case it could throw my way a card with some cool food in the area that I never tried (Google knows that too).

We can get a lot more creative I am sure:

  • Instead of my commute time showing me a nice destination to a far away country, with pictures, travel cost and and an excuse to go there.
  • Instead of the weather in my location the weather in a location where one of my friends is now travelling, and a reason to send him/her a message.
  • Instead of the Amazon package info, a friend who just opened Google Now nearby so we can go get a beer together and be both late home.
Feeling Lucky?

Feeling Lucky?

From “feeling lucky” to “getting lucky“!

Can serendipity be designed into an experience? What if there was some randomness, a push to get outside our usual path and habits, actually giving us the habit of being more open, try more things, meet more people and ultimately get lucky for real?

 
Post inspired by:

What should NEST build next? An alarm clock, please.

19 Jan
What should Nest build next?

Alarm Clock + Nest = Love

Just a few hours after the announcement of the acquisition by Google, designers and experts worldwide were tweeting and blogging, as usual: there is no time to loose when a news hits worldwide geekness. @jonathanstark was asking the question on Twitter: What should Nest build NEXT? and the usual locks, fridge controller, etc. came out. Now, if there is something I have personally learned from Nest is that when of the smart/connected home you do not have to think of new&crazy appliances (like the home automation fans, and the industry have been doing for years): start by re-imagining the old and basic like a thermostat, and a smoke detector!

Nest has proven this is possible, valuable, and a lot easier to sell.

So what shall Nest build next? An alarm clock, I say. Yes, that old device that is currently being put out of existence by our phones.  I believe the alarm clock has its place in our homes, should get along with our phones, and with the other devices in the house. I do not have a fancy, appropriate name for this Nest Alarm Clock, but here is how it might work:

“It is finally time to go to bed, I play one last time with my phone, adjust the time I want to wake up and drop the phone on the dock of the (Nest) Alarm Clock. The small appliance looks great, Dieter Rams is proud of it. The Alarm Clock syncs with the phone’s alarm clock data, it will charge the phone during the night, then wake me up with its crystal-clear sound using the sound or tune I setup in my phone. I sincerely love its soft-lit big button to snooze it, when slowly awakening. Time to get up, alas: I remove the (fully charged) phone from the dock and the alarm stops, this time for real.”

Nice, lovely product: it will also filter calls, messages and notifications during the night, automagically letting through only certain numbers or alerts, using its night-friendly display to pop up the notifications and calls, and of course the time and, why not, the temperature maybe. Wait, what?

Sure, if you have a Nest Thermostat it will get along with the Alarm Clock, exchange data to improve temperature settings, and more. Obviously, do not forget to connect it with the Nest Protect: should the alert trigger, the Alarm Clock will convey, as gently as possible, the message that yes, there might be a serious problem and you must get up, now!

Finally, you can ask it (her?) to track your sleep too, and it might post your achievements to Google+ without you knowing, but wouldn’t you buy the Nest Alarm Clock right away?

I would.

Designing for limited connectivity

6 Apr

This is long-due post on designing web tools for  “limited connectivity” contexts, a challenge I’ve addressed in several projects at Reflab, and that can better described as a “compilation” of requirements and constraints.

My goal here is to draw attention to the topic and summarize what it means to access a web tool from the “fields”: emergency situation, remote or just under-served areas of the world, where humanitarian relief takes place. There is nothing really new, but it is worth having very clear when developing products that require an Internet connection, either  for PCs or mobile devices (and there are many, you know…).

I’d rather not talk (and rant) about how data could be managed and information organized, I want just to make an overview of the technical challenges and solutions to making better web tools.

Limited connectivity

Connectivity is just a promise still for many on our planet: in large urban settings, and places like the north of Europe it is even difficult to imagine but in a crisis, in an emergency, in rural contexts, in remote areas of developing countries the best you can get is: limited connectivity.

TelecomMap maps 3G Networks, Network Quality and Wi-Fi hotspots in Indian cities (powered by Ushahidi)

Imagine you’re on a train (in Italy, this time, and if you are not familiar with Italian trains, good for you): you need to access a website or use an online application, they promised you 3G or better, but in fact you get a lot less. You pick up your mobile, type the web address and your spinner spins, but nothing appear on your browser, finally you get some elements of the page but, no luck, a series of tunnels starts. Patiently you wait, retrying from time to time, your page loads then stops, then reload, Finally the train is now past the tunnels in the nice countryside: you try again, the page loads… slowly, and finally you have it. You click on the link you were looking for, it works! Now back to the previous page and oops! connection is gone again.

As Imna Gonzales (Organizations and Systems Responsible at MSF Spain), puts it:

“Vendors design their products from a very well connected office in some large US/European city, and their regularly fail to understand how much things can be different in the areas we operate”.

This is limited connectivity: you have some bandwidth, you have bad to awful latency (don’t even think playing online games), and connection goes up and down more or less frequently and, in many places, you do not have any connection at all. Depending on location and time you get a mix of all of the above (in office good connectivity, in cybercafé some connectivity, here a 3G, here SMS only, here nothing!). Unstable. Note also that I’m simplifying a lot by focusing only on web and mobile (smartphones) and assuming the (limited) connectivity is relatively cheap).

Now imagine that the software you are building has to be used in those conditions by people with a very limited time, in a hurry, in an emergency, people how are working to save lives. If you build and maintain a product that has to operate in those conditions here are a few things you should always consider in the design, monitor and continue to improve:

Hints for designers and developers

Here are a few hints, starting points in fact, for designers and developers; good results can be achieved by just setting the bar higher on some common requirement: for example a slower than average site is less likely to be used, but in these contexts it will not be *possible* to use it. And keep monitoring, and keep caring.

Page weight

A classic. The first thing you hear about and usually followed by the request to have a huge banner, logo or video in the homepage. Lighter pages require great UI design, clean code and optimizations, and those don’t just come fore free, unfortunately.
A recent article on The Guardian by John Naughton, “Graphic designers are ruining the web” shows the awful trend of webpage obesity.
It is quite interesting to see how much data (before cache) we are downloading every time we open a web page: the home page of the CNN today have 948.22KB transferred, YouTube home page 1.4Mb, etc.

Speed and performances

Just after page weight, and event more important, comes the speed and performances. While having well responding, fast systems is a general principle for usable software in the case of limited connectivity they can really make the difference. There are two sides of it:

Server side

Speed and performances are far too complex to discuss here, let’s just note that worst-than-average performances will sum up with page weight and client side performances to make it really impossible for some people to use the system in limited connectivity conditions.

Client side

Most will focus their attention to the server, but it’s important to keep in mind that users might be browsing from old browsers and old hardware. I’ve never been a big supporter of old-browsers compatibility (especially IE), but a good product will try to avoid long rendering time and heavy Javascript.

Cache

A good old way of speeding up things is caching: server cache, browser cache and “supercache” (see HTML5 Application Cache). Even for small projects a good use of the browser cache, maybe even of the new application cache can bring very significant improvements reducing transferred data from hundreds of Kb to a less than  a hundred Bytes. Server caching is not always good for every project, in my experience and, as my friend Federico (system administrator) keeps reminding me:

“There are only two hard things in Computer Science: cache invalidation and naming things” - Tim Bray

Asynchronous calls

Particular handy to manage long list of documents and the huge banner in homepage, it is a very useful technique the UI designer should keep it mind: user will be able to immediately access new pieces of information or features, only downloading the necessary Bytes. For a simple example see the logcluster.org preview of documents.

Binary files management

Ok, this is getting even more technical, let me just mention file compression and a good management of the synchronization, if any.

Offline

If you know what I’ve been working on in the past months you know I have to talk about offline web: the most complete support to limited connectivity would include it, but note that having offline support does not mean all of the above can be skipped! Offline support means the site/application can work online and offline, if needed it updates (sync), and updating is “sensible” i.e. just update things that have changed, use compression for files, etc. See my post on HTML5 offline support.
Two examples: the Ushahidi mobile web application and OOPS (Online Offline Publication System). The year looks promising, the standards are being finalized, will browsers follow?

Final considerations

Products made to be used in emergencies, crisis, humanitarian operations, remote, unserved areas, etc. require a lot more than just tackling limited connectivity, of course, and several of the points above are true for every good software product in general. Important improvements can be also made by designing different information flows, data formats, interfaces, etc. The main point? whatever is your product, please care about limited connectivity and keep evaluating, monitoring and improving!

Trabaju, men and women working

12 Jan

A damaging and painful secret

(and women too)

It all began with frustration: I was looking for information on workplaces, wages and conditions and I spent several days searching the web but I have not found what I was looking for.

Wages, benefits, works conditions, workplaces information is not available, not accessible or extremely difficult to find.

Or how a friend of mine put it:

“In our information driven society the labour market information is a well kept secret.”

Information rules

There is nearly a complete vacuum of real, actionable information that workers, either alone or organized, and organizations can use.

It is possible to make a revolution in the labour market. It is needed, and would be good for the workers, and for the economy in general:

“Without the large market that a robust middle class provides, innovative companies don’t have buyers for their products, and without a competitive labor market and increasing wages, they don’t have much incentive to innovate on the production side, either.”

Tim Fernholz, GOOD Business editor

Our biggest, more important market completely lacks of accessible information.
Internet gave us access to billions of information and data, and showed us who has the wisdom and the power to act: the crowd.

Crowdsourcing:

  1. because everyone is a worker (or will be, or has been, or should be)
  2. because every worker has a very small, private part of the information, and can share it
  3. because these small private chunchs of information, alltogether, can bring the change we need

It is time to step into the labour market and to change it, and for the better.

In an way similar to how Wikipedia changed forever our approach to (enciclopedic) knowledge, there should be the same with labour market, to make labour market “work” better, to give power to those who have less, to show reality, to recognize the employers that are good and make them better, …

This is the idea of Trabaju (means “work” in Sardinian).

Issues -> solutions

Labour market is extremely complex, there are cultural barriers, there are privacy issues, there are legal problems. So how can we do?

All the people we talk to are bringing new energy and helping us move forward the idea, here are some of their suggestions:

  1. find very smart folks that have already faced similar challenges (and are still facing them): folks in Wikimedia Foundation, LinkedIn, Ushahidi, …
  2. hire very good lawyers
  3. it is business, but work for its social mission
  4. … ask for more help
So here we are, ready to tap into every human being willing to give us suggestions, expertise, or encouragement:
what do you think of the idea?
how can we move forward?

Idea inspired by:

Tim Fernholz - Why Fixing the Wealth Gap...
The incredible community of Crisismappers
Ushahidi
Wikimedia Foundation
#nofreejobs

[Antonio, Francesco, Giorgio]

The context of the project: http://www.fastcoexist.com/1679128/principles-for-social-innovation-in-2012-follow-the-developing-world

Mobile webapp for Ushahidi

16 Dec

As a (web) project and program manager working in the humanitarian and for development, I’ve been always fascinated by the amount of challenges that any tool aimed to the fields presents; just to cite a few: reliability, low bandwidth, cross-platform, offline support, extreme simplicity, and of course it should work-when-everything-else-fails(TM). I will not mention that, as a plus, in many cases budgets and funding are limited, if not extremely limited, compared to complexity.

I guess this is the reason that pushes those who works in this domain to keep being extremely pragmatic, ingenious and sometime very innovative.

In Reflab we have lately labelled this whole lot of design challenges as building resilient tools (resilience being THE buzzword nowadays, I guess it is a good choice to promote the idea).

In such context of resilient applications, limited connectivity is one of the main issues I’ve been personally working on in the last years, first developing OOPS, i.e. offline and portable web-based information publishing (or offline websites, if you prefer) and later working on Data Collection.

The idea for a not-so random Hack of Kindness

some nice folks hacking HTML5 for Ushahidi at RHoK

Just before ICCM 2011 I though we could apply what we had learned so far in data collection and mobile web applications to a project that we really appreciate a lot and which, hopefully, would immediately benefit: Ushahidi.

Ushahidi is an amazing tool in terms of impact in crisis management, works well via web and also has mobile applications for several platforms. A mobile web application, with offline support, would make it address some extra use cases: offline data collection, of course, but it would also make it a lot more easy to distribute, update and, last but not least, as Erik (@whiteafrican) immediately pointed me out, if would be great if it could support Custom Forms.

So, together with some friends and colleagues we when forward spending a few evenings, and then a whole RHoK weekend to develop the Ushahidi mobile webapp.

The hack

What we did: using the Ushahidi APIs, HTML5 and some Javascript libraries we could quickly build a very first version of the application, then a second one by the end of the weekend.

The app uses different HTML5 features:

  • application cache for offline use of static resources (html, css, javascript)
  • storages (Web SQL) for report data saved locally on the browser
  • geolocation API to obtain latitude and longitude from the device GPS
  • FormData to post the image
  • online/offline events

The UI interface is based on jQueryMobile, server-side there is a very lightweight back-end written in Python, that can simply be replaced by other frameworks or directly integrated in Ushahidi core.

What does the application provides: at the moment is only manages reports, collecting data online and offline, saving it locally and sending it when some connectivity is available. It features all basic fields, included GPS coordinates and image/photo upload (on platform supporting it), but not the custom forms.

Not bad to have something running, plus some documentation; and the same code could be used for other mapping or assessment tools!

Credits go to Riccardo Lemmi (guru and lead), Francesco Occhipinti (Javascript wrestler), Francesco Merlo (Python/API uber-developer) and Antonio Tirabasso (wise UI engineer).

What’s next?

In the pipeline we have: to put everything on Github, work on the UI (no work has been really done, yet), and do a real-world simulation/testing.

I really hope the app will prove useful to Ushahidi users: with the feedback collected we could then consider extra features, better interfaces and move forward looking at the custom forms.

Thanks to Heather Leson (Ushahidi Director Community of Engagement) we are now looking to other related challenges and will connect with more people willing to join online-offline and connectivity-related developments!

 
References:
The Next steps for Ushahidi Hacks
Online offline web applications
OOPSHTML5 rocks

New energies to help in humanitarian crisis

30 Jun

CrisisCamp, Paris

A room at the CrisisCamp, Elena Rapisardi presenting

A case study presentation (by Elena) at the Summit of CrisisCamps Europe, Paris

It was in Paris at the 2011 Summit of European CrisisCamps, that I felt, understood, the true power of  the Crisis Campers fast growing community: no tweet, blog post, article, or paper can replace the experience of being in person within that small crowd of extremely motivated, capable and genuinely devout people! (and yet I’m blogging in the hope that some reader will be inspired).

Crisis Camps are a special breed of barcamps, born to connect a global network of volunteers who use creative problem solving and open technologies to help people and communities in times and places of crisis. 

Senior information managers, developers, bloggers and journalists, project managers, designers from big NGOs to small non-profits, volunteers or professionals, very young and less young, the very diversity of the people gathered there was so powerful to me.

We spoke a lot about technology, sure, but the common ground for all people there is not to invent radically new tech (maybe sometimes) but how to use, mix and shake existing tools, to solve immediate problems.

This changes everything!

At a CrisisCamp you might find yourself developing an application to help refugees find their relatives, designing a system that processes Tweets to provide assistance after an earthquake, brainstorming around a mobile application, open data, transparency and security, and discussing a hundred new ways to volunteer and help, and build a more resilient world.

Among all wild ideas and new technologies, there is one central aspect that needs all of our attention:

people, the very people affected by a crisis are getting connected!

Not all of them, no, not everywhere, not all the time, but they are there. They might not have a pc, but they might access Twitter, and be on Facebook, and this changes everything!

Tools liberating new energies

people in Haiti working on the OpenStreetMap project

New energies in the fields (Haiti, OpenStreetMap) - (C) Kate Chapman

The opening case study of the CrisisCamp is the story of #CIVSOCIAL (slides here), a beautiful, immensely human story, of how a group of friends and volunteers reacted to save lives in recent Cote D’Ivoire crisis, using ordinary technology (Twitter, Skype, etc.) and leveraging the energies of extraordinary people. Thanks to Jean-Patrick (@ jpehouman) for sharing his great story.

Have you ever heard of Ushahidi? Per se, it’s a great idea: with it you can crowdsource geotegged information, provide visualization and interactive mapping… quite powerful. But you should listen to the stories of Anahi (@anahi_ayala) and others that have been using it, to really grasp the revolution that happens behind: hundreds and hundreds of people collaborating worldwide to create accurate maps, to translate messages, requests for help, reports, to harvest information from the Internet aggregate and validate it, and more. The output is information, rapid, often good and very valuable information, to inform people, coordinate, and act, in crisis: for the Haiti earthquake, Chile earthquake, Pakistan floods, Egypt, Lybia, Sudan, …

Other major projects presented, discussed and worth our attention are: OpenStreetMap and Global Voices, and there are many many others, and all of them share the goal to build a little piece of a better world, a more prepared, transparent, resilient, open and human world.

People in humanitarian crisis are getting connected: connected one to each other, connected to people in other countries and willing to help, connected to the rest of the world, when listening. The names of the tools that connects us all are not new: Facebook, Twitter, Skype, WordPress, …

Tools liberating new energies, the energies of:

  • volunteers across the globe translating, validating reports, spreading the information and spreading awarness,
  • geeks, mappers, developers, hackers, creating new and better tools,
  • and most of all, the energies of the people there!

Few have yet acknowledged such a big change and big opportunity.

The new paradigm in Crisis Management

Social, partecipatory web is liberating new energies, energies that have already shown their impact, so where do the well established agencies, NGOs and institutions stand?

An important debate that took place in Paris: “Civil Society & institutions in Crisis Management : New Paradigm of the Participatory Web.”, a roundtable on the current understanding and acceptance of the new paradigm from the Institutions. The main outcome of the debate was that not only the Institutions but also most humanitarian agencies and  large NGOs have not yet seen, understood, nor accepted the change. And it was great to have people from UN OCHA and the International Committee of the Red Cross at the table, OCHA in particular has already done much and is leading the effort of collaborating with the volunteers communities defining the new challenges.

CrisisCamps collect the enthusiasm, the appeal, the dream of the many that have experienced the change: volunteers, humanitarian geeks and technoutopists, a movement born from the bottom, very young, and unexperienced. On the other side the institutions and international organizations that have been working in humanitarian crisis for decades, with their experience and knowledge (and rules and procedures) aimed to ensure quality, safe, transparent and effective action.

Conclusions

Participatory web, and notably the direct participation of the affected communites, will have a growing impact on the information, knowledge sharing, privacy and security, and action before, during and after a crisis.

As Anahi puts it:

“people have access to these tools and they will use them, anyway!”

and also:

“people are now in the information loop and can provide and will also benefit a lot from information.”

I urge all international organizations, NGOs and Institutions to look at, explore and embrace the new paradigm: the debate is open, while communities are growing and social web spreading more and more.

And only these organisations only can provide the experience, the training, the wisdom and the resources needed.  And I’m sure the “new energies” will listen, learn from them, and organize, develop new tools, practices and continue to innovate.

I really hope that in the next years international organizations will foster and help accelerate such change, fully understanding that the social web is an everyday tool to fulfill their very mission.

What’s next?

The Paris Summit of CrisisCamps has motivated me more than enough to move forward and start bringing such new powerful ideas and tools into my everyday work in Reflab, and engaging in the community: together with Elena Rapisardi (@erapisardi) and Marco Boscolo (ogdabaum) we have kickstarted an Italian group. Thanks to Header (@poplifegirl) and CrisisCommons for the support. Huge thanks to LaCantine for giving us a great location, wi-fi, food and everything we needed and to Claire (@ClaireInParis) for leading and guiding us all.

Related resources
crisismappers.net
crisiscommons.com
Disaster Relief 2.0 (report)
Volunteer Technology Communities (paper)
Follow

Get every new post delivered to your Inbox.

Join 1,132 other followers