Android Design in Action: Sleep Monitors and Backward Compatibility

ROMAN NURIK: Hello again, and welcome to
Android Design in Action.
I'm Roman Nurik.
ADAM KOCH: Adam Koch.
NICK BUTCHER: And Nick Butcher.
ROMAN NURIK: And today we're going to talk about a sleep
monitor app and backward compatibility.
We have a lot of content to get through today, so we're
just going to get started with sleep monitors.
So the app that we decided to look at today
was Sleep as Android.
It's called Sleep as Android.
This is one of the apps that was reviewed on the App Clinic
last Friday by Reto Meier.
And Nick took a look at this app in much detail.
And Nick, do you want to jump into your
thoughts on Sleep as Android?
NICK BUTCHER: Sure.
So Sleep as Android is an application that monitors your
sleep and lets you set an alarm, so it will wake you up
at an opportune time when you're in a very kind of light
sleep cycle.
It's a very detailed app.
If you take a look at it, it offers a whole ton of
functionality and configuration options.
And you can see that the author is very responsive to
the community.
He's put out something like 15 updates in the last couple of
months alone, which is very, very responsive.
From a visual point of view, they have made some effort to
get towards the Holo design guidelines.
But my overall feeling of the application was that while
it's very, very functional and powerful, I found it kind of
hard to get into and understand how to operate and
to prioritize what tasks I should be doing first and what
information was important.
So if we take a look at the application here--
this is the first screen you see when you start the app.
This is where you can create different alarms, as well as
there's a prompt to unlock.
And some of the key functionality on this screen
is down there on the bottom left, kind of like a
split-action bar, but kind of not a split-action
bar at the same time.
And you can see some of the functionality there is to add
a new alarm, start the actual sleep-tracking mode, to see
some statistics of your previous night's sleep.
So, since we're short for time, should we go straight
into the redesign and see what we cooked up?
So here, you can see we've done--
it's not a huge departure, but we tried to apply some of the
Holo look and feel to the application.
So straight off there's a standard action bar giving
that that sense of where you are, and a common place to
look for some of the actions.

I felt like we had to reorganize some of the
functionality a little bit, because this main screen,
while it offered the alarms, there's a lot of functionality
kind of hanging off sub-screens, as well.
And I felt like this app has two main purposes, which is
setting alarms for waking up at the right time, and for
monitoring your sleep and seeing how that
sleep pattern is going.
So I wanted to float those right up as your primary
options into these two main tabs, here, these Alarms and
Stats tabs.
As you can see, we've also really, really emphasized the
Track Sleep button.
So instead of just a little button at the bottom with
equal, fair weighting toward the other options, it's now
this gigantic purple button.
And finally, a little note on the coloring and the palette.
I found some of the green highlights to be grabbing your
focus, saying, look at me, I'm a divider, which felt
slightly off to me.
So we readdressed the palette a little bit here.
It's taking quite a lot of cues from the stock alarm
clock in the latest version of Android for two reasons.
Firstly, I like it.
I think it's a that beautiful app-- might be controversial,
not everyone thinks so.
But also, it is offering slightly similarly
functionality, so it's helping to bootstrap
these as mental model.
A lot of the user interface elements we've used look the
same as from the stock alarm clock app.
So hopefully it can get started with this application
a bit quicker.
ROMAN NURIK: Yeah.
One thing I wanted to mention about the color scheme, the
switch from these neon green to a neon violet.
I guess it's the violet that's in the Android Design official
color palette.
I think that it's just a little less in your face.
It's still very much an accent color.
It's not like a dull gray or a dull blue,
where it's more muted.
But it's a little easier on the eyes.
And I think you can even probably go even one shade
darker, if you want.
On some devices, it may be too bright.
But I think it's just much easier to look at the screen
and not be overwhelmed immediately.
NICK BUTCHER: Yeah.
One of the thing that I wanted to say is that this is one of
the last things you'll look at before you go to sleep.
If you're about to go to bed, you're going to hit Sleep.
So normally, for this kind of app, I would immediately want
to change it to a light palette.
For most apps I think a light palette is generally a good
starting point.
But, for this app, because you didn't want to have that
feeling of you're [INAUDIBLE]
and you turn your phone, and suddenly, you're kind of
blinded by intensity.
So I tried to keep the tones quite mute to try and ease
that kind of transition, really.
ADAM KOCH: In terms of navigation, I like how you've
split Stats and Alarms into the top-level tabs there, and
removing it from the faux split-action bar that was in
the previous version, leaving the two main actions that are
visible there-- the Track Sleep and the Add.

