May 9, 2017

5 Ways to Craft the Ideal App Experience

We’re fresh off our Dallas breakfast event with the Mobile Marketing Association where Bottle Rocket, 7-Eleven, and Urban Airship shared what effective mobile experiences look like and why they matter. We’re still feeling jazzed about the concepts discussed during the event, and had to share five of our favorites.

Click below to watch the entire breakfast conversation or continue reading for our top 5 takeaways from the event.

Every mobile moment is an opportunity

We believe every mobile moment is an opportunity for a brand to connect to users. Between the rapidly changing mobile market and its technology, it can be hard to keep up. But, consumers expect it. Think about your audience – is it customers, employees, partners? Or a combination of these and more? Effective mobile experiences can serve any variety of audiences when developed with their needs in mind.

People want just a few things from their apps

Users want three things: personal, frictionless, contextual mobile experiences. The needs are few, but the apps that win are successful on all fronts. At Bottle Rocket, we build mobile experiences that exceed customer expectations, bringing them relevant and easy-to-use experiences. Companies like Urban Airship help us take it one step further to ensure we appropriately reach customers in the moments that matter with notification-style messages at every step in the customer journey.

Begin with the user

Through ethnographic research and observing mobile metrics, examine the user journey and learn their experience. Where do they encounter friction and what can a mobile experience do to make things easier? Anticipating these needs makes the experience delightful. You know you’ve done something right when the user responds with, “How did they do that?”

Make it easy

Engage users by extending communications beyond the app with push notifications. Don’t just present thoughts, though—provide actionable prompts, then make taking action frictionless. Take users straight to the app or let them handle business right there in the moment.

Say the right thing at the right time

Since most people use an average of three connected devices per day for more than 200 daily mobile moments, forging connections to users can be difficult. Mobile experiences need to be meaningful. Relevant engagements with appropriate frequency (learned through understanding the user and their habits) can put a brand in users’ good graces. Then, once you’ve got their attention, guide them in taking some kind of action.

Bonus trivia!

  • The farthest 84% of millennials place their phone is on their nightstand.
  • On average, people own 6 connected devices, like smartphones, tablets, and smart TVs.
  • Within the first 30 days of downloading an app, 70% of people delete it.

Want to learn more? We’ve got a lot of experience to share. Tell us what you want to know—we love this stuff!

May 8, 2017

Engineering Jedi: Alexa Lingo

It’s an exciting time for voice. Amazon’s Alexa has come into her own these last couple of years. Some analysts estimate as many as 8.2 million devices have been sold since late 2014. I personally find myself talking to Alexa multiple times a day, every day. It’s truly a remarkable feat of technology.

The engineer in me is fascinated by Alexa. And, being at Bottle Rocket where I work on the frontline of all things technology, I recently decided I wanted to write my own Alexa app, uhm I mean skill (which you’ll learn about later). Bottle Rocket promotes a learning culture, so I quickly tapped into other engineers and strategists here who were already tinkering (and in some cases, more than tinkering) with voice and lots of impressive things in the “personal digital assistant” space.

Much to my surprise, I found that even as a veteran engineer, I had some trouble following the conversation. While Alexa hasn’t even officially turned 3 yet, a whole vernacular has popped up around her that can be a little overwhelming.

So, before I rolled up my sleeves and started coding my first Alexa skill, I put together this handy little glossary of Alexa lingo.

Alexa Development Terminology

Wakeword

Except in the case of the Echo Tap, which has a physical button, Echo has multiple microphones that are always listening. Think of the device as being in standby mode. It is not fully activated and comprehending until you call out the wakeword. By default, this wakeword is “Alexa.” There are currently four other wakewords you can set on the device.

Skills

Skills are essentially apps for Alexa. The list of available skills for Alexa is growing every day. If you haven’t done so before, spend a few minutes browsing some of the most popular.

Invocation

The invocation is the word or words used to identify a particular skill. I’ve heard it described as synonymous to an app name, but I think a better analogy is the app icon since you may choose to call your skill “Greatest Alexa Skill” but might settle on an invocation word that’s less of a mouthful, like “G.A.S.”

Intent

This one doesn’t directly relate to the spoken script with Alexa, but rather intent is the “what” in what are you trying to accomplish by speaking to Alexa in the first place.

