Webサイトのカスタムの戻るボタンを配置する必要がありますか？
リストと詳細ビューの構造を持つ4ページのウェブサイトはどうですか？
ほとんどのユーザーがブラウザの戻るボタンを使用して前の画面に戻ることを知っていることを願っています。または、ウェブサイトにカスタムの戻るボタンを提供する必要がありますか？
これを行うべきではありません。
ユーザーは戻るボタンについて知っています。 「[戻る]ボタンは、Webユーザーのライフラインであり、 2番目に使用されるナビゲーション機能 （ハイパーテキストリンクをたどった後） "です。 1999年のJakob Nielsen。または2010年の Firefox調査 ：「Windows、Mac、Linux全体で、93.1％のユーザーが5日間で少なくとも1回ボタンをクリックした。」
それで、機能がすでにあり、ユーザーがそれを見つける方法をすでに知っている場合、サイトに冗長バージョンを含めるのはなぜですか？
せいぜい、ユーザーは、戻るボタンの機能がブラウザーの組み込みボタンとまったく同じであることを理解するでしょう。それはそれを単純に冗長にし、画面の無駄を無駄にし、ユーザーにとって余計な余計な余計な認識の負荷をもう少し加えます。
最悪の場合（そして最良の場合よりも可能性が高い）、ユーザーはサイトに純粋に冗長な機能を配置しないと考えます-なぜそうするのでしょうか？ -したがって、戻るボタンが実際のボタンとどのように異なるかを理解しようとすると、混乱が生じます。
ブラウザの戻るボタンとまったく同じ機能を複製するつもりなら、カスタマイズの戻るボタンは少し冗長です。戻るボタンのカスタマイズが問題になる状況が考えられます。たとえば、URLまたはブックマークを使用してサブページにアクセスすると、戻るボタンはまったく意味がありません。また、ユーザーが[戻る]ボタンをクリックしたときに、ユーザーの所在を混乱させるリスクもあります。そのような状況では、ブレッドクラムがより理想的です。
これは、UIのタイプによって異なります。ブラウザのback関数を実装する場合は、実装しないでください。ただし、たとえば、現在のページの上にオーバーレイ（つまり、いくつかの設定ダイアログ）を表示する場合、ブラウザーの戻るボタン（履歴APIを使用して達成できる）を使用して前のアクティビティに戻るのは間違いかもしれません。そうすると、左矢印ボタンの方が、ダイアログを元に戻すよりも、ダイアログを非表示に移動するように認識されるため、より明確になります。
ブラウザーで実際に戻るのか、それとも事前に設定されたページに戻るのか、たとえばWebサイトがアクセスしたとWebサイトが判断した別のページにリンクしているだけなのか、混乱することがあります。