NICK BUTCHER: I found a point on the before shot.
You can see there's a little bug droid figure
in the bottom corner.
And his state changes depending on how close it is
to you having to go to bed.
So right now, it's the daytime, and he's got a
[INAUDIBLE] in front of him or whatever.
But as he gets close to night, he starts brushing his
teeth and so on.
And while I think that's useful and fun--
I do really like that--
I do find sometimes including a bug droid in your
application or even Android or Droid in the name of the
application is kind of lazy and amateurish.
It doesn't really shout, this is a fully professional
application.
I've thought through the interaction.
So I tried to incorporate the same elements using Same
Difference.
So if you can see on the aftershot, very subtly,
there's a number of sleepy Z's in the background to the
application.
The idea here being as you get closer to bedtime, more of
them start coming out from the Track Sleep button or you
could have them subtly animate in some ways.
It's very, very subtle here, but it's trying to convey the
same kind of information, but in a slightly more subtle way.
ROMAN NURIK: Yeah.
And we also did a job on changing the icons.
So we shifted the icon from being a sleeping, cute bug
droid to something very generic.
This is just a very generic icon, but, again, something
that is a little more recognizable and something
that is a little more unique to the app.

NICK BUTCHER: Cool.
[INAUDIBLE].
ROMAN NURIK: Should we move on to the next screen?
NICK BUTCHER: Yeah.
All righty.
So next up.
The next one of the major functions I thought this app
does is give you lots of information about how you have
been sleeping, almost too much information.
So if we touch the graph, like on the bottom left, you get to
the subsequent screen here with a number of options here.
So we've picked out the Stat screen here, which can have a
very, very long table.
And this is just and a small sampling of information,
because I hadn't been running the app for very long.
If you look at the developer's screenshots on the place
though, you can see this can be a massive table.
And while it gives you some average stats, it's summed up
over all time.
Now, I tried to readdress this and think, what do I really
care about?
I probably only care about the last week's stats, like
anything that's older than that probably doesn't really
have much bearing on how I feel my sleep has been going.
What happened two months ago isn't really
relevant any longer.
So what I've done with this screen is I've tried to
provide these summary stats.
So the most important thing to me is a summary of this week,
how have I been doing for the last, say, seven days or
whenever the start of the week in your calendar starts from.
And so we've pulled out some summary statistics, and those
are big and bold.
And it uses color to signify whether you are close to your
target average length of sleep per night or whether you're
building up a sleep debt.
So here, we can see we're using orange for OK-ish, blue
for yeah, you're doing well, or red for warning, you're not
getting enough sleep.
So instantly, when I look at this, I get this quick,
scannable screen which tells me what's going on.
ROMAN NURIK: Yeah.
You can see that on Tuesday, you, for some reason, didn't
sleep very well.
Maybe you were out on the town the night before, or
something like that.
NICK BUTCHER: Too many Christmas
parties at the moment.
So, we've consciously demoted a lot of information.
So if you look at the before, there's other tabs for noise
and graphs, as well as some kind of store, as well, which
didn't seem to be worthy of being a
top-level information item.
It was kind of like adding noise, and making it harder
for me to realize what was really important.
So we've really simplified it down to these few items, and
we let you roll the whole week up and down, if you want to
turn it into a summary or drill down into each one.
We still think this information's interesting, for
those people who want it though.
So the idea here is that you can tap on each of the days.
You can then go forward into a subsequent screen, which is
going to give you details about that one night's sleep
that you've tracked.
ROMAN NURIK: Cool.
NICK BUTCHER: So here, on the next slide, instead of having
this whole roll of graphs--
that kind of view of all the different days as a graph
didn't really tell me much.
I didn't find that very glanceable.
You couldn't really look at it and say, oh, that was a good
night, oh, that was a bad night.
But the graphs themselves are quite cool.
So we demoted them down to a detail screen.
So if you touched each of the line items from the previous
screen, you get through to sleep details that will tell
you how long you actually slept for, how long of that
was in deep sleep, what percentage, and give you that
really nice graph showing you exactly what
the night was like.
That's where there's a [INAUDIBLE]
information can capture when you record your sleep--
like a rating or a comment on how good a night it was.
So these are really details that truly change the
information hierarchy and can put these down to
a subsequent screen.
[INAUDIBLE].
ROMAN NURIK: I think it was just a great job, just
splitting up a very, very complex screen-- a complex
screen that has good data, but it's just
not as easy to consume.
And showing you something that's letting you really look
at the content, or one specific piece of content, the
specific day, and seeing all the details on it.
I think it's just a good combination of different types
of pieces of the content, like a graph, some averages, some
data like that.
Potentially allowing the user to provide a comment, or even
providing a recommendation.
Like maybe you should wear something or sleep stiller.
Who knows?
I know nothing about sleeping medication or
anything like that.
But giving the user all these different types of components
to their one night of sleep is a really interesting and
unique way to present that.
ADAM KOCH: Yeah.
Personally, I really like the typography that you've used
here, Nick, on both this screen and the other screen.
It just really brings out the important information, and
plus the coloring really helps.
It helps you glance at it and see what's going on.
NICK BUTCHER: Cool.
And there's one final redesign idea we had for this
application.
And that's to take advantage of a cool new feature in
Android 4.2 called Daydreams.
So for those of you who might not be aware, Daydreams is
like a screensaver functionality.
So you can set up a Daydream to say that when my device is
docked or charging, kick over into this--
kind of like a screensaver.
So what I thought would be really, really cool is rather
than having to manually go into the application and start
it to track you sleeping, it would be awesome if--
just the fact that, I guess, most people like me probably
plug their phone in at night so it's charging overnight.
So just doing that is enough to say kick off a Daydream,
which will then start tracking your sleep.
I imagine you'd probably put some logic in there if it's in
the middle of the day, or something like this.
You wouldn't actually kick off Daydream.
But just the act of plugging in the device and putting it
down on your bed could then kick off the functionality.
So I really find it's a bit of a burden on the user to have
to go into this application every night and
remember to do it.
Hit the Start button, hit the Stop button.
Remember to do that in the morning.
So anything you can do to automate that process I think
is going to make the user more regular.
They're going to keep on using it and see the value of their
application.
So I thought a Daydream might be a cool way to do that.
ROMAN NURIK: Yeah.
It's just another way to step up the level of, or the
feeling of, magic in this app, where, if you can
automatically track these things, then do it.
So before 9:00 PM, 10:00 PM, if it turns on, or if your
phone goes idle, maybe you just show a clock.
It's fairly easy to just create a simple clock Daydream
that just shows the current time and the current date.
But then after a certain point, it kicks into kind of
tracking mode and shows the clock.
And maybe this is a way to play like soothing sounds in
the background or something, as you're sleeping.
So since this app is already doing all this data capture,
maybe it can use that intelligently to even improve
your sleep as you're sleeping, maybe by playing sounds or
something like that.
So, lots of ideas here.
I think the Daydream idea is really good, here.
Nick.
ADAM KOCH: Yeah.
And, of course, you can interact with
Daydreams, as well.
So you could still have something that you could touch
and resize, or potentially graphs during the day that you
could look at or something like that.
NICK BUTCHER: Yeah.
So overall, a really nice app with lots and lots of
functionality.
I hope the developer likes some of the ideas we've thrown
around there and perhaps runs with them.
ROMAN NURIK: Yeah.
And if you're the developer of this app and you're watching,
feel free to let us know what you think on Google+ or even
email or whatever.
But we're definitely looking forward to talking to you if
you have any questions or if you want some of the ideas.
Or even some of the source.psd files, or anything that.
If we ever review your app or take a look at your app and we
do a mock up, if you want to sources, they're are always
available--
no licensing issues.
We'll just hand them over to you.
NICK BUTCHER: And we do it with love.
I saw some comments for our past redesign of [INAUDIBLE]
saying, is that a slap-down from Google having them to
redesign your app?
That's not what this show is about.
This is about what it could be.
We'd love to work with you to help you get the best Android
design that you can.
ROMAN NURIK: Yep.
And almost all the apps we review, they're awesome apps.
They're really just good.
They're fulfilling their functions really well.
NICK BUTCHER: OK.
We need to move on.
ROMAN NURIK: Yes, we should.
ADAM KOCH: [INAUDIBLE].
ROMAN NURIK: So we've got 15 minutes left.
We need to fly through backward compatibility.
So we have a lot of slides on backward compatibility--
fortunately, a lot of them are screenshots.
But let's get started.
So before we talk about our strategies and tips for
backward compatibility, and specifically for designing for
backward compatibility, not so much for developing for that.
We have lots and lots of training sessions and all that
for developers, but this is really
more targeted at designers.
Before we share some of our own tips here, I'd definitely
make sure that you guys, you designers out there, are
looking at the design guidelines for compatibility.
The guideline's page for compatibility is fairly short.
It only talks about a few important things.
Some of the things include the Legacy menu button, how Action
Overflow behaves across different devices.
So it's definitely stuff that you should be aware of before
jumping into mockups or anything.
NICK BUTCHER: Just pause this video right
now and go read it.
We'll wait.
And we're back.
ADAM KOCH: Let's move on.
ROMAN NURIK: Yeah.
We do have a lot to cover.
So backward compatibility.
The way we view backward compatibility is that for each
screen in your app-- and you could extend this to your
entire app or just an individual widget--
for each screen, visual styling and the behavior,
basically visual and interaction design, can
operate along a spectrum of how close it is to the primary
version of the app.
So for example, and if I have an app design for Android 4.0
and above, and I have Holo elements in there, on earlier
versions, on Android 2.3, Gingerbread, Froyo, whatever,
you can make a choice of either taking that Holo design
or your completely custom design and
using it on that device.
Or you can kind of say whatever the
device default is--
for example, for check boxes on Gingerbread, they were
green instead of blue--
in some devices back then, it was like
blue, red or whatever.
You can make the choice that I should use a device default,
or you could just choose something in the middle.
So usually it's a little harder to make everything Holo
back to Gingerbread and Froyo.
It's very, very easy for developers to
use the device defaults.
And then this hybrid is somewhere in the middle.
So the hybrid solution--
you have to be kind of careful about it.
It can still really work, and we'll show you guys in the
screenshots coming up that hybrid UIs, where some
components are Holo and some components are using the
device default styling, they can work.
So we'll show a couple of examples of those.
But this is really how we see the way you decide on a
backward compatibility strategy.
You kind of pick somewhere along the spectrum.
And depending on where you choose, you need to work with
your developers on this.
But depending on where you choose, that will change the
amount of effort involved for developers, and certainly it
will change the final outcome.
But just be aware that these are the different options, and
there's really no correct choice, I'd say.
Like I said before, you can do it correctly, you can do it
right using any one of these different options.
It's really up to you to make sure that it just works well.
ADAM KOCH: Yeah.
It's really just a trade-off between
these different options.
Like there's more effort involved on the left side of
the spectrum, but you'll have a more consistent look.
On the right side, it can still work, as we'll show you
in the screenshots shortly.
NICK BUTCHER: A bit more effort.
There's some tools out there to help.
ROMAN NURIK: Absolutely.
And we'll talk about the tools out there that are more
relevant to the developers and designers, but still,
definitely, there is stuff out there to help.
So having said that, Holo--
a lot of people ask us-- is Holo for
Android 4.0 and above?
In the end, should I even try to use Holo in earlier
versions of the platform?
And our answer is yes.
Holo is not designed just for the latest devices out there.
Holo is really designed for all people, for all humans.
It's really a design language for human-computer
interaction, not just human-Android 4.0 Plus
interaction.
It can work everywhere.
Obviously, it takes some effort to make it work, but
again, as a designer, you to think of it less as the
styling of Android 4.0, and really as
the identity of Android.
So that's an important point to make.
Another is that the core experience across all
platforms should really be consistent.
You shouldn't really have to design an entirely separate
app for Gingerbread and for Ice Cream Sandwich.
So things like the action bar, those should be visible and
persistent across all devices.
You shouldn't switch into a completely different UI on
earlier versions just because there's no
built-in framework component.
And, again, we'll talk about that.
So things like layouts, the core layouts, the navigation--
like swiping between tabs--
and the core interactions--
like the basic way you choose a contact, for example.
Those should really behave the same across
different OS versions.
And I think that for design-- and the last point is really
more about developers--
but be opportunistic.
Beyond the core experience, the core navigation, really,
the core feel of the app, like the individual check boxes,
and the spinners, and things like that, be
opportunistic about it.
Make sure that nothing looks really bad, obviously, but be
opportunistic.
And don't put yourself in a position where you must have
everything pixel-perfect, because that's
just a losing battle.
It's going to take too much time, and you're going to lose
focus from what's really important, and that is the
core experience of the app.
So before we go on, any other points, guys?
About these three?
NICK BUTCHER: Nope.
ADAM KOCH: Let's go.
ROMAN NURIK: Solid.
Let's go.
ADAM KOCH: Let's do it.
ROMAN NURIK: Another thing to mention-- this is more on the
tactical side.
So one of the big differences, and you'll see this in
screenshots, between Android 4.0 and Android 2.3 and such
is the topography, is the font.
So Roboto is the default on Android 4.0 and higher, and
Droid Sans was the default everywhere else.
So this is one area where you really shouldn't try to just
take Roboto and use it everywhere on Android 2.3.
The reason being that users are really accustomed to
seeing-- like their eyes almost expect to read text in
a certain way on their device, and so you should really just
use the system default font.
The good thing is that for designers, when you're
planning out the widths of your elements and things, you
have to think, obviously, how many characters will fit in
this line or in this UI widget.
And the good thing is that Roboto and Droid Sans are
metrics-compatible, meaning that if you take the same
piece of text in Roboto and Droid Sans on an Android 2.3
device and an Android 4.0 device, you'll notice that
they're pretty much the same width.
So what's more important here is things like translations,
where, for example, the German version or the German strings
for something will cause things to be
really, really wide.
That's more important to think about than just saying, oh, I
need to choose the right font here.
So be more aware of that than just the difference between
Droid Sans and Roboto in English, for example.
And then also--
this is, again, more for tactics--
but in your process, it's really important for designers
to participate in the device-testing process.
So usually, you'll have a QA team or maybe a developer that
has a whole bunch of devices, and they're kind of testing
the APKs on all those devices.
Designers should really participate, because sometimes
designers in a team are some of the most
visually sensitive folks.
So they'll be able to pick out what the little quirks are.
So, as a designer, you should try to introduce yourself into
the QA process.
Not, obviously, full-time, but spend some time making sure
that you're testing the output on earlier versions of the
platform as well different devices, so you just get a
feel for what it looks like.
NICK BUTCHER: And there's a bunch of continuous
integration tools that test your app on different versions
and will produce screenshots.
And you can take a look at the screenshot generated on older
or smaller devices [INAUDIBLE], which will help
you [INAUDIBLE].
ROMAN NURIK: And this is something that, Nick, you
alluded to earlier, but if a developer comes to you as a
designer and says, we can't do this specific UI because it's
only available on Honeycomb and above or
Android 4.0 and above.
That's not always a great excuse, because there are
great libraries out there that solve this for them.
So you don't have to think that, oh, I need to design an
app with an action bar and an app without an action bar, and
an app with all Holo components, and an app with
zero Holo components, because it's just not available.
There are lots of libraries out there that will help you.
Here are just a few.
So ActionBarSherlock, I'm sure a lot of you
are familiar with.
That, basically, is almost a 100% backport of the action
bar to previous versions of the platform.
HoloEverywhere actually gives you a lot of the standard
widget styling, like spinners and text fields and such.
And, actually, they do a lot more, like calendars, calendar
view, and things like that.
The give you a lot.
This library gives you a lot of stuff that you can just
backport to earlier versions.
So if a developer comes to you and says, I absolutely cannot
use the action bar because it's not available on earlier
versions of the platform, fight that.
Tell them that you do have tools available to you, and
maybe that's not the greatest reason for not doing it.
Before we move into the screenshots, any extra
thoughts, parting wisdom for backward compatibility
strategies?
NICK BUTCHER: Holo all the things.
ADAM KOCH: Holo everything.
ROMAN NURIK: Holo all the things.
But it's really up to you, right?
As a designer, you should be aware of the different types
of devices out there, be aware of the tools that developers
have to them, and make the right decision for your app.
NICK BUTCHER: More seriously, I'd say that if you had
infinite resources, you'd probably end up writing a
version of your app which [INAUDIBLE] write a home in
Ice Cream Sandwich, write a home on Gingerbread, write a
home on Froyo.
But given not everyone has the resources to do that, you want
to put most of your effort into skating where the puck's
going, and designing for Holo and then, like Roman says, be
opportunistic about backporting the finer pixel
control stuff, where you have the capacity.
ROMAN NURIK: All right.
So in the interest of time, since I think our producer
actually has to run in about five minutes or so.
So let's fly through some screenshots.
So all these screenshots are going to be apps that we feel
do the right thing, and you're going to see that it's a
combination of that universal Holo everywhere, kind of a
pure, device default, and somewhere in the middle.
So this is tasks-free.
This is both the interactions and visuals on Gingerbread and
Jelly Bean, and you'll see that throughout all these
screenshots.
So this is just their edit screen.
You'll notice that they have Holo styling everywhere.
This is the same, tasks-free.
And all these slides will be available after.
And, by the way, guys, feel free to jump
in as you see fit.
But this is all just, again, another example of apps that
have a pure universal look and feel here.

