「リッチ」アプリケーションが戻るボタンを壊すことはますます一般的になっています。私はいつもこれは悪い形だと思ってきましたが、おそらくその見方は時代遅れですか？
戻るボタンを壊しても大丈夫ですか？もしそうなら、基準は何ですか？
回答:
予想される場合にのみ、戻るボタンを解除します（Webサイトでイベントが発生した後に戻らないことが合理的である場合）。
Mozillaは、人々がどのようにブラウザを使用しているかについて調査しました。戻るボタンの結果は印象的です。
[戻る]ボタンは、他のナビゲーション要素（つまり、[戻る]、[進む]、[再読み込み]、[停止]、および[ホーム]ボタンを意味する）よりも頻繁に使用されます。調査参加者の93.1％が[戻る]ボタンを少なくとも1回使用し、平均して、各ユーザーが5日間で [戻る]ボタンを66.2回クリックしました。これは、[再読み込み]ボタンの3倍、[ホーム]ボタンの10倍、30倍以上のクリックです進むボタンと停止ボタン！
戻るボタンはよく使いますが、使えないときは嫌いです。
戻るボタンを壊しても問題ない場合がありますが、ほとんどの場合不要です。あるページから次のページに投稿するマルチステップフォームでよく見ました。このインスタンスで行うべきことは、フォームページから（1）、別のページに投稿して（2）（たとえば）セッションに内容を保存してから、別のページにリダイレクトします（3）。ユーザーが戻るボタンを押すと、（3）から（1）に戻ります。
RIAを使用しても、URLハッシュ/アンカー（つまりpage.html#section）を使用して、変更を監視できます。Gmailは、受信ボックス、作成、設定などのさまざまな「ページ」に対してこれを行います。スタックオーバーフローに関するこの質問は、実装する場合に役立ちます。
「ますます一般的になっている」主な理由は、一部のRIAフレームワークでは[戻る]ボタンがサポートされていないか、使用方法をアプリケーションに組み込む方法を積極的に検討する必要があるためです。ただし、Silverlight 3のFramesおよびPageコントロールのサポートなど、ほとんどのフレームワークではナビゲーションのサポートが提供されますが、効果的に使用する方法を知っている必要があります。同じナビゲーションフレームワークがWindows Phone 7アプリケーションで使用されます。
私の経験では、ブラウザのコンテキスト内でアプリ（上記のSilverlightなど）などの含まれているフレームワークを使用し、明確で適切なナビゲーションを設定している場合を除き、とにかく動き回るのは得策ではありません。デフォルト機能。私がそれを使用しているのを見た場合、別のブラウザがjavascriptと互換性がないか、セッションが常に正しく保存されないという問題がほとんど常にあり、誰かが「誤って」ボタンを押すと、物事が期待どおりに続行しない傾向があります。
「頻繁な」ユーザーが「戻る」ボタンを押す方法、または単に「ブレーク」するのが「良いアイデア」ではないことを軽視しないために、別の提案を提供します。彼らが今いる場所に着いた。多くの場合、リンククリックを1つ戻さないほうが理にかなっており、使いやすくなっています（実装がはるかに簡単になる場合があります）。たとえば、フォトアルバムを閲覧します。ユーザーはアルバムを選択するためにワンクリックを行い、サムネイルが表示されます。サムネイルをもう一度クリックすると、その写真に次/前のリンクが表示されます。この時点で、ユーザーはアルバムをナビゲートします。終了したら、クリックして戻ります。この時点で、前の画像よりもサムネイルに戻る方が便利で直感的です。
要するに、戻るボタンは何かをする必要がありますが、正確に何をすべきかはアプリケーションによって異なります。