The Final Stretch

Team Synapse is one week away from the CS210 final project fair, where we’ll present two quarters of development work to a community of Bay Area entrepreneurs. As we approach delivery of our final product, we’ve been developing a few key features to improve user engagement.

One of our main goals has been to improve the Synapse experience for users not currently experiencing a disaster. During our first product launch, we noticed that many users found their initial download experience to be confusing–they would open our app, see a blank map, and be unsure how to proceed. Pins only begin to appear on the Synapse app during a disaster scenario, so users who download our app currently don’t see any content which might keep them engaged.

To counter this problematic user experience, we’re developing two core features: a newsfeed and a Synapse tutorial. Jordan is leading development on our newsfeed, which will provide a portal for local governments to communicate with constituents. We hope that early Synapse users will be encouraged by newsfeed messages. A newsfeed message from Jerry Brown saying “Thanks for preparing yourself with Synapse; if a natural disaster occurs, please return to the application” may help users trust that our application will serve useful in a disaster. Jacob is taking point on our tutorial feature, which will be shown to users as soon as they download the Synapse app. The tutorial walks users through basic flows such as refreshing events, dropping pins, and disputing and verifying reports in order to introduce Synapse users to the application. By show users what they can expect out of the Synapse application, we hope to decrease the rate of uninstalls.

Our last development push has been to flesh out two new Synapse clients: the Synapse SMS client and the Synapse web portal.  The Synapse SMS client is a low-weight way for feature-phone users to request data about infrastructure changes in their area. It will complement our Android application in regions where many mobile users have feature phones, not Android devices. The Synapse web portal is online tool for local governments and aid organizations to view an overarching summary of all reported infrastructure changes. John has taken point on this web application, and Josh has handled user authentication through Auth0.

We’re spending our last few days of development hammering home a few last features: mobile application login, UI improvements, and a cronjob to remove expired pins from the Synapse map, to name a few. We plan to be feature complete by Wednesday, and will spend our last work week preparing our software demo.

Check in next week to hear about our software fair demo!

Lessons from Launch Week

Since our last check in, we’ve been analyzing our launch week and key performance indicators, hunting bugs, and planning the next steps for the Synapse platform. Last week was all about a final sprint to get our application out to users. Now that we’ve published it, we’re looking to reevaluate what our focus is for the final weeks of the quarter.

During launch week, we ran a Facebook ad campaign to get the word out about our launch. While we reached a lot of people, we noticed a drop off between initial clicks and downloads, so we’ll be focusing on changing our Play Store listing to be more international, and updating our description and graphics to better showcase what our app can do.

In terms of development, Jordan and John have been focusing on changes to the client in order to improve user experience. Josh has been finalizing the details of the login process, which will bring increased information about users and will help change the way we assign value to each person’s reporting of events. Jacob has been hard at work trying to make changes to our application so that we can also release it on iOS and expand our potential user base.

Now that we’re moving into the final weeks of spring, we’ll be putting the finishing touches on existing features, making sure our application is as robust and bug-free as possible, and working to create a web interface for NGOs and governments to be able to access information that users report to help them respond to these situations. Stay tuned!

Launch Week

Team Synapse is proud to announce that we have officially launched the Synapse mobile application. Individuals can now download Synapse from the Google play store, and use it to communicate about road closures, aid stations, and other infrastructure changes in the immediate aftermath of the disaster. In this post, we’ll talk a little bit about our launch from a business perspective and a software perspective.

To spread as much publicity as possible about Synapse, we took a multi-pronged approach to launch. Our first goal was to ensure that information about Synapse was easily accessible, so we built a Facebook page and product website. We also developed a Google Play Store download page which included product screenshots and a product description. Lastly, our our corporate partners at Oracle helped us develop a product introduction video, which provides a description of our team mission and is accessible from our website.

         

With these launch materials at our disposal, we set out to ensure that the Synapse launch would be visible to our partners and to others interested in the disaster relief space. We sent release announcements to individuals like Rob Munro and Butch Meily, who provided key insights in early product development. We also launched a Facebook ad campaign, and reached 105,000 unique users in the first 24 hours of our campaign. Installs from these initial downloads will help us track KPIs throughout the next month.

One last publicity push is still under way. Together with Oracle, we look forward to releasing a technical article describing our use of Mobile Cloud Services. We can’t say more about this now, but stay tuned…

