The Story of a Feature: Flashcards

The Weekly Iteration

This video is only a short sample, but you can access the full version and all our other great content by subscribing.

Video

Notes

On this episode of the Weekly Iteration, Chris and Ben discuss the recently added Flashcards feature on Upcase. See a behind the scenes look at the processes, decisions, and code used to release this new feature.

Introduction

Flashcards are a new feature on Upcase that allow for learning on the go. They're designed to be mobile friendly overviews of programming concepts that you can review even when you only have a few minutes:

sample flashcard

The idea

Ben originally had the idea for a simple Ruby quiz which he tested via twitter using a simple gist version. This got feedback with very little effort and told us that there might be something worth pursuing in the quiz idea.

Following that, we had a simple brainstorming session to rough out the initial version we wanted to implement:

Initial flow white-boarding image

Mobile Testing

Since this functionality was intended to fit well in breaks, commutes, and other short bits of time, it was likely that users would be trying out the quizzes on their phones and we wanted to ensure that we provided a great experience on mobile. In order to focus on the mobile experience, we used the following techniques and tools:

  • Browser Mobile Emulation - All browser testing during the development was done with the browser mobile emulation enabled. This ensured a truly mobile first development focus.
  • Ngrok - Ngrok is a tool that allows you to expose your local development server to the internet. Using this, we were able to test the feel of the application on real devices while still working from our local development setup.
  • Staging - Although ngrok made it possible to test on real devices, there is still no comparison for testing against a production environment to get a feel for the actual performance of the feature. Our staging server allowed us freedom to test without worry of messing up production data.

Development Processes

Although the development was relatively traditional Rails work there were a few aspects of the development process that stood out:

  • True TDD - The first few days of coding were spent almost entirely in the terminal, TDDing out the functionality and barely touching the browser.
  • Ping Pong Pairing We used the practice of ping pong pairing in which the team alternates one person writing a test, the other writing the implementation code to make it pass. Check out this Weekly Iteration episode on PingPong Pairing for a more detailed introduction.

Deferring Functionality

Although we had many more ideas for enhancements to the flashcards functionality including a number from early testers, we purposefully chose to push these out in order to get this feature in the hands of all our users sooner.

Admin

Upcase currently uses RailsAdmin but for the flashcards admin we chose to implement a custom admin rather than use RailsAdmin automatic configuration driven interface.

Although this took a bit longer we had found that RailsAdmin had certain limitations and would occasional fail on more complex relationships and workflows. By building our own admin pages we were able to optimize and test the specific workflows we needed, while leaving the rest to be done in the console.

One particular example of an optimized workflow was in the live preview functionality we added to the Flashcard editor. We implemented the live preview functionality using a bit of JavaScript and a very minimal FlashcardPreviewsController. This again allowed us to focus on the mobile experience.

Note you'll need access to the Upcase repo on github to view the above code samples. Upcase subscribers can get access by visiting the repositories page on Upcase.

Decks admin page

Phased Release and Testing

  • We made sure to close out the first PR early to avoid having a long running branch. We had initially started building out the admin on the same branch, but popped that off to a new branch and closed out initial push.
  • We used a simple admin visibility flag to allow internal release to colleagues at thoughtbot for early testing
  • Beta testing was then done with a handful of Upcase users via a simple user attribute
  • We specifically did not use something more full featured like rollout to manage access during this phased release to keep things simple.
×

15 Full Courses, 100+ Screencasts & New Content Weekly