コラム No. 14

Ridual的Webサイト哲学論？

Webサイトを視覚化して扱おうと考える。構成要素を何らかのメタファに分類する必要がでる。Ridualでは、サイトに最低限必要な５つの基本要素を考えた。ゾーン、ページ、リンク、URL、コメント。それぞれを「Unit（ユニット）」と呼ぶ。それぞれのユニットに「プロパティ」が存在する。

例えば、ページユニットには、タイトルや拡張子といったプロパティがある。サイト開発者はページを画面上に配置し、プロパティの項目に情報を埋め込んでいく。ページはコンテンツの塊だと考え、そのコンテンツの見栄えをどうするかは、ここでは扱わない。サイト訪問者が、どのようにコンテンツ群を辿っていくかを考えて、２つのページユニットをリンクユニットで結ぶ。基本的な操作はこれだけ。先ずは情報の流れ（デザイン）ありき。それから詳細デザインを、というコンセプト。

では、「ページ」とは何か。サイト訪問者が目にする画面であり、サイト開発者が何らかの形で作らなければならないモノ。だから最終的に動的生成されるのもので、おそらくは紙芝居的なものは作るだろうから、概念的には対応する。勿論動的生成ロジックに組み込まれた時点で、それはゴミとなるが。ページは更に三種類に分類する。スタティック（静的）、ダイナミック（動的）、サーバ（ロジック/判断）。

リンクも二種類。仮想リンクと実リンク。仮想リンクは、プロデューサの頭の中にある「導線」。訪問者にどう辿ってほしいかの道筋。実リンクは実ファイルに記述されているハイパーリンク線。前者は画面上で描けるが、後者は後で出るアナライザしか描けない。

メンテナンスを考えると、類似のコンテンツは同じフォルダ（ディレクトリ）に入れておく方が良い。だから、ゾーンユニットが必要になる。画面上では単なるグルーピングのためのツール。但し、生成するとそれはフォルダとして扱われる。

予めゾーンを配置してから、その中にページを配置していっても良い。最初にページをコンテンツとして並べて作って、それを後から作ったゾーンに入れて行っても良い。画面上のユニットの移動に際しての注意点は、ユニットの左上の点が何処にあるかが位置情報の基点になっていること。左上端をゾーン内に入れれば、そのページはゾーン内に吸い込まれる。

サイトを開発する上で、そのドメインを外れて存在する登場人物も居る。外部リンク。それをURLユニットとした。開発担当の範囲外のモノ。だから、検索サイトへのリンクも、開発上の都合でドメインを分けてあるサイトも、iMode用の電話番号も、URLユニット扱い。

あとはそれらの登場人物への注釈、コメントユニット。パネル単位、マップ単位で独立に書けるようにした。どのパネルの情報を誰に見せるか考えてハンドルする。或いは、最終的にはSVG出力して、Illustratorで編集するだろうから、そこでサジ加減する。

Ridualを使う場面は二方向から始まる。上流設計と解析の場面。前者では基本的に頭の中のイメージがそのままRidualの画面であって欲しい。今まで何人かのRidualユーザにお会いしたが、我々開発者の想像を越える使い込みを行ってくれていて、少し驚かされた。後者では、そのためのツールを三種用意した。ダウンローダ、インポータ、アナライザ。ダウンローダは指定したURLのページをリンクを見ながらページを取って来てくれる。インポータは、ダウンロード或いは自分で配置したファイルのファイル配置構造を調べてくれるもの。アナライザはインポータが内部的に作成したファイルリストにそって中のHTMLタグを解析する。競合サイト分析にも使えるし、教材配布にも使える。

但し万能ではない。現在Ridualが、認識するのは、以下の拡張子のファイル：

• スタティック(静的)ページ：htm html xml xhtml shtml
• ダイナミック(動的)ページ：asp php cfm jsp cgi
• リソース：gif jpg jpeg swf png css svg pdf class js doc xls zip txt

これを原則として、更にリンクの張り方を考慮して自動的に（XML）情報としてまとめる。

ここまでが前置き。では問題。 swf はページか？　PDFはリソースか？　SSI（Server Side Include）で組み合わせるHTMLはページか？リソースか？　XMLとXSLでクライアント生成したHTMLはページか？そのリンクはどうする？

今まで考えたことのない問題が降って来た。そんなことはお構いなしに、最終的にサイト訪問者に届くページを考えていた。けれど、自動で判定をするためには、何らかのルールが必要だ。存在するページに何らかのルールを無理やり押し付けることに疑問も感じるが、１つのルールで開発が楽になるなら嬉しいはずだ。Ridual開発陣は、機能だけではなく、そんな議論を続けている。これはページか!?、と。

結論としては、カスタマイズを用意した。後日公開するが、上記の拡張子の設定はあるファイルに記述してある(探せば分かると思います)。それを変更すれば、何をページとするかが変更できる。勿論自己リスクで。

解析機能で一番の悩みは、swfファイル。MX以前のものには辛うじて三種類のリンクの張り方に対応したが、MXではまだ解析ができない。悔しい。

上流サポート機能での悩みは、表現力の足りなさ。パフォーマンスを考えて、できる限り少ない登場人物でサイトを描けるように考えたが、考えが浅かったようだ。もう少し表現力があれば、より多くの情報記述が可能になりそうに思ってきた。悔しい。

先日訪ねて来てくれたRidualユーザ曰く、「このツールで4割作業が楽になった。しかし、このツールで工夫するのに2割今までにない作業が加わった。だから、トータル2割減」。しかし要点は「2割では不満」という点だ。まだまだ改良の余地があるはずだ、と。現時点で2割の作業減になるのであれば、余程相性が良かったレアケースと思うべきだろう。それでも嬉しい。Photoshopが写真を暗室からディジタルに引きずり出したように、Webサイト開発を頭の中からディジタルに引きずり出したい。そんな野望も実は持っている。

開発すること自体が目的化しないようにしながら、今の悔しさも忘れないように、もう暫く走ります。リクエスト、ご意見募集中。

以上。/mitsui