Utterance

Utterances represent the variances of spoken language and all the nuance that implies. Think of all the different ways someone might ask about the weather. What’s the weather? What’s my weather? What is my weather? What is the weather like? That list can get very long very quickly. Getting utterances right can be tough, but Amazon’s guidelines are helpful.

Slot

Slot is another word for what programmers and mathematicians call variables. If you think back to algebra, x in the equation 50+x=75 would be the variable. In Alexa’s vernacular x is the slot.

Developing for Alexa

Now that you know the terms in play, you can begin to see how they fit together.

Wakeword
Invocation
Utterance
Slot
Intent

Alexa, ask Southwest about my flight info.
<Respond with information about an upcoming flight>

Alexa, ask Coke Freestyle for today’s top mix.
<Respond with information about the most popular Freestyle mix for today’s date>

Alexa, tell NPR to remind me when Way With Words starts.
<Set a reminder for when the program “Way With Words” is scheduled to next air>

Eureka! Now you’re speaking Alexa!

Of course, a lot more goes into building a great voice experience than just understanding the terminology. Publishing an Alexa skill is a blending of engineering, strategy, and quality assurance. Amazon’s submission process requires knowledge of policy guidelines, cloud-based security, and a combination of functional and experiential testing. Lucky for you (and me), my colleagues here at Bottle Rocket have a head start.

I encourage you to schedule a demonstration of Bottle Rocket’s voice expertise. Even if you aren’t quite sure how an Alexa skill fits into your overall digital strategy, seeing some of the exciting work going on here will get the wheels turning

December 28, 2016

Low-Friction Development Environments

At Bottle Rocket Studios, we do our best to provide our developers with a low-friction development environment. We do this to help maximize productivity – for both our customers’ and developers’ benefit.

Elements of low-friction development environments

Developers select the tools best suited for a given task

Many projects will have predefined toolsets such as Xcode for iOS and Android Studios for Android, but that’s just the foundation. Developers doing the work should, whenever possible, select the tools they find work best for the task at hand. The only real exceptions to this are tools that may be a security risk or are undeniably less productive. Projects and workflows will vary, so the tools used in each should be expected to change as well. Flexibility has a low cost and can lead to a sense of ownership and comfort.

Developers are free to research new tools as needed

Since developers select their own tools, they also have the freedom to research new tools as needed. From interactive Slack channels to Google searches, there is no shortage of sites to leverage and each developer will have their favorites. This freedom of access will increase productivity. Developers will do what’s needed to get the information they’re looking for; reducing the barriers to doing so means they have more energy and time to spend on projects.

Open Communication

Open communication is a hallmark of low-friction development environments. A developer should never have to wonder the importance of a given task or where it fits in relationship to the project as a whole. Open communication must be practiced to be effective. An organization can't simply state that they value open communication; it must be demonstrated that communication channels are open and that asking tough questions is acceptable and encouraged. Without asking tough questions, developers don't get to deliver their best work quickly. Without answers to tough questions, the project is unlikely to succeed.

Developer-driven task sequencing

In a low-friction development environment, developers have the freedom to select the tasks that they will work on at any given time. This does not mean that the features and deadlines are subject to the whims of developers – it means that after presenting a set of requirements and a timeline, the person doing the work knows best how to accomplish that task. The developers best know how to sequence sub-tasks. This removes a significant amount of overhead and gives developers a sense of self-determination that leads to improved productivity and satisfaction.

Freedom to focus

One of the most vital things a developer can have in their work environment is the ability to focus fully on their work. This is not achieved through isolation or being freed from meetings – those come in a close second and third place. The most important thing to help a developer focus on the work is for the work to be meaningful and challenging. When a developer has a challenging (but not too difficult) task that matters to the completion of their project, they're more able to ignore distractions. Tasks that seem meaningless lead to distraction. It is important to present developers with directed challenges, or they will find their own. They will gravitate toward what they know and enhance or replace solutions to problems that were already solved adequately. Try to focus them on problems that provide the most value to the project like a UI feature that is orders of magnitude better than the norm instead of a slightly more efficient or succinct way to load images.

Benefits of a low-friction development environment

Higher Productivity

