サイトデザインでもんもんと悩んでいたら、古くからの友人にいいことを教えてもらいました。(uenomanabu さんのコメント... のところ。)それは、悩んでいる内容よりも、そもそもその悩み方自体に問題がある、というようなお話でした。
そういえば、人生の問題は解決できない、いつの間にか、もはや問題にならなくなるだけだ。みたいなことを誰かいってなかったっけ？
それはともかく、友人の教えを自分なりに理解してまとめてみたところ、ちょっと大げさかも知れませんが、Webサイトをシンプルかつ柔軟に構築、運用するための設計原則、みたいなかんじになりました。
こんなかんじです。
1. Webサイトを、リソース検索エンジンとリソースサーバーがセットになったWebアプリケーションだと考える。
2. 全文検索だけでなく、サイトに固有なリソースのメタ情報の形式と内容に密結合したリソース検索エンジンを用意する。
3. サイトに必要とされるさまざまな形態での出力をサポートし、データ形式、テンプレートの適用、ページングなどについてのオプションを提供するリソースサーバーを用意する。
4. ページとは、リクエストに応じてリソースサーバーが出力したリソースのビューであり、リソースそのものではない。サイトマスターが作成し、管理するのはページではなくリソースであると考える。
5. リソースのURIは表示形態やサイトのナビゲーション構造上の位置を表現しない。リソース自体の内容、形式、属性を表現する。
6. サイトのナビゲーションは、検索結果とリソースの表示という二階層、二状態間の遷移の組み合わとしてデザインする。
7. 従来トップページ、メニューページ、インデックスページと呼ばれてきたページが果たしてきた役割のほとんどは、リソース検索エンジンの検索結果に取って代わられる。検索結果とは別に、サイトやセクションの概要をていねいにガイドしたい場合は、そうした情報をサイトのリソースの一種として用意する。
今、ぼくがふつうにやっているサイトデザインは、ディレクトリ構造を持つファイルシステムにHTTPでアクセスするという古典的なWebアーキテクチャに基づいているんだと思います。
サイトの論理的な構成を、そのままファイルシステム上のディレクトリとして表現することが多いし、サイトデザインの要として意識するサイトの、あるいはセクションのトップページというのは、ディレクトリアクセス＝ファイル一覧表示をユーザーフレンドリーに整えたものだと考えていました。
否も応もなく、ただ、これしかないということでやってきたけれど、経験上、このやり方には少なくとも二つの欠点があったと思うんですよね。
第一に、変化に弱い。
少し大きめの企業サイトを長期にわたって運用していると、サイトの構成を見直して大改訂なんて話が何年かおきに持ち上がります。見た目のリニューアルだけならともかく、セクションの区分や階層構造を変えるということにでもなれば、なんだかえらい騒ぎになる。
あちこちのURLを書き換え、外部からのリンク切れを防ぐために膨大なリダイレクトを設定し、リンクチェックを繰り返しながら、一体誰がこんなことやろうって言い出したんだと上流のえらい誰かを呪いはじめたりして。
要するに、サイトの論理構成がそのままディレクトリになっているので、いろいろな切り口やグルーピングでサイト内の様々なリソースを見せていくとか、必要に応じて臨機応変に再編成を行うといったことができないわけです。どこの誰に対しても、あるひとつの決まったディレクトリ構造による整理の下でしか、リソースを差し出すしかない。
第二に、サイトデザインがいびつになりやすい、かもしれない。
半ば無意識のうちにディレクトリ構造上の一貫性や整合性を追求してしまうので、ユーザーには迷惑でしかない深い階層を作ってしまったり、たいして意味のないメニューページを乱立させてしまったりしがちです。
それに、ユーザーにとってサイトの価値が生じるのはリソースとの接触においてなんだから、本来、サイトデザインはリソースの表示を最高の品質にもっていくことこそに注力するべきでしょう？
それなのに、ディレクトリをたどることのそもそもの難しさに気をとられて、ついナビゲーションデザインにばかり力が入ってしまう。まるでユーザーに素敵なナビゲーションをお楽しみいただくのがサイトの唯一の価値ででもあるかのように。
どっちの話も、上で古典的と呼んだWebアーキテクチャに支配されているうちは、むしろ、それで当たり前、ということだったのかも知れません。
でも、いまやWebアーキテクチャは質的に変化したわけで。ストレージ層はファイルシステム中心からデーターベース中心になり、データーの送受信にアプリケーションが介在するようになった。もう、サイトデザインを古典的なWebアーキテクチャのパラダイムに寄り添わせておく必要はないんですよね。
だから、「Webサイトをシンプルかつ柔軟に構築、運用するための設計原則」に則って仕事をすることは、夢でも、突飛な考えでも、極端な話でもなくて。現にそうなってるWebサイトはたくさんあるし、ブログで作れば自然にそうなる、ともいえるくらいのことなんですから。
(前のエントリーで「フィルターパターン」なんていってたのは、まさにこれのことだし。)
それなのにおれは何やってんだ。ということですよ。
教えてくれた uenomanabu くんにあやかって、この原則を密かにUM法と呼びつつ、ぼくも頭を切り替えてがんばります！
3 件のコメント:
おお、僕が言いたかったこと＋アルファをメソッドとしてまとめていただき、ありがとうございます。
ウェブ CMS が普及して、仕組みとしては半ば普通になりつつあることだとは思いますが、メンタルモデル的にも、いよいよページメタファから脱却していく何かを感じました。
とはいえ、本来ドキュメントをマークアップするための HTML にUI的な要素がごっそり入ってくるのを許容している現状には、まだまだ気持ち悪いところがたくさんあるのですけどね。
結局、サーバーサイドでごにょごにょやって広告風のページを生成するというのは、ユーザーにとっても作り手にとってもメンタル負荷が大きいので、もっとシンプルにすればいいと思うのです。
ところで、
> 検索結果とは別に、サイトやセクションの概要をていねいにガイドしたい場合は、そうした情報をサイトのリソースの一種として用意する。
これですが、具体的にどうやってサイトのリソースとして扱うかなのですが、うちの会社のサイトを作った時に考えたのは、検索クエリーに対してメタ情報を付けるという方法でした。
例えばホームで「UIデザインパターン」を選ぶと、「カテゴリー=UIデザインパターン」というクエリーでコンテンツが検索されるわけですが、結果一覧の上の方には、この検索結果専用のリード文が表示されます。これはカテゴリーごとのテンプレートに書いてあるのではなく、「カテゴリー=UIデザインパターン」という検索クエリーに対してあらかじめ用意してあるメタ情報が出ているのです。そういう仕組みを作ったわけです。だから、色々な検索クエリーに対して異なる情報を自由に挿入できます。（サイト内検索で、うちの会社名を入れると...）
でですね、
これまでのウェブサイトというのは、いわゆるサイトマップのイメージで、トップページを頂点にしたツリー構造のイメージだったと思うのです。だけどコンテンツが構造化されてデータベースに格納され、ナビゲーションが動的に行われるようになると、階層が解体されて、末端のコンテンツ（を構成する最小単位の何か）はすべてフラットに存在するイメージになります。
これを別な見方をすると、これまでは、コンテンツをグルーピングする「カテゴリー」という名の各ノードを中心にして放射上にそこに含まれる末端コンテンツがリンクされていたものが、フラットな世界では、各末端コンテンツがノードとなって、それぞれのファセット属性が放射状にリンクされるというイメージになると思うのです。当然各ファセット属性ノードには、同じ属性を共有する他の末端コンテンツノードがつながります。
ファセット属性は、いってみれば検索クエリーなわけですが、その検索クエリーもひとつのノードとして考えれば、そこにメタ情報を付けるのは自然なことではないかと思います。
Google で適当に検索すると「もしかして：〜」と言われますが、あれも一種のクエリーに対するメタ情報ですよね。あれをもっと拡張できるのではないかと。
よく検索エンジンとかタギングエンジンのチューニングで「制限語彙」を作って似たようなキーワードを名寄せ（？）しますけど、それを単にキーワードに対してやるのではなくて、色々なタイプのクエリーに対してやれるのではないかと思うのです。
>各末端コンテンツがノードとなって、それぞれのファセット属性が放射状にリンクされるというイメージ
>ファセット属性は、いってみれば検索クエリーなわけですが、その検索クエリーもひとつのノードとして考えれば、そこにメタ情報を付けるのは自然なことではないか
いやあ、わかる。わかりますよ。非常によっくわかります！
さすがですね。
そういえば、
> 第一に、変化に弱い。
↑ ここがかっこよかったです。
大リーグボール2号は、水に弱い！
みたいで。
コメントを投稿