Back button on iPhone

This question has received: 3 Votes.

There is an opinion that in iPhone apps, there’s no point in placing the Back button on screens that are directly accessible via the main navigation menu (at the bottom) – because the button just leads to the main screen, which can be reached with one click on the menu.

On the other hand, the apparent convention is to have the button on these screens, the same as any other screen.

Are there any Apple guidelines concerning this? Or any other authoritative sources?

Tue Jun 28 07:15:04 AST 2011
Answer #: 1
This answer has received: 8 Votes.

The iOS HIG doesn’t specifically say about the back button on the directly accessible screen, however, just because it happens to be possible to get back to the main screen via the main menu, that doesn’t mean that’s the best way to do it.

While in the app, returning from deeper screens using the back button should stop at the main screen otherwise you’d go back, back, back – oh! No back button! Context switch – Think – How do I get back to the top – I guess I’ll have to use the main menu button.

So I think it should be there.

Sun Jul 03 19:51:33 AST 2011
Answer #: 2
This answer has received: 0 Votes.

Usually when you go to a new page on the iPhone, the new page swipes in from the right, giving a sense that you’re moving forward. The mentally natural way to go back to the previous page is to move backward via the back button. It’s quicker to use the back button than to parse the 4+ menu items for the right item that would take them back to the previous page. 1 button VS 4 buttons – 1 button wins.

Mon Jul 04 03:55:55 AST 2011
Answer #: 3
This answer has received: 0 Votes.

Benefits of each option:

Keeping the back button:

  • Consistent with other pages in this app
  • Consistent with a very familiar pattern on this platform
  • Consistent behaviour with similar patterns on other interfaces (e.g. the ever-present back button on a browser).
  • From any page, users can get back as far as they want using just one button

Removing the back button:

  • It could be argued that it removes clutter. However, by creating a conspicuous absence that isn’t on other pages, with something very familiar noticeably disappearing on some page transitions, you’re as likely to actually increase the cognitive effort required to process that page, and distract them with something appearing and disappearing for reasons unrelated to their task.
  • Two buttons on the same page would have the same function, and it could be argued that that removing duplication or redundancy is always a good thing. This isn’t always true: this misconception is dealt with very well at Is it frowned upon to allow the user two different options to perform the same action?

So, that’s four benefits for keeping it, and the two apparent benefits for removing it don’t stand up to scrutiny.

Therefore, keep it.

Mon Apr 13 16:10:37 AST 2015
This question and its answers are found at: Back button on iPhone

Best way to switch between views with different navbars

This question has received: 1 Votes.

On the iPhone, when a set of views have different colored and textured navigation bars, what is the best way to animate in the new view when the user taps on a tabbar icon? Should the new fade in while the old fades out, should it come from the side or should it just replace the old view without any kind of animation?

Tue Jun 28 20:26:42 AST 2011
Answer #: 1
This answer has received: 2 Votes.

Judging purely on my experience (of the apps I’ve used), there is rarely animation of any sort when tapping a tab bar button. I’d go for no animation, personally, based on convention.

Swiping is more suited to going back/forward and fading is rare – almost animation for animation’s sake, rather than a constructive addition to the UI.

Wed Jun 29 10:14:35 AST 2011
This question and its answers are found at: Best way to switch between views with different navbars

Customizing iPhone app’s navigation bar with custom typeface?

This question has received: 3 Votes.

I’m currently designing my first iPhone application, and I’ve decided to go with a UI using the default UIKit controls, but customized with my own colors and textures.

One area where I’m having trouble making a decision is whether or not to use a typeface different from the default Helvetica Neue in the navigation bar. My instinct at first would be to leave the default, but I’ve seen several apps with different typefaces that pull off the effect very well (namely: Camera+ and Everyday). Here’s where I currently am in my Photoshop comp:

What do you think of this, from a User Experience standpoint? Would it be alienating for users of this app, or would it add to the overall design feeling of the app (I’m going for luxurious but easy to use)?

Sat Jul 09 00:41:30 AST 2011
Answer #: 1
This answer has received: 2 Votes.