When the developer is free to use familiar tools instead of the tools everyone else uses, productivity will increase. As long as their tool is capable of producing standard outputs and follows the same process as the rest of the team, they will work faster and happier. It is important to keep in mind that any burden of converting the work to a team agreed standard format is incumbent upon the user of the unique tool. If the user of the unique tool can prove that it is objectively better and easy to use, the team may switch and evolve. If the tool is truly better, the whole team can eventually see a boost in productivity that rigid adherence to the old way would have prohibited.

Increased Job Satisfaction

A sense of self-direction drives job satisfaction. Being treated as a peer and not a commodity provides a sense of belonging and worth. Truly innovative developers are like good craftsmen – they’ll never be happy building the same set of cabinets over and over. It may be cheaper to build a spec home, but it will never make the cover of a magazine. Similarly, putting an experienced developer on rails and having them fill in templates will make them insulted, then despondent, then someone else's employee. Similarly, challenging developers with new problems or creative UI will allow them to stretch their skills and produce noteworthy software.

Being low-friction without being no-friction

There are drawbacks to having absolutely zero guidance for developers. For one, each project can be an experimental work of art understood by one or a few people. This is difficult for a maintenance team because they must learn to unravel the new flavor of the month used by the developer. A developer could also take a new direction and find it causes more problems than it provides solutions, putting the project in jeopardy.

Provide developers with challenges that keep them producing quality software without micro-managing them. Encourage them to evaluate the risk/benefit of using a new approach or tool. If the risk is high and the benefit is small or merely cosmetic, have them do a sample project on their own to prove it out. Review the solution and provide feedback. They might have just discovered a valuable new approach and the risk to a project was never taken.

Review projects to give them a health check. It is imperative that architectural review doesn't become a blocking portion of the development process. However, that doesn't mean you should defer the review indefinitely. Developers are generally receptive to meaningful and well-delivered feedback. This excludes seagull management where one flies into the room yells a lot and poops on everything. You should perform a considered, prioritized evaluation of the project with explanations for criticism and direction for solving the problem. Present this to the team lead and let them digest the changes and present it to the rest of the team.

Conclusion

Having a productive, low-friction environment for developers requires keeping an open mind about tools and approaches to software development. Good developers have some creativity and are eager to express it. Give them an ability and a channel in which to express it, and they'll be a long-term asset to the organization. Keep them challenged, but provide direction and monitor their ability to rise to the challenge. Guide them to innovate where needed, and they will produce high quality and innovative applications.

November 21, 2016

Develop for the Future: Reducing Technical Debt

When we say “develop for the future”, we do not mean that you should develop apps that will be useful in the future – we mean to develop apps that are ready for the future. By watching for trends from platform providers, such as Apple and Google, and selectively adopting new development guidelines and features as they are announced, your app will be prepared for future releases. Getting an application ready to ship on a short timeframe or otherwise is great, but if you rush, cut corners, or do not plan for later updates, something as simple as a new OS release could cause major problems. A little extra time spent implementing these changes and ensuring everything is "as it should be" in the present can, and usually will, save a lot of time and money in the future.

To better understand the importance of preparing your app for the future, we’re going to take a look at a few past updates and announcements that resulted in full-blown initiatives – features that seemed almost trivial at the time, but are now practically platform standards.

 

Size Classes on iOS

Size classes originally appeared for iOS 8 in 2014. These classes worked with Auto Layout to provide a UI that would work properly no matter what the screen resolution was. This was a pretty significant departure for iOS, as that platform had previously enjoyed a very small number of screen size variations, which made it simple to design to a fixed size. There was some initial resistance from the community; after all, even though size classes existed, we could still design for the phone sizes. With the introduction of multitasking on the iPad in iOS9, however, the value for size classes became more apparent. Size classes allowed developers to build a UI that would work well even with the unpredictable configurations of a changing screen size. By paying attention to size classes when they first appeared in 2014, developers could be more prepared for changes that appeared in 2015.

 

Google Screen Size Buckets

