Behind the scenes of the HEXO+ app

Smartphone apps have become a mainstay in our daily lives. There are apps that do just about everything–track our food and fitness, monitor our sleep, do our banking, and even, fly drones (Hexo+!). There are hundreds of thousands of apps on the marketplace— have you ever wondered what it takes to get an app up and running? While we can’t speak for the other app makers out there, we have our own methods for developing the Hexo+ app that involves many steps.  With an upcoming release and also some new app features on the horizon (hint, “Magic Wand”), we thought you might be interested in getting a glimpse into our process for creating and publishing the HEXO+ companion app. Check it out!

 

1)  Identify need for the app

We start by asking ourselves, how can we make the product even better, provide more value, and attract new customers? What is the new feature or functionality that is needed? These answers and ideas come to us from many channels—  customers, ambassadors, Hexo+ internal team, partners and prospects. We take all suggestions and feedback very seriously and it all factors into defining the apps intended purpose. The input is gathered over time and logged. For the upcoming release of our “Magic Wand,” we heard from multiple user channels that in addition to the pre-programmed camera movements, people would sometimes like to be have more freedom to choose the angle, distance, and altitude from which Hexo+ films them. So we got to work. How to offer more flexibility, while maintaining such ease of use and intuitive interface, without turning our app into another remote control emulation of drone piloting…?

 

conception_2

 

2)  App brief and outline of desired specifications

Here is where we create “quick and dirty” specifications for the developers so they can determine the feasibilty of turning dreams into reality. We define the precise movements we want the app to perform in conjunction with the drone. Before we knew that we would create the “magic wand” we started out with the desire to have the drone and app interact in a very natural and intuitive way. So we sketched out the basic concepts; the rough height, interaction on the screen, speed, etc. . Once the team got working on it, they realized that they could turn the phone and app into a virtual magic wand by enabling users to wave their hand in the air to make the drone move. The concept seemed fun and innovative, so the name stuck! And the brief was created.

conception_5

 

3)  Prototyping

Prototyping is essential for getting a working sample in hand to physically test if what we had in mind actually makes sense. Prototypes don’t often have ALL of the desired functions (or the final look and feel)  that will be in the app, but enough of them to get a good idea of how the app will work and respond in general. Here we prototype it enough to be able to send it out for testing by multiple users.

For the magic wand, we started all of our prototyping on Android as this has historically worked well for us (but for future developments we will start first with IOS). We chose some limited functions to do a “quick and dirty” rough draft of the app for proof of concept. Before CES we had made a prototype of the magic wand that was working quite well, which enabled us to demo the magic wand during the tradeshow well before we were ready to publish the app to consumers.

At the same time we were prototyping the magic wand, our developers were working on the current HEXO app, fixing some bugs and creating a set of improvements on the app. Multi tasking!

 

4)  User testing

We’ve described user tests in an earlier blog... We typically give our beta testers the interface and ask them provide feedback, which is very valuable and allows us to refine specifications.

At CES, putting the magic wand into hands of athletes, media, and distributors made us realize the value of the concept (people loved it!)  and also identify where there’s still some work to be done before it’s released. For example, using the magic wand in follow mode resulted in very fast movements that could be perceived as dangerous. There were some questions about the interaction: is the increment of distance we used big enough? How do you adjust the distance? In hover one can’t control the drone with the magic wand, so how do we fix that?   These were all issues that were raised during this valuable hands-on testing in the field. It helped us identify where we need to further define the specifications.

 

5) Implementation Specification

Once all of the specs are defined and the concept is confirmed by users, we get to work on how to implement the details into the app. But before we can code the magic wand into the app, we need to define every single action, behavior, image, and message, and this work is done by the product team who pays close attention to the app’s ergonomics. Here are some questions we asked ourselves for the implementation of the magic wand:

  • Altitude: How high can we go, how low is too low before Hexo+ collides with the ground?
  • Behavior: What are the increments for adjusting distance, height, orientation?  At what speed is the drone moving, is it framing you while moving? What does it mean for a slide sideways to place the drone at any point? For the fly away? Does it make sense?
  • User Interactions on the screen: How do I grab the drone using the app? What feedback do we get? Are there vibrations? Should we implement voice command? Change of color on the screen? What does the screen look like? How do people know what do to next?

Defining an intuitive flow of use takes time and a lot of trial and error. We realize that the first version of the app was not perfect, so we worked (and continue to work!)  everyday to reduce the pain points and create more value for the user so that its super easy and intuitive to use.

Once we determine how to implement the specs, they are all mapped out on wireframes (and many other documents!) so that the development team has a road map to guide them. The hardest part is to fill in the gray areas, or confusions, that lead too often to recoding a function. So we try to limit those.

During this step,  there’s a lot of back and forth between real life and specification.

conception_3

 

 

6)  Development

conception_4

Our engineers transform the magic from paper to life through the writing of codes. Here they can encounter some challenges, and sometimes creating a new feature means questioning how we did all the previous developments in the past. What makes the most sense in the architecture? Is the development robust enough for the future evolutions?
The existing embedded system in the drone must be considered here, as well as how the new functions will affect the programming of drone behavior.  Sometimes developing new functions into an older system can create contradicting parameters, and regressions can become a challenge in the devlopment phase.  But, normally they are resolved after a few attempts.

 

7)  Test and validation

Now its time to put all that development to the test! Algorithms are tested virtually on a daily basis, twice or more, leading up to 1500 tests covering more than 90% of the code.

Our validation process is in 2 steps, functional, and practical:

Functional validation: This is imperative from both the user and the performance perspectives. We test every function and take note of it all so that we can correct it before the app is released. Here we test the UI, the new functionalities added, and overall performance of the app- to ensure that it performs every time. Functional validation also Includes creating test protocol samples.

Practical Validation: Once validated on the functional side, we test it in real life conditions: Xavier de Le Rue takes it to the limits wherever he goes in the mountains, our video team takes it on video shoots to determine best practices, and the product team is constantly checking that everything looks and feels the way it should.

Once all of this runs smoothly we are ready for publication!

 

8)  Publication

All that planning, developing, and  testing, and here we go!

The Android publication process is fairly simple: simply load it and make it public on the play store. Voila!

For  iOS publication, however, it requires a few more steps. Apple must approve every update and version of any app on the Apple Store. The first publication of an app could take months to approve since they review everything within the app (remember it took us a few weeks to review our own app) and every update after that takes between a few days to a week, depending on the changes to the app and the Apple team’s work load. Once the app is approved it gets pushed to the Apple store!

Now is the time we send you a communication alerting you that the app is up–your app might even update automatically based on your settings, and you’re set for fun!

 

9) Showtime!

Once the app is out, you, our users,  are the ones coming into play to tell us what you like, areas of improvement and how you’d like to see the product evolve. I’d love to hear your feedback about the product and your experience with it for improvements and new functionalities.

 

PS–we did talk a bit about the magic wand, so I’m sure you are wondering…when is it going to be available? We are currently in the development and testing phases for certain components, so a bit more work to do for sure! We don’t have a precise date for its release, but stay tuned for updates! Its coming this year:)

Eva

Comments/Discussions

Eva
Eva's our ever good-spirited, globetrotting and ever-demanding Product Owner. She oversees everything from software, hardware, app, packaging to the smallest details of the website copy. The kingpin if you like, no less.