iOS has established a strong design-friendly ecosystem where apps are expected to follow standard UI guidelines for usability’s sake. But they’re also encouraged to stand out from the crowd of “boring” apps that just use Apple’s default style by using design to their advantage. Some of the most popular apps even deviated from Apple’s standard, such as Tweetie, Convertbot, and more recently, Aelios.

So in terms of user experience design, it’s clear that the iOS ecosystem can be very flexible if you step away from the blue hues and do something different. iOS is arguably a platform where great UX is rewarded with sales more directly than other platforms (like Windows) because the app store promotes great looking apps, the community buzzes about them, and as a result, the audience has come to expect great looking apps to work well (which is also a pitfall of the ecosystem).

But your priority should lie with a great app first and foremost. So although different typography looks good, make sure your app works well first. Beyond that, I say go for it, and let us know when it hits the App Store!

Sat Jul 09 23:06:45 AST 2011
This question and its answers are found at: Customizing iPhone app’s navigation bar with custom typeface?

Android application for London Transport (usability ?) [closed]

This question has received: -1 Votes.

I’m developing the Android application for London Transport which includes Journey Planner, Tube status, Live Departures Boards, Maps, Finding a taxi function and so on.

I’d like to get some feedback about the layout of the application, because it is one of essential part of developing. Therefore, I made a basic prototype of the application that you can find here –>

Mon Jul 25 12:14:28 AST 2011
Answer #: 1
This answer has received: 1 Votes.

Looks good. The only problem is ‘Home’ button. It’s unclear for the first launch if it leads to home screen, or ‘planning journey home’.

Mon Jul 25 12:32:18 AST 2011
This question and its answers are found at: Android application for London Transport (usability ?) [closed]

Is swipe gesture in Mobile Application distracting users with vertical scroling page ?

This question has received: 6 Votes.

Normally Vertical scrolling page that used with up-down gesture for Mobile Application to browse data but also have next page to browse too

Example of Sitemap

  • Categories (Table List of Detail)
    • Detail 1 with scrolling vertical
    • Detail 2 with scrolling vertical
    • Detail 3 with scrolling vertical
    • Detail n with scrolling vertical

Normally way to navigate across all data is Categories > Detail 1 > (back button) to Categories and choose another.

Another ways is use Swipe gesture left-right in Detail Page for navigate to next page.

What are you think? It’s make distracting to user that need to learning curve for swiping left-right with vertical scrolling in up-down ? two gesture in 1 page

Thu Jul 28 07:09:49 AST 2011
Answer #: 1
This answer has received: 3 Votes.

It’s definitely okay (see Android’s Google+ and Windows Phone 7’s Metro UI).

The only problem is discoverability. I would add left/right buttons that animate to each page, so the user picks up on the fact that the pages are to the left and right of each other.

Thu Jul 28 17:21:09 AST 2011
Answer #: 2
This answer has received: 2 Votes.

I would think its ok to provide both vertical and horizontal gestures. If you are concerned about the learning curve you could add a context sensitive help overlay that prompts the user regarding the gestures.

Thu Jul 28 16:12:13 AST 2011
Answer #: 3
This answer has received: 1 Votes.

In general I don’t see a problem to have both swipe directions in one view.

The only thing to consider is what gestures are native to what platform. The behavior described is standard on WP7. On iOS this behavior wasn’t recommended by built in iOS apps. With iOS 5 the UISplitViewController can now be swiped in and out of the screen in portrait oritentation, which can be seen in the Mail app. Also third party apps on iOS implement similar functionality like the Google+ app.

Thu Jul 28 18:18:10 AST 2011

A workable tag auto-suggestion design for mobile devices

This question has received: 6 Votes.

Over at Stack Exchange we (fairly) recently rolled out a mobile design for all of our sites. This was definitely a 1.0 attempt, and while I think it’s a huge improvement over what we had (which was basically nothing) there’s a lot that can still be improved.

The subject of today’s question: tag auto-completion.

On the desktop version of the site we’ve got a standard drop down.
desktop site tag auto-complete

This approach fails on mobile for space reasons: vertical space is at a huge premium on many phone (especially with a software keyboard displayed) so the drop down is a bad fit, and we really can’t afford the horizontal space for tag counts either. This is compounded by many phones habit of centering the text field when it’s focused, causing about 1/2 the available real estate to be wasted (whatever is above the text field after focus).

