魔法使いをこの手に
データは集まった。あとはそれを文書にまとめるだけ――。フォーマットの決まった文書作成なら、ここでもハイパーカードの「魔法使い」がお手伝いする。
- 定型フォーマットの作成を支援する
- ハイパーカードでの段階的業務支援
- HTML再び
- バックグラウンドの設計
- ファイルを選び、基本部分をつくる
- 表題を用意する
- 本文を読み込んで変換する
- リンクを設定する
- ウイザードとアンカーアプリケーション
定型フォーマットの作成を支援する
前回は、多様な文書データの海から必要な情報を拾い出すための検索システムを考えた。これで材料が揃えば、今度はこの素材を加工してアウトプットにつなげる番だ。
オフィスで作る文書の多くは、定型のフォーマットや作成規則を持つ。雛形やデータベースのレイアウトを用意することで、これらの文書の作成はかなり効率化されるだろう。しかし、盛り込むべき内容が複雑になると、単純な雛形では間に合わない。素材に合わせて柔軟に指示を変更し、適切なプロトタイプを作成できるような仕組みが必要になってくる。
ユーザーの指示に従ってデータを加工し、ドキュメントやオブジェクトの作成を支援する仕組みとしては、マイクロソフト社の「ウイザード」が頭に浮かぶ。エクセルやワードでお馴染みになったこの手法は、言ってみればダイアログボックスを複数に分割したものだ。ステップを追って確認しながら進むから、込み入った手順も無理なく実行できるようになっている。
一つのダイアログで全ての情報を処理しようとするとどうしても複雑なものになってしまい、利用者にわかりにくくなることが多い。作業をパートに分割したウイザードでは、各段階でのポイントが明確になっている。画面の設計もすっきりと使いやすくできるし、説明のスペースも十分だ。各パートの役割をはっきり意識することで、業務全体の流れを系統立てて理解するということにもつながるだろう。
ハイパーカードでの段階的業務支援
ひとつの作業工程に1つのダイアログを割り当てるこの仕組みは、まさにハイパーカードにうってつけである。カード1枚でひとつのステップを完結させ、順次カードをめくっていくという業務支援スタックを作れば、高機能なウイザードとして活躍できるに違いない。
ポイントは、業務をいかにうまく複数のカードに割り当てるかという点だ。従って、これはどれだけ的確に業務分析をするかという問題になってくる。支援システムを設計するのに業務分析をするのは当然のことなのだが、自前でシステムを作る場合は、仕事そのものに慣れているだけに、ついこういうステップがおろそかになりがちである。そういう意味では、今回の支援スタックの作成は、業務内容を再吟味する良い機会にもなるのではないだろうか(*注1)。
HTML再び
この原稿でのHTML説明は誤りが含まれています。HTMLそのものの説明は無視して、定型フォーマット変換の例としてお読みください。HTML説明の誤りについては補注を参照してください。
1995/9号では、ハイパーカードを使ったHTML(*注2)エディタを作成したが、その後インターネットはますます盛り上がりを見せ、ドキュメントをHTML化するニーズは一層高まっているように思われる。HTMLエディタはタグ書式などの文法をある程度知っていることを前提にしたものだった。そんな知識がなくてもインターネットに情報を流せるように、ここはひとつHTML作成支援のウイザードに挑戦してみよう。
既存のテキストファイルをHTML化する作業を幾つかのパーツに分解してみるとおよそ次のようになる。
- ベースとなるファイルを決める
- タイトル、ヘッダなど基本フォーマットを決める
- ファイルを読んでHTMLに変換する
- 画像やファイルへのリンクを設定する
- 細かいスタイルの編集を行う
この作業の流れを念頭に置いて、スタックを作成していく(HTMLのためのスクリプトは1995/9号で解説したので、今回はスタックをウイザードに仕立て上げる過程そのものを見ていくことにする)。
バックグラウンドの設計
最初に、ウイザードに共通する要素をバックグラウンドに設定し、全体の構成を固めておこう。
ウイザードで必要となるものは、大まかにいえば、(1)操作の説明部分、(2)カードごとの操作部分、(3)先に進んだり戻ったりする共通のナビゲーション部分、(4)操作結果を表示したり確認したりする部分、ということになる。これらのうち、(1)(3)(4)はバックグラウンドに作って共有するのがよさそうだ。画面1に今回作成したサンプルスタックのバックグラウンドを示した。
(4)の結果表示は、ここではブラウザで表示した場合のイメージをつかむ部分とHTMLそのものを表示する部分の2つからなっている。
(3)のナビゲーションボタンは共通要素だが、最初のカードに「戻る」があったり最後のカードに「次へ」があったりするのはうまくない。こういうところは、バックグラウンドスクリプトのopenCardハンドラを使って不要なものはグレー表示になるよう処理しておく(リスト1)。ウイザードのような支援システムを使いやすくする上では、こうした細かい作り込みが大切になってくるので、十分に考えて基本設計を行いたい。
ファイルを選び、基本部分をつくる
最初のカードでは、HTML化するテキストファイルを選び、HTMLの基本部分を構成するタグを設定する(画面2)。普通のエディタなら、ファイルを選んだ時点でその中身を読み込んで編集用のウインドウにテキストを表示するわけだが、このウイザードではその前に幾つかの前処理を行う。そのため、選択したファイルのパスをいったんフィールドに保存し、実際のテキスト読み込みはあとのカードで行うようにしている。
HTMLは全て<html>,<head>,<body>などの骨格にあたるタグを持つので、最初にこの部分を作成しておく。<title>タグで表されるウインドウタイトルの部分はファイル名と共通することが多いから*補注1、ファイルを選ぶときに合わせて
answer file "HTMLの元となるテキストファイル" ask "TITLEを決めて下さい。" with lastHCItem(":", it)
のようにしてタイトルを決めておくと流れがスムーズだ。
これらの材料が揃ったら、HTMLの骨格はフィールドに書き込み、タイトルもイメージ部分のウインドウタイトルに表示して確認できるようにしよう。
表題を用意する
一般にHTML文書は文章の冒頭に大きな表題を持っている。これは<h1>のようなタグで表現するが、大きさや位置にバリエーションがあるので*補注2、ラジオボタンで好みの表題を選べるようにする(画面3)。
既存の文書をHTML化する場合、もとの文書の1行目が表題に相当する可能性が高い。そこで、表題設定ボタンでは、ファイルの1行目を読み出してデフォルトとし、ユーザーに実際の表題を決めてもらうようにした。
タイトルと同じく、表題もイメージ部分に書き込んで、実際のWWWではどのように見えるかを把握できるようにしておく。このイメージを見て気が変わったら、ラジオボタンを操作することでタグを変更することも可能だ。HTMLを書き換えるとともに、イメージ部分のフィールドの属性を変更することで、表題がどのようになっているのかをすぐに確認できるようにするとよい(リスト2)。ウイザードでは、ユーザーが作業の進み具合を確実につかめるようにしておくことが重要である。
本文を読み込んで変換する
ここまでの準備が整ったらいよいよ本文を読み込んでHTMLに変換する作業に入る(画面4)。基本的には、改行を明示的に行うために<br>タグを各行(段落)の最後に加えればよいのだが*補注3、構造的な文書を読み込むならその構造を生かして小見出しなどを自動的にタグ付けしたい。なにしろ、本来HTMLは文章の論理構造を表現するためのマークアップ言語なのである。小見出しや箇条書きの構造がファイルを読む段階で識別できれば、<dl>,<ul>,<li>といったタグをうまく埋め込むことができるはずだ。
今回のサンプルでは、例によってHDBスタイル(*注3)のファイルを読む場合に、区切り行(--)を使って各レコードのタイトル/本文を調べ、小見出しとして処理するとともにリンクリストを作成するようにした。ここでのポイントは、小見出しに当たる部分をどのように識別するかという点に尽きる。したがって、例えばセクションの最初に1,2,3...という数字で始まる小見出しを付けるという作成のルールがあれば、行頭に半角数字がある行を小見出しとみなして処理していくというようなバリエーションを作ればよい。
オプションとしては、小見出しで分けられたセクションを、<dl><dt><dd>タグを使った辞書スタイルにするかどうかを選べるようにした*補注4。辞書スタイルに設定すると、本文が小見出しから1段下がった形で表示されるので読みやすい。このオプションも、見出しのスタイルと同様、イメージ部分を使ってブラウザではどのように見えるか、およそのところが分かるようになっている。
リンクを設定する
一通りのHTMLドキュメントの要素は出来たので、今度は画像や外部ファイルをリンクさせていく。この段階では、ユーザーがテキストを直接編集する必要があるので、今までのような小さなフィールドでは使いにくい。そこで、大きめのカードフィールドを用意し、ここにこれまで作成したタイトルや本文などのパーツをつなぎ合わせて表示して、選択した箇所にリンクのタグを埋め込むようにする(画面5)。
リンクの設定は、リンク先のファイルをダイアログで選び、そのパスを受け取って適切なタグを作成するという仕組みだ。ここで注意しなければならないのは、リンクするファイルとHTMLファイル自身の位置関係である。基本的に、リンクファイルへのパスは相対パスで記述するから、自らをどこに保存するのかが決まっていないとリンクが設定できないことになるわけだ。そのため、まず作成中のHTMLテキストを保存するファイルを決め、それが完了して初めてリンクを作成するような仕組みにしておく必要がある。
このカードではイメージ確認エリアは設けず、「プレビュー」ボタンを用意して、HTMLの内容を実際のブラウザでテスト表示させるようにした。「完了」ボタンをクリックすると、先に設定した名前のHTMLファイルを作成する。
ウイザードとアンカーアプリケーション
ウイザードのような支援スタックを作るに当たっては、余り細かい機能を盛り込みすぎない方が良いだろう。ウイザードはあくまでも骨格の作成を助けるもので、細部に関してはそれぞれの専門ソフトに任せればよい。その方が、スタックの目的が明確になり、ユーザーもこのスタックを使って何をすべきなのかが理解しやすいはずだ。ウイザードの狙いは、対象の業務(HTMLの作成)に慣れていないユーザーでも、特別な予備知識なしで一通りのことがこなせるようにするというところにある。機能が豊富すぎると、かえって混乱させる可能性があることは注意を払っておくべきだ。
このようなウイザードで雛形を作り、これを次のアプリケーションに送り込むようにすれば、作業のつながりもスムーズだし、それぞれの役割分担もはっきりする。次工程がスタックの場合は、完了ボタンにgo命令とデータ転送のput命令を加えればよい。スクリプタブルなアプリケーションならAppleScriptを使ってさらに雛形を自動的に加工するという方法も考えられる。単なるアプリケーション起動(ローンチャ)から一歩進んだ自動化は、ハイパーカードオフィスの可能性をさらに拡げてくれるだろう。
注
*注1
もちろん、工程を単純にカードに置き換えればよいというものではない。ウイザードのような方式では作業を順番に行うと想定するが、実際には幾つかのことが並行したり、後戻りしたりすることもある。こうした点を考慮に入れながら、できるだけ実際の流れと違和感がないようカードを構成していくわけだ。
*注2
HyperText Markup Languageの略。WWWブラウザで書式やハイパーリンクを表現するために、普通のテキスト文書にマークアップタグ(markup tags)という記号を加えた形式である。詳しくは簡単なHTMLの説明を参照。
*注3
1995/7号で作成したHyperDB形式のデータのこと。レコードをハイフン2つの行(--)で区切り、各レコードの最初の1行を見出しとするテキストファイル。添付CD-ROMに、これまでの連載のテキストをこの形式で収録している。
リスト
リスト1
--最初と最後のカードがそれぞれ"Wiz 1"、"Wiz 4"という名前を持つ --HC ver 2.1以前の場合はenabledの代わりにvisibleを使う 1: on openCard 2: if short name of this cd is "Wiz 1" 3: then set enabled of bg btn "戻る" to FALSE 4: else set enabled of bg btn "戻る" to TRUE 5: if short name of this cd is "Wiz 4" 6: then set enabled of bg btn "次へ" to FALSE 7: else set enabled of bg btn "次へ" to TRUE 8: pass openCard 9: end openCard
リスト2
--ラジオボタンをクリックしてアラインメントを変更する --HTMLを書き換えるとともにTextAlignでフィールドの行揃えも変更 1: get fld "HTML" 2: if hilite of btn "CENTER" then 3: if char 1 to 8 of it is NOT "<center>" 4: then put "<center>" & RETURN & it & RETURN & "</center>" into fld "HTML" 5: set TextAlign of fld "MyHead" to "Center" 6: else 7: if line 1 of it is "<center>" 8: then put line 2 of it into fld "HTML" 9: set TextAlign of fld "MyHead" to "Left" 10: end if
【補注】
この原稿を書いた当時、まだHTMLをきちんと理解していたとは言いがたい部分があります。以下のような点は、今でも誤解されやすいと思いますので、悪い見本として原稿はオリジナルのまま残し、補注で不正確な点を訂正いたします。
- TITLEはコンテクストから外れてもその文書がどんなものであるか分かるようにつけるべきなので、単なるファイル名のような単純なものでは一般に不十分。
- あたかも見出し要素が文字の大きさを好みに指定するための機能であるかのような書き方になっているが、明らかにこれは誤り。このケースでは文書全体の表題を扱っているのだから、<h1>に固定しておいた方が良いだろう。
- 改行でも構わないが、段落の場合はやはりp要素を使うほうがよい。
- 辞書スタイルが段下げになるブラウザが多いことは確かだが、HTMLでこのように定められているわけではない。この場合、段下げにこだわるよりも、適切な見出し要素を使うべきである。
- ほとんどの場合「タグ」と記述しているのは「要素」として考えるべき
詳しくは当サイトのごく簡単なHTMLの説明をご覧ください。
(1997-03-25)。
(MacUser Japan, February 1996)