The other day I was playing around with a potential design for a little something I’m working on. After messing about in Photoshop drawing a button that would take the user back to the previous screen, I had to stop and ask myself the million dollar question: “Why?”
Why are you wasting time building something that all browsers already do?
All browsers come with a back button. All users know where it is and how to use it (at least partially). Why would I spend even a single minute adding complexity to my interface when the browser gives me the same functionality for free? So I ditched it.
But the back button isn’t the only button that’s often recreated. Another common culprit is the print button.
Now, in the case of printing, I might begrudgingly have to admit that in some cases it makes sense to create a specific printer-friendly view. If you are spreading your content over multiple pages1 offering a print option that prints everything can be a good idea. Perhaps.
However, if all your print button does is invoke the browsers built-in print functionality, you’re wasting your time and needlessly increasing the complexity of your UI. Why?
Great point about both the print functionality and the back button. The case against back buttons is even greater in cases, when the implementation uses the Javascript history.back() function for this, which exactly mirrors the functionality of the back button.
Fringe cases would be something like image galleries, where the full width image opens on a separate URL. In this case, a "Back to Jakob's gallery" link would help user from Google find their way to the gallery view.
In the above case, you wouldn't necessarily have to explicitly make a "Back to gallery" link though, since other parts of the UI could communicate the hierarchy. Your point still stands.
I love the way you code your interfaces btw. I'm guessing it's intentional to not support IE, right?
For the gallery example, it's not really a "Back" button as much as it's a "More images from Jakobs gallery" button. That's a good idea, in particular when users arrive from search engines, and something I've done on (among others) Lokalebasen
For application interfaces it rarely makes any sense, though, as they aren't Googleable.
I love the way you code your interfaces btw. I’m guessing it’s intentional to not support IE, right?
Uh... yes, "intentional", let's say that... ;)
Interesting how you should bring this up a few days after my crusade at work to not have us rebuild functionality that browser makers have spent many years perfecting.
I agree but how do we convince our clients? I often hear them saying that we need to add a back button because people don't use the built in one.
If a client claimed people don't use the built in back button, I'd probably start by asking them what they base that assumption on. Then gently inform them, that they're wrong.
Tons of websites wisely do not add their own back buttons. Users still use them without problems.
Then redirect them to all the research and articles that clearly put the Back button as a usability "lifeline": http://www.google.dk/search?q=back+button+usability
If that's not enough, start namedropping. Google.com doesn't have their own back button, neither does amazon.com, apple.com, facebook.com, or youtube.com for that matter.
If that's still not enough, sigh deeply, and remember they might be wasting their money, but at least they're wasting them on you.
I would like to give a back button some backing. For forms with several pages to fill out like flight bookings etc then an existing back button helps the user to know 'going back' and alter entries is allowed. If they rely on the browser back button, then it feels more hit and miss and 'the system' might not cope with the user goon back do make changes.
sorry for double posting - problems commenting from my iphone.
Just came across a site by google, that uses a 'back to ..' button! Just thought i would mention that!
sample:
http://code.google.com/webfonts/family?family=Cantarell
For a multistep form it probably shouldn't be built as a back button anyways. A list of steps with the ability to jump directly to that step is better in most cases. Or even better, build the form as an inline multistep form (ie on one page) as advocated by Luke Wroblewski in http://www.slideshare.net/gdnovey/modern-web-form-designluke-wroblewski/13
As for back buttons not working, that tends to be shoddy development. Adding bad UI behavior to cover up development deficiencies doesn't sound like a great idea.
The example from Google Font Directory is pretty blatant. The button doesn't seem to do anything but add cruft to the interface as the logo right next to it does the exact same thing. Oh well, Google isn't necessarily known for their great designs ;)