Android Design in Action: Design Hangout No. 1

ROMAN NURIK: All right.
Hello, everyone.
Welcome to Android Design in Action.
This week's episode is unlike the other
episodes that you've seen.
This week we're going to have a hangout,
Google+ Hangout on air.
Oh, right, that's probably a good idea.
We're going to have a Google+ Hangout on air to discuss
design, specifically this show or other top tips or anything
that folks may have.
I'm, as always, your host, Roman Nurik.
ADAM KOCH: Hey, guys, Adam Koch.
ROMAN NURIK: And Nick Butcher unfortunately
couldn't join today.
I think he's out sick.
We've invited him to the Hangout just in case he wants
to join, but he'll probably stay home and
rest up for next week.
So with that, let's get started.
We're going to structure the format of this Hangout not
like a regular Hangout where we just talk about stuff.
We're going to go into a few slides in the very beginning.
We want to talk briefly about the Nexus 4 and the Nexus 10
very, very briefly.
And then at the end, we'll have a few slides, as well.
But for most of this episode, we'll be talking to the folks
that have joined to see what thoughts they may have.
So let's jump into the slides.

So Android Design in Action.
Let's see if I can navigate this thing.
There we go.
So the Nexus 4 and Nexus 10.
As many of you know these are the newest
devices coming from Google.
These are the newest devices in the
Nexus family of products.
The Nexus 4 is a handset.
It's 4.7 inches diagonally.
You can see all the screen specs here.
The Nexus 10 is a 10-inch device, so it's a new
reference device, if you will, for a 10-inch size, kind of
replacing the Motorola Zoom, in our opinion, for pure
Android experiences.
The important thing to note is that this is I guess the first
time, Adam, that we've had such a
high-density tablet display.
Before, almost all tablet displays, 10-inch tablet
displays, have been MDPI.
ADAM KOCH: I don't think any of them have been anything
other than MDPI.
ROMAN NURIK: Yeah, yeah.
So they've all been roughly, I guess, 1, 280 by 800 pixels,
so this doubles that.
So you now have a crazy number of pixels on the screen.
The good thing is that the dip resolution hasn't changed, so
your existing layouts will just work.
The difference, though, is that the assets that will be
used in those layouts, you know if you have buttons and
things like that, they'll be twice the density, so
basically 320 DPI assets.
ADAM KOCH: Yeah, any assets I guess shared
from your phone UI--
[SIDE CONVERSATION]
ADAM KOCH: Yeah, any assets shared from your phone UI,
obviously the tablet UI on Nexus 10 will just pick those
up immediately.
But if you have any assets that are specific to tablet
layouts, you will need to update to include XHDPI.
Also for Nexus 4, it's worth mentioning that the width is
slightly larger than Galaxy Nexus.
It's 1,280 by 768 as opposed to 1,280 by 720.
ROMAN NURIK: Yeah, and that maps to about 24 extra dips--
horizontal dips of resolution--
for the Nexus 4 as compared to the Galaxy Nexus or other
devices like that.
So that's the new devices.
I mean, there's lots and lots of other stuff to talk about,
but you guys probably know all these things from all the
different press that's been out there.
But these are some of the details that are probably
important to designers in thinking
about these new devices.
And then just to recap.
We now have the Nexus 4, the Nexus 7 and the Nexus 10.
And here are, again, their rough screen
specs, if you will.
The other thing we should point out is
that launcher icons--
as many of you know, when designing for MDPI tablets, I
guess the older density or the earlier density for tablets,
you'll also want to provide an HDPI launcher icon.
Because what the launcher does-- and the launcher is
that home screen, as many of you know.
What the launcher does is when it displays an icon for an
app, it chooses the one bucket larger icon because it wants a
physically larger icon.
So instead of showing a 48-by-48 dip icon in a
launcher, it actually chooses to show
a larger icon launcher.
So to get an icon of that high resolution, it basically uses
a shortcut.
It basically looks at the same asset at a higher
density and uses that.
So on XHDPI tablets like the Nexus 10,
that one bucket larger--
that one size larger icon is actually XXHDPI or
480 dots per inch.
The important thing to note here is that the tablet
itself, the screen itself, is not XXHDPI.
It's simply that the framework and the launcher will be
looking at XXHDPI.
It'll be looking for an icon in that folder.
So basically, you want to provide just the launcher icon
in 480 DPI and nothing else because everything else will
just not be used.
So XHDPI for all your regular assets, and then your launcher
icon should be in both XHDPI and XXHPI.
ADAM KOCH: Yeah.
I believe this only holds true for tablet.
So Nexus 7 included, but not for handsets, is that right?
ROMAN NURIK: Yeah.
All right.
And I think that's really all the slides we had.
So let's jump into-- let me just turn off
the screenshare here.
Let's jump into the discussion.
So to get started, I'd say we should all just introduce
ourselves really quickly.
Like I said, I'm Roman, and we have Adam here.
Do you guys want to just go around table to introduce
yourselves, maybe starting with Akhil.
AKHIL INDURTI: OK.
Hey, guys.
I'm a 17-year-old Android developer
from Ashburn, Virgina.
I've only recently started.
I finished learning Java extensively, and I'm actually
going to apply to the Google's Computer Science Institute in
the summer.
So hopefully, I can see you guys there.
I use Fireworks as my program of choice for design.
And obviously, I like to use Eclipse because it's easy to
work with for me.