What I came up with as a stop-gap solution.

mobile site 1.0 tag auto-complete

The logic is basically, chose the top 5 likely tag auto-completions and display them above the text field. Clicking them will replace the text in the tag field as expected.

This runs into problems with hit boxes (especially on Android phones), as it requires a great deal of precision to click some of the smaller tags.

Since I’m going to be redoing this anyway, I thought it best to solicit some feedback on the various designs I’m considering.

Mockup #1

tags are much bigger, but not in a grid

The idea here is that I’d make the tags huge (with really exaggerated hit-boxes in comparison to the text), and try and force the input field to the bottom of the “screen”. The scroll would only occur on initial focus, the user would be able to scroll back up to the question or down to “Post your Question”.

Mockup #2

drop-down steals the whole screen

The idea here is to still present something that resembles a drop down, but to steal the whole screen for the auto-complete controls. Effectively, this would be a modal dialog (with a little “done” button and everything). Unfortunately, we can’t capture the “Done” button on any of the phone keyboards… so, that’s a wrinkle to consider.

In Super Constrained Screens

On a number of phones, if you’re in “landscape mode” then there’s really not a lot of screen real estate to play with at all. Literally 2 lines of text in some cases. When this happens, I intend to fall back to the existing auto-complete controls (flawed though they are, they’re better than nothing) with the added constraint of not allowing more than 1 line worth of tags to display (the exact count would thus vary depending on the suggested tags’ name lengths).

The Actual Question

I say all of that to basically ask: Which of these approaches would actually present a better user experience?

The sort of “multiple entries in a single field” auto-complete is a tad rare, at least in my searching, and I’m unaware of a canonical mobile equivalent. Are there any I should be considering?

I’m personally leaning towards Mockup #1, out of a dislike of modal dialogs. It’ll also be a tad harder to implement, due to having to cope with orientation changes.

In terms of platform, we’re constraining ourselves to recent iPhone and Android phones (not tablets), and the upcoming Windows Phone 7 Mango release.

Thu Jul 28 19:33:25 AST 2011
Answer #: 1
This answer has received: 4 Votes.

Mockup #2.

This is how Google handles it (mobile and non-mobile) and this seems very intuitive. It is also in line with the way the desktop/laptop version works. Anything that is more seamless is better as long as it is not more difficult to use.

Thu Jul 28 19:47:44 AST 2011
Answer #: 2
This answer has received: 0 Votes.

Mockup #3 (none of the above?)

I’ve been in this situation before and been really surprised at how foreign the concept of a tag is to the average adult. (There’s an average!? Probably not.) I ended up with something pretty close to both of your comps, for a lot of the same reasons. Lack of vertical space being a big one.

Make the tags, tags.

Assuming the intention is to attribute many tags to one (or many) objects, I think a static list like mockup #2 is sort of misleading. Not maliciously, but enough to make tagging something feel very final—immutable. It’s interesting that the tags on are so similar to what I’m talking about. They’re defined very clearly as separate entities in a collection. Do that! Invite the user to interact with them, rather than wonder how to interpret or sort or otherwise treat them like a list.

Fri Jul 29 02:47:53 AST 2011
This question and its answers are found at: A workable tag auto-suggestion design for mobile devices

Is there a name for the type of grouped list used for iPhone contacts?

This question has received: 3 Votes.

I use iPhone contacts as an example but you see it everywhere.

The sort of list I’m talking about is where the group header (e.g. in the contacts example “S” ) docks to the top of the list while you scroll through all the S’s then gets pushed off the top of the list as you get to the T group header which in turns docks to the top of the screen.

Is this just a fancy grouped list?

Thu Aug 18 09:38:33 AST 2011
Answer #: 1
This answer has received: 3 Votes.

Look at the developer documentation of apple: The groups are called sections, and they are used within a plain table.

So to use Apple developer language I would say it’s a plain table view with indexed sections. Not a very nice name, but a precise one 🙂

Source: (page 14)

Thu Aug 18 09:57:18 AST 2011
Answer #: 2
This answer has received: 0 Votes.

“Indexed list” is what I’ve heard used.

Thu Aug 18 13:54:51 AST 2011