Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[Applause]
>> MIKE STERN: Hello, everyone.
My name is Mike Stern.
I am a User Experience
Evangelist at Apple,
and it's a pleasure to
be with you here today.
So today's session is about
designing for Apple Watch,
and in particular we are going
to talk about tips and tricks
about how you can do that.
Now, on Wednesday I
gave a different talk
on the same topic, but it had a
bit of a different nature to it.
And for those of you who weren't
here for that, it's okay.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And for those of you who weren't
here for that, it's okay.
I'm not totally hurt.
But I do want to bring you
up to speed a little bit.
So there were three key
themes for that presentation
that I'll review very briefly.
Those three themes were Personal
Communication, Holistic Design,
and Lightweight Interaction.
Personal Communication
involves taking what we know
about positive and effective
interpersonal communication
and using that as a model
for how we design
apps for Apple Watch.
Now, interactions on Apple
Watch create a more intimate
and personal experience with
technology, and it's important
that the apps that you design
for Apple Watch take advantage
of that and feel more
intimate and personal as well.
Holistic Design is about
blurring the boundary
between software and
hardware, and that could be
through the visual design
of your app's interface
and allowing it to
seamlessly blend
in with the Apple Watch bezel.
It's about harnessing
the capabilities
of the Force Touch display
and using it properly.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of the Force Touch display
and using it properly.
Same thing with the
Digital Crown.
And the Taptic Engine,
especially now
that we have haptic feedback.
You can use these things
to create a more immersive,
sophisticated, and
nuanced experience
for the people who
use your apps.
And Lightweight Interaction is
about designing for quick looks
and fast interactions.
It's about taking advantage
of the Watch's unique
position on the user's wrist.
So together, these three
themes are the foundation upon
which you can design really
great apps, notifications,
and glances for Apple Watch.
And everything we are going
to talk about today relates
in some way, some shape or
form, to these three themes.
But this talk is a
little bit different.
Now, in today's presentation,
we are just not going
to recycle the things that
we talked about earlier;
we are going to get down to the
specifics, the nuts and bolts,
the brass tacks about how
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
the brass tacks about how
to make really great
Apple Watch apps,
notifications, and glances.
And we are going to
do that by talking
about the top 10 common pitfalls
that we've seen developers run
into when designing
for Apple Watch.
Now, Apple Watch is a new
type of device for Apple,
and you know, even for someone
like me, I've never designed
for a wearable device, so a lot
of things are a little bit
counterintuitive or new.
So we see these kind
of common missteps.
So there's no issue with
that, but we want to talk
about these things we've
learned along the way.
Does that sound like
a good thing?
Are you guys on board with that?
[Applause] Yeah?
All right.
Cool. Great.
I am really fired up
to talk about this,
so without further ado,
let's get into the number one
common pitfall, and that's --
[Laughter] -- and that is not
a very good user experience.
The number one common pitfall
that we've seen are slow apps.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The number one common pitfall
that we've seen are slow apps.
Apple Watch is all
about convenience,
so if your app takes too long
to install, or it takes too long
to launch, or pages
take too long to load,
that's not very convenient
for people at all; right?
The design of your app's UI
and how you produce graphics
can have a huge impact
on the performance of your app.
You want to design
for performance.
So whenever possible,
for example,
you want to use progressive
loading of pages,
and that simply means that you
don't need to make people wait
for all of the content
to be ready to display
on a page before you let
them go to that page.
You can bring them to the
page, show a few things,
and then show the rest of the
stuff as it becomes available.
You know, seeing this
is pretty disappointing.
We want to avoid this.
When someone taps a button to
load a new page or they swipe
to it, they should get
to that page immediately.
It's a reasonable expectation.
So let's look at an example.
Let's say we have an app
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Let's say we have an app
that simply lists nearby
Apple retail locations.
Now, on this screen, we have
a list of all those stores,
we have the store name,
we have the address,
and we have the distance
from our current location.
Now, all of this information
is going to be present
on the detail screen for each of
these stores, so we have a lot
of data that's already ready
and stored locally on the watch.
So when we go to that page,
we already have a bunch
of content to display.
Other things, like the store
hours or maybe a description
about how to get to the store,
it's all text and it's going
to load pretty quickly.
Now, perhaps there's also
a photo of this store.
We didn't need to
make users wait
around until we had the photo on
the Watch just to draw the page.
In fact, it's better
to let people go
to the detail page first so they
could see specifically what it
is that they would
have been waiting for.
I mean, by showing
a photo label,
these labels here make it very
specific about what remains
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
these labels here make it very
specific about what remains
to be loaded into the page.
And people might not be
interested in looking at photos
at all of the store,
and if that's the case,
they have access to the other
information on the page.
They can get that
and then leave.
Now, if you use progressive
loading like this,
you want to make sure that
you hold open the space
for the things that
will eventually load
in by using placeholder
graphics.
The reason for that is when
things eventually draw in,
you don't want the height
of the page to change
because if you were looking at
something like below the photo,
all of a sudden it
would jump out of view.
It actually, I guess,
would go down lower.
And that's very disorienting,
so you've got
to hold the space open.
Now, if you use this
technique, you should also think
about the way that you've
ordered content onto the page.
You want to put things that
are likely to take longer
to load further down
on the page.
So with that photo offscreen,
there's going to be more time
for it to load in before the
user actually scrolls to see it.
They may never realize that
it wasn't present onscreen
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
They may never realize that
it wasn't present onscreen
when they had first
gotten to this page.
Now the next way to
design for performance is
to optimize your graphics.
And the best way to do that
is through compression.
When you are producing
graphics, it's important
to pick the right compressions
type and use the right settings.
So for example, with photos,
most of the time you
are going to use JPEG.
JPEG is what we call
a lossy format,
meaning whenever you save
a JPEG, there's some loss
to the visual quality or
fidelity of the image.
But with moderate
compression, that's okay.
It may not really affect the
perceived quality of the image.
Let's say we are going to
compress this photo here.
It's kind of blown up, so
it looks a little pixilated.
Let's compress this photo.
At the highest quality
setting for JPEG,
it's going to take about 125 K.
As we lower the quality setting,
we see that the file size starts
to drop off pretty dramatically.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
At the highest compression
setting,
the lowest quality setting,
it's just about 25 K,
or about 20 percent of
the highest-quality image.
That's a pretty big file
size savings, but it's going
to look pretty terrible there.
Usually when you are
compressing JPEGs,
you want to find
somewhere in the middle.
As you can see, we
sort of hit a point
of diminishing returns anyway.
So let's look at how these
compare side by side.
It's pretty hard to tell that
there's actually any difference
in quality whatsoever, and
yet we've saved two-thirds
of the file size.
You can only really see those
visual artifacts of compression
when you look up close.
But that's not how people
experience these images.
That's not how we take them in.
They look at it on a very
high-resolution Retina display
on a device that is kind
of constantly moving
around a little bit because
it's strapped to their wrist.
So it's hard for people
to see those artifacts.
Next, let's talk about PNGs.
Now, PNGs are basically the
way most other graphics other
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, PNGs are basically the
way most other graphics other
than photos are displayed on
most apps, and by default,
PNGs use a 24-bit color
palette, which basically means
that there's millions of colors
that are at your disposal
for drawing the artwork
in the graphic.
But for most graphics like this
icon, that's way more color
than you actually need.
So when you save out your
PNGs, you should be aware
that there's also an 8-bit
color palette setting
that you can use.
That just means that you
have 256 colors or less
to draw your images,
but for this graphic,
it's more than enough.
In fact, it's only at around
200 colors or less that we start
to notice any kind of dithering
or posterization of our artwork.
You want to be really frugal
with file-size settings
by using 8-bit pings.
As you can see here, the
file size savings are
really tremendous.
It's almost a tenfold
decrease in file size.
Again, there's no discernible
difference in quality.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
When your app has
a lot of graphics,
the overall file size savings
can be really tremendous,
especially when you have image
sequences for animations.
It can lead to significantly
smaller sizes for your apps.
So it's important to take
this stuff seriously.
Now, next you want to
avoid using transparency
when it isn't necessary.
Transparency requires
alpha channels,
and alpha channels
take up file size.
So avoid those unless
you actually need it.
Now, sometimes you
do need transparency.
For example, this graphic
for the Weather glance,
it's composited against a
translucent dark background
that blurs the watch
face behind it.
Because of that, you
need transparency to let
that color information
come through.
But a similar icon for the
Weather app doesn't need it.
It's always composited
against a black background.
So we can just assume and bake
in that black matte background
and not have an alpha
channel at all.
Okay. Now, the last
main technique
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Okay. Now, the last
main technique
for optimizing graphics
is to just make graphics
at the size you actually
need them.
And this is especially
true when you are sending
over graphics at runtime.
There is no sense in sending
over a larger graphic or video
than what you actually need
to display on the Watch,
and that's especially true if
portions of it are just going
to get cropped out anyway.
So make sure images and
videos are the right size.
Okay. So designing
for performance means
progressively loading content
on pages.
It means ordering things
so people don't realize you are
progressively loading content,
and optimizing graphics through
compression, no transparency,
and using the correctly
sized graphics.
Now, for more information,
I recommend watching the
video for this session.
There's lot of great, a little
bit more engineering-focused
tips and tricks about how
to optimize for performance.
Now, there's another
really good technique
for optimizing the
performance of your apps,
and I'd like to share
it with you now.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and I'd like to share
it with you now.
It's a really, really good one,
and it involves not
making complex apps.
Common pitfall number two.
Now, a little bit earlier
I said I wasn't just going
to recycle content from
my earlier presentation.
That's a little bit of a fib
because I am going
to do that a bit.
Apple Watch is not
a miniature iPhone.
This is so important that
I want to say this twice.
We've seen developers do this
time and time again, and again,
it's a natural thing to
try to take our assumptions
and processes for making
apps from iPhone and apply it
to Watch, but it winds up with
apps that are difficult to use
and difficult to navigate.
Apple Watch is ideally
suited for quick looks,
for convenience, and
brief interactions.
So what information and actions
do people really want quick
access and convenient
access to from your iOS app?
Make sure that you
focus on the essentials.
Don't overload your app
with too much information
or functionality.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or functionality.
This is really a recipe for
poor usability on Apple Watch.
So for example, the Calendar
app on the iPhone does all sorts
of things that the Apple
Watch Xalendar app does not.
You can't search in the
Calendar app on Apple Watch.
You can't add events.
You can't manage your calendars.
And you can't see nearly
as far into the future
or into the past at all.
Calendar on Apple Watch
is just a small subset
of the overall functionality of
what you can do on the iPhone,
but it's the things that
make sense for the Watch.
Right? You can check your
calendar, what's going on today
and what's happening
in the next few days.
You can get a little
bit of detail about each
of the events in your calendar.
You can accept, you can
decline invitations,
you can contact the organizer
in case you are running late
or you need to cancel
the meeting.
This is the things that
make sense on the Watch.
Not all of the other stuff
that you can do on your iPhone.
Apple Watch apps should
complement your iPhone app.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Apple Watch apps should
complement your iPhone app.
As we just saw with
Calendar, that could be
by providing a small subset
of the overall functionality
from your iPhone on Apple Watch,
or it could be extending the
capabilities of your iOS app.
So for example, the Camera app
for Apple Watch turns Apple
Watch into a viewfinder
for Camera on your
iPhone, which allows you
to set your iPhone far away from
you, take a picture of yourself,
friends from a distance,
and make sure
that everyone's in the frame.
It's extending the experience
of the Camera app on iOS.
Now, I challenge you to think
about how you can
do a similar thing
for your apps with Apple Watch.
How can you extend the
experience of your apps in ways
that were not previously
possible?
Okay. Common pitfall number
three is tedious navigation.
Tedious navigation is the
result of inefficiencies
in the user flow that
makes it harder for people
to find what it is that
they're actually looking for.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to find what it is that
they're actually looking for.
Now, tedious navigation
often results
from choosing the wrong
structural model for your app.
There are two structural models,
two core ones, for Apple Watch.
The first one is a
page-based model,
and here we just have a series
of pages that are sort of side
by side with each other and
you swipe to go between them.
That's the model
that Weather uses.
You swipe from city to city.
The other structural model
is a hierarchical model,
and in a hierarchical model,
you have a high-level set
of categories or content
summaries, and then you tap one
to go to more detailed
information
or more specific functionality.
Stocks is an example
of a hierarchical app.
At the top level, we have a
list of stocks and markets,
and if we tap on one of these,
it pushes on a child view
with more specific information
on the item we selected.
In watchOS, it's not possible
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
In watchOS, it's not possible
to mix these models
with each other.
So you can't start
with a page-based model
and then transition
to a hierarchical
one at lower levels.
And conversely, you can't start
with hierarchy and transition
to a page-based model
at lower levels.
The reason for this is
because of screen size.
To explain why, let's
look at this child view
in a hierarchical app.
So I just highlighted that
little chevron or back arrow
in the top-left corner, and
that's your way of getting back
up to the parent view
if you tap that button.
But it's a pretty small tap
target, and the hit area
for it is not very well defined.
It's a little bit
definitely bigger
than the arrow, but not much.
So to make it easier
for people to get back
up to the parent view,
you can also swipe
in from the left
edge of the screen.
And that will help
you transition back
up to the parent
view, as we see here.
Now, the trouble is
in a page-based app,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
very similar gestures how you
go to the previous screen.
And because the Watch
display size is pretty small,
it's difficult to support both
of those gestures
simultaneously.
So you must decide which
model is best for your app.
The structure that you choose
should obviously make it easy
for people to find what it is
that they are looking for with
as few swipes or
taps as necessary.
Now, usually deciding
between hierarchy
or a page-based structure comes
down to the number of screens
that are in your app and
the type of information
that you are displaying.
So a page-based structure
works best
when you are showing a flat
collection of information
in which all of the
items are peers,
and page-based apps shouldn't
have too many screens
because swiping between them
is a relatively slow way
to browse through content.
So Weather meets both
of these criteria.
Most people only want to check
the weather for a few cities,
so you don't have
too many items,
and it doesn't feel
cumbersome that you have
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and it doesn't feel
cumbersome that you have
to swipe between them.
When it comes to understanding
weather conditions,
all cities are basically equal.
There is no need to organize
or categorize them
on some higher level.
On the other hand, hierarchical
apps are better for larger
or more complex data structures.
People may use the Stocks
app to track dozens of stocks
and markets at the same time.
By using a top-level list,
navigating to any one
of those individual stocks or
markets is really easy to do.
You just scroll the screen,
find the one you are
looking for, and select it.
Now, the other cool thing
about this is there's a ton
of really useful information
just at this level.
So people may get all of the
information they actually need
without even needing
to navigate at all.
That's really efficient.
Okay. So, now just imagine
if we had designed this
as being a paginated
or page-based app.
It would take people forever to
get through all of the stocks
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It would take people forever to
get through all of the stocks
to go from -- to find the
one that they are looking
for if it was really far away.
And hopefully they would start
swiping in the right direction
because if they didn't,
they'd have to double back
and go all the way
back to the beginning.
Choosing the right model
is really important.
Tedious navigation
can also result
from overusing modal sheets.
Now, modal sheets support
paging through multiple views,
and I've seen people try to
get around this limitation
of not being able
to go from hierarchy
to page-based structures by
using modal sheets instead.
Now, this is something that I
would strongly advise against.
First of all, modal sheets
don't display the time,
and we think it's pretty
important that most
of the time people can see
the time on their Apple Watch.
And the animation of a modal
sheet sliding up is meant
to be a bit disruptive.
It's like this separate pane
of information, which slides
up over the main
interface and takes people
out of the main app experience.
It's meant to signal
a departure.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It's meant to signal
a departure.
It should feel a
little bit disruptive.
So if a primary aspect of
the way people navigate
in your app causes these
modal sheet animations
to occur all the time,
the overall experience is
not going to feel very fluid.
It will feel jarring,
disjointed.
Now, another thing
related to modal sheets
and tedious navigation,
is you don't want
to have too many
modal sheets sliding
up over each other
or back to back.
This is the same thing on iOS.
People will start to
feel like they are lost
in this modal experience
that never ends,
and they will have difficulty
or feel like it's difficult
to get back to the main
experience of your app.
Now, regardless of what
structure you choose,
it's important to
keep it simple.
So in a hierarchical app,
you shouldn't have more
than two levels of
hierarchy, three at the most.
Anything more than
that, and it's going
to take people a long time
to find the things
they are interested in,
and they will start to feel
lost in your hierarchy.
And with page-based apps,
as I was suggesting before,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And with page-based apps,
as I was suggesting before,
avoid having too many pages.
Again, swiping through all of
these pages will take a lot
of time and feel really tedious.
Tedious navigation is really
inefficient navigation.
And there's that design
principle I was talking
about earlier, Lightweight
Interaction.
Lightweight Interaction
is really all
about efficient navigation, or a
big aspect of it is efficiency.
So moving on, the fourth common
pitfall is confusing labels.
Now, what I am talking about
here is mostly about page titles
and the Close buttons or Dismiss
buttons for modal sheets.
Let's start with page titles.
Now, a common misconception
is that in a hierarchical app,
the title there where it says Do
Not Disturb on the right side,
that that's actually a Back
button or Back button label
and not a title for
the current view.
But that's not really the case.
If we were to use it
as such, we would wind
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
If we were to use it
as such, we would wind
up having multiple screens
that share the same title,
and at a quick glance,
they both are supposed
to look like titles.
So you should really
avoid doing this.
Now, I understand
why people do it.
This is also wrong
for the same reason.
It's not a Back button,
so please don't have
Back here instead.
So as I said, I got
ahead of myself.
I understand why people
treat it as a Back button
because it originally
resembles a Back button
from an iPhone or an iPad.
But on the iPhone or
an iPad, you have space
to show both the Back button
and a title at the same time.
Now, in Apple Watch, the
display is much smaller,
so you can't show both.
It would be kind of ridiculous.
So you have to choose which
one to show, and ultimately,
showing a title is
more important
than showing a Back button.
It's more important that people
know what they are currently
looking at than what's
on the previous screen
or the parent screen.
Now, the other common
misconception when it comes
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, the other common
misconception when it comes
to labels relates to
modal sheet Close buttons
or Dismiss buttons.
Now, these can be
renamed because,
instead of saying Dismiss,
it might be more natural
to say Close, or
Done, or Cancel.
But however you rename it, it
needs to be clear to people
that these are actionable.
People need to realize that
they can tap that label
and it's going to do something.
And not just do anything.
It's actually going to close the
modal sheet and take them back
to the previous screen.
So you don't want to
do something like this,
where you just use
it as a title,
because then people are
not going to realize
that it's actionable, and they
are going to hunt around and try
to figure out how they
are actually going
to close the modal
sheet and be stuck
in this screen for too long.
And for a variety of reasons,
please, please do not do this.
Right? As I said before,
even in a hierarchical app,
you shouldn't treat
this as a Back button.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So this is just putting
an angle bracket
and the word Back in here.
But this is going to be
confusing for people.
First of all, modal sheets
slide up from the bottom
of the screen, they don't
slide in from the right,
and you can't use the left-edge
swipe to get back out of here.
This is really confusing for
people when they see this.
Okay. Now, the fifth next major
common pitfall that we have seen
on Apple Watch is
using the menu control
for primary navigation
in your app.
Now, menus like this one
for Messages are really good
for contextual actions,
like making a new message.
Or for view mode preferences,
like this one for Calendar
for switching the visual
appearance of your schedule.
But when you try to use a menu
for navigation, it causes a lot
of usability problems.
The main one is that people
just don't know where they are
in your app structure or
even that they can navigate.
So for example, in
a hierarchical app,
that arrow there serves a
really important purpose.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that arrow there serves a
really important purpose.
It lets people know about
what the structure is
of the app that they are in.
It lets people know that they
are in a hierarchical app.
More than that, it lets people
know they are in a child view
so they can go back up to access
the navigation for the app.
That's pretty important,
that's a pretty fundamental
thing for people to know.
Similarly, in a page-based
app, those dots at the bottom
of the screen tell
people that they're
in a page-based structure.
And it tells them how many other
pages there are, it tells them
where they are relative
to those pages.
It tells them that they
can swipe side to side
to navigate between pages.
It's a lot.
It's doing a lot; right?
It tells people a lot about
how to interact with the app.
But if you used a
menu for navigation,
there would be no onscreen
visual cues about how
to navigate, and like I said,
you wouldn't see any cues
that navigation is
even possible.
So you might feel like the
screen you are currently looking
at is the only screen
the app has.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
at is the only screen
the app has.
So it's best to stick with
just straight-up hierarchy
or page-based structures
in your app and not try
to use a menu for navigation.
Now, this is a bit of a tangent,
but it's related to menus,
so I thought I would
mention it here.
It's sort of a bonus pitfall.
You don't have to
pay anything extra
for this, but I accept tips.
So in menus, like I said.
Menus are -- have a very
distinct visual style to them.
The appearance of the buttons
here have dark liner icons.
They are situated on these
filled-in lightish gray circles,
and they have light labels.
It's a very distinct
visual appearance.
If you design your app's
UI to look like this,
it's going to confuse
the heck out of people.
They might think that they
pressed the display too hard
and they are actually looking
at the menu for your app,
and then they realize they
don't want to navigate anywhere
or do any of this
stuff, so they try
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or do any of this
stuff, so they try
to close this by
tapping outside.
But that does nothing, of
course, because they are not
in the menu, so they feel like
your app is frozen on them.
Not a good experience
for people to have.
Fundamentally, there's
nothing wrong
with having a navigation
system in your app
that has these large
graphical icons like this,
but try to do something
to distinguish it
from the appearance of
the menu control itself.
So rather than having those dark
icons, light gray background,
try adding in your
Global Tint color.
Or rather than having
the dark icons there,
maybe make them white and do an
outline stroke for the buttons.
Or do something more
even different than that.
Whatever you do, try to make
it distinct from the appearance
of the menu control itself.
Okay. So that's it for
menus, and that's it for me.
I actually would love to hand it
over to my esteemed colleague,
Rachel Roth, to take this home.
Rachel?
[Applause]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[Applause]
>> RACHEL ROTH: Thanks, Mike.
Hi, everybody.
My name is Rachel Roth, and I
am the other User Experience
Evangelist at Apple.
So I am going to take you
through the rest of this list.
On the Apple Watch,
it is really important
that people can quickly
determine what's tappable
and what's not tappable,
and a common problem
that we see all the
time are buttons
that don't look like buttons.
The Watch has its
own design language,
and it's not identical to iOS.
On iOS, we primarily rely on
color or position on the screen
to tell if something's tappable.
So when a control is placed into
a toolbar or a navigation bar
and it's given a different
color, people can assume
that it's something that
they can interact with.
Like here on Maps, we
know that each item
in the corner is tappable
because of its location
and its color.
Now, on Apple Watch, most
controls are put inside
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, on Apple Watch, most
controls are put inside
of these rounded rectangle
or circular shapes,
and that's because of
the limited space we are
dealing with.
There just aren't room
to have a dedicated place
like a navigation
bar or toolbar.
Everything aside from the
status bar is in one view.
So there's no dedicated
place to put those controls.
And it's also trickier to rely
on color as a visual indication
of interactivity because
page titles are colored
on the Apple Watch.
And we do this to reinforce
context and also branding.
It aids in usability
because the color
of the titles can help you
understand what app you are in,
especially if you
look away because --
to see if your bus is coming
and quickly look back.
Here are two apps with
very similar content.
We have Yelp on the left, and
on the right is Foursquare.
Again, both have
similar content,
but because Yelp has
their red branded color
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
but because Yelp has
their red branded color
and Foursquare is
more of a pink,
that page title color lets
you know what app you're in.
Same thing.
We have Timers on the left and
Runtastic Six Pack on the right.
The color really helps reinforce
the identity of the application.
A lot of people have said
they are not sure how to set
that color, so that's
the Global Tint color.
Now, another convention that we
use on iOS is we add chevrons
to things that are tappable,
like we do in table rows
of settings and next
to text labels
like the developer
name in the App Store.
But if we put chevrons
on the Apple Watch, well,
they just take up
too much space.
If the label for
voicemail was any longer
or my font size was set larger,
it would cause the text
to wrap or truncate.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And also, they just
become noisy.
You are dealing with
a very compact width
on the Apple Watch, so the
chevrons become a distraction
from the icons and the text,
and that's the important
information.
If you are using the
rounded rectangle shapes,
there's no need to add chevrons
to indicate interactivity.
They are going to
instinctively look tappable.
Now, another convention that
we use on Apple Watch is
to put buttons into a circle,
and without the circle,
these phone icons would
look pretty ridiculous,
and they would also seem maybe
more like a status indicator
or a decorative embellishment.
But the circle makes them
unmistakably button-y.
When you are dealing with
these short interaction times
and quick decisions,
you really want to --
people need to be able to
quickly react to something.
I have a phone call.
Do I want to accept
or decline it?
The circles help make
the actions very clear.
But it's not as though
rounded rectangles
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But it's not as though
rounded rectangles
and circular shapes are these
revolutionary new concepts.
This is where there
is similarity to iOS.
We use circles on the iPhone
when buttons might
otherwise be ambiguous.
Same with the rounded
rectangles.
You see them all the time
with segmented controls
and the Buy buttons
in the App Store.
In fact, if we didn't have
the rounded rectangle,
that Buy button might
be ambiguous,
and if there's one thing
we can all agree on,
we want to make it
really obvious how
to buy apps in the App Store.
So on Apple Watch,
the rounded rectangles
and circles help people quickly
understand what's actionable,
and when you are dealing
with those really brief
interaction times,
like Mike said, you really just
have a couple seconds while
someone holds their arm
up before it gets tired.
Every fraction of
a second counts.
So you want to be sure to
put anything that's tappable
into a rounded rectangle
or circular shape,
and just as importantly,
don't use these shapes
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and just as importantly,
don't use these shapes
for anything that's
not tappable.
They will look tappable and
confuse people if they aren't.
Now, in iOS, we sometimes do
use these shaded backgrounds
to group like items together.
So it might be tempting
to do something like this
on the Apple Watch,
but if you do,
all of these things
would look tappable.
And if the person using your
app thinks they're tappable
and they try tapping and nothing
happens, they're going to assume
that your app is broken.
So if you have a
situation like this,
you are much better off
using separator lines
to group things together,
just like we do in Stocks.
They demonstrate which
items are related,
and they'll also
help your eye track
across that horizontal list.
So make sure your
buttons look like buttons,
and make sure your
noninteractive content doesn't.
Which brings me to
the next item,
which is inadequate tap targets.
Now, knowing what is
interactive is a start,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, knowing what is
interactive is a start,
but if people can't
easily tap those things,
you still have a
usability problem.
Designing for Touch is
critically important
on the Apple Watch, especially
since someone might be using
your app while they are
in motion.
So something like this might
seem usable when you are
in Photoshop or in Sketch.
You are sitting nice and
stable in your office chair,
you've got a nice big
monitor at your desk.
And even in the simulator
when you are using your
mouse, this seems very easy.
But once you get
it on the Watch,
it's going to be a problem
to hit those tap targets
if they aren't adequately sized.
Scrolling is so easy
on the Watch.
You've got the Crown.
It's easy to swipe your finger.
So don't be afraid to let
things scroll out of view,
especially if that means
you can avoid truncation
and make your buttons
really easy to hit.
Now, on the Apple Watch, you
want your circular controls
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, on the Apple Watch, you
want your circular controls
to be at least 80 by 80 pixels
on the 42 millimeter or 75
by 75 on the 38 millimeter.
But there's nothing
wrong with going bigger.
That's what Chipotle did.
The primary action, the one
thing they want people to do
with their Watch app
is order a burrito,
so they've got this nice, big
button that does exactly that.
I mean, there's no
way you are going
to have trouble tapping
that button.
Now, when it comes to
the rectangular buttons,
you absolutely should not go
smaller than 53 pixels in height
on the 42 millimeter
or 50 pixels on the 38.
But we tend to go larger
everywhere throughout
the system.
Usually 80 pixels
in height or more.
Again, bigger is better.
And always be sure to extend
your buttons to that full width
of the canvas, even if
you have a short label,
because this is not going to
be as easy to tap as this is,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
because this is not going to
be as easy to tap as this is,
especially when you
are about to step
out the door to go for a walk.
Now, in some cases, you may
need to have two buttons side
by side, and this will still
work, but you are going to have
to find really short
text labels.
And three side by side with text
is really not a good option,
even with the shortest words.
Now, if you have individual
numbers or single characters
or icons, you can get away with
putting three side by side,
but they're still going to
be really close together,
especially on the
smaller-size watch,
and this often gives people
trouble tapping accurately.
Definitely don't
go more than three.
It's highly unlikely that
more than three buttons side
by side is going to be usable,
and that will just
frustrate people.
So be generous with
your tap targets
because this is the one time
you want to make it easy
for someone to push
your buttons.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for someone to push
your buttons.
It's Friday afternoon.
We are going for bad puns.
[Laughter] Next I'd like to
talk a little about legibility
because it is so
hard to use an app
if you can't actually read the
content it's displaying to you,
and when you are looking at
fonts in Photoshop or Sketch
or even the simulator, it's
easy to get a false sense
of how legible they are.
Again, you are sitting
at your desk,
you've got that nice big
display, you are probably
in some bright office lighting.
Something like this
might look totally fine.
But then once you
get it on the Watch,
it's going to look
more like this.
That's not legible.
Not at a glance,
at arm's distance
when you are moving on a train.
Larger type is going
to be easier to read.
And you don't just want to
look at this in Photoshop
or Sketch or the simulator.
You really need to look at your
apps in context on your wrist.
You need to make sure the most
important content is legible
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You need to make sure the most
important content is legible
when the person's
going to be needing it.
Can you tell the important
information as you are rushing
out the door to catch a bus?
Or while you are
actively doing crunches?
How about if you are outside on
a sunny day actively running?
People need to quickly
be able to glance
and see the information
that they are looking for.
Now, to optimize legibility,
I strongly encourage you
to use SF Compact, the
system font for Apple Watch.
Custom fonts are
able to be used,
but even at reasonable sizes,
thinner fonts just aren't going
to be as legible as
San Francisco is.
And San Francisco was
specifically designed
to be the most legible font
for digital display
that we can make.
And I could go on and on
about all the care and detail
that went into crafting this
typeface, but it's better
if you hear it from
the type team directly,
and if you didn't
see the session
that was right before this one,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I highly recommend
checking out the video.
It's really fantastic insight
into everything that went
into that typeface creation.
Now, the best way to
use the system font is
to use the system type styles
so that you can take
advantage of Dynamic Type.
Dynamic Type scales when
people adjust their preferred
reading size.
Now, if someone changes
their preferred reading size
and your app doesn't adjust
to match that preference,
they are either going to
be disappointed, or worse,
they may not be able
to use your app at all.
Implementing Dynamic
Type is straightforward.
You just need to use one
of the five text styles
that we have here.
And then for each text
setting that someone specifies,
the system will adjust
a number of properties
to ensure optimal legibility
and typographic integrity.
We adjust the size.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We adjust the size.
We also adjust the leading.
So that's the vertical space
between the lines of text.
And we adjust the tracking,
which is the space
between the letters.
And if you are using a
custom font, you will have
to handle all of these
sizing adjustments manually.
Now, like I said, we do have
five styles, Headline, Body,
Caption 1, Caption
2, and Footnote.
It's called Footnote
for a reason.
Don't be tempted to use
that for every piece of text
in your app just because
it's the small one.
Bigger is better when
it comes to everything
on the Watch, especially fonts.
Now, as Mike was saying
earlier, we really strive
to blur the lines between
the hardware and the software
when it comes to Apple Watch,
and nothing wrecks that faster
than gratuitously
bright background colors
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
than gratuitously
bright background colors
and unnecessary padding.
Suddenly the screen feels tiny,
and everything is
cramped into the center.
You are already dealing
with a small screen.
You need to use every precious
pixel of that for your content.
Don't waste it on padding.
And bright backgrounds are
the worst because the majority
of the platform is on black, so
you are going to get this blast
of color, and you can't
change the background color
of the status bar, so it's
always going to be black,
which means that your
content area is going
to look even smaller.
And I also see a lot of
people putting photos
in the background just to
kind of jazz up their app,
and while this can be done
well, more often than not,
it's a distraction
from the content.
It increases your file size
because you need more images,
which affects your launch times,
like Mike was talking about,
and it makes the
text harder to read.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and it makes the
text harder to read.
Again, you are dealing
with these incredibly
short interaction times,
so you want to eliminate
any friction
to interaction that you can.
Fractions of seconds have
never been so valuable
as they are on the Watch.
And while this lack of padding
is very uncomfortable to look
at in Photoshop, it does make
me cringe, everything is going
to be great when you
get it to the Watch
because of that hardware bezel.
The bezel is the
illusion of padding.
So this means you don't
need to add any in.
You can use all of the screen
real estate for content
and controls, and you
will have less truncation
and text wrapping that way.
And like I mentioned
a few minutes ago,
buttons that go edge to edge are
going to be much easier to tap.
If your app has a
black background,
it's going to blend seamlessly
into that bezel and feel
at home on the hardware.
It will be so much
easier for people to focus
on your content of your app.
But this doesn't mean you
have to make your app boring.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But this doesn't mean you
have to make your app boring.
There are so many ways
to carry over branding
and add personality without
relying on a colored background.
I've got a few great
examples for you.
Hailo is one, a popular
taxi app in the UK.
They have this recognizable
bright yellow color
and cheery car icon you see
throughout all of their app.
Citymapper relies on their green
color for branding recognition.
They have the Citymapper
face that they use
as loading graphics,
but most importantly,
they carry over their
cheeky sense of humor
that they are known for.
Next time you guys need
directions someplace,
I highly recommend checking
out the teleport option.
Rules! is a really
fun memory game,
and they took the
background texture
that they use throughout their
iPhone app, and they've turned
that into the button
texture here on Apple Watch,
and they also have these
really adorable characters
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and they also have these
really adorable characters
and charming animations,
so there's no way
that you could call
this app boring
or confuse it with
some other app.
So there's no need to do
anything like this when you have
so many better options
available to you.
So avoid those bright
backgrounds for embellishment,
and never inset your content.
Let the hardware bezel
take care of that for you.
But really, none of
these things matter
if people can't find your
app in the first place.
Now, unlike iOS, Apple
Watch icons aren't labeled.
So it's especially important
that people can find your
app just from the icon.
And as you've undoubtedly
noticed,
the Watch App icons are
circular and much, much smaller.
So that can present some
design challenges as well.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So that can present some
design challenges as well.
Now, most of these Watch App
icons would be familiar to you
if you have their iPhone
apps on your phone.
Making an exact match
of your Apple Watch icon
to your iOS icon is the best way
to help people find
it on the Watch.
Citymapper and Nike+ Running
and Procreate all directly
translated their App Icons
for the Apple Watch, and that's
because they already
had very simple shapes
that would read well in
that circular format.
But I know it's not
always that easy,
so I have some techniques
you can try if you need
to make modifications to get
your App icon to read well
in a small circle and
still be recognizable.
The first thing to do, really,
is just simplify as
much as possible.
So what can be removed
and still be recognizable
as your brand in your app?
Start with text.
Text is going to be particularly
tough at such small sizes.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Text is going to be particularly
tough at such small sizes.
So can you eliminate
it altogether?
That's what Yelp did.
Their burst icon and their
signature red color is enough
to make the app recognizable.
So start by removing the text,
or if you absolutely can't,
look for an abbreviation.
And if you have a lot
of detail in your icon,
consider simplifying it because
that will help it be much easier
to read at those small sizes.
Take the Twitterific bird,
which many of us recognize.
Just scaling it down and masking
it into a circle wasn't going
to work very well
on the Apple Watch.
The white space becomes awkward,
and the bird is just not
as recognizable this way.
So the Iconfactory team
redrew the bird to work better
in the small circular format.
Now he is facing you dead on,
and a lot of the features have
been simplified or removed.
It's no longer got nostrils
on the beak, and the pupils
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It's no longer got nostrils
on the beak, and the pupils
and the eyebrows are much
simpler graphically rendered.
Complex shapes with a lot of
detail will be harder it see
at small sizes, so do
everything you can to simplify.
Now, unless you have a strong
justification for moving away
from your current color palette,
you want to retain your
current color scheme
and overall visual style.
Color is a very strong
branding element,
and that will be very important
in helping people
find your App icon.
What if messages were
suddenly a different color?
You would probably think this
is a different app altogether,
or a beta version,
or a trial version.
So here you can see how
Fanatee simplified the App icon
for their game, Letter Zap.
They removed the text, which
would have been impossible
to read at the small
size on the Watch,
and enlarged the lightning
bolt, but most importantly,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and enlarged the lightning
bolt, but most importantly,
they retained that green
and gold color scheme,
which is what makes
it so recognizable.
So even though it might seem
scary to remove text or change
that icon that you have
been using for so long,
as long as you retain the
overall color and visual style
of your App icon, it's still
going to be recognizable.
Now, as Mike said
earlier, it is not a goal
to offer all the
functionality of your iPhone app
onto the Watch, so sometimes
using an identical App icon may
not be appropriate.
Your Watch app might offer
complementary functions
to your iPhone, so maybe a
complementary Watch App icon
concept might be better.
As we were talking about
earlier, the Camera app
on the iPhone offers a
ton of functionality.
You can take pictures,
edit them, share them.
But on the Watch, it
really just acts as a remote
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But on the Watch, it
really just acts as a remote
for the shutter button.
So we could have taken this App
icon and just put it in a circle
and called it done, but
it didn't feel right.
Instead, we came up with
a complementary concept.
It's still a recognizable Camera
icon, but we've simplified some
of the texture, retained
the color scheme,
and really emphasized
the shutter button
because that's what
this app does for you.
It presses the shutter button.
Another great example
of this is Sky Guide.
Now, masking their icon
into a circle just
doesn't read very well.
The composition is off, and
it doesn't exactly feel right
because of what the
app does for you.
On the iPhone, Sky Guide is all
about telling you,
What am I looking at?
What am I seeing
right now in the sky?
But on the Watch, it's
alerting you when there's
about to be an event
in your area,
like the International
Space Station might be
about to fly overhead.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
about to fly overhead.
So they came up with a
complementary concept
for their App icon, and
it looks great in a circle
and implies an astronomical
event.
But because they're using
similar color scheme
and visual style, the
relationship is very clear.
So if you are struggling
how to adapt your iOS icon
for Apple Watch, try
some of these approaches.
Because none of these Apple
Watch icons are literally the
same as their iOS counterparts,
but the resemblance is clear,
and as a result, the
apps are easy to find.
And as I've said many times, it
is not necessary for your Watch
and iOS icons to be identical
twins, but you do want them
to look like siblings.
So that takes us to the end of
our list, and as you're working
on your Watch apps, I hope this
will be a handy tool for you
so you can avoid some of those
common usability pitfalls.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
so you can avoid some of those
common usability pitfalls.
It really has been
amazing for us
to see how many great Watch
apps are out there already,
and we're so excited to
see what you guys come
up with for watchOS 2.
We had a ton of great
design sessions this week,
and the WatchKit Tips
and Tricks, again,
from this morning was
particularly fantastic.
And loads of information online,
especially the Designing
Great Apps page.
It has been a tremendous week.
I hope you guys have had
as much fun as we have.
There's still a few
more hours of labs left,
so go take full advantage
of that,
and we'll see you next year.
Thank you.
[Applause]