This is Pattern, another app that is a really good example
of how to do things almost perfectly replicated across
Gingerbread and Jelly Bean.
And this is the first example you see where
there's hybrid styling.
So the Play Store on Gingerbread uses kind of the
standard text fields and a custom button style, and on
ICS and above, they use the Holo text field
styling and the Holo--
well, actually, I guess it's also a custom button.
But, again.
It works really well in both cases.
There's no obvious mismatch of components here.
This is one minor case I wanted to point out, where
almost everything here in Series Guide in Holo, except
for the little stars.
And so these stars, here, in Gingerbread are green, on ICS,
they're blue.
And, really, again, it doesn't really detract from the
experience that it's sharing some styling, and that it's
using what the device has as a default.
This is an example of the I/O App.
This is just one minor screen, where
there's a mix of styling.
This, actually, we need to improve this for next year.
I think this could be better.
But this is an example of where it kind of works fairly
well, but it can be improved.
NICK BUTCHER: And that's a great example of what you're
talking about with the typography, where the Droid
Sans looks right at home on Gingerbread, and the Roboto
looks right at home on ICS.
ROMAN NURIK: And note all of these use Droid Sans on
Gingerbread, and Roboto on ICS.
Another quick example from the Recipe Search App of text
field on the left, text field on the right.
This is an example of using--
I think it's from How About We, which is an
online dating site--

