Apple, after much anticipation, has entered the wearables vertical. Joining other major consumer mobile hardware producers like Samsung, Motorola and Xiaomi, this foray signals wrist-born computers have really arrived. Going forward, we’re going to be consuming content from and producing content for our wrists increasingly. Smartwatches are here.
In many ways, wrist-wearables are just another size of “smart glass,” joining an already-wide variety of mobile “phone” and tablet screen sizes. There is one key difference, though: wearables don’t have web browsers. No Safari on your Apple Watch, no Chrome on your Moto 360 or Google Glass.
There are only two kinds of content on wearable devices: native apps and cards. Wearable apps are native to the device, and have to be developed individually for each platform (like all mobile apps). It’s important to note they are new and separate, though: your iPhone app is not your Apple Watch app, just like your Android app doesn’t work on Glass or Wear.
Cards are another way to reach users on wearables. Cards are single-purpose units of structured data, optimized for mobile interaction. They are the only way (other then wearable app development) to structure your content so it can be displayed and interacted with on devices like the Apple Watch and Google Glass. Smartwatches don’t render HTML. They can run native applications, and they can understand single-purpose structured data units: cards. Cards also are the core unit of what, so far, seems like the wearable’s killer use case— Google Now, and Apple’s analogy, Apple Watch Glances.
Now and Glances surface relevant cards based on context and personalization data. These cards are meeting reminders, directions, weather, stock prices, or any single-purpose piece of content. Now and Glances are the center of wearable devices, the new homescreen, lock screen and notification center all in one. And they are completely card-based. As a brand, merchant, publisher or developer, if you want your content there, you need to publish cards.
Widespread wearable adoption is now a question of when, not if. Websites don’t exist on smartwatches*, only apps and cards do. As with all mobile devices, native apps will provide great user experience and costumer retention— think about your wearable app strategy right after you finish developing for multiple iOS screen sizes and iPad. Cards are going to be the currency of discovery, search and sharing on wearables. With Wildcard, you can leverage the same single implementation that gives you Twitter Cards, Rich Pins and other card types to share content into Android Wear and the Apple Watch. Wildcard partners go through one integration and get cards across mobile discovery platforms— from purchase-ready products cards on Twitter to place cards on an Apple Watch.
With the launch of Apple Watch, wearables are part of the present and future of mobile. And there is no mobile web in that future. Cards are how we consume, find and share content in the future.
*Unless you think this is the future https://www.youtube.com/watch?v=A8vwb06wuYg this is the definition of porting “legacy web technology” to new hardware where it doesn’t make any sense.
Rich Pins are a way to publish cards in Pinterest. Like all cards, Rich Pins are typeful, and include information and functionality specific to their type. They’re more useful and engaging than standard pins, which only contain an image, link and title. Providing a more informative and delightful experience in Pinterest gives users a stronger incentive to convert on a key action, or into your brand’s mobile app or website.
There are currently 5 types of Rich Pins (which are cards) offered by Pinterest:
Each type represents a unique template that displays data specific to its content. Recipe pins include data like ingredient lists and instructions, Movie pins include plot summaries and ratings, and product pins include price and availability, among many other fields. This information, displayed beautifully, provides a user more information about the pinned object, making the content behind a link less opaque. They render faster than web views or an in-app browser, and help a user engage with and understand your content in Pinterest.
Rich Pins, like Twitter Cards, are based on URL’s. However, where Twitter Cards are reliant purely on HTML meta-tags in the <head> section of webpages, Pinterest accepts two architectures. The first, like Twitter, is HTML markup-based.
For every URL you’d like to render as a Rich Pin when shared to Pinterest, semantic meta-tags must be added to the head or body of the webpage. Pinterest accepts both Schema.org and Open Graph markup in the <head> section, as well as markup wrapped around the content in the <body> of your pages. The tags required are specific to each Rich Pin type: they differ for products, recipes, movies, articles and places.
After adding the appropriate tags, a brand can submit a URL (or canonical domain) for approval. During the approval process, Pinterest will check to see that all required tag fields are present in your webpages. Once approved, any time a user shares a link to your domain in Pinterest, the relevant Rich Pin tag fields will be fetched from your HTML, and displayed as a card in Pinterest. If at any point your HTML changes, and the required tags cannot be located by the Pinterest bot, your Rich Pin will not display. In some cases, the Pin will fail to be posted, and in others, a standard Pin will be displayed.
Maintaining semantic markup for all webpages, across a variety of card types, is tedious. Additionally, it only allows a single card per webpage. With this in mind, Pinterest offers a second, preferred method: oEmbed. oEmbed is a protocol that allows you to designate a card-providing endpoint. This method is more scalable and flexible than HTML markup, and allows multiple cards per page.
A card-providing endpoint is one that can accept a request, usually in the form of a URL, and return the structured data required to populate the appropriate card. oEmbed refers to the standard Pinterest uses for formatting the request and card data returned in the response. An oEmbed endpoint that satisfies Pinterest’s requirements accepts a URL from your domain, and returns Rich Pin data in oEmbed format. The address of this endpoint does not have to match your domain, and could be set up by you, or by a third-party card provider, like Wildcard.
To enable this, a card provider (oEmbed endpoint, in this case) must be registered with Pinterest. Once approved, whenever Pinterest sees a URL from your domain, it will pass that address to the endpoint as a request, and the endpoint is expected to return Rich Pin data as a response.
Creating Rich Pins
Enabling Rich Pins requires implementing one of the two methods listed above (meta-tags or a card-providing endpoint).
For tags, each Pin type has a different set of required fields. These can be added to the <head> section of your HTML document, with the appropriate values filled in, or you can simply wrap the existing values in the <body> of your page with tags. Adding tags to the <head> can appear cleaner and more concise, but requires duplicating the data necessary to populate the card. Wrapping content in the body section means simply adding tags where your content already is, without replicating the data. However, this will make the body of your page less concise and human-readable.
Alternatively, you can set-up a card providing server. This server must have an endpoint that accepts URL’s, and returns the matching card data in Rich Pin format. There are a variety of ways to set up a card-providing endpoint, including working with a third-party, such as Wildcard.
After implementing tags or a card-providing endpoint, you need to apply for Rich Pins with Pinterest. This is accomplished by submitting webpages URLs (tags) or an oEmbed endpoint (card provider). Both forms of registration start by submitting an address into a form on the Pinterest Rich Pins dashboard. After that, it’s time to sit back and wait for a confirmation email. Pinterest has provided no information on how the approval process works, but, in our observations, it takes 2-3 weeks. As with the Twitter Card Platform, we hope this process becomes more transparent in the near future.
Rich Pins are Pinterest’s verison of cards, and they’re the best way to engage Pinners. They are a better representation of your brand and content in user’s boards. On mobile, where friction to switching contexts is high, Rich Pins can help a user understand your brand’s content. Providing a more informing and interactive user experience will improve engagement and conversion.
Twitter Cards are a way to tweet more than just 140 characters of text, links and static images. Using them, you can publish different layouts with use-case specific media, data and features. These cards are not just visually distinct and more engaging than “normal” tweets, they’re also more interactive— designed to include specific features and content for each use case.
10 different card types (like templates) are currently offered by Twitter:
There are also a variety of other card types that have been teased in temporary promotions, such as a voting card, as well as rumored-but-not-spotted types, like the commerce-enabled product card.
Cards are the most expressive and effective way to present content in Twitter. They increase engagement and conversion by bringing key content and actions into a user’s stream, rendering them natively. This presents a much faster, delightful user experience than asking a user to undergo the friction of a full-age in-app mobile web browser. Those are slow, frustrating for users, and have minuscule conversion rates. Cards are better, but how do they work in Twitter?
Twitter Cards are based on URL’s. After registering your brand, whenever Twitter sees a URL from your site in a tweet, it sends a bot to your page. That bot looks for specific “meta-tags” (labels, like creator, and values, like @trywildcard) that point to all the information needed to populate a card template. If all the required fields can be found by the bot (if their tags are formatted correctly), the tweet will render as a Card. If there are no tags, or some tags but not all required, or unexpected/disallowed values after tags, no card will appear. Instead, the plain text link will be included in a standard tweet.
Twitter also has a web dashboard where you can test product links, view card previews, and inspect which tags are working or broken. Once you’ve tweeted out some cards, you can track their performance in this dash as well.
Creating Twitter Cards
Specifically, Twitter Cards are based on tags in the <head> section of HTML pages. Registering your domain with the Twitter Card Platform is what informs the bot to check for Card tags each time your URL’s are published in Twitter. So, to get Twitter Cards, you need two things:
- Twitter Card (or, in some cases, Open Graph) meta-tags in the <head> section of your webpage
- Domain registration with the Twitter Card Platform via the Twitter Dashboard
Meta-tags must be added to the head section of a webpage according to Twitter’s standards. The required fields vary by card type, but can be found in more detail here. These tags convey basic information, like title, and content-specific information, like a product price or app download link. As information about the content in your card changes, the tags must be updated accordingly. The Twitter bot doesn’t read any of your page except what’s captured currently inside Twitter tags. While some other card platforms have begun offering more scalable, programmatic ways to create and serve cards, this remains the only way to integrate with the Twitter Card Platform.
After adding the necessary tags, you must register your domain and validate your cards with Twitter. This is achieved through Twitter’s Card Vaildator dashboard, available to any logged-in Twitter user here. The ‘Try Cards’ tab allows you to check the accuracy of each field, and see a preview. The ‘Validate & Apply’ tab is a single URL submission form. This is where you register your domain for card approval with Twitter. The time it takes Twitter to approve you for cards is highly variable— time sit back and wait for a confirmation email! Hopefully, in the future, this approval process will be more programmatic and transparent.
Cards are a great way to increase engagement and conversion on Twitter. They do a better job highlighting your brand’s content, and provide a more interactive, enjoyable experience for users. However, implementing them isn’t painless. Tags for all required fields must be added to the <head> section of each webpage on your domain. After adding meta-tags, you can apply for approval. A confirmation email will indicate when your URLs are Twitter Card enabled!
Cards have received a lot of attention over the last year. Across the industry, investors, entrepreneurs, designers, engineers and product people have taken turns exploring the future of mobile interaction and discovery*. Some of the advantages touted range from user experience, to search, shareability, inter-app communication and sheer performance. There’s one theme that recurs in all the commentary though: the current mobile ecosystem is missing something.
The mobile web, which is increasingly our primary web and the only web for many, sucks. It’s slow, it breaks a lot, it’s hard to use.
Screenshots from Alexis Madrigal’s wtfmobileweb.com
Apps fix much of that: they’re fast, dynamic and engaging. But only if you stay within a single app’s confines.
Try to share content or context between apps, or discover a new one, and the experience is slow, difficult and confusing. If mobile is the new dominant paradigm, why do we limit mobile optimization to single programs, and wrestle with legacy technology the rest of the time? Imagine if users could access their touchscreen only inside apps, and had to use a mouse to navigate between them—they’d be outraged. This is more or less analogous to the way we’re plugging the gaps between sandboxed applications with legacy web technology.
Cards fix that. They’re the best way to format content for your phone, whether that content is a product, an article, a video, a map, a stock price, a reservation tool, or pretty much anything you might encounter in a web page or app. Cards are single-purpose: one card usually contains one thing. This keeps them fast and easy-to-use.
The look and feel of cards are also ideal for mobile devices, as the many successful apps that have adopted this approach can attest to. The user experience and performance of cards outstrips mobile webpages by several orders of magnitude. Additionally, a card’s single-minded focus on just one piece of content or functionality keeps it fast and easy to digest, and makes the form particularly well suited for re-arrangement, engagement and intelligent presentment to users.
Cards, unlike content locked inside an app, can work across platforms. That’s because, under the hood, cards are just structured data—information formatted in a predictable, specific way. Apps lack this common syntax, which is why we can’t easily share content between them. There’s lots of structured data in webpages, but there’s also lots of data related to layout and interaction that doesn’t take advantage of mobile device affordances, which is why the mobile web is so slow. Cards provide a middle ground, allowing us to share content between apps, without forcing the user to load an entire webpage every time.
So, what are cards? Single-purpose units of structured data, optimized for mobile interaction. They’re the ideal amount of content, coupled with a sip of functionality. Cards are fast and delightful, ideal for mobile users. They’re easily discoverable and sharable. Cards are the beginning of a truly mobile web.
For further reading on cards, check out these great posts by our friends:
If you’re a brand or business looking to take advantage of cards, we’d love to hear from you.
One of the themes over at Wildcard Engineering is continuous self improvement as an engineer. Since we have team members working on all sorts of different projects, using many different programming languages and technologies, we have clear opportunities to learn skills from one another that we wouldn’t if we were all pigeon holed into one particular project or codebase. In addition to general team meetings and pair programming, two ways in which we try and share knowledge with each other are tech talks and hack days.
Once per week an engineer at Wildcard gives an hour long tech presentation on a topic that may be new to most other people on the team. Someone may present on a Wildcard specific topic like the architecture of a particular internal service, or on an interesting technology that we may want to considering using the future like a new iOS framework or devops tool.
Last week the super talented @yusmi gave a great talk on search architecture and ElasticSearch , and this week Matthew Ng will be speaking on automated entity extraction. The talks are generally interactive and leave plenty of time for examples, questions, and looking at code. Outsiders are welcome to attend or even speak, so if you’re in the area and want to participate in the future just drop us a line.
This past Friday we broke from regular work to hold our first internal hack day. We pitched some projects, split into teams of 2-3, and sprinted to finish working apps by the end of the day. The benefits of spending a day like this include:
- Collaborating with people you don’t work with frequently.
- Learning and experimenting with tools or technologies that are out of your comfort zone.
- Get in the mentality of shipping something quickly.
On top of that, it’s fun. The hack day was a tremendous success. Business folks, designers, interns, and developers all got down to work. Some people hacked on Wildcard related one offs that add a ton of value, but never seem to make it onto the product roadmap as top priority. Some people worked on office related improvements like the ability to buzz people into the office without getting out of your seat.
The winning hack, called Entrance Music, was an iOS app where you can choose the song that you want to play as you walk into the Wildcard office…much like a baseball player picking the song that plays as he walks up to bat. It used iBeacons, donated by Estimote, to detect the users location, and a custom music server hooked up to our Sonos speakers to play the song.
Maybe we’ll release it so guests can make a powerful entrance of their own design.
After a few months of living with the leftover artwork hanging on the walls of our Chinatown office, we decided that it was time to spice things up a bit….
Wildcard is a seamless replacement for the Internet on your phone. Our vast library of cards delivers the mobile web faster than any browser, and in a fraction of the time it takes to download native apps.