"Give people a logical path to follow. Make the path through the information you present logical and easy for users to predict."
"In most cases, give users only one path to a screen."
Screen 1 -> Screen 2 --> Screen 3 ---> Screen 4 ----> Screen 5
On a lot of Android launchers, you can have page one centered.
Screen a <--> Screen b <-> Screen 1 <-> Screen x <--> Screen y
What's the benefit? I can get to my two most used screens both within 1 swipe. In fact the most swipes I need to access any of my five screens (from the Home) is 2, on iOS as above it's 4 (for the same number of screens). You could argue that some people use "Search" so much it negates this, but I think search should be accessed in a slightly different way to how Apple have it programmed in now anyway.
That's the best-case scenario. Another scenario is that you don't have perfect memory and don't always recall where all 80 (5 screens of 16) of your apps live, so you go to the right looking for an app, and you don't find it, so you then have to go to the left, for a total of 6 swipes. I'd bet that this is a pretty common scenario for most people with enough apps to fill 5 screens.
1) I organize my Android's 3 screens by function: (left) Scheduling/Tasks, Home, (right) Social stuff. On each screen are a relevant widget (or two) and related apps.
2) The Android app drawer is much more useful than iOS's app pages because the app drawer is arranged alphabetically, is continuous and is organized top-to-bottom. I use the drawer about 10% of the time and, when I do, I don't need to "recall where all 80 apps live" because I recall the alphabet.
... a total of 6 swipes. I'd bet that this is a
pretty common scenario for most people with enough
apps to fill 5 screens.
But then the question of 4 swipes vs 2 is kind of moot. You're not using 5 screens to store apps, so comparing your setup to iOS isn't apples to apples.
Personally, I setup my 3 screens (iOS) to have 1. Stuff I use a lot, 2. Stuff I use a little, 3. Stuff I barely use. This works well for me, and going to a left-center-right model wouldn't gain me anything (I expect that it would cost me instead).
> 2) The Android app drawer is much more useful than iOS's app pages because the app drawer is arranged alphabetically, is continuous and is organized top-to-bottom. I use the drawer about 10% of the time and, when I do, I don't need to "recall where all 80 apps live" because I recall the alphabet.
This is debatable. There's something to be said for not forcing alphabetical order. It comes down to personal preference, though.
In popular launchers (including the 'stock' one) there's the "app drawer", accessible from all home screens. It's an alphabetical listing of all installed apps; it is ~5 icons wide and scrolls vertically.
Icons (shortcuts) or widgets added to home screens are merely user-created convenience shortcuts to get to apps.
This is analogous to desktop shortcuts vs navigating the start menu on Windows.
edit: commandar replied with a similar sentiment while I was writing this.
I still use the App Drawer (the alphabetical list of all installed apps) occasionally for the rare app I don't use frequently to merit a prime spot on my home screens.
If it's not something I use all the time, it can live in the app drawer rather than be in my way on a home screen.
As for accessing things quickly, an iOS user can stick all their "social" apps in a folder on their main screen. The 5 screens can easily become a single screen, with 1 click to open any folder. Left and right swiping don't even mean anything here.
As I said, it's not Apples to Apples. Saying that iOS should have left/right screens because it works on Android doesn't make sense if the usage patterns are different.
(I think you may not have realised commandar's and cristoph's replies were not written by the one person)
Certainly, offering the option to put apps on the left of "screen 1" is not a problem if that's what you prefer. I'd probably never use that if I were on Android, though. Of course, Apple already uses "screen 0", so the "swipe left" option is already taken by search.
Your point only applies if you fill the 5 pages with apps as they're installed, iPhone style.
As I've said a number of times, the usage patterns are too different. If you're using your screens as folders, then maybe you want the left-swipe functionality. If your screens contain every app you install, then that might not make so much sense.
I'm not saying Android is wrong to have left/right screens, merely that the behavior would generally be wrong for iOS.
One screen to the right are the rest of my social media things and various camera apps plus the powerbar widget for turning on and off various things on my phone without heading into settings (flashlight, wifi, GPS, etc.)
One more screen to the right are my various nerd tools, an ftp server, a terminal emulator, file manager, heck I even have a tricorder app and the tron bit on there.
Going left I have productivity apps, google docs, drop box, a folder full of various audio apps like pandora and Tune In radio, The Kindle app, a comic book reader, etc.
And finally all the way left I have games, emulators, calculators whatever sort of entertainment junk I want.
I know immediately where I am on my phone at a glance and can almost navigate to it without looking.
If I start to run out of space, or want more organization, I just dump a category of apps into a folder...or my Launcher lets me add more screens if I want.
The "back" button goes back to the last thing you were looking at (a sort of stack based approach kinda like a web browser, but across the entire OS).
So if you are in an app, launched from the left-most screen, and want to get to another app on the left-most screen, you might hit "back" and it'll background the app and put you on the left most screen.
Given the same scenario, if you want to go to the right-most screen, it's easier to just hit "home" and swipe twice.
My Nexus One has the layout you propose, and I don't prefer it to iOS.
As for the "one path" argument, making the button take you directly to the home screen doesn't reduce the number of paths. You exit the app via the home button and it takes you to one place. That's one path. Whether the path is to the home screen or back to the state you were in is a design choice that has no effect on the number of paths.
Personally, I think Apple made the right choice. It would be pretty obnoxious to be on screen 3, launch the wrong app on accident, and then be dumped back to screen 1 when exiting. I'd much rather be able to hit the home button and then immediately launch the app I intended to launch.
There's also the use case where you have a related apps on the same screen or in the same folder. If you open a Facebook app, how likely is it that you'll want to check out Twitter next? If you get done checking the NYT headlines, might you want to open CNN or Flipboard next? Sick of Angry Birds so you open up Words With Friends? These scenarios don't seem that unlikely to me, but the "go to screen 1" behavior breaks them.
Even so, presumably, if these apps are important to you and you open them regularly, you have them on the first or second screen, so making the home button take you to the first screen doesn't seem like a huge additional burden.
The other situation you describe (you have a set of applications on a screen far away from the first home screen, and want to launch many of them at the same time) seems uncommon. It's typically bad to have a UI that makes the common case worse in order to make an uncommon case better.
But I don't have data to back up "a lot of regular users", just anecdotal experience with them.
Imagine my frustration when I mis-click an app, and instead of taking me back to the place where I was just a moment ago, it warps me back to the first page of applications. I have to rescroll through a few pages of apps.
After doing this a few times, I curse Steve Jobs' name and hurl the device from the driver's side window... lamenting the day I bought it. I hollar to my driver. He snaps his whip, urging my fine brace of stallions on-wards... to my local Verizon store where I purchase The Jitterbug: a testament to Human Interface Guidelines and ease of use.
If i press the home button while on one of the pages of icons i am brought back to the first...
But sometimes, in the same apps, the back button might take me back to the home screen (If i answered a message from the notification bar), or a previous app if something launched a browser.
It's incredibly aggravating that the behavior changes, and especially so as Android devices have a home button! Back should be constrained to a specific application. Otherwise in google talk I have no reliable way to get back to my contacts and usually have to make a trip back to the home screen to directly launch the talk app.
The back button in Android does have the fault of not always being consistent, but that is due to it being usable by the developer of individual apps. I find it extremely useful that I can be doing something in Tweetdeck, click a link which opens up my browser (Dolphin HD), view the full article, and then just press the back button to go right back into Tweetdeck. That's just not possible on iOS.
Also, long-pressing the back button in certain apps (like Dolphin HD) provide a nice shortcut to quitting the app (instead of keeping it running in the background), which helps on battery life.
The problem here, I think, isn't so much the button itself, but developers not following the conventions, and Microsoft (and possibly google, I don't have an android) not steering developers in the right direction.
For example, the IMDB app on WP7 has a search icon on the top right of the screen which they expect you to use to search. They should have used the already existing search button on the phone, but if you hit the phones search button, you go to bing search, because the app only knows how to use it's own search button.
Same with back buttons. If the developer has used it properly, it should take you to the previous screen of that app, but 90% of the time, it goes to the previous app.
Hopefully 'app switching' in mango (I don't think multi-tasking is the problem, its that we can't switch from one app to another without going to the home screen) will solve much of the back button issues, and possibly the new Bing/app search integration tools will help with the search button.
btw, IMDB can't support the search button because it's actually not exposed to third-party developers. Use of the search button for in-app search is actually scrapped in Mango because people found it confusing - the built-in apps that support search now have their own on-screen search buttons.
I guess that is really the problem, the majority of apps follow convention, but then every once in a while you get something that doesn't and it is gets confusing.
Personally, I just don't see the usefulness of Back buttons on WP. The Back button should be replaced when the multitask swtich feature in "Mango". The Search, maybe, it's useful sometimes. Again, like you've mentioned, the users would have to guess whether it will bring up the Bing Search or the in-app one. It sounds just confusing.
So you would remove the back button in web browsers, right?
I can clearly see the back button in all 3 UI pictures, including the one for Firefox 5. For that matter, I can see the back button in the Firefox 5 window I'm using to type this comment. I agree that Firefox 5's UI is simpler and cleaner than Firefox 1's and Netscape's, but I don't know where you got the idea that they'd eliminated the back button.
Having fewer buttons seem to make interface cleaner and less chance to screw up for users. But again it's a hardware issue for debate rather than software.
EDIT (more): I can also imagine many situations in which I want to disallow a back button (like in my own application for example), or in which the back button could be expected to perform, but actually doesn't. Say I'm in a game and have navigated to a level, start the level, but then decide I want to exit. It isn't clear that the programmer has implemented the back function, or what level of destruction the back button will perform. I'm going to have to test the back button every time I press it to see what it even does, or what the implementation is. This is poor UI. In iOS, the developer is free to label the back button or to disable it entirely to remove ambiguity. I would say that this is far more powerful than occasionally switching to the previous app if I haven't navigated at all yet in the stack of the new app.
I'm not sure if you've used an Android device, and it is quite different from an experience w/ an iOS device, but the inclusion of a dedicated back button really is a welcome one IMO. You have to switch from thinking about the back button as 'go back to the previous view in this app' to 'go back to the previous thing that I was doing'. I think iOS doesn't go far enough to create synergy between apps here (and yes, Android can go too far in some instances) but the point is that the possibility is there in one and isn't in another.
The one feature that you are really stating is a plus of a dedicated back button is to serve as a pointer to the referring app, but there is nothing in the UI to indicate that the back button will go there either, just a mental note by the user!
If you sum up all of the points of confusion that could possibly arise from a permanent and ambiguous unlabeled back button to be used for in-app navigation and compare it to the pain of double tapping to get back to the previous app in iOS (guaranteed, by the way, from any point in the app), I don't see how you could possibly come to the conclusion that forcing a back button into every point of every UI is a net plus. Not even close.
I'm not sure where you expect such an indicator to be, but that isn't the problem. If the user can't remember where they came from, why would they want to go back? The same 'problem' must also apply to the double-tap of iOS. (Which I had never heard of until now, but I only use iPhones occasionally.)
Given that you seem to have no issue with the concept of global 'return to home' and 'return to previous app', both of which are places previously visited, it's rather contradictory to take issue with a method of going back which is at worst equivalent to those features.
Because "back" is often conflated with "out"--the user might simply be done with the task and wants to get out. Unfortunately, the app simply shoots them to the previous app on the stack, which may or may not be where they want to go or remembered they came from.
Ex: Many apps go to the browser, but the user might not remember which app sent them to the browser. They might have thought it was Twitter, when it was in fact the home screen.
To enlighten you, the home double tap in iOS does not take you straight to the previous application. It brings up iOS's multitask tray that has the four previously viewed apps on it, in order of recent use. The first app on it is always the previous app. You can see which one it is. Android doesn't show this to you, nor do you even have the option of getting to the previous app unless you are at the bottom of the stack.
Edit: We're arguing about the merits of having a dedicated back button. If an advantage to the iOS task switching feature is found in yet another button on Android, that doesn't contribute support to the back button's existence.
This is exactly what I like about the back button. Frequently I'll finish an article I was reading in the browser but not remember immediately what brought me there. (This might happen if I had to interrupt reading it for a moment to pocket my phone and use two hands.) I'll have a sense I'm supposed to do something with it, but what? Did someone text it to me? Was it in a Gchat? Email?
"Well, that was a good article... why am I here, again?" I hit back, and find myself in an email with a link to the article. "Ah, yes, that's it! Joe emailed it to me." Now I can reply to Joe about it.
Maybe this wouldn't be as helpful to others, but I like it because I'm quite forgetful.
Then don't override the default functionality. Overriding the back button on android is like doing so in a web browser, optional and a dumb idea.
This also allows you to launch in the middle of an application, to a specific screen, etc. It's better to think about activities as URLs. The back button on Android behaves the same as the back button on your browser.
This is true especially when the app provides the button.
> In iOS, the developer is free to label the back button or to disable it entirely to remove ambiguity.
You can do what you like with Back in Android, including disable it.
> I would say that this is far more powerful
Even if Android restricted what you could do, it would be an apples-to-oranges comparison since an app-specific back button has no concept of 'take me to the activity that spawned me'. But in light of what I've shown it is hardly less powerful.
As for going back to the previous app, as I argue below, the back button is crippled there too because you need to be in the root view controller of whatever stack you're in for it to do that, and you need to remember which app sent you there, which is not indicated in the UI.
In iOS you can get back to the previous app from anywhere in the navigation stack with a double-tap gesture. An additional tap, to be sure, but all ambiguity from the constant and ever-present back button is removed.
That's also another thing: iOS is app-based, Android is activity based. You don't have the same navigation possibilities in iOS so you can get by without it. When you flow from one activity to another, you want to return to the previous activity rather than the previous app. Hence the back button.
I talked about UI indications for the previous app elsewhere, but it's dishonest to present the lack of indication as a point against Android when iOS doesn't even have a precise analogue of this, and what feature it does have already exists Android by long-pressing Home!
No it isn't. This whole argument just boils down to whether it makes sense to require an unlabeled backward pointing arrow to be present at all times in all UIs. In practice it doesn't make much sense to require a button that isn't always used and doesn't always do the same thing just for the sake of returning to the previous app from an empty navigation stack when you need to do that occasionally. iOS might not do it, but this comes with the added benefits that no back buttons anywhere in the iOS UI is ambiguous.
I'm also not looking forward to the first gesture requiring the use of my big toe.
When you hit back in the browser, you go back to the email message iff the browser did not open with an existing history. If it did, then it navigates to the previous page inside that browser, instead.
 PSA: you call up the Android switcher by holding Home
 This isn't a hard button like home/back, instead the app logo gets painted with an "up" arrow when this is available.