Of course, the majority of time spent on this launch came in the form engineering groundwork. In order to get Synapse out the door, we drove our development cycle into turbo mode. Here are new features you’ll see on the launched Synapse application:

1. 1. A visual overhaul of our application. Jordan designed new application icons, John updated the user experience for viewing a new event, and Josh developed a new splash screen. Together with a freshly sculpted logo from Oracle’s design team, these visual changes mean that the Synapse mobile application is looking cleaner than ever before.
   2. A real time scoring algorithm. Jacob built a scoring system which takes into account user upvotes and downvotes geospatial information about those event votes to compute a “reliability score” for each event on our map. If an event score becomes too low, it is automatically removed from the database.
   3. Complete Oracle Mobile Cloud Services integration. John organized a complete deployment to Oracle MCS. Our Flask backend now runs on an nginx server on an Oracle compute instance, and Oracle MCS wraps around this server to filter API calls and collect request data. John and Josh also configured a “Staging” server, where changes to the backend can be tested end to end before the deployment of a new change.
   4. Map tile caching. Jordan finalized a feature which allows a user to download entire cities while online, and refer to that city map once the user is back online.
   5. Other miscellaneous features, including: the ability to only refresh events in your current window, improvements to our syncing UI, complete offline queuing for user actions, a MapBox upgrade to improve the speed of application, and many small UI improvements.

The last two weeks have certainly been a sprint. We’re ecstatic to have officially launched, and are turning our heads towards new features which will improve user engagement. An iOS version of Synapse, a newsfeed, and photo uploads are at the top of our to-investigate list. Stay tuned!

Dev, Dev, Dev

This week was another dev-heavy one for Synapse–as approach launch, we’re working to get as many features up and running as we can.

Our main dev focus for the week has been preparing the app for use in low-connectivity situations. In an earthquake, data access often remains spotty for a few days following the disaster. Data use can be costly and inconsistent, so we want Synapse to provide a natural user experience when phones are offline.

Jordan and Josh have been leading the charge on this effort by building two key features: map tile caching and offline request queuing. Using our “map tile caching” feature, users can download map tiles when connected and access them regardless of their network status. This allows users to view streets and landmarks while completely offline. Our “offline request queuing” functionality allows our app to store user actions like report posts, event syncs, and event updates that a user makes while offline. Our app then listens for network connectivity changes, and makes a necessary server requests when the app regains service.

John continues to charge ahead on production-readiness for the Synapse app. He’s been working on Google Play deployment, incorporation of the Oracle MCS platform, and documenting our production pipeline. John’s also been our point person for testing the Synapse application, and continues to be a bug-fixing machine.

We’ve also been cruising on business development milestones this week. Jacob took point on constructing our “Real Customer Profile,” outlining two ideal users for the Synapse application. Jacob’s first profile focused on Mukta, an engineer at SAP who experienced “roughly one disaster per year” while living in India. His second profile focused on NGO/Aid Organization representatives, and spotlighted Rob Munro, head of Mission 4636 and former CEO of Indibon. Both profiles helped us center in on two target customers and consider how our application is being developed for both use cases. Jacob also finalized our Contract of Deliverables this week with Oracle! We’re now committed to a full list of deliverables.

Check back in next week to hear about launch!

Looking towards product launch

Team Synapse is continuing to plug away on development work as we move towards our product launch!

This week, we made a huge leap forward in productionisation. John completed our deployment to an Oracle Compute instance, which is running a server connected to a MySQL database. With our mobile application pointing to this new API address, the Synapse app will be able to handle many more users. Jacob also completed work on our backend API, updating DB schemas to lay groundwork for our “event” scoring algorithm.

On the frontend, Jordan merged and tested a refactor of our mobile application to prepare for launch. He also completed design documentation for the pin types that we will support for our final Synapse product. Josh and John will test these designs through experience prototypes in the coming days. We’re curious what information about local infrastructure changes will be most important to users!

Josh spent the week designing and developing another core front-end feature: offline queuing of user network requests. Our app is designed for users in low-connectivity situations, so Josh built a RequestManager that uses local storage on Android to cache requests which fail due to low connectivity. He’ll spend this week integrating the RequestManager into our current Synapse codebase.

Last (but not least) on the development side, Jacob built a Synapse website which will accompany our Synapse product launch. The site will serve as a homepage where potential users can discover more about the Synapse product.

