Wildcard and The Native Mobile Internet

I very frequently get asked, “What is Wildcard?” People want to know what we’re building. It’s an extremely fair question, and it is one that we should be able to answer without hesitancy. Other variations include:

What is your vision?
What is true North? What is the bullseye of the target you’re running at?
What if you ignored all outside influences, and just built the thing you wanted to build? What would it be?

While there are many sides of our business, and it would be easy to begin describing the B2B opportunities in mobile or the SDK opportunity to serve other apps, what people are really curious about is the consumer vision for our product. In my head, I have a clear view of what I believe we are executing towards on the consumer facing side. I have a clear view of the future of the Wildcard app. Yet still, it’s been difficult to convey it to people concisely. It’s been even tougher to distill it down to one easily understandable sentence. This essay attempts to make clear exactly what it is that Wildcard is running at.

So, what are we building? The browser for the native mobile internet.

That’s it. The tagline may not be consumer friendly, and it may not be marketable, but it’s the most straightforward and honest description of what we are trying to accomplish. The unfortunate part of this seven word description is that it opens up many sensical follow up questions in order to truly understand what it means; for someone who hasn’t thought deeply about the future of the internet on mobile, and isn’t familiar with many of the new cutting edge technology decisions that big platforms are making, there is a lot of required background information in order to accept this as something both possible and necessary. Let me try to begin addressing some of the biggest questions.

What is the native mobile internet? In many ways it is similar to the current world wide web. It is an open network of machines serving data in response to requests, and users view and interact with that data from their client – a browser. However in the native mobile internet, these servers don’t serve pages, markup, or styling information along with their content. They just serve structured data according to a schema. And they just respond to actions according to a well defined interface.

The reason there is no HTML, CSS, or javascript-based flexibility to manipulate the layouts or provide custom actions is based on the idea that on mobile there are so many different screen sizes, form factors, and “edges” emerging (like Apple Watch or Android Wear), that from the perspective of a developer it’s nearly impossible to deliver a great experience across all these devices. Instead, if the developer or publisher delivers structured data according to a schema, then it can be up to a client implementation on each platform what the best possible native experience for interacting with that content is. On Watch it may look a lot different than on iPhone, and that’s ok. Every developer everywhere doesn’t have to decide what the killer experience is – they just need to provide their content and functionality, and the platform will handle providing the best experience.

This idea sounds reasonable in theory, but it would be logical to wonder: is it even close to remotely possible that developers and publishers would structure their data such that it can be rendered in a way that they don’t control? This is already happening. Publishers already structure the data behind almost every popular web page into schematized standards. OpenGraph, Twitter Card Markup, Schema.org, Microformats, are all examples of publishers providing this structure. And the platforms that consume them and render them natively, FB, Twitter, Google, and Pinterest, already use this structured data to alter the experience and place their content in areas that the publishers don’t control. On mobile this tradeoff is even more important, as the experience of leaving one of those platforms to consume publisher content in the web is terrible, whereas consuming it inline is far more natural and engaging for the user.

Of course, there is still a long way to go before this loose collection of markup standards become the backbone of a true native internet that exists devoid of web pages in the first place. In addition to structuring content, publishers need to respond to actions like “search”, “signup”, “buy”, “locate”, etc. Defining these supported actions, and defining the different structured data elements that are supported on the native mobile internet, is part of Wildcard’s charter, hopefully with the participation of the major platforms and other interested parties.

Moving on to other questions that need to be addressed, What are cards? Cards are the UI element that Wildcard uses to display the structured data and interactions natively on iOS. And we believe that they work well on Android, watches, glass, and other mobile and desktop platforms. It’s possible that we’ll need other UI elements for other edges that emerge, like voice interfaces for example, and that’s fine. The native mobile internet supports rendering the content in whatever way the platform implementor (browser provider) sees fit. “Card” is just a word…don’t get too hung up on it. However, cards do have a couple properties that make them appealing when searching for something that’s cross platform – they’re self contained, they’re portable, they can link to other cards, they’re simple. It’s easier to do a platform implementation of a card type when you know it’s size, shape, and data elements, than it is to do an open ended one for content of any size, shape, color, and level of interaction.

At this point you should hopefully realize that some of the building blocks of a native mobile internet have already emerged. Data is being structured by publishers, and displayed natively by platforms. Wildcard’s consumer opportunity is to build the first browser for this native mobile internet. And part of its thesis is that users will prefer this browser because it will be faster, more consistent, and less prone to failure or dissappointment or frustration than conventional web based browsers on mobile. Because it’s based in structured data and actions, and the content is rendered natively in the best possible way, the user experience will be “guaranteed”. This is very different from the roulette users play on mobile when clicking on google search links.

If Wildcard built only on top of what existed today, the best it could really do would be to display static content in the form of cards, and on top of that it could build a way for users to find the content they’re looking for. However, much like Netscape in the early days of the web, as part of building the first browser we also have to define some of the building blocks of the native mobile internet as we go. Some of these building blocks include answering questions around how cards link to other cards, how publishers receive input or personalization, how you build applications on top of these primitives, how publishers monetize their content, how identity and payment are baked natively into the browser, how publishers differentiate their brand’s presence, and more. The vision for Wildcard takes note that these questions need to be answered and aren’t figured out just yet, but running at finding the right answers to these questions should be part of the thrill of working with Wildcard. People with strong opinions rooted in experience should be eager to make the right calls here, with the mobile user in mind.

Finally, I’d like to loop this back to where Wildcard is currently. For 2015, we are working on two major product themes: search experience and home screen experience. Why focus on search if you’re building a browser? As Google has demonstrated on the desktop web, search is the killer application. It allows users to express their intent, and quickly find the content or actions that they’re looking for. As the native mobile internet emerges, there’s an opportunity to build a powerful native-only search. The cards that exist and the functionality that’s available is different than what exists on desktop. In addition to this being the huge long term opportunity, it also improves the user experience in the short term. A browser without access to search may not be compelling enough for consumers. In direct support of this search effort, we’re working on a data project to know about every piece of structured content out there, such that it’s possible for us to search, find, and surface this content to users in the browser.

And on the other hand, the home screen focus aims at making the browser compelling for users in the absence of an amazing search experience. The reasons for this are threefold. 1) Search is difficult and may not be good enough for awhile. 2) Initially search may not be a daily behavior on mobile, like reading top news or following socially shared content. 3) Many new users like to browse and discover, rather than explicitly declare their intent. Think of the Wildcard home screen as an attempt at creating the best home screen on the internet, analogous to Yahoo.com, AOL.com, or MSN.com. Sure, power users may start at Google or in a blank tab, but those home screens still serve as the starting points for much of the traffic on the internet today. As the native mobile internet emerges, many other home screens will be possible, including ones based purely on search, purely on navigation, purely on bookmarks, or purely on personalization. Today there may only be one starting point, but in the future, much like within a web browser, the user can start wherever suits them best.

In summary, Wildcard is a browser for the native mobile internet. This browser makes it possible to browse all the “cards” or structured pieces of data out there today, and in the future. It has the best home screen for navigating to and discovering these card experiences, and it has the best search engine for satisfying user intent within these experiences. It may take awhile to deliver on all of the above, but trends are all moving in this direction, and we have an incredible early team to continue tackling these challenges.

* If you’d like to join us on this mission, email me at any time.