記事ページを新して半年経ち、読者の動きに様々な違いが表れ始めました。良くなった点とそうでもなかった点をみて、今後の課題を幾つか考えてみました。

このエントリーは「404ページのデザイン提案」の続きにあたります (前編) (中編) スケッチをすることでページの大まかな形が見えてきたところで、早速コーディングに入りました。404という1ページの課題なので、そうしているというのもありますが、最近は Photoshop とかでビジュアルを固めないままマークアップを記述することがあります。結局ブラウザで表示される状態でないと分からないこともありますし、骨格の状態から徐々に色や雰囲気を加えて行く作業は結構楽しかったりもします。構造への意識もしやすいですし、この時点でまたレイアウトを吟味出来る機会があるという意味でもメリットがあると思います。こういう作り方をしているので、ブラウザのデバッグツールが充実しているのは非常にありがたいです。 すべての案件でそうしているわけではないですが、今後はそうしていきたいですし、素早く骨格（又はプロトタイプ）が作れるようにならないといけないなと思っています。CSS3がもっと使える状態になれば、さらにいろいろな装飾が CSS で可能になるので、マークアップしながら装飾やインタラクションを充実させていく作り方のメリットが高まるでしょう。装飾画像の重なり具合の調整や角度を少しずつ変える作業がたった１行で出来るわけですから素敵じゃないですか。 今回のページだけではないですが、だいたい最初のマークアップでは、ブラウザ云々はあまり考えずにサッとキレイに書ける手段を選びます。例えば最初は :nth-of-type(n) や :last-child といったセレクタは積極的に使っています。最初は面倒な感じがしますが、覚えてしまえば使った方が断然楽なんですよね。HTML に必要以上にクラス名を増やすことなく装飾が出来ますし、より柔軟性が増すような気がします。 当然ながら、上記に挙げたセレクタは IE ではさっぱり理解出来ません。見た目をまったく同じにする必要はありませんが限度もあるので、ここから徐々にクラス名を加えて調整をしていきます。今回は凝ったレイアウトではありませんが、場合によっては IE 向けの CSS ファイルを用意してレイアウトの調整を行うことがあります。もちろん、多くのセレクタは jQuery を使えば IE でも擬似的に使えますが、JavaScript の処理が遅い IE に対して装飾のために負荷をかけるのはどうかと思い、今回は止めておきました（ケースバイケースですし、１、２くらいすることはありますが）。 装飾のほうは IE のケアだけでなく、別ブラウザの拡張属性を利用することもあります。例えば Box Shadow はひとつの例でしょうね。とはいっても最近のブラウザの実装スピードが良好なので、それぞれのブラウザで大きく違うということにはならないです。 真ん中のほうにある、記事数はダイナミックに生成されています。以下の PHP を記述することで数値を取得することが出来ます。あとは好きなところに書き出すだけ。 $article_count = $wpdb->get_var("SELECT COUNT(*) FROM $wpdb->term_relationships WHERE term_taxonomy_id=15;"); 最後にある term_taxonomy_id のあとに続く数字は取得したいカテゴリ ID にします。あと、「いろいろなトピックを扱っています」という文章に添えられているキーワードのほうは PHP を記述しなくても wp_tag_cloud を使えば表示出来ます。 しばらく真剣に記述してなかったので、今回の 404 ページは HTML5 にしていますが、CSS の継承が楽になることを除いてはこれといってメリットが感じられませんね。まぁ 404 という小さな場所でメリットどうこう言うのも変ですけど。まだ確定していないことが多いので当然ながらしばらく様子見になりますが、ブラウザとそれを実装しているデバイスの技術、そして JavaScript や CSS といった HTML と一緒に使う技術をどう組み合わせるかによって HTML5 のメリットが明確になるでしょう。これから楽しみですね。 hail2uさんのように自分ならではの 404 ページを提案している方がいます。いろいろあっても良いよね 最初公開した時点では「404 Page Note Found」がやたらでかい文字でしたが、ご指摘をいただいて日本語のほうを大きく見せることにしました。こっちのほうが良いと思います ページが見つからない。情報が見つからない。うーん 404ページの情報量の加減は難しいですね。多すぎると意図が分からなくなりますし、少な過ぎても突き放してしまう感じがします RGBa 大好き ひっそり COLOURlovers から色データ取得して使ってます。効果的な使い方とはいえないですが、ちょっとしたアクセントにはなってるかと

このエントリーは「404ページのデザイン提案【前編】」の続きにあたります。 なぜ 404 ページが表示されたのか、そして利用者が出来る次のアクションが何かがみえてきました。これからいよいよ大まかなレイアウトのスケッチに入るわけですが、もうひとつ考えておきたいことがあります。ページに表示させたい項目だけでなく、必要でないと考えられる要素も洗い出しておくと、スケッチが最初の段階からある程度洗練されたものになります。 通常のページでは必須項目でも目的が絞られてるページだとそうではない場合があります。「あっても良い」「もしかすると誰か必要になるから」くらいの要素は目的が絞られているページでは省いてしまっても良いと思います。要素を最小限に絞り込むことで、ページで伝えたい目的がより明確になるでしょう。サイト内のリンクからで 404 が表示される割合より、サイト外からのアクセスで 404 が多く表示されています。そこで、サイト内でいろいろ読みたいけど行き詰まった人というよりかは、読みたい情報へ辿り着かなかったけどどうするかと考えている人が多いと判断。カテゴリリストのようなメニュー要素は省き、誘導の仕方も 404 に対する解決に絞ることにしました。 イメージが結構膨らんできたので、具体的にページ構成を考えてみました。資料として誰かに見せなければならないというわけではありませんし、思い立ったときにすぐに描けるということで、ノートにスケッチ。右図が最初に描いたスケッチになります。こうしたステップをふめば必ず探している情報に辿り着きますよ、というストーリー仕立ての構成。ちょっとしたアイコンも添えて少しやわらかい雰囲気が特徴です。 この時点で、サイトにある記事数を表示するアイデアが生まれました。利用者が探している情報へ行き着くためのヒントとは言いきれませんが、ここをキッカケに「なんならいろいろ見てみるか」と思ってもらえると良いなと考えました。人気記事などをリストアップすることも考えましたが、そこまでやると読ませてしまうので、ザッとみて雰囲気が分かる数字やキーワードだけにしました。 最初のバージョンでも悪くなかったのですが、ひとつひとつ要素を囲うのは少々息苦しく感じたので、ステップごとにコンテンツを分けるものの開放感のある見せ方が良いと思いました。左図のスケッチが次の描いたものです。線をウィンドウの幅全体に広げるだけでも少しダイナミックな雰囲気になります。一応、ステップはあるものの、この順番でしなければならないわけでもないので、特徴的だった矢印もここでは目立たなくなっています。また、マークアップをし始めた際に決めましたが、同じ理由で番号も完成版ではなくなっています。 ページのテンプレート化や要素のコンポーネント化は、サイトの拡張性を考える上で必須になります。しかし、目的が絞られているページであれば、「こうしなければならない」というルールから少し外れて目的に合わせたカスタマイズをするといいでしょう。そうすることでサイドバーやページの片隅ではなくコンテンツエリアに検索フィールドを入れた方が良いというアイデアも自然に出てきます。

Twitterのほうでひっそりと告知しましたが、404ページのデザインを変更してみました。なぜこんなところから始めたのかというと、サイト制作でいつも後回しになってしまう部分なので考えてみたかったですし、1ページ完結型なので早く形に出来るというのが理由です。いわゆるエラーページなわけですが、「見つかりませんでした」という結果表示ではなく何か補助出来ないかというのがテーマでした。 機械的なエラーの表示の仕方はケアが必要です。多くの利用者はエラーをみると、たとえシステムエラーでそうなったとしても、自分のせいにしてしまう場合があります。メッセージの出し方によっては「何か誤操作をしてしまったか」「そもそも何が起こったの？」「もしかして壊した？」といった感情を引き出してしまう可能性があります。利用者が悪くないのに、悪いと突き出してしまうような見せ方だけは避けなくてはいけません。 専門用語を使ったり、簡略化過ぎるエラーの説明もよくありません（説明抜きにしておもしろ楽しく見せる方法はアリですがサイトのターゲットユーザーによるでしょう）。利用者が分かると思われる範囲でエラーが表示されている理由を簡略に説明するほうが良いですし、回避方法・解決方法を幾つか提案すると次のアクションへ繋がると思います。 では何が 404 を引き起すのでしょうか。4つ可能性が考えられます。 スペルミス ページの削除・移動 リンクミス (私には理解不能な) システムエラー ものすごい数というわけではりませんが、意外と多かったのがスペルミス。Webmaster Tools は、どのアドレスで 404 が表示されたのかを記録していますが、それによると全角スペースが付いていたり、2つのアドレスがひとつになっていたり、日本語が付いていることからエラーに繋がっているケースが見られました。メール、SNS、Twitter などコミュニケーションの際に気軽にリンクをはるものの、クリックするとエラーが出ているのかもしれません。 利用者にも分かる範囲で何が起こったのか説明した後、どのような『出口』を提案できるでしょうか。検索を通してアクセスしようと思ったサイトに近づけるかもしれません。他の記事へ興味をもってもらうための入り口になるかもしれません。あれこれ提示するのはクドいですが、次のページへ繋がるヒントを利用者に提供出来ると良いなと。わざわざエラーが出たからといって連絡をする方はほとんどいませんが、誰がこのサイトの『責任者』であることを明示し連絡の窓口を築くにもサイト運営をする立場として重要な姿勢だと考えています。特にエラーページはそうかもしれませんね。 中編 - 情報構造スケッチ 後編 - マークアップ

この記事は「リンクタイプの構成案」の続きにあたります。 とてつもなく間が開いてしまいましたが、忘れてしまったとか飽きてしまったというわけではないですよ。他のことを書いたりしているとついつい後回しになってしますね。徐々にまたスピードを上げて行きますのでよろしくお願いします。 さて、リンクの構成案は随分前に出来上がっていたのですが、肝心の実装を進めていなかったので初めて見ました。途中経過ですが、どんな感じで進んでいるのかをこの場で共有したいと思います。作る前にリンクタイプには以下のような条件項目を挙げました。 リンクのリストは <dl> で構成。 <dt> にサイト名、<dd> に簡単な説明文を書く スクリーンショットを入れたい マウスオーバーしたときのエフェクトを工夫したい メンテナンス・拡張性を考えると面倒な作業や特殊なマークアップルールなしで実現したい 似たようなサイトを手軽に探す機能は自動化させたい JavaScript のライブラリは jQuery を採用。階層を縦貫して値を取り出したり、改ざんや新しい要素を加えたりするのに使いました。あと、<dt> エリアをマウスオーバーしたら <dd> エリアも一緒にハイライトしたり、 マークアップ上ではリンクがない <dd> エリアでクリックしてもリンク先へ移動出来るようなイベントも追加されています。 当初 SimpleAPI からスクリーンショットを取得しようと思いましたが、ドメインのトップページが画像になるだけで、下階層のスクリーンショットが撮れるわけではないことが判明。例えば YouTube にあるビデオリンク集を作ると、すべて同じ見た目になってしまうわけです。そこで今回はScreenCasaを使ってスクリーンショット画像を取得。無料で YouTube のビデオもちゃんと内容が分かる画像で生成されます。画像の取得と貼付けも JavaScript 経由。こうしておけば、たとえ ScreenCasa から違うサービスに移行したり見せ方を大幅に変えたとしても対応がしやすいという利点があります。 エントリーの下には関連情報として Google Ajax Search API を利用した検索結果を表示させています。ほとんどそのままサンプルコードを使っただけですが、検索キーワードはエントリーのタグ (キーワード) を使って欲しいので、以下のように PHP でタグ名を検出し Google さんに検索してもらうように記述しました。 var term = "<?php $posttags = get_the_tags(); if ($posttags) { foreach($posttags as $tag) { echo $tag->name . ' '; } } ?>"; searchControl.execute(term); 当然ながら、これで正確に関連したサイトを見つけてくるというわけではないですが、エントリーキーワードはいつも 2,3 記述しているようにしているので、的外れなサイトが検索結果に表示されることは今のところなさそうです。 アーカイブページもほとんど同じ形式を継承していますが、こちらは延々とリンクが観覧出来るように日付、キーワード、コメント数といった要素を省きました。昔からあるようなリンク集そのままといった感じですね。実は IE6 では崩れているというわけではないのですが、見え方が他のブラウザとちょっと違うのが今の課題ですね。リンクがクリック出来ないとかエラーが出るというわけではないので、プライオリティは高くないですが検討しておきたい部分ではあります。今後リンクタイプのビジュアル面の調整やサイドバーにも手を加えて行きます。リンクタイプが終わると比較的フォーマットが近いまとめタイプもすぐに終わりそうな予感。