openwebdesign

A collection of 22 posts

openwebdesign

今月のデザイン変更点

昨年8月に「記事ページのアクセス通信簿」と題して記事ページのデザインの変更の意図とその効果について解説しました。その後、いろいろ機能を追加して模索をしているのですが今月が大きな機能が幾つか追加されたのでその紹介も含め、効果と課題について紹介していきます。 次に繋げるための工夫 まとめ系記事を除いて、記事は非常に高い割合で最後まで読まれている場合が多く、滞在時間も長いです。コンテンツの質も月ごとで若干異なるのでなんともいえないですが、今月は直帰率も低かったので読者が滞在してくれた月といえるかもしれません。 しかし、このサイトは検索やソーシャルメディアなどを通じてサイトにアクセスする方が多いこともあり、一期一会の関係で終わってしまう場合が多々あります。平均ページビューを増やすにはどうにかしたらいいのか、どのサイトも頭を悩ませているかと思います。たくさん選択肢を与えればクリックするわけでもありませんし、メインコンテンツ (記事) の邪魔をしていたら逆効果です。 そこで今回追加した機能が「ランダム」と「ガイド」です。ランダムはその名のとおり、クリックするとランダムで別の記事を読むことが出来ます。特に目的はないけど、何かおもしろいものが見つかるかもしれないという楽しみを与えてくれると考えました。Random Post Linkというプラグインを使えば簡単に導入できます。 「ガイド」はこのサイトに訪れた方に読んでもらいたい旬な記事を集めています。以前からあった人気記事リストはこちらに移動し、新たに一押し記事のエリアも追加。こちらは WordPress の the_post_thumbnail を活用。
openwebdesign

記事ページのアクセス通信簿

今のような記事ページになった理由 今年の始めに記事ページを新しくしました。そのあと小さな調整を行ったり機能を追加はしていましたが、そろそろどのような結果が出たのが発表するには良い時期だと思いますので幾つか紹介したいと思います。 ご存知の方もいるかもしれませんが、今「記事」と呼ばれるエントリーはほとんどすべてレイアウトが違います。中には色を変えただけのものもありますが、レイアウトが少し複雑なものや画像が活用されているものもあります。凝り過ぎたことをすると読み難くなってしまいますが、毎回見た目が新鮮なので飽きることもありませんし、それがキッカケで読んでくれる方もいるかと思います。 最近、海外ではこうした記事ごとにレイアウトを変えるという手法が増えて来ていますが、私は10年近く前に同じようなことをしていました。当時は CMS もなく、ひとつひとつ HTML で書いていました（アーカイブページのリンクまで手書きで調整していたわけですから、今考えると信じられない手間ですね)。学生で時間があったということで日記を書く度にレイアウトを変えていましたし、場合によっては Flash も利用していました。 ではなぜ、この時期に今のような形式に変えたかには理由があります。大きな要因となったのは Twitter でしょう。ちょっとしたサイトの紹介や、短い思いを語るには Twitter で十分になりました。Twitter の登場により、ブログを書かなくなった方もいると思いますが、私の場合はこれで役割分担がしやすくなると感じました。手軽な情報は Twitter、分析や主張など長い文章を掲載するにはサイトを利用するといった住み分けが必要になったわけです。
openwebdesign

404ページのデザイン提案【後編】

このエントリーは「404ページのデザイン提案」の続きにあたります (前編) (中編) スケッチをすることでページの大まかな形が見えてきたところで、早速コーディングに入りました。404という1ページの課題なので、そうしているというのもありますが、最近は Photoshop とかでビジュアルを固めないままマークアップを記述することがあります。結局ブラウザで表示される状態でないと分からないこともありますし、骨格の状態から徐々に色や雰囲気を加えて行く作業は結構楽しかったりもします。構造への意識もしやすいですし、この時点でまたレイアウトを吟味出来る機会があるという意味でもメリットがあると思います。こういう作り方をしているので、ブラウザのデバッグツールが充実しているのは非常にありがたいです。 すべての案件でそうしているわけではないですが、今後はそうしていきたいですし、素早く骨格（又はプロトタイプ）が作れるようにならないといけないなと思っています。CSS3がもっと使える状態になれば、さらにいろいろな装飾が CSS で可能になるので、マークアップしながら装飾やインタラクションを充実させていく作り方のメリットが高まるでしょう。装飾画像の重なり具合の調整や角度を少しずつ変える作業がたった１行で出来るわけですから素敵じゃないですか。 今回のページだけではないですが、だいたい最初のマークアップでは、ブラウザ云々はあまり考えずにサッとキレイに書ける手段を選びます。例えば最初は :nth-of-type(n) や :last-child といったセレクタは積極的に使っています。最初は面倒な感じがしますが、覚えてしまえば使った方が断然楽なんですよね。HTML に必要以上にクラス名を増やすことなく装飾が出来ますし、より柔軟性が増すような気がします。
openwebdesign

404ページのデザイン提案【中編】

このエントリーは「404ページのデザイン提案【前編】」の続きにあたります。 なぜ 404 ページが表示されたのか、そして利用者が出来る次のアクションが何かがみえてきました。これからいよいよ大まかなレイアウトのスケッチに入るわけですが、もうひとつ考えておきたいことがあります。ページに表示させたい項目だけでなく、必要でないと考えられる要素も洗い出しておくと、スケッチが最初の段階からある程度洗練されたものになります。 通常のページでは必須項目でも目的が絞られてるページだとそうではない場合があります。「あっても良い」「もしかすると誰か必要になるから」くらいの要素は目的が絞られているページでは省いてしまっても良いと思います。要素を最小限に絞り込むことで、ページで伝えたい目的がより明確になるでしょう。サイト内のリンクからで 404 が表示される割合より、サイト外からのアクセスで 404 が多く表示されています。そこで、サイト内でいろいろ読みたいけど行き詰まった人というよりかは、読みたい情報へ辿り着かなかったけどどうするかと考えている人が多いと判断。カテゴリリストのようなメニュー要素は省き、誘導の仕方も 404 に対する解決に絞ることにしました。 イメージが結構膨らんできたので、具体的にページ構成を考えてみました。資料として誰かに見せなければならないというわけではありませんし、思い立ったときにすぐに描けるということで、ノートにスケッチ。右図が最初に描いたスケッチになります。こうしたステップをふめば必ず探している情報に辿り着きますよ、というストーリー仕立ての構成。ちょっとしたアイコンも添えて少しやわらかい雰囲気が特徴です。 この時点で、サイトにある記事数を表示するアイデアが生まれました。利用者が探している情報へ行き着くためのヒントとは言いきれませんが、
openwebdesign

404ページのデザイン提案【前編】

Twitterのほうでひっそりと告知しましたが、404ページのデザインを変更してみました。なぜこんなところから始めたのかというと、サイト制作でいつも後回しになってしまう部分なので考えてみたかったですし、1ページ完結型なので早く形に出来るというのが理由です。いわゆるエラーページなわけですが、「見つかりませんでした」という結果表示ではなく何か補助出来ないかというのがテーマでした。 機械的なエラーの表示の仕方はケアが必要です。多くの利用者はエラーをみると、たとえシステムエラーでそうなったとしても、自分のせいにしてしまう場合があります。メッセージの出し方によっては「何か誤操作をしてしまったか」「そもそも何が起こったの？」「もしかして壊した？」といった感情を引き出してしまう可能性があります。利用者が悪くないのに、悪いと突き出してしまうような見せ方だけは避けなくてはいけません。 専門用語を使ったり、簡略化過ぎるエラーの説明もよくありません（説明抜きにしておもしろ楽しく見せる方法はアリですがサイトのターゲットユーザーによるでしょう）。利用者が分かると思われる範囲でエラーが表示されている理由を簡略に説明するほうが良いですし、回避方法・解決方法を幾つか提案すると次のアクションへ繋がると思います。 では何が 404 を引き起すのでしょうか。4つ可能性が考えられます。 スペルミス ページの削除・移動 リンクミス (私には理解不能な) システムエラー ものすごい数というわけではりませんが、意外と多かったのがスペルミス。Webmaster Tools は、どのアドレスで 404 が表示されたのかを記録していますが、それによると全角スペースが付いていたり、
openwebdesign

リンクタイプの進行状況

この記事は「リンクタイプの構成案」の続きにあたります。 とてつもなく間が開いてしまいましたが、忘れてしまったとか飽きてしまったというわけではないですよ。他のことを書いたりしているとついつい後回しになってしますね。徐々にまたスピードを上げて行きますのでよろしくお願いします。 さて、リンクの構成案は随分前に出来上がっていたのですが、肝心の実装を進めていなかったので初めて見ました。途中経過ですが、どんな感じで進んでいるのかをこの場で共有したいと思います。作る前にリンクタイプには以下のような条件項目を挙げました。 リンクのリストは <dl> で構成。 <dt> にサイト名、<dd> に簡単な説明文を書く スクリーンショットを入れたい マウスオーバーしたときのエフェクトを工夫したい メンテナンス・拡張性を考えると面倒な作業や特殊なマークアップルールなしで実現したい 似たようなサイトを手軽に探す機能は自動化させたい JavaScript のライブラリは jQuery を採用。階層を縦貫して値を取り出したり、改ざんや新しい要素を加えたりするのに使いました。あと、<dt> エリアをマウスオーバーしたら <dd&
IA

リンクタイプの構成案

可能な限りフィードバックを得れるような状態にしながら、徐々に方向性を固めて組み立てれるように複数のサイクルで構成されたプロセスを提案しました。今回はその第一弾である「リンク」タイプのデザインに取りかかろうと思います。リンクは「クラフトっぽいアート作品いろいろ」のようにゆるいテーマがあるかもしれないですが、リンクが羅列しているようなエントリーのことを指します。 このタイプのエントリーはあまりブックマークもされることもなく、どちらかというと検索からくる方のほうが多いです。サイトへのロイアリティもあまり高くないので、最近のエントリーやタグリストなどといった全体像が分かるものを省いて、読者が必要しているものをはっきり見せることが必要とされるタイプになります。リンクタイプはイントロダクションのような文章もない単純なリスト（<dl> で記述）なので、文体も統一されています。マークアップ面では完全にパターン化されるので、独自の見せ方もしやすいです。 そのあたりを頭に入れて、とりあえず紙にワイヤーフレームやアイデアを書き込んでいきました。 リンクを紹介しているタイプなので、サイト名の文字を通常より大きくしたりクリックエリアを大きめにとるといった工夫は必須でしょう。また、リンク先のスクリーンショットも見えると良いですね。Snap Shots を使うという手段もあるかもしれませんが、ポップアップはちょっとうるさく感じることがあるので、ここは Simple API の力を借りることになるでしょう。 他に考えているのが、リンク集で扱っているようなサイトのリストアップ。これはタグをキーワードにして Google Ajax Search API
openwebdesign

ブログの向こう側にある会話を追う

この記事は「ブログでの会話を見えるようにするには」の続きにあたります。 従来オンライン上の会話は一元化されていました。例えばフォーラムや掲示板で会話を始めるためのネタが挙り、それに対しての反応がその場に連なっていました。ブログが使われるようになると、フォーラムでの会話だけでなくブログを中心とした会話もスタートしました。簡単にブログを設置することが出来るので会話が一カ所ではなく数多くの場所で発生するようになったものの、ブログにあるコメントやトラックバックによってなんとなく繋がり合っていました。また、TechnoratiやGoogleブログ検索を利用してある程度、会話を追うことも可能です。しかし、現在はさらに会話を追うのが難しくなってきています。 今はブログより気軽に自分の意見を書き込む場所が数多くあります。Livedoor クリップをはじめとしたソーシャルブックマークサービスのメモ機能。Tumblrのようなスクラップサービス。Newsingのようなソーシャルニュースサイト。コメントが集中するところは特定出来ますが、それでも膨大な数のサービスが存在します。最近ではFriendFeedのようなライフストリーム系のサービスでもコメントを記入出来るような機能を実装しており、類似サービスも幾つか登場してきています。 自分の意見をサクッと書く場所として最も敷居が低いのはTwitterやTimelogのようなプチブログ。1日に数十もの言葉を発している人も少なくないところから、インプットの敷居の低さが分かります。Twitter のようなサービスが典型といえますが、最近の会話が起こる場所はよりリアルの会話に近づいてきたといえます。リアルタイムかつ簡単に出来るだけでなく、発信するための道具も豊富にあるので、自分の発言スタイルやネットワーク (友達との繋がり方) にマッチしたものも選べば良いわけです。一元化されていてフラットだった会話がダイナミックでソーシャルになってきたといえるでしょう。 自分のブログを中心に発生する会話の場所も分散化しています。中心から離れるほどリアルタイムになり追ったりアーカイブするのが難しくなります。 このように単純にブログをチェックしているだけでは特定のトピックを取り囲んで行われている会話が追えなくなってきています。ここで課題になってくるのが、いわゆる Web 1.0
IA

サイドバーの行方

サイドバーはブログが広まる前から存在していたコンポーネント。メインコンテンツ以外の情報を上部に載せることが出来るので、多くのサイトでサイドバーが採用されています。実装も簡単に出来ますし、３カラム、４カラムと増やすことも出来るわけですが、実装の敷居も低いのでただの賑やかしになってしまいがちの部分でもあります。情報の配置の仕方によって、情報が活かされるときもあれば、そうでないときもあります。サイドバーもメインコンテンツ以外の情報を放り込む場所ではなく、的確な情報が載る場所として扱わなくてはいけません。 ブログのサイドバーで必要なもの サイドバーによくある情報は 最近のエントリーリスト 最近のコメントリスト アーカイブリスト カテゴリリスト タグクラウド Feed をはじめとした購読ボタン ウィジェット諸々 アクセス解析やサイトコンセプトによってサイドバーの使い方も変わってきます。このサイトは Feed は多くの方に登録されていますが、サイトまで訪れる方はその中のわずかな数ですし、エントリーによってアクセス数も数倍違うこともあります。よって、情報収集家が最も多いと仮定出来ます。もちろん、検索から訪れる方も少なくありません。つまり、レギュラー読者より初めてもしく時々サイトに訪れる方のほうが多いといえます。Feed を購読している読者もたまに訪れるわけでですから、彼らが久しぶりに訪れたときに便利な情報も欲しいところです。 ブログのサイドバーの情報の置き方で参考になるのは、ニュースサイトです。asahi.com>の記事ページをみると、サイドバーには「注目」
openwebdesign

複数のサイクルで構成されたプロセス

ブログエントリーをタイプ別に振り分け、どのような読者がサイトを訪れているのか漠然的ですがみえてきました。そして、ついにプロトタイプをそろそろ作って行くという段階に近づいて来たわけですが、ここでプロトタイプからテスト、もしくは公開までの進め方を紹介していこうと思います。 通常、上図のように分析、プロトタイプ、デザイン、コーディング、テストというプロセスが順に行われます。それぞれのフェーズにサイト全体を考慮しつつ進めて行くわけです。このプロセスは多くのサイト構築に使われていますし、特に問題もないと思いますが、別の方法も考えられます。特に様々なタイプのページが存在するところだと、全体を一気にデザインしたりコーディングするのではなく、細分化して進める方法もあると思います。 こうした進め方をするメリットは幾つかあります。 一部の機能やページに特化するのでフォーカスしやすくなるだけでなく、ビジョンの共有もしやすい ひとつひとつ組み立てていくことで全体的な方向性も見えて来る可能性がある 先に行われたサイクルが次のサイクルを進めて行く上で参考になるので、より洗練されていく フィードバックの数が必然的に多くなる まったく同じワークフローを繰り返すのではなく、サイクルを進めて行くにつれてより全体的なデザインへと進化していく ひとつのサイクルを終わせるごとに達成感を味わえる 特に最初に挙げた「ビジョンの共有」が、オープン Web デザインで重要な部分になっているところだと思います。サイト全体をどんどん構築するのはそれほど難しいことではないですが、その分あなたが消化しなければならない情報量が多くなります。しかも考慮しなければならない項目が増えれば増えるほど追うのが難しくなりますし、結果的にフィードバックが少なくなってしまいます。ひとつひとつ作ればそれだけ情報はフォーカスされた話題にもなりますし、プロセスもスピーディになるのではないかと考えています。 今までまとめて作っていた Webサイトを細分化して作って行くので、気をつけなければならない点も幾つかあります。
IA

拡張性のあるデータ配置を模索する

そろそろ大まかな形でワイヤーフレームを作っていこうと思っているわけですが、その前にいろいろ準備しておきたいことも幾つかあります。そのひとつが、拡張性を考えて、どのようなデータをどの辺りに配置するのがベストかを考えること。これは Webアプリケーション開発において特に重要になってくることだと思いますが、大幅な改変をしなくても、機能やミニコンテンツといったコンポーネントを付け加えることが出来るように設計しておく必要があります。もちろん、すべての可能性を考慮することは不可能ですが、あらかじめ拡張されることを考慮して設計を始めるか始めないかでは大きな違いがあります。 下の図はページを大まかに4つに別けて、異なる配置を考えたものです。 ※ ワイヤーフレームの基盤のような存在なので、実際のサイトのワイヤーフレームを作っているわけではありません。 ナビゲーション サイトのグローバルナビゲーションに当たるエリア。Webアプリケーションにおいては機能を示すことが多い コンテキスト / データセット 現在観覧しているページがどういったページが示していたり、サイト全体からみたページの位置を示しているエリア。パンくずがあるケースも メインコンテンツ ページのなかで最も重要とされるデータ。ブログであればブログエントリーのことを指す 関連データ / フィルター メインコンテンツに何かしらの形で関連したデータであったり、メインコンテンツを操作するためのコマンドがあるエリア どれが拡張する可能性があるのか見極める グローバルナビゲーションはサイト全体を大まかに見渡すことが出来る重要なエリアですが、サイトによっては幾つか増える可能性がある場合もありますし、ネーミングを長くしなければならないこともあるでしょう。そういった場合、ナビゲーションを横に配置すると、２列になってしまうなど限界が出てしまいます。名称が長いと、配置出来るナビゲーションの数も減っていくでしょう。そういう可能性があらかじめ分かっている場合であれば、横ではなく縦に配置したほうが良いです。 例えば Amazon.
openwebdesign

ブログでの会話を見えるようにするには

2005年なので少し前の資料になりますが、Noor Ali-Hasan という方がブログスフィアでどのように会話が始まってお互い繋がり合っているのかを調査した Analyzing the Social Patterns and Behaviors Associated with Blogrolls and Blog Comments という論文を発表しました。クウェート、アラブ首長国連邦、アメリカ・ダラス という異なる場所に住む 500人のブログと、それらに投稿されたコメント 4000通、サイドバーにある Blog Roll のようなリンク集を調べたそうです。視覚的に表現されたものもあるのでぜひ見て欲しいですが、論文で重要になってくるのが、場所や文化に関係なくブロガーは新しい人 (オフラインの世界で知らない人) と対話をする傾向にあるという点です。 試しに僕のサイトに投稿された過去 100以上のコメントから自分がまだ会ったことない方が何人いるか調べてみました。結果は 65.7% と半数以上は会ったことない方、知らない方になりました。3年前といえば、まだ SNS
openwebdesign

コメントを残す8タイプの読者

「コメントリストで考えられるパターン」では、ブログのコメントリストの見せ方から読者との関係を良いものに出来るかを考えて行きましたが、今回はもう少し突っ込んで読者にスポットを当てたいと思います。読者と一言でいってもブログに訪れる方は実に様々です。住んでいる場所も職種も年齢もすごく幅の広いです。それゆえ明確な切り分けは出来ませんが、コメントを残す方はある程度決まっていると思います。 もちろん人間なので、そのときのムードやちょっとしたことがきっかけで変化すると思うので明確な区別は出来ないですが、８つのタイプの方（もしくはモードになった方）がコメントを残したりコメントを残す可能性を秘めています。 友達・同僚 その人を個人的に知っているから読んでいる方も少なくないです。たとえ日常を書いた日記でもおもしろく読めるのは、文字だけでは伝わらない何かを読み取ることが出来るからかもしれません。今でも mixi 日記を書いたり読んだりするのは、この要素は大きいでしょうね。特に SNS だと特定の方しか見ないこともあり、軽いノリの一言コメントも気軽に書けます 情報収集家 RSSリーダーに登録している方で、タイトルや概要が自分にとって興味のある内容であれば全文読む方。興味や共感の度合いが高ければ、コメントや別の場所で何かフィードバックをしてくれます ゴールドメンバー すべてのブログエントリーを読んでいる方で、ときには過去のアーカイブも辿って読んでいます。コメントも積極的に残しており、自分もこのブログの一部であると感じている方もいると思います。ときにはモデレーターのような役割も果たすのもこのタイプ ファン ゴールドメンバーのように積極的な参加まではいきませんが、すべてのブログエントリーを読んでいてコメントもたまに残すタイプ。参加しているほうですが、どちらかというと今後の展開を楽しみながら観察している傾向にあります 黙読者 ほとんどのブログエントリーを読んでいますが、
openwebdesign

コメントリストで考えられるパターン

Webサイトの基本３要素のひとつである「Relationship」。ブログでは重要な部分ですし、例え企業サイトを構築する際にも重要な要素になっていきます（もちろんブログと同じ見せ方ではないですが）。ブログで最も簡単に関係を築く方法がコメントです。それぞれのエントリーにコメントフォームを置いて読者がいつでも感じたことを自由に書き込むことが出来るようにします。コメントを通じて筆者と読者の関係がより濃いものになるだけでなく、そのコメントを読む他の読者とも共感という間接的な繋がりをもつことが出来ます。 ひとつの窓口としてコメントは良い機能だと思いますが、不満点がないわけではありません。コメント数が長いと見た目が単調になり、読み難いという印象もありますし、多くの方に読んでもらうべき貴重な情報もコメントにあるがために読まれないというケースがあります。自分のサイトは自分が管理しているので気にはなりませんが、コメント数が多くページが延々と続くと読む気が失せることもあります。 貴重なコメントを読んでもらえるようにする 貴重なコメントをハイライトするひとつの方法として、Engadgetのような投票システムをコメントに導入というのがあります。ビジュアルには大きな変化はありませんが、ポジティブに投票されると「Highly Ranked」とラベルが付くので、それが貴重なコメントなのか読み流しながら見つけることが出来ます。 Engadget の手法をさらに押し進めているのが digg のコメントリスト。こちらでは投票によって評価が低いとコメントが非表示になりワンクリックしないと内容が読めないようになっています。Engadget のように読み流して自分で確認しなくても貴重なコメントだけが生き残るようになっているわけです。WordPress でも trollr! のようなプラグインを導入することで、似たようなコメントリストを作ることが出来ます。 こうした投票を利用して良いコメントを多くの方に読んでもらうという手法は悪くないですが、Engadget や digg のように大量のコメントが書き込まれる場で初めて有効な手段であって、それほど多くないブログではかえって投票システムの導入が隔たりになってしまうこともあります。
openwebdesign

手動と自動のバランスがサイトの質へと繋がる

カテゴリをエントリーのタイプと見なし、それぞれのエントリーに関するキーワードをタグとして書き込むという分類方法は多くの方にとってもしっくり来たといえるかもしれません。しかし、まだ考える余地が幾つかあるといえます。その代表格にあたるのが「タグの役割を考えた見せ方」でも話題になった「Follow-up」という分類。 Follow Up はサブタイプ ToruさんArticleのFollow Upならば、ArticleとFollow Up。AnnoucementsのFollow Upならば、AnnouncementsとFollow Up。と言う具合に、両方にタイプ付けはどうでしょうか？個人的にはFollow Upは必要無いのでは？ Toruさんが提案しているように、２つのタイプをチェックしておいたほうが良さそうです。また、「Follow Up」のリンクをクリックして、そのタイプのみを読むということはないでしょう。「Follow Up」というタイプが存在し、それを明確に表現したいですが、わざわざタイプリストのひとつとして表示していることもないでしょう。ある意味、「Follow Up」はサブタイプと呼べるのかもしれません。 タグもいらない 以下のような意見もよく見かけます。 reaさんまた必要以上にタグを付けているサイトもたまに見かけますが、それがかえって利便性を損なっている場合もあります。
openwebdesign

「マインドマッピングツール」としてblogを見る視点

この記事は「タグの役割を考えた見せ方」の続きにあたります。 とても重要な視点だと思うので紹介します。 rssky.tblr*より ここら辺の事をもう一回徹底的に考え直してみることが、実は「blogの次」に繋がっていくのだと思う。ここにプラスして小川宏高氏のラディカルなまでの正論と、あとやっぱトロット夫妻のもうそれはそれは絵に描いたようなリベラル理想主義の部分をプラスして。 　ヤスヒサさんに欠落しているのは「マインドマッピングツール」としてblogを見る視点、かな。（立ち位置をはっきりさせるためあえて除外してるんだと思うのだけど）　あるいは”個人のマインドマッピング”がサイト、というかコンテンツとして成り立ちうるか、とか。 　ツリー構造のカテゴリーと横断的連接のタグの相関関係を明確に見せる手法とセマンティック検索技術がうまく結びついた瞬間に”次のかたち”はそこに立ち現れるように思える。 実に鋭い意見だと思います。ここ２回ほど続いたエントリーでは関連タグを表示させるとか必要な情報を見せるといったことを中心に書いたこともあり「マインドマップ的」に見られるのは当然だと思います。そして僕自身もそういった部分だけにフォーカスしないように気をつけないといけないなと考えています。今回、カテゴリやタグといったどちらかというとシステマチックな部分がフォーカスしたこともあったかもしれませんが、当然のことながら、それだけだけでは良い体験には繋がらないと思います。 論理的な部分と視覚要素と感覚によって作り出す世界観といった感覚的な部分をいかに組み合わせてサイトを形にしていくのかが最大の難関なのではないかと思っています。ここにエントリーを書いて行く際もその部分に気をつけなければいけないなと改めて感じました。 こうした建設的な指摘をしてくださった rssky さんに感謝。こういうのがあるから Web でやることに意味があると思っています。
IA

タグの役割を考えた見せ方

この記事は「カテゴリとタグを上手に使い分ける」の続きにあたります。 カテゴリに関して迷っている方は少なくないみたいですね。前回、提案したブログエントリーをタイプ別に分類する提案をしましたが、それに対して様々な意見や感想が出ているので、ここで共有しておこうと思います。 lilacさん(カテゴリは) ふつうにいらないんじゃね？みたいな。明確に必要、という答えが出せないんですよね・・・ 他の方も書いていらっしゃいましたが、機能が提供されているからといって使わなければならないというわけではないと思います。無理にいろいろ使おうとするとかえって複雑化してしまうので、そういった場合は思い切って省くことも重要です。これはデザインするときには重要な考え方のひとつでしょう。 今回のようにカテゴリをタイプと見なして使うのは自分のサイトにはフィットしているように思えたから採用しましたが、ブログによってはタグだけで管理したほうが治まりが良いのもあるような気がします。 タグの扱い方いろいろ 前回のエントリーではカテゴリにフォーカスした話題でしたが、タグはどうでしょう。役割が明確になってきたので、コンテンツに関わるキーワードを記入していけば良いわけですが、多くなって来るとどうページに表示させて良いか迷うところです。Tag Cloud の見せ方はいろいろあり、中には参考になるのも幾つかあります。情報を視覚的に見せるという意味ではタグ専用のページを設けて Tag Cloud にするのは有効な手段だと思います。しかし、これをサイドバーに掲載したとしても読み難いですし、多くなって来たときの問題解決にはならないでしょう。 そもそも Tag Cloud のようにしてすべて（もしくはほとんどの）タグをすべてのページに掲載したほうが良いのかという疑問が残ります。
IA

カテゴリとタグを上手に使い分ける

CMS にタグというコンセプトが組み込まれる以前は「カテゴリー」はどういった情報がコンテンツに含まれているのかを示すものでした。例えば、Mac、映画、ライフハック、仕事といった具合だと思います。しかし、タグ機能が CMS に導入されるようになると、以前カテゴリ名として扱っていた名称 (キーワード) がタグへ移行していきました。 ここで課題になってくるのが、タグがコンテンツに含まれている情報を示すようになったので、カテゴリに明確に違う役割を示さなくてはならないところです。もし従来のように「Mac」というカテゴリを作ってしまうと、Macに関する情報が書かれたエントリーに Mac というタグを書き込むことは重複になりますし、管理する側もこれはカテゴリなのかタグなのかというのが分かり難くなり、記事によって異なる示し方になりかねません。 ブログエントリーとひとことで言ってもエントリーによって様々なタイプ (形式) があります。徒然と文章が書かれていることもあれば、リストだけで終わっているものもあります。どういったブログエントリーを書くかによって、文章の構成は変わりますし、場合によっては文体も変わるでしょう。そこでカテゴリをエントリーのタイプと見なして考えてみました。 このサイトではブログエントリーを７つのタイプに分けています。 Article (記事) たぶんうちのサイトでは、これがメインコンテンツになっていると思います。以前から心がけていますが時間が経過しても、さほど色あせしないエントリーを書いているのが記事にあたります
openwebdesign

サイトの方向性を考える (後編)

この記事は「サイトの方向性を考える (前編)」の続きにあたります。 これからのWebサイトを構築するときにおいて、サイト訪問者の「インタラクション」「体験」「関係」を無視して作ることが出来なくなってきています。サイトの目的や性質を考えてデザインするのではなく、サイトの目的や性質を反映する「インタラクション」「体験」「関係」を考えてデザインするだけでも完成したものは従来と違ったものになるでしょう。しかし、これら3要素を考えて構築作業を開始すればいいといえば、そうでもありません。 例えば、３要素を補う技術というものは既にたくさん出回っており、Web 2.0 と呼ばれるサービスがそのひとつといえます。サービスが提供するウィジェットや API を利用して３要素にあたる部分を補うことは出来ますが、ただ導入しただけではバランスの悪いものであったりしまし、それぞれの要素に負の影響を及ぼすことも考えられます。そこでコアとなるこれら３要素を繋ぎ合わせる重要な『部品』が必要になってきます。 視覚要素と感覚によって作り出す世界観 視覚要素から言語が生まれる 「インタラクション」「体験」「関係」の3要素を繋ぎ合わせるのは、視覚要素の役割といえるかもしれません。つまりビジュアルのことですね。統一した視覚要素があることで、
openwebdesign

サイトの方向性を考える (前編)

masayaさんのコメントでもそれをやるにしても最初にある程度方向性は示さないと難しいのでは？ これは正に仰るとおり！ コンセプトも何もない状態でいきなり「サイト作ります」では、表面的でつまらないサイトになるでしょうし、宣言する意味もないですね。何か方向性があることで、それを起点にしてあなたとの会話もしやすくなると思います。誰でも分かる明確な形として説明出来るかどうか分かりませんが、頭の中で描いているイメージを書いていきたいと思います。 これからの Webサイトにおける基本３要素 サイトを構築するにおいて、従来のように『ページ』や『サイト』という単位での考え方から脱するのがスタートになります。Webアプリケーションを構築する方にとっては当たり前の考え方だといえますが、これは中小企業のサイトを作る際にもいえることですし、今回フォーカスになるブログについても同じことです。もちろんページを実際作り上げて行く作業段階では『ページ』をこしらえていくわけですが、その前段階でそういった単位は不必要ですし、かえって広がりのないサイトになってしまいます。 それではどのような要素を考えて行けば良いのでしょうか。そして、今回のようなブログ的サイトを作っていく際に何が課題になってくるでしょうか。 インタラクション 利用者にとって分かりやすい表現でアクションを助長したりフィードバックを提供するのがインタラクションの役目です。技術的に言えば Ajax のようなページという概念に捕われずにデータのやりとりが出来る環境を作り出すことでしょう。それでは、このサイトでそのようなインタラクションが必要な場所は何処でしょうか。何を改善するとより分かりやすくなるでしょうか。 体験 「Content is King」なんて言葉があるように
openwebdesign

このプロセスで何をオープンにしていくか

この記事は「オープン Web デザインを始めます」の続きにあたります。 コメント、Twitter、ソーシャルブックマークなどを通して幾つかメッセージをいただきました。どういうものを目指しているのかを以前の記事で説明されていない部分があったと思いますので、コメントに応えながら説明していきたいと思います。 これはオープンソースということ？ 「オープン Web デザイン」というフレーズを聞いて、オープンソースを連想された方は少なくないと思います。そう考えるとソースを公開してみんなで作るという感じになりそうな予感がしますね。 DocSeriさんのコメントWikiのような、何らかの無認証編集可能なシステムを利用して自由にCSSを編集してもらって切り替え表示させるというのはどうか。 こうしたオープンソース的なマークアップは結構おもしろそうです。Wikiではないもので、こういったことが可能なシステムってあるのでしょうか？WordPress でも権限を工夫すればいけるかもしれませんが・・・。実際、僕より CSS や HTML に長けている方は山ほどいますし、そういった方がマークアップしたほうがサイトの質も上がりそうです。これはこれで考えておきたいトピックです。 僕が考える「オープン Web デザイン」というのは、どうつくるかではなく、どう使われるかを考えることをオープンな形でやってみたらどうなるだろうという模索です。デザイナーによる提案や、Webや書籍に掲載されているセオリーやメソッドでは実現出来ないものは多いです。そこで少人数で考えるよりこのサイトにアクセスしている様々な分野の専門家に問いかけたほうがリアルで直接的なものになるような気がします。 ここでいう『専門家』
openwebdesign

オープン Web デザインを始めます

去年の暮れから今年の始めにかけて Web デザインへの思いを書いてきました。その思いは「Web という媒体を理解した上でのデザイン」「Web デザインへの理解を深める」の２つの記事に集約されているかもしれません。これからも Web デザインへの興味は薄れることもないでしょうし、これからも続きになるような内容を書いていこうと思いますが、ここでひとつ問題があります。 掲載しているサイトのデザインがコンテンツに耐えられなくなって来ているという問題です。 コンテンツを反映しているサイトへ 長い間、このサイトを読んで下さっている方はご存じだと思いますが、以前のデザインは 3年半前に作ったものです。当時はそれで良かったかもしれませんし、そのときにはあまり見かけなかった情報の配置や見せ方をしていたと思います。しかし、今となっては使い古されたものですし、機能面や使いやすさは貧弱としか言いようがなかったといえます。 5年前に自前でブログシステムを構築し、徐々にコードを調整したり機能を追加してきました（実は非公開でタグもサポートしていました）。デザインを一新したいという思いは常にありました。学生のときは年に３回リニューアルしていたくらいなので、リニューアル癖というのは身体に残っていたものの、システムを構築しつつデザインを考えるのは少々大変な作業だったといえます。特に情報をいちはやく発信しつつ、環境を保持しながら機能を加えて行くのはひとりの人間では難しいですね（仕事もありますし）。本当はシステムも構築したいですが、それを作りあげるために後押しになり、コンテンツを台無しにするのはもったいないと感じました。 そこで、システム部分はすでにある優秀なものを利用し、デザインに集中しようと決心しました。それが今回の