iBooks AuthorのウィジェットがePub3じゃなくて良かったという話 – Booki.sh Blogより

先日「iBooks Authorは電子書籍ではなくブックアプリを作るソフト。だからePub3じゃない。」という書き込みの中で、iBooks AuthorがePub3を採用しなかった最大の理由はデジタルの可能性を最大限に追求したいからだろうと推論しました。

その書き込みをしたときから気になっていたことがあります。ePub3ではJavascriptが使えます。そしてJavascriptを使えば、もしかしてiBooks Authorと同じようなインタラクティブなウィジェットが作れるかもしれません。つまり、iBooks Authorと同じ機能をePub3で実現することが不可能とは断言できないのです。

それにもかかわらずiBooks AuthorがウィジェットにePub3を採用しなかった理由は何だろうと考えました。以前の書き込みをした当時は、ePub3やJavascriptのような業界スタンダードに縛られてしまって、イノベーションのスピードが落ちるのを危惧したのではないかと考えていました。

しかし Booki.sh Blogの“A favor from Goliath”という記事を読んで、考えが変わりました（ちなみにBooki.shはebookをブラウザで読むためのプラットフォーム）。

Booki.sh Blogが言っているのは要約すると次のことです；

1. ebookの中にJavascriptを埋め込んでインタラクティブなウィジェットを実現するやり方はセキュリティー上の問題があるし、ユーザインタフェースとしても良くなりません。（詳細はこっち）
2. iBooks Authorのやり方は、ebookファイルにはどのようなインタラクティブな機能を実現するべきかを記載するに留め、それを動作させるための実際のプログラムはebookファイルに記載していません。ebookファイルに記載された通りの動作を実現するためのプログラムはiBooks 2の中に置いています。
3. インタラクティブなウィジェットのプログラムをebookファイルの中に（Javascriptで）埋め込んでしまうと、ebookファイルそのものを書き直さない限り、ユーザインタフェースを改善したり、バグを直したりできません。それに対してウィジェットのプログラムがebookリーダーの中にあれば、ebookリーダーをアップデートするだけですべてのebookのウィジェットのユーザインタフェースが改善できます。

言われてみるとなるほどと思うものばかりですが、プログラミングをあまりやったことがない人だとわかりにくいかもしれませんので、以下に自分なりに解説してみたいと思います。

セキュリティーの問題を考えるとebookフォーマットでのプログラミングには制限を設ける必要があります

ウィンドウズユーザであればわかると思いますが、メールの中に”.exe”拡張子のあるファイルがある場合、かなり気をつけなければなりません。”.exe”ファイルは実行可能ファイル、つまりプログラムです。そしてそれがもし悪質なプログラムであったらば、コンピュータにいろいろな悪さをしてしまう可能性があります。プログラムというのは怖いのです。

それに対して”.txt”拡張子であれば、それは単なるテキストファイルであり、実行されることはありません。これを開くにはメモ帳などのソフトが必要で、勝手にコンピュータに悪さをすることはありません。

ebookについても同様です。対策としてebookファイルの中で実行されるJavascriptプログラムにはかなり制限を設けるつもりらしいのですが、そのあたりはまだはっきりしていないらしいです（こちら参照）。またはっきりしてきたとしても、本当にJavascriptで良いウィジェットが書けるかどうかは未知です。

HTML, CSSなども「どういうものを表示するか」というフォーマット

ウェブページやePub3の基盤となっているHTML, CSSには、「どういうものを表示するか」しか記載しません。HTML, CSSを解釈して、その通りに表示するためのプログラムはすべてブラウザの中にあり、Firefox, Safari, Internet Explorerはそれぞれ独自の方法で表示させています。

ウェブページではJavascriptも使いますが、本来は補助的なものであり、HTML, CSSでは提供されていない特殊な機能を実現するために用意されているものです。最近ではJavascriptをより積極的に活用しているウェブサイトもありますが、それでもコンテンツのメインは依然としてHTMLとCSSです。

この視点で考えると、数多くのebookに共通して見られるであろうウィジェットについては、HTMLタグみたいなものをあらかじめ用意し、わざわざその都度Javascriptを書かなくても良いようにしてあげることがベターと言えます。

ebookリーダーの改良だけでユーザインタフェースが改善されるということ

OSのバージョン間の違いを例に話します。

ウィンドウズ上で動くプログラムにしてもマック上で動くプログラムにしても、かなり多くの部分はOSが担当しています。例えばほとんどすべてのマックのプログラムにはスペルチェッカーがついていますが、これはOSの機能です。プログラムを開発している人は自分では何もしなくても、OSが勝手にスペルチェッカーをつけてくれるからです。同じように、テキストを自動的に読み上げてくれる機能もOSが「勝手」につけてくれます。

しかもOSのバージョンが上がると、このスペルチェッカーの機能が改善されます。昔のMac OS Xにはスペルチェッカーしかついていませんでしたが、今のMac OS X Lionだと文法チェッカーもついています。プログラム開発者が何もしなくても、OSのバージョンが上がるだけでプログラムの機能が「勝手」に増えるのです。

もう一つ例を挙げます。最初のiPhoneではコピー＆ペーストができませんでした。どういうユーザインタフェースが良いか、Apple社内でも結論が出ていなかったらかです。そしてiOS 3になってようやくコピー＆ペーストが実現されましたが、このときもほとんどのプログラムは何も書き換える必要がありませんでした。OSのバージョンアップをするだけで、いままでのプログラムに「勝手に」コピー＆ペースト機能がついたのです。

現在のePub3のフォーマットにJavascriptを埋め込むというやり方だとプログラムはすべてebookファイルの中に入ってしまっていますので、完全に固定されてしまいますので、このように「勝手」に機能が増えたりユーザインタフェースが改善されるということは起こりません。

それに対してiBooks Authorのやり方であれば、iBooks 2のバージョンが上がるだけで、全く同じebookファイルを読んでいるにもかかわらず機能が増えたり、読みやすくなったりすることが将来的に起こる可能性があります。

最後に

つくづくAppleはイノベーションのやり方がうまいと感心します。

自社の中でどのようにイノベーションを推し進め、研究開発を行うかだけではありません。Apple、出版社、クリエーターを含めたエコシステムをどのように構築すればイノベーションが起こりやすいかもしっかり考えています。

ePub3ではない独自のebookフォーマットを採用している理由もそうですし、おそらくFlashを潰したのも根底には同じ考えがあるのでしょう。パソコンの歴史を振り返ると、旧Mac OSにしてもウィンドウズにしてもエコシステムに足を引っ張られ、イノベーションが停滞した時期があります（旧Mac OSの場合はマルチタスクが導入できなかったことなど）。スティーブ・ジョブズ氏はこれを全部見てきて、反省してきた人なんですね。