Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In mobile website for all smartphones (iPhone, Android, Blackberry, Windows phone 7), should I provide a "Back" button inside the webpage even when the browser has functionality to go to back?

Screenshot of an iPhone "back" button.

Screenshot of an website viewed with an iPhone web browser.

Edit - 19 August


I explored this topic some more and Found that iphone has Back button inside the screen

enter image description here

But in Android it's outside the screen. I don't know about other Smart phones.

enter image description here

And in Desktop Websites we never use Back button.

  • We use link of homepage on logo to go to home page

  • We use Browser back button.

And in Mobile Website Home page don't require Back button.

  • Should we still use back button in mobile website.?
share|improve this question
    
+1, Interesting question –  Jørn E. Angeltveit May 18 '11 at 8:46
1  
Hi Jitendra, you should put your update in a new question so people can answer it separately! –  Rahul Aug 21 '11 at 21:29

8 Answers 8

up vote 14 down vote accepted

First of all a question on your statement: Does all mobile browsers have the back-button? I have the impression that some mobile browsers remove this elementary navigation button to save screen real estate? I might be wrong, but if this is the case, then you should implement a back-button on your website.

This is also the case if your web site should be shown in full screen mode or rendered into some custom made webkit solution (I don't remember if Flipboard and FeeddlerRSS have the back-button or not, but apps like these might skip the back-button).

Conclusion so far: Yes. Include a back-button.


Then, I would turn the question upside down:

"Can I solely rely on the back button in my own app/web?" And the answer is no!

The browsers back button is one of the most fundamental anchors the user have. They may be lost in limbo-land, but they always know that the back-button will take them to the previous page.

The only thing you can be absolutely sure about when it comes to the average web surfer, is that they know that the browsers back button will take them to the previous page!

  • Don't disable the browsers back-button.
  • Don't create forms that re-posts the content when the user clicks "back".
  • Don't create any custom back-functionality that will affect the ordinary back-button.
  • Let "back" be "back to previous page in history", and not "a link that takes you (forward) to previous visited page"

Final conclution: Let your back-button work side-by-side with the browsers back-button.

share|improve this answer
    
Although you have answered my question but I added some more question in same question because they were related to this. I would like to know your views on my new questions. Thanks. –  Jitendra Vyas Aug 19 '11 at 13:24
    
@Jitendra: Nice follow up on the original question. I think you should ask the new question as a new seperat question, though. This is two good questions and you'll get more attention if you add it as a new question... –  Jørn E. Angeltveit Aug 21 '11 at 19:43
    
Indeed - Jorn's answer should be the accepted one to this question. –  icc97 Sep 25 '11 at 10:19
    
If we came from an external page and we drop on your page, then, the user has two (perhaps) different expectations. If they click on the browser back button, they perhaps wish to return to the previous visited page. However, if they click on the layout back button, perhaps they wish to return to the previous layout page. I would suggest, in addition here that, we should perhaps consider disabling/hiding the layout back button, when the user comes from an external page, to avoid frustration. –  MEM Apr 19 at 11:02

There is a big distinction between a navigating history versus navigating a site. I could have come directly to this page from someone's link, or I could've come from the parent page.

Rather than adding a back button, which is actually a history navigation function that browsers already have functionality for, I would provide a site hierarchy with links kind of like this at the top:

Home > Electronics > This Page

This is different from a back button because I may or may not have come from the Electronics page, and I need context of where I could go.

share|improve this answer
1  
Regarding "site hierarchy with links" (aka "breadcrumbs") on mobile, see ux.stackexchange.com/questions/16210/… –  Mark Gavagan Jan 21 at 15:18

Don't forget that (on the iPhone at least), the user can add a webapp to the home screen. If they open it from there, it is (or can be) displayed full-screen, i.e., without the browser controls (including the back button).

In this situation, you must provide users with a way to go back.

share|improve this answer
    
yes but it only happens in we add a meta tag to hide the browser controls. –  Jitendra Vyas Aug 22 '11 at 11:17
    
Sure. I just meant that it's one more thing to consider. –  martinpolley Aug 24 '11 at 5:46

I would stick with the rule above: Don't duplicate functionality. If the user can see the browser back button or in the case of android the hardware back button, then this should be enough.

Screen "real estate" on mobiles is very limited on smart phones, so make the best use of it.

share|improve this answer

And in Desktop Websites we never use Back button.

  • We use link of homepage on logo to go to home page
  • We use Browser back button.

Desktop Gmail has a 'back' button I use occasionally.

I would say whatever you do don't change the functionality of the browser back button between your desktop site and your mobile site.

Could a mobile browser be considered modern if it didn't include a back button? Don't duplicate functionality.

share|improve this answer

One of my favorite articles by Don Norman and Jacob Nielsen is Gestural Interfaces: A Step Backwards in Usability.

An entire section, entitled "Feedback", discusses the issue of the back button in mobile interfaces.

Yes, provide a back button - or perhaps call it a dismiss button, but make it follow the user's model of "going back," not the programmer's model that is incorporated into the Activity Stack of the OS. Among other things, it should have a hard stop when at the top level of the application. Allowing it to exit the application is wrong. 1

They are referring to native applications, but I think it is applicable for a website optimized for mobile screens.

The key point is to allow for the user to have an option of "going back". Otherwise, they'll take the easiest way out - an exit.

share|improve this answer

As screen real-estate is more limited on portable devices, perhaps instead of a 'Back' button you could add an 'Up a Level' button which will move up a level of the hierarchy. (You'll probably want to use better terminology that 'Up a level' though, that's just the first thing that came to mind).

That way you aren't duplicating functionality on the mobile site but are offering an alternative to the inbuilt browser functionality.

share|improve this answer

Yes you should create a back button if your interface requires it. Try to not to rely on the back button within browsers. Don't forget that when you design an interface you are designing for multiple devices as more and more devices emerge that can browse the web. Consistent interface in your website is a key to success no matter what device it is viewed on.

share|improve this answer
    
But I think all browser on all old and new devices will have back button as a part of browser controls. Is creating back button on the page still good? –  Jitendra Vyas May 18 '11 at 4:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.