As a team, we’ve also been building the business-side of our project. John led the team in a “Closing a Candidate” exercise, where we defined team cultural values and simulated a first-hire scenario. The event was a helpful reflection for Synapse: we identified a team cultural values such as “being willing to debate”, “driving towards goals”, and “wearing many hats.” We also wrote up a first draft of a contract of a deliverables, which defined our minimum featureset for launch.

Stay tuned on our work this week as we drive towards product launch and keep developing our application!

Diving into development

Team Synapse has recovered from Tokyo jet lag, and we’re back in development mode!

As you read last week, extensive user testing interviews culminated in a three hour “Big Think” session on Sunday, 4/9 (pictured below). We wanted to review user feedback, evaluate our current feature set, and establish development goals for the next eight weeks. Our “Big Think” helped us establish minimum pre-launch deliverables, and gave us the opportunity to develop a wishlist of future features.

Currently, we’re hard at work on our minimum pre-launch deliverables. These will guide the Contract of Deliverables we develop with Oracle in the coming week. We’ve built a task list to organize dev work for our deliverables, and are hacking away! Each member of Synapse is taking point on a few aspects of development.

John is leading the “productionization” of our code. He’s leading a migration to Oracle MySQL Cloud Service, and is writing up plans for how Mobile Cloud Service will support the current Synapse product.

Jordan is taking point on client development. He refactored our ReactJS code to prepare for another wave of front-end development, and added new features like “current-location” functionality which center the app on a user’s GPS coordinates.

Jacob is hacking away on the Synapse backend, extending the “Events” and “Reports” schemas we’ve already built and adding API endpoints to enhance app functionality. He’s also building a website home page for Synapse to help us communicate our value proposition.

Josh has led database migration as we move from SQLite to MySQL. He’s also developed some new front-end features, and is developing login and offline message queuing.

We’re excited about the week to come, and will keep you posted on our development process! Look out for more updates on our Contract of Deliverables and our outline for closing a first candidate.

Back in Action

We’ve learned a lot over the last few weeks. After building our proof of concept and presenting to our corporate liaisons at Oracle Headquarters, we moved on to collecting feedback from as many sources as possible so that we could launch into our next big product cycle and move one step closer to deployment – and everyone had something useful to say.

We were lucky enough to have the chance to meet with Bill, a CERT from the Palo Alto area who’s trained to be a community leader to step up and help respond in the event of a disaster, as well as Sandy, a member of one of FEMAs Disaster Medical Assistance Teams (DMAT). They both gave us valuable insights about our product, both as users and as sources of information about the natural disaster space. Kathy Davies from the Stanford d.school also gave us design centered feedback on our interactions and on engaging users, and Matt Huang from Sequoia talked with us about our target customers and acquiring users.

Our post-Proof of Concept user testing culminated in team Synapse’s most exciting endeavor yet: a trip to Tokyo, Japan.

Synapse chose to visit Japan because the country faces more earthquakes than almost any other area on earth. As a result, cities like Tokyo have extensive disaster preparedness infrastructure. Since the 9.1 magnitude Tohoku earthquake hit Japan in 2011, Tokyo residents have engaged with disaster preparedness products ranging from guidebooks to apps to news sources. Synapse wanted to investigate these products to learn which features were most useful to consumers, and which user needs were still unsolved. Over the course of 5 days, meetings with Oracle Japan employees, IDEO design director Greg Perez, CS210 alumnus Yuri, and Canadian expats  Kirk and Agnes helped us better understand the disaster preparedness landscape in Tokyo. And luckily for us, the cherry blossoms were in bloom!

At Oracle, product leaders talked to us about product internationalization. What might it mean to deliver a product to a Japanese audience? How can early design decisions make a product internationally accessible? At the end of our meeting, we were lucky enough to experience a traditional Japanese tea ceremony in Oracle’s tea room. Many thanks to Junichi Chigira, Reiko Saito, and the many other Oracle employees that made our visit such a great experience. Unfortunately, we couldn’t take pictures inside the office, so here’s one of us in the lobby:

At IDEO, Greg chatted with us about Japanese design standards, and about existing disaster preparedness tools in Tokyo. We learned about the “Yellow Book”– a large disaster preparedness manual, which is designed with comic illustrations to make preparedness accessible.

