I mean, I get it. You’ve got a complex application with a whole bunch of retained state that you don’t want to blow away if the user hits the back button.
In most (all?) cases, disabling the back button is a sign that
- you haven’t thought the problem through, and/or
- you didn’t have the time to implement it correctly and/or
- you couldn’t figure out how to implement it correctly.
And yes, I’ve heard the “the application is way too complex” argument too. Over and over again at that. The back-button needed to be disabled because
- User information — name/address/… — was being collected on sequential pages, with the back-button blowing away information that was already entered (no it wouldn’t)
- Shopping carts would get out of sync (no they wouldn’t)
- Submitted information would get re-submitted (no it wouldn’t)
and so on. In every single case, we figured out that the application may indeed be complex, but not that complex. A combination of refactoring and/or rethinking the problem resulted in actually improving the behavior with the back-button.
Also yes, the examples above are dated, but that’s exactly the point. The “too complex” argument has always been deployed as an excuse for lazy behavior, and especially by #CowboyDevelopers.
We need to be better than that. We have to be better than that!
The next time you find yourself pulling “too complex” out as an excuse, stop, and re-examine your priors. Ask yourself what the actual User Experience is that you’re trying to promote, and whether there are other ways to get the result. You’ll be glad you did!
(And yeah, there is a special place in hell for those who insist on disabling the back-button…)
Source link https://uxdesign.cc/a-special-place-in-hell-3822390da21f?source=rss—-138adf9c44c—4