How Sappu helped SapientNitro to break boundaries at beyond tellerrand

tl;dr#

This is the tale of the truly collaborative effort behind "Sappu's Lost Memories", a project where every team member added a twist to the plot and helped to expand a simple idea into the complex storyscape we presented at btconf Düsseldorf 2015.

Brief#

All stories, however boundary-breaking, must begin somewhere. Sappu’s story started because the hiring team once again wanted Sapient to be present at the beyond tellerrand conference in Düsseldorf, an event with a focus on creative web design and development that has earned a high reputation in Europe for inspiring content that often broadens the audience’s horizon in unexpected ways. Sapient has been a long-time sponsor and already used the event as a stage for employer branding in past years. Traditionally, the hiring team would prepare a quiz (with support from Experience Technology) that tested participants’ frontend savvy. While the best answers were rewarded with prices, it was also a fun way to collect contact details for the company's Talent Relationship Pool. This year, however, we agreed during the kick-off meeting that we could and should raise the bar to better represent Sapient’s unique strengths.

Conception#

We quickly came up with the two ideas that would define the whole project:

• Showcase our skills in and with innovative iBeacon technology
• Build native apps to enable the tech, but also to put Sapient on participants’ home screens

It didn’t take us long to flesh them out into the concept of a beacon-based scavenger hunt around the conference venue: Participants would basically download our app, search for beacons and answer quiz questions at every beacon they found.

Collaborative evolution#

With roughly four weeks to go until the conference, we started to assemble a team for the project. While our app developers began to set up the apps and beacon integration, a few others sat down to think about how the scavenger hunt might work and look on mobile screens. We explored a few directions for the interface and got excited about silly ideas like sonar animations and submarine sounds. In the end, we didn’t really settle for any of them, but the most notable result of this initial brainstorming session was the idea to reward participants with the chance to enter a raffle. Entry to the raffle would be limited by a combination lock that could only be unlocked with the right code. To generate the code, every quiz answer would return a one-digit number to the participant so they could finish the game with a number code of four to six digits, depending on the amount of beacons we wanted to hide.

We pitched our idea to the rest of the team and talked about our vision of locking the lottery wheel with a cable lock in order to further gamify the raffle participation. Feedback was good and we discussed the impact a bit until suddenly someone suggested changing the cable lock to an Arduino or Raspberry Pi robot with a key pad. Everybody loved how this would add another twist to the story and we agreed to make it happen if we could.

At this point we took the rough concept to our UX and visual design people who focused on adding a few bells and whistles to our very basic ideas for the user experience. We agreed that the game should be open to more than only frontend developers and that the quiz questions should be answerable by a broader spectrum of the audience. Our creatives were quick to create a flow chart for the app experience and wireframes for the different screens we would have to implement. They also came up with a little robot icon in the process:

It was gratifying to see our ideas take shape and get a face. We were certain that the right backstory would help us to transform the still rather dry and technical beacon hunt into a fun and memorable experience. We played around with digital production domains like UX, Design, Development and Management and tried to connect them to gaming metaphors where players might enter different virtual worlds (“World of UX”, “Planet Management”) based on both their and our beacons’ physical location in the conference venue. While that would probably also have worked out, we kept coming back to the quirky little robot icon and eventually decided to make the robot a person and put him in the middle of our story. Sappu was born and we had finally found our story’s protagonist. The individual pieces of our plot started falling into place almost automatically: Sappu was promoted to the whimsical position of Chief Digital Delivery Assistant and we imagined him to be equipped with memory nodes for the different skills he would need. Suddenly we had a reason for our beacons – they were distress beacons in case Sappu lost his memory nodes. We decided we wanted Sappu to talk directly to our participants because he needed them for a crowdsourced memory node rescue mission. He could then reward them for their help by handing out a secret code that would enable them to join the otherwise inaccessible raffle.

While some of us were trying to put this to work by creating the interface copy and intro text, our UX team came up with yet another layer that we could apply to the story. Couldn’t we take up the earlier idea to build an Arduino robot and build him out as an actual robot look-alike who would greet the participants in the physical space at our booth and validate their secret code? Of course we could. We quickly debated whether this should be Sappu himself but settled for creating a colleague of his instead – Cistro.

Implementation#

While Sappu’s story was growing in complexity and vitality, our developers got busy with actually implementing the game. Due to responsibilities in other teams and projects it was hard for anyone to finish the app alone, so in the end everybody pitched in where and as much as they could. Both the iOS and the Android code ended up changing steward no less than three times.

We decided early on that we wanted the native apps to handle the beacon logic (a technical necessity) but that we wanted to implement the actual game’s screens as WebViews in HTML, CSS and JavaScript instead of doing everything natively. We hit a few downsides of this decision later on (browser history management being one of them) but we also unknowingly hit a jackpot because the WebViews enabled us to adjust our beacon sensitivity on location in Düsseldorf (more about this later).

The frontend devs took up the job of writing the JavaScript logic that would accept and evaluate the beacon data from the native apps, translate it into a game state and display the correct screens while participants progressed through the scavenger hunt.

During a short review of how it felt to use the app we decided to add “more Sappu”. Our designer was subsequently asked to create a set off different Sappu SVG icons (in different emotional states) and accompanying storyboards for little animation sequences. We implemented them in JavaScript so we could trigger and pause them from outside as needed (we tried velocity.js but eventually chose GSAP to power the animations).

We were soon able to put the WebViews on a Sapient server, reference them in the native apps and stage the first test runs on devices from our device library. When people started walking around the office to look for hidden beacons with Sappu on their screens, we felt we had hit another important milestone.

