Tip:
Highlight text to annotate it
X
>>Matias Duarte: Hello, everybody. Good morning. Welcome. Thanks for coming out here. Thanks
for joining our session on designing Android UI for tablet and for phone and, specifically,
on Honeycomb. My name is Matias Duarte. I run the UX team for Android. Up here on stage
with me are Christian Robertson, Rich Fulcher, Adam Powell, and Roman Nurik. And they're
going to help speak through all the different aspects of designing UI here. Before we get
started talking about the fun stuff, let's do the administrative stuff. Make sure you
get the cool apps here that will help you give feedback. Also download the Google I/O
Android app which has the same links. We're going to use the Google I/O Android app as
an example for some of this. So take a look at that. By the time we get to that, you'll
have had plenty of time to download it. So, if you start downloading it now, you should
be set. So first we're going to talk a little bit about the context. We're going to spend
some time talking about Honeycomb and the visual design of Honeycomb, which we're code
naming Holograph. And then we're going to talk about the tablet UI patterns. And, again,
then spend time using the Google I/O app as an example for that.
So first, though, some context. What were our design goals for Honeycomb?
On any given project you always have way more that you want to do than you possibly have
time to do. So it's very important to decide which part of the pie you're going to bite
off. So we decided to do three things at three different scales starting from the very big
and ambitious down to the more tactical. And that first most ambitious goal was to actually
advance the state of computing. Mobile computing, in specific, but computing
in general. Now, thankfully, we've come a way since this picture was taken. But there
still is a lot to do in terms of advancing how we use computers. And that focus resulted
in some of the system level changes that you guys can take advantage of with Honeycomb.
Specifically, things like the visible tangible recent task switching, which we just recently
made scrollable and more interactive in the 3.1 update yesterday. That also resulted in
things like the actionable more customizable notification system. So that was the big goal.
We also wanted to specifically focus on making the best possible tablet experience.
That meant not just transitioning our UIs that had worked on phones and making them
bigger and just making sure that they worked, but really optimizing them for phones. So
that, actually, leads to one of the things that we're going to talk about a little later
today. The way that we allow to you have multiple column and multiple fragment-type layouts
in your applications and how you make choices about when it's appropriate to use what number
of columns and how you transition the columns in those states between portraits and landscapes
and how you position them in your tablet apps. The Third goal was the blocking and tackling.
Really spending time making sure we move the ball forward on improving the basic usability
of Android. There's a lot of ground for improving the usability of any platform of any project.
So we focused on a couple of the biggest most painful points, the discovery problem people
have in many applications where they don't understand what all the possible actions are;
the out of sight, out of mind problem that's created with the menu button and hiding options
under the menu button; and a lot of the confusion or complication that resulted from navigation
and the difference between navigating back through the system back stack and navigating
up inside applications themselves. So these guys are going to talk in more detail
about how we actually accomplished those three goals. But the most important thing I want
you to keep in mind, as you're looking at all this, is this really is just the beginning
of the journey for us. This is the first of many, many steps for Android. It's always
an ongoing evolution. And with Honeycomb, you can see that commitment that we've got
towards making interfaces more tactile, more flexible, more immersive, start to come to
life and it's just something that's going to accelerate more and more. And I wish I
could tell you about how we're going to do it in Ice Cream Sandwich. I'm sure a lot of
you want to ask questions about how we're going to do it in Ice Cream Sandwich. But
you're just going to have to stay tuned for that. So, with that, I'd like to invite Christian
Robertson up, who is going to talk about the visual design of Honeycomb.
>>Christian Robertson: All right. So you might have noticed that the visuals for Honeycomb
have changed a little bit from what they were like in Gingerbread. And Matias was talking
about some of these overarching goals. When we were thinking about the visuals, one of
the things we wanted to do is make a UI that would make the user feel powerful. It's not
enough just to make a device where it looks like it would do a lot and the device is powerful.
The user needs to feel enabled and in control. This kind of power and control requires UIs
that can be dynamic and can change base on users's needs and expectations. We realized
that to do this, that we would need a visual language that would move beyond static screens
that were made out of Photoshopped plastic or metal or leather.
So, as we were looking for inspiration, we were inspired by the immediacy of heads-up
displays in game UIs. We were inspired by the Hollywood holographic UIs that wrap around
their users and seem to react instantly to their every intent.
And one of the characteristics that we realized these UIs had is they were essentially digital.
We wanted to create a language that really utilized the flexibility of the screen. In
fact, as we were designing, we joked that the metaphor for our screens was that they
were screens. So some of our more specific goals: We wanted
to enable these flexible dynamic UIs. And we also wanted to simplify, open up the design
and enable extensibility so that any new visual language we made would allow for applications
to represent their own brands in a strong and powerful way.
So I wanted to show a couple of the drawings that led to the final design that shipped.
As you can see here, the music carousel as the albums are loading in, before the album
art loads, you can see a hint of the wire frame behind it. Or in the case of a list
where users try to scroll beyond where the list allows, the energy of the scroll has
dissipated and escapes as light. And you might have recognized this as something we snuck
into the Gingerbread release. But the idea is that we use physical and spatial and tactile
cues. But, at the edges and underneath, we give users a hint that this thing is created
digitally. And we prepare them for more advanced kind of -- we use the term "techno magical"
things to happen. So one example of this is with the multi-tasking UI. You can see that,
on the edges of the screen shots you have a hint that these things are created digitally.
And this gives the user a cue and helps him understand that they're going to be able to
very quickly switch contexts and understand how the screen is going to redraw.
But it's not enough just to create UIs that are quick and responsive. It's important that
users understand where they are and what's happening so that they feel like they're in
control of the device and not the other way around.
So, in the case of the home screen editor UI, when a user picks up a widget and drags
it onto the home screen, the home screen expands. And an echo of that widget is projected onto
a grid that is visible as you scroll around. So this kind of heads-up immediate transformative
UI enables us to have this kind of flexibility. And, like Matias says, this is just the beginning.
We want to bring more of this. So, in another example, even in cases where
these holograms, if you will, are resolved into full 3D objects that are opaque and cast
shadow, even here we give the user a hint that they're in a virtual space by how the
books are hovering over this implied floor. It tells users that they can expect a list
of books that goes on. They're not going to run out of space on their bookshelf.
Okay. So, as we look to have more flexibility, we realize that UI that changes with user
needs can also become more simple and more open.
So this is a sheet that shows the UI elements that make up the light theme, the hollowed-out
light theme. And you can see that we've pushed to simplify elements. We want to solve more
design problems with space and with typography and not necessarily have to draw a plastic
box around every element. So here's an example of how it starts to play
out. If you notice the compose screen from Gingerbread on the left, the purpose of the
screen is absolutely clear to the user. We felt like the number of boxes that -- or number
of containers that showed up on the screen added some unnecessary complexity. So on the
right you'll see the Holo theme and how they're represented. You see even the text boxes aren't
boxes. It opens up the design and makes for an approachable and easy-to-understand interface.
And you'll notice in the composed space, we don't even have a box. We just left a big
open space to invite people to write their mails.
Even on list elements, as we expanded them out to the tablet, we looked to keep the design
open. The divider lines start to become more like typographic rules than bounding boxes
that make list elements into tiles. And, as we started to remove some of the kind
of the structural boxes that surrounded things, we realized that the spacing and the grid
and the metrics became more important than ever. The design of the holo theme is based
on a 16-dip baseline grid, which -- baseline grids are something that graphic designers
and typographers like to nerd out on. But it really does make a big difference in creating
a screen that's ordered and that has strong hierarchies and is easy to understand.
You can see here this is the subcolumn grid that we use to lay out the interfaces. And
you'll notice, as you start to build with these underlying structures, that you'll need
less and less of the boxes that show up on top of the UI.
And then, lastly, we really wanted to create a UI that could get out of the way and let
application brands really shine through. And, as we're starting to do this, a few of the
tips that I want to talk about, the first thing you'll need to do is choose the light
or dark theme that holo elements are optimized for light or dark backgrounds now. And consider,
as an easy first step, to switch out some of the primary colors for the UI elements.
And then one new thing in the holo UI also, we have background images on the screens.
You have to be careful to not put too much complexity out there where it conflicts with
your content. But very quickly you can express your brand with the application through those
backgrounds. As you're overriding those themes, make sure that, for each element you use,
you override each state. It's easy for some of those extra states to sneak through. And
then, as you're opening up the design and removing the boxes, again, the spacing and
metrics really matter. One place where this shows up when you're porting phone apps to
tablets, you'll notice that on phones a lot of times we'll fill things to parent. And
then, on a 10-inch tablet screen, those line lengths can be way too long. The buttons can
get way too wide. So pay attention to that. And then, lastly, as you're looking to promote
the brand of your product in the marketplace, we've given some new and better opportunities
for applications to show the visuals of their brand through a larger high-res market icon
512 by 512. And, if you think about your users scrolling through the app marketplace and
thinking about the things that they're using to decide whether or not your app is a high-quality
app, turns out that the quality of their rendering and the execution of your icon is a really
strong signal that people use to determine whether your application will be a quality
application. So there's an opportunity there. And also we've also introduced new future
banner graphics and promotional graphics, again, to let people see what your application
is and your brand is about. So, with that, I'm going to hand the time
over to Rich and Adam who are going to talk about some of the UI patterns and framework
features of Honeycomb. [ Applause ]
>>Richard Fulcher: I'm Rich Fulcher. I'm one of the interactive designers on Android.
>>Adam Powell: I'm Adam Powell. I'm a framework engineer. I work to make some of this a reality.
>>Rich Fulcher: So we're going to look at a few UI patterns today. Just for those of
you who missed the talk last year or just aren't familiar, a UI pattern is very much
like a software design pattern. It's generally similar to a recuring problem. It's not necessarily
the perfect one, not always even appropriate. But it's generally a good way of going about
solving the problems that we hit repeatedly. These are, in general, framework supported.
And we'll be talking about that as we go. And also they're not restrictions. These are
just guidelines. These are practice that we can follow that we found to be successful.
We'll talk about four different topics today. We'll start with the Action Bar, move on to
some tips for multi-pane layouts. We'll talk about app navigation. And then we'll close
with a little bit of discussion of how we go beyond simple lists.
So, first up, the Action Bar. So this isn't a new pattern. If you were here last year,
we talked about action bars. And I said go make merry, make lots of action bars. And
you did. Thank you. If you look around in the market, you see lots of apps. We haven't
gone idle either. So we've been working on this pattern a lot, as, hopefully, you can
see in Honeycomb. You can see the trajectory behind where we were last year and where we
are now. And we added some new features and new capabilities into the action bar. But,
just a quick reminder, the action bar is reserved real estate at the top of the screen. It's
used for navigation and for indicating the view that the user is looking at. And, most
importantly, it's used for presenting the most frequently used actions to the user so
they don't have to go into the menu structure to get to those. It's also a convenient way
to get to the menu to search when you have devices that lack those physical hard keys.
So, in general, the action bar has three sections as we've done it in Honeycomb. So, on the
far left, you've got your app icon. In the middle, you've got your view details, which
also has a navigation component to it. And on the right-hand side you have the collection
of action buttons. One way to think of it is, from the users perspective, the first
is where am I? The middle section is well, what can I see?
And the last is what can I do here? So, starting on the left, the app icon doesn't
have to be your apps icon. Could also be a logo, other branding. It's mainly here to
give the user a sense of place. We also use it for navigation. But we'll talk a little
bit more about that later. As you move to the right, the middle section
is the view details. This can be very simple. This could just be
a title as you're using some title bars in Android today. But you can put more interactive
elements into it as well. You can put in tabs or drop-downs, Breadcrumbs, things like that.
And then, finally, at the right you have the actions themselves. Again, these are the most
important, most frequently used actions you want to collect here. You can present them
as text, as icons, as text and icons, your choice. Also we have an overflow menu here.
You can present your most frequently used actions in the bar, less frequently used actions
can just be demoted into overflow menu. That's things like settings and help that we don't
think a user wants to get to all the time. But we want to have in a consistent location
across different applications. We also support the action bar transforming into a contextual
mode. Once the user makes a selection on the screen, you can change the Action Bar so that
it is more tightly tied to the selection as opposed to just the entire screen. It still
has three sections. You still have an I'm done, I'd like to leave it on the left; a
set of view details in the middle; and on the far right-hand side a set of actions you
can take with them. How do we implement this? Action mode.
>>Adam Powell: We have a few implementation details for this talk. So the action -- whoops,
want to be still on this page for a minute. So, as we take a look at the problem that
the contextual Action Bar solves here, most of the developers and users are familiar with
the idea that you can touch and hold on a particular element to get a context menu.
There's kind of a problem with context menus as soon as you have more content on a screen.
Often times you'll want to interact with several pieces of that content at once. A context
menu you have to make a choice or get out. You have to take the action right away. What
the action modes let you do is you can start an action mode from any view, similar to the
way that you can show your context menu from any given view. This lets you, like Rich said,
sort of flip the Action Bar over and offer a series of actions that the user can take
on your content. This is really handy for things like text selection, multiple selection.
Anything where you might want to sort of revise your context in flight once you know what
you're able to do with it. But this is also part of just the standard
action bar, and this is one of the things that the new action bar APIs in Honeycomb
can do. So in general, an action bar is not particularly difficult to create in an application
before Honeycomb, either. Stick a layout at the top of your activity, stick some buttons
there. What's hard about this? Why do we need a separate API for this? Not only can we do
things like the action modes that let it do double duty, but we also have the ability
to offer some consistency, offer an implementation of some of these common design paradigms.
So to get a basic action bar, you can use either of the default holo themes offered
in Honeycomb, theme.holo or theme.holo lite. If your target SDK version as declared in
your manifest is 11 or above, then theme.holo is your default theme.
The action items themselves over on the right side of the bar actually come from your options
menu. So the implementation details of this end up being pretty much identical to what
you're used to when you are populating your options menu panel on previous versions of
Android. So for customizing the action bar, you can
obtain an instance of the action bar object from your activity, call various methods on
it, place custom views into it, edit the menu, invalidate as necessary, so on and so forth.
And we also offer some customization in terms of how you want to show each menu item as
an action as you populate your menus. So again, it's not too difficult to write
a custom action bar implementation before Honeycomb, and the Google I/O app actually
shows an interesting way of doing this that still takes advantage of the options menu
items that you may already have available. So alternatively, you can still continue using
the default options menu on previous versions of the platform. It's something that users
are already familiar with using. So more reasons about why to use the new action
bar APIs versus just rolling your own. Once we start moving down to phones and smaller
screens again, some of these patterns start to break down a little bit. Suddenly you want
to start swapping out elements for a little bit more space conservative variance. You
might want to reduce icon plus text into just the icon alone, even if it may not be quite
as descriptive as you may like when you have more room available to you. And the overflow
icon may no longer be appropriate if you have a physical menu key still on the device.
So what can you do about this? You can also split a single bar into two.
>>Rich Fulcher: Yeah, a good approach to this is, especially in portrait on a phone device.
The amount of real estate you have becomes highly constrained very, very quickly. So
if you are trying to do something like tabs is a great example, if you look at the I/O
app. I'll actually just skip to that slide. There's three different strategies at play
here. Adam already mentioned a couple of them. Take something like that new action and reduce
it just to an icon. Move other actions that were in the overflow menu into the menu hard
key. And then finally, take the bar itself and split it across two lines, actions at
the top and view details below that. Or you could split it up the other way as well. You
could have view details the top and just put actions at the bottom of the screen.
>>Adam Powell: And even then, we are still maintaining a little bit of the same patterns
that you described before, where we try to separate out the idea of the anchoring and
navigation component which we're showing at the top of the phone UI in this case, from
the actions which still appear at the bottom of the screen in the form of the options menu.
>>Rich Fulcher: Okay. Our next pattern is multi-pane layouts. I'm sure, as you have
been playing with your tablets, you have been appreciating all the real estate you have
compared to older Android devices. We do, too. As designers So we want to pack more
and more content into every stream. One way we have approached that is for certain spaces
we put in the multiple view panes within a single screen. It gives the user a little
bit more context for what they are operating on. It can divide up the space and it avoids
some of the very long line widths that you can sometimes run into. You don't want a button
that spans the entire width of a tablet device. In general, we kind of rely on the notion
that as the user kind of reads from left to right across the screen, the details kind
of get more specific. If I am seeing a list, it then leads to details for an item.
One of the trickiers parts of using multi-pane layout is when you get into changing the device's
orientation. So we have one rule we want you to adhere to and then a couple of strategies
for how to deal with that. The rule is that we want to preserve functional
parity between the two orientations, meaning if the user is in one view, they should be
able to achieve all of the same actions that they can in the other.
We never want the user to have to reorient the device to kind of stay and complete the
tasks that they are trying to achieve. So we've developed a few strategies that help
you get at this. And these strategies are really just kind of on a screen-by-screen
basis. The same application can use a number of these strategies, depending on the context
it's depicting. And, happily, even the Google Apps that you'll
see cover these strategies. So we have good examples of each of them. We tried to kind
of go broad in the apps that we were creating. So the simplest strategy is stretch. And if
I've got two columns, one of them just gets smaller and smaller and smaller.
If you look at settings, that's how we deal with that. You have a left-hand list which
enumerates all of the settings on the device. And that shrinks as we go into portrait.
The second is that you can kind of stack or rearrange the panes within the view. We use
this pretty nicely, I think, in calendar, where you have a major pane that is your day
or your week or your month view. And then supporting panes when you rotate the device.
We just kind of keep those panes -- those panes contain their own identities and they
just kind of shift around within the screen. The last two strategies are, actually, closely
related. Now, we call them expand/collapse, which is
one that we use in Google Talk. There, you have a friends list on the left
and then an active chat on the right. And as the device orients, the friends list, instead
of having name and icon, just kind of reduces in size so it's just showing the icons of
the different people in your friends list. You can still expand it back by pressing and
bringing it back to its kind of original landscape width.
A variant of that is what we do in GMail when you're reading a conversation in you're in
portrait view, is that we kind of tuck away the list of conversations and it slides off
the screen to the left. But we give the user using up and back a way
to kind of bring that back on and select a different conversation or select multiple
conversations. >>Adam Powell: All right. So how would you
go about implementing some of this? If you watched the talk about sort of an intro
to Honeycomb yesterday, you've already heard about the fragment class and what it's able
to do as part of the new Honeycomb API. If you've watched the Android developer blogs,
you've seen this before as well. So the two entry points to this new API are
going to be the fragment class itself and optionally, the fragment tag in your layout
XML. They can actually have presence within your layouts.
So a really quick intro to fragments in general. They're fragments of an activity. That's the
best way to think of them. It's a way to split up the idea of an activity into multiple components.
And as a result of that, they become a unit of reuse between activities.
The same fragment can have a presence in multiple activities across your app. So depending on
what makes sense for your app in terms of how you want to display your content on a
phone versus on a tablet, then you may arrange those fragments a bit differently.
It also helps with just general separation of concerns. This is not a new software engineering
principle at all at this point. But it -- how many of you have ever written
just an oncreate method that has to wire up a whole bunch of different pieces of your
UI, and it just starts getting very, very large as your UI gets more complex?
This lets you sort of separate out a bunch of those pieces into a little bit more manageable
component. But fragments also don't necessarily have
views. They're a life cycle construct, not necessarily a visual construct.
Like an activity, a fragment gets a number of life cycle call backs for creation when
it gets attached to an activity and on general destruction as well. And they can also save
state in between orientation changes similar to the way that activities do.
But this is a talk about UI, so we're going to go ahead and try to stay a little bit more
focused on that. As Rich already knows, I can talk about fragments for a really long
time. So for compatibility, I mean, obviously, we
haven't shipped any phones running Honeycomb right now, so a Honeycomb-only API doesn't
do developers a whole lot of good if we're really presenting this as a way of dealing
with these vastly differing device configurations. So we have the fragment support library that's
available, free, open source, go ahead and download it, use it. This will work all the
way back to Android 1.6. That's Donut. So it covers pretty much everything that's still
live and active in the market right now. So all activities extend fragment activity
when you're using this. You can get the support fragment manager. Most of the rest of the
API is pretty similar from there on. But take a look at the link that's on the
slide here if you want to know more about that.
But the interesting thing about creating some of these multiple pane layouts that Rich is
describing is that fragments are really only one part of that story. And they're actually
kind of a small part of that as well. Most of the heavy lifting when working with
these apps is actually done by the Android resource system that's been in place for quite
a while. You've probably seen this sort of a configuration
before as you write your apps. You may lay out several directories in your
resource folder for working with different density screens. So you may have a version
of a particular image for low, medium, and high-density screens. But what you may not
have seen before is that we have a whole bunch of configuration specifiers that the resource
system can pick from for you at run time. So the resource system always tries to pick
the best fit for the current configuration that you've provided as an app developer.
So in this case, as you're working with different screen sizes, you can provide different layouts
for normal, large, Xlarge, X large screens in portrait, all across the spectrum. You
choose where you decide to make these cuts. So how does this actually work out in practice?
Activities can inflate layouts with different fragment configurations.
So if you provide different layout files, then it suddenly makes it a whole lot easier
to create effects like Rich mentioned with the stack here. So since fragments can actually
have presence in layout, you write your layouts in such a way that basically says where do
these containers go on my screen? Where do these panes show up?
And this becomes your activities -- your activities layout that you set to your view content call.
In this case, this version of the layout is placed in layout Xlarge land. So this is our
layout for Xlarge screens. But with a few really simple changes, we can create a portrait
version of the same layout. Now, none of your Java code actually changes in this case. Everything
just kind of wires itself up. You get orientation changes as long as your fragments are set
up to pass their state to their new versions, just like you would with an activity. And,
suddenly, you're able to deal with very robust orientation changes with very little work
on your part. So there are a few other handy uses of the
resource system that you might want to take advantage of as you're writing your tablet
apps here as well. So not only can fragments use layouts with
different view configurations. So these are the panes themselves. List items, you can
have those individual layouts be more detailed or compact as needed, depending on the space
available. And even very simple resources, like integer
constants or Boolean constants can have different values from one configuration to another.
So if your code is dependent on a particular configuration setting in that regard, then
the resource system can actually do that selection for you and you don't have to worry about
doing those tests yourself. Navigation.
>>Rich Fulcher: App navigation. This is actually one of the areas we made
some really significant changes in Honeycomb. I haven't heard as much discussion about it
in the press, but it's a big area. I want to take us into it in a little bit of detail.
One of the critical changes in Honeycomb is that we now have a much wider array of mechanisms
via which the user can kind of dive deeply directly into a lower level of an application.
Some examples of that are, you have richer notifications, where now a notification can
contain a set of controls with it that can take you do different destinations or perform
other actions. You have these rich home screen widgets which
give you more of a glimpse of the app's content and let you pick a particular piece of content
and go right to that in the app. And you have recents, as we talked about earlier.
So traditionally, navigation in Android has been based on the user's temporal memory,
meaning kind of just users are good at remembering what just happened. They're slightly less
good at remembering a sequence of things that happened shortly ago.
So the -- knowing what just happened is great for hitting back and just snapping back one
step to the prior context. But it gets more -- there's more potential for confusion, bad
kind of user confusion, if the app has a longer sequence built into it.
The example I like to give for this is, if you go to a grocery store. You go to the grocery
store, you go to the produce aisle, and you fill your cart with seven or eight things.
If I were to stop you as you were exiting that aisle and say, "What was the last thing
you picked up," you can probably say, "A kumquat." If I asked you to take the seven things in
your card and order them in the reverse order that you picked them up, that's a much heavier
task, and not necessarily one -- even if you can perform it well, it's the kind of cognitive
load we don't want to impose on users. Users are good at structural memory. They
remember the relationship between different screens within the same application. And users
have a lot of strong conventions built up from the Web context that, you know, there's
a convenient way for me to get home or get upward in the upper left of the app. And as
users saw the Action bar, they started to have that kind of expectation in testing.
And it's also -- just there are clearer suggestions of what the thing immediately above this thing
will be. And the users have just a richer model there.
Back to the grocery store, you probably know where all of the individual aisles are. You
have a good sense of that. You don't have to think about it very much.
So we wanted to be able to address both of those in Honeycomb. So in addition to the
system back, which still handles the history of moving between related screens, we've now
added an application up, which we support through the Action bar, and we just support
by transforming the app icon by putting a little left-pointing Chevron beside it. That
lets the user navigate hierarchy within the app.
Sometimes those two actions will do the same thing. Here's a quick example. If I'm in contacts
and I'm looking at the list of all contacts and then I select one particular contact to
see their details, well, in this case, if I hit back, that just takes me back to the
list of all contacts. If I had hit up, it would do the same thing. But that's not always
true. Let's take the example in a slightly different
path. Now I am starting contacts. I go see a detail
for a particular contact. And then now I'm going to choose to e-mail that contact. So
I hit on their e-mail address and I launch into GMail. Now we actually see distinct behaviors
between back and up. Back would just walk me back to the contact
details. But up from compose would say, "You know what, I want to stay within GMail, and
I want to navigate here." So what do we want you to do in the apps that
you're building? The first one is pretty straightforward. Support
up. If you're going to use an Action bar, use that left spot to have an up affordance.
The second is, if you have deep system links in your app, just do a little bit of work
to make sure that the back behavior is -- matches the user's expectation.
So if you're kind of deeply diving into an application from a widget, it makes sense
to have back also walk up through the application. >>Adam Powell: There's a new API for this
in Honeycomb. You're familiar with just the general start activity call that you can make
that just takes an intent object. There's a new start activities call that takes an
array of intents so that you can actually construct an entire task stack as you begin.
>>Rich Fulcher: The last pattern we want to cover quickly is kind of going beyond simple
lists. So you've noticed in all the Honeycomb examples
that Christian showed earlier. You have all these different views that you
can support for these media-rich applications. We want to make it more -- want to encourage
users to just browse through the content and explore a little bit more freely.
And also, just going beyond simple lists lets you break up the monotony of simple list views,
that you can create these hero moments within your application. You know, that would be
a great screen shot to put in the market to demonstrate what your app can do.
So we have a lot of different flavors of this in Honeycomb.
If you look at the books app, you know, it's about showing just a handful of titles in
kind of rich detail. You know, I don't need to see a ton of different books. Just focusing
on the last few that I've been reading covers a lot of use cases.
YouTube goes the other direction completely and says we're going to show you this vast
sea of content that exists out there. We're going to go wall to wall with video screens,
and they're going to wrap around. You can kind of even imagine that they go around behind
you if the tablet were just a little bit wider. We take kind of a -- an in between approach
in the market where we have a promotional area that has this rich kind of exploratory
component as in the pane at the top. But we also have more traditional elements on the
screen as well. >>Adam Powell: So implementation of some of
these things. There's not a whole lot of specific guidance that I can give for this, because
as Rich said, as soon as you start doing the same thing in many places here, then it kind
of dilutes the experience of some of it. So this is where we say be really creative.
We have the carousel view, which is the component that we used in several of our applications
in Honeycomb which we're open sourcing along -- as a sample for I/O right here.
So this is implemented using the new renderscript APIs in Honeycomb. And it's really intended
for customization. So some variant on this was used for both
books, YouTube, and all of our other applications that used some sort of, like, 3D carousel
during Honeycomb's development. So take this and really sort of make it your
own. We've also got a few other components that are either out already or will be shortly.
We've got the fragment pager and the work space, which encompass essentially your left-to-right
paging navigation that a lot of you have asked us for many times in the past. But specifically,
we kind of want to gear people away from using the gallery widget for a lot of this. Because,
in general, the gallery widget is for choosing single items, single images out of sort of
a film strip type of list. It's really not meant for the types of full-screen things
that we see a lot of developers try to do fairly commonly.
And now here's Roman to walk you through sort of what happens when you bring some of this
all together, and using the Google I/O app. >>Roman Nurik: Thanks, Adam. Thanks, Rich.
[ Applause ] >>Roman Nurik: All right. So we have just
over seven minutes for a demo for an application that actually took over two months to write.
So -- just kidding. Let me quickly introduce myself. My name is Roman Nurik, on the Androids
Developer Relations team, a developer advocate. Also the tech lead and designers for the Google
I/O app, which hopefully all of you have installed. And if you haven't, please install it now,
because that would make me really happy. First of all, we're going to do a quick demo
of the app. Then we're going to talk through some of the things that, I guess, were swirling
in our minds as we were thinking about how to implement this and how to make this a really
solid demo app. I'm going to leave this for one more second,
and it's gone. So let's actually switch to the demo. to the
-- the WolfVision thing. So this is the I/O app on a tablet. I'm first
going to demo the tablet and then jump into the phone.
Here's the I/O app. I'm actually not connected to the Internet here. You're just going to
see a Web page not available. On the left, this is actually the home activity;
right? On the left, you have the dashboard fragment, which is pretty much a kind of a
launching point into the other parts of the app. And on the right, you have a realtime
stream fragment. It's not showing up right now.
So you have two panes. And we use this kind of -- these two panes to take this large amount
of screen real estate and do something very useful with it. You'll see later on on the
phone how we kind of map this to the phone. So if you first go into sessions, you'll notice
a couple of things immediately. You'll notice that at the top, we have the Action bar that
comes with Honeycomb. For the up affordance, we're actually using a logo instead of an
icon. And also using for that view section just the title, which is "sessions" for the
activity. We also have some common actions. Right now,
there's nothing we can really do. So it's just a search key.
So let's actually go and open our own session. Now you'll see that we actually are populating
that empty area, that second space, with more detail. And now you'll actually notice that
there are some action buttons that are populated from that fragment.
So the important thing to note here is that there are actually three fragments on the
screen. And this will be important in a second. But three fragments on the screen. On the
top left, rather, you have a tracks dropdown fragment. Below that, you have the sessions
fragment. And then to the right, you have the session detail fragment.
So let's go and jump into schedule, which is another important part of the app.
You'll notice that here there are actually two panes. On the left, you have the calendar
fragment. And on the right, you have kind of an empty space where we'll populate content
momentarily. So if we jump into one of these blocks, we'll
notice that that gets populated with the sessions fragment from before, as we just showed in
the previous screen. And, again, this is just part of fragments that you can reuse them
across activities. That's one of the greatest parts of them.
And if we select, say, another session, we'll replace that with -- with the session detail.
And you'll notice that there are fragment bread crumbs here that indicate what is kind
of the relationship between the session detail and the sessions.
And if we press "back," you'll notice that the back stack is kind of very closely tied
with the way fragments work. So -- Oh, and there's one more thing I wanted
to show on this screen. You'll notice that we're actually using the work space to allow
flicking left and right between different days.
So I think that's it for the -- actually, there's one last thing I wanted to show on
the tablet. That's what we do with portrait. So if we jump this into portrait mode, you'll
notice that we're using the stacked orientation strategy. So, basically, we're reorienting
our fragments to make most -- to make the most sense of the space available in portrait
mode. So let's actually jump onto the phone. There
we go. Just give that a moment, too. There we go.
So if we open up the I/O app on a phone. Let me zoom in a bit. If you open up the I/O app
on a phone, you'll notice that here there's really only one primary fragment, whereas
on the tablet there are two. So here, there's simply just a dashboard. And what we've done
with the realtime stream, we've actually created a separate affordance on the bottom right
of the screen to let you get to that as a separate activity.
There's an Action bar at the top. And as Adam and Rich mentioned, on phones right now, there's
no kind of native Action bar component. But this is a custom component that we'll talk
about in a bit in terms of how it's implemented. And let's actually jump into sessions.
You'll notice that there's actually a logical progression of three separate activities that
performs the same task, effectively, as what we would have done in one activity in the
tablet, simply because we don't have that much space to work with.
And, actually, the fragments used in these activities are all the same as the fragments
used on the tablet. So, again, there's endless amounts of code reuse. And that's something
that's really, really powerful when using fragments. So I can't emphasize that enough.
Or maybe I can. I'll stop here. Okay. So I think that's all we wanted to show
for the demo. Let's actually jump back to slides.
So here's a very quick sample of some of the things that we just showed for those that
didn't see it in full detail. I'll just quickly run through this since we're
running a little low on time. Basically, you see side by side what a certain
activity looks like on phone versus tablet. How does this work? The first most important
thing that we can say here is that it's a single APK. It's a single binary that you
can install on a phone and a install on a tablet and get a very similar, yet at the
same time, very different experience. It's really optimized for the device that you're
on. Some of the ways in which this works. We use
a lot of different resource directory qualifiers, as Adam hinted at before. The base set of
resources that we provided, the base layouts, the base drawables, the base styles, dimensions,
everything, those are all for the phone layout. We also added on another set of resources
specifically for tablets, for Honeycomb tablets. And we do that using the Xlarge V11 resource
directory qualifiers. The reason we did Xlarge and V11 and not just Xlarge or not just large
is that we really wanted to -- we really wanted to really deliver an experience for tablets,
for Honeycomb tablets, that used all the great tools that Honeycomb had to offer that wasn't
previously available on Gingerbread. So, for example, fragment and bread crumbs is something
that we used in some of the Honeycomb layouts that just weren't available in Gingerbread
and below. And so we had to make a concession where,
let's say you had a Gingerbread tablet, since Gingerbread does support the Xlarge screen
size, if you had a Gingerbread tablet, you would still get the phone experience. It's
not the optimal experience, but it's also something that still does work.
And, of course, we're using -- we're heavily using the fragment compatibility library,
which I will not beat to death by talking about more.
So let's go on to the next section and talk about some of our activities.
So there are really three different types of activities in this app. There's first the
universal activity that -- it's just a, I guess, in quotations. It's not a real name.
But universal types of activities that are the same pieces of code that run on both phones
and tablets. They may use, you know, different fragments. They, you know, may have switch
statements in certain cases. But most of the core code is the same.
You also have phone-specific activities, such as the sessions activity. And then tablet-specific
activities such as sessions, multipane activity. The important thing here is those are just
shell code -- those are just shell activities. They don't actually have that much code in
them. They're maybe 20 lines, 30 lines at most. All of the hard work is done by the
fragments. We also have a couple of activity helper classes
that we wrote for this. Basically, they do things like setting up the Action bar, setting
the kind of the title bar color, things like that. And those are, again -- there's two
separate ones. There's one just for phones, and there's one that takes what the phone
code is and layers on an additional function -- set of functionality just for Honeycomb.
And so you'll notice, if you look at the code, that activity helper Honeycomb extends from
activity helper, so it kind of layers on that extra layer of functionality if it's available.
And the Action bar, as Adam mentioned, is kind of a neat thing. It's kind of a tricky
thing. So I'll talk about it in a little detail. Basically, the way we do it is -- the action
bar is basically just a set of normal views; right? It's a linear layout with some action
-- with some image buttons. The way it's really done is that, first of
all, we have this simple implementation of the menu interface. We instantiate it. We
then tell the activity to populate it with all the menu items that it thinks should be
shown. So if you have three fragments and each one
wants to show an action button or -- sorry, I'm probably misusing terminology -- but if
each one wants to show a menu item or an action item, basically, the activity will group those
together, populate the menu, and then pass that to the for loop that you see here. The
for loop takes those menu items and then adds each one to the action bar.
So one thing you should keep in mind here is, obviously, not to -- you know, not to
use this with, you know, let's say, four or five action items, since you'll be complicating
the action bar. But that's something that is currently -- we're
kind of working on it to improve that. I'm running really low on time, so I'm going to
skip through a lot of this. Two other things I wanted to mention quickly
is that tab drawables. You'll notice that tabs look very, you know, specific, very different
on Honeycomb versus on Gingerbread. So we actually have customized some of our tabs
so that they really, you know, mesh well with the rest of the system.
For example, as you see at the top, there's kind of the Gingerbread or phone tabs. And
these actually stretch to fill the entire screen. And at the bottom, here are some examples
of the tab drawables that we use for Honeycomb, which are more like that. And they're actually
using wrap content instead of stretching to fill.
Lastly, a really important point here is that you don't always have to tweak, you know,
your entire layout. You can just tweak some of the dimension resources used.
So, for example, if you want to just bump up the font size a bit so that it's a bit
more legible on tablets or tweak the padding, you can do that using the resources system.
You simply need to have separate dimensions resources for that.
So that's it for -- that's it pretty much for the demo and the walk-through of how it
works. I really advise you to just look at the code
and see what you can take from there and use in your own projects.
The code for the I/O 2011 app is open source. The project was formerly. I/O 2010 app. You
should be able to get all the goodness there. To recap, we talked about some of the design
goals for Honeycomb. We talked about some of the influences and inspirations for the
holographic UI and some visual design tips. And then Rich and Adam spent a while talking
about some of our awesome new patterns that we're really advocating for. And lastly, we
did a demo of the Google I/O 2011 app. So with that, I'd like to invite you all to
now ask questions. You can fire Google Moderator or ask live
questions here. And do, please, provide us feedback so that
we can give you an even better presentation next year.
Thank you. [ Applause ]
>>Roman Nurik: So there's mikes up here. There are -- I don't know if there are mikes back
there. There's only one mike up here. So we'll take
a couple live questions. And then we'll look at moderator. We have about five minutes.
So.... >>> Will any of those components that you
mentioned, like, say, the work space that's inside of I/O 2011 app, are you going to be
repackaging those as, like, Android library project for wider reuse or is that our job?
>>Roman Nurik: You want to talk about that? >>Adam Powell: For the moment, that's your
job. It's available open source as part of the I/O app right now. We may get some more
libraries out there to offer a few more widgets for this functionality. But we're still kind
of working on that. >>> Okey-dokey.
>>Roman Nurik: Any other questions? There's one back there.
>>> Yes. So we're about to embark on a redesign of our application for Honeycomb, and I know
you can't speak too much about Ice Cream Sandwich just yet. But if we start going with the hologram
type style of things, are we going to have to do significant redesigns when we're looking
for phones in the future? >>Matias Duarte: I'll take that one.
No. Everything that you see in Honeycomb represents the direction that we're taking Android in
general. And you'll expect to see more of that not exactly the same, refined and better,
in Ice Cream Sandwich. >>> Great. Thank you.
>>Roman Nurik: So it's actually a take one moderated question. Will it be possible to
create HTML-based -- that went away. There it is -- will it be possible to create HTML-based
home screen widgets in order to display a live Web page, JavaScript, or sockets on the
home screen? >>Adam Powell: I don't think we have immediate
plans for that right now. But we could look into it.
>>Roman Nurik: So stay tuned. When will a real UI design tool that's compatible
with interface builder blah, blah, blah. Basically, look at Xav's talk later this afternoon. They're
-- Xav and Tor. They're going to be demoing a new UI design and layout tool that we've
been working on heavily. So you can check out that talk for that.
Let's see another live question. >>> Thank you. I'm just wondering what the
benefit is on your phone version of the app using a new activity rather than using the
back stack method of fragments. >>Roman Nurik: It's a good question.
I don't know -- I personally don't have, like, a preference either way. I know that, you
know, you can definitely implement the same thing by just having one phone activity and
then several fragments that swap in and out. I found that it was a little easier just to
have separate activities. Also, we make heavy use of intents throughout the app. If you
look at the intent model and kind of the content provider model, there are a lot of things
there that didn't naturally or immediately map to having just one activity. So there
would be a lot of code that you would have to reimplement.
So definitely both can work. We just chose one. I think that the other could work as
well. But if you guys have any other comments. Okay.
>>Adam Powell: No. That covers it pretty well. >>> Thank you very much.
>>Roman Nurik: Sure. >>> You mentioned launching the activity with
a couple of intents before the one the user actually sees. So when they receive a notification
or something. What other uses would you have for creating
that back stack on launch? >>Rich Fulcher: I think the biggest one is
-- we hinted at it a little bit here. But the general idea that users will sometimes
have the expectation, if they didn't get directly referred from another application, that they're
just kind of in that app and they're expecting back to kind of move them within that app.
So this was something that was kind of generated by user research, this kind of testing out
the new behavior of deep-dive notifications. I think that's the most critical use case
is a dive deeply into an app. I forget exactly how I arrived there, whether it was recent
or back or some other affordance. And I just -- rather than just restoring you back to
home, it would take you kind of gently back up through that application.
>>Matias Duarte: A rule of Thumb we've used for knowing when that's appropriate is, if
the user has used a system-level affordance to really switch tasks or switch application
contexts, that that's a good sign that they're expecting to really kind of completely go
from one building to another building. And so when you're deep-linking in through a widget,
when you're following a notification, when you're following some kind of specialized
shortcut on home, those are all appropriate places to build them a reasonable back stack
in case they don't already have it. If you're directly linking from one activity
into another activity as part of one task, not the user using the system, but just using
an application, that's not usually an appropriate time.
>>> Okay. Thank you. >>Roman Nurik: All right. Any more live questions?
Yes. >>> Got a second one now.
I'm just wondering if there's going to be more development with the compatibility library.
It's pretty good already. But I think it could probably be better and I'd like to see some
of the newer features as they come. >>Adam Powell: We'd like to. What would you
like to see? >>> Well, it would be great if we could get
the Action bar in there. And also, Web fragment would be wonderful.
>>Adam Powell: Hmm. >>Roman Nurik: We'll take those's feature
requests to ask Diane and Adam. I'll file that later.
One more question up here. >>> Can you hear me?
>>> Yep. Last question, I think. >>> So do you know when -- I'm not sure if
this is appropriate. So do you know when the entire alias support
will be coming into Honeycomb? Because when I switch the wheel, like, five degrees, the
lines get too short. >>Roman Nurik: That's probably a loaded question.
There are a number of different ways to do drawing; right. So are you talking about 2D
Canvas drawing? >>> Yeah, 2D, just basic view, I have a view,
and then I kind of turn that a few degrees. >>Roman Nurik: Like a rotation?
>>> Yeah, yes. >>Roman Nurik: Good question.
Adam, do you know the answer to that? >>Adam Powell: I think it's being worked on.
>>> Okay. Any ETA? >>Adam Powell: Not at this time. Sorry.
>>> Okay. Thanks. >>Roman Nurik: I think that's it for questions.
Thanks, everyone, for coming. And give us feedback.
[ Applause ] >>Adam Powell: Thank you very much.
[ Applause ]