How we built an app for crowdsourcing questions for interviews

Have you ever attended a fascinating live interview at a conference or other event and wished there was a way to share great questions with the host?

We built a tool so you could do just that, and Glitch CEO Anil Dash tested it while he interviewed Mindy Kaling at Twilio's SIGNAL conference.

We received 194 questions from the audience and Anil ended up asking Mindy about ten percent during the hour-long keynote interview.

Here’s how we did it and how you can use our free Glitch app to collect questions at your next event, too.

Conceptualizing the app: a brief overview

The interview took place on stage while Anil showcased how the Twilio API works, creating an engaging experience for the audience and for Mindy. We often work with partners to develop apps that help them engage in meaningful conversations with their communities or showcase their APIs.

We wanted to build an interview-style questions and answers app that lets hosts solicit live questions from the audience without compromising user privacy. We baked in a human curation element to control for harassment, et voilà! You have an app that lets you engage with hundreds of people:

The next step: pitching our idea to Twilio.

The Solutions Engineering team often has to move quickly on projects, so we always want to provide enough information to describe the project without getting too mired in technical details to avoid unpleasant surprises and get all questions answered before a single line of code is written.

We agreed on an app that presented a landing page explaining how to send in questions for Mindy, an administrator area where incoming questions could be curated, and a presenter area that Anil would use onstage. We knew that limited time meant only a certain number of questions could be asked, so Glitch and Twilio staff would log in to the admin area, select which questions to feature, and send them to the “presenter” section of the app.

Twilio approved the idea, and off to work we went!

We primarily leveraged Twilio’s Programmable SMS service, but we also included a form on the landing page — some users might not have a roaming plan that includes text messages at a reasonable cost, so we wanted to ensure there was an alternate way of submitting a question.

(Programmable SMS is a paid service by Twilio. Signing up for a new account will get you US $10 in credit. Your phone number will cost $1/month, and each SMS sent or received in the US costs $0.0075 — for our purposes, that $10 will go a long way.)

We had a total of about four days to build and test this project. That’s a short timeline, but by scoping the work the way we had, it was possible!

The app: an(other) overview

The app is a Node.js app that can be broken down into three areas.

Going to the live Glitch app gives users instructions on how to send in questions for the keynote. It’s a basic HTML page with a single-input form to send in questions. In the lead up to the keynote, the FlipDown library was used to generate a countdown.

The form sends the submitted question to the app’s back-end server, which returns a success or error message.

A big ol' text input on the internet for submitting content to a live event can be a little ... scary. Beyond being a vector for abuse, it’s possible someone accidentally submits a password or other sensitive information. We decided against displaying questions live as they came in. Instead, they’re fetched and displayed at a password-protected /admin page. On this page, a teammate can click/tap a question that they’d like to send to the interviewer.

The interviewer accesses this subset of questions at a different /curated page, which is also password-protected.

The back end of the app consists of two files: an Express server in server.js, and the methods for storing, fetching, and manipulating submitted questions in storageController.js. Let’s look at the key features of each:

server.js handles the back-and-forth between the app and your browser. It’s set up to parse incoming questions and to always use secure HTTPS connections, and then it sets up the GET and POST endpoints. GET endpoints fetch data from the server, and POST endpoints provide a place to send data.

We serve the three pages mentioned in the front end description:

• the landing page, at /
• the admin page, at /admin
• the presenter page, at /curated We also set up a /questions endpoint, which is where the admin and presenter pages GET the list of submitted questions. This endpoint is what’s password-protected on those pages.

There are also three POST endpoints for submitting data:

• we set up /sms to listen for questions being submitted via Twilio’s Programmable SMS service

• we set up /form to listen for questions being submitted via the form on the landing page

• we set up /toggleSelection to listen for staff selecting (or un-selecting) a question on the admin page storageController.js, on the other hand, is what handles the back-and-forth between server.js and the data file where the questions are stored, using three methods:

• getQuestionList fetches the list of questions from the data file

• addQuestion adds a question to the end of the data file

• toggleSelection changes the selected property of a given question in the data file So how does all this work together? When you send an SMS or use the form to submit a question, that question gets added to the end of the data file with a selected value of false. When a teammate goes to the admin page, they log in and get the list of all questions in the data file; if they tap or click on a question in the list, it toggles the selected property of that specific question.

On the other hand, when the interviewer goes to the curated page, they log in and get a subset of all the questions in the data file — specifically, they only see the questions where the selected property is true.

Integrating the Twilio API

We built the form-based functionality first so that we could test the back end independently of what the Twilio service might require. However, we also stubbed out what the /sms endpoint would look like, using this excellent guide from Twilio.

The form-based approach pretty much copies this — including returning TwiML (Twilio’s extension of XML) rather than, say, JSON. Eagle-eyed readers will see that the only difference between the /sms and /form endpoints is the twilio.webhook() middleware. This validates incoming requests to make sure that incoming requests are coming from Twilio by checking them against the TWILIO_AUTH_TOKEN value in the .env file (which we get from our Twilio developer account). Then it’s just a matter of telling Twilio where to send SMS messages.

As mentioned in Twilio’s guide, this is done by setting up webhooks (in the Twilio Cloud Console’s “Active Numbers” area, choose a phone number and look under ). Under “a message comes in” we set up a webhook pointing to the /sms endpoint (using HTTP POST). And in case that fails, we set another webhook pointing to the /form endpoint (again using HTTP POST). This is why we set up the form handling logic to return TwiML. Our webpage can parse the response as XML, but Twilio can also use this to reply to an incoming text message, too. We’ve already got that endpoint open to the world via the form, so using it here as a fallback is convenient.

Make this interview app your own

By leveraging the Twilio Programmable SMS API, we were able to very quickly build an app that creates an exciting and engaging live experience.

Working on a very short deadline meant that we had to make some design tradeoffs to reduce complexity, but the ease of integration of the API — as well as Glitch’s zero-setup development environment and near-instant feedback loop for rapid iteration — allowed us to go from new project to live app in no time flat.

Are you running a live event and looking to increase audience engagement? Remix the app and make it yours!