Maps have changed.
Cartography used to be fairly simple and largely a novelty:
Unimaginable to the users of that Genoese world map from 1457, today’s maps are used daily by hundreds of millions of ordinary people around the globe to accomplish what’s now regarded as pedestrian tasks, like 3D flyovers:
Indeed, in the post-PC era maps have ceased to be cartographic snapshots of the Earth’s terrain and become spatial portals to a vast array of virtual services:
- Wayfinding — In the not-too-distant future, the principal feature of maps may no longer be wayfinding. Yes, we still want to go from A to B and know where B is and what’s around it. Today, however, we also want to know not just what, but who among our social network is around B, even before we get there. And we want to know not just how to get to B, but by what modalities of transportation, when, how fast, etc.
- Discovery — Knowing “what’s where” is clearly no longer enough. We want to see 2D, 3D, panoramic and synthetically composited photographs taken yesterday (and 50 years ago to compare) sprinkled around the map. We want to see strangers’ virtual scribblings and audio recordings left at particular coordinates. We want to know where our favorite brand of coffee or most scenic bike path may be located. We want to read all the news and tweets around a dropped pin. We want locals facts accessed on a map even before we asked for them.
- Commerce — Today we want our maps to not only show us places, but also let us shop directly. We want to tap a restaurant on a map, get its ratings and book a reservation right then and there. We want geo-fencing to alert us automatically as the GPS tracker on our map gets near a commercial point of interest, show us a discount coupon even before we walk in and get ready for a quick transaction. We want a virtual check-in on a map converted into real-life currency discount at a retailer.
- Integration — We’re no longer satisfied with “cartography as content”. Our maps are now intention harvesting funnels. When we ask Maps via Siri a very simple question like “How is the traffic?” we’d love for her to know 1) we have a trip planned to see 2) our mother in 3) two hours, and we usually take 4) a particular route and we’re really asking about the traffic conditions 5) at our mother’s, so that we can get 6) alternate routes if it’s unusually busy. Maps without deep semantic correlation (public: directions, routing, traffic, and private: calendar, contacts, navigation history, etc.) are not part of the future we want.
- Entertainment — This is no longer the 14th century or the 20th, so we want to experience places without being there. We want our maps to talk to us. We want to virtually fly over not just our neighborhood, but places we may never visit. We want to tour inside malls, stores and offices without moving off our couch. We want to submerge and commune with sea turtles — all within a “map” on a tiny computer we hold in our hand.
Tinker, Tailor, Soldier, Not A Mapmaker
We could go on listing just how profoundly our expectations of what a map is have changed and will continue to expand. Apple understands this more than most companies, but Apple hasn’t been a mapmaker and knows it. Five years ago, Steve Jobs himself favored partnering with companies like Google, for search and mapping backend services:
Jobs wasn’t likely thrilled to have to rely on Google or any other company for these services, but others had a significant head-start in digital maps, and Apple had its hands full reinventing the phone at the time. The intervening five years brought Apple unprecedented success with the iPhone but also a well known systems design problem: it’s very hard to change user habits and expectations once set in. Due to contractual circumstances now being breathlessly analyzed in the media, Apple finds itself having to part with an app powered by a one-time partner, now its chief rival. Regardless, users are rarely comfortable with the loss of what’s familiar, no matter how rationally justifiable the reasons might be. Enter, Mapgate.
Is old new again?
In his open letter on Maps, Tim Cook positioned Apple’s new mapping effort as “Maps 2.0”:
We launched Maps initially with the first version of iOS. As time progressed, we wanted to provide our customers with even better Maps including features such as turn-by-turn directions, voice integration, Flyover and vector-based maps. In order to do this, we had to create a new version of Maps from the ground up.
In other words, Apple seems to be not so much reinventing Maps, as evolving it into parity with its now more feature-rich cousin on Android, and, this time, without Google’s help — a tall task, given Google’s eight-year head start. In this seemingly catch-up game, rapidly increasing accuracy and coverage appear to be Apple’s first order of business.
Mapbusters, who you gonna call?
A company in Apple’s current predicament could have followed a number of curative paths. It could have hired the equivalent of more than 7,000 mapping related personnel Google is said to employ to gather, analyze and correct data. However, for other than its retail stores, Apple has no history of hiring so many personnel (8% of its entire head count) for such a narrow operation.
Unlike Google (Big Table), Facebook (Cassandra), Yahoo (Hadoop), Amazon (Dynamo) and others that have accumulated big data storage, processing and operational expertise, Apple’s not been a magnet for data scientists or web-scale infrastructure, automation, real-time analytics and algorithm design professionals. Facebook, for example, can bring online tens of thousands of servers in less than a month in an automated fashion, Apple continues to lag, underperform and underwhelm in this area.
Instead, Apple could acquire a mapping company. Unfortunately, there aren’t a lot of those around. Neither does Apple have a history of buying companies just to get process oriented employees. It’s telling that Apple hasn’t bought any of the companies it currently gets mapping data from, like Tom Tom or Waze. Further, Apple uses multiple map data sources abroad such as AutoNavi in China.
Apple could augment its accuracy efforts by crowdsourcing corrections through OpenStreetMaps, which it’s already been using elsewhere. But OSM may not scale as fast as Apple would like and, more importantly, may pose licensing issues in the future. Another avenue for Apple is to get much more aggressive and encourage a hundred million iOS 6 Maps users to actively send map corrections and suggestions to earn accumulating incentives such as App Store or iTunes credits, iOS device prizes, free trips and so on.
But these acquisition or incentive based approaches are ultimately process oriented remedies not in Apple’s DNA. You can expect, say, Microsoft wanting to code for, test and manage thousands of models, peripherals, drivers and legacy bug exceptions for Windows as they have done for a couple of decades…Apple not so much.
Of course having good map data by itself is not good enough. Apple has to decide if it really wants to clone feature by feature what has become very familiar to its own Maps 1.0 users. That is, would Apple really want to spend all its time, resources and focus to clone Google Maps (on Android) because some of its most vocal users are asking back what was degraded in iOS 6 Maps?
Playing by its rivals’ rules hasn’t been Apple’s modus operandi. Apple often enters a semi-mature industry underserved by system design and rearranges constraints and possibilities to create unique products. More recently, for example, everyone has been busy adding NFC chips to smartphones to rejigger the entire payment industry, full of entrenched players. Apple remained agnostic on payment modalities and ignored NFC, but reimagined everything else around payments: rewards, promotions, cards, tickets, coupons, notifications…all wrapped in a time-and-location based framework, thereby opening up new avenues of growth, integration and deeper ties to users in the form of its new app Passbook. In the same vein, can Apple reimagine and redefine what mobile “mapping” ought to be?
Fortuitously, Apple has another systems design problem in its hands, not unlike Maps. If Maps has become the gateway to mobility, iTunes has been Apple’s portal to content. iTunes started as a single-screen song organizer. On the desktop, it’s still a single-screen app, but has grown to cover the storage, backup, authentication, transaction, discovery, promotion, browsing, preview, playback, streaming, conversion and sharing of every imaginable modern media format. It’s the focal point of a quarter trillion dollar media empire. In the process, the cognitive load of using iTunes has become considerable, not to mention the app’s performance, reliability and myriad other problems. Many users complain about it. Apple’s response has been to separate various functions into individual apps: Podcasts, iTunes U, Music, Videos, Trailers, iBooks, App Store, etc.
Developing and delivering map services as separate apps would prevent the immaturity of one or more components from bringing down the overall perception of the entire Maps platform. Can the Maps app be sliced into 8-10 separate apps: satellite, roads/traffic, mass transit, turn-by-turn direction, 3D/flyover, search, discovery, points of interest and so on? While this may make logical sense, not all users will be happy exchanging an integrated app where especially the novice user can find everything in one place for several single-purpose apps. It can get complicated. For example, millions of people commute daily to New York City from many smaller cities and at least four states, some driving through three states twice a day. Would they want to manage various aspects of that process in multiple apps?
Clearly, Apple has already started to think about and experiment with unorthodox displays of map data, as exemplified by its “Schematic Maps” patent application. So, for instance, instead of slicing Maps into separate apps horizontally, could it be another option to display metadata vertically as layers, like the tissue-paper overlays of yesteryear?
Conceptually, this can be an effective way to deal with complexity, data density and integration issues within one app. PlaceBase, one of the mapping companies Apple has acquired in the last couple of years, was known exactly for such layering of data through its PushPin API.
Apple could even parallelize and greatly accelerate its Maps development by starting a mini “Map Store” and actively enlisting third parties to develop layers on top of Apple’s “base-map”. Users could make nominally priced in-app purchases (think $0.99) to add custom layers to replace and/or augment Apple’s own layers. It would be very attractive for third parties, as their layers, floating on Apple default base-map, could quickly capture a massive user base in the millions (think getting 70% of $0.99 from 10-20 million users). Wouldn’t you pay $0.99 for a Google Search layer that pre-processes a local point of interest overlay?
Layered maps don’t, of course, come without issues. It would be sensible to make layers adjustably translucent so multiple layers can be co-visible and interact with each other, such as traffic and mass transit. However, too many layers could become hard to manage for novice users, simple show/hide checkboxes may not suffice. Memory management of layers in terms of pre-caching, loading and state-saving, as well as intra-layer version compatibility and licensing could be problematic. Apple would have to carefully select and test a rather limited number of vitally important layers to go on top of its base-map.
And yet a mini Map Store could help Apple catch up and pass Google Maps or other players in the field much faster than Apple alone could, as well as open up significant opportunities for Apple’s developer ecosystem.
Does Apple have to lose for Google to win?
Not if it doesn’t play by the same rules. After all, it’s Google’s game to lose. Tim Cook telling customers to use other companies’ mapping products must have taken some guts at Cupertino. It’s perhaps a conviction on his part (with his inside knowledge) that Apple can and over time will do better than the competing apps he so forthrightly listed. That’s the confident view Google would likely prefer to fly over.