バックブレイクサイト
最近、非常に多くのサイトで「戻る」ボタンのエクスペリエンスが「壊れる」理由は何ですか。
スタックでもこれを行います。質問を読んでコメントを展開し、最初の回答までスクロールし、リンクをたどり、興味がないと判断して押し戻します。
その時点で、スタックはコメントセクションを展開せず、サイトを離れた場所として別の場所に移動します。これは、ページを離れたところをもう一度検索する必要があるため、非常に不安です。
コメントを展開できるslashdot.orgのように、他にも名前を付けられる例はたくさんありますが、リンクをたどって戻ると、コメントが展開されず、どこにいたのかがわからなくなります。
また、多くのサイトには、disqusのような「統合されたフォーラム」があり、サイトを離れると、戻るとコメントの先頭に戻ることができます。
これらのサイトがimoの非常に悪い戻るボタンエクスペリエンスを実装する理由は何ですか？
考えてみると、ブラウザで最もよく使用されるボタンは戻るです。
この動作には3つの理由があります。
多くの新しいWebアプリが JavaScript MVCフレームワーク と シングルページアプリ 。このコンテキストでは、説明されているような動作を機能させるには、 履歴API を使用する必要があります。これはすべて非常に新しいテクノロジーであり、設計者、開発者、および製品マネージャーは、多くの場合、これにまだ取り組んでいます。
技術的には難しいです。より単純で古い実装では、すぐに使える動作を模倣するために時間を費やす必要があります。このための時間とお金が利用できない可能性があります。
たとえば、サービスプロバイダーがデータをいつどのように送信するかを厳密に制御する必要がある場合に、オンラインで送金する手順を実行する場合など、セキュリティ上の理由で行われることがあります。繰り返しますが、単に無効にするよりも、戻るボタンで発生する可能性があるセキュリティ問題を回避するのが 難しい
これをすべて言っても、かなり基本的なユーザビリティガイドラインに反します。1つ は[戻る]ボタンをハイジャックしないでください 。 ほとんどのユーザーがこれを期待しているように、強力なユーザーエクスペリエンスを本当に必要とし、セキュリティ上の懸念がない（100万人に1人を除いてそれを読む）Webサイトは、戻るボタンを期待どおりに機能させる必要があります動作します 。
いくつかの人々が質問にコメントしているように-それは技術的な理由です。
ただし、ほとんどの技術的な理由と同様に、技術的な解決策があります（ほとんどの場合、安全なアプリはまったく別の魚のやかんです！）。それらはおそらくコストがかかるか、遅いか、そうでなければ何らかの面で厄介ですが、それは不可能な問題ではありません。
サイトが戻るボタンを壊す本当の理由は開発努力の投資を優先することに帰着し、まったく技術的ではありません。簡単に言えば-優先度が低すぎて努力を受けることができない傾向がある、または悪臭の一部が原因である「うーん...それは機能しますが、それは怪しげに聞こえます。それほど好きではありません。」）それに伴う問題は、問題よりも悪いと認識されています。
戻るボタンの問題を回避するにはいくつかの方法があります（問題のないサイトやブラウザーベースのイントラネットツールで証明されています）が、実装にはコスト（時間、お金、保守性）があり、すごいことはありません因子。
したがって、理由は技術的ではありません。
技術的には回避できます。この問題が発生するのは、修正に時間と労力を費やして（最初の作成と維持の両方に）費用がかかりすぎるためであり、そうなると、待ち行列を下る方法も-おそらくそれが起こらないほど十分に遠いからです。
多くの場合、その投資に値するとは見なされないか、「いつか修正する必要がある」リストに永続的に含まれます。
まとめると：修正は優先事項ではありません。他のものは優先順位です。他のことをします。そうでない場所では修正されます。
ここでの問題の核心は、過去数十年の間、WebブラウザーはWebサイトをナビゲートするための非常に優れたツールでしたが、最新のWebサイトは根本的に異なる方法で機能し、私たちが使用するブラウザーは、必ずしもそれらをナビゲートするための最良のツールではないということです。
最も単純なWebサイトは、静的ドキュメントの階層と、それらの間のハイパーリンクで構成されます。
例：
Home Page
About Us
Products
Contact
Help
ユーザーがこのWebサイトに移動すると、まずWebサーバーにホームページを要求します。 Webサーバーは、HTMLドキュメントと、ホームページ全体を説明するその他の各種アセットを返します。ユーザーはそのページを閲覧し、製品ページのハイパーリンクをクリックします。ブラウザは、そのページのリクエストをWebサーバーに送信します。ブラウザーがWebサーバーから新しいWebページを受信すると、ホームページ全体が破棄され、製品ページに置き換えられます。ユーザーがホームページに戻りたい場合は、戻るボタンをクリックします。これは、ブラウザに「現在開いているページをすべて破棄し、最後に表示したページを元に戻す」ことを伝えます。
説明した例で、WebブラウザーとWebサーバーがどのように相互作用するかを詳しく見てみましょう。
Stack Exchangeのリンクをクリックして質問を表示します。 Webブラウザーは、その質問のWebページを要求する要求をStack Exchange Webサーバーに送信します。 Webサーバーはページを見つけてブラウザーに返します。下にスクロールし、クリックしてコメントセクションを展開します。ブラウザーはそれらのコメントの要求をWebサーバーに送信しますが、それらのコメントが返されると、現在のドキュメントを破棄してコメントを含む新しいドキュメントに置き換えるのではなく、適切な場所にある現在のドキュメントに新しいコメントを挿入します場所。
別のページに移動して[戻る]ボタンをクリックすると、Webブラウザーには、最後にアクセスしたドキュメントが質問のページであることが表示されますが、そのページに加えた変更についてはわかりません（新しいコメントを挿入するような）。
これは、Webサイトの本来の動作方法とは根本的に異なる方法でWebサイトが動作する方法の例です。一度に1つのドキュメントを表示する代わりに、実際にはドキュメントの小さなフラグメントをたくさん要求し、それらをブラウザーで組み立てています。
では、非常に多くのWebサイトで[戻る]ボタンが機能しない理由は何でしょうか。これは、Webサーバーから要求された最後のページを読み込むことで[戻る]ボタンが機能するためです。また、多くの最新のWebサイトは、他のページのフラグメントからブラウザーでWebページが動的に構築されるパラダイムを使用して設計されています。
ほとんどのWebサイトでは、戻るボタンを壊すことを正当化することは非常に困難です。ショッピングカート、銀行送金などでもべき等にすることができるので、更新したり、元に戻したり、転送したりしても、予期しない動作は発生しません。
戻るボタンをサポートできないシナリオがいくつかあります。たとえば、私は数年前に非常に複雑なWebアプリケーションに取り組みましたが、すべてのシナリオで戻るボタンを完全にサポートすることは非常に困難であり、おそらく不可能でした。
すべてを理解するために多くの時間を費やすのではなく、戻るボタンをオフにすることにしました。最終的に、アプリケーションが十分なコンテキスト主導のナビゲーションを提供し、戻るボタンを逃さなかったので、誰も文句を言いませんでした。
戻るボタンをいじってはいけないと多くの人が言うだろうが、私には厳しすぎる。