Transcript
[ Music ]
[ Applause ]
>> With iOS 13, the way that we
design and build apps is going
to change in some subtle but
significant ways.
Dark Mode brings a new approach
to how we work with colors,
images, and text.
The new card-style sheets not
only present modal presentations
in a different way, but they
change how we interact with them
as well.
And the new contextual menu
control makes it easy to quickly
access contextually relevant
functionality with ease.
Now, between these three topics,
we've got a lot of ground to
cover, so let's dive in with
Dark Mode.
Now, last year we introduced
Dark Mode on macOS, and it was
pretty popular.
For many years, photo and video
apps have used dark interfaces
because they allow people to see
photos and videos with clarity.
Dark UIs are great for dark
lighting conditions; it's much
easier for our eyes to adjust
between a dark screen and the
world around us.
And, functional reasons aside,
some people just prefer dark
interfaces as a matter of
personal preference.
Dark Mode on iOS uses a fully
black background to provide
maximal contrast with text and
other foreground elements.
Black backgrounds blend in
seamlessly with the hardware
bezel to make your UI feel more
expansive and integrated with
the hardware itself.
In general, all of your apps
should support Dark Mode.
When the people using your app
have set their device to be in
Dark Mode, they'll expect your
app to change as well.
Now, supporting Dark Mode
involves moving towards the
updated iOS design system which
has been fully overhauled for
iOS 13.
Now, just so we're all on the
same page, "design system"
basically just means a set of
parts like colors, fonts, and
glyphs that work together in a
logical and consistent manor.
A rational -- excuse me -- and
consistent design system helps
people to learn and use apps
with ease.
By integrating with the iOS
design system, your app will
feel more familiar to people and
be more understandable.
Now, before we get into all of
the details, I'd like to share
some of the key design goals
that guided the design team's
efforts.
First and foremost, they wanted
iOS to remain familiar and
intuitive.
The iOS design system has
received a complete makeover but
the end result is still
recognizably iOS.
They sought to provide more
internal consistency.
All of the built-in apps were
redesigned to bring them into
alignment with each other, using
all of the components that we'll
be talking about with you today.
They also wanted the new design
system to include a range of
color options to help
successfully articulate
information hierarchy, to allow
the most important elements to
be the strongest and the less
important elements to recede.
They also put accessibility on
equal footing with these other
goals.
The new system fully supports
bold text and increased contrast
accessibility modes.
And, lastly, they wanted the new
design system to be simple,
straightforward, and easy to
implement.
All right, now let's get into
the specifics.
Color seems like the right place
to start.
Every app has a background, and
most apps have text and glyphs.
And some apps have separator
lines and grouping boxes to help
organize all of that content.
Now, when describing these
colors, we can naturally talk
about them by their values.
The text is black, the
background is white, etc., etc.
Now, as your interface gets a
little bit more complicated, the
length of that color palette
extends.
But that's not really an issue.
However, when you add support
for separate appearance, you now
have two parallel sets of colors
to keep in sync with each other
and manage.
At this point, it becomes
helpful to think about color in
a more abstract way.
This is where semantic colors
comes in.
A semantic color describes the
purpose of a color rather than
what its value is.
Because semantic colors are
extracted away from their exact
appearance, they can work both
-- they're dynamic.
So, a background color can be
black in Dark Mode and white in
Light Mode.
So instead of maintaining two
separate lists of colors for
Light and Dark Modes, you can
apply semantic colors from the
system palette to UI elements
and their appearance will
automatically adapt between
Light and Dark Modes, which is
pretty convenient.
iOS 13 includes a palette of
semantic colors for you to use.
Many of these colors have
primary, secondary, tertiary,
and quaternary values.
These variants are used to
express information hierarchy.
Label color has the most
contrast with the background, so
it's going to advance into the
foreground and grab your
attention and should be used for
primary elements like titles,
secondary for subtitles,
tertiary for placeholder text,
quaternary for disabled text.
The same basic principle applies
to background colors.
System background is a primary
background color, and it's pure
white in Light Mode and Pure
Black in Dark Mode.
Secondary and tertiary system
background colors allow you to
structure information
hierarchically.
There's also a parallel set of
background colors for grouped
table views.
Now, if you observe closely,
you'll note that the colors
aren't simply inverted between
Light and Dark Modes.
The table row backgrounds are
lighter in both.
There was a concerted effort to
select a palette of colors that
assured contrast while at the
same time keeping apps looking
similar between Light and Dark
Modes.
When you're designing for Dark
Mode, it's often helpful to
think about the lights as having
been dimmed rather than
everything being flipped inside
out.
The new system palette includes
fill colors and separator
colors.
All of the fill colors and one
of the separator colors are
semi-transparent, which helps
them to contrast well against
variable background colors.
The new palette includes six,
fully opaque gray values.
These colors are best used when
transparency would lead to
undesirable results.
So, for example, when drawing
intersecting grid lines,
overlapping semi-transparent
colors can create distracting
optical illusions.
And, if elements overlap, solid
colors are really helpful and
prevent things from looking
disabled or broken.
These colors are used throughout
the system for basically
everything, and we encourage you
to use them in your apps.
To get you started, you can
check out the full color palette
in the Apple Design Resources
and the Human Interface
Guidelines.
I'll have more information about
those at the end of the
presentation.
As before, we will continue to
provide tint colors for you to
use as your app's tint color.
These tint colors are dynamic,
meaning that they have variants
for Light and Dark Modes.
Each tint color has
high-contrast variants.
When they increase contrast,
accessibility setting is
enabled.
Tint colors get lighter in Dark
Mode and darker in Light Mode.
Now, if you opt to pick your own
tint color, try to select colors
that work well in both modes.
A color that works well in Light
Mode, though, might have
insufficient contrast in Dark
Mode, and vice versa.
Even when colors seem to you
like they're going to work well
in both modes, it's always best
to check your colors with an
online color contrast
calculator.
Now, because tint colors can be
dynamic, you can have two
slightly different colors for
Light and Dark Modes, and when
you're picking those colors, aim
for a contrast ratio of 4.5 to 1
or higher.
Strong color contrast improves
the accessibility and usability
of your apps.
The system palette should
basically have you covered for
most of your needs.
But, of course, you're going to
have to define your own colors
as well.
Perhaps you have user-selectable
label colors or status
indicators.
As with tint colors, any color
can be dynamic.
Given that the perception of
color is influenced by the
background that it's shown
against, you'll want to make
some adjustments to help keep
those color values looking
similar between modes or to make
sure that there's enough
contrast in both modes.
Now, all this time I've been
talking about Light and Dark
Modes, and as you may know,
that's a little bit of an
oversimplification.
There's actually two sets of
background colors that are
called "base" and "elevated."
As the names imply, these
background colors are about
layering interfaces.
When two light interfaces are
layered, a simple, diffuse drop
shadow is all you need to create
visual separation between the
two.
With dark interfaces, drop
shadows are slightly less
effective.
System background colors will
use the darker or base values
for background apps or
interfaces and the lighter,
elevated values for apps or
interfaces that are in the
foreground.
So take, for example, the
Contacts app.
It's using the base set of color
values when drawn on its own,
but when the same interface is
brought up in a modal
presentation in the phone app,
it uses the elevated background
colors.
Okay, let's look at a slightly
more complicated example.
Here's Mail running on an iPad.
On its own, Mail is drawn using
the base set of background
colors.
When we bring in Contacts in a
slide-over, we see that it's
being drawn with the elevated
set of background colors.
Now, the lighter appearance of
contacts helps it stand out from
Mail and advances it into the
foreground.
When Contacts is displayed side
by side in multitasking with
Mail, they are both drawn with
the elevated set of background
colors.
This helps provide contrast with
that splitter down the middle
and keeps the two apps from
blending together.
When we compose an email in
Mail, it comes up in a sheet.
This too is drawn with the
elevated background colors, but
the main app UI Mail looks a
little bit darker because modal
presentations draw an overlay
layer to dim their background
content and they cast a little
bit of a drop shadow.
Now, because background colors
change when your app is
elevated, you have to be mindful
that some of the darker colors
that you might use, even from
the system palette, may not
contrast well.
You always have to check your
designs when they're in elevated
state.
Again, semi-opaque fill and
separator colors are going to be
your best friends here.
They adapt gracefully between
base and elevated backgrounds.
Okay, moving on to materials.
Materials have been overhauled
and refined with iOS 13.
There are now four materials for
you to choose from with a range
of translucency levels: thick,
regular, thin, and ultra-thin.
These materials have been
designed to work well against a
variety of background contexts.
Their appearance will change
dynamically based on whether
someone is using your app in
Light or Dark Mode.
You can select which material
you want based on how much
separation you want from the
background, how much is most
appropriate.
The default material is regular,
and it's going to work well in
most circumstances.
But if you're presenting content
against this material that needs
a little bit more contrast, you
can use the thicker material.
For lighter-weight interactions,
maybe with simpler content, thin
and ultra-thin might be the
right way to go.
Which material is right for your
app just really depends on the
content that's being displayed
inside of it.
Speaking of which, light and
dark materials have an
accompanying set of vibrancy
values for labels, fills, and
separator colors.
Vibrancy is a visual affect
that's used throughout iOS and
other Apple platforms.
With system materials, it's
typically best to use vibrancy
rather than solid colors.
Because depending on the
background context, solid colors
can get really muddy and can
lead to some serious legibility
issues.
Vibrancy helps to maintain that
contrast regardless of what's in
the background.
The updated visual design system
for iOS also includes changes to
controls and bars.
Visual attributes like shape and
color have been brought into
greater alignment for more
internal consistency.
Controls are now drawn with
semantic colors so that they
gracefully adapt between Light
and Dark Modes.
If you use UIKit controls, you
get the benefits of all of this
for free.
If you spent time recreating
what UIKit gives you for free,
with custom controls, you may
want to, I don't know how to say
this, but stop doing that.
[ Laughter ]
[ Applause ]
Recreating what UIKit gives you
for free takes a lot of effort
and time, it's hard to do right,
and there's very little upside
for you.
But of course, custom controls
are often necessary.
UIKit does not provide
everything that you need.
For example, UIKit doesn't
provide a rating indicator.
So, when you're making custom
controls, you should use the
system palette so that you don't
have to do two different color
treatments for Light and Dark
Mode.
Navigation bars have also been
updated.
By default, they're now drawn
for large titles without the
background and shadow.
This allows the title to connect
seamlessly with the content that
it's labeling.
When content scrolls underneath
the navigation bar, the
background and shadow will fade
back in.
Now, large title bars,
navigation bars work especially
well with this visual treatment,
but it can be used for default
navigation bars as well.
So, in the Settings app, for
example, the master view's
navigation bar uses a large
title and it has no background
or shadow.
The standard navigation bar is
stylized to match.
Now, while a seamless navigation
bar looks great, it's not always
going to be appropriate.
That background is completely
transparent, so if you've tucked
anything underneath the
navigation bar, it's going to
show right through, and it's
probably not going to look very
good so don't use a treatment
then.
And if you have a really dense
interface with a lot of controls
and navigation bar next to the
content area, the clear visual
delineation that's provided by
that shadow can be really
helpful.
Okay. So, before we move on,
there's one more big feature
that I'd like to discuss with
you related to Dark Mode.
iOS has always provided a
handful of symbols for things
like table rows and toolbars.
When shown against a dark
background, the previous set of
symbols did not hold up very
well; they often looked a little
too thin.
So, the design team redesigned
all of the symbols in this
design system.
And what's really cool, as many
of you may know already, we're
making all of those glyphs
available for you to use with SF
Symbols.
SF Symbols includes over 1500
symbols.
And this isn't just a new set of
glyphs; this represents a
completely new way to think
about and design glyphs.
As the name suggests, SF Symbols
are designed to match the visual
design characteristics of San
Francisco, the system font for
iOS and other Apple platforms.
They can literally be typed out
so that they can be displayed
inline with text.
They have imbedded baseline
values to assure proper vertical
alignment relative to text.
And every SF symbol offers
small, medium and large-scale
variants relative to the current
size for different contexts.
And every symbol comes in nine
weights just like the SF font.
Because they're vector based, SF
Symbols can scale with text when
used with dynamic type.
And by offering multiple
weights, SF Symbols will become
bolder when the bold text
accessibility setting is
enabled.
Now, when designing comps of
your app, you can use the new SF
Symbols app to browse or search
for symbols, copy the ones that
you want to use, go over to your
design comp, and just paste them
in to a text layer.
The updated iOS Apple Design
Resources for Sketch is already
set up to work with symbols.
To swap out the symbols for this
tab bar, for example, you just
select the tab bar, go to the
inspector, and paste it in to an
override for the buttons.
I've been playing with this
feature for a few months now,
and I have to tell you, it's
totally game-changing.
Now, if the set of symbols that
we provide, 1500, isn't enough,
you can actually generate a
template in SVG, go into
Illustrator or Sketch and make
modifications to design your own
and get all the same benefits
that I just described.
It's really cool.
Okay. Now moving on to modal
presentations.
Modal presentations are often
called sheets because of the way
they slide up over the screen.
This animation informs people
that they've shifted from one
mode to another or into a new
modality of your app.
With iOS 13, sheets have a new
card-like appearance that's used
throughout the system.
This style is now the default.
And the benefit of this style is
that it gives this little peek
of what's in the background,
which is a helpful reminder that
there's a different UI that
accommodates a different task or
mode of the app that's still in
the background.
With the full-screen modal
sheet, you can sometimes forget
what you were doing before.
Card-style modal sheets can be
dismissed by swiping down
anywhere on the screen.
And that dismiss gesture is
often going to be easier than
tapping a button in the
navigation bar.
As with swiping to go back,
pulling down to dismiss
facilitates one-handed
operation, which is particularly
convenient on devices with
larger displays.
Now, you may wonder, "How does
this work with scrolling?"
When the content area has been
scrolled, swiping down will
scroll it back to the top.
When scrolled all the way back
to the top, continuing to swipe
will dismiss the modal
presentation.
But at any time, you can pull
down from the top edge of the
card to dismiss.
Now, if this gesture is
problematic for any reason, like
you have a control in the
content area that works with
vertical swiping, it can be
prevented.
It can also be prevented when
there's a mandatory decision
that's required in the modal
presentation itself.
So, for example, here we either
need to cancel or add.
And if we pull down, it will
just bounce right back.
In cases where people must make
a decision before leaving a
modal context, you can prevent
that dismiss gesture and display
an action sheet asking people
how they wish to proceed, which
is actually pretty convenient.
Now, in case you're wondering,
all of what I just described
here doesn't mean that you don't
need to have buttons for modal
cards anymore.
Buttons are critical for letting
people know that they can close
the modal.
Buttons are also necessary for
accessibility reasons.
And people might not be familiar
with using the gesture yet or
don't want to.
And when the content area's been
scrolled down, tapping a button
might actually be more
convenient.
Similarly, seeing negative and
affirmative action pairs at the
top of the screen lets people
know what choices they have to
act within this modal
presentation, what actions they
can take.
Now, we think the new card style
is pretty great, which is why
it's now the default for iOS.
But they're not always
appropriate.
For some tasks, like editing a
picture or marking up a
screenshot, you really want to
maximize screen space and
minimize visual distraction.
For workflows like this, you
should use the optional
full-screen presentation.
And one final comment about
modal presentations: modals are
for switching modes.
Don't use them just because you
like the animation or the visual
style of them.
So, a good example of modal
sheet use is from Calendar.
Calendar has two primary modes:
viewing events in a grid or list
and then creating or editing
events.
Viewing your calendar involves
scanning all the events that are
in your calendar and then
selecting them to see detail.
Since we're still in the viewing
mode, a child view is used for
displaying those details.
As the name suggests, a child is
an extension of the parent view.
A child view should be a
continuation of the task or
workflow that was started in
that parent view.
When creating or editing an
event, a modal sheet signals to
the people who are using
Calendar that they've switched
into a distinct and new
workflow.
Okay. Now for our final iOS
design topic, and that's
contextual menus.
With the introduction of 3D
Touch a few years ago came a new
interaction called Peek and Pop.
Peek and Pop was primarily about
getting a larger preview of
content.
If available, actions could be
accessed by swiping that preview
upwards.
Contextual menu shifts things
around a bit and puts the focus
on actions.
Actions are presented
immediately.
Contextual menus also work on
all devices.
Peek and Pop only worked with 3D
Touch, so it wasn't available on
any iPads and some iPhones.
While 3D Touch makes contextual
menus appear more quickly, the
gesture to get a contextual menu
is just tap and hold, and you
can do that on any touch device.
Contextual menus are comprised
of two parts: there's a menu of
commands that can be performed
on an item or selection, and an
optional preview of the selected
item that'll be affected.
That preview can be a helpful
reminder of what item will be
affected by those menu of
commands.
The exact appearance of
contextual menus will change
based on device size and
orientation.
On iPhone, the preview and phone
are stacked, in portrait, and
the same thing on iPad when
there's three commands or fewer.
Otherwise, the menu and preview
are displayed side by side.
Contextual menus will appear
directly above the object they
affect or as close to it as
possible.
As with macOS contextual menus,
you can choose the order of menu
commands.
It's best to put the most
frequently used or accessed
commands at the top so that
they're easier to access.
Otherwise, you should group
commands because they're heavily
related with each other.
So, it totally makes sense that
cut, copy, and paste are near
each other.
You can also use separators to
create visually distinct groups.
And iOS contextual menus can be
hierarchical, meaning that some
of these options can lead to a
secondary submenu.
Contextual menus on iOS also
include glyphs to help people
find what they're looking for
more quickly, and they allow you
to warn people about destructive
actions by labeling them in red.
You should try to add contextual
menus to every object in your
app.
Think about macOS.
You expect every object in every
app to have a contextual menu.
They're great way to learn what
actions can be performed on an
object.
And the more iOS apps add
contextual menus, the more
people will expect every app to
support contextual menus,
including yours.
Okay, one final comment about
contextual menus.
The actions they contain should
still be available somewhere
else in your main interface.
Contextual menus are powerful
and convenient, but people might
not always think to access them.
Now, I can't wait to see what
you do with Dark Mode, updated
modal presentations and the new
contextual menu.
For more information and
resources, go to
developer.apple.com/design.
There you can find the updated
SF font, the SF Symbols app, and
the updated iOS Design Resources
for Sketch.
The Adobe Photoshop and Adobe XD
resources will be coming later
this summer.
Also, check out the Apple Human
Interface Guidelines for more
details about everything that I
covered today.
Okay. Thank you for your time.
[ Applause ]