OK, that's my introduction.
ROMAN NURIK: OK.
Do you want to move on to Ed?
ED LEA: Yup.
Hi, I'm Ed.
And I'm a designer working mostly
Android, but iOS as well.
And I've worked for a company called Qiip, and we're working
on bringing the Qiip hop up to Holo standards at the moment,
so a bit Gingerbread.
ROMAN NURIK: Very cool.
All right, Linden, do you want to go next?
LINDEN DARLING: G'day.
I'm Linden Darling.
I'm a professional Android developer based in Australia.
I make my own apps, also provide Android development to
banks and other companies to make their apps.
I do a little bit of dabbling in design and
multimedia as well.

ADAM KOCH: Cool, cool.
Linden, where are you in Australia?
LINDEN DARLING: I'm in Melbourne.
ADAM KOCH: OK.
I'm from Melbourne, originally.
Hopefully, you've met our counterparts in Sydney
[INAUDIBLE].
LINDEN DARLING: Yeah. yeah, yeah.
I don't know why they're based in Sydney to be honest.
ADAM KOCH: We used to have a Melbourne office, but it's not
there anymore, actually.
ROMAN NURIK: Cool, all right.
And is it Ron or Ran?
RAN NACHMANY: It's Ran.
ROMAN NURIK: Ran, do you want to go next?
RAN NACHMANY: I'm Ran.
I'm an Android developer from Israel.
So we're covering, I think, the whole world here.
We're only missing Nick from the UK, and
then we' d have Europe.
Actually I'm a GDE, a software expert, and I'm working a lot
here in the community and providing professional
services to companies or building community events,
talking in them, and so on.
ROMAN NURIK: Awesome.
Well, welcome to the Hangout.
And we have two other participants, Oscar and--
I believe it's pronounced "De-an-dre." I'm not sure.
But if you guys want to introduce yourselves, feel
free, although your video is muted.
If not, then we'll just move on.
OK, and feel free to join at any point.
Oh, is it "De-an-dre?" or am I pronouncing that right?
DANDRE ALLISON: I'm Dandre.
ROMAN NURIK: Oh, Dandre.
Do you want to introduce yourself?
DANDRE ALLISON: Sure.
I am a Android developer.
I started a little over a year ago.
I'm in San Francisco.

