This past weekend was the third annual Saigon MobileDevCamp held at
Bach Khoa University. Although I'm mainly a web developer, as the event was billed as
a brother to BarCamp, I decided to go and check it out, meet some
people, support my friend Dan, and see if anything from the event could be applied to
the upcoming BarCamp Saigon on December 11th.
Like BarCamp, the venue is a local university. However, the quality of facilities between a regular Vietnamese university like Bach Khoa and a foreign-operated campus like RMIT are on a quite different level. Most rooms were without air conditioning and became quite hotter than I'm accustomed to.
In the morning there were
a number of sessions on developing mobile apps (I checked out a session on PhoneGap but missed the Unity 3D session). In contrast to the BarCamp ideal, guest speakers were invited to give sessions which were planned and scheduled beforehand. Topics were confined to the "mobile development" theme.
After lunch, the main event would
be a 24-hour coding competition. As I was already waking up far earlier than usual to
attend the conference which I hadn't even properly registered for, I had no intention of joining the hackathon but
I would eventually be overcome by my friend Cong's excitement for Doing Things.
The Contest (click to expand)
19 teams. 5 persons max. 24 hours. 3 categories.
There were 19 teams of up to five people competing. We were number
19, registering about an hour after the competition had begun. (Not only was I the only foreigner on our team, I was the only foreigner on any team. The rest of the foreigners were there to hang out and talk to people, which was all I originally intended on.) Participants included employees of sponsors as well as students.
At the start of the competition, MC Minh announced in Vietnamese
the three categories that apps could be in: spelling, medical
emergencies, and fighting pollution. (I think I misunderstood initially, but later an email in English was sent out.) This prevents teams from having ideas and apps already in development beforethe competition. This, along with the 24 hour time limit and 5-man team limit, are the constraints we were working with; otherwise no judging criteria were announced. It's unrealistic to expect to develop much of an application in 24 hours and we knew this going in. We would later realize how little the actual code mattered.
Once the 24 hour clock had started ticking at 2 PM and neither Cong nor I had joined any teams, we decided to see what we could come up between the two of us. We went outside for some fresh air (actually, cigarette smoke) and discussed some ideas for the
spelling topic but we dismissed them the most quickly. We came up with an idea
for the medical emergency category but when we came up with an idea
for the environmental category, one which we could talk about at length and come up with numerous uses for, that's when
Cong
called up Hong who also liked the idea and joined our team as our third member. We were probably the smallest team there.
During the hacking event there is a large room available for
participants to use and even sleep in. At night there was a pizza party. For me, the room was too hot and
humid so we decided to leave and find someplace more conducive
to hacking for the remaining hours. We even considered renting a hotel room for 300,000VND but in the end
we decided to just go to my house which at least has soft places to
lie down, a working (at least better than Bach Khoa's) wifi connection, and air conditioning. The only
problem was that it was a bit far from the competition so we lost some
time commuting there and back. We also got soaked by rain on the way.
Hackathon
A hackathon is a chance for hackers to push themselves both mentally and physically. Although in previous years, teams who skipped sleeping at all didn't fare so well, I'm sure most people didn't get a good night's sleep. For our team, besides a short nap, a dinner break as the rain was dying down, and a breakfast break for my teammates, we were hacking the entire time we were at my house. As the hours wore on, I found myself getting more easily frustrated while staring at nonfunctioning code, code that it would often later turn out didn't need to be written. In some ways, the experience is similar to working at a startup with even shorter horizons.
Our Idea (click to expand)
Our idea with this: we live in an apathetic world where social
problems that were once taken care of by the local (think village) community are now left to a (criminally)
unresponsive government. Littering,
driving dangerously, and domestic violence may be crimes which are
witnessed by millions of people every day who simply think "it's not my
business". The saying goes, "No good deed goes unpunished". Clearly, the world needs a hero. But there are heroes all
around us or at least people doing heroic things. We just don't
recognize them as heroes. In real life, there is no Superman. But suppose
each of us is a Clark Kent, hiding an "inner Superman"?
We wanted to attack a problem that was beyond just our ability to solve. We wanted to create a better world, not just entertain. We wanted to think beyond the contest, while still participating within its constraints. We wanted to do well, but more importantly do good.
The Solution
Our solution was to create an application that makes it simple (in a way only possible with modern technoloy) to be
recognized and recognize others for doing simple deeds that might
otherwise be too mundane to mention (mundane being what most people's initial impression of Twitter's concept was), meaning also that it's "not worth
doing". At first, we would be increasing awareness of the dismal situation
within and around each person, then encourage them to take small
actions to improve the situation with friends and strangers. There are still some good people left in the world; others are at least good enough to act altruistically if it's convenient enough. Not only would you receive recognition for your history of good deeds, we would arrange for local businesses to sponsor the top do-gooders on each district's leaderboard, giving them access to influential people (in a way that Klout is trying and failing to do). This would provide operating and marketing income as well as give people an extra push to participate.
Some Use Cases
You see a truck hit a bike. Before the truck driver has a chance to get away you snap a quick photo of the truck's license plate, tag it as a crime-in-progress, and your photo and location are quickly uploaded. Now, anyone else using the app in the same neighborhood can spot the truck and force it to stop.
You see a pile of trash near a canal. You snap a photo and tag it "trash" and as you're clearing it up, a fellow user who lives nearby comes to help. When you've cleaned up the area, you both snap shots of the results and receive thanks from each other and some latecomers.
You get stuck in traffic. Up ahead you see that several cars are in the wrong lane and are stuck in gridlock. You post a "traffic" update with location and a few people about to leave work, and a friend in a taxi approaching that intersection thank you.
You see a new crack in the road. You snap a photo of it and send the link, which includes the GPS coordinates, to the local authorities. After a few weeks, the crack hasn't been fixed and has grown wider. Eventually, the post gathers "thanks" and comments from a number of people and someone is forced to take responsibility for the fact that action wasn't taken earlier.
You see your neighbor abuse his wife. What can you do? After publicly shaming him, you receive some helpful advice in the comments.
Your neighborhood has a small plot of unused dirt, so you plant a tree there.
There are also the good things others are doing. When you see someone who is not a police officer stand in the street and direct traffic. When a mother scolds a child for littering. When a stranger tells you your bag is unzipped, or your phone about to fall out of your pocket. The person who sticks a big block in a pothole. The person who stops a taxi from entering a crowded one-way street in the wrong direction. The person who subdues a drunken belligerent Australian when the police couldn't do it for two hours. The inspector who refuses a bribe. The seller who throws out dirty or spoiled food. The car that doesn't enter a backed up intersection and block it when the light turns red.
SoLoMo
The idea has all of today's buzz words. It's social, mobile, and local. It has crowdsourced goodness. It will post to your Facebook, Twitter, and Foursquare. It's green, social enterprise that profits from companies that want to greenwash. It's got gamification. It's a location-based service measuring real reputation online. It consumes web APIs like Google Maps, while exposing its own API for others to mashup.
Implementation (click to expand)
Drupal | REST | iOS | Your Social Networks
The mobile application stores and retrieves data from a website we developed for it. I developed a
web backend and frontend using Drupal which exposes a REST API which was consumed by
the iPhone app which could use it to login, create and retrieve local status updates
with photo and location much like Facebook, Twitter, or Foursquare.
Other people could then see what people were doing near them and
either thank them or leave a comment, or even go there in person and help -- it could be happening a hundred meters away. By
posting updates and getting thanked you earn points which puts
you on the leaderboard for your local district and can lead to being awarded badges, like "trash hero". The idea was we would
find local businesses to sponsor each district and give prizes to the
community leaders while getting to be associated as an upstanding member of a
neighborhood.
We integrated with Google maps to show location and also used their
reverse geo-code API to find the ward or district name, so people could "follow" a neighborhood irregardless of distance -- like their home. Furthermore, there was a one-way "follow" relationship like Twitter and Google+ to get all of a local hero's updates. More followers leads to more thanks.
The web version (same Drupal site as the API) has all the same functionality as the mobile app
and more. We developed an iPhone app for the contest, but an equivalent Android version would be easy to build. We used Twitter Bootstrap as a foundation for the frontend design.
In the future, we could strongly integrate with Facebook, Twitter, Foursquare, and any other social network which allows geo-tagging of posts, so their posts appear inline with your local hero timeline.
Presentation, judging, and lessons learned (click to expand)
All teams had to be physically present in the main room at 1PM on Sunday, which effectively meant we lost over an hour of hacking time. We arrived just in time for the deadline, but then waited another 4-5 hours to give our presentation and demo. We had probably slept less than 8 hours combined among the three of us, and by the time it was our turn to present, I was nearly completely faded. There's a lesson in that.
Humans Get Worn Down By Serial Decision-Making
Our first lesson was this: don't present last. Don't expect judges not to be mentally exhausted after several hours of listening to presentations. Don't expect that their state of mind will be the same when they started as when they're about to finish.
Don't Alienate The Judges
In short: Our presentation was a failure. It was a trainwreck that lasted 10 minutes. By the time we were presenting, a strict 10 minute time limit was being enforced. I think our presentation was designed for 20 minutes. Both Cong and Hong had experience with previous MobileDevCamps and they had made a presentation for the app before I had finished coding.
We opened with a video of a toddler in China being run over by a truck, a clip that sparked outrage all over the world including Vietnam and within China. It was bad form. My partner hadn't realized that two of the judges sitting in front of us were actually from China. They were visibly upset, not taking kindly to the implication, and this set the tone for the rest of the presentation. Meanwhile, other judges wanted to watch the video again. Not only did this upset the Chinese judges but the other sympathetic organizers were also quite upset by the possibility that we had jeapordized future sponsorship by the Chinese. By the time we were done talking about the video, we only had 5 minutes left, and hadn't even opened the app.
Fake It.
In the remaining time, we struggled to explain the idea behind the product and finally give a quick demo of some of the features. We ran out of time before showing off some of the minor features. One of the judges expressed interest in hearing about the implementation, and we missed a chance to impress based on technical features. There just wasn't any time.
So that's it. We lost. We learned some lessons.
1. Be one of the first to present if you can.
2. Don't single out and alienate judges.
3. Don't build clean, well-architected software with maintainable code. In real life, this matters. For this competition, it doesn't.
The greatest tragedy perhaps (besides not winning) was that the presentations were all made in private with the judges. Having groups present their apps for everyone to see, or at least putting them somewhere online, would have been the BarCamp way. As we didn't receive any feedback or anything from the judges, it would have been nice to share what we all worked on for 24 hours (multiplied by nearly 100 people) and be able to learn from others' experience. Even if there wasn't time for all to present, I don't think I was the only one interested in seeing at least the demos from the winners.
P.S. Our second idea was this (click to expand)
In Vietnam, emergency response service is nearly nonexistent. If you
get into an accident where you need emergency medical treatment you
will most likely die. People are reluctant to take you to the
hospital because the hospital will then expect you to pay the bill.
Taxis don't want to deal with getting blood in their seats. If nobody
contacts your relatives or if you don't have enough money in your
wallet to pay the hospital on arrival, people will just let you die because they don't feel it's their business. See Idea #1.
Our idea was to make it so your friends and family could automatically
be contacted in case of emergency. Many phones have a feature where
without unlocking the phone, the phone can still make emergency calls.
But what if the phone could also send an SMS message and some friends
as well as post a call for help on your Facebook wall, your Twitter, your FourSquare, etc. along with your location. It could turn out to be a follower on Twitter you don't follow back who happens to be nearby who saves your life. In Vietnam, this type of "hail Mary" is more likely to get a response than the local 911-like service. Of course there are problems, like the fact most people wouldn't think to install the app until they're laying there dying, if that.
Recent comments
1 year 11 weeks ago
2 years 3 days ago
2 years 1 week ago
2 years 3 weeks ago
2 years 19 weeks ago
2 years 19 weeks ago
2 years 19 weeks ago
2 years 19 weeks ago
2 years 19 weeks ago
2 years 19 weeks ago