In July 2011 Android 3.2 introduced screen size buckets. These buckets include constraints like a shortest width demarcation. This was just after the launch of Honeycomb when they realized that tablets were much more varied in size than phones and indeed phones were getting pretty big as well. The existing buckets like "normal" and "large" were too vague and didn't carry a guarantee of a physical size for developers. The shortest width buckets were based on the physical size of the screen measured in density independent pixels which are roughly 1/160". The next year saw the release of the 2012 Nexus 7 which sold like wildfire and popularized the 7" format. Now in 2016 we see multi-window multitasking where two apps are shown at the same time. A 10" screen size might be displaying a phone-sized UI. If you took the hint with the new buckets, you were in good shape for both events.

 

Android Apps on Chrome

At Google I/O 2014, Google quietly announced an effort to get Android apps onto the Chromebook. The first demonstration partner for this was the Evernote app. It wasn't a great experience and it was a little clunky. Fast-forward to 2016 and now publicly available Chromebooks run native Android applications right out of the box. Google has largely combined its tablet efforts with the Chromebook OS in something rumored to be called "Andromeda" a combination of the words Android and Chrome. Whether or not this name sticks, Chromebooks from several vendors are already capable of this type of functionality with 10" screens, capacitive multitouch, accelerometers, GPS and other sensors. These devices should behave like a lot like a full-fledged Android device and add the ability to take multi-window multitasking to a new level. Looking back at 2014, the reveal of Andromeda and first-class Android applications on Chromebooks isn't really a surprise.

 

Deep-linking and Google Assistant

Also announced at Google I/O 2014 were app-indexing and enhanced deep linking support. At the time this seemed to be related primarily to their desire to index the world's information and play a larger role in app discovery. That in itself is a strong reason to work on deep-linking your app and ensuring your website is set up properly for app indexing. Then at Google I/O 2016, they announced the creation of Instant Apps which would go directly from a search to taking action in a slice of the app. Also, Google Assistant can use these types of links to launch apps directly from chat. If your app and website aren't taking advantage of app indexing and deep linking, you are reducing your app visibility and ease of use.

 

Swift 3 and third-party frameworks

When we choose a third-party solution, including open-sourced solutions, we assume responsibility for maintaining those libraries. This has become an issue with the release of Swift 3.0, as some frameworks have been either abandoned or slow to update to the new language syntax. Since a project can't simultaneously use Swift 2.0 and Swift 3.0, you can end up with an unexpected level of technical debt as a result. The best solution to this is threefold: First, use as few of these as possible. Secondly, choose ones that have a significantly sized user community for the best chance that it's updated. Thirdly, if all else fails, truly understand how the framework works, so that you are ready to perform any language updates required. Note that this can occur with any language that gets updated, whether that's Swift, Objective-C, Java, or anything else.

 

Future-proofing is a process, not a feature - and is ultimately something that must be done on a consistent basis. This can only be accomplished by viewing one's apps as living entities – receiving regular updates, not only for features but to ensure they're taking advantage of the latest capabilities of mobile devices and mobile operating systems. By evaluating even the minor advancements of the platforms, one can see future opportunities and get ready to succeed with future environments without scrambling at the last moment.

Contact us today to learn more about future proofing your projects.

May 9, 2016

Lifecycle of an App

There are four key steps designers need to consider when crafting an app experience that delivers genuine relevance and value to their users. Bottle Rocket’s Executive Creative Director Michael Griffith talks us through the user lifecycle of an app.

1. The App Store Experience.

Getting a user to opt in and download your app involves asking them to take a leap of faith, and it’s up to you to make that leap as short and painless as possible. Ensure your app is easily findable in the App Store, with a short and simple description, and screen captures or videos which show exactly how the app works.

2. The First Open.

The user very rarely opens up an app immediately after download, which means you have to win them over again once they finally do. The first experience of an app should combine “beauty, magic, and innovation,” says Griffith. Utility comes later.

3. The First Task.

Completing a simple task on your app should be “elegant, simple and efficient,” says Griffith. He cites the TED Talk app as a prime example, which allows users to find relevant content without having to waste time by entering search terms. Deeper tasks need to be “personal, exacting, and reliable.”

4. The Update.

Installing updates for an app isn’t a priority for many people, as they simply don’t have the spare memory on their phone for an automatic download. You need to reward users for updating the app by doubling down on the beauty, magic and innovation of their first experience.

© 2020 Bottle Rocket. All Rights Reserved.