WWDC2018 Session 239
Transcript
[ Music ]
>> 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.