TidBITS-J#453/02-Nov-98 TidBITS-J#453/02-Nov-98まず Emailer、そして今度は HyperCard? 果たして Apple 社は最も基本的 で優れたソフトのひとつを取り去ることができるのか? Geoff Duncan が HyperCard の歴史と発展の過程を振り返り、同時に HyperCard が窮地に立 たされている理由を探る。Jeff Carlson が Web ページから不必要な部分 を残らず取り去る 2 種類の HTML 最適化プログラムを検証する。そして ニュースは、Conflict Catcher 8.0.3 と Palm Buddy 1.1、そして Electronic Phoenix Project メーリングリストの開始についてお届けする。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。
今回の TidBITS のスポンサーは：
（翻訳：秋山 晃子 <nobineko@club.udn.ne.jp>）
Conflict Catcher 8.0.3 アップデートが配布される -- Casady & Greene 社が先週 Conflict Catcher 8 の無料アップデート、Conflict Catcher 8.0.3 をリリースした。この Clean-Install System Merge 機能はオリジ ナルアイテムに正しくラベルを付けることができる。またバージョン 8.0.3 は Sherlock プラグインが収納されたフォルダ“インターネット検索サイ ト”を管理し、68K のサポートを向上させ、システムマージの追加情報を 含んでいる。ダウンロードは 1.8 MB だ。 [ACE]
<http://www.casadyg.com/products/conflictcatcher/8/>
Palm Buddy アップデートにコンバータが追加される -- PalmPilot か Palm III を持っている Mac ユーザーは Palm Buddy 1.1 をダウンロード できる。これは Florent Pillet 氏作の大変有用なユーティリティで、 PalmPilot ファイルのバックアップをとったりインストールするためのソ フトである（“Mac PalmPilot オーナーのための新 Buddy” TidBITS-436 を参照）。新バージョンでは Palm ベースの 2 種類のデータベースプログ ラム、JFile と MobileDB 用プラグインが加えられ、Mac に表示された Palm Buddy のウインドウにタブ区切りテキストファイルをドロップするだ けで、これらのテキストファイルをインストールできるようになった。ま た、バージョン 1.1 ではフォルダを Palm Buddy にドロップできる機能が 追加され、ユーザーは一度の操作で前回のバックアップを回復できるよう になった。多くのバグ修正、より速いシリアル接続のサポート、Roman 以 外の言語用プラグインなどが追加され、よく仕上げられたアップデートに なっている。このプログラムは 20 ドルのシェアウェアで 1.2 MB のダウ ンロードになる。登録ユーザーのアップグレードは無料だ。
<http://perso.wanadoo.fr/fpillet/>
<http://db.tidbits.com/getbits.acgi?tbart=04956>
関連した PalmPilot のニュースとして、Palm Computing/3Com 社の Doug Wirnowski 氏によると、新しく Macintosh Palm Desktop 2.0v2 のパブリッ クベータ版が 11 月上旬に出るとのことだ。このソフトは 3Com 社が Apple 社から購入した Claris Organizer をベースに構築されている（“Palm Organizer for Macintosh：詳細が判明” TidBITS-432 を参照）。 [JLC]
<http://db.tidbits.com/getbits.acgi?tbart=04915>
Electronic Phoenix Project メーリングリスト登場 -- Electronic Phoenix Project（EPP）は見捨てられたソフトウェアを採用するために私 が設立を呼びかけた組織だが、数人からボランティアの申し出を受けてい る。EPP 設立のアイデアは広く興味をもって受けとめられ、オランダでは 新聞 Het Parool 紙に掲載されるまでに至った。議論を促進するために、 私は公開メーリングリストを作った。購読の申し込みは <phoenix-talk-on@tidbits.com> に、購読を中止するときは <phoenix-talk-off@tidbits.com> にメールを送ってほしい。リストは管理 しないので、議論の内容を EPP の創立と業務に限定するよう努めてほし い。（採用するプログラムについての提言は必要ない。すでに TidBITS Talk で多くのプログラムが候補に挙げられている。）どんな展開になるか 楽しみだ。 [ACE]
<http://db.tidbits.com/getbits.acgi?tbart=05141>
<http://db.tidbits.com/getbits.acgi?tlkthrd=424>
by Jeff Carlson <jeffc@tidbits.com>
（翻訳：西村 尚 <hisashin@axes.co.jp>）
（ ：高島 均 <hitak@kk.iij4u.or.jp>）
グラフィックデザイナーたちは、Web が“次の大物（The Next Big Thing）”となろうとしていた数年前に障害に突き当たった。それまで巨大 な画像のピクセルの各行に可能な限り多くのディテールを詰め込むことを よしとしてきた。しかし、Web 関連に携わるデザイナーたちは、画像を可 能な限り小さくする必要があることに気づいた。圧縮は Web デザインの求 めるべき聖杯となったのである。
この探究は新しい産業と不釣り合いな数のハウトゥ本を生み出す結果となっ たが、最近だけを取り上げると、それぞれの Web サイトを構成する HTML ファイルを最適化することに焦点が当てられている。Web ファイルからさ らにもう数バイトを削ぎ落とすために 2 つのユーティリティが生まれた。 Antimony Software 社の Mizer と Voget Selbach Entertainment 社の VSE HTML Turbo は、機能性を損なうことなく HTML ファイルの容量を小さくで きる。
毛すき中に噛みつくな -- 画像圧縮は 2 つの概念に依っている。繰り返 しの値を短い記述で置き換える（“損失のない圧縮”と呼ばれ GIF ファイ ルで使われる）か、視覚上目立つグラデーションのない不必要な情報を削 除する（“損失のある圧縮”と呼ばれ JPEG ファイルで使われる）かのど ちらかである。（画像圧縮の概要に関しては、 NetBITS-007 の“A Closer View of Web Graphics”を参照。）Web ブラウザは圧縮されたテキストファ イルを読み、デコードし、表示するように設計されていないので、損失の ない圧縮を HTML ファイルに適用するわけにはいかない。残るは損失のあ る圧縮である。不必要な情報を削ぎ落とすが、内容と HTML タグは手つか ずで置いておく方法だ。
<http://db.netbits.net/getbits.acgi?nbart=04458>
では、捨ててもよいものは何だろうか？ 何が Web 上で意味あるのかを探 るまでもなく、典型的な HTML ファイルには不必要な要素がある。ページ 内の改行、タブ、空白は最も顕著なものだ。目には見えなくても容量を消 費している。HTML 純粋主義者（と HTML チェッカー）は意義を唱えるかも しれないが、ほとんどの Web ブラウザは、タグ属性周りの引用記号（たと えば <IMG HEIGHT="50">）や HTML エディタが付け加えたタグ（たとえば <NATURALSIZEFLAG>）がなくても、正しくページを解釈できる。
また、コメントタグを標的にしてもいい（これは Web ブラウザに現われな いが注意書きを記すために、<!-- COMMENT HERE --> のようにして使われ る）。しかし、Web サーバによってはテンプレートから予め用意された内 容を追加したり、コメント内の命令によって指示されたアクションを行っ たりするものもあるので、このオプションには危険が潜んでいる。
時間があれば全部手動で行ってもよいが、そんな人はいないので、それな ら作業を代わりにやってくれる前述のユーティリティをチェックするとよ い。削ぎ落とされたファイルは、テキストを読みやすくするタブや改行、 空白がなくて見た目はひどい。これが Mizer と HTMLTurbo の作成者が HTML 圧縮はアップロード直前に行うよう薦める理由だ。このように、Web サーバ上にはより小さなファイルを置き、編集可能なコピーは自分のハー ドディスクに残る。必要な更新はローカルファイルに適用し、その後サー バ上のファイルを新しく最適化したコピーで置きかえるのだ。
Mizer でより賢く -- Mizer を使ってファイルを処理するには、Mizer のアプリケーションアイコンにそのファイルをドロップする。最後に 3 つ のファイルを手にする。最適化された HTML ファイル、オリジナルのバッ クアップコピー、達成された圧縮容量を報告するログファイルである。プ ログラムを直接起動して File メニューから Preferences を選ぶことでさ まざまなオプションを変更することができる。また、Mizer には、公式な HTML ルールに反するものだが、</LI>、</HEAD>、</HTML> などオプション の閉タグを削除する Tag Optimization と呼ばれる設定がある。
個々のファイルを圧縮することに加えて、Mizer はドロップされた Web ファイルのフォルダ全体を凝縮できる。Web サイトのローカルコピーを一 度で処理することが可能になるわけだ。
また、Mizer は JavaScript テキストも最適化するが、JavaScript の構文 は正確であることが重要だ（構文が崩れていてもブラウザが表示すること の多い HTML とは違う）。特に、記述は正しくセミコロンで終わっていな ければならず、改行（Web ブラウザによっては機能コードと認識するもの もある）だけではだめだ。
Mizer はスクリプタブルなので、Web ページ作成工程の中に自動化ステッ プとして組み込むことができる。たとえば、Mizer が提供するサンプルス クリプトはファイルを最適化した後、Fetch を使って Web サーバにアップ ロードする。
VSE HTMLTurbo でテキストを一吹き -- Mizer 同様、HTMLTurbo も HTML ファイルの最適化がドラッグ & ドロップ操作でできる。ただ、こちらには よりたくさんの設定オプションがある。例えば、Preferences ダイアログ ボックスで、取り除くコメントタグや <META> タグを指定できる（<META NAME="generator"> タグのみを取り除くことも可能だ）。
HTMLTurbo は、HTML コードにエラーを発見したときにそれを知らせてくれ るのだが、しかしその実装は雑な作りで、ダイアログボックスが現れ出る とそれを閉じない限りプロセスが停止してしまう。幸いなことに、このオ プションは機能停止が可能だ。
HTMLTurbo は、Results ウインドウを表示して、節約した総バイト数を用 いてある期間内に節約可能な帯域幅がどのくらいかを見積もってくれる。 ファイルを選択しそのページが受けるおおよそのヒット数を入力すると、 HTMLTurbo は、日、月または年単位での平均的な節約見込みを報告する。 これを確実なデータであると見なすものではないが、努力の効果を見るの は興味深いことだし、とりわけ Web ホストの料金が実際に使用された帯域 幅を基に算定されるのであればなおさらだ。
役に立つか? 両方のユーティリティを、小さなテキストのみのページか らたくさんの JavaScript エレメントを使った複雑なレイアウトに至るま で、さまざまな HTML ファイルでテストしてみた。両プログラムともに、 デフォルトの圧縮設定のままとした。当然のことながら、より複雑なファ イルのほうが良い結果をもたらした。あるケースでは、45,532 バイトの ファイルが、Mizer では 39,486 バイト（6,046 バイトもしくは 13.3 % の節約）に、HTMLTurbo では 40,448 バイト（5,084 バイトもしくは 11.2 % の節約）に縮小した。しかしながら、マクロが生成した TidBITS-452 のファイルでは効果が最も小さかった。32,983 バイトというオリジナルの サイズから、Mizer は 32,586 バイトのファイル（1.2 % の節約）を生み 出し、一方 HTMLTurbo は 32,432 バイトのファイル（1.67 % の節約）を 作成した。
完成した 2 つのサイトをプログラムにかけてみた。22,713,440 バイト （22.7 MB）もある大きなほうは、Mizer では 21,589,258 バイト （1,124,182 バイトもしくは 4.95 % の節約）に、HTMLTurbo では 21,488,988 バイト（1,224,452 バイトもしくは 5.39 % の節約）に縮小し た。これらの数値は、サイト 全体 やグラフィックやあらゆるものすべ てを表していることに注意して欲しい。全く派手さがない 2 つ目のサイト は、134,236 バイトから 14.8 % 縮小し 114,265 バイト（Mizer）、また 15.5 % 縮小し 113,445 バイト（HTMLTurbo）となった。
圧縮への難癖 -- 総合的に言えば、私は、非公式な実施結果に見られた 5 % から 15 % という圧縮に満足している。最適化によるページエレメン トの破壊は何も確認できなかったし、いくつかのケースではロードに要す る時間が改善されたようだった。ところが、両方のプログラムが熱狂的に 主張するにも関らず、実際の利用におけるスピードの差異というものは、 インターネットのトラフィック、所持するコンピュータ、インターネット へのアクセス方法など、他の要素の影響を受けるものなのだ。
事実、私がそれぞれのプログラムに見出した問題点は、結果よりもむしろ インターフェースや動作に関するものだった。Mizer についての最大の悩 みの種は、複数の HTML ファイルを含むフォルダの取り扱いに関するもの だ。プログラムはオリジナルファイルのバックアップコピーを作成するの だが、それらは新規フォルダ内ではなくもともとのディレクトリ内にばら まかれる。このことは、複数のフォルダ階層に 1,466 個のファイルを持つ 大きなサイトの例に対し、オリジナルと圧縮後バージョンとの分離を手作 業で行わなければならないということを意味する。
内容に違いはあるものの HTMLTurbo にも似たような問題がある。こちらは 処理後のファイルを全部一つのディレクトリに放り込むのだ。たから、ハー ドディスク上の異なるサイトから複数のファイルを圧縮しようものなら、 （index.html のように、同じ名前を持つファイルが全くないことを願いな がら）それらを選り分けなければならないことになる。HTMLTurbo へもう 一つ難癖をつけるなら、それは HTML ファイルから実際に何が除去される かついての情報を全く欠いていることだ。このような詳細レベルを必要と しない人もいるかもしれないが、私は、私が苦心した HTML に何が施され ているかを知りたいのだ（このことは私がしばしば WYSIWYG HTML エディ タを不審に思う理由でもある）。Mizer なら、少々自在性には欠けるもの の、ReadMe ファイルでその動作を正確に説明することでこの点を埋め合わ せている。
自己満足に耽るのならどうぞ -- HTML からできる限りを絞り出したいデ ザイナーにとっては、両ユーティリティはその作業に打って付けだ。Mizer 1.2 は、TidBITS スポンサーである Digital River 社から 69.95 ドルで 購入できる。デモ版はないが、Antimony Software 社は、購入後 30 日以 内であれば全額払い戻しを保証している。VSE HTMLTurbo は 1.2 MB の ダウンロードだ。デモバージョンは 21 日間すべての機能を使用でき、そ の後の登録コードの入手は 79.95 ドルだ。
<http://www.antimonysoftware.com/>
<http://www.vse-online.com/>
by Geoff Duncan <geoff@tidbits.com>
（翻訳：尾高 里華子 <rikako@pobox.com>）
（ ：尾高 修一 <shu@pobox.com>）
Apple 社の HyperCard は 10 年以上もの間、画期的な製品であり続けた。 たった一人でスクリプティングやオーサリングなるものを生み出し、数多 くの類似製品のモデルになった。そしてユーザーには努力さえすればコン ピュータで驚くような独創的なものを作り出すことができるという可能性 を与えた。HyperCard ほど Macintosh の精神を受け継いでいるものはない。
今 Apple は何の前触れもなくこのソフトの息の根を止めようとしている。 HyperCard が高性能な QuickTime オーサリングツールとして復活する直前 だというのに。HyperCard の窮状を説明するのは、HyperCard のたどった 道を振り返ることになるが、同時に今も失われずにいる HyperCard の根本 的な強さを示すことにもなる。
では本論に入ろう -- HyperCard ほどその正体を説明するのが難しいソ フトはないだろう。大抵のソフトはある特定の処理を行うようになってい る。例えば、ワープロは文字列や文書を取り扱うもので、データベースは 情報を貯めたり取りだすもの、表計算はデータを入れて計算を行い、Web ブラウザはオンラインにあるコンテンツを表示するものだと言えばよい。 こういったプログラムはその用途がはっきりしており、ほとんどの Macintosh ユーザーはあるプログラムが何をするもので、どういった目的 で使うかを説明することができる。
さて HyperCard だが、これはあまりにも抽象的である。上記で取り上げた アプリケーションが行うことを（向き不向きがあるものの）ほとんど すべて 実行できるし、それ以外にできることも多様にある。昔からあ る真のオーサリングプログラムの一つで、（グラフィック、文字列、音、 ムービーなどの）情報を組込みながら、内蔵の強力なナビゲーション機能 を利用し、さらには特定のニーズに合うようにスクリプトを書くこともで きる。プログラムを書くことと同じではないかと思うかもしれないが、そ れもそのはず。HyperCard には HyperTalk という英語っぽいスクリプティ ング言語が含まれているのだ。そしてこれは今でもプログラミングの第一 歩として多くの人に利用されている。HyperTalk を使えばマルチメディア ゲーム、キオスク、プレゼンテーションから住所録、請求書、製品のデモ、 オンラインヘルプなどなどを作れるのだ。さらに HyperCard は AppleScript、PlainTalk、QuickTime、（特に重要な）WorldScript のよう な要となるテクノロジーをすぐにサポートしてきた。
<http://www.apple.com/hypercard/>
正体は? HyperCard は柔軟性が最大の強みである一方で、抽象的だとい うことがまた最大の弱点でもあった。「HyperCard って何をするものなの ?」「再生エンジンなの? 」いう質問には「イエス」。「開発ツールなの?」 という問いには「そう思ってもいいよ」。「個人情報オーガナイザー?」に 対しては「もちろん」。「データーベース?」「全くその通り」。「スクリ プティング環境?」「そうだよ」。「もっとほかのこともできるの?」「何 だってできるよ」。
「でも HyperCard はマルチメディアオーサリングツールじゃないの?」 「そのようなものだ」。1987 年に登場した HyperCard はマルチメディア プログラムツールの先駆けであった。その頃はモノクロの Mac が高価な時 代で、その一世を風靡した HyperCard のプレゼンテーション機能は、 HyperCard の考案者である Bill Atkinson 氏に因るところが絶大だった。 それ以前に彼は QuickDraw や MacPaint を手がけていたのだ。
HyperCard のプレゼンテーションやグラフィックはそのモノクロ時代に基 礎が作られたため今でも HyperCard 自体は色を認識することができない。 その間サードパーティーや Apple が HyperCard に拡張機能を付け足しな がら、カラー画像の表示、インターフェースのエレメントへの色付け、 QuickTime のサポートをおこなった。これらのアドオンは HyperCard の 柔軟性を誇示し、Myst のような好評な製品のベースにもなった。だが、こ ういったものには大きな穴があり、しばしばぶざまで、派手な色のマント をまとっても所詮 HyperCard が白黒のペンギンである事実を偽ることはで きない。
HyperCard は膨大な努力さえすればカラーを扱えるように書き直すことも できるはずだが、実現には至っていない。1991 年に出た HyperCard 2.0 では組織的かつ業務的な制約が邪魔になった。HyperCard が Claris に移 されて商品版になったことがその原因の一部である。Claris で HyperCard はやつれてしまい、Apple に戻ってからはさらに憔悴してしまった。 HyperCard がもたついている間に SuperCard や Director のような製品は カラーを扱えるオーサリング環境を整え成長を遂げた。HyperCard のデベ ロッパーは単独アプリケーションにする機能や、AppleScript や WorldScript を始めとする改善を山ほど行ったのだが、フルカラー対応に なるように書き直すには及んでいない。
希望は? 次に Apple の QuickTime 3.0 プロジェクトが始まった。3 年 前赤字に転落して、市場のシェアを減らし、ユーザーの信頼を失いだして いた Apple にとって、QuickTime は成功への鍵だった。QuickTime はデジ タルビデオの標準になり、Apple は QuickTime で大博打に出た。
QuickTime 3 の中で、“ムービー”は根本的に各種のデータのタイプの一 コンテナに過ぎないが、（音声、画像、古典的なメディアには付いていな いボタンのような）独立したオブジェクトを持つことができるようになっ ている。これらオブジェクトはマウスクリックのようなイベントを受け取 ることができるのだから、ユーザーや別のオブジェクトからのアクション に答えることができても当然だろう。これこそが QuickTime Interactive （QTi）の元になっているアイデアであり、オブジェクトがいかにしてユー ザーやオブジェクト同士に働き掛けるかの方法の特定が QuickTime が必要 としていることである。すなわち、スクリプティング言語が必要なのだ。
Apple はすでに HyperCard でスクリプティング言語とオーサリングツール を手にしているし、答えは明らかだった。QuickTime データ形式を用いる QuickTime に HyperCard 3.0 を載せて動くようにすれば、HyperCard 3.0 は QuickTime ムービーを扱うエディタになるだろう。HyperCard で書かれ たプロジェクトは QuickTime のカラー機能をそっくり受け継ぐだろうし、 QuickTime をサポートしているものであればどのプラットフォームのどの アプリケーションでも動作するだろう。HyperCard チームは窓際に追いや られて弱体化していたが、中枢に位置し優先的に扱われるうえに資金も豊 富な QuickTime のチームに組み込まれ、HyperCard ファンは大喜びだった。
Apple はここ数年 HyperCard 3.0 を幾度となく見せびらかしてきた。デモ では HyperTalk が QuickTime オブジェクトに埋め込まれており、 QuickTime を通して HyperCard スタックが Web ブラウザで動作し、 HyperCard のスタックのウインドウにインターネットのコンテントが表示 されるのを示した。HyperCard 3.0 が実際に動くのを目にした人は大勢い るし、Apple は HyperCard 3.0 の出荷を公約しているが、リリースの日程 は未だはっきりしていない。
1997 年に Apple は QuickTime 3 を QTi 抜きで出荷するつもりだとこっ そりとデベロッパーに知らせた。QuickTime 3 は完全クロスプラットフォー ムの最初のリリースだったので、少しでも早く QuickTime 3 を完成させる ことはビジネスの点からすると理にかなっていた。Apple は QTi を取りあ えず QuickTime では先送りしつつも、QTi と HyperCard 3.0 の約束は再 公言した。同時に HyperCard チームは HyperCard が Mac OS 8 で速くな るアップデートをリリースし、QuickTime 3 に対応したスクリプト機能を 含めた幾つかの機能を搭載させた。
なぜ今? ところが、ここ 2 週間の間に気がかりなニュースが Cupertino から漏れ聞こえてきている。HyperCard のエンジニアたちはだいぶ前から QuickTime そのものの開発に携わってきた。これは QuickTime 3 を早く出 荷して HyperCard 3 に必要な条件を整えるためでもあった。ところが数週 間前、HyperCard チームが全員 QuickTime 開発に配置替えになったのだ。 現時点では、HyperCard チームというものは存在しないし、今後存在する 予定もなく、HyperCard の開発は全く行われていない。信頼できる情報筋 によると、Apple の Worldwide Product Marketing 担当副社長、Phil Schiller 氏は 10 月末の社内会議で HyperCard の開発が停止されること を発表した。HyperCard コミュニティからの粘り強い要求にもかかわらず、 Apple は HyperCard の未来について公式な態度表明をしていない。
Apple が HyperCard 3.0 を放棄する理由は? 様々な憶測が流れているが、 私が見たところ最もつじつまが合うのは、原因は HyperCard よりも QuickTime にあるとするものだ。Apple は QuickTime 3 で巨大かつクロス プラットフォームなメディアアーキテクチャを構築しており、しかもそれ は ISO MPEG-4 規格のベースとして採用されている。これは大変な成果で、 Apple がコンピュータ業界で明らかに優位を保っている数少ない分野の一 つだ。推計によると、QuickTime は世界中で 2,400 万台の Mac に搭載さ れており、Media Metrix 社の調査によると、1998 年 3 月時点で米国内の Intel ベース PC 3,530 万台のうち、70 % に搭載されていた。しかもこれ は QuickTime 3.0 以前の話だ。
<http://www.mediametrix.com/corp/press/press_mm58.htm>
したがって、QuickTime は他の Apple テクノロジーと比べて、業界の風当 たりが強く陰謀の渦にも巻き込まれやすい。Microsoft 社は特に Windows 環境での QuickTime の優位を嫌ってきた。Microsoft の反トラスト訴訟の 資料からは、Microsoft がサードパーティーに QuickTime サポートをやめ るように圧力をかけ、Apple にデジタルメディア市場を分割するように働 きかけたとされる様子が浮かび上がってくる。これが真実かどうかはとも かく、Apple が QuickTime で獲得した陣地を守るために多大な時間と労力 を割いていることは確かだ。
<http://www.seattletimes.com/news/technology/html98/appl_102998.html>
<http://www.seattletimes.com/news/business/html98/micr_092098.html>
こういった圧力があることを考えると、QuickTime への支持を確保するた め、Apple がデジタルメディアのデベロッパーに対してなんらかの譲歩を せざるをえないとしても不思議ではない。ましてやこうしたデベロッパー の多くは Windows と Mac 両方の開発を行っているのだ。この譲歩の一つ がサードパーティ製 QuickTime オーサリング・製作ツールと競合しないと いうことだとも考えられる。HyperCard 3.0 が本質的にはインタラクティ ブな QuickTime ムービーのエディタであることを考えると、Macromedia、 Adobe、Sorenson Vision、TrueVision、Equilibrium、それに Electric Image などのデベロッパーが、Apple によるインタラクティブ QuickTime ムービーエディタの開発と販売に抵抗する可能性はある。ある意味でこの 状況は Apple が Emailer で陥っているジレンマと似ているということも できる。製品を放棄してユーザーの怒りを買うか、前進してデベロッパー の怒りを買うかだ。
<http://db.tidbits.com/getbits.acgi?tbart=05129>
というわけで、HyperCard は開発チームを失い、QuickTime Interactive の機能はほんの一部が QuickTime アプリケーションデベロッパー向けに ローレベル API として提供されているだけだ。
<http://developer.apple.com/techpubs/quicktime/qtdevdocs/REF/ tp_qt3sprite_wired.htm>
今後は? HyperCard がどのようにしてこんな状況に陥ったかを思い出し ていただきたい。マルチメディアオーサリングで決定的に不利な統合カラー ツールの欠如だ。これは HyperCard の抽象性が同時に最大の欠点になって いることを示す格好の例だ。HyperCard はマルチメディアなどこれっぽっ ちも作らなくても、Macintosh ユーザーの多数のニーズに答えることがで きている。たとえば、TidBITS を支えているのは HyperCard なのだ。購読 の管理、配信、データベース管理、Web サイト制作、それにメーリングリ ストのアーカイブも HyperCard で作られている。Adam は TidBITS の最初 の 99 号を HyperCard で配布したぐらいだ。
私は頻繁にビジネス、教育、それに家庭向けの HyperCard プロジェクトの 仕事を請け負う。この中でマルチメディア機能を利用するものはほとんど ない。多くは情報へのアクセスや、学生がプログラミングや外国語を学ぶ ためのものだったり、AppleScript だけではできないようなアプリケーショ ン間の連携だったり、実験室の機器を制御したりするものなのだ。私が作っ た中で最大の HyperCard プロジェクトは URL の検証や Web ページの分析 を行なうインターネットロボット、Golem だ。これは Microsoft をはじめ とする有名企業も使用している。ほかには、カスタムデータベース、コン タクト管理、Web サイト管理、テレビの字幕作成、原子モデリング、CD-ROM や Web 用のコンテンツ作成などの利用がある。HyperCard の柔軟性を示す 驚くべき実例は、Jacque Landman Gay 氏の Web サイトで見ることができ る。多くの場合、こうしたプロジェクトがそもそも Mac が導入された唯一 の理由だったのだ。
<http://www.hyperactivesw.com/HCStories/stories.html>
HyperCard の歴史的使命は終わったとする人もいるかもしれない。もっと モダンなプログラムで、ほぼ同等の機能を実現することができるからだ。 ユーティリティのデベロッパーは成長目覚ましい REALBasic を手にすれば 良いし、AppleScript ユーザーはアプリケーションの連携には FaceSpan でインターフェースを作ることができる。HyperCard に慣れたユーザーは、 IncWell 社が Allegiant 社から買い取ってから息を吹き返しているカラー 対応の SuperCard でマルチメディアオーサリングをしてみることも可能 だ。クロスプラットフォーム機能が必要な HyperCard ユーザーは Windows、Unix、それに Mac に対応した MetaCard を使うこともできる。 スクリプティング一筋の方は Userland Frontier の自動化・Web パブリッ シング機能をチェックすると良いだろう。もちろん、マルチメディア制作 にはヘビー級の Macromedia Director に大金をつぎ込んでも良いし、 QuickTime 3 に集中するのなら Totally Hip 社の Web 指向ツール、 LiveStage でインタラクティブムービーを作ることができる。
<http://db.tidbits.com/getbits.acgi?tbart=05043>
<http://www.facespan.com/>
<http://www.incwell.com/SuperCard/SuperCard.html>
<http://www.metacard.com/>
<http://www.scripting.com/frontier5/>
<http://www.macromedia.com/software/director/>
<http://www.totallyhip.com/Link/ProductsLiveStage.html>
上記の製品はいずれも良いものなのだが、HyperCard の柔軟性に匹敵でき るものはない。一方、多くは HyperCard のマルチメディア機能をはるかに しのいでいる。このうちほとんどは HyperCard が利用できる外部コマンド を利用することはできない。ほどんどは AppleScript などの OSA スクリ プティング言語をわずかにしか、あるいは全くサポートしていない。一部 は難解なスクリプティング言語を持っており、HyperCard のようなナビゲー ション機能やデータ格納機能を持っているものは少ない。しかも、私が知 る限りインターナショナルなユーザーになくてはならない WorldScript 機 能を備えているものはない。HyperCard は依然として他の追随を許さない のだ。
それでは何を? 今日、HyperCard の運命ははっきりしていない。もしあ なたにとって HyperCard が大事なら、なぜ HyperCard を使うのかと、ど のように HyperCard を使っているかを Apple に知らせよう。Apple が HyperCard が Mac の売上に貢献し、Macintosh でしか実現できない機能を 提供し、とっくに PC で置き換えられていたかもしれない現場で Mac の寿 命を長らえたということがわかったら、Apple も HyperCard が Macintosh コミュニティで比類なき価値を持っていることを理解するかもしれない。
HyperActive Software 社の Jacque Landman Gay 氏は、Apple の暫定最高 経営責任者 Steve Jobs 氏に Mac ユーザーにとって HyperCard がいかに 重要かを説明する投書キャンペーンを始めた。（電子メールでの投書はメー ル爆弾になるのでダメだ。メール爆弾を喜ぶ人などいない。）HyperCard ユーザーからの礼儀正しい、よく考えられた手紙は、HyperCard の再検討 を促す効果があるだろう。同時に、これまで何年もの間縁の下で HyperCard を支えてきた Apple エンジニアたちに、HyperCard の未来を確かなものと するための力となるだろう。必要なものはすべて HyperActive 社の Web サイトにある。あと必要なのはあなたの力だけだ。
<http://www.hyperactivesw.com/SaveHC.html>
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 