Conversations with other Tokyo residents–Yuri, Kirk, and Agnes–gave us a much better idea of how Tokyo residents reacted after the 2011 earthquake. How were risks about radiation perceived? What information sources were helpful? Were resources readily available? We were amazed to realize that for many Tokyo residents, finding basic supplies like diapers was close to impossible after the disaster. We were also surprised for many individuals, sensationalized news reports were often more accessible than formal updates from the Japanese government. One of the most striking facets of Japanese disaster preparedness was the use of technology–many residents used apps to track earthquake reports, and the Japanese supported an alert system to give SMS alerts in the event of a large earthquake.

Overall, our meetings in Japan gave us a picture of a culture which is extremely developed in its disaster preparedness–apps, guidebooks, and government updates were all very advanced. Importantly, all of our meetings highlighted important shortcomings in current technologies. We feel well-positioned to meet user needs which current products are failing to design for.

Through all of our conversations, we gained a lot of key insights about the direction of our product, and what to focus on as we tackle our second quarter. Our user testing taught us a lot about usability, specifically about interactions with a map and how we can make them as intuitive as possible. Our hosts from Oracle Japan taught us about internationalization, something we’ll consider deeply in our design cycles from now on. Additional needfinding conversations both in and out of Japan taught us a lot about the priority of information in a disaster, what types of information we can still include, and disaster preparedness applications. Our trip to IDEO really reminded us about user-centered design, and gave us ideas about how we can make Synapse useful in more than just a disaster situation, so that it’s maximally effective when disaster strikes.

One of our greatest finds while in Tokyo was the suite of disaster applications in Japan. This really helped us understand what needs were being met already, and how in most cases, although an application might solve one or two needs out of many, there still isn’t really an information solution that incorporates some of the most important features of a disaster application.

On top of all of this, we got so much information and inspiration just from being in Tokyo. The background hum of emergency preparedness was really present in the city, and is an experience that will color our product.

Now that we’re back in the swing of the quarter, we’re trying to hit the ground running and launch into our next big product cycle. Once we had recovered from jet lag, we got together in the Loft for a “Big Think” design meeting about the future of our product. We revisited who our users were, recentered on our most important features, and prioritized what we’ll need to do in order to get ready for launch. We also created a “dream product” featureset, which includes everything we might like to see in our application, even if it might not happen by the end of the quarter (or be technically possible – yet!). Finally, we talked about our launch and deployment strategy, and determined our key performance indicators – the pieces of data that will best inform whether or not we’re hitting our usage goals.

We’re excited to dive back into development, and will be back soon with more updates on what we’ve built.

Houston, The Eagle Has Landed

Two weeks ago, we began development work with just two expo markers and a whiteboard. We gathered in a Stanford meeting room and mapped out our tech stack, our proof of concept featureset, and our development flow. 94 github commits (and a few sleepless nights) later, the Synapse proof of concept application is complete!

With the current Synapse app, users can drop pins on an interactive map to report infrastructure changes. Users can specify the severity of an infrastructure change, and also upvote and downvote events reported by others. In order to limit data consumption, our app also provides a “sync” button to allow users to fetch changes posted by others.

         

The Synapse proof of concept is a full stack application. Our ReactJS frontend runs on an Android device and communicates with our backend server. Our backend is built on the Flask framework, is written in Python, and integrates with a SQL database. We deployed the Python backend and SQL database using “pythonanwhere”, a quick cloud deployment tool. With this full stack deployment, users on the proof of concept app can drop pins to each other from different phones.

Each team member contributed core features for our proof of concept. John tackled front-end UI development, building buttons and modals to help users report infrastructure changes and change event ratings. Jordan took point on the map interface, using the MapBox ReactJS API to build droppable pins and a scrollable map. Jacob wrote our server code, using Flask, Python, and pythonanywhere.com to deploy a restful Python server. Josh built our SQL database by writing a series of initialization scripts, and wrote networking code on the front-end to integrate our ReactJS app with our Python server.

On Friday, our team got the chance to present our work at Oracle Headquarters. We presented to Oracle President of Product Development Thomas Kurian (!!), our advisors Jenny and Ashish, and Oracle media whiz Lauren Cohn. We also got a great tour of Oracle campus. Thank you to everyone at Oracle that made the day so great–we felt lucky to share our product development process with you all.

Over the next week, we’ll be gathering feedback on our proof of concept and overall business strategy. Recent meetings with Sam Edelson (entrepreneur and investor) and Julie Stanford (founder, SlicedBread Design) have helped us consider next steps for the Synapse product. Stay tuned!

 

Sprinting to Deliver an MVP

Team Synapse is now in full dev mode, and we’re sprinting to deliver a minimum viable product (MVP) by March 16th. Our MVP will be a functioning Android app which allows users to mark road closures on a map, and receive road closure information from other users.

