SSブログ
オンライン・サイト編集 ブログトップ
前の10件 | -

メニューページ自動生成は中止 [オンライン・サイト編集]

突然だが、トップページを自動的に作るのはよくないと思うようになった。

 トップページ、あるいはそれに続くメニューページは、そのサイトの「顔」のようなものだ。これを、機械的に生成するようなページにすべきではない。来てくれた人に一番最初に見せるものだから、そこで、来た人を惹きつけるような工夫をした方がよく、そのためには、作る側が十分にデザインなどを練って作る必要があることに気付いた。

 ただ、メニューシステムのために考えたことは、サイトマップに活かせるだろう。サイトマップは、最初に見るものではなく、いわば、そのサイトをじっくり見ようとしたときに、「後から」見るものだ。デザインよりも機能性が大事だし、それならば、機械的に作ることができる。しかも、そのためには、別にXMLで手書きの情報を蓄えておく必要もない。

 サイト編集のツールの中心ページは、そのサイトのファイル一覧を表示するページで、そこでサイト全体のファイル・ディレクトリ構成が一覧できるようになっている。それと同様のものを、ユーザー向けのお化粧をして作ればよい。

 更新するたびに作る必要はあるが、それに多少の時間がかかってもいいので、ページのタイトル、URL、ディレクトリ構成などを収集してくればいい。いや、ちょっと待てよ。ページについてはタイトルは取り出せるが、ディレクトリについては、ディレクトリ名以外には情報はないぞ。ということは、ディレクトリ名とそれを表示するための「タイトル」の対応関係をどこかに書いておく必要がある。それは、新規ディレクトリを作る際に、どこかに書いておくようにすることにしよう。作成者が見るファイル一覧のページにその情報をしまっておくことにしよう。サイトマップもそのページから作るようにしよう。

 あとは、更新履歴も自動化できる。これは新規にページを作るたび、あるいは更新するたびに、その情報を一つのページに追加していく。手動でいいが、ある一定の期間や量になったら、古い更新記録のページにして、新たに更新履歴のページを作り直せるようにもする。

 今回は直前まで言っていたことを、180度方針変更してしまった。といっても、何かを作ってしまってから方針変更するよりはずっとましだったと言い訳することにしよう。


WebサイトのメニューのためのXML [オンライン・サイト編集]

サイトのメニュー作成をどう自動化するかを考える。

 結局、タイトルとファイル名の対応は、その順序も含めてXMLで手書きで編集することにする。XML自体は、考え方はRSSに似ているが、必要最小限の情報に限り、書きやすく、処理しやすいものにしなければならない。

 前回は、ディレクトリ毎に別々のメニューページを作るとしたが、これは作る人の自由に任せた方がいいだろう。ページ数が少ないときには、複数のディレクトリがあっても、単一のメニューの方がいい。形式をうまく考えれば、単一ページでも複数ページでも処理できるようにすることができるだうと思う(まだ、具体的には考えていないが。)。

 とりあえず、単一メニューページで書くとして、XMLで書いた例を考えてみよう。XMLを設計するためには、具体的な例をいくつか書いて、そこから要素などを取り出すことでDTDを考えるのがよい。

<?xml version="1.0" encoding="euc-jp" ?>

 オンライン・サイト編集
 福田洋一
 
    オンラインでWebサイトを作成するための、シンプルで使いやすいツールを開発しています。
 
 
   
     目的
   
   
     計画
       
          使用する環境
       
       
          作成ツール
       
   
   
     経過
   


一目瞭然だろう。ただし、特にsub-menu要素の辺り、またファイル名やディレクトリ名の書き方など、やや試行錯誤したし、これで確定とは言えないかも知れない。

 また、まだ足りない要素があるかもしれない。とりあえず、こういう書き方で、実際のサイトのメニューをいくつか書いてみよう。