a mix of Holo styling for Gingerbread and platform
default styling.
And again, it works OK.
The core feel and experience in the app is really
maintained.
It's just this one screen has kind of a mix of widget
styling, so I think it still works quite well.
Another example from How About We.
So this is another case, Search, where by default, the
platform has this built-in search mechanism.
So if you're using the [? called ?] search manager,
which is kind of irrelevant for designers, but the
platform default search looks a certain way on Gingerbread.
And you should really try to use that, because users are
really used to that.
Whereas in Jelly Bean, there's another, different type a way
to do it using something called Search View and the
action bar.
That shows that same kind of auto-complete stuff.
So it's really very, very similar.
The implementation's slightly different for developers.
But, again, it's using what users would expect--
standard platform stuff on the left, and the standard action
bar stuff on the right.

ADAM KOCH: Another example of Ted Search View versus old
Gingerbread styling.

ROMAN NURIK: And this is an example of preferences, where
you generally want to use the system defaults styling.
You don't want to have your own custom styling there.
So, where possible, use the standard preference, activity
preference fragment to do all that stuff for you.
And apps like tasks which have generally themed everything
Holo style, in the preferences, they still fall
back on the standard--
oh, here we go.
You beat me to it.
Yeah.
The same as Ted.
ROMAN NURIK: The same as Ted.