I guess I started at the interesting point where you
guys were switching to Holo and 3.0, and then Ice Cream
Sandwich came out, and then Jelly Bean.
So it's been a pretty drastic change since when I started
and how it is now.
ROMAN NURIK: Yeah, Android has gone under somewhat of a
reimagining, I guess the core visual image, and it's visual
identity has really just gone under a complete renovation
since maybe, even two years ago.
So, yeah, that's a great time to join.
Welcome to Android.
And Oscar, we're assuming that you're just a bit shy, or
don't want to join, or have video meter or such.
But anyway, we'll just get started.
Feel free to join when you're ready.

God, I suck at working Hangouts.
ADAM KOCH: No, no.
It's good, good.
ROMAN NURIK: OK.
So guys, do you want to just start off with any sort of top
tips that you have or maybe even like favorite apps or
anything like that?
The floor is really yours.
What types of things do you want to talk about?

AKHIL INDURTI: I was wondering if I could
show a design maybe?
ROMAN NURIK: Yeah, sure.
Totally.
AKHIL INDURTI: And this is my Chrome.

I actually showed Roman this.
I emailed him a while back.
And it's basically a course-organizing app for
students that I'm currently working on.
And it lets basically organize all their courses, and
assignments, and schedules with their teachers, and their
contacts with their teachers.

I have one question.
If you can see my contextual action bar here, what color
should I make that?

ROMAN NURIK: Wow, of all the questions.
So contextual action bars, I mean, just using the default
color is generally fine.
In general, you really want to just hint that it's a
different mode.
So really maybe a darker version.
If you do want to change it, then maybe a slightly darker
version of your core accent color which seems to be brown.
I know the general palette is kind of brown, like a dark
burnt orange and like a tan paper.
So maybe something that's somewhere along the spectrum,
maybe slightly darker.
But I think the big important point here is that you just
want to visually indicate that it's a different mode.
So as long as it's fairly different from the standard
action bar, it should be OK.
If anybody else has thoughts feel free to jump in.
ADAM KOCH: Yeah, i was just going to say, I think it's
fine to leave it, to be honest, unless you really want
to get that full theme-y thing across, albeit
I think it's fine.
ROMAN NURIK: Yeah, and in general, when we talk about
Holo, there's lots of different guidelines that fold
under Holo, this Holo umbrella.
One of those guidelines is the visuals, right?
But I think for me the visuals are less important, and what's
more important is the interactions, right?
So having the check box there, right?
Having the done button there is far more important than the
specific color of the action bar.
That is really up to you as a designer to choose what looks
best to you But really, the core things that you should be
leaving are the standard expected interactions like
pressing the top left area, which would be a check box to
close the action mode, having the action overflow there in
case there are additional actions.
So it's really, for me, more about the interaction side of
things than the visual side of things.
Although the visuals are important, it's really just up
to you to make them look good.
AKHIL INDURTI: Yeah, and one more question.