It was time to switch gears and move on to the physical space and Cistro. We went down to Team Black’s innovation lab, reserved a work station and had soon ordered the missing materials (a small display, a keypad, a wooden box that would serve as lottery wheel/Cistro’s torso). Our Team Robot soon had programmed an Arduino to accept and evaluate a four digit code and start up a servo motor if the code checked out. They then conceived that Cistro should rotate his head and reveal the lottery deposit slot for participants with the right code. It took some duct tape and tiny ball bearings until the head would move smoothly, but they got there in the end. After Cistro was dressed in red foil with the Sapient logo on his breast, Team Robot declared him ready for the show.

Meanwhile, our test runs had led us to discover a disconcerting truth: the beacons were working fine, but every device reacted with different sensitivity to the beacon signals. We wanted the apps to “find” a beacon once a participant entered a 10-15m radius around the hidden beacon. The apps reported the beacons’ signal strength as a value to our JavaScript and the JavaScript decided whether the necessary threshold was reached. The challenge: iPhones have a different sensitivity compared to Android phones. Not only that, but different Android phones also vary greatly in what signal strength they actually receive from the beacons. We started to think about a device-specific adjustment table but had to abandon the idea due to time constraints. Note: If you require homogenous values across many devices for accurate indoor navigation, there is probably no way around it. In the end we elevated the signal strength for Android devices to bring them to the level of iPhone sensitivity and accepted the issue that some Androids would make the game really easy (Samsung S4 Mini) whereas some Android owners would have to play on “Hard as Hell” difficulty (apologies to all 1+ One owners). In any case, having the final threshold defined in our ftp-hosted JavaScript proved to be a godsend because we could hide the beacons on site in Düsseldorf, test the difficulty and adjust our median required sensitivity on the fly – which was good, because due to building safety restrictions some beacons ended up quite a ways from the main walkways. If the value had been part of our native app logic, we would never have been able to make the necessary adjustments and update the apps in the app stores in time (we were only able to hide the beacons one day before the conference).

Up to this point we had had fantastic momentum and a lot of fun, so when Apple rejected our iOS app (“Missing meta data: please provide a video showing app functionality”) we had a little shock moment. We rallied and resubmitted, but were rejected again (“Video needs to be exactly 750 x 1334 pixels in size”) and again (“Video must be recorded at 30fps, yours is 60fps”) and, finally, again:

Your app includes a contest but it does not:

• Include official rules for the sweepstake, which is required
• Indicate that Apple is not a sponsor or involved in the activity in any manner

In hindsight, it seems trivial to clearly research all applicable requirements for a successful submittal, but we didn’t – and we suffered for it. Even a last minute effort by the combined force of the legal team (who helped us to write up a revised and approved T&C text) and another submittal for expedited review would not be able to save us: we were not able to launch the iOS app in time for the conference. Ironically, we created a paper-based fallback quiz for iPhone owners and went to Düsseldorf with only the Android app.

Launch#

Despite this rather significant drawback, we received a lot of positive feedback from visitors to our booth. Instead of making fun of us for not having an iOS app, our plight made for an excellent conversation starter on AppStore reviews, the battle of web vs. native and many other topics. We were very happy to see that people were genuinely interested in our capabilities from mobile development to beacon technology and that we could make them curious about Sapient as a company (we had the only booth with a robot!).

At the end of the conference we presented three happy winners with their raffle prices, and the hiring team with a lot of interesting contacts (11x the amount we generated in 2014) for their talent pool.

Lessons learned#

Sappu’s success despite the iOS failure is a great return, but there are a few other learnings that I would like to emphasize. Here is a list of my personal take-aways for future projects:

Get the legal department involved at the start, not the end.

• Plan extra time for Apple’s AppStore reviews, then double it. Then double it again.
• Stay in a loosely explorative mind throughout the whole project, you never know when the next idea will take shape.
• As clichéd as it sounds: a truly collaborative effort results in a product that is more than just the sum of its parts.
• If you hit the right story (or organizing idea), things may start to fall into place almost magically.
• iBeacons are a fantastic technology at heart, but your results will vary across the diverse device landscape. A lot.
• Once your projects cross over into physical spaces, never go anywhere without duct tape.
• It is easier to motivate people by silently bringing them coffee instead of telling them to work harder.

Thanks#

My heartfelt thanks go out to everybody who made this project possible and that includes our staffing partners and many other teams who allowed the following people to donate time and bring Sappu to life.

In accidental order:

• Michaela Schwarz got the ball rolling and defended our analogue flank (flyers, contact forms)
• Holger Hellinger provided oversight and the original beacon idea
• Florian Feiler came up with the Arduino idea and provided feedback throughout
• Patrick Sbrzesny came up with the idea to put a combination lock on the box
• Sara Ziskovic got involved with UX, design and went manual in Team Robot
• Felix Hofschulte carried his share of the UX work and created the robot icons
• Philipp Hammerschmidt was the mechanic in Team Robot and responsible for the Arduino
• Annick Querfeld wrangled HTML, CSS and JavaScript and got it all animated
• Dominik Pich set up the iOS app and beacon logic
• Stefan Jager took up the iOS torch and finished the app
• Jens Kreuels had the ungrateful task of dealing with Apple’s AppStore reviews
• Adalbert Schanowski got the Android App started
• Raanan Nevet came, saw, rolled up his sleeves and finished for Team Android
• Markus Ruhl jumped in very last-minute and provided legal support for our terms & conditions
• …and, finally, I tried to manage things without getting in the way