Designing Web Content for watchOS

Welcome to designing web content for watchOS. My name is Wenson and I'm on the WebKit team. In watchOS 5, we're introducing the ability to render rich HTML content on Apple Watch using WebKit. Before we explore how it works, let's go over a couple of the ways WebKit enriches the user experience on watchOS.

Previously in mail, rich HTML mail messages would be rendered in a text-only format requiring the user to go to another device for the full experience. New in watchOS 5, the full HTML mail message can now render on Apple Watch in cases where text-only formatting cannot express the full content of the message.

When tapping links in mail or messages, we'd previously direct the user to iPhone in order to view the web page. Also new in watchOS 5, the user can now tap links to view and interact with the web page directly on Apple Watch.

In this session, we'll explore the techniques WebKit uses to adapt existing content to watchOS and introduce a new mechanism you can use to optimize your content for display on Apple Watch. We'll also cover some other important details you need to know to ensure that users viewing and interacting with your content will have a great experience. I'd like to start by discussing how WebKit works on Apple Watch.

Out of the box, WebKit supports the gestures you're already familiar with.

Turning the digital crown scrolls vertically and you can also drag your finger on the screen to scroll the page.

Double tapping zooms into the page and a subsequent double tab zooms back out.

Lastly, a firm press reveals back and forward buttons, but you can also swipe forwards or backwards to navigate through your history. It's important to note that we optimized WebKit for quickly consuming content. Therefore, a limited set of features are not supported at this time. These include video playback, service workers, and web fonts.

Now let's see how WebKit lays out web pages on Apple Watch.

Most responsive content is already well proportioned when laid out at 320 CSS pixels, the width of iPhone SE.

We ensure that it's also well-proportioned on Apple Watch by laying out at this width and then computing the initial scale of the page such that the content width fits within the viewport. This means that text and images may appear smaller but the overall layout of the page is preserved.

When this technique is used, the viewport meta-tags initial scale is ignored in favor of an initial scale that contains the entire content of the page.

Additionally, inner width is inflated to a minimum of 320 CSS pixels. And when using media queries, the device width will also appear to be 320 CSS pixels rather than the true width of Apple Watch.

By shrinking to fit, we also avoid horizontal scrolling on pages where content is wider than the viewport.

These heuristics adapt existing content to Apple Watch, but you can override them when designing content tailored for this form factor. Let's look at an example. I've written a web page that contains a gallery of photos I took from a recent trip to Vietnam, and I'd like to share it with my friends.

If I send them a link to this page using messages, they can view it on Apple Watch. Right now it's laying out at a width of 320 CSS pixels and shrinking down to fit. However, I've also written this page to be responsive on Apple Watch by using a media query to limit my two-column layout only to viewports larger than 320 CSS pixels.

Now all I need to do is tell WebKit that this page is already optimized for Apple Watch and doesn't need the default adaptations. To do this, I simply include a new meta-tag in the head of my document with name equal to disabled-adaptations and content equal to watch. I'm using this new disabled adaptations meta-tag along side the existing viewport meta-tag I'm already using to ensure responsive layout on iPhone and iPad. This allows WebKit to treat the viewport's device width as the real width of Apple Watch.

Let's now switch gears and talk about some best practices for form controls. WebKit supports interaction with form controls out-of-the-box. To ensure a great experience for users when designing form controls and inputs, it's important to keep a couple of things in mind.

First, choose the appropriate type attribute and element tag for your form controls. WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.

Secondly, it's important to note that unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.

Lastly, let's dive into Safari Reader.

You may already be familiar with Safari Reader, a feature on iOS and macOS that reformats text heavy web pages to make them easier to read.

We've brought Reader to watchOS 5 where it automatically activates when following links to text heavy web pages. It's important to ensure that Reader draws out the key parts of your web page by using semantic markup to reinforce the meaning and purpose of elements in the document. Let's walk through an example. First, we indicate which parts of the page are the most important by wrapping it in an article tag. Specifically, enclosing these header elements inside the article ensure that they all appear in Reader.

Reader also styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we're able to ensure that the author, publication date, title, and subheading are prominently featured.

This paragraph contains content that is of strong importance and other content that is emphasized, so we put this text under strong and em elements. Reader recognizes these tags and preserves their semantic styles.

For this image, we use figure and figcaption elements to let the Reader know that the image is associated with the below caption. Reader then positions the image alongside its caption.

For this quoted paragraph, we use a blockquote element rather than a stylediv. Reader automatically styles these blocksquote elements as appropriate.

Lastly, adding open graph meta-tags gives more context to Reader and also ensures that links to the article look great when shared.

For more information about open graph meta-tags and rich links, check out our video on Ensuring Beautiful Rich Links.

To recap this session, we've seen how WebKit adapts existing content. And we've also seen what you can do to optimize content for layout in Apple Watch. Finally, we covered best practices for form controls and also learned how to ensure that Reader brings out the key parts of your web page.

We're so excited to bring the power of the web to watchOS and can't wait to see what content you create for Apple Watch.