We’re building a React Native frontend, a Python backend, and a SQL database to deliver our first product. Each Synapse team member is developing full stack, and for this two-week sprint, each of us is tackling a specific task. John and Jordan are focused on the frontend user experience this week, so they’re developing in ReactJS. John is focused on user flows which allow a Synapse user to add new road closures. Jordan is focused on the map portion of our app, and is integrating the MapBox API into the Synapse frontend. Jacob is taking point on our Synapse API, and is using the Flask framework to define endpoints for our Synapse client. Josh is tackling the Synapse database. He is defining schemas and writing initialization scripts to build our SQL database.

We’ve defined our tasks for the week through github issues. We’ve used a development sprint board (https://waffle.io/cs210/synapse-code) to organize code tasks, and we’ve used a general sprint board (https://waffle.io/cs210/Oracle-Mobile-2) to organize product and needfinding tasks. The sprint boards have helped us split team jobs evenly between our four members.

Synapse has also been lucky to work with Oracle’s Mobile Cloud Service (MCS) for this project. Many thanks to Ashish, our technical advisor at MCS. In the coming weeks, we’re excited to integrate MCS into our application. MCS services like API analytics and mobile notifications will be invaluable as we expand the Synapse product.

Our team will be heads down until March 16 to finalize our Synapse MVP. On March 17th, we’ll present this product at Oracle Headquarters. We’re ecstatic to share our work with our Oracle mentors: Jenny, Rich, Arvind, and Lauren. We will also have the honor of meeting with Thomas Kurian, President of Oracle Product Development. After three months of product work, we cannot wait to share our work.

Stay tuned for updates! We’ll posted a video of our product when we finish the sprint.

Prototyping Results: Defining Our Product

Last week, we told you about our plans to test experience prototypes. This week, we have results. We’re excited to tell you how three main tests have shaped our final product concept, which uses peer-to-peer communication to spread information in the immediate wake of a disaster.

Our first  test came in the form of a Facebook advertising campaign. Why use ads to test our product? Facebook ads provide a quick and cost-effective way to test product assumptions on a massive scale. At Synapse, we wanted to know if there was general interest in a peer-to-peer disaster relief app. We also wanted to answer two essential product questions. The first touched on distribution: would users willingly sign up for a disaster relief service before a disaster hit? The second question explored the feasibility of our crowdsourcing model: would users be willing to generate content in the immediate aftermath of a disaster?

To answer these questions, we created a fake company called DisasterMappers, launched a site where people could “download” the DisasterMappers app, and advertised the DisasterMappers product via Facebook. We established a benchmark click through rate (CTR) and cost per click (CPC) for comparable existing ads, and established general benchmarks for download rate. Then, we launched. Over the course of seven days, our ad campaign reached over 150,000 users. DisasterMappers had a higher CTR and lower CPC than average facebook ads, and 30% of users reported an interest in sharing information in the immediate aftermath of a disaster. 5% of individuals who visited the DisasterMappers website downloaded the app.

Overall, our ad campaign validated Synapse’s product-market fit. Individuals were eager to download the DisasterMappers app, and many individuals were excited to generate content for the app. After testing our concept with over 150,000 users, we feel confident that the Synapse product will generate user interest.

Synapse also conducted two smaller tests to investigate different disaster relief interfaces. One of those tests explored an SMS interface, where users followed SMS directions to arrive at a central location. While some users were able to interpret SMS texts, many individuals got completely lost. What’s more, some individuals used different names to describe the same landmarks, which violated our initial hypothesis that landmark names would be interpretable by all users. Our second test explored a map interface, where users navigated to an objective by tracing routes on a map. We learned that maps were easily interpretable by users–even without descriptive names–but that users often forgot the names of streets and buildings that they were familiar with.

Overall, our 10-day prototyping sprint proved extremely valuable. After extensive user tests, we have settled on a final Synapse concept: our product will gather information from victims in the immediate aftermath of a natural disaster, and will deliver verified safety updates to individuals on the ground. Specifically, Synapse will serve mobile users for whom high-data apps (Facebook, Twitter) are inaccessible.

Now, it’s time to get our hands dirty. We’ve developed a high level architecture for the Synapse application, and we’ll be hacking away this week to develop a minimum viable product before the end-of-quarter CS210 software fair. We’ll keep you posted, and we’re excited to share what we build.