Tip:
Highlight text to annotate it
X
ROMAN NURIK: Hello and welcome to Android Design in Action.
I'm your host, Roman Nurik.
ADAM KOCH: Hey, guys.
My name's Adam Koch.
NICK BUTCHER: And, hi, I'm Nick Butcher.
ROMAN NURIK: And today, in our special episode of Android
Design in Action-- I feel like I say special episode every week,
but--
ADAM KOCH: That's because it is a special episode every week.
ROMAN NURIK: --yeah, I guess.
But this week, it's actually a very special episode.
We're going to be talking about what's
new in Android 4.4 KitKat, which was just recently announced.
We're going to talk through a couple of specific changes,
a couple of new design guidelines, updates
that all designers should be aware of when
planning for Android 4.4 KitKat.
So, without further ado, let's jump into the content.
So the very first thing we should probably talk about
is the new Nexus 5.
As with every platform release for Android,
there's usually a lead device, as we call it, I guess,
that comes out.
And it's kind of the showcase device for that platform
release.
I think for Android 4.2, it was the-- what was it,
the Nexus 4 or the Nexus 10-- I forget already.
And then for Android 4.3, it was the Nexus 7, 2013 edition.
But anyway, so for Android 4.4, it's the Nexus 5.
And the Nexus 5, as you might imagine,
is about a five inch device.
I think it's like something like 4.95 inches diagonally.
But here's some of the interesting characteristics
that you don't really get from the spec sheet, if you will.
These are characteristics that are
very important for designers.
So the first is that it's 5 inches, so it's a phone.
It's very obviously a phone, not really a tablet at all.
But next, I think is a very important point here,
is the screen resolution in density-independent pixels.
So, as most of you know, anytime you're designing layouts
or things like that, you should really
be thinking in terms of density-independent pixels,
rather than just regular pixel units,
because that more accurately represents
the size of the device, which is very important,
obviously, for layout purposes.
So the screen size of the Nexus 5 is 640 by 360 dp.
And that's actually the same exact screen
size in dp as the Galaxy Nexus.
It's a little more narrow than the Nexus 4,
but that's kind of the screen size there.
And then the last bit of information
here is the logical density of the device.
Now the screen itself is about 440 points per inch,
or dots per inch.
But the logical density, as you guys probably know,
we actually use density buckets.
The logical density of the device is XXHDPI, or 480 dpi.
So, if you're creating assets now,
if you're creating assets for your apps,
you should definitely start thinking about--
and actually, if you haven't already been thinking about it
because of other devices like the Galaxy S4, or the HTC One,
you should definitely start thinking about XXHDPI,
as the highest density assets.
So before we move on, anything else you guys
want to say about the Nexus 5?
ADAM KOCH: Nope, not really.
It's a great device.
ROMAN NURIK: Yeah, and--
NICK BUTCHER: Yeah, the screen is incredibly crisp.
ROMAN NURIK: Yeah, it's pretty amazing.
Reading text on the screen is just
a really, really great experience.
It's beautiful.
Here's the Nexus.
We have a couple of Nexus 5's, but here it is.
I'm sure you guys will see in stores and all that, whatever.
Anyway, let's move on to branding.
Nick, do you want to talk about branding?
NICK BUTCHER: Yeah, absolutely.
So one of the changes in KitKat is
we've really tried to move the system
UI into a more kind of neutral tone.
So what I mean by that is in prior releases of Android,
we often used a very kind of strong blue accent color, which
you might have seen in the status bar
where the notification icons go-- so the signal
strength, and battery, and so forth--
as well as the default kind of pressed state color.
Whenever you touch on any item, or radio button,
check boxes, and so forth, they would
have this very high contrast blue.
So the problem with that was that it could very well
clash with the branding and the coloring
which you were trying to bring to your app's personality.
So in Android 4.4, we've really toned back this color palette
that the OS uses in order to let the applications stand out
and show their own personalities.
So the OS really does get out the way
and doesn't impose its own personality
within your application.
And so you'll see this throughout the application
in the notification icon scheme, changing
to this muted gray and white color, as well as
the change in the default touch highlight states.
So, as before, the idea of this is really
to allow you to bring your own personality to the app.
So as we've called out here on the slide,
there's some tools out there, such
as android.holo-colors.com, which will help you to marry
the Holo digital theme, the look and feel of the buttons
and check boxes and so forth, with your own brand accent
colors.
ROMAN NURIK: I'm having trouble zooming for some reason.
But one of the things that we should probably mention
is that there's a new section in the design guide called
the Your Branding section.
I think it's under /design/style.
And it calls out specifically things
that you should keep in mind.
For example, using your brand accent colors
rather than using the default Holo blue
everywhere-- use your brand accent colors.
One thing, I guess, that is important to note here
is that this has been around for awhile.
The guidance has always been to try
to customize, to try to kind of find the right balance visually
between your brand and Holo.
And color is one of the best ways to introduce your brand.
So now we're just formalizing that
in the design guide in this Your Branding section.
So there's two examples here, I think, in the guide.
The first is Google Wallet, using the Google blue,
red, yellow, and green colors throughout the UI
to add some flourishes, as well as the Google Play Music
example, which was a very good example of branding,
where you see orange basically everywhere replacing
stock blue.
So as part of this new Your Branding section,
at the very bottom, you'll also notice the section on icons.
And specifically, it talks about the distinction
between visual styling and iconography,
I guess the actual glyphs, or the meanings of the icons.
So basically, just to summarize this point-- here
at the bottom, it basically says when
you're coming from other platforms,
or when you have an existing visual style for your icons,
make sure that if there's something in the Android icon
pallet that is universal-- for example, Sharing,
or Refresh, or things like that-- make sure that you apply
your visual style to Android's iconography.
So use the object or the actual icon from Android's palette,
but apply your visual styling.
So here's an example.
So let's say you have these three icons,
and you have Upload, View on Web, and Share.
So iOS7 recently introduced this new visual styling
for that platform where they basically
have outlines as the primary motif,
right, throughout-- each icon, everything
is basically just an outline.
So here are some of the icons you may build for, say, iOS7.
And they have a new Share icon.
It looks like this.
But when you're taking this to Android,
make sure that you don't just blindly copy those same icons.
That you apply-- whatever visual styling you deem necessary
for your app, or you deem fit for your app,
let's say in this case again, outlines, but still use
Android's actual icons.
So here's the Android Share icon.
This is just the example of the Android Share
icon with the outline motif applied.
So this section of the Your Branding Design Guide pattern,
or Style section, really just formalizes that.
Just make sure that you are applying this,
you're not just blindly copying the exact PNG assets
across platforms.
And if your styling, if your visual style is not outlines,
if it's something else-- if it involves,
you know, 3D effects or whatever, if that's your thing,
then that's fine as long as you maintain Android's iconography.
All right, so let's move on.
Actually, real quick, just to drive the point home--
so you wouldn't use something like the top right
here on Android for sharing, you'd
use something like the bottom right here.
Moving on, touch feedback--
ADAM KOCH: So in Android 4.4 KitKat,
I think as Nick mentioned before, touch feedback has more
of a neutral color applied to it.
So when you look at the system UI widgets,
you'll notice now that there's this much more neutral color,
as opposed to this Holo blue that you've become used to.
So in this particular case, we see a button,
the standard Android widget for a button.
And there's a 10% opaque black overlay applied accordingly.
And when it comes to implementing your own touch
feedback, you should follow a similar guideline,
so you should have a more subtle and neutral color tone.
And, of course, if you're adapting for your brand,
and you have a color that matches your brand,
you could also apply that when creating your touch feedback.
We talked about touch feedback on images the other week,
and the same kind of applies there.
You can also go with the more neutral, 10% opaque
black overlay, or you can apply your brand colors accordingly.
ROMAN NURIK: So basically, anytime
you have touch feedback in your app,
try avoid the stock default blue.
And actually, the default blue, for developers out there,
if you just use selectable item background,
that is no longer blue.
It's actually kind of like a light grey at about 10% or 20%
opacity.
But the idea is that it should be more subtle.
And anytime you have touch feedback, or basically
any widget in your app, make sure
that it's not using the stock blue,
unless blue is your brand accent color.
Make sure that it's either something very neutral,
like a gray scale tone or something like that,
or your brand accent setting and stuff, main thing there.
Moving on to full screen-- so this
is actually a new guideline.
It's under developer.android.com/design/patterns,
and this guideline talks about when and how you should present
full screen UIs to your users.
So there's two modes, two, I guess,
approaches that they talk about, and they're
called Lean Back and Immersive.
So Lean Back, you guys have already seen before.
If you open up YouTube and you start playing a video,
the system UI-- the navigation bar, the thing with Back, Home,
and Recent-- and the status bar, the thing with your status
icons, and your clock, and all that, those fade away.
And the full screen is left for the video.
It's a truly immersive video playback UI.
Now, as soon as you touch the screen,
the navigation bar-- the thing with Back, Home, and Recent--
and the status bar fade in.
Now this is called Lean Back because, generally,
if you're watching a video, you're not really
interacting with the screen, right.
You're not doing stuff in the middle of the screen.
You're just sitting back and watching the video.
And so as soon as you touch the screen, the bars appear.
That basically prevents the app from doing anything else
with the screen.
Now, I guess using the or--
ADAM KOCH: Interacting with the screen.
ROMAN NURIK: --yes, exactly.
With Immersive mode-- this is something
that's new in Android 4.4 KitKat.
And Immersive mode basically, again, hides the bars,
but it also allows the user to interact
with the middle of the screen.
And Immersive mode is more suitable for things like games,
where you actually need to interact with the screen,
or book readers, where you're kind of flipping between pages.
Now the reason that the Lean Back mode--
as soon as you touch the screen it
shows the bars-- the reason for that
is really because those bars are critical.
You know, not having access, or losing access
to Back, Home, or Recent, it can fundamentally
break your experience or your usage of the device.
And so that's why it consumes that first touch
and shows them automatically.
In Immersive mode, the way in which a user can show the bars
is by swiping down from the top of the screen,
or swiping up from the bottom of the screen.
And every time-- actually, I guess
we'll look at this in a second-- anytime you hide
the bars in Immersive mode, you basically see this.
Actually no, not any time-- the first time in a single,
in a specific app, that you hide the bars,
they'll see this pop-up overlay type thing.
And it'll basically say swipe down
from the top of the screen to show access to your Back, Home,
and Recents, and stuff like that.
So as soon as you swipe down, you'll
actually see your bars again.
But the idea is that now, in this Immersive mode,
you can use touch events and everything, all
in the middle of the screen, without showing the Back, Home,
and Recent.
And it's really, really ideal for things like book readers
and games and things like that.
So we have a full-- we're not going to talk in too much more
detail on this--
NICK BUTCHER: We could demo it.
ROMAN NURIK: Yeah, I guess we could demo it.
So--
NICK BUTCHER: Sign us out.
ROMAN NURIK: --we could swipe.
That's not actually going to work
because I think we're in a special mode in our Nexus 10.
But the point here is that we have-- so this is a new mode.
It's called Immersive mode.
We're going to have a DevByte released on this very shortly.
And the DevByte is basically going
to explain how you actually use these APIs.
It's actually very, very simple.
It's not a very complicated API to use,
but it's very, very powerful.
So, long story short, if you're building a game, or a book
reader, or a magazine reader, anything like that,
make sure to check out Immersive mode in KitKat.
NICK BUTCHER: And you have full control
of exiting Immersive mode as well.
While the system provides those gestures, the swipe up
from the bottom or down from the top,
but you can also control that.
So, for example, Play Books takes over every single pixel,
so when you're reading, you get this fully immersive mode.
But if you tap a gesture which they always
use to show the system Chrome, so the action bar comes back
and the text controls come back.
But they've also listened to that's
happened and restored the system UI as well.
So you have full control over this.
ROMAN NURIK: Exactly.
All right, let's move on.
Translucent bars-- is that Nick?
Nick, you want to talk about translucent bars?
NICK BUTCHER: Sure.
So a slight variation upon this theme is translucent bars.
So this is still showing the system Chromes
as showing the status bar and the navigation bar
at the bottom, but allowing your application
to draw to that same real estate with minimal background
protection applied over the top.
So this is used to great effect by the new home screen,
the new launcher application on the Nexus 5,
which allows you to show the wallpaper,
like from edge to edge at the screen, while still preserving
those system functions.
And your application can do the same thing.
So if we go on to the next slide to take a look at a sample
application of the kind of thing you could build.
So here's an application which is
using Maps as the main UI element.
And here you can see that we're extending the content
all the way behind the system bars.
So it really gives you this immersive feel,
that the map is the entirety of the canvas you're drawing to,
and you just have this minimal background protection applied.
And you can control what is drawn behind the system bars.
ROMAN NURIK: So two points I wanted to make [INAUDIBLE],
go ahead.
NICK BUTCHER: I was going to say, as a slight-- not new
in Android 4.4, but in a very recent update to the Google
Play Services Library, you now have the ability
to do more with Maps, have a little bit more control
over the stock UI Maps Chrome.
So that's things like here, we can
see the Locate Me, and the Zoom In and Out button, as well
as the orientation compass point.
You can now set padding on those controls
so that if you do have system UIs, such as the action
bar at the top, and the system bar, and buttons
at the bottom, or even your own controls overlaying the map,
you can now pad them in, so they will remain visible.
And despite your other Chrome on top of the map canvas.
ROMAN NURIK: So I guess my two points turned into one
point I want to make, because that was one of the points
I wanted to make.
One of the points I wanted to make
was the background, there will always be, like you said,
there is always some background protection.
I think in this first iteration, I guess there'll be a gradient.
So regardless of what's shown-- I guess, regardless
of what your app UI is, there will always
be a gradient, a subtle kind of black to transparent gradient
behind both the status bar and the navigation bar.
So just keep that in mind if you're
designing screens like this.
And also, another thing I wanted to mention
is we don't really have guidance on exactly how you
should use this yet.
So this is still, I'd say, in an exploratory phase.
One of the things that I know one of the engineers mentioned
was that you should try to avoid using action bars in this case.
I think that this translucent bars type of UI
is really designed more for like wallpapers or kind of wallpaper
type apps, apps that really go full bleed with the content.
So it's not really quite clear exactly how
you should use this yet with other UI Chrome.
But definitely, this is just one of our early explorations.
All right, let's move on to launcher icons.
ADAM KOCH: All right, so, for launcher icons,
hopefully you're already aware, they're
normally shown at 48 dp, a square of 48 dp.
Now on Nexus 5, due to the new launcher,
they're actually shown larger, actually about 25% larger,
or 60 dp.
And then because Nexus 5 is an XXHDPI device,
essentially, in order for the icons
to show at their crispest, you really
need to include an XXXHDPI, or 640dpi icon.
Yes, we really just said that.
[LAUGHTER]
ADAM KOCH: So the actual pixel size of that icon
is 192 pixels.
And this is somewhat similar to how tablets behaved previously
with their launcher.
They would actually show the icon slightly larger,
and so it needed to dip into the density bucket that's
one larger than the density of the actual device.
And so I guess our guidance here is
the icon is just so important.
It's such an important part of your application.
You should really be including an asset that
makes it look its best on all devices and all screen sizes.
And so that means, in this case, you
need to provide XXXHDPI icon for the launcher icon.
ROMAN NURIK: And so right now, this applies to Nexus 5,
since Nexus 5 has this new kind of launcher.
Be to imagine that other devices in the future
would potentially do something like this.
So basically, just get ahead of the game.
Start including the 640dpi icons.
And also, I mean, just to kind of, I guess,
talk about how this works with tablets, right.
If there was an XXHDPI tablet, then
you'd have to do this anyway.
It just happens to be that there's an XXHDPI phone that's
now using this tablet scaling behavior for launcher icons.
Let's move on to new gestures.
So these aren't exactly, I guess, new gestures,
but we're formalizing two new gestures in our design
guidelines.
So if you go to developer.android.com/design,
I think it's under Patterns, Gestures, I forgot.
But you'll see two new gestures.
The first is an expansion of double touch.
And the second is, I guess, double touch to drag.
So the expansion on double touch basically
says, if you're looking at a photo, right, I mean,
or something that's just zoom-able, double touch
to zoom it in.
If you're in something like Google Chrome,
like that, right, exactly-- if you're in something like Google
Chrome, or something else that has
bits and pieces of information laid out,
and you want to double touch on one of those bits
and pieces of information, basically what this is saying
is that you should zoom in to that content.
So if you're in Chrome and you double touch
on a column of text on a web page,
it'll actually zoom to fit that column of text.
So this basically says if you have any other types of,
or if you're building an app that
is similar in terms of what content it presents
and the layout in which it presents that content, this
is something that you should do.
So this may apply to things like magazines, or books,
or things like that.
The second, and this is a little more universally
applicable I'd say, is anytime you have double touch to zoom,
if you double touch and then drag up or down
with that same finger-- so it's like touch,
touch, drag up and down, that should basically also
be a zoom.
So rather than zooming in by a fixed amount, say, 50, or 2x,
or whatever it is, double touch and drag up and down
is kind of like a dynamic zoom.
So I think if you drag-- I forgot if it's drag up,
it's zoom in or zoom out-- but an example of this
is Google Maps.
So if you open up Google Maps right now--
and this has been around for quite some time--
if you open up Google Maps right now,
double touch, drag up and down, I think up will zoom in,
down will zoom out.
NICK BUTCHER: It's in Chrome as well,
and it's a great way because you can do,
similar to a pinching gesture, but you can do it one-handed.
So it's great.
ROMAN NURIK: Yeah, that's actually how I discovered it.
I was using Maps with one hand, and I was double
touching a lot, and then I accidentally stumbled upon it.
I was like, oh my god, this is the best thing ever.
But if you're building something like this,
then definitely use this.
I will say that we don't have sample code available just yet,
but I'll probably do an update to our Gestures training
class for this at some point.
NICK BUTCHER: No, the gesture detector in the Support
Library's being updated to support this.
ROMAN NURIK: Excellent, even better.
There you go.
NICK BUTCHER: We've written the code for you.
ROMAN NURIK: Awesome, so my change to the training class
will be one line of code or something like that.
Awesome, let's move on to screen recording.
NICK BUTCHER: So this is nothing to change
the way you have to design your applications,
but we've made it a lot easier to capture video
from the device.
So I think in previous shows we've
talked about having specialized hardware,
or certain devices which let you record the screen
output in order to create really high quality product videos.
But a new system feature in Android 4.4
called Screen Recording will let you do this
by a simple command.
So there's no on device UI that's actually doing this.
This is like a developer feature for producing
these videos ahead of time, rather than a run-time user
feature, as it were.
And so you simply execute this command written on screen,
and this will record up to 15 seconds of video
in full high definition, the full kind of screen resolution.
And then you can just use the adb pull commands in order
to get that video file off of the device
and onto your computer.
So a really easy way to record product videos.
And as a little pro tip-- if you go into the Settings, and then
Developer Settings section, and enable Show
Touches, as we have on this tablet here,
you get these white circles, which goes really well with it.
I'm doing a screen recording.
So you can produce high quality product videos
without having fingers in the way, and so forth.
ROMAN NURIK: I will say, I think we updated it to three minutes.
Or is it still 15 seconds?
I think at some point we made a change
to make it three minutes.
But it's either three minutes or 15 seconds.
One other thing we should--
NICK BUTCHER: Has that changed?
[LAUGHTER]
ROMAN NURIK: One other thing we should mention
is that what we're doing right here with our own setup here--
we're not using screen record.
Again, screen record is not meant for live screencasting.
It's really for recording video, and then post-processing,
or things like that.
So it's really good for things like your promotional video
on Google Play.
If you want to show a video of your app in use,
this will make it tons, tons easier.
All right, last but not least, scenes and transitions.
ADAM KOCH: Yes, so scenes and transitions--
so the animation framework in Android
gets some fantastic new additions in Android 4.4.
And we're calling them scenes and transitions.
So there are two parts to this.
The first is where you can essentially
define scenes within your UI.
This is sort of two different UI states for a particular screen.
And then you can have the system actually calculate
the animation to get from the first scene
to the second scene.
So this is, it's a really neat addition.
And the second part to this is you can actually go and modify
a particular view group.
So this is talking more on the developer side.
A view group is a collection of views
within a particular screen, and make changes to those,
and have the system animate those changes as well.
So it's definitely something to look
into if you want to get more involved inside the animation
side of Android.
For developers, there's the android.transition.trans--
[LAUGHTER]
ROMAN NURIK: Transition manager?
ADAM KOCH: --transitionmanager, that you should go look at
to get more information about this.
And if you're familiar with Keynote's "Magic Move"
animation, which let's you morph an object from one
portion of the screen into another,
it's very similar to that.
So just to give you an idea of how it works or how it looks.
ROMAN NURIK: Yeah, and I think that the big thing here
for designers is if you're talking to a developer
and you're like, hey, I want these animations,
these transitions to happen, and they're like,
oh, you know, I just can't do that, it's
going to take too long-- for earlier versions of Android,
it does require a bit of work.
It's definitely still doable.
But if you're running Android 4.4 or later,
I don't think there's an excuse anymore to not use this API.
The great thing about this API is that it's so simple.
I mean, the easiest form of this is one line of code.
It's basically just, I think it's
begin-delayed-transition or something like that.
And it basically says anytime you show, or hide, or resize,
or move things, automatically adjust their bounds,
or animate their bounds, or fade them in, or fade them out--
it's really awesome.
So I think that, for designers, make
sure that you press your developers to use
this new API if they have any sort of concerns
over the amount of time it would take
to implement certain transitions.
ADAM KOCH: And lastly, for developers, look for a DevByte
from our animation expert, Chet Haase,
which we live very shortly as well.
ROMAN NURIK: So that's it for what's
new in Android 4.4 KitKat from a design standpoint.
Watch out for all those DevBytes that we talked about
for developers.
And we're looking to create a whole bunch of design bites
on these topics as well, over the coming weeks
or months-- hopefully weeks.
So, yes, stay tuned for all that.
Anyway, so, see you next week, or the week after, or whatever.
As always, I'm Roman Nurik.
ADAM KOCH: See you later, guys.
Adam Koch here.
NICK BUTCHER: Bye from Nick Butcher.