For the check boxes here, if someone was to click on it, do
you think it's good for the entire list item to go to the
bottom of the list, or should they stay there?
ROMAN NURIK: The checkbox really means that it's like a
completed task?
AKHIL INDURTI: Yeah.
ROMAN NURIK: In general, I'd say--
and this is just a general rule.
Do what people would expect.
In general, what users expect is what they're used to, what
they're accustomed to.
And so if there is something on the system, especially if
it comes with their device, if there's a system app or a
platform app that does this exact thing, then just mirror
what that does because that's just what they're going to be
accustomed to.
In this case, I can't think of anything where a check box
marks something as completed that's built into the system.
So in this case, you don't really have much of a default
to rely on.
One thing you could consider, though, is when you interact
with something, if it's jumping around, it's going to
be hard to continually interact with it.
So let's say you wanted to check it, mark it as
completed, and then do something else to it.
If you mark it as checked and then it jumps down, your
finger is no longer at the relevant target, right?
So you basically have to jump around there.
That's just another minor point.
I think it's less important than following conventions
because again, that's what people are going to expect.
But I think in this case, having it jump around too much
may be a negative thing.
Does anybody else have comments on that?
ED LEA: Yeah.
If you did put it to the bottom of the list, and the
bottom of the list is actually off the bottom of the screen,
then you're probably going to struggle to
find that moved item.
So maybe try and distinguish it a bit more
than just being checked.
I know a lot of apps change the color or maybe some kind
of strikethrough or something if it's a done item.
That's quite a common pattern.
ROMAN NURIK: Yeah, and one of our favorite apps, the Tasks
app by Team Tasks, they do exactly that.
They just show an additional strikethrough as an additional
visual indicator that something is checked.
RAN NACHMANY: Actually, I would go with a
swipe-to-dismiss instead of a check box.
ROMAN NURIK: Definitely another option.
Absolutely another option.
We talked about this, not last week, but two weeks ago or
three weeks ago on that episode.
Swipe to dismiss is definitely another option.
Nick's very much in favor of that.
RAN NACHMANY: You can see that in task management, like
any.DO, they're doing it.
And I can't think of other apps, but it's very natural to
the user to just get things out of his way.
AKHIL INDURTI: I'm curious on how you would go about
implementing the swipe to dismiss, actually.
I may be going way over my time.
So I'm probably done but--
RAN NACHMANY: Actually, that's easy.
I think, Roman, it's your library, right?
ROMAN NURIK: Yeah, so--
I don't know if I have keep pressing around.
God, these Hangouts are very difficult.
So yeah, I wrote a library-- well, not a library, a gist on
GitHub that basically did swipe to dismiss for you.
So for any list view or any vertical linear layout, it
gives you that's swipe automatically.
But one of the differences is the item that you swipe to
dismiss actually then goes away.
And so in this case, I don't really know if you would want
the item to disappear so much as you want to change its
visual state.
You may be able to use some of the things from that library
in this app.
But I don't think necessarily that swiping to hide the item
would work.
ADAM KOCH: One thing Nick pointed out the other week was
a really nice pattern is to swipe, and then have an Undo
button hiding underneath, and then you tap that and it comes
back again.
Just another thing to think about.
ROMAN NURIK: All right, Akhil, maybe you want to show just
one more screen, then we'll move on to other topics.
AKHIL INDURTI: Oh, actually no.
I was done with my screenshots.
ROMAN NURIK: All right, well, overall, yeah
it was a great job.
Like you said, I did see it before.
You sent me that email.
It's a great job overall.
There are just some minor things.
But, yeah, following that through and publishing it on
Google Play, let us know when that happens, and we'll make
sure to take a look and see if there's any sort of promotion
we can provide.
But yeah, it's a really great start to the job there.

