SurveyMonkey Goes Mobile

In 2016, SurveyMonkey released a redesigned mobile version of our webpage. We have seen a marked improvement in the user experience on mobile devices that we wanted to share what we did and what will come in the future.

Why did we build a mobile site?

Over 25% of users signing up for our services are doing so on a mobile device and the numbers are growing.

We didn’t just want to give users a responsive site, but a site designed for use on a mobile device. We took in mind space, speed, and internet connectivity limitations. The mobile site offers users improved navigation, a new layout, and a streamlined, mobile-tailored feature set. To check it out, just sign in to surveymonkey.com on your mobile device.

How did we build our mobile site?

We built our mobile experience using React, React-Router, Redux, and Webpack. React gave us huge performance gains and the ability to easily reuse code. Redux made state management simple, while Webpack enabled us to easily bundle, minify, transpile, and polyfill our es6 modules. We used React Router to navigate between pages. We added code-splitting to load only the javascript needed for the page being viewed. This cut down on the initial load time and allowed us to load javascript on an as needed basis. On our servers, we enabled HTTP/2 to load assets faster and increase ajax return times.

There are several frameworks out there: React, AngularJS, Backbone, and Ember. We chose React for a few reasons.

First, it is the most performant of the popular frameworks

Source: https://www.codementor.io/reactjs/tutorial/reactjs-vs-angular-js-performance-comparison-knockout.

This is extremely important when using mobile devices. Google found that 53% of users will abandon your site if it takes longer than 3 seconds to load.

Source: http://www.marketingdive.com/news/google-53-of-mobile-users-abandon-sites-that-take-over-3-seconds-to-load/426070/.

React also has an active open source community. The community is continually improving and adding to the ecosystem by developing tools, libraries and best practices. In addition, React is easy to get up and running.

For large applications, state can become difficult to control. Redux has made this simple. We have one “store” that centralizes the state of the application. Anytime we want to change the state — for instance, if a user changes their account preference — we call an action to update the state. Redux is a great library that has simplified a lot of the issues with Flux (the original state management library developed by Facebook).

How does our mobile site work?

  1. When a user requests a page, we send back raw html containing the application shell (the header and footer) and just enough javascript for the loading spinner.
  2. When the remaining javascript is loaded and parsed, we render the contents of the page.
    Screen Shot 2017-07-12 at 6.46.21 PM
  3. Moving around the mobile site is fluid and snappy. Thanks to React-Router, the user can navigate around without needing to reload the page. We fetch only data that is needed for the current page, and if we already have that data we don’t fetch it again.
    Screen Shot 2017-07-12 at 6.46.31 PM

Our mobile site feels so much like an app that it’s easy to forget it isn’t. Take a look at our Android app versus our mobile site. Can you tell the difference?

Screen Shot 2017-07-12 at 6.46.38 PM

Well if you can’t, don’t feel bad because it is actually the same code! That’s right, we reuse our React code for both our iOS and Android apps.

Old vs. New

The new experience increases mobile conversion rate by 50% and survey deploy rate by 43% in our english speaking countries. Before our redesign, users would have to pinch and zoom to navigate and create surveys. Now you can easily navigate between pages and create surveys on the go. Here is a look at what the mobile experience used to look like versus now:

Screen Shot 2017-07-12 at 6.46.45 PM

What will the future bring?

With the introduction of Progressive Web Apps, we want to spice up our mobile experience even more. In the next year, we hope to incorporate Service Workers and tree-shaking to improve load times and caching. Services Workers will make previously visited pages load faster even without internet access. Tree-shaking will allow us to eliminate unused code from our javascript bundle. Webpack 2 does this by looking at your code and including only modules that you actively import. This greatly reduces the total javascript bundle size and decreases the time it takes to load an interactive view. In addition, we would like to bring what we have learned on mobile devices to the desktop experience… Because, why shouldn’t everyone have faster load times and a better experience?

2016 Interns Reflect…

We asked a few questions to some of the SurveyMonkey 2016 interns about their experiences. Here are their responses..

Catherine Johnson, Rising Senior at University of Washington

How did you find out about this internship?
Catherine_Johnson_1_I first found out about this internship at my school’s internship fair when I talked to some employees at the SurveyMonkey booth. After having a pleasant conversation with someone at the booth, I gave them my resume and a day later they contacted me for an interview. The interview process itself was very straight forward. My future manager and I just sat and talked about my experiences, what I knew about the company, and solved a few problems such as constructing a method that converts ascii characters to integer values. The interview even went a little over time because we were having such a great conversation. In the end it was a great experience for a process that tends to be surrounded in anxiety.
Continue reading

Monkeying Around with Machine Learning Workflows

Machine Learning at SurveyMonkey

SurveyMonkey collects around 3 million responses each day, which has amassed into an extensive treasure chest of structured and unstructured survey data over the years. While the raw data has been analyzed and processed for the SurveyMonkey data businesses—Benchmarks and Audience—we’ve only just begun to perform more sophisticated statistical machine learning on the data. More specifically, some of the problems we are currently tackling are in the area of natural language processing (NLP) such as:
Continue reading

The Architecture Behind SurveyMonkey

For those of you interested in what’s under the covers here at SurveyMonkey, here’s an overview of our tech stack and architecture.

For most of SurveyMonkey’s 16 year life, the website was a monolithic application written in C#, sitting atop a single SQL Server database. Six years ago, for reasons that were as much logistical as technical, we realized that we needed to re-architect the system. We decided to replace the monolith with a Microservice Architecture. This bought us a couple of nice benefits:
Continue reading

Welcome to our Engineering Blog

Engineering VPThree big events have set the course of our company, SurveyMonkey, and with it, our long strange trip in Engineering. The first event occurred in 1999 when our founder, Ryan Finley finished the 1.0 version of SurveyMonkey. 7 years before Fred Wilson and Jarid Lukin popularized the term “freemium”, SurveyMonkey was born and became one of the “freemiums” best case studies. Ryan and his employees doggedly pursued our customers with a simple model: build features that customers want, tweak, brush and polish until it’s easy to use, and then rinse and repeat.
Continue reading