Back Button

Is having a **_Back_ Button** (in your Web App UI) **_good UX**_ (_progressive enhancement_) ? #**discuss**

read these:
- http://ux.stackexchange.com/questions/7909/do-users-understand-the-browser-back-button
- http://ux.stackexchange.com/questions/36017/is-the-browser-back-button-still-the-second-most-used-navigation-feature
- http://ux.stackexchange.com/questions/50688/is-a-back-button-a-good-idea-for-mobile
- http://stackoverflow.com/questions/9103482/one-page-html5-web-application-should-not-have-a-back-button
- http://ux.stackexchange.com/questions/42392/does-dont-break-the-back-button-apply-to-web-applications
- http://baymard.com/blog/back-button-expectations

I found _one_ UX question/answer that makes the case for back button: http://ux.stackexchange.com/questions/72769/do-we-still-need-to-add-custom-back-buttons-to-our-design but it only has _one_ up-vote so don't take it as "_truth_"...

I _understand_ that "**_the browser back button takes you back in history, not back in navigation**_", and in _some_ applications this can be confusing, but in a _well-designed_ UX, where an "SPA" isn't trying to _re-invent_ how the browser _should_ behave, this should not be a factor.

More research is required and preferably a _usability study_ should be conducted.
Once we have some more up-to-date qualitative/quantitative insight we should write a blog post on this.

The issue names no files, tests, or entry points. Start by reviewing the linked UX research and the app's navigation behavior, then determine whether a custom Back button is warranted and how a usability study would be scoped. Done would require an agreed conclusion and, if adopted, a documented implementation plan or follow-up issue.

Written by the indexing model from the issue text.