AKHIL INDURTI: All right, thanks.
ROMAN NURIK: Anyone else want to either show their work or
talk about--
and also one of the options, if you want to rant about
something for like a full minute, by all means.
There's plenty to rant about, I'm sure.
But if you do want to rant about it, that's
just another option.
But also if you have work to show, if you want to get
comments from the rest of the folks here, then that's
definitely another option.
Any takers?
LINDEN DARLING: Yeah, so I have a couple things to show.
ROMAN NURIK: Let's see them.
LINDEN DARLING: Can you hear me?
ROMAN NURIK: Yup.
LINDEN DARLING: Yeah, yeah, cool.
OK.
So I'll be real quick.
Obviously, there's the Android Assets Viewer, which I think
everyone is going to find very useful.
Another thing is a little library that I've been working
on that basically extends and fixes up the setError
functionality I'll feature in Android in a bit.
So I'll quickly show you that.
ROMAN NURIK: Formidable-validation, that's
a cool name.
LINDEN DARLING: Yeah, yeah.
So it's providing easy validation for forms as well
as making the feedback consistent.
So you've got setError working for any
TextView-derived class or view.
But it doesn't work for, say, a spinner or a selector.
Basically, you can add setError.
You can extend any view and make it setError-able and then
use this validation manager.
And it will be set the error on anything that
got errors on it.
So that's stemmed from me having to provide feedback in
very complex forms and Android apps.
ROMAN NURIK: So if you have even like a check box or like,
for example, I accept the terms and conditions, if you
don't check it, you can have a an error
bubble show above that.
I'm guessing, right?
LINDEN DARLING: Yeah, so that's like a
dependency sort of.
It's the way I've categorized or named something like that.
For instance, here if you're signing up to a newsletter,
you've clicked the "yeah, I want to sign up to the
newsletter" check box.
That then makes the email address fields necessary.
So if that wasn't checked, then you wouldn't be getting
an error frame on that one.
So it's got a couple validators.
Generally a lot of people are going to be using the regular
expression validator, but you can write your own ones and
add them in as well.
So, yeah, this is Open Source.
And it would be great if you guys could have a look, and
anyone that's interested in using it or adding to it or
extending it gets involved, that would be sweet.
ROMAN NURIK: Cool.
And what was the Android Assets Viewer?
I remember reading about it a little bit.
But do you want to give a brief overview and maybe show
some examples?
LINDEN DARLING: Yeah, let me just share that one.
Tell me if you can see it.
ROMAN NURIK: Yep.
LINDEN DARLING: Is that up now?
ROMAN NURIK: Mm-hm.
LINDEN DARLING: OK, so it's --
again, it stemmed from, I suppose, pains that I've found
in different contracts working quickly to make apps and
working with designers that are generally new to Android.
So basically, the idea is you want to provide an easy way to
show graphics and look at all of the graphics across your
different size buckets, all the drawable variants.
So this does that and gives a little
bit of analysis feedback.
It's showing you whether your sizes are right, whether
you've got odd pixels, or whether you're going to have
half-pixels and stuff.
For instance, this is the assets.
I've uploaded the assets from formidable-validation, that
library I just showed you, and you can see them here, that
it's showing different sizes.
So you've got your LDPIs your MDPIs.
There's even the XXHDPI in there, just to be super fresh.
And here, it's missing an XXHDPI, but it's saying that
basically if you were to put that in, the right size of it,
it's shown in green.
It's 96 by 96.
So it's just providing--
ROMAN NURIK: Does it look at which assets
you currently have?
So if you have some random assets that's like 40 by 40 in
MDPI, it will show you what the equivalent is in XHDPI in
an empty slot if it's not there?
LINDEN DARLING: Yeah, yeah.
That's exactly what it's doing here, right?
So all of these are based off MDPI at the moment.
I might add something to look at sizing based on other
buckets if the MDPI isn't there.
But you can see here that the MDPI is 48 by 48.
It's suggesting that the XHDPI--
well, it's saying that it's not there, and it
should be 96 by 96.
You can see, here that TVDPI is always going to have odd
pixels or half-pixels.
And so it's I guess a way of when you're talking to
designers that are trying to give you iOS graphics and
don't want to do any more work, this is a great way to
bring them on board and show them things.
ED LEA: How do you put those?
LINDEN DARLING: What was that?
Sorry?
ED LEA: How do you actually put your assets into this?
LINDEN DARLING: Oh, yeah.
So you just upload either an APK or a zip file.
If you're afraid that I'm going to reverse-engineer your
APK, which I could do anyway just getting it off the
market, you can just zip you're res
folder and upload that.
So It's looking for a res folder that's containing
drawable folders.
So you've got your drawable LDPI--
no DPIs.
Well, whatever--
you might have your extra-large
whatever bucket is there.
It's going to show them all.
ROMAN NURIK: Awesome All right, Linden, we're running a
little low on time, but what's the fastest--
LINDEN DARLING: One last quick thing.
ROMAN NURIK: Yeah, sure.
LINDEN DARLING: One last quick thing--
the Device Viewer.
So this is something I added just recently, and it lets you
view this stuff on real devices, scaled as though it's
on that device.
So it gives you a real quick glimpse as to how things are
going to scale and how those graphics and different buckets
are going to look on different devices at their original
smaller size.
In this case, it's a 9-patch with scale, and you can get it
just for what it would look like at its smallest size.
ROMAN NURIK: And the most important thing, Linden, how
do you get to this awesome tool?
LINDEN DARLING: Yeah, so it's at celebellum.net--
which is like cerebellum if you hold your
tongue and say it--
slash androidassetsviewer.
So I'll just show you there.
ADAM KOCH: We can post a link up in the Google+
ROMAN NURIK: Yeah, we'll definitely post a link
afterwards.
LINDEN DARLING: Yeah, yeah.
ROMAN NURIK: OK.
Let's move on, though, since we're running a
little low on time.
I just want to get one last thing from everybody
who wants to answer.
What would you like to see in a future episode of Android
Design in Action?
What specific topics would you like us to cover?
And let's it, I guess, from Akhil.
AKHIL INDURTI: Crouton versus Toasts.
ROMAN NURIK: Crouton versus Toasts.
AKHIL INDURTI: I'm wondering.
ROMAN NURIK: OK.
AKHIL INDURTI: It's a new library, and I was just
wondering who's out there using Crouton right now.
ROMAN NURIK: OK, yeah.
It's an awesome library.
It's definitely interesting to provide a different and more
contextual Toast almost.
Definitely a good topic, we'll keep that in mind.
Dandre, any thoughts?

DANDRE ALLISON: I'll pass for now.
ROMAN NURIK: OK.
All right, Ed or Linden?
ED LEA: Yeah, I've got a couple of requests.
And I guess one of them is the production process from
graphics to developer and how do you manage that process?
Do you design MDPI and then just email it over graphics,
or do you share some repo--
just the whole production process would be quite good.
I guess a little bit on fonts and thoughts on including more
than just the bold and regular, and whether that's a
good idea to do or not.
And then tablet apps, a lot of developers have got mobile
apps out there, which could work on a Nexus 7.
How much effort should be put in to releasing for a tablet
versus making people wait for the app and releasing a custom
type of app?
ROMAN NURIK: Totally.
And we did have an episode recently on responsive design,
but we're definitely going to do more on tablet design since
it is a nuanced area in designing for mobile since
it's like semi-mobile, but definitely something that
we're going to continue to talk about.
And those other suggestions we're great.
We're definitely going to looking into that as well.
Linden and Ran, any thoughts on things we should cover for
future episodes?
LINDEN DARLING: I mean, the stuff that Nick and Marie did
at some conference in Germany, I saw a video for that where
they did a redesign on the fly and showed the thoughts that
would go in the plan, and that's really useful and
interesting.
I think something like that could be good to do again.
ROMAN NURIK: Definitely.
LINDEN DARLING: You do it with obviously lots
of different apps.
You guys started doing that with your looking at apps at
the moment as well.
But I think having the design tools out there and showing
how people can do it quickly as well.
And also tackling the big problem of making an app look
good on Honeycomb Plus, but as well as old Gingerbread 2.2,
without, say, using--
just going for a pure Holo theme and trying to
pull that all back.
This is just the main problem.
I know you guys are pushing for the newest
style all the time.
But the reality is that apps out there and companies want
to target as much of the market as they can, and stuff
just doesn't look that great.
Not everything--
even Holo, everywhere doesn't bring everything back, and so
if there's any tricks or talking about some of the
issues there.
ROMAN NURIK: Yeah, so like maybe potentially an episode
dedicated at backward compatibility and designing
for earlier devices.
That makes a lot of sense.
Since that is a very pragmatic view of the current landscape,
is most devices are below Android 3.0, so definitely
something we should look at.
OK, and Ran do you have any thoughts on
what we should include?
RAN NACHMANY: Thoughts, and a request, actually.
I started working on a project.
It will be basically a car-mounted tablet.
It will replace the entertainment system.
And will also talk with some chip inside the vehicle that
talks with other vehicles, other cars, to provide
collaborative safety.
I don't know if you guys have heard of that standard.
It's called 11P.
But never mind.
We're not going to look at that today.
The idea is that it's a 7-inch tablet that is going to be
used-- the application is going to be used
dedicatedly in a car.
It needs to be operated by a driver or the passenger, but
also by the driver.
So there needs to be very little
interaction with the user.
And obviously, action bar cannot fit there.
It's too small, things like that.
So right now, we're banging our head against the wall
trying to figure out what will be the best way or approach to
show a map, some very necessary available
information, and that's it, and still be very responsive
and intuitive to the user if he wants
to go to other screens.
And you've done some amazing job with the design guide, but
it's all focused for mobile phones, and mobile usage, and
that stuff.
And actually, Android is going to other areas and not just
handsets, tablets but also--
[FUZZY AUDIO].

ROMAN NURIK: So basically exploring how to design for
alternative or auxiliary use cases, right?
RAN NACHMANY: Exactly.
ROMAN NURIK: So outside of the standard holding a phone in
your hand or holding a tablet in your two hands.
Yeah, definitely something we can look at.
We'd probably need to see a few example devices, right?
A few example use cases.
But definitely we can imagine what is the next step,
designing for the next step or the evolution of Android
devices in different areas and different use case.
ADAM KOCH: And there are some apps that need to do something
like that anyway.
Like navigation apps, for example, that have catered to
that use case.
ROMAN NURIK: Totally.
OK, so we're super low on time, but we just want to run
through a few last slides.
We have a little bit more information to share.

So bear with us for just a second.
So let's just quickly run through news.
And there isn't too much news.
Oh, actually the most important bit of news here is
that a uistencils.com has recently released an Android
tablet stencil kit.
And this is like a physical metal piece of kit, I guess,
that you plop down on some paper, you fill in the blanks,
and you get your standard iconography.
You get your standard . widgets, things like that.
So if you're looking to sketch on real paper with real pens
and pencils, then try to get this kit.
We actually do have an example here.
And you're not going to be able to see it.
I'll show it after.
But the really cool thing is that we have
a few to give away.
So we're going to be giving away about 10.
So the way in which we're going to do this is that we're
going to ask the greater community to take a few
screens from one of their favorite apps, or even their
own app, redesign it using some of the Holo elements that
you've see on this show, and then post it to Google+
publicly by the end of the week.
And when you do post, make sure to use the hashtags ADIA
and AndroidDesign so we can see them.
So the first or maybe the best 10-- we don't really know yet.
We'll try to send out some of these stencils.
And these stencils, I think they retail for like $27 on
uistencil.com.
So if you want to just get them and not wait for us to
look at your stuff, then you go to uistencils.com
and get your copy.
And we'll post details about this giveaway at some point on
Google+ as well, probably right after this show.
Also, I did two posts very recently.
First on wizard design, like designing a wizard, in this
case, one the lets you order a sandwich, very, oddly enough.
But it's got all sorts of things like dependencies, like
dependent sections and things like that.
So if you're designing wizards, check out that post.
And then lastly, cheat sheets.
There's another post I did.
Basically, in the action bar, as many of you know, when you
long-press an icon in the action bar, it shows you
little toast, a little tool tip that pops up and
says what that does.
This is really useful outside of just the action bar.
So if throughout your UI you have icon-only UI elements,
you'll want to use something like this to give the user an
extra bit of confidence that what they're about to press
does what they think.
So this is especially important in cases where your
iconography may not make perfect sense.
So there's a library--
I guess another GitHub gist that shows you how you could
do this, and that's the apps I have here.
So I think that's all the slides we have today.
Thanks again for joining, guys.
We're hoping to do a few more of these
Hangouts in the future.
For the next few weeks, we'll probably go back to our
regularly scheduled Android Design in Action, where we
will be doing redesigns.
But look for other invitations to join another Hangout
sometime in the next, say, few weeks or next two months.
So thanks for joining everybody, and I guess we'll
see you next week.
Thanks, guys.