1

I've been working on some extremely complex web-applications and supporting the back-button in all scenarios is non-trivial, to say the least. This is especially true when you support various devices and browsers.

So, the question is, will it ever be acceptable to disable the back-button, within a complex web-application?

Data Point: We did some trials, where we got a few dozen users to work with a version of our application that does disable the back-button and they very quickly adapted (on average, 30-60 minutes, based on feedback).

Of course, you have to provide all appropriate navigation options, but it certainly makes life a lot easier, as there's a lot of edge cases you don't need to care about.

I welcome any feedback and suggestions. Thanks.

  • what sort of applications are you working on? It of course depends on the application if the user has many other options to choose from in his previous information and if not you can move away from providing that option. – user3464111 Oct 17 '14 at 11:07
  • It is a line of business application, where the users are using it pretty much all day to get their work done. Specifically, it is an insurance underwriting system, where the users follow various complex procedures (guided by the app) to perform their various daily tasks. – Steve Jones Oct 17 '14 at 11:18
  • What is your solution for this usecase?"If am viewing a contact's info and i wish to go back to view all the customers' list"' – user3464111 Oct 17 '14 at 11:22
  • There are lots of options, including breadcrumbs, links, buttons, recent-links, etc. Blindly clicking back-button lots of times can lead to issues, for example, if the user went from list to view contact 'A', then deleted contact 'A' and viewed contact 'B'. What do you show on the way back to the list? All gets messy pretty quickly. Can't really treat it as an error condition, as they've done nothing wrong, so showing a 'Contact no longer exists' message is inappropriate. What if they stop at the 'deleted' contact and try to do something with it. – Steve Jones Oct 17 '14 at 11:48
  • "Contact does not exist" is perfectly acceptable and exactly what the user expects. If I delete a contact and click on it again to check if it worked and it shows something other than "Unknown Contact" I'd file a bug report that deleting does not work. – nwp Oct 17 '14 at 12:16
6

Usability shouldn't be looked at in terms of 'will it be acceptable to do x', if you know doing something is bad and you're looking for excuses to do it then you really shouldn't be doing it.

Usability should be approached in terms of 'what advantages does doing x have?'.

Disabling the back button...what does it give you? I am struggling to think of any advantage that comes of getting rid of this useful standard button. Pencils have rubbers for a reason, no matter how basic or advanced the work, alterations will sometimes have to be made mid-flow.

Disabling the back button is generally just a way to cover for bad design and/or bad programming, where things go wacky if you do press back.

