ShananAGAINS

One of our team members lived abroad during the late 90s, right around the same time home internet access was becoming popular. In the world of dial-up and “America Online,” there wasn’t a lot of information for expats to understand or challenge the idea that it was possible to utilize “America Online” without dialing an American number. Aside from the timezone difference, the sheer expense of getting online while abroad meant that time online had to be used wisely. Connecting with family members in time zones 6-8 hours behind meant timing was also a factor in engaging with one another. (The cost aspect of this problem was solved pretty quickly through TCP/IP connections after dialing to a local internet access provider, but the timing challenge still remained.) The solution became an interesting behavioural change. If the grandkids abroad or grandparents on-shore wanted to chat with one another, they would call one another’s homes, let the phone ring once, and hang up. The signal became a means to communicate and take action, and subsequently since phone lines were occupied with the dial-up connection of accessing the internet, if a caller tried to signal and the line was busy, there was a good chance the intended recipient was already online and engagement between family members could be pursued.

This solution went on to be the means of signaling between family members for over 5 years. Effectively we had invented our own bat-signal: throwing up a means to say “your attention or self is needed” and if the signal was seen (by Batman) or heard (by family members) they could then choose to take action. There wasn’t ever a real feedback mechanism for Batman to acknowledge he was going to take action, just the one way communication of “you are needed” was thrown up in the sky. Likewise, if the grandparents called once and hung up, regardless of what the grandkids were doing, they may not have been available. There was never really a means to provide feedback other than to say “I am doing this activity and I want you to join me.”

This same problem presented itself decades later, amongst friends and co-workers in Chicago. At the time, many of what would later become Double Bear Rolled team members lived in the Logan Square neighbourhood of Chicago. Individually and on an ad hoc basis as a group, there was one bar we all frequented a lot, Smallbar. We used this bar as our staple for starting out our weekend, relaxing on the patio, or just catching up over adult beverages. As friends, we tried using group-text conversations to coordinate between one another. This presented a problem for individuals who were not able or interested in joining friends who an evening at the bar as they had no means of opting-out of a group text. So a Facebook Messenger group was created. Since Facebook provided the tools for users to mute conversations, participate or leave conversations, and had no restriction or real direct cost to be utilized, it provided a means for group members to say “I am doing this activity and I want you to join me.” (Though not in so many words.)

As more and more of this group of friends started removing their presence on Facebook, the group chat was no longer becoming effective. As Facebook’s product strategy evolved to require users to download and maintain a second application exclusively for messaging, usage of this group chat nosedived off a cliff. Without going back to the group texting model, we needed a way to signal one another that would also enable members to opt in and out of receiving a beckoning cry to a bar.

There were a few core concepts to be addressed in this product. The underlying ulterior motive was to understand more about push notifications and secondarily to understand more about utilizing a piece of software – primarily focused on game development – to build non-game-focused applications. Arguably there’s a case that can be made to say this application would enforce real world game mechanics, but the folks at Unity didn’t build their engine to depend on a gaming experience that happens outside the scope of the device.

In early iterations, we looked at Google Cloud Messaging – powered by Firebase – as the service provider that would deliver payloads to and from devices. With the core concept of the application to send up a flare and tell subscribers “I’m doing this thing, join me!” we don’t really set ourselves apart from the early days of Facebook — where a post or flare doesn’t guarantee participation, much less engagement around said post. We were betting on the learned behaviours from the Facebook Messenger Chat group, described above, to expedite any learning curves around the use of this application.

There was some time spent trying to find existing implementations of Google’s Material Design within Unity applications to no avail. Pursuing sliders, buttons, and animations then became an uphill or manual battle, so we elected to stick with building a series of cards. User is therefore presented with a handful of cards, each of which has a bell that can be tapped and the user is then subscribed or unsubscribed to notifications from the application, specific to that card. Firebase has a concept they refer to as “topics.” Think of them like different areas or threads of conversation or even channels where information is disseminated. Since our app concept was focused on throwing up that signal around “I’m going to the bar!” or “I want to see a movie!” the topics-concept was very useful of facilitating the subscription of users to a particular activity.

Since the UI for a non-game within Unity was challenging, we didn’t want to cheap out and go a route where confirmation of an action (like a subscribe or even a broadcast) would show a line of text or a toast saying “Ye’ dun sent sumthin’” when a card was tapped. This is where Unity’s particle system came into play. For those who remember the Macromedia days, this particle system effectively takes everything we painfully learned to do in ActionScript (1.0) and drops it into a UI where a few clicks and an upload of an image and you’re able to randomize, highlight, and fire across the screen thousands of rubber duckies, all coloured orange. We started with little balls of anti-aliased light, and eventually moved on to a sparks or fireworks display (see the video below).

At about the middle of the project, we have cards that can be slid left and right, bells to enable the user to subscribe or unsubscribe to notifications of an activity, and a particle system that provides confirmation to the user when they’ve sent out a signal for a particular activity. What’s missing?

Oh right! Maybe we don’t want the universe downloading the application and spamming “I want to go to the bar” 800 times a minute. Also, if a user gets a push notification from another user that says “I want to go to the bar” there’s no way to tell who the “I” is in such a statement. So we needed to build a level of authentication, name-capture, and in a way that doesn’t raise any eyebrows around privacy concerns. Utilizing the same cards pattern, we provided some UI text inputs to capture a name, a secret key, and an invisible card to handle any error handling.

The secret keys were interesting: since the target audience for this app was (a) locally based and (b) a very specific group of individuals, we could pre-generate a bunch of key value pairs of names/secrets and then hand them out to our friends. Easy peasy. And it was, in fact, very straightforward to build this information and share it among our intended user base. The key value pairs actually are passed to a custom server side element that passes back the equivalent of an authentication token. The underlying goal being even if someone did find out what URLs our app was posting notification payloads to, that clever little engineer would still need an authentication token – separate from the name, separate from the secret – in order to actually be effective. This was supposed to be an application that deliberately had less than two dozen users, with a very high engagement rate among the intended user base. (Such statistics have been otherwise unattainable in each of our careers, and would be a nice feather in the hat to say “90% of the users are engaged, and that number doesn’t include my mother – who also happened to accidentally download the app 32 times.”

With UI patterns established, authentication system in place, particle system providing visual feedback to users they’ve broadcasted their interest in an activity, everything’s ready to go, time to test and submit!

For those readers that have launched mobile applications before, and speaking from over a decade in the mobile industry, that goosebump-raising feeling when an app is tested (in production) for the first time and nothing explodes never seems to fade. Well, the feeling fades, they’re not perma-goosebumps, but that feeling occurs over and over.

The final product did exactly what was intended with a little extra visual flare. Total monumental success! The application, built in Unity and compiled for both Android and iOS platforms, has only made it onto Google Play. Unfortunately, due to the NDA in place between Double Bear Rolled and Apple, we’re unable to share the trials and tribulations getting this application approved.

We can say, however, that keeping an application concept simple is a sure path to successful product launches. One thing to keep in mind is to provide enough features and functionality so that your simple concept still takes advantage of a few features of the operating systems’ ecosystem and features. You wouldn’t build an AR game and not utilize the camera.

Actually, that inspires another idea. Maybe some AR work is in our future.

ShananAGAINS was the first of the 2019 App Per Month Challenge at Double Bear Rolled.