このエントリーは「404ページのデザイン提案」の続きにあたります (前編 [http://www.yasuhisa.com/could/article/designing-404-1/]) (中編 [http://www.yasuhisa.com/could/article/designing-404-2/])スケッチをすることでページの大まかな形が見えてきたところで、早速コーディングに入りました。404という1ページの課題なので、そうしているというのもありますが、最近は Photoshop とかでビジュアルを固めないままマークアップを記述することがあります。結局ブラウザで表示される状態でないと分からないこともありますし、骨格の状態から徐々に色や雰囲気を加えて行く作業は結構楽しかったりもします。構造への意識もしやすいですし、この時点でまたレイアウトを吟味出来る機会があるという意味でもメリットがあると思います。こういう作り方をしているので、ブラウザのデバッグツールが充実しているのは非常にありがたいです。 すべての案件でそうしているわけではないですが、今後はそうしていきたいですし、素早く

このエントリーは「404ページのデザイン提案【前編】 [http://www.yasuhisa.com/could/article/designing-404-1/]」の続きにあたります。なぜ 404 ページが表示されたのか、そして利用者が出来る次のアクションが何かがみえてきました。これからいよいよ大まかなレイアウトのスケッチに入るわけですが、もうひとつ考えておきたいことがあります。ページに表示させたい項目だけでなく、必要でないと考えられる要素も洗い出しておくと、スケッチが最初の段階からある程度洗練されたものになります。 通常のページでは必須項目でも目的が絞られてるページだとそうではない場合があります。「あっても良い」「もしかすると誰か必要になるから」くらいの要素は目的が絞られているページでは省いてしまっても良いと思います。要素を最小限に絞り込むことで、ページで伝えたい目的がより明確になるでしょう。サイト内のリンクからで 404 が表示される割合より、サイト外からのアクセスで 404 が多く表示されています。そこで、サイト内でいろいろ読みたいけど行き詰まった人というよりかは、読みたい

Twitter [http://twitter.com/yhassy/status/4492566304]のほうでひっそりと告知しましたが、404ページ [http://bit.ly/z8X7x] のデザインを変更してみました。なぜこんなところから始めたのかというと、サイト制作でいつも後回しになってしまう部分なので考えてみたかったですし、1ページ完結型なので早く形に出来るというのが理由です。いわゆるエラーページなわけですが、「見つかりませんでした」という結果表示ではなく何か補助出来ないかというのがテーマでした。 機械的なエラーの表示の仕方はケアが必要です。多くの利用者はエラーをみると、たとえシステムエラーでそうなったとしても、自分のせいにしてしまう場合があります。メッセージの出し方によっては「何か誤操作をしてしまったか」「そもそも何が起こったの？」「もしかして壊した？」といった感情を引き出してしまう可能性があります。利用者が悪くないのに、悪いと突き出してしまうような見せ方だけは避けなくてはいけません。 専門用語を使ったり、簡略化過ぎるエラーの説明もよくありません（説明抜きにしておも