And then this is, real quick, to talk
about contextual actions.
Jeff, if you have to go, by all means.
So contextual actions-- this is something that's kind of
controversial.
Do you backport the contextual action bar, which is kind of,
I'd say, a minor interaction.
And I think that's really up to the developer.
If it's easy, then do it.
If not, then don't do it, unless it's the core
experience in your app.
In this case, for Pattern, the core mechanic here is to work
with patterns, so allowing users to do multiple selection
on the patterns make sense here, but certainly, I think
it's still secondary, where you can still perform these
actions in a detail screen.
So don't feel completely obligated to backport your
contextual action bar.
I will say the ActionBarSherlock does this
contextual action bar backport for you, so
something to keep in mind.
And this is an example of the I/O App, which in which we
chose not to backport the contextual action bar.
So here, when you long-press something, you just get a
Context menu, which, again, is more standard on earlier
versions of the platform.
Another screen from Pattern where they've chosen the
device default styling for dialogs.
And they've actually correctly flipped the positive and
negative actions in the dialog, which is good.
And some more from the Play Store, and I think
that's the last one.
Yes.
OK.
ROMAN NURIK: So that was backward compatibility.
Obviously, we can't cover such a big topic in
such a short period.
If you guys have comments, thoughts, feel
free to post online.
And if there's anything we missed, we even touch on this
sometime in another episode.
NICK BUTCHER: Yeah.
Maybe we should do a follow-up show.
ROMAN NURIK: Yeah, for sure.
NICK BUTCHER: Lots of content here.
ROMAN NURIK: Let's fly through Design News, since we have
very little time.
First, Taylor, as always, has been doing redesigns.
He just did a really cool redesign on a movie ticketing
app using the Wizard Pager example that I pushed out a
few weeks ago, which is really cool.
And this is kind of a custom card style, here, for the
tickets you've purchased.
It's really cool.

Obviously we recently launched the official Android Design
Community on Google+.
Here's just a couple of examples of post there.
If you haven't seen it yet, I'd recommend joining--
lots of good content coming out from there.
NICK BUTCHER: I'm loving this community.
Really high quality of discussion going on in there.
Good job, guys.
ROMAN NURIK: And lastly, Nick, do you want to talk about the
response of Headache Relief for Android slides?
NICK BUTCHER: Yeah.
This is a really beautiful presentation.
I highly encourage you to check this out if you want a
good summary or take the temperature of where
Responsive Design is on Android, especially from a web
developer's point of view--
a really, really good presentation.
I recommend it.
ROMAN NURIK: Awesome.
I think that's it for the show.
Thanks to everybody who tuned in.
We will not see you next week.
This is actually the last show of 2012.
We will see you sometime in 2013.
Thanks for tuning in.
I'm Roman Nurik.
ADAM KOCH: Adam Koch.
NICK BUTCHER: Bye from Nick Butcher.
ADAM KOCH: Have a great holidays, everyone.
ROMAN NURIK: Happy holidays.
[MUSIC PLAYING]