Yoyo Wallet Powers The New Caffè Nero App

Summary

1. We built the Caffè Nero App on top of the existing Yoyo platform
2. We achieved #1 in the Food & Beverage category on launch day ahead of Starbucks and UberEats
3. We have the highest rated app in its category (mostly 5 star reviews)
4. We modified our architecture and built a fully automated CI/CD system for rapid, regular releases

Launch

On April 10th, 2017 my team and I at Yoyo Wallet launched the Caffè Nero App across the UK and Ireland enabling a digital payment and loyalty experience for millions of Caffè Nero's customers.

The product engineering team at Yoyo Wallet (consisting of Android, iOS and backend engineers along with product mangers and designers) were responsible for designing, building and shipping the Caffè Nero App for the April deadline, whilst still continuing to improve and maintain the Yoyo Wallet App which is live across the UK and Europe at many Universities (e.g. Imperial, Oxford Brookes, York), Corporates (e.g. JP Morgan, Guardian, Accenture) and high street stores (e.g. Planet Organic, independent coffee shops).

Marketing

Nero kicked off a number of marketing campaigns after the release of the app to raise its profile, including posters and collateral in-store (see above) and email campaigns. 

Feedback

On launch day and the days since we've seen a surge in registrations for the app which resulted in the app obtaining the top ranked spot in the Apple App Store for the Free Food & Drink category (out ranking other apps such as Starbucks, Costa, UberEats, Nando's and Just Eat to name a few). Off the back of customers downloading, registering and using with the app to pay and collect stamps, we've received mostly 5 star reviews making us the top reviewed app in the category (As of April 27th we've received a total of 395 iOS and 416 Android reviews with ratings of 5.0 and 4.7 respectively). Along with positive user rankings, we've also maintained a very high quality threshold shown by our crash-free session rates which are at 99.97% and 99.94% for the latest versions of the iOS and Android apps respectively (measured via Fabric's SDK).

Features

We've abstracted away much of the complexity of the app behind a simple UI/UX that customers engage with and rate highly. Behind this simple UI/UX the app has the following features:

• Multi-mode registration (Email, Facebook or Yoyo login)
• Camera based credit card scanning to more easily gather card details (A/B testing proved the uplift in conversion)
• Secure payment and loyalty in a single scan of the app OR loyalty-only so customers can also pay with their own cash/card
• Rule-based loyalty that triggers in real-time based on each items in a customer's basket and notifies them via silent push notifications of their loyalty reward(s)
• An activity feed that aggregates receipts and loyalty reward information 
• Store locator for finding the closest store
• Apple and Android Wallet integration for loyalty-only transactions
• Settings: account management, support and promo codes

Architecture

Given that Yoyo is powering the Caffè Nero app, as an engineering team we were very conscious of leveraging both our existing mobile and backend platform architecture in the right way to minimise code/feature duplication across 2 (and eventually more) mobile frontends. Both sets of mobile apps call the same Yoyo API endpoints running on Amazon Web Services (AWS) and much of the mobile code base, for both iOS and Android, is re-used inside our own internal SDK as well as the core business logic of the app which we call "App Core". Only the UI of the mobile apps (which is visually different) and a small bit of custom business logic are unique to each app and therefore cannot be re-used:

Shipping

At Yoyo we ship new versions of ALL our mobile apps to their respective app stores every week without fail on Tuesdays at 3pm for iOS and Tuesdays and Thursdays at 3pm for Android (we follow a release train process). This requires building, packaging and deploying a total of 6 .ipa and .apk binaries across our internal test, staging and production environments along with our 3 testing channels (alpha, beta and live). To manage this complexity effectively we've automated the entire build, package and deployment process for multiple apps by using our own custom mobile CI/CD pipeline built on Bitrise, Fabric, Testflight and our own scripts. 

Here is an example of what our mobile CI/CD pipeline does each day multiple times:

1. An iOS engineer fixes a bug in the SDK and merges his/her change to master
2. Bitrise immediately kicks off a new CI build cycle for both the Yoyo Wallet and Caffè Nero versions of the iOS app
3. Once complete both iOS .ipa binaries are pushed out via Fabric to all alpha testers
4. The next time all alpha testers open their Yoyo Wallet or Caffè Nero app on their iPhones (most internal Yoyo staff are alpha testers except the sales team) they will be asked to download the latest build
5. Once downloaded, alpha testers will be using the latest and greatest version of the app and are more easily able to identify bugs or usability issues

This new, fully automated, CI/CD pipeline was implemented late in 2016 and has dramatically increased our mobile team's ability to rapidly release new versions of the mobile app to our users. The chart below shows this increase over time as we've improved our ability to ship to production using automation:

It's worth mentioning that we also use a company called Applause for crowdsourced continuous testing of our mobile apps. The service that Applause provides is incredibly helpful and cost-effective in terms of finding many usability issues and bugs across the plethora of Android devices and configurations that are available in the marketplace today. However we do not use their crowdsourced continuous testing service as a quality assurance gatekeeper for pending production app deployments (there is a very specific reason for why we do not use them in this way which I will explain further). 

Whenever there is a human gatekeeper of quality, I find that developers and their teams often rely on that person or set of people as the main quality assurance mechanism instead of themselves (they are less thorough with their code changes and code reviews and often write fewer automated tests). They effectively offload the burden of responsibility for quality assurance to someone else for the change(s) they are making. This is orthogonal to the idea that each developer is the best person to know what could be most affected by their changes and should therefore assure the quality themselves. At Yoyo we wanted to keep quality high by using Applause but did not want the service to become a crutch for developers to rely on. Therefore we only use Applause in parallel with existing deployments to production. Applause testing never stops any deployment, it merely identifies existing issues and bugs that need to be fixed post deployment and does a very good job at this task.

Learnings

• Watch out for trademark checks: One unexpected thing to happen in the 11th hour was when we submitted the Android app to Google Play and it was rejected. We had completed and submitted the iOS app a week earlier because we knew the review process was more stringent and always took longer with Apple. We weren't worrying about our submission to Google Play as it was always seamless due to less checks and balances (or so we thought). This was not what happened in our case, Google flagged the fact that a 3rd party developer (i.e. us as in Yoyo Wallet) were submitting an app with someone else's trademarked branding and so the app was rejected. We had to scramble in the 11th hour over a weekend to get documents signed by Caffè Nero to assure Google that we, as a 3rd party developer, had the right to submit an app that contained Caffè Nero branding. This did delay our Android submission by a few days but luckily we still had enough head room for it to ship on-time.

• Public wifi with logins can cause headaches: A phone's OS will automatically connect to a public wifi that it has previously connected to when it's within range but the user usually still has to accept the terms and/or re-login to gain full internet connectivity. If the latter does not occur then the user usually assumes they have internet connectivity when the app is open due to the wifi symbol displaying on their phone when in fact they do not have internet connectivity. There are a few ways to solve this by either (1) if the public wifi is within your control make sure certain outbound connections (via IP or domain) are given access even without the need to accept the terms or re-login to the public wifi OR (2) the app displays a "no internet connectivity" warning message so users expect limited functionality until they have fully connected to the internet. 

• Improving mobile architecture and deployment infrastructure upfront was worth it: Given that we had the Yoyo Wallet app and were effectively white labelling it (modifying the UI for Caffè Nero as well as adding some new features), we wanted to approach this intelligently to minimise long-term technical debt. We knew that white labelling Yoyo Wallet could get rather messy quite quickly with multiple sets of apps being created and maintained long-term. Yoyo's mobile team spent time upfront to improve the mobile architecture on both iOS and Android to separate out the App SDK and App Core dependency layers which could be re-used across apps while the UI layer could be modified heavily. We also focused on improving the deployment infrastructure using Bitrise CI and compile time configuration flags within the app so that we could automatically build the different UI versions of the app with the reusable App SDK and App Core dependencies. Although this deployment infrastructure took time upfront to build and configure correctly, it reaped large dividends later in the project as the deadline loomed (it continues to reap ongoing benefits every day with each new commit). Mobile engineers now barely need to think about the Yoyo Wallet or Caffè Nero app deployments, we focus on improving the UI or business logic of the app and the deployments continue to happen automatically each day and in exactly the same way since the start of the Caffè Nero app project.

Conclusion

The entire team at Yoyo Wallet have done an incredible job building Caffè Nero's mobile app on time for the April 10th launch. Not only did they meet the deadline but have built an app that is available to millions of Caffè Nero customers. Many of these customers already love the product based on their ratings and are actively asking for more functionality to be added in near the future which is exactly the kind of response a product engineering team hopes for when releasing a major new product into the market.

---

Download the Caffè Nero App today:

• Apple App Store: https://itunes.apple.com/gb/app/caff%C3%A8-nero/id1209864393?mt=8
• Google Play: https://play.google.com/store/apps/details?id=com.yoyowallet.caffenero&hl=en_GB

Examples of Mobile First Development

We all know that developing for mobile is different than developing for the desktop but how exactly is it different? I'm deeply interested in how a mobile product needs to be structured in a fundamentally different way than a desktop product in order to thrive. It cannot simply be a slimmed down, feature minimal version of a the desktop or tablet version. It should not feel as if its missing critical features or useful add-ons simply because they couldn't fit into the mobile format.

Various concepts have emerged for how to approach mobile app development. One revolves around mobile apps being remote controls for real life. Another is about mobile apps being useful for a user while they wait for something (i.e. in a line-up or in an elevator). In order for that to happen a user should be able to launch the app and perform some task within 30 seconds to a minute. MG Siegler of CrunchFund also had this to say about building for mobile:

"Don’t build an app based on your website. Build the app that acts as if websites never existed in the first place. Build the app for the person who has never used a desktop computer. Because they’re coming. Soon."

Some companies have built very compelling business models that fit well with this mobile first, quick and effective/remote control paradigm. Users are responding well by engaging with and being retained by these mobile apps due to their simplicity. The following examples show how mobile apps can reduce inherently complicated tasks down to very simple actions which are fundamentally different from anything we've seen previously on the desktop.

1. Hotel Tonight

Hotel Tonight is a mobile-only app where users can book last-minute hotel deals. Hotel Tonight has simplified booking a hotel room down to only a few essential actions without degrading the experience to the point where it feels limited. Here is the user flow from initial launch through to booking confirmation:

1. During launch the mobile app retrieves the hotels on offer given the user's current location. Although this may take a few extra seconds, it presents the user with the exact information they are interested in right when the app loads (the user is not required to type anything).

2. The user is then presented with the hotel selections in a scrollable list with the 3 most essential details displayed: photo, price & location. The app also provides some other useful data like the type of hotel experience (Solid, Basic, Luxe, Charming, Hip) and a rating by other Hotel Tonight guests. This information makes it very easy to select an appropriate hotel for the night.

3. Once a hotel has been initially selected, some further details can be reviewed such as additional photos, information about the hotel itself and its exact location on a map along with the final price.

4. The final screen allows the user to easily confirm the dates, price and credit card to be used for the transaction.

From start to finish this process only requires 3 simple actions: a single hotel selection, an initial booking of the room and finally a confirmation of the booking details. Hotel Tonight has given travellers the ability to easily choose and book a hotel room from their mobile phones. The whole process from start to finish feels uninhibited by the mobile form factor it actually thrives within it. Its because of this that the mobile app thrives and continues to delight users.

2. Car2go

Car2go is a vehicle sharing service paid for by the minute where vehicles can be picked-up and dropped off in different locations. The primary way to find and reserve a vehicle is via its mobile app. Given the nature of the service offered, it needs to take seconds (not minutes) to book a vehicle via the app. Here is the user flow from initial launch through to vehicle reservation:

1. The mobile app launches fairly quickly, determines the user's current location in order to position the map correctly and starts retrieving vehicle locations. Again this presents the user with the exact information that are looking for without any interaction after launching the app.

2. Vehicles begin populating on the map and the user can then zoom in and out to find the vehicle closet to them or simply select a vehicle.

3. Once a vehicle has been selected, the blue vehicle marker expands to show 3 additional bits of information: license number, distance away and gas available (indicated as a percentage). Although this information may be helpful in some circumstances it can be presented in a different and this third step can potentially be removed completely:

• The license number is unimportant to the vast majority of users unless a user has forgotten something in a vehicle and is trying to find it (but this is a very rare case).
• Knowing the distance to a vehicle isn't as helpful as knowing the approximate time it would take to walk. A vehicle may be 562m away but how long would that take if the user walked there? A separate interaction with the marker (such as a "2-second hold") could display the walking time from the user's current location therefore removing the need for the distance measurement in the expanded marker.
• The gas available is the most helpful but it could be more easily displayed so that it can be compared with all other vehicles. By displaying something visually on each vehicle's non-expanded marker (possible a textual percentage of even a level indication), this again would avoid the need to click on the marker to find out how much gas is available.

4. The final screen allows the user to review the vehicle's gas available, cleanliness, street address before confirming the reservation.

Again from start to finish this process only requires 3 simple actions: a single vehicle selection, reviewing some of the vehicle's specific information and finally a confirmation of the reservation details. As outlined above this 3-step process can be further simplified to just 2 steps by removing the expandable marker step and simple going straight to the reservation confirmation screen. Having said this, even with 3 steps this mobile app by Car2go is very efficient to use - a vehicle can be reserved in under 30 seconds.

3. Uber

Uber seamlessly connects a user needing transportation with a taxi driver. Uber, the company, does not own any vehicles and does not have any drivers on staff, instead they provide ride-logistics to both users and drivers in order to match supply and demand more effectively. Ultimately Uber wants to get users a taxi in the shortest amount of time and give them the best experience while helping drivers anticipate demand and therefore maximize the earnings per shift. Here is the user flow from initial launch through to taxi request:

1. During launch the mobile app determines the user's location in order to display the correct map along with taxis on the following screen. 

2. Taxis begin populating on the map but they also update in real-time as taxis move about through the streets or get requested by other users and are no longer available. This gives the user immediate feedback about each taxi's relative speed and direction along with the approximate supply of taxis in the given area. All a user has to do is position their pickup location, review the approximate wait time and then tap the "SET PICKUP LOCATION" button.

3. The final screen allows the user to review the pickup location, credit card to use and approximate wait time before confirming the request.

From start to finish this process only requires 2 simple actions: choosing a pickup location and confirming the taxi pickup request. Uber has made the process of booking a taxi on their mobile app as simple as possible and it works phenomenally well for users.

RESAAS reblasts App Featured on Appcelerator Titanium Blog

In a previous post I showcased the iOS and Android App that my team and I at RESAAS released in March, 2013 after only 2 months. The App was built using Appcelerator's Titanium cross-platform framework after we migrated from an older PhoneGap implementation. We chose to go with Titanium due to its (almost) write once run everywhere framework.

Once we released the App, the folks over at Appcelerator took notice of it and loved the look & feel of the App, specifically the photo heavy activity feed that showcases real estate professional's listings. They subsequently asked me to respond to a number of questions they had about our App for an upcoming blog post on their developer blog. 

Here is that blog post they created: http://developer.appcelerator.com/blog/2013/06/featured-app-reblasts.html

The official RESAAS blog also has a couple posts about other features related to reblasts App:

• Taking and sharing photos: http://blog.resaas.com/2013/05/iphone-app-update-take-photos-and-share.html
• Commenting on reblasts: http://blog.resaas.com/2013/05/iphone-app-update-commenting-on-reblasts.html

Mobile Development Trends

:: Facebook on Android vs. iPhone Trend

A colleague of mine, Marwan Haddad, sent me an insightful article today about a poster that was recently seen at Facebook:

Many engineering teams are currently engaged in mobile development and because of this, mobile user trends are very important to keep track of so that each of us ends up building the right mobile applications today and hopefully as far into "tomorrow" as possible. Trends are shifting quickly as new users enter the smartphone market, decide to switch devices or simply change their overall mobile behaviour.

Facebook's poster (or really the IDC) is projecting quite far into the future as the date when this poster was mostly likely seen was around November 2012 (which puts us somewhere in the middle of the graph). The projection spans approximately 3 years from today till somewhere in 2016. In the technology business that's a very very long time to project anything as few people really know what will happen in 1 year from now let alone 3 (the iPhone 3GS was released just over 3 years ago and now look where we are with Android phones dominating). Maybe Windows Phone, the forthcoming Firefox OS or even a yet unnamed player will be lucky enough to steal some market from Google or Apple but really only time will tell. All I know right now is that the competition among these tech giants is fierce and as a result its producing an upward spiral of innovation within the smartphone market which all of us will benefit from for years to come.

The really interesting nugget of information within that Facebook poster projection is the dominating trend that Android currently has over iPhone and looks to have and increase in the months/years to come. If you or your company is still solely focused on iOS development at this point it may be worth reconsidering where the bulk of your customers are today let alone tomorrow. There was much talk way back when about Open vs. Closed Platforms and many predicted that even with Apple's initial dominance Android's "open system" would eventually prevail and it looks like that prediction is happening in full force (for the foreseeable future at least).

:: Kleiner Perkins' Mary Meeker on Mobile Trends

For an even deeper analysis of various Internet and mobile trends, Mary Meeker's year end trend report is an absolute gold mine of information. I've included a screenshot of slide #16 below where she notes that Android phone adoption was nearly 6x that of the iPhone... WOW.

:: TechCrunch's MG Siegler on Building for Mobile 

TechCrunch's MG Siegler wrote a post on Dec 11, 2012 titled Mobile Burst where he argues that "the mobile device is a different beast than a computer". He believes that companies/developers should focus a large amount of their resources on building the right type of user experience that is not only optimize for, but created exclusively for mobile use. In that post he links to his own personal blog post where he makes some very pointent statements:

• "Don’t build an app based on your website. Build the app that acts as if websites never existed in the first place. Build the app for the person who has never used a desktop computer. Because they’re coming. Soon."

• "What matters is that in the next five years every person on this planet is going to be using a mobile device. And these devices are going to be used far more than any traditional computer ever has been and ever will be."

So whether you're building mobile applications with HTML5 or going native, make sure to build the right experience for that specific mobile form factor instead of replicating or mimicking what you've previously built for the desktop.

:: Updates

Following on from MG Siegler's article above, here is an interview with Vibhu Norby on TechCrunch TV who disagrees that Mobile is unanimously the future of all development.

Megan Quinn of Kleiner Perkins Caufield & Byers (who formally worked at Google and Square) was interviewed on TechCrunch TV and had some things to say about the emerging mobile landscape:

• "mobile is not an evolution this is a revolution."
• "every human activity is being re-imagined through the prism of a mobile device"

She went on to say that the 3 areas of mobile development that are seeing huge potential are: Education, Consumer Health and the Internet of Things.

Another Mobile Internet assessment from Business Insider called "The Future of Mobile".