The only possible advantage that comes to mind for me in getting rid of the back button is to buy a little bit extra screen space by totally getting rid of all the chrome- perhaps in a system which is the only app the user will ever run on their computer, (maybe the management even want employees locked into this system because they're sick of people wandering away from their customer management suite to check on the sports scores) this could be desirable... But in those cases I would very highly suggest having a 'soft' back button built into the system to replace the loss of the default one.

  • Thanks for responding. I agree with what you say in theory, but in practice, disabling the back-button gives numerous advantages, in that it makes implementation vastly easier, in the case of a complex web-application. I don't think it is acceptable to cut out a lot of functionality, as the time was spent catering for edge cases where the user clicked back, or forward. AFAIK, there is no standard approach that addresses all these issues. If there was, I'd use it in a heartbeat, as I'd prefer to keep the back-button functionality intact. Nothing to do with "bad design" or "bad programming". – Steve Jones Oct 17 '14 at 12:00
  • true, I was speaking ideal world and in practice sacrifices may need to be made and some big but difficult to fix issues avoided. A soft back button should be possible for 90% of the screens even in rather advanced programs though, the only iffy area that comes to mind for me is after having submitted forms...but in those cases a soft back can be changed so it doesnt go back one screen but rather to the screen before the form- thats a bit of an advantage of a soft back button, a lot more versatile and controllable than a standard browser back. – the other one Oct 17 '14 at 12:27
  • There's the problem, right there. That's messing with the back-button, which is meant to be sacrosanct. I suspect it is easier for users to cope with it being switched off altogether, rather than having it work sometimes, but not other times. I agree with your suggestion, by the way, just trying to point out how silly the pseudo-religious "Don't mess with the back button" concept is. – Steve Jones Oct 17 '14 at 12:31
  • Frameworks like Ember.js manage the routing for you and there's not much to code for you have the back button working. There are also a lot of other libraries to manage history in single-page applications etc. I wouldn't ever consider to disable the back button, because it has a huge impact on user experience / the perception of your brand, even if users silently adapt to it. – CoDEmanX Oct 17 '14 at 16:24
  • @CoDEmanX Yes, we did look at Ember, but it didn't seem like a good fit for extremely complex web applications. It looks way too complex to sort out the routes, etc for a system with around 1,000 screens. Looking at the big picture, the opportunity cost of supporting back/forward-button across all possible scenarios is just too big. I kind of hope I'm wrong and someone will point to a similarly complex project that uses Ember, or similar, but so far that hasn't happened. – Steve Jones Oct 18 '14 at 9:43
0

Thanks to everyone who responded to this question. I really appreciate it.

I have to say that I'm no closer to being convinced about the idea that you must never mess with the Back-Button. I get the theory behind it and I wish it was possible in all cases, I really do, but it seems to me that for extremely complex applications it just isn't possible.

As I mentioned in the comments, I don't want to have a "halfway house" solution, where the Back-Button works sometimes, but not other times, as this will likely seem arbitrary and be more confusing than switching it off altogether.

I have looked at various browser history libraries and spent a lot of time thinking about this myself, but none seem able to cope with complex scenarios in a satisfactory way. I suspect that this is something to do with the fact that browsers are not really designed to host applications. The linear-navigation paradigm doesn't seem to fit user's real-world behaviour, when performing their daily tasks.

As always, I'm open to further suggestions, but so far I remain unconvinced, especially in light of the fact that users don't seem to care and adjust almost immediately, while the amount of effort required to support every scenario raises an enormous opportunity cost.

  • 1
    While users may be forced to accept the idiosyncrasies of this app are they happy with that learning experiance? You may want to benchmark your usability with SUS usability.gov/how-to-and-tools/methods/… or similar. Your back-button issues may just be symptomatic that this application is less consistent in terms of navigation and possibly not as simplified in design as possible - which would also be indicated by SUS scores too. – Jason A. Oct 24 '14 at 10:58
  • 1
    Ironically, the issues highlighted by the SUS test, and others, are what I was trying to avoid by disabling the Back-Button and greatly simplifying the system, while increasing the consistency. The users love the system and both they and the project sponsors wouldn't trade the substantial additional functionality built for an imperfectly working Back-Button. This is the opportunity cost I mentioned above. Easy to say it should support the Back-Button, much harder to actually do that consistently in all scenarios, which is why I asked this question in the first place. – Steve Jones Oct 24 '14 at 14:13
  • 1
    @Jayfang okay, so I did a quick SUS test, via email, on a few users around the office. Only a small sample of 22, but they all gave much the same responses. Average normalised score was 95, which is pretty good, I think. It would be nice to have a control group to compare, where the Back-Button was enabled, but didn't always work consistently, but I suspect the scores would be lower. More importantly, overall project satisfaction would be lower. I'm not saying this one project proves anything, but I do think it is unhelpful to always cling to the "Don't mess with the Back-Button" mantra. YMMV. – Steve Jones Oct 24 '14 at 17:37
  • What is key is your users are happy and the UX job is done, that project did what they needed to given the constraints, which is heart of design. However looked at clinically "I suspect the scores" is not sufficient evidence to counter the "Don't mess with the Back-Button" mantra. – Jason A. Oct 27 '14 at 20:46
  • @Jayfang Thanks for that. I think the project is a success and that's all that really matters. I still wish there was a better solution, but right now, it remains elusive. – Steve Jones Oct 29 '14 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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