役立つ500内部サーバーエラーページを作成する方法
私は有用な HTTPエラー500内部サーバーエラーページ を作成しようとしています。そして、私が見つけた推奨事項と、私が非常に単純なレイアウトを使用して作り上げたライブの例です。基本的には次のものが含まれます。
- ロゴ
- 見出し
- メッセージ
- そして、ページのリロード、後で戻ってくる、またはウェブマスターに連絡するなど、それを修正する方法のいくつかのソリューション。
訪問者がWebサイト上の別のページを見つけることができるように、メインのサイトナビゲーションまたは検索バーも含めない理由は何ですか？それは技術的ですか、それとも単にエラーメッセージに焦点を合わせ続けるためですか？
適切なエラーページのポイントは、エラーについて謝罪し、何が起こったかを簡潔に説明します、これの原因、および次のステップ取る。
ただし、error 500が適切な説明を提供することはほとんどないため、エラーページはあいまいである必要があります。この結果、ユーザーはページの更新を開始し、コードの大規模な障害が発生した場合でも、ページが奇跡的に表示されることを期待しています。したがって、次に何をするかについての明確な指示でそのような動作を防ぐ必要があります。
訪問者に「サイトは死んでいます。あきらめるべきです」と伝えるのは良い習慣ではありません。ユーザーはある程度の制御感と状況への関与を持っている必要があるため、規模が大きくても小さくても、エンジニアリングチームにメッセージを送信できるようにして、状況を伝えます。次に、サイトがバックアップされたら、それらを（一般的にも）電子メールで送信し、エラーの報告と復活の通知に感謝します。
これまでに見つけた最高のサンプルデザインは Goodbye、Old 500 Pageon Think Vitamin（web.archive.org） です。 =。 NetTuts +（ one and two ）およびSmashing Magazine（ one ）のエラーページの例もご覧いただけます。複数の場所にいるので、すべてのページで500をページで検索します。
エラーページにナビゲーション機能または検索機能を提供することは非常に良い考えだと思います。ユーザーが何かがうまくいかないことに気づいたら、次の考えはおそらく「今何をすればいいですか？」私たちはデザイナーとして、ユーザーがその決定をするのを助けることができ、そうするべきです。
この Carsonified の例は、私のお気に入りの1つです。 
トーンはあなたのブランドに適していないかもしれませんが、これらは私がそれについて好きなものです：
- ユーザーに責任を負わせるのではなく、ページに開発者の写真を掲載するまで、エラーの責任を負います。
- ユーモアはイライラしたユーザーの気分を良くするのに役立ちます
- ユーザーはチームにフィードバックを送信するオプションがあります。理想的には、これは再現するための手順を意味しますが、暴言でさえ、ユーザーが状況をより制御できるように支援することができます。
- 問題が調査されていることを意味します
私は自分のアプリケーションのカスタム500サーバーエラーページについて考えていました。興味があれば、私の blog をチェックアウトできます。ここでは、このリストについて詳しく説明し、追加のスクリーンショットを用意しています。
500を他のエラーと異なる方法で処理する合理的な理由はないと思います。 ただし、エラーが5xxの範囲内にある場合may次のいずれかの問題が発生します。
- サーバー構成が無効です。現在のリソースだけでなくサイト全体に影響するため、メインメニューが役に立たなくなります（他の多くのエラーページへのリンクにすぎません）。
- 同じことが検索機能に適用される場合があります
- エラーは管理者だけが修正できるため、ページをリロードすることはできません（少なくとも管理者がエラーを修正するまで）。
これを考慮すると、「安全にプレーする」ことを好み、ロゴ、見出し、エラーメッセージのみを提示する方がよいことが理解できます。