GDD-BR 2010 [1E] Android: Effective UI Best Practices


Uploaded by GoogleDevelopers on 20.12.2010

Transcript:
>> BRAY: Okay. Let's talk. So welcome to the second of the four talks in the Android session,
Android track at Google Developer Day, Brazil. My name is Tim Bray. I'm an Android advocate
in the Android group at Google. And you'll be happy to hear that the next talk in the
track is being given by somebody else. So, today, we're going to talk about how to make
applications that will make users happy. Now, how many of you are Android developers? Oh,
more than the last session. Okay. Excellent. Good. So, today, I'm here to be unfriendly.
I'm going to lecture you and tell you to behave better, okay? So I apologize in advance. Because,
you know, one of the main criticisms--one of the main criticisms that we get about Android
being compared to the competition and, you know, I don't want to mention Apple's name,
but--is that the Android apps are not as beautiful as their apps and they're right. So fix that,
okay? So here's the story that we want to see. You know, we want to have a better UI.
People are happier. We want people to perceive quality. We want to get better ratings. You
want to get better rankings. You want to get more installs. You want to get more money.
Do you know where money comes from? Money comes from quality. One thing we've learned
is that even if an app does something that's incredibly useful and incredibly difficult,
if it's ugly or confusing or slow, people will not use it. They just won't. Now, in
the world of enterprise software where your boss says, "Write a program to do this" and
then you write the program and he go and says, "You must use his program," then they will
use his program. I'm sorry boys and girls; it's not like that anymore. Software that
goes in somebody's pocket is very personal statement. And you're talking to consumers;
you have no way to force them to use the software. You have to make them want to use the software.
Of course, it's possible that some of you may be writing Android applications for your
boss in big companies where users will be required to use them, so you can leave now.
No? Okay. So you have to take your app and throw it out into the deep waters of the Android
market and it has to find love based on appeal. And we see so much of this. You know, if somebody
launches an application and it crashes and they give it one star and they uninstall it
and they put a nasty comment on the Android Market and they blog about it and they Tweet
about it. And I tell you, if you publish an app that's not good, it's really, really hard
to recover, okay? On the other hand, five star apps--we're starting to see some huge
success stories. In terms of business success, people are starting to make some real money,
people starting to do some wonderful thing with Open Source. So the rest of the talk
today, I'm going to talk about our advice for how you can avoid the left hand side and
get on the right hand side of this picture. But this requires some mental modeling. We
need to think before we start about in the most general way, what makes people happy?
Well, when somebody goes and gets your app, they have some expectations. They say, "Okay,
here's an app to play Dominos or to find restaurants or to take my temperature or to measure a
running distance" or something like that. So they will have an expectation in their
mind of what your app does. And also, even though this is not fair, they will also have
an expectation in their mind of how difficult it will be to use and, you know, how it should
work. And basically, the measurement of quality in the user's mind is expectation versus reality.
You know, if the expectation is low, it's easy to have high quality. If the expectation
is high, it's very, very difficult. So, really, the absolute measure of quality seems to be
the difference between the expectation and the actual experience. So that's really the
right way to think about it. You have to try terribly, terribly, terribly hard to figure
out what it is that users expect and need and to do better than that. So how are you
going to do that? It's really hard to do that. So very few people are smart enough to guess
accurately what it is that people want from an application. So the Google solution for
this is the public beta, right? The idea is get the code out in front of users as soon
as you possibly can and don't try and guess what they want. Ask them what they want, show
them the software and, you know, if you want to write software to, I don't know, to help
you train for a long distance run or something like that, you know, you have your own ideas
but you can't guess what people are going to want. You have to put it in their hands
and find out. Now, we actually think you should be even braver than that and start to gather
the experience even before it seems reasonable. Now, I have some advice. When you're doing
the public alpha, don't put it in the Android Market, right? Because any alpha is going
to get some bad reviews and the bad reviews don't go away. Now fortunately, unlike some
other operating systems, and I don't want to mention Apple's name, they--you can't--you
don't have to get an app from the market. You can get an Android app from a website,
you can send it in e-mail, you can, you know, put it on a USB key, you can even present
that. So as soon as you have something that works at all, you really need to give it to
a few of your friends and family and your mom and your girlfriend and your boyfriend
and see what--see what they think of it because you'll start to get some real honest user
reactions that will be incredibly valuable to you. And then one of the other advantages
of Android Market is that the release process is instant. So, most of the successful Android
Apps that I see have a habit of releasing regularly. Once per month, sometimes even
once per week. For example, there are many, many Twitter apps out there. The one that
I use is called Twidroid. I'm very fond of it. And Twidroid releases several times a
month, absolutely regularly. And it just gets better and better and better and better because
they listen to what people are saying and they adopt the policy of continuous improvement.
Now, somehow you have to find a way for people to tell you what they think. You know, the
Android Market comments, there's too many of them; they're hard to track. So there are--there
are many websites like, you know, Get Satisfaction and we have one of our own. You can go to
places for people who can, you know, leave a discussion forum and leave their comments
and give feedback. And you should definitely do that. There's a problem with doing that
which is that when people give feedback of what applications, unfortunately, they lie.
You know, they say, "I tried this and it didn't work." Well, actually, if you look at what
they really did that wasn't what they said they did. Or they said, you know, "This didn't
work" or "That didn't work" or "That's fast" or "That's slow" and it's very hard to replicate.
So there's this thing you can do called Analytics--oops--Analytics for Android. And it will give you reports
like this, showing you all the different activities and services and screens in your--in your--in
your application and exactly how often they were visited and what people did and what
path people took through the application. And it's absolutely invaluable. If you're
serious about your application, this will tell not what your users said they did but
exactly what your users really did. And it's actually pretty easy to do this. So, you know,
one of the most common things is people report a bug. Now, serious application has some settings
that people can change. And if you have more than three settings, you have a, you know,
a very large number of possible combinations and it's hard to figure out what could have
gone wrong. Well, with Analytics, you can find out what settings were, you can find
out all about errors and exceptions and so on. And if you look at the code, there's really
not much to it, okay? So maybe, you know, one of the single most important things is
you got to pay attention to your users and you got to measure your users. Another thing
is that bugs are unacceptable. You know, in an enterprise--in an enterprise app where
you get people at desktops, if it crashes sometimes "Nah" they just restart it. And
also, as we at Google know very well, in many cases when you have a bug in a web application,
the user never even notices. I mean, sometimes you use to do a Google search and it doesn't
comeback and you say "Oh, stupid web" and you refresh and there it is. Well, what happened
was there was a bug on the first search and you never noticed. So you really got to--got
to fight bugs. And once again, one of the nice things about the Android Market is that
when you find a bug, you can get it out to all your users very, very, very, quickly.
So for those of you who are not doing test-driven development, please start doing test-driven
development. This is the idea that came out of the Agile Software Movement that when you
write a new routine, you should write the tests first and then write the code until
it passes the tests and then stop. And test-driven development does enable you to produce high
quality software. But even more important, if you do test-driven development, it gives
you the courage to do big refactorings to--when you see some part of your code that's running
badly, you can tear it apart and put it back together. And as long as you have a good test
suite that keeps running, you have courage and you know that you can--you can be brave
and rebuild your software as much as it needs. So, test-driven development is really, really
important. Now, unfortunately on Android, it's much more difficult to do test-driven
development than it is with web applications. It requires a little bit of extra work, but
it's worth the work. If you're going to be living with and maintaining your app into
the future, you really, really, really need a good test suite so that you can sleep at
night. Most people know about this but some don't. Inside the Android SDK there's a thing
called the Monkey. That it's--it's called--it's a testing monkey and what it does is it simulates
a bunch of random user interface actions, touching the screen everywhere, swiping it,
pressing all the buttons, all the things that a user can possibly do. And you should never,
never release an app unless you have exposed it to the monkey first. It is very, very effective
of finding stupid bugs that you would never think of because you would never do those
things but lots of users will do those things. You should--you should have a public bug tracker,
a place you can register bugs. One of my favorite Open Source software projects has a bug tracker
and you register bugs there. And whenever they release a new release of the software,
they send a personal email to everybody who reported the bug saying, "Oh, by the way,
in release 6.1.8, we fixed this bug that you reported last April 14th." And, you know,
that really--that's a really nice thing to do. Okay. So you got to be super aggressive
about bugs. The next thing you have to worry about is speed. If you--an application not
responding is a horrible, horrible thing you should never allow to happen. People are incredibly
sensitive to the performance of mobile applications. And we do have another--last talk in the Android
track this afternoon is about how to make your app--Android applications responsive
and fast. It's super important. You just absolutely have to worry about it. So I'm not going to
talk too much more about that. Let's move on. So assuming it doesn't crash and assuming
it does more or less what people want and assuming it's reasonably fast, the next thing
you have to worry about is this very abstract notion called usability. And it's incredibly
hard to define--to design ordinary things in a way that they're usable. And this, by
the way, is a totally wonderful book. It's been revised a few times. It's quite old,
but it's a--it's a wonderful book and it talks about how to make things that are actually
usable in a day to day sense. You know, the slogan is that in any piece of product, software
product included, "Easy things should be easy and hard things should be possible." And for
the basic everyday operations on a mobile phone which somebody is using with one hand
while they're holding on to the pole in the bus going around corners being crowded by
strangers, the basic things that your application does have to be one or two clicks. Anything
more is unacceptable. So this is the usability stuff. There are all sorts of methodologies
and tools and so on for increasing usability, but I think that unfortunately there is some
magic in here. You know, usability is one of the things that separates great developers
from not so great developers. And it--it's really about talent. And, you know, if there's
error that is possible, somebody will absolutely make it because even--you know, I have this
very, very small simple Android app in the market which is for transferring your phone
log from an old phone to a new phone; the simplest thing imaginable. It's got over a
thousand downloads. I mean, it's crazy. The Android market is getting so big, the Android
humidity is getting so big, it's very, very easy to get 10,000 downloads. If you get 10,000
users, some of them will be crazy. They will do all sorts of stupid things. They will make
errors that you can't possibly imagine, okay? So what do you do about that? You--the right
answer is to try to make the errors impossible, okay? Just set it up so it simply can't get
into a fix. Now, there are also some very simple, straight forward techniques you can
do to improve usability. And people are used to seeing lists of things and they know how
to click on them. You know, they know what the controls on a music player should look
like, they know what a back button should look like, they know what a search icon should
look like, they know what a menu should look like. Don't invent new stuff, okay? When there
are existing patterns, the people are well trained to do, just use them, okay? Also,
please bear in mind that a lot of Android phones are very small devices and a lot of
people like me have big, fat, clumsy fingers. So please, no small buttons. Big buttons,
big targets, things that are easy to hit. Also, I don't know how old you are, but you're
all going to be one year older in one year and I guarantee that none of you have eyes
that are getting better. So--and, you know, I'm over 50 and my eyes are not what they
once were and, please, no teeny tiny texts. You know, I have to wear reading glasses to
read anything that's small and I love Android apps that have, you know, the important stuff
in big letters so that I don't have to put on my reading glasses to see it; big fonts.
And finally, in usability, remember those analytics that I was talking about? The analytics
are incredibly important for usability because they show the patterns that are--people are
taking through your code. Now, in any application is going to be subject to an 80-20 rule, which
means there's probably 20% of the application where people spend 80% of their time. And
in that 20%, you really have to work hard so that everything is one or two clicks at
most. And here's another way to think about it is if--to use your App, if people have
to read a bunch of complex instructions you, are doing it wrong, okay? It's worse than
that. Okay. I'm serious. People are used to picking up very complex computer games. My
son, you know, this little boy this big, he goes to a complex computer game and it always
comes with a book of instructions. I give him the instructions, "No, Dad, I don't need
that. Go away," you know. He just starts playing and he figures it out. And people--we have
trained people that they should not need training, okay? And every time you add one minute of
instruction that's required to use your App, you lost 50% of your audience. I'm not exaggerating.
It's not--sometimes you have to do a little bit. Even I've seen some popular games where
you need that, but, you know, any instruction is a bug; you know, instructions are a bug.
So if you're--once--so let's assume you're--you do useful stuff, you don't have bugs, you're
fast, you're usable, what else do you need to be? You need to be beautiful, okay? You're
application has to be beautiful. And what is beauty? Well, beauty is in the eye of the
beholder, we say in English, and the eyes are very sharp. I mentioned that in the area
of Twitter, in particular, there are lot of Twitter clients and I actually--I'm interested
in that area so I watch that area quite closely. And here's the secret, most of the Twitter
clients are about the same. They do about the same things and most of them are actually
pretty good. And what people talk about when they talk about it is how they look, you know,
"Oh, this just looks great. This looks great." People respond very, very, very strongly to
aesthetic beauty. So how do you make your application beautiful? Well, it's easy. First
of all, you have good typography which means that you have, you know, kerning which is
how close letters are to each other. You put a good font that's appropriate for the application,
you do the justification, justified left, justified right, justified center, both sides,
you pick the right font weight and you pick font weights so they contrast with the other
font weights and you worry about letting which is how close the lines of text are to each
other. And then, you talk about the color and, you know, you worry about the color transparency
which is the Alpha channel and you worry about color spaces. Do you want SRGB or Adobe color
space and what--do you need a--you need a palette of a small number of strongly related
colors. And then you need to worry about the contrast level, particularly as it applies
to different kinds of screens. And then once you've solved that, you have to worry about
the lay out, you know, should it be landscape or portrait? And one of the important aspects
of design is where you leave empty space on the screen. People need empty space for their
eyes to focus on the important things. And, you know, you need to worry about whether
it's for handset or a tablet. And then, you know, any application that's interesting is
going to have some motions. You have to worry about animations and graceful transitions.
And when somebody touches, what visible indication do you give them that it's touched? So do
you about all that stuff? I don't see a lot of hands going up. I have to say, most computer
programmers are idiots when it comes to this stuff. It isn't easy. You need a lot of talent,
you have to go to school, you have to practice, you have to be good at this stuff to do it.
There's only one answer; hire a professional, okay? Would you hire a painter to write your
code in your application? Well, then, why are you doing the design, right? So are there
any professional designers in the crowd today? Stand up, please. Stand up. Come on, hire
those people, okay? You need them. I'm serious. Let me give you an example. One of the guys
in the--in the--in my group at Android, this guy named Reto Meier and he's--he wrote the
best book on Android by the way--and he wrote an application that's quite popular to track
earthquakes everywhere in the world, okay? And it turns out there's a lot of people who
are really, really interested in earthquakes. And he's down--they've downloaded a huge number
of copies and Reto is a really good programmer, and so this was his application. And he wrote
it and then he got the idea of talking to a designer. And the designer he talked to
is another guy in our group called Roman Nurik who's a pretty good designer, and then it
looked like that. Uh-huh, that, that. How many of those ideas would you have thought
of? Okay. Designers, it's difficult sometimes because designers and software creators tend
to have different values, different world views, different ways of thinking about things.
Also, they dress differently from us, you know? They spend a lot of money on clothes
and they still wear black all the time. I don't know, I can't figure it out. But, you
know, we need these people. One of the main things that will make a difference between
having a successful application and a not so successful application is whether you have
a good design pro working on it. Okay. So you've all agreed for your next App you're
going to go get a designer, right? So you're fast, you're bug-free, you're usable, you're
beautiful, what else is important? Well, you need to look like an Android App. We see too
many cases were people go and say, "Oh, I'll just port my Java MA App over" or even worse,
"I'll just go port my Windows App over and put it on Android." And this never ever gets
a good result. Well, sorry, it does with games sometimes because, you know, once you're into
the game and, you know, the game is just what the pictures are on the screen. But even for
games, the things like, you know, the instructions menu, the high scores, the stuff like that,
we see these people hoarding over buttons and menus and things from other systems and
it always looks wrong. The Android applications tend to have a strong look; they have a lot
of things in common. This is incredibly valuable for the users because they just know how to
use things. Things like the back button. The back button is one of the best things about
Android. Don't steal it for your application. You know, don't go and use it for something
else. If you have a list in your application, please don't code up your own list. Just--the
Android framework includes eight kinds of lists. They all work; they're good. Please
use them. Don't invent your own. Please do not invent your own menu system, okay? Android
has a very good menu system built in. It comes more or less for free when you press the menu
button. If you're--if you don't look like an Android App, people will notice this and
they won't--they won't be able to say clearly why they don't like it. They won't say, "Oh,
it doesn't look like Android." They'll just say, "Oh, it looks weird. I don't like it."
So be a good citizen of the Android ecosystem. Okay. So those, I think, are the essential
characteristics of a--of a highly successful quality user interface. I'm going to give
you some things, some general principles that we believe in that this applications you have.
So the first thing we believe in is clarity over simplicity. There's a gentleman named
Edward Tufte who's written several books about the display of information. And the big lesson
that he taught us--and he's got lots of studies that prove this--people say they want simplicity
but that's not true. People want information. People want a lot of information but they
want it displayed in a totally clear way so that it's easy to understand. Consider a,
you know, this view of the--this is the App that's running on Android when you put it
in the dock and it's sitting there on your desk or beside your bed, and there's actually
quite a lot of information in there. There's the--it tells you when the alarm's going to
off, it tells you the current time, there's a control to dim the screen, you got the current
weather, where you are, how the battery's charging, your branches to music into alarm
clock and things like that but it's not crowded. You got a good designer on there. They achieved
clarity. So do not starve your users of information. You have to go to a lot of work to crowd it
in. Now, another principle is that chrome is bad. What is chrome? Chrome is all the
stuff--oh, jeez, I shouldn't--I should use a different word because chrome is something
else at Google, doesn't it? Anyhow, so when people--when browser people talk it, they--when
they say chrome, they're talking about stuff around the browser; the tool bars and the
switches and the sliders and the buttons and the decorations. And on desktop applications
because we have a lot of room, we have the temptation to put a lot of chrome around our
stuff. And you just can't do that on a phone. So this is one of my favorite applications.
This is an application called TripIt, which I really recommend. And it is a travel application.
And the great thing about it is you don't have to tell it. What happens is when you
book a trip, the travel agency or the airline sends you an email, you send the email to
TripIt and it automatically creates your schedule for you. It's really brilliant. And so, look
at this. I mean, they've just packed an incredible amount of information onto the screen without
losing clarity and because they just got rid of all the--all the stuff that wasn't totally
essential. So if you get rid of the non-essentials, you win. Another thing that we believe strongly
is that it's really a mistake to store any information--important information permanently
on the phone, okay? I think--we also believe that it's a real mistake to store important
information on a personal computer. Telephones can fall into the toilet. Telephones can be
stolen. Computers are heavy. Often, you don't have your computer with you. We think it's
completely wrong that to put information onto a phone, you should have to plug it in to
a computer. I mean, suppose the computer the computer isn't here? Suppose the computer
is stolen? Suppose the computer crashed? For anything that matters, it should really live
in the Cloud, which means it's available anywhere and it can't fall in the toilet. So this is
an app--this is a screen shot of Dropbox. I assume lots of people know about Dropbox.
If you don't know about Dropbox, you should get it. It's just one of the world's great
applications. It's just a--it's just a network disk drive. Nothing fancy about it, but it's
got a really nice client for Mac and Windows and--I don't know with Linux, but it's got
a nice Android client. It's got--Linux, yes? It's got a nice Linux client. It's got a great--a
great iPhone client. It basically works from anywhere. You just put stuff on it and then
it's there for anybody and it's really easy to share. So get anything that matters off
of your fragile, insecure, local computers. So--and Google clearly has bet on this. And
we're going to be doing some things in music and so on that follow the same principle.
Here's another principle that's just more subtle, which is that people hate being warned,
okay? They don't like a dialogue coming up and saying, "Oh, are you sure?" So a better
principle is to never do that. So if you look at Gmail, for example, this is the Android
Gmail app, if you delete some mails, it doesn't--it doesn't come up and say, "Are you sure? Did
you really want to delete those mails?" It's just, "Okay. Oh, and by the way, you can undo."
So an undo is better than a warning. And, in fact, particularly if you're using a Cloud
as backup for your operations, you should really be able to have almost infinite undo
in any application. Really, people should be able to work for an hour and then say,
"Oh, I didn't really mean that. Make it all go away." And the more undo you have, the
better. The fewer warnings you have, the better. Don't get in people's way. When somebody wants
to delete a mail, they want to delete a mail. They don't want to see a dialogue. So that's
good. One thing that's coming at us very, very fast is multiple screen sizes. So, here,
we have some small Android phone, a Nexus One, a Samsung Galaxy Tab and a Google TV.
This is great news. Anybody who says that one size is the right size for everybody is
just crazy. That's arrogant. Some people carry phones in their pockets. Some people carry
phones in their purses. Some people carry phones in their briefcase. Some people want
to--want to run Android on their TV. All those things are just fine. So it's a good thing.
And whether you like it or not, it's coming. There are going to be a huge number of different
sizes of devices coming at us and you, as the developer, have to do a good job with
that, okay? Now, the Android ToolKit is full of facilities to help you with this stuff
so that you can provide alternate application layouts for different sizes and shapes and
screen densities and things like that. And start getting ready for that now because it's
coming at you very, very quickly. And from your point of view as a developer, this is
basically a good thing because it means that there are more devices to run your apps on.
Very closely related to that, please don't lock--you see, Android allows you to lock
your application. It's running only landscape or only portrait mode. Don't do that. That's
a really, really bad idea. Maybe it's okay for a game, but not for anything else. Don't
tell people how they can hold their phones. This subject is so important in the last two
slides that we're going have a whole session on it. The next session after the break is
going to be on how to make sure your Android app will run on lots of different kinds of
devices. And it's not going to be by me. Another thing, you're going to laugh, but I mean this.
Icons are really important, okay? When somebody picks up their Android screen--phone and looks
at it, what do they see? They see a bunch of icons. If yours is the ugly one, that's
no good. So we've recently published a new set of guidelines that say, you know, how
icons should look; a bunch of rules for how the lighting should be, what the shape should
be like, what the color should be. Please, go read those. And we're starting to get some
good tools out there to help you develop icons. So focus on your icons because they really
matter. When people interact, it's absolutely wrong if you're--when people touch the screen,
something should happen. They should see that they've touched the screen. That means that
for most buttons that are in your applications, you need to have them in four forms, okay?
Another thing that we believe is that your application should cooperate with other applications.
I--you know, so if you hate a URL, don't try and be the web browser; call the web browser.
If they want to send mail, don't send mail. Just give control to the mail program. Android
is just carefully designed so that the user experience is presented as a combination of
a lot of different applications working together. Here's a beautiful example; two applications
whose names that I forget; one of them is Open Table and I'm not sure with the other
one. Anyhow, one is a thing for finding and reviewing restaurants and the other is an
application for booking tables, for making reservations at restaurants. And so, the rep--the
apps--so they got together and they agreed on an intent, Android has intents. And so
the application finds restaurants. When you'd find it, you'd say, "Oh, we'll try and book
a table," and it gives control to the restaurants booking up the table. Isn't that great? Each
of them is focusing on the things that they do really well. Finally, we believe that some
things are sacred. Don't fool around with them. These are the things that are sacred.
So first of all, the status bar. We see a few applications that take over the status
bar and make it go away because I want the whole screen to be red and it's gray. That's
really a totally evil to do and you should never do that. People really, really care
how much battery they have left. People really, really care if they're getting a mobile signal
or not. They really, really care if they've had emails arrive and they're in there. And
if you take the status bar over, you are taking that away and I, personally, will uninstall
an app. If an app takes away the status bar, I'm done with it. Games, once again, are allowed
to do this and that's why, you know, you miss emails and your wife's phone calls and all
sorts of things when you're playing games, but, you know, that's life anyhow. The other
thing that's sacred is the back button. Everybody in the world has been using browsers for as--you
know, anybody under 30 has been using browsers for as long as they could sit up. And we've
trained the entire population of the user--of the world that wherever you've been, you can
get back there. Just press the back button. So please be careful. When you--when your
application is built with a bunch of activities, you know, think about where should the back
button take you. Sometimes you've got a particular error condition and you don't want to go back
to the previous screen, when they hit back, you want to go to the front screen or something
like that, okay? So you need to think a lot about where should the back button take people.
And if people hit the back button and they're surprised, you've really failed as a developer.
The menu button, once again, the menu button acts the same on all Android apps. And it's
really important because the menu button is very powerful because it allows you to put
the 20% of controls that people use all the time on the screen and not try and squeeze
in the minor controls because everybody who uses Android for more than about a day learns
that "Oh, I want to do something. I don't see how to that. Well, I'll hit the menu button,"
right, and they expect to find it there. So don't fight that. Go with it. And there are
a few applications where you hit the menu bar and nothing happens and that makes you
feel something's deeply wrong and the application must be broken or something like that. At
least it should say, "Oh, this is version 1.5 of the application" or something. I don't
know. And then, finally, the search button. Speaking as a representative of Google, I
think I can say that we've proved that there are many different navigation schemes through
information. But by far, the best is to open a search window, type in a few characters
and press enter and let the system find it. So I was reviewing a new application the other
day, it was a newspaper reading application and it has hundreds of newspapers in it from
hundreds of countries and I had to scroll through this huge list of all the countries
in the world. And then I went to, I think, U.K. Britain and they had 300 newspapers from
Britain and I had to scroll through this huge list of newspapers. Well, I just want to see
if they had the Guardian. This is crazy. Just "Search", "Guardian", find it, right? So basically,
the majority of screens in your application should have a search button. Okay, now I'm going to talk about a few tools.
I'm almost finished here, but I'm going to talk about a few tools and leave time for
a little bit of questions at the end. This is stuff that we're going to be talking about
in the next the talk, but the amount of work that it takes to support multiple different
screen sizes and densities and orientations is not that high. Learn how to this stuff,
okay? There's an incredible number of possible combinations of screen sizes and densities
and orientations and you don't have to fill them all in because the Android framework
is actually pretty good. It's scaling things to fit the sizes and densities available.
But the more you fill in, really, the better. Another thing that you should learn how to
use is 9-patch graphics. I don't know--a lot of people don't even know about this stuff,
but it's really valuable. This is just a little PNG file and the system will stretch the last
row of pixels, the border pixels, all the way across. So this is absolutely the best
way to do a fancy border or to fill in odd places in your application. Learn about 9-patches.
They are a really great way to make your applications look great. And if you're going to have buttons
on your thing--on your--on your screen that people push, there's this thing that not enough
people use called the Selector. So you put a button in there and then as the people press
it, it will automatically switch in different renditions of your button. So--and the difference
that it makes when buttons change color as you touch them, it just makes the whole thing
more enveloping, more pleasant, more friendly. So I'm about finished but, you know, I want
to show you a graph. One of the good things that can happen if you have a good app is
that it can be featured in the Android Market, okay? So when you go to Android Market on
your phone, you see a list of featured applications. And the process by which an application gets
featured is a combination of an algorithm and some human judgment, okay? And one of
the things that goes into the human judgment is usability, beauty, speed, the kind of things
that I have been talking about here today. You'd think that there are thousands of great
apps out there, you know, wanting to be featured. We actually have to work pretty hard to find
the apps to be featured. So if you got an app that's good, it stands out from the crowd
and is beautiful and fast and usable, you have a pretty good chance of getting featured.
When an app gets featured in Android Market, the number of downloads goes up by a factor
of from 600 time--from six times to about 200 times. So this is an app, just a typical
app. In fact, it's the Earthquake App that Reto Meier wrote. So that was just his number
of total downloads and he was featured there for a couple of weeks and look what happened.
Okay? So that's the reward. But if your app is slow, it won't be featured. If your app
is ugly, it won't be featured. If your app crashes, it won't be featured. If your app
doesn't have good usability, it won't be featured. And not only will it not be featured, it will
not succeed. It's really, really easy to write an Android app. Writing a beautiful, fast,
useful Android app is more difficult. It's a real test of your talent and the job isn't
finished until you've hit all the things that I've been talking about here today. So I'm
going to stop there. Thank you kindly. Okay. Thank you very much. Time for coffee.