先日「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が言っているのは要約すると次のことです;
- ebookの中にJavascriptを埋め込んでインタラクティブなウィジェットを実現するやり方はセキュリティー上の問題があるし、ユーザインタフェースとしても良くなりません。(詳細はこっち)
- iBooks Authorのやり方は、ebookファイルにはどのようなインタラクティブな機能を実現するべきかを記載するに留め、それを動作させるための実際のプログラムはebookファイルに記載していません。ebookファイルに記載された通りの動作を実現するためのプログラムはiBooks 2の中に置いています。
- インタラクティブなウィジェットのプログラムをebookファイルの中に(Javascriptで)埋め込んでしまうと、ebookファイルそのものを書き直さない限り、ユーザインタフェースを改善したり、バグを直したりできません。それに対してウィジェットのプログラムがebookリーダーの中にあれば、ebookリーダーをアップデートするだけですべてのebookのウィジェットのユーザインタフェースが改善できます。
言われてみるとなるほどと思うものばかりですが、プログラミングをあまりやったことがない人だとわかりにくいかもしれませんので、以下に自分なりに解説してみたいと思います。 Continue reading “iBooks AuthorのウィジェットがePub3じゃなくて良かったという話 – Booki.sh Blogより”
Steve Jobsと共同でアップル社を創設したSteve Wozniak氏が好んでLos Gatos, CaliforniaのApple storeの前に並び、徹夜でiPhone 4Sの発売を待ったそうです。