Android Design in Action: Cricket App Specs + Maps

ROMAN NURIK: Hello, and welcome
once again to “Android Design in Action.” I’m your
host, Roman Nurik. ADAM KOCH: Hey guys. My name is Adam Koch. NICK BUTCHER: And hi, my
name is Nick Butcher. ROMAN NURIK: And today, we
have an episode about the visual design. And specifically, I guess we’ll
talk about the specs or redlines for the Cricket app
that Reto put together, or the Cricket app design that Reto
put together at, I think it was last Friday’s App Clinic. Once we’re done talking about
that, we’re going to jump into a couple of designing details
and recommendations on how to incorporate maps, specifically
Google Maps, into your app. We have a bunch of interesting
fun slides there and yeah, should be fun. So with that, let’s get started
with the Cricket app visual design. Nick, you want to
take it away? NICK BUTCHER: Yeah,
absolutely. So for those of you who didn’t
catch the App Clinic last week, Reto Meier looked through
his ideal kind of design, both in terms of screen
design, as well as architecture, so creating an
up-to-date sports results app. So if you missed it, I encourage
you to check it out. It was a really great episode. And here on the screen we see
what he put together. So while Reto spent a lot of
time thinking about the functionality of the
application– and I think he’s done
a pretty good job– he didn’t, and in fact, he
stated he wasn’t going to focus very much on the
visual design. So we’re going to pick up where
he left off, pass over the banner, and have a look at
some of the visuals that we can do here. So just quickly, the app on the
left is a cricket score tracking application. It has a panel at the top for
tracking in progress or kind of what’s going on now games. And then it has a panel below
which gives you a summary of the upcoming matches, which
are sorted by all kinds of intelligent signals, as to
whether they’re going to be relevant to the user. I’m not going to lay on too
thick, sorry, Adam, about The Ashes result because that just
wouldn’t be sporting of me to just pile the shame onto my
poor Aussie colleagues. So we’ll skip past that. So what we will look at, though,
is some of the steps that we’ve taken to address
some of the visuals. And we’re going to take it
step-by-step and build it up. So one of the first things I
looked at is the action bar. So one of my favorite
components, one of the key navigational components in
the Android platform. And I’m not sure if it was a
conscious choice, but Reto picked this blue color
for the action bar. And one my problems is this is
one of the stock Android hollow colors. And I find if an application
goes with this stock kind of blue, it makes it feel almost
too stock, in a way. It’s almost like no attention
has been paid to it or you’re just using an out-of-the-box
component. So what I decided to do is when
I think of cricket, I think of green fields with
players wearing white and a red ball, and that’s the
kind of palette I think to work with. So we, instead, reskinned it
using this kind of grass green, I’m going to call it, as
our strong, single accent color– which we’re going
to extend throughout the app later on– and went for a monochrome icon,
which works quite well. So again, picking up on that
white and green, as you’ve got the cricket bat icon there. And one thing we’ve done is
we’ve actually themed the title text as well there. So picking up on the weight of
the icon we’ve used, we’ve gone for a slightly
heavier weight. So here we have Roboto
Bold Condensed in a slightly larger font size. So again, pick up on the icon’s
weight, as well as we went with the metallic theme
there to give it some motion. As well as adding some of the
usual items you might find in the action bar. So Reto said he’s going to use
a navigation drawer, so we added the drawer affordance
there, as well as adding search and overflowing
buttons. So step one, we had a look at
the action bar and showed it some visual love. ROMAN NURIK: One of things that
I really like about this is specifically when you look
at the way the icon is juxtaposed with the title, the
weight of the glyphs and the font are actually not really
similar, but they balance well with the thickness
of the icon. So it’s not like the icon is
overpowering the title text or vice versa. It’s actually very
nicely balanced. So I think that Bold Condensed
works really well here. Moving on? NICK BUTCHER: OK. Step two. So after we’ve picked an accent
color, we then took a look at the rest of the palette
in the application. So we extended the accent color
throughout, so you can see it in the header and in the
page indicates that we’ve picked up on that same color. But also, the original
used this quite stark, contrasting palette. So we had like a near black
section at the top and then a white section below. Very, very highly contrasting,
and felt to me, a little bit too visually contrasting. And as a side note, you want
to be quite careful in your use of pure white, very,
very pure white colors. Just used to the technology,
most phones and tablets users have in their hands have these
very, very bright screens. So using pure white can
actually be kind of overpowering. So you want to reserve pure
white for something which you want to draw attention to, you
want to have stark contrast, not so much for a background
panel. So what we’ve done here is we’ve
kind of muted the color scheme down a little bit. So we’ve gone for these
off-whites and kind of gray background. Just to make it a little easier
on the eye, a little less contrasting. ROMAN NURIK: Yeah. Perfect. Moving on. NICK BUTCHER: Yup. So next step, we took a little
look at the metrics. So there’s a few things you can
do to your application to really easily make it easier to
both scan, and then to work out what items that belong
together and which items are separate. So we applied the standard kind
of 8 and 16 dp grid– which we commonly talk about
here on this show– to this screen here. So you can see here, we’ve just
moved some of the lines around, changed the margins and
the spacings, just to line up to this. It’s majorly a 16 dp grid. And then for any minor,
inter-list item spacing, we’ve gone for 8, or sometimes
even 4 dps. So basically, we’re using this
kind of system ribbon. And it just makes it
feel much easier. So you work out what belongs
together, and see how things should be spaced out. Not related to the metrics
here, but I always swapped out– I wanted to talk about– I wanted to swap out the view
and the view page indicator here as well. So instead of them– I think before we had four
dots with one of them colored in. Instead, I’ve gone for this
bar where they color in, almost like a scroll bar. It’s a slightly more Android-y
design, like having these angled, flatter kind of lines,
rather than these dots, which is a bit of a hangover from
the iOS design guides. ROMAN NURIK: And you’ll see this
view pager, or this pager indicator, I guess, in apps like
the Launcher, obviously, when you swipe between your
different home screens– although it’s a little
hard to see there– as well as apps like
Google Currents. NICK BUTCHER: The Currents
is a good example. I like that because it keeps
the bar persistent, whereas Launcher kind of fades it out. Which is kind of subtle and it’s
right for a homescreen, but I think if it’s something
where you actually want to indicate that there’s more
content, this present design works very well. ROMAN NURIK: Yeah. One of the things I wanted to
point out, as you mentioned, grouping, the ability for white
space and margins to communicate relationships
between elements and group things together. This is something that Alex
Faaborg talks about a lot in a couple of his talks in Google
I/O this year, and I think last year as well. But basically, I think
it’s the Gestalt principle for grouping. Placing items in
close proximity naturally implies a grouping. So it helps here, I think, to
communicate that these are individual elements. You almost can imagine what
would happen if you removed all of the list item
separators, right? Would the structure
still be apparent? And I think in this case, it
would, given that there are ample margins. It also makes for a much better
reading experience. As you’re scrolling down, your
eye can naturally land on an individual item. And once you actually see
something interesting on an individual item, then you can
spend a little more time to explore it, rather than having
to parse out which are the individual items in your list. NICK BUTCHER: Great. Cool. And then I think the last step
that we took on this screen here, is to then apply some
different type of graphical treatments, to really tease out
the information hierarchy. So in the previous design, all
the information was there, but it was a little bit overwhelming
to try and understand what was the
most important. And nothing really jumped
out to you. It kind of came across as kind
of almost too dense, these blocks of text. So what we’ve done here is we’ve
used things like color and additionally, different
sizes and weights of the different texts, to
really tease out what is the most important. So I think the first thing
I look at is the score. Obviously, it jumps out
straight away at you– as well as the team names
and the summary section. And then scanning down the
upcoming list, it’s very, very easy to quickly pass this
list and find a game. You’re going to look at this
list and see, all right, that’s the game I’m
looking for. And then you can deep dive
further down to find subsequent information. So by using these different
text sizes, colors, and weights, it really, I think,
helps tease out the information hierarchy. So one of things we didn’t want
to do is introduce too much complexity. So there’s actually only and
two different font sizes, three different font sizes, if
you include the score, on the screen here. So it’s not too busy. There’s not too much going on. But by using these different
colors and weights, we can really establish
the hierarchy. ADAM KOCH: I think it really
makes a huge difference. And I think we’ve mentioned this
before on the show, but I was actually looking at the two
screens from a distance because we’ve got a TV here
to view the slides. And when you take a step back,
you can really see what the difference that it makes. When you look at it from that
distance, you can see the titles very clearly. As opposed to the old
screenshot, where you just see these blur sections of text,
which you can’t really understand or comprehend
very well. NICK BUTCHER: One thing I wanted
to pick up on is the use of the all caps style, which
is fairly commonly used in Android. It’s actually sometimes used
for the less important information. So it might seem
counterintuitive to when you might use capitals. It might think that
it’s shouting. But quite commonly in Android,
we’ll use a smaller text styles with a lighter font
color, best full value perhaps, coupled with
the all caps style. And it really is this kind
of byline or strapline. Like the detailed information. I think this works quite well
here for making this information seem like it is
secondary information. ROMAN NURIK: Yup. Just to give Reto some credit,
I will say that the amount of information, I think, was
accurate, was correct. And I will say, that I will
caveat, that I know nothing about cricket. But one of the things that you
should also think about in terms of typography and what to
put on your screen is, are you showing too much at once? Are you showing too little? And I will say that I feel like
Reto, in the original design, was actually showing
the right amount of detail, the right amount
of information. Again, caveatting that I know
nothing about cricket. But I think that it’s really,
once you decide what to show and really kind of pick
and choose, and again, you’re on mobile. You don’t want to cloud
the user’s context with too much stuff. You don’t want to cloud their
vision with too much unnecessary information. But once you decide what to show
you, you have to really think about how to show it, how
to portray the hierarchy. And I think that’s where
typography can really help. NICK BUTCHER: Yeah. The one thing that I wasn’t
quite sure about was, I think, the second flag, the second
England flag on the left screen here. On the other one. I think it denotes the team
currently bowling next to the number of overs bowl. And I found that kind of
repetition of the visual a little bit jarring, a little
bit uninterrupted. So I swapped that out for a red
dot, which is supposed to look a bit like a cricket
ball, right. So I thought that cleaned up the
visuals and also made it feel a bit more balanced
as well. ROMAN NURIK: Got it. OK. Yeah. Actually, I remember making some
minor tweaks here, and I wasn’t quite sure what
was going on. Again, because I know nothing
about cricket. I guess that’s another lesson. Know your users, know what
you’re designing, before you design it. NICK BUTCHER: All right. Let’s crack on. So the other thing with this
exercise that I’ve been cleaning up, it’s showing how
easy it is to perform a few tweaks on the information. Reto did the hard work. Like Roman says, the hard work
is deciding what to show on screen and how much information
to show. We’ve just provided a few
digital tweaks to make it easier to scan and
easier to see. But another thing we wanted to
in this exercise is just demonstrate how you would take
such a mock, and then communicate that design
to a developer. So here’s an example of the kind
of techniques we use in our applications here, this kind
redlining technique where we’ll actually overlay the
document with these red boxes and annotations, I guess,
showing exactly what font sizing, spacing, and going
through and just really documenting everything,
including there’s an example of the touch highlight,
the opacity, the color, and so forth. So this is really the interface
a designer has with a developer, right. This is the information the
developer wants to know. They want to know– It’s no good just giving them
a PSD or things like that. They want to know things in dp
sizes and absolute colors, and so on, so they don’t to go
digging in to a PSD file to find this information. ROMAN NURIK: One of the things
that I find really useful is when you’re creating a response
of design, or something where you’re targeting
multiple devices, rather than using– potentially. I mean, I don’t know if this
will actually work in practice, but it’s definitely
something that I’ve thought about before. Rather than using 4 dp, or 8 dp,
or 16 dp here, you could say small, or medium, or large,
and then have a lookup table saying, on phone size
devices, small is this size, medium is the size, large
is this size. And then, on, let’s say, seven
inch devices or once you have 600 dps of horizontal space,
let’s say, you start bumping those up. And having something like a
lookup table where basically like, this is small, this
is normal, this is large, and so forth– that’s actually really easy for
developers to then take and map into dimensions files. So you can literally just take
that lookup table, and create XML files to specify the
dimensions in those configurations. NICK BUTCHER: Yeah, you could
go and just do the dimensions as well. Things like the text
size, like I’ve specified here as 18 sp. But that maps to what we have
as this text appearance medium, is this standard
text size. That’s 18 sp on some devices,
but it could be larger on other devices. A device which you’re more
likely to hold further away, that could actually
be a larger value. So rather than specifying
anything, any number, I guess you could swap out for
some lookup value. ROMAN NURIK: Let’s carry on
to the navigation drawer. NICK BUTCHER: Yeah. So we didn’t redo the whole
application, we just looked at this one screen. But I did want to pick
up on something on the navigation drawer. Reto’s used it. He’s done a good subdivision
of the different sections. But to me, there was a couple
problems with it. Firstly, the individual
navigation items felt a little bit insubstantial to me. This is like your major
navigation within the application, so I wanted it to
feel a little big weightier. And the other problem I felt was
that there was no idea of selections. So if you’re currently on one
of those screens, it should echo back to you that yes, this
is where you are on the application. So this is what we did, some
very, very easy visual tweaks. We just changed the screen. So the first one we did is we
changed the line height of each item, to pick up on the
size of the action bar. So here on a phone-sized device,
it’s going to be 48 dps, but on a larger device,
that icon might grow to like 56 dps, for example. But yeah, this echoes the height
of the action bar, so it falls into the natural
rhythm of the screen and echoing the system components. We then borrowed from the style
we picked up for the screen title, and used
this bold italic. It’s not the condensed version
here, just because I didn’t feel like it sat quite right. So this is just actually Roboto
Medium Italic here. But yeah, I think these items
feel a bit weightier. And we didn’t actually go
through and create glyphs or find glyphs for this, but I feel
like having some kind of iconography would also help
with this sense of place. ROMAN NURIK: Yup. And then we have a spec for the
navigation drawer that you put together here? NICK BUTCHER: Yeah, exactly. So I just wanted to call out a
few items here, so this is how you might spec this. So one of the things that
we’ve done here is we’ve followed our guidelines than a
navigation drawer should be between 240 and 320 dps. So we called that out
explicitly, so it’s not going to grow too big. And we’ve called out things like
the drop shadow to use, just to the right, the drawer
that has this very subtle free dp drop shadow at 30% opacity. So just calling out this
documentation that your developer is going
to want to see. And you can see they’re
actually kind of similar to how– Roman, if you can zoom in on
the big square there over Countries icon. Yeah, we specified the
icon frame area. We called it 48 by 48 dp. We’ve actually specified there
in brackets, these should be the same height as
the action bar. So a developer’s going to see
that and they, oh, right, I can see I should assign that
to the same height as the action bar. So on a different device, it
might be a different size. ROMAN NURIK: Any parting
thoughts for this design? NICK BUTCHER: Not really. Like you say, I think Reto did
a great job with doing the hard work of actually working
out the information design. And we’ve just shown a few easy
techniques to communicate that better. ROMAN NURIK: Yeah. I think Reto started with basic
wire frames, like you said, the information
architecture. And then the process of taking
that and creating medium to high fidelity visual
design mocks. It’s fairly simple. I think that you really
start with the grid. You then move on to things
like typography, color, and so on. But really, once you have the
wire frames, I think it becomes pretty easy to
put together the visual design part. Not to trivialize all the work
we need, Nick, but– So let’s move on to maps. So Adam, you want to
take away for maps? ADAM KOCH: Yeah. So let’s talk about Google
Maps for Android, the API version 2. So hopefully this doesn’t need
too much of an introduction. It was released last year with
great fanfare, as an upgrade to the original version
of Maps or MapView. It’s a great API. If you have an app that takes
advantage or needs to display content on a map, it’s
definitely something you should use. For those of you who aren’t
familiar with it, it’s a very powerful API that lets you
display these vector-based map components in your
application. And the advantage of that is
that well, first of all, there’s technical advantage
to it, but from a visual perspective, the user can
actually pan, tilt, rotate the camera, as the user looks
at the map, very easily. And it’s just a really
immersive, interactive experience. ROMAN NURIK: And they can see 3D
building silhouettes, which is actually really good for
providing extra context for if you’re looking for an apartment,
or looking for pizza places or something, that
extra bit of context can really go a long way. ADAM KOCH: It’s a really
neat feature. And I think it only happens
when you zoom to a certain zoom level and in some cities,
but it’s really cool when you see it. NICK BUTCHER: I think one of my
favorite changes in Maps v2 is that I think in the Maps v1,
there was some technical limitations about how many maps
you could have in your application, and so
on, and so forth. So you had developers pushing
back about the designs about where you can and can’t
include a map. That’s no longer the case. In v2, you can have as many map
projects, and as big or small, and make them animate
and move as you like. So don’t take that
for an answer. ADAM KOCH: Yeah. I think you’re also referring
to MapFragment there, which lets you use a map as a portion
of the screen, rather taking up the entire screen. Definitely great updates
in the v2 version of the Maps API. So in terms of interacting
with Map, there’s a few standard controls that
come with the API. Pictured here, you see
the Zoom controls, Compass, and My Location. Those are fixed in various
corners of the map, if you enable them. The Zoom controls is always
in the bottom right. The Compass is in
the top left. And it’s actually not
always visible. It’s only visible when the user
rotates or moves the map away from the default
angle or rotation. And then there’s the My Location
button, which is in the top right corner,
normally. And of course, these can all
be toggled on and off. And you can also create
your own UI controls, if you want as well. These are just the
standard ones. And then there’s also some
standard map gestures that you can use. So zooming in. Obviously, pinch zoom is a
standard gesture for zooming in on a map or zooming out. Scrolling or panning,
just by touching the screen and dragging. Tilting is using two fingers
to drag up and down. Rotating– two fingers to rotate around. These are pretty standard
things that you probably already experienced
when using Maps. So in terms of customizing
the map, there’s two main components that you customize. Well, there’s a few others,
but the main ones here are markers and info windows. So the markers are the actual
little markers that drop down on the map to indicate
a location. And info windows are those
little dialog boxes which pop up, normally when you touch
one of those markers. So obviously, the default ones
are kind of plain and boring. You should almost always
customize these to fit your app appropriately. The info windows, they do
support layouts, but they’re very static. So for the developers out there,
you’ll find that you can’t actually make
some dynamic updates to those views. It really just draws it once
and then you’re stuck with that until you re-add
them again. And I think we’ve got some
more information. ROMAN NURIK: The one
thing I wanted to mention was touch targets. So when we were designing the
Google I/O app, which you see pictured here, we were actually
thinking, oh, can we have an info window that has a
primary target, and then a secondary, see more target? And unfortunately, the current
limitation is that no, the entire info window is a single
touch target, and there’s no real way to customize that. So there’s no way to have a
button to the top right or a separate section in
that info window that takes you elsewhere. So just plan for that and
keep things simple. It does help simplify the
interaction model for the map, but it is a current
limitation. ADAM KOCH: This is a good
example in the I/O app of customizing the info window. So you can see here, the Android
track is selected, and we’ve got this nice, green
highlight faded there with the little Android icon
in the top right. ROMAN NURIK: And just for the
developers in the audience, what basically happens is you
can provide your own layout. But what the map component
will do is it’ll take a snapshot of that layout. It’ll actually draw it,
lay it out, and so on. It’ll take a snapshot, and then
use that bitmap snapshot to render the info window. So it’s not actually like a text
view, and another text view, and so on. It’s really just a snapshot. It’s an image. ADAM KOCH: Basically,
it calls draw. And then whatever the output
is, it just displays that. ROMAN NURIK: Exactly. ADAM KOCH: Cool. Did you want to talk a bit
about the visual design? ROMAN NURIK: Yeah. So a couple of ideas for
marker visual design. There’s really two types of
markers that you can have. And I guess you can use whatever
shapes you want. If you have, let’s say, a person
on a map, obviously, probably you want to use their
avatar in their somewhere, and then that will guide
some of the shapes. But if it’s just a very basic
marker that indicates something, I guess a couple
of suggestions. The first is to try to use
your brand accent colors. So just as you would use your
accent color in the action bar or for list section headers or
subtle accents throughout, definitely keep using that here
in your marker images. And I think that we’ll probably
be able to share a PSD template for this kind
of thing at some point. But here’s an example
from the I/O app. We actually didn’t use this
one on the right here. But we did use this where
basically the marker ends up just being white, since
we know the background is colored. And then we use the standard
Google I/O– purple, or blue to red gradient,
as one of the items that was in the marker image. So it helps to further that
message of brand consistency throughout the app. Another thing I wanted to
mention is around density. So if you have a lot
of markers– this is one of the
things that– one of my pet peeves, I guess. When you open up, let’s say,
a real estate search app or pizza search app or whatever,
and there’s like hundreds of results, and all you see
are just these– ADAM KOCH: Sea of sea. ROMAN NURIK: Yeah,
sea of markers. It’s not that useful, right? You can no longer see the map. You lose the whole point
of having a map there. It’s just like a whole bunch of
people standing in a crowd and you can’t really make
out any one of them. So for those cases, you may want
to use a smaller marker. The point here is not
to actually have a smaller touch target. The touch target should still
really be the same size, maybe a little smaller. Like this entire– Or I guess, all around this one,
for example, this marker should be a touch region, that
touching that actually triggers it. But the idea here is that it
doesn’t really matter if you accidentally click
the wrong one. What the user would do is be
able to zoom in to see more information about that area. And once the markers, these
smaller markers are well-separated out, then there
will be no ambiguity in terms of which one you clicks. So the idea is, use smaller
markers purely for the purpose of seeing the map underneath. Because like we said before,
actually what was said in one of the slides there,
was the map is– Actually, no, later on. The map is the UI, right. The whole context, the
whole interface for the user is the map. It’s the geographic context. So you don’t want obscure that
with too many markers. NICK BUTCHER: Speaking of that,
the map’s not going to provide the clustering algorithm
for you because we leave that to you. You probably know more
about information and how to cluster yourself. But if you want to have an
example of how we do clustering, there’s a great
blog post called “Too Many Markers,” from the Google Maps
team, describing how we do clustering. So for developers out there who
want to implement that, Google for “Too Many Markers.” ROMAN NURIK: Cool. All right. Moving on. ADAM KOCH: So changing
the view. As I mentioned before, you’ve
got a lot of control around how the user is viewing,
the perspective the user’s viewing the map. Basically, the camera angle
that the user’s viewing the map on. And actually, the Maps API makes
it really, really easy to animate the camera
between locations. Basically, animate the location,
zoom, bearing, and tilt, all these different
things. And it actually does it by just
sending an extra flag. It’ll animate between
two locations. And this is really useful for
giving the user a way of illustrating the difference
between two locations. So for example, if you’re
viewing something in New York and you want to jump across to
London, the map will very quickly zoom out, swing across
the London, and give you this very easy mental spatial idea
that you’ve moved a very long distance across the map. And I guess one point to mention
is that you don’t need to always pan the map if there’s
tons of different info windows around. So that will mean that the
touch targets, where the user’s trying to touch the map
will keep shifting from underneath them. So in those particular cases,
you may want to minimize the amount that the map
moves around. But in most other cases, it can
be useful to show these animations between locations. ROMAN NURIK: Yeah. And I think with the
API, there’s no automatic panning behavior. So you can definitely customize
what happens when you touch something. But really, at that point, I
can’t mention it enough. It’s one of my other pet peeves,
I’d say, is when you touch a marker that’s just
off-center, and then it re-centers the whole thing,
and everything else shifts around underneath you. And obviously, the animation
helps maintain that context. But it would still be much
better if you just kept things in place, only moving the map
as much as you need just to show the content. ADAM KOCH: Yeah. So if you tap the marker like
maybe the edge of the screen, then you may want to
pan that down. But as Roman’s saying, if it’s
just off-center, it may not make sense. ROMAN NURIK: All right. Let’s speed through, since
we’re running low. ADAM KOCH: OK. The most important slides will
have no time anyway. So a full screen map or a large
map– the reason why I say large map here is just
because if you’re on a larger screen device, it may not
actually be a full screen map. It may be taking up the majority
of the screen, but not all the screen. So in this particular case,
the map is really the interface here. You should really
allow panning, tilting, zooming, rotating. Not allowing those is kind of
unexpected to the user. They’ll be expecting to be able
to do all those things. And of course, you should be
minimizing UI distraction. Now one thing that we’ve
recommended in the past is using the action bar overlay
mode, so adding some transparency there to
the action bar. And this is actually from one
of our first episodes of “Android Design in Action”
that we did a very long while back now. I will note that it’s a
great thing that you can enable, if possible. There is a minor issue with
it from a technical spec perspective, in that the Maps
API will actually show you the UI controls underneath the
action bar– potentially because it doesn’t actually
re-layout those UI controls in some cases, when you engage
the overlay mode. So it’s maybe not appropriate
at the moment for all applications. Maybe if you’re using custom
UI controls, it could work. But definitely if you can enable
it, it’s a really neat feature to make the map
feel more immersive. All right. Should we just zoom through? ROMAN NURIK: Yeah, let’s
fly through. ADAM KOCH: OK. So embedded map. So now the map is not
full screen anymore. And what’s written
here, the map is really the context here. So it’s just trying to give
some context around the information on the rest
of the screen. In this case, you should
really be removing or minimizing the UI controls. You don’t really need to
have the zoom buttons. The user’s probably not going
to be doing two finger gestures in that tiny
little space. This is an example from
Foursquare, by the way. The nice thing that Foursquare
actually does here is if you tap on the map or single press,
it actually expands the map out to the full screen and
switches back to that full screen map mode that I was
talking about before. And the last thing is that there
you could potentially switch using static maps, if
you’re using embedded apps. So not really having any
interaction, or removing some of that dynamic feel from the
maps until you tap on it, and maybe be taken to a
full screen map. Anything else there, guys? I know we’re zooming through
really quickly. ROMAN NURIK: No, I think you
covered it pretty well. Those are– NICK BUTCHER: Yeah. The only thing I would say is
yeah, also take a look at the updates to the Google Maps
application because I think that’s a phenomenal job of doing
some of the things Roman was talking about, like keeping
the interface stable, but having easy interactions,
moving between different pins and stuff. So I think that’s a great
example as well. ADAM KOCH: All right. ROMAN NURIK: Design news. Let’s try to do this
in a minute. First, if you are in the Bay
Area, San Francisco, Mountain View, whatever, there’s an
Android designers meeting coming up, a meetup coming up. Check out this URL here to, and join. I think the first event is
happening next week, August 6. NICK BUTCHER: And if anybody
wants to do things together in London, then ping me because
I wouldn’t mind starting something like this. ROMAN NURIK: Yes. And we have a similar New York
Android designers meetup. I don’t think we have the next
one planned yet, but sometime in August, hopefully. All right. Next. So one thing I really wanted
to point out is that we’ve been posting a lot of protips
on the Android Developers Google+ page. We have a bunch of Android
development protips, but also a bunch of Android
design protips. So this one here is specifically
about the new Nexus 7 that was launched
last week. And specifically, some
design details there. Basically, long story short, you
have already designed for the new Nexus 7. There’s no extra work to do. It’s basically the same dp
resolution as the old Nexus 7, just with a higher density. So everything should
just work. NICK BUTCHER: And oh my
god, it’s beautiful. Everything is so sharp. ROMAN NURIK: Yes. It is a gorgeous screen. And lastly, one of the things
that was new in Android 4.3 is this new optical
bounds feature. So basically, if before your
nine-patches had extra spacing around there to account for
things like drop shadows and glows and such, and that caused
your UI elements to not really visually line up. And Kirill Grouchnikov did a
fabulous blog post about this specific problem and
how they address in this Google Play Store. But if you are having this
problem, and you want to address it, as of Android 4.3,
there’s a new feature called optical bounds in
nine-patches. So basically in your
nine-patches, you have these extra red markings to indicate
that this should be the negative margins that you should
shift the UI elements to, so that the left visual edge
or the left optical edge aligns with other items along
that line, along that edge. So it’s new in Android 4.3. You go from a sloppy layout here
on the left, to something a little more clean and
well-aligned on the right. And pretty easy to do. I think that’s all the
time we have today. So thank you everybody
for tuning in. I don’t know what we’re doing
next week or when our next show will be, but
see you soon. I’m your host, Roman Nurik. ADAM KOCH: See you
guys, Adam Koch. NICK BUTCHER: Bye. Nick Butcher. ROMAN NURIK: Adios, folks,

1 thought on “Android Design in Action: Cricket App Specs + Maps

  1. Android Design in Action: Cricket App Specs + Maps is starting in just a few minutes!

    #AndroidDesign   #ADiA  

Leave a Reply

Your email address will not be published. Required fields are marked *