The back button always goes backwards in the history stack, but the app developer can push new pages onto the history stack however they see fit. An analogy on the web is either navigating to a new page (back button works), or loading a new page on top of the current page (back button doesn't work).
(Yeah, I realize that using the back button to invoke the application's back function would cause its own set of issues. It's a case where the same button needs to do two different things based on the user's current mindset, which the phone obviously won't know about.)
Proper back button behavior isn't something you can bolt on, but Android could still get much better than they are.
For example, I group all my work (let's say .doc, .xlsm, .ppt) into one folder. When I exit or alt tab, should it switch to the last thing I was on, or should it go to my desktop?
You only need to hit Home once anyway and the bit about the double tap is a little silly. A simple tap on the screen will get you out of the folder, and a finger swipe is a reliable method to change screens. I use my phone A LOT: text, email, twitter, fb, linkedin, lal, bloomberg, fxtrade, google voice, skype, and calender on a daily basis... and it's organized in patterns, so it minimizes browsing time.
Similar to the lack of out-of-the-box right-click functionality with their meece.
The inconsistency you talk about only happens when authors poorly create their applications. Android's entire multitasking functionality is built on top of a stack of activities, which is easiest to think of as a stack of screen views. I start at my "desktop", click on my Photo Gallery, decide to share an image using Dropbox, and it takes me to choosing a Dropbox folder. That's roughly three activities or so (depending on how many screens within each app I have to go through) all on a stack. Built properly, if I decide I don't want to share on Dropbox while choosing a folder, I would just hit the back button, it'd pop the Dropbox folder browsing screen off the stack, and take me back to browsing my Photo Gallery. Poorly-created apps will try and "recreate" their internal activity stack when they're not supposed to. Let's say that getting to Dropbox's folder browser if I were to launch the app independently took four activities in and of itself. If Dropbox was poorly written, it would try and recreate that natural flow of previous activities when you're just trying to do a share, so hitting the back button won't take you to the Photo Gallery from sharing.
Sorry, it's complicated to explain but makes perfect sense when you're actually using a device. The tl;dr is that if app developers don't suck the back button's behavior is seamless and consistent.
Android's back button strikes me as an interesting idea that doesn't really work. If it depends on application X doing the right thing in order for the experience using application Y to be pleasant, then it seems pretty broken.
I know you have to cheer on your team here, but the back button is completely intuitive and users like it; you're creating problems based on what is theoretically possible and not what is reality.
In the same vain, any poorly-written application on any device that doesn't conform to UI standards and guidelines will drag down the experience when using that device. This isn't a problem unique to Android, but it's more obvious when apps violate it due to how multitasking is built into the OS from the ground-up.
As for poorly-written apps dragging down the experience, I don't think that's necessarily a given. Obviously if you have a crappy app, then using that app sucks, but that crappy app shouldn't also make the experience of using other apps crappy.
Don't you think this is a silly argument to use against Android's back button when the post we are commenting on is a complaint about iOS's home button? By your logic, that should indicate that the home button's behavior is not intuitive and complicated... you know, because somebody complained about it.
Obviously some people disagree with the iPhone's home button behavior. Then again, they're not complaining that it's too complicated to understand, merely that it's not the ideal (or perhaps "correct") behavior.
Also, sometimes the back button in my browser totally sucks, such as when I click a link to a Twitter message and it decides to totally break my back button so that I have to press 3 times rapidly to go back. I don't want this experience with apps on my phone.
Would you rather your browser didn't have a back button at all?
And I would much rather have no global back button on my phone than a sometimes-broken one.
It makes sense with the way Android works. Applications are often interconnected. I can browse to reddit in Browser, click on a YouTube link and open it in the YouTube app, hit share, and open up GMail to send it to a friend. I can then hit back to go back to YouTube, then again to go back to reddit. Believe me, it feels so natural to me now that I find iOS clunky to use without it.
As for applications that get it wrong; that happens on all platforms for all kinds of different features -- it's unfortunate but it shouldn't reflex poorly on the feature itself unless it's particularly hard to implement correctly.
The "desktop" you're referring to is the functional equivalent of your web browser's home page. So yeah, the browser does take you there.
The idea that you have a linear sequence of "actions" across all apps seems pretty weak in a multi-tasking environment.
Google has simply extended the concept from web apps to regular apps -- and that's hardly a big stretch -- especially when all your regular apps can link to each other.
But for example, as a user, I think it's confusing that you can open an app from home screen and can go back to home 2 different ways (either back or home button).
Also, if it's that easy for developers to mess up navigation, then it's going to create a frustrating experience for user.
Touch is neat, but it is also a PITA. Typing on iPhone or iPad is decidedly decades backwards with respect to hard-button keyboards. In addition to this, if you regularly communicate in multiple languages it is impossible to use the auto-completion feature and, therefore, you are relegated to making horrible spelling mistakes.
I like the devices for what they've done to push tech forward but it'd be nice to see Apple put out a new iPhone with something like a clamshell design and a real keyboard along with some multi-function buttons. It would make the platform so much more useful and easy on the users.
As a counterpoint to this, I do find that I use the same 3-5 apps most of the time on my phone so double clicking home as actually most efficient as I can double click and tap to get to where I want most of the time, though sometimes I do need to swipe through the list a page or two.
No excuse for rapidly failing buttons, of course, but it will allow out-of-warantee devices to continue to be functional without costly repairs, which is good news.
The first, Quick Lock, shows up as an app, but all it does is turn the screen off when you press it; this saves wear on the sleep button. I keep it on the home screen.
The second, Springjumps, lets you insert button (or apps) that, once pressed, jump to a specific screen number. I have one on the bottom bar that jumps back to the home screen (page 0). To turn off my screen I typically press the go-to-home screen SpringJumps button followed by tapping the QuickLock button which I've placed in the middle of the home screen (didn't want to use up a spot on the bottom row but maybe I should).
Finally, the SBSettings close button lets me close apps without pressing the home button, from inside the SBSettings display. You could probably also configure the activator to "close" given some gesture.
This keeps the wear and tear on that one button to a minimum, for when I really need it, or for when I'm feeling lazy or rushed. Triple-home-button press? Forget it.
Imagine a swipe up scenario from the bottom that would show your full location using symbols (and allow you to navigate back with a press):
Home > Home Screen 4 > Running Apps > Current App Home > Current Page in App
And other iPhone buttons, too:
I've definitely noticed the creep of more and more being added to the Home button in subsequent iOS releases.
I've not seen iOS 5 yet, but I hope that no more functionality is triggered by the button.
Menu brings up options for what you can do in an application. For example, in the browser, hitting menu brings up the URL bar and bookmark button (which can also be reached by scrolling to the top of a page), as well as a bottom row of icons with "New window", "Bookmarks", "Windows" (tabs, basically", "Refresh", "Forward", and "More" which contains all the esoteric options for a browser. I guess this could also be put at the top of a browser, but having a handy menu button to bring it up is quite nice for screen real estate. Think of it sort of like hitting alt when you're in a full screen browser to bring up the menu.
Honeycomb cleans this up with the action bar. The action bar is on top of the screen and contains whatever actions are currently available. If there are more actions available than what can be fit in the bar, then they get put in a visible overflow menu. The key improvement here is that the action bar is (almost) always visible, so you can quickly glance at it to see what actions are possible (rather than the more complex menu-button flow).
I use Android, but I do see the value of the single-button UI. Although it may not be the "get me home ASAP button", it is easy to learn what happens. The only thing you can do with the phone is press that button. That makes it very easy to learn what's going to happen, and it's easy to predict what will happen in the future.
 I can't find a great link to describe this. Suffice to say the paradigm was that each folder had a new window and the windows stayed where you put them.
You can’t even resort to just hitting the home button
blindly a bunch of times, because if you hit it too
rapidly, the iPhone will interpret it as a double-tap.
I can't fault him on the other points, but this seemed like a blind-spot.
I don't care about that task, that was weeks ago. I'm opening up the app to start a new task right now. Take me to the main screen.
Safari has a similar issue. It will constantly save the last search you did. Every time I want to search, I have to delete the old search term first. Even 10 days after searching that term. A 2-minute timeout would be better.
Perhaps a Cydia developer could make a tweak to avoid this problem?
Design is always trying to find the best compromise.
(parallel conversations here ;)
Once I got used to it, the home button is okay, but it can register anywhere from 0-2 clicks for any given press. That is the bigger issue: I never truly know where I'll end up even if I do know how it should work.