２．AD-BOOKの原点となったホームページ

■AD-BOOKの原点となったホームページ

AD-BOOKは最初から電子書籍として構想していたわけではありません。むしろホームページを本を読むような感覚で見ることを念頭に置いていました。開発初期はまだインターネットの黎明期と言える時代で、ホームページもほとんど個人発信の独断場のような状態でした。企業や自治体等の参入も少なかったせいか、ホームページの構造も単純なものが多く、トップページからのリンクでコンテンツのページを見る程度のものだったように思います。現在のようにネットが商売に活用されるのはまだ先のことで、当時の最先端のツールと言えども、自由奔放で牧歌的なのんびりとした時代でもありました。誰もが試行錯誤の中で、インターネットの未来を模索できたからこそ、私もAD-BOOKに理想を抱いて開発に専念できたのかもしれません。

当時の一般的なホームページは、魅せる要素などあまり重要視されず、何層にも渡る複雑なページ構成など皆無に等しいものだったと思います。AD-BOOKのコンセプトは、コンテンツをいかに効率良く楽しく閲覧することができるかでした。ブラウザは初期の頃からJavascriptを実装して動的なコンテンツを扱えたため、漠然とながらこれを利用すれば目的が達成できると考えたわけです。そこで、まずは効率良く読めることを目指しました。最終的には本のようなものを実現したかったのですが、知識も技術も乏しい状態でいきなりは無理な話です。最初は単純なものからスタートすることにしました。例えばネット上で小説やマンガを読むような場合を想定してみて下さい。最低限必要なのはページを進めるボタンと戻るボタンです。下図はその基本イメージになります。

しかし、紙媒体の本のように自由に読み進めるためには、ホームページに単なるページ移動ボタンを備えただけでは十分ではありません。目次を見たり任意のページに移動したり、しおりのような形でいつでも同じページを参照したりと、様々なブックリーダーとしての機能が必要になります。従って、最初はホームページに埋め込む形でブックリーダーの機能を搭載することにしました。現在のブラウザ上で読むブックリーダーと着想は同じです。前述したように、ブラウザにはJavascriptと呼ばれる強力なプログラム実行環境が搭載されていて、ブックリーダーの機能を実装することも可能に思えました。しかも、紙媒体では不可能な動的なコンテンツまでも実現できそうです。また、ページ内でURLを指定すれば、インターネット上の他の情報にシームレスにアクセスできるのも魅力的でした。当時の少ない情報や未熟な知識の中でも、ブラウザが内に秘めた可能性は無限に思えるほどだったのです。

当時を振り返ると、AD-BOOKの開発当初はDTPに専念していたこともあって、作業環境はMac（Macintosh）が中心でした。ちょうどWindowsが勢力を伸ばしていた時期でもあり、作業環境自体もMacからWindowsへの移行を模索していた頃になります。ところが、DTPは本来の効率アップの目的よりもコストダウンの道具とみなされる傾向が強まり、次第に作業そのものにハードワークが要求されるようになっていきました。印刷会社も大手が地方にまで進出して業界の淘汰が進むことになり、身近でも廃業する業者が増えて取り巻く環境は悪化の一途でした。その頃には所持するMac関連の設備も古くなり、DTPを続けるためにMacの環境を一新するかWindowsに移行すべきか、迷いながらの日々だったのです。

DTP環境が厳しくなる一方で、インターネットは確実に一般にも浸透して広がり始め、時代は印刷からネットへと動き始めていました。個人を中心としたホームページ作りが盛んになるにつれて、企業も積極的にインターネット参入に取り組むようになったのです。COSMOLIGHTがDTPからインターネットへのシフトを目指したのは、当時の情勢からもごく自然の流れであったわけです。そんな中で、前述したようなブラウザの機能に目を付けて、まずはホームページの中で本のように扱える方法を考えました。残念ながら当時の資料は古いMac関連の媒体内にあって、環境が完全にWindowsに移行した今では参照もできません。そのため一部の移行した資料と曖昧な記憶になりますが、当時を思い出しつつ簡単に紹介しておきたいと思います。

電子ブックと言えば、その頃は専用端末（今で言えばAmazonのKindleのようなもの）自体を示す言葉で、ホームページ上の本を電子ブックと呼ぶことはあまり無かったように思います。私自身はコンピューターの世界でも本のイメージを強く持っていたため、当初から電子ブックの名で通していました。最初に作ったホームページ上の電子ブックは、ブラウザの表示ウインドウ上部にページを操作するコントローラーを配置し、下部の大部分をコンテンツ表示エリアに当てたものでした。わずかな資料として残っていた下図がその全貌です。コントローラーには電子ブックを呼び出した元のホームページに戻る「Home」ボタン、目次を表示する「Navi」ボタン、自動でページを送る「Auto」ボタン、サウンドをオン・オフする「Sound」ボタン、本の使い方等を表示する「Info」ボタン、ページを前後に進める移動ボタンとかなりシンプルなデザインですが、後のAD-BOOKシリーズにつながる実用的な基本機能を備えていました。

しかし、コントローラーを上部に配置した場合、マウス操作が意外に煩雑となることがわかり、途中で下部に配置する形に改めました。Windowsのメニューバーが画面の下部にあるように、目線と操作を考えるとその方が明らかに自然だと考えたからです。実は最初に上部に配置したのはMacの影響によります。当時からMacのデスクトップは上部にメニューが配置され、長年その操作に慣れていたからに他なりません。確かにリアルなデスクを考えた場合、手前（画面では下）に色々置いてあっては邪魔です。恐らくMacもそれが念頭にあったのだと思いますが、画面上ではむしろ手前側にあった方が操作は楽になります。意外な盲点でしたが、実際操作してみるとその優位性が実感できます。もっとも、当時はモニター画面も小さく、上下スクロールも頻繁に行う必要があったので、画面の下に操作ボタンがあると誤操作の恐れがありました。些細なことですが、Macはそんな細かな点まで配慮していたのでしょうか。今でも上部にメニューは配置されたままですが、下部にランチャーを置いたのは（アプリのアイコン類をまとめて配置）、その方が使いやすいという判断があったからなのでしょう。メニューは頻繁に使うものでも無いため、従来通りの配置と言うわけです。

少々話が脱線したので電子ブックに戻ります。当時はまだビューワーに正式な名前も無く、単なるホームページの機能として実用化を目指していたに過ぎません。電子ブックを開発するずいぶん前からホームページを作っていたため、電子ブックの構造の目処はすぐに立ちました。それはHTMLのフレームを使ってベースを構築し、コントローラーとページを別々のフレームにして、コントローラーの操作がページフレームに反映されるようにするものでした。制御プログラム自体はコントローラーフレーム内にJavascriptで記述しています。正確にはコントローラーフレーム内に操作ボタンを配置したHTMLドキュメントを書き出し、Javascriptで記述した制御プログラムの外部ファイルを取り込んで実行しているのです。ページはファイル名を通し番号で管理することでブック構造を単純化しました。早い話が順にページファイルを読み出して表示すれば、本のページをめくるのと同じ状況が実現するわけです。この時生まれた新しい電子ブックは、簡素ながらもなかなか使い勝手が良くて、やがてAD-BOOKの開発へと発展する原動力になったのです。