Fragment and Distribute - CityMapper’s (Almost) Everywhere
The app vs web debate is a well trodden path, and the story largely remains the same; apps are good for engagement and native hardware features, web is best for reach and accessibility. The gap, however, is narrowing as web APIs are completed, but at the same time hardware is getting better (ARKit, CoreML, taptic engine). This is going to continue to be the case for a while. But the range of new channels to reach users is increasing.
Android Instant Apps are now available on over 500 million devices. Concurrently, usage statistics are starting to come back, and are proving impressive. According to Business Insider, Vimeo has seen a 130% increase in session length from users on mobile web, and Walmart owned Jet has seen a conversion rate increase of 27%.
As Google stakes its claim to the mobile web, Messenger Platform is becoming established. There’s now over 100k bots, exchanging over 2 billion messages a month with users. Apple’s fighting back with an updated iMessage app store alongside the release of iOS11, improving discoverability of the programs. All the while, the digital assistants continue to see their feature sets, integrations and usage grow.
This is not a post about whether or not you should build an app or a website; it is a story about how you should look at building for everything, taking advantage of the nuances of different platforms.
Let’s look at how a single app, CityMapper in this case, puts a ‘fragment and distribute’ strategy into practice.
The app is the purest version of CityMapper, the platform which all users are being driven to eventually.
It acts as a wrapper, from which Citymapper features can be surfaced across a user’s device. Take the iOS Get Me Home compass that lives in widgets. It’s an awesome use of native device features to provide a stripped down experience that suits its environment - in this case the quick glance of the widgets panel.
It takes full advantage of rich push notifications, widgets, and in it’s latest iterations, even some basic ARKit features. This is fertile territory for them. No doubt they will be exploring it further, see this CoreLocation + ARKit demo.
Apple Watch App
Contextually relevant, glanceable information, without the need to input anything.
Apple watch is a natural place for transit information, and unsurprisingly, CityMapper was one of the first Watch apps to launch. It focuses on disruptions and departures in your immediate vicinity, and is acknowledged to be one of the best Watch apps available.
The iMessage app store hasn’t been gaining as much traction as Apple will have hoped, hence the redesign in iOS11 to more clearly surface the mini-apps. True to CityMapper form however, it already has a presence on there.
Even more stripped back than Apple Watch, it again considers the context of the platform, in this case that it’s a conversation, and includes features accordingly. For now it’s just the ability to share saved and recently searched for locations. However, it’s likely we’ll see this feature set grow if the platform gains traction. Live route tracking and notifications for other participants in a conversation if transport is delayed may be worthwhile additions.
The website has clearly been designed mobile first, with many of the modules exactly the same as you would find them in the app. It is not an afterthought, as app-first companies have a tendency to do. It contains the core functionality of the app, allowing users to login and view preferences.
Searching for ‘Directions to Kings Cross from Victoria’, doesn’t list CityMapper on any of the first 3 pages, suggesting it isn’t being used as an acquisition tool. This is maybe an area it could focus on, particularly Android users, who it could serve the actual app to using Instant Apps.
CityMapper’s lack of support for any of the digital assistants, such as Alexa, Siri, and Google Assistant, is surprising. There’s a clear use case both for regular requests (‘When’s my next bus?’), made possible by the setting of home and work locations, and more occasional route requests (‘How do I get from Euston to Victoria?’). Given the growing importance of conversational interfaces, voice in particular, this will likely be a high priority in its backlog.
Another noticeable absence is from any of the messaging platforms that offer bot capabilities, including Line, Skype and biggest of all, Messenger. This would be an excellent route into providing the CityMapper service to users who don’t have the app, then encouraging them to upgrade.
The success of Skyscanner has already shown that transit is an excellent use case for bots, and the same conversation structure could be easily applied to their user flow. The API for it already exists, so it’s possible a 3rd party could beat them to it, using their own data.
The foundation for any fragment and distribute strategy is an API. It’s a big part of CityMapper’s ubiquity, enabling the ‘get there with CityMapper’ buttons you see sprinkled across the open web.
In summary, the core of CityMapper’s success, is the quality of its service. However, a large part of that quality is that it is always there when you need it, being useful and reminding users why they value it so much.
Companies should learn from CityMapper. Think how your offering can be stripped back, packaged up, and surfaced somewhere that it can add value? Adding value means being there when you’re needed, ‘there’ now doesn’t just mean native app or web, it means everywhere.