サイトのメニューページを自動的に作る [オンライン・サイト編集]

 これはやっかいな仕事だ。いろいろ考えてみているのだが、どうもうまくいかない。各ページを作るのはいいとして、その都度、トップページのメニューに追加していくのは大変な面倒な作業である。それをできるだけ自動化できるといい、というのが、このオンライン・サイト編集システムの目的の一つだった。

 しかし、どこまで自動化し、どこまで手動でやるのか、その境目が決まらない。全自動にすれば、もちろん人間は楽だが、メニューとしての細かい制御ができない。それを個々のファイルのどこかに、たとえば特定のタグをつけたコメントととして記入しておくとするというの一つの解決策だが、そういう小手先のつじつま合わせをすると、段々、身動きがとれなくなっていくことが多い。

 一方、ほとんどを自分で編集し、どうしても面倒な部分のみをツールに任せる、というのも一つの手だ。今はどちらかというとこの方向に傾いている。いつも手動でメニューを更新するのが面倒だと思っているが、いざ、ツールのプログラムを考えようとすると、それはそれで面倒なので、日頃の面倒の方に逃げてしまいたくなる、ということなのかもしれない。

 取り敢えず、できるだけ人間が書いておき、頭を使わない部分だけプログラムに任せる、としたら、どうなるだろうか。

 まず、サイト全体のメニューを一ページにおしこむか、トップページは表紙と各章へのメニューだけにし、各章ごとのメニューページを別に作るか、という選択肢がある。おそらく、後者の方がサイトはきれいになるだろう。また、この場合、トップページには、最新の更新履歴をたとえば5件ほど載せる。ついでに、全サイトについての更新履歴も自動的に作ることにしよう。トップページの更新情報も含め、この更新履歴のページについては、後日考えることにする。

 さて、そのトップページからリンクされる各章のメニューからリンクされる各章の実際のページの方は、一つのディレクトリの中に収めることにする。その関連づけは、そのメニューページ、たとえば、books.htmlと、ディレクトリはbooksというディレクトリにする、というように、拡張子を除いた名前を一緒にしておく。

 メニューページの内容は、HTMLで用意するのではなく、XMLで用意しておく。そうすることで、HTMLにするときの煩雑な書式を書かずに、できるだけシンプルにデータを記述しておけばいいようにしておく。そうすることで、せめてもの面倒の多少の解消をする。

 たとえば、メニューからのリンクは、aタグでメニュー項目を囲むことになるが、XMLではそれは単にファイル名と内容ページのタイトル要素とを書いておくだけにする。アップデートした項目には、update属性をつける。新規項目にはnew属性をつける。各ファイルの最終更新日付は、ファイルの更新日付とし、これは後からプログラムが書き込むことにする。つまりデータには含まれるが人間は触らなくていい。

 各メニュー項目にはdescription要素を含みうるが、これは、各内容ページのmeta要素でname属性がdescriptionのcontent属性を、ツールが自動的に収集して記入する。人間は触らなくていい。

 そのディレクトリの下に更にサブディレクトリを作ることもありうる。しかし、それらについてのメニューも、このトップディレクトリに置かれるメニューページに記述するものとする。

 要するに、このメニューページのXMLでは、メニュー項目の順序を決定して、その順序どおりに、タイトル要素とファイル名の対応だけを書いていけばよい。あとはプログラムがメニューページを生成するときに、実際のファイルのを走査して、必要な情報を調査し、さらにHTMLとして書き出すようにする。

 書くのは簡単だが、プログラムするのはそうとう難しい作業かもしれない。少しずつ簡単なコアから作っていかなければならないだろう。

  メニューページの情報を記述するXMLの設計については、明日書くことにする。


Webコンテンツのためのテンプレート [オンライン・サイト編集]

 「Webページのテンプレート」で、僕が考えるWeb編集支援のテンプレートについて説明したが、別の観点からもう少し説明しておこう。

 その記事で言及した情報箱さんからご紹介いただいたページでは、たとえば、メニューの自動生成といっても、メニューの項目を自動的に作ってくれるのではなく、項目をこちらから指定すると、グラフィカルなメニューを作ってくれる、というものらしい。つまり、デザインテンプレートというようなものだ。

 それはそれで便利かもしれないが、最近、脚光を浴びるようになっているのは、「コンテンツ・マネージメント・システム(CMS)」である。つまり、巨大なWebサイトを出来る限り効率的に管理するためのシステムが必要だということだ。これはは「コンテンツ」、つまり、Webの内容を管理するためのシステムである。ページ数が増えていくと、それらの間の統一性や一貫性、構造化などが急務になってくる。デザインももちろん、その内容の統一性に寄与するものとして考えられる。

 そういうCMSについても、ZopeやXoops、Smartyなどの大がかりなシステムも存在する。これらはあらゆる要求に応えられるような、柔軟性のあるシステムだが、そのために逆にユーザーは、HTMLやCSSとは別に、別のプログラミング言語を覚えるのと同じくらいの勉強が必要になる。それはそれで極めて負担になる。

 そうではなく、HTML、CSSの知識を前提にして、コンテンツ管理の面倒な作業を肩代わりしてくれるようなツールがあれば便利だと思うのだ。決してHTMLやCSSの知識を、別の言語で置き換えるのではなく、単に面倒を組織的に軽減してくれ、さらにはWebサイトを作成する手順も示してくれるような、そういうツールである。

 したがって、このツールはまず、内容の管理が第一であり、それに付随してデザインの統一性を提供できるようにしたい。しかも、デザインもユーザーが作ったものをテンプレートととして使えるようなものであって、システムの方がデザインを用意するのではない。内容もデザインもユーザーが用意する。それを管理するためのツールである。


Webページのテンプレート [オンライン・サイト編集]

 「オンライン・サイト編集におけるテンプレート」に情報箱さんからトラックバックをいただき、いろいろなWebページ作成のためのテンプレートのサイトを教えて頂きました。

 いろいろいとページをショーアップするグラフィカルなツールが揃っていますので、関心のある人は行ってみてください。

ただ、同じテンプレートという言葉を使っていますが、僕が考えているテンプレートとは、少しコンセプトが違うようです。僕がここでテンプレートと言っているのは、一つのサイトを統一的に作っていくためのテンプレートを自分で作れるようにすることです。自分で作れると言っても、一から作っていては大変ですので、その辺りをサポートするようなツールを開発できればと思いますが、どこまで支援し、どこから作成者に任せるか、という線引きがむずかしいところです。

 前にも言及したかもしれませんが、PHPで書かれたテンプレートSmartyというのもあります。非常に高機能ですが、その分、覚えたり使ったりするのが難しくなっています。コンセプトは似ているので、その機能を研究してみる必要はありますが、もっと簡単に、自由に作れる、つまり、作る人のレヴェルに合わせてカスタマイズできるものであってほしいと思います。

 ある意味ではブログやWikiもテンプレートです。これは使いやすくなっていますが、自由度は極めて低い。まあ、ブログサイトにはCSSを使ってデザインを変更できるものもありますが、それはあくまで見栄えの調整で、構造的には効き目はありません。

 特にHTMLやCSSはWebサイトを作るときの基本的な知識なので、これを知っている人が、それをフルに使えて、かつ面倒な作業、定型的な作業は、テンプレートとしてまとめていける、それを支援するようなツール、というのが僕の考えているテンプレートのコンセプトでした。


使い回せるCSSを作れたら [オンライン・サイト編集]

 これまで、CSSを使うべきだと力説してきたが、実際にきちんとCSSを使ったページを作ったことはこれまでなかった。出来る限りCSSを使うようには心がけているが、その時々の必要に応じてページを作っていると、大抵時間がなくて、いそいでその場しのぎの対処ですませてきた。ないしは、極めて単純なデザインですませてきた。

 事実、Wikiはほとんどデザインを変更する余地はなく、このブログもたまに、インラインのstyle属性を使って装飾をするくらいだ。後は自分のホームページだが、これがメニューを除く大部分は、もともと配布プリント用にTeXで書き、それをPDFにも変換し、またtex2pageという変換ツールでHTMLにも変換して作っているので、そもそもHTMLをきちんと書いてはいないのである。

 TeXからHTMLに変換したものは、メニューへのリンクを付け足す以外には何も変更を加えていないので、そこで使われるhタグやpreタグ、箇条書き、背景色などを一つにスタイルシートにまとめておき、それを全部に共通に読み込ませている。全部に共通だから、ある意味ではサイト全体の統一感はあるが、そのデザインそのものは、ほとんど試行錯誤もせずに、場当たり的に作ったままで、何の変更も加えていない。

 で、実際に、CSSでレイアウトやデザインの微調整をしながらページを作ったが、これが結構時間のかかる作業だった。一つ一つのタグを一からデザインしていくのが大変だった。これを何とか解消できないだろうか。

 CSSには、何段階かのレヴェルがある。

  1. まず、必ず何らかの編集をした方がいいもの。使うとすれば必ず手を入れる必要のあるもの。定型的なものとしては、文書のタイトルや著者、更新日付、クレジット、メニューへのリンクなどである。また、テキストの行間も150%〜160%位には設定しておきたい。これらについては、よく考えたスタイルを予め定義しておく。いくつかのパターンがあってもいいが、それほど多様性はないかもしれない。もちろん、使う人がデフォルト以外のデザインにしたいのなら、それはそれでいい。
  2. 変更する可能性は高いが、どのように変えるかは、作る人のデザインのコンセプトによるもの。一番は背景色や基本的な文字の色、テーブルのデザインなどである。これらは、いくつかのひな形を用意しておいて、選択できるようにするとよい。どういうデザインを用意するかは、各種のサイトを見て、そこから一般的なパターンをいくつか選定すればいいだろう。
  3. クラスを作る必要がある場合。それぞれ意味によってクラスを作る必要があるので、最初から用意しておくのは難しい。クラスの作成は、そのページの内容に大きく依存しているからである。ただ、たとえばemタグのように「強調」という意味が決まっている場合には、最初から用意しておくのもいいだろう。

このように、いろいろなレヴェルがあるので、それを一つのファイルで提供するのは難しい。そこで、部品に分けておき、必要に応じて選択して読み込むようにしたらいいのではないかと思う。ただし、種類が多すぎると、探したり覚えたりするのが大変になり、結局は使わないことになってしまう。この辺りは、適当なバランスを考えないといけない。試行錯誤が必要となるだろう。

また、ひな形をもとにある程度サイト全体の統一的なCSSが出来てきたら、それを一つのファイルに統合してもよい。オリジナルのひな形そのものは編集させないようにして、それのコピーに手を加えていくようにしよう。試行錯誤しているうちに、結局もとのものがいいということになるのは、よくあることだ。

 どうも抽象的な話になってしまった。実際にどのようなCSSのひな形を用意しておくのがいいか、それをどのように分割し、またどのように利用させるようにしたらいいのか、これらはそう簡単に答えが出ることではない。ただ、必要だ、ということに気付いたことだけを書き留めておく。


ローカルでの編集とリモートでの編集 [オンライン・サイト編集]

 最近、Webページを更新するとき、直接エディタでサーバー上のファイルを読み込み、編集後、保存すると、サーバーに保存される、というやり方でページを更新することがある。これは、非常に便利だ。

 これまで、オンライン・サイト編集の利点を、直接サーバー上でファイルを作成し、また更新でき、ファイル管理をサーバー上で一元的に出来ることと考えてきたが、エディタでサーバー上のファイルを編集できる、というのは、サーバー上でのファイル管理システムの一部として使えそうな気がしてきた。

 といっても、もちろん問題はそんなに簡単ではない。オンラインで編集できるとすれば、どこからでも、Webにアクセスできさえすれば、サイト編集ができるという利点がある。エディタは、特にサーバー上のファイルを直接編集できるエディタがいつも手元にあるとは限らない。またそれができる環境も、何らかの設定が必要となる。たとえば、サーバーにアクセスするためのFTPの設定をしておく必要がある。しかし、それは自分のコンピュータ以外では難しい。

 一方、このブログにせよ、Wikiにせよ、オンラインで、つまりHTMLのformタグ内のテキスト・エリアで編集をしていると、まず、編集機能が制限されている。無限Undoなどは期待できない。文字のサイズや行間なども固定されている。色もつかない。検索・置換ができない、など。

 そして最大の問題点は、ときどき以上終了したり、アップロードしたときにサーバーの負荷が大きいためか、エラーになって、書いたものが消えてしまったりする、という不安定さである。これは多くの人が経験していることだろう。

 ローカルでエディタで編集していれば、サーバーの不具合でアップロードがうまく行かなくても、データは残っている。ネットワーク越しに安定した編集をするのは、実はとても難しいのだ。

 ではどうしたらいいのだろうか。現在、いい解決策を思いついているわけではない。両方の利点と欠点のバランスをもう少し考えてみる必要がある。今、言えることは、両方に対応できるように作っておくことだと思う。そのとき、どれだけの機能が必要とされるかだけを箇条書きにしておこう。

  1. ローカルで編集する場合には、更新したファイルのみをアップロードできるような機能が必要。
  2. オンラインでサーバー上のファイルを編集する場合でも、ファイル編集自体は、ローカルのエディタを使って行い、そこからアップロードするか、あるいはフォームのテキストエリアにコピーするようにする。これを何らかの仕方で自動化できるといい。
  3. サーバー上でのみファイル管理を行う場合には、更新するたびにサーバー上で、あるいはローカルへとバックアップがとれるようにしておく。これは全体を一括して圧縮する場合と、更新したファイルのみをダウンロードする場合とがありうる。両方できるといい。
  4. ローカルでのファイル編集と、オンラインでのファイル編集は、どちらか一方に決めたら、そちらでしかできない、というのではなく、家にいるときはエディタを使ってのローカルのファイル編集、出先ではオンラインでの簡単な編集、というように、場合場合に応じて両方のやり方ができるといい。

この最後の機能が最終的には両方の利点と欠点の妥協点かもしれない。


HTMLの一番基本的なテンプレート [オンライン・サイト編集]

HTMLの一番基本的なテンプレートを示しておこう。これをコピーして使い回すこともできる。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>

</body>
</html>

 あと注意すべきことは、

  1. タグや属性は全て小文字にする。
  2. 属性の値はかならず" "で囲む。
  3. タグは、開始タグに対して、必ず対応する</タグ>という終了タグを書く。

 これらはXHTMLでは必須であり、将来XHTMLに移行する準備にもなるので、この書き方に慣れておこう。


CSSのclass属性の作り方 [オンライン・サイト編集]

 前に「XHTMLを構造化する」で書いたように、CSSのclass属性で、XHTMLの構造を定義することができる。

 ということは、class属性を付けるとき、デザインの違いでクラスを作ってはいけない、ということだ。classには、必ずその文書の構造的な意味を表すようなものにすべきだ。

 一つのページなり、Webサイトなりを作るとき、どういうページにするかを考え、HTMLとは別に、全体のアウトラインをまとめてみる。そのアウトラインを整理・分類し、共通なものをまとめてクラス名をつける。この段階でデザインのことは(あまり)考えない。デザインはあとで、試行錯誤して決めていけばいい。

 こういうように、内容やデザインとは別に、統一的に構造を考えてWebページを作っていく、という手順をできるかぎり守るようにしよう。

 前回はtitleとかauthorとかdateとかのクラスを紹介したが、すぐ考えつくのは、

h2.chapter { }
h2.section { }
h3.subsection { }
h3.subsubsection { }

などの見出しのクラスである。

 他に、プログラムのソースやHTMLを表すクラス

p.code { }
p.html { }

などだ。これと文章の引用は別の方がいい。引用についてはblockquoteがあるので、これはそのまま使うことができる。

 たとえば、本の引用などが多ければ、

span.book { }

というクラスを作り、<span class="book">〜</span>というように使う。さらにそのbookクラスの中で、タイトルなどを区別したいとすれば、

span.book span.title { }

とすればいい。そして、

<span class="book">
  <span class="title">CSSのclass属性の作り方</span>
  <span class="author">福田洋一</span>
</span>

というように使う。

 このtitleクラスは、h1.titleのh1におけるtitleクラスとは別のものになる。XMLにおける子要素と同じように(若干分かりづらいが)使える。


XHTMLを構造化する [オンライン・サイト編集]

 XHTMLはXMLの一種なので(と、突然の話では難しいか。まあ、XMLは余り気にしないでいい。)文書の論理的な構造とデザインが分離されている、ことになっている。

 が、しかし、もともとのHTMLが、その辺りまぜこぜで、というよりは、デザイン用のタグの方が大部分なので、それをXMLの規格に適合するようにお化粧したとしても(XHTMLのXの部分が、そのお化粧の程度を物語っている。)、やはり、文章の構造的な意味を表すようなタグが新たに導入されたわけではないので、それほど代わり映えはしない。

 一応、デザインはCSSに分離して記述することになっているが、実はこのCSSを利用する方法が、期せずして、構造を表すタグを作る手段になるのである。もちろん、XHTMLではタグを新設することはできないので、擬似的なタグということになるが。

 どうするのかというと、class属性を、擬似的な構造用タグに使うのである。XHTML (HTMLでも可) のタグにはclassという属性を使えるが、その属性値の定義はCSSの中ですることになっている。そのclass属性に構造的な意味を持つ値を作っていけばいい。

 たとえば、一つの文書ならば、タイトルや作成者名、作成日などを記述する必要がある。これらは「タイトル」や「作成者」や「作成日」などという、文書に必要な構造的意味をもっている。しかし、(X)HTMLでは、これらの構造的意味を示すタグは存在しない。そこで、

<h1 class="title">XHTMLを構造化する</h1>

<h1 class="author">福田洋一</h1>

<h1 class="publish_date">2005/3/20</h1>

というように記述する。デザインについては、ここでは何も決めない、あるいは決める必要がないのは、XMLと同じことである。デザインは別にCSSの中で、

h1.title { font-size: 16px; text-align: center; }

などというように指定する。ここで、同じh1タグが、class属性の値によって、三つの異なった構造的意味を表すものとして区別されていることに注意。CSSを指定しなければ、このclass属性は無視され、何事もなかったように、普通のh1として扱われる。

 このようにして、class属性を使って、文書全体の構造を設計し、それとCSSを組み合わせることで、構造的な意味ごとにデザインを指定し分けることができるようになるのである。


前の10件 | - オンライン・サイト編集 ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。