What to do about all those buttons?

by Peter Eastman » Wed, 27 Jan 2010 03:15:03 GMT


Sponsored Links
 his is partly a rant, partly a set of suggestions, and partly an
attempt to start a discussion on how to improve a basic part of the
Android UI. But to skip straight to the punch line: Android phones
have too many physical buttons on them, and those button don't work
very well. Now let me back up and explain why.

When Apple designed the iPhone, they decided to completely do away
with physical buttons. Instead, they would have a touch screen that
allowed infinitely configurable UIs. Each application could have
whatever buttons were appropriate for it. This was a very good idea
that worked very well in practice, but they did end up making one
exception: the Home button. They decided that, no matter what options
an application offered at a particular time, you always needed a way
to get out of it, and the only way to guarantee that was with a
physical button.

When Google developed Android, they decided that one button might be
enough for Apple, but it wasn't enough for them. Why? Who knows?
Maybe they just thought more was better. It reminds me a bit of the
mid 80s. When Apple introduced the personal computer mouse, they made
a big point of the fact that it only had one button. "All you need to
do is point and click." But Microsoft decided that Windows mice would
have two buttons, and thus would be more powerful than Macintosh
mice. And then Unix system vendors of course had to make their
computers even more powerful, so Unix mice all had three buttons! Of
course, this didn't actually make them more powerful. It just made
them a lot more confusing to use.

So let's look at the four buttons found on every Android device: Home,
Menu, Back, and Search. Do they really belong there? Do they do more
to help or hurt the user interface?

First is the Home button, the one button Apple felt was required. I
agree with their judgement, and have nothing to say against it. So
let's move on.

Next is the Menu button. I can understand the logic behind it: lots
of applications need to display menus, so it makes sense to provide a
standard mechanism for bringing them up. That sounds reasonable. So
what's wrong with it.

Well, first there's just the fact that it's unnecessary. If an
application wants to offer a menu, an on-screen button would work just
as well. But much more importantly, it turns every menu into a hidden
feature. There is absolutely no way to tell when a menu is
available. The user needs to just happen to wonder, "Does this screen
have a menu?", then try pressing the Menu button to find out. That is
simply a bad user interface.

What can we do about this? It's probably too late to get rid of the
Menu button, but there are several ways to improve the situation. One
is for developers not to rely on it. If you want to make a menu
available, provide an on-screen button as an alternative to the Menu
button. Another option is to establish a standard indication to tell
the user when a menu is available. Perhaps this could be a standard
icon somewhere on the screen, or maybe the Menu button could light
up. But users really need to be told when a menu is available. They
shouldn't be required to guess.

Next comes the Back button. At first glance, this seems reasonable.
The idea of a Back button is familiar to anyone who has used a web
browser, and it works very well there. So why not here?

The problem is that the Back button doesn



What to do about all those buttons?

by Matt Kanninen » Wed, 27 Jan 2010 08:20:48 GMT


  could not agree less.  One of my biggest gripes about my Droid is
that the 4 buttons, which I use all the time, are virtual soft keys,
not real buttons. I also miss the Green send and Red hangup button.

Also I'd just like to say, on all phones you should be able to hit the
green send button to answer the phone without having to unlock it
first. You should have to unlock to initiate a call. That way you
won't pocket dial, but you will be able to answer a phone without
having to look at it.

On Jan 23, 10:14pm, Peter Eastman <peter.east...@gmail.com> wrote:

--


Sponsored Links


What to do about all those buttons?

by Simon Jagoe » Wed, 27 Jan 2010 08:45:12 GMT


 I don't disagree with questioning the UI design. I think it would be a
good idea to give users an indication of when a menu is available, for
example, but I think that saying those buttons should be removed is
taking it a little far. The only one I have had trouble with is
search. And that only because I forget that it is there (this nexus
one being my first android phone). I think when I get used to it I
will make more use of it. I have fired up the browser a lot and
started searching from within it when I could just hit that button.

I find the behaviour of the back button to be quite good and
predictable. If I have been reading email and follow a link, the
browser opens. I click back and I am taken back to my email. If I
instead press home and open my calendar then as you say, pressing back
takes me to the home screen. I think this is better than going to
email because there could be hours between pressing home from the
first task and beginning the second. Say the first task was in the
evening and the second was in the morning after waking up. If the
phone randomly took me into my email when I pressed back, I would
think it had gone mad and there was some obscure bug in the back
button behaviour.

And for the record I don't think Apple is the king of UI design. The
iPhone is probably a good example of where they got it quite right,
but there are also arguments for the physical buttons. An app
developer does not need to draw toolbars or button boxes and design
these elements into the UI. Maybe that is a silly reason, I'm sure
there are others.

--



What to do about all those buttons?

by Peter Eastman » Wed, 27 Jan 2010 09:56:50 GMT


 > If I instead press home and open my calendar then as you say, pressing back

As it should.  That is consistent with the interpretation of Back as
"take me back to where I was before."  Before opening the calendar you
were on the Home screen, so that is where Back should take you to.

The example I gave was a different situation: you press Home, then
Back without opening any other application.  In that case, it ought to
take you back to where you were when you pressed the Home button.
That is consistent with the idea of "take me back to where I was
before."  But that isn't what it actually does.  In fact, it doesn't
do anything at all.

Peter

--



What to do about all those buttons?

by Zero » Wed, 27 Jan 2010 19:40:36 GMT


 yeah, flamewar time !
<rant>
i couldn't disagree more.
a mouse with only one button is useless crap.
a phone with only one button is....

it's ok if you prefer the way apple designs things over everything
else, i do not.
so please, don't question valid design decisions made on other
platforms
simply because they are not to the liking of the apple fan boys.
</rant>





--



What to do about all those buttons?

by Streets Of Boston » Thu, 28 Jan 2010 03:56:04 GMT


 The Back button takes you back until your reach home, just like a web-
browser.

Menu button allows you to save some real-estate on the screen.
Blackberry users are used to it. WinMobile users are used to it.

All your points are valid, but they are a specific choice of UI-design
and i don't think that either choice (iPhone vs Android) is wrong.
They're just different.




--



What to do about all those buttons?

by Peter Eastman » Thu, 28 Jan 2010 06:55:15 GMT


 

...

I'm not interested in a flamewar, and please don't attribute things to
me that I didn't say.  I don't believe that everyone must do things
exactly the way Apple does (after all, I chose to buy a Nexus One
rather than an iPhone), but I also believe we can all learn by looking
at the solutions other people have found to common problems.  I don't
believe that more buttons or fewer buttons is inherently better, but I
do believe that designs can be rationally compared and, when one
design is objectively better than another one, we should use it.

For example, is it better to have a physical Menu button, or to use an
on-screen Menu button?  Either one could be implemented well or
implemented badly, but Android's implementation is objectively
inferior to Apple's implementation in a very important way: users have
no way to know when a menu is available, and that significantly harms
the usability of Android devices.  I also believe there are ways of
improving the implementation to eliminate this problem, and I made
some specific suggestions for ways to do it.

Peter

--



What to do about all those buttons?

by Matt Kanninen » Thu, 28 Jan 2010 07:21:19 GMT


 esponses are in line and I snipped a lot.

On Jan 27, 2:54pm, Peter Eastman <peter.east...@gmail.com> wrote:

I believe we all need to look at the iPad. Dissect it. Root it.
Reverse Engineer it. Challenge the Apple p...@t3ntz. Risk pissing off
Apple.


Physical button. The answer is almost always physical button, but you
don't want more then 26+10+4+5+2+2 buttons where x is user
preference.
26 letters, 10 numbers, the 4 Android buttons, an up, down, left,
right and center button, a volume up, a volume down, an answer and a
hangup button. I also like a period, an @ sign, a shift key, and a
trackball myself.


We are teaching users to always check the menu button. Some
developers don't use it, but that is not a Framework or a User error,
it is a Developer error.

On Jan 26, 5:56 pm, Peter Eastman <peter.east...@gmail.com> wrote:

Home means clear the stack. Back should do nothing after you clear
the stack. What does home mean to you? If you want similar
functionality to Home without clearing the stack you can long press
the home.

On Android "Exit" is "hit back 7x". It should only take them back
until the last time they hit Home.

On Jan 27, 3:40 am, Zero <zeroo...@googlemail.com> wrote:

A phone with only one button is crap. You need at least 2, 1 to
answer and 1 to hangup.

Do there already exist apps that let you use an Android device as a
keyboard for a text editor, which is displayed on an iPhone screen?
I'd like to use my iPad as a screen, and my Droid as my UI. I'm
willing to slave a Windows PC in the middle if I have to.

-Matt Kanninen
-Mobile Developer

--



What to do about all those buttons?

by Peter Eastman » Thu, 28 Jan 2010 07:33:08 GMT


 On Jan 27, 11:55am, Streets Of Boston <flyingdutc...@gmail.com>



Is it really just like a web browser?  Consider it carefully.

Suppose your home page is "mycoolpage.me.com".  So you start up your
web browser and it takes you there.  Now you spend a while browsing
the web, looking at different pages.  Then you decide you want to
check something on your home page, so you type "mycoolpage.me.com"
into the address bar and takes you there.

Ok, you checked what you wanted to, and now you want to get back to
what you were browsing before, so you hit the back button.  Does the
web browser decide that, since you've come back to your home page, you
can't go back any further and therefore the back button should be
ignored?  Of course not.  It takes you back to whatever page you were
on before.  And I'm suggesting Android should do the same thing.

Peter

--



What to do about all those buttons?

by Peter Eastman » Thu, 28 Jan 2010 07:44:56 GMT


 



That reminds me of the standard UI designer's joke: "Let me explain to
you why this is intuitive!"  If you have to explain it, then it's not
intuitive, and if you have to teach users to do something, then it's
not intuitive.  And even if you teach them, why should they have to
take the trouble to check whether a menu's available?  Why can't we
just tell them?  (Answer: There's no reason we can't, and we should.)


I understand that's what it means, but only because I've read the
developer documentation.  The problem is that it isn't what users
expect it to mean.  In a web browser, Home means, "Take me to my home
page," and Back means, "Take me back to where I was before."

Long pressing the Home button has exactly the same problem.  I'm
working in application A.  Then I switch to application B.  Then I
press Back and it takes me to... the home screen???

Peter

--



What to do about all those buttons?

by Matt Kanninen » Thu, 28 Jan 2010 09:17:24 GMT


 Users expected multitouch to be impossible.  Users still expect
multitasking to fail.  It is intuitive if it sucks, users expect it to
suck.  Intuitive does not mean good.  Intuitive today is not the same
as intuitive last year or next year.

Apple had to explain a great deal to users.  Now that they have done
that we have to explain to the users why Apple was wrong.  The user's
intuition is, unfortunately, off.  It has been heavily influenced by
bad design.

Android has much looser constraints then the iPhone.  I am impressed
that Apple claims that 100k + iPhone apps will be available on the
iPad.  Especially since when I was working on an iPhone app I did not
even know I was working on an iPad app.  I guess I need to go back and
change my resume, I am now an iPad developer, retroactively!







--



What to do about all those buttons?

by Streets Of Boston » Thu, 28 Jan 2010 12:20:21 GMT


 >so you type "mycoolpage.me.com" into the address bar and takes you there.<
Typing is just like a navigation-action, like clicking a link. I see
no difference. In the end, the home page is where you opened the
browser.

In your example, typing to go to "mycoolpage.me.com" does not make
"mycoolpage.me.com" your new home-page. Your home page is still the
page that opened when your browser started.

Same in Android:
If i am in my application (activity) and i get a phone-call, the Phone-
activity is shown. After the call, when i press back, my original
application (activity) is shown again.






--



What to do about all those buttons?

by Peter Eastman » Fri, 29 Jan 2010 05:05:14 GMT


 



Exactly.  It sounds like we're actually saying the same thing.  In a
web browser, if you press Home then press Back, it takes you back to
wherever you were before you pressed Home.  Would you agree that
Android should work the same way?  If so, then we're in complete
agreement.

Peter

--



What to do about all those buttons?

by Peter Eastman » Fri, 29 Jan 2010 05:07:15 GMT


 



Could you explain?  What are the bad designs you think users have been
influenced by?  What aspects of their intuition do you think need to
be challenged?

Peter

--



What to do about all those buttons?

by Streets Of Boston » Fri, 29 Jan 2010 12:07:09 GMT


 But that's what i described in my second part of my previous post:
Android *does* work the same way:

activity is shown. After the call, when i press back, my original
application (activity) is shown again."<<

where "my application" is like my current browser session and "phone-
activity" is like navigating to 'mycoolpage.me.com'.

When you hit back enough times, you'll hit the page that was opened
when the browser was started, and even in the browser you won't go
'back' to anything anymore.

I will give you this: :-)
If you hit 'Home' in the browser after doing some other browsing, you
can click the 'Back' button, bringing you back to the page you were
previously on. The 'Home' button in a browser is like a navigation...
it does not clear the stack.







--



Other Threads

1. What's different in the new Developer Distribution Agreement?



Do you know of a hosted edition of the former version of the Agreement?
I hunted but couldn't find one.


Their argument, reading more into section 7.1, is that by invoking one
of those four allegation/infringement claims, is that they are yanking
the app from the Market totally, meaning those who bought it cannot
download it again (e.g., had to hard-reset their device). Hence, even if
Google doesn't apply a proactive "kill switch", some users would be
affected.

It all comes down to the implementation of "at Google's request" for the
refund. If the refund is *only* for those users who are affected by that
problem, this clause isn't a big deal -- there's only going to be so
many affected people and only a portion of those will kvetch enough to
get Google's attention. If, on the other hand, they demand a blanket
refund on all apps sold, this clause will be hell.


This is certainly more troublesome. I detest agreements that use
open-ended language like "applicable law". All we need is some remote
village to pass a rule saying that the Button widget is illegal, and
we're potentially screwed.


This is pretty standard fare. Most legal agreements set up the venue for
legal jurisdiction. Every contract I put together has it set for
Pennsylvania (USA), for example.

Now, I take a somewhat blas attitude because I plan on avoiding Android
Market like the plague as a publisher, except in very specific
circumstances.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 2.8
Available!

--

2. Regarding orbital menu in sdk 2.0 android

Hi,

I want to use the orbital menu in my application, similar to that used
in lock screen in sdk 2.0 emulator.

Resources used in that lock screen task are available in sdk 2.0, but
i am not able to find souce code for this.

Can anyone tell me from where can i get this code.



Thanks in advance.

Regards,
Rakesh

-- 

3. Load xml from a url instead of R?

4. Google Analytics : 403 Forbidden => Has anyone downloaded the jar ?

5. Please help me to choose Android Phones (For Android development)

6. Camera and Surface problems with 1.6

7. Extremely slow Android SDK download (5 kB/sec)