曖昧になるWebコンテンツと「書籍」コンテンツの境界 – HTML5電子書籍余話 その2 –

 当初、このエントリは「Webサイト化する電子書籍– HTML5電子書籍(2) -」のまとめとして書いていたものだったのですが、いつものように長くなってしまったので、エントリを独立させました。
 

1.前回のエントリをうけて

 というわけで前回のエントリでは「Webサイト化した電子書籍」と「電子書籍的UI」を付与する方法について紹介してきました。あのエントリをお読みいただいた方の中には以下のような疑問を抱いた方もいるのではないかと思います。
 
 従来のWebサイトとWebサイト化した電子書籍を区別する必要はあるのか。
  
 コンテンツの由来が紙の「書籍」由来であろうとWebオリジナルであろうとWebサイトとしては同じではないか、「電子書籍的UI」はデザイン上の些細な違いでしかない。そうお考えの方もいらっしゃるだろうと思います。
  正直、意見が分かれるところだと思いますが、私自身は後で述べる理由で少なくとも紙の出版物が消滅するということでもない限りは、今後もある程度区別はされていくと考えています。しかし、WebとWebサイト化した「書籍」コンテンツがビュワーとして同じようなデバイスとブラウザを共有している以上、その違いはこれまでのWebと「書籍」のような絶対的なものではなくなり、相対的なものになっていくだろうも考えています。 
 
 

2. Webコンテンツと電子書籍の共通する大前提

 Webコンテンツもリフロー型電子書籍(Webサイト化したものに限らず)は以下のような様々なサイズのデバイスに対応しなければなりません。
デスクトップ、タブレット、スマートフォンの図
 
 Webコンテンツや「書籍」コンテンツがどれほど優れたデザインをしていようと、読者が読むデバイスで読みづらかったらその読者にとってその「優れたデザイン」は何も意味はありません。「Web」や「書籍」というコンテンツそのもののデザインを論じる前に、その読まれるデバイスへの最適化するためのUIを考慮する必要があります。つまり、デバイスのインターフェイスを無視したコンテンツのUIはありえないということですが、言い換えると
 
  デバイスのインターフェイスがコンテンツのUIを規定する。 
 とも言えます。これが大前提です。
 Webコンテンツとリフロー型電子書籍の場合は、特定のデバイスのインターフェイスの制約に規定されるのでなく、様々なスクリーンサイズのデバイスのインターフェイスに対応しなければならないという制約がコンテンツのUIを規定することになります。
 
 同じ制約のもとで読みやすいUIを追求していく限り、Webコンテンツも「書籍」コンテンツも似たUIを持つ可能性はあります。Webサイト化した電子書籍はデバイスだけではなく、Webブラウザというビュワーまで同じくするのですからなおさらです。
 
 

3. 「電子書籍的UI」の意義

 では、Webコンテンツと「書籍」コンテンツは同じデバイス上で読まれる限りは同義ではないかと言われてしまいそうですが、
  Webコンテンツと「書籍」コンテンツは長さが違う。 
  
  ということで、他にもいろいろと違いはあるのですが、端的にいえば、長さという点で大きく異なります。
 
 「書籍」というコンテンツは100頁強の量でも少ない部類に入りますが、Webコンテンツは紙に打ち出せば、A4で数頁で収まるものが主流です。WebコンテンツのUI(Webデザイン)は大雑把にいえば、そのA4で数頁という長さに最適化するためにこれまで試行錯誤してきたわけです(もちろんそれだけではないですけど)。同じデバイス上で読むとはいえ、WebコンテンツのUIに「書籍」コンテンツにそのまま適用するわけにはいきません。
 将来の有り様はわかりませんが、現在の「書籍」コンテンツには長いコンテンツを読むことに集中できるUIが求められています。「Webサイト化した電子書籍」に「電子書籍的UI」というものを付与する意味があるとすれば、そこにこそ意味があるのだと思いますし、Webコンテンツと「書籍」コンテンツを分かつものだと思います。つまりは、長いコンテンツを読むのに適したUIが「電子書籍的UI」なのであって、必ずしもページめくりのエフェクトが必要だとか具体的なUIを指しているわけではありません。長いコンテンツを読むのに適したUIはコンテンツごとに異なってくるわけですから。
 
 「書籍」コンテンツが100頁強でも短いとされるのはその前提として「紙の書籍」が存在するからです。同じコンテンツが紙版と電子版で刊行という次元の話ではなく、紙の書籍という存在そのものが比較の対象として「書籍」コンテンツの長さをある程度規定している。50頁や100頁の「書籍」コンテンツは読者に「短い」と感じさせ続けるわけです。
  

4. 曖昧になるWebコンテンツと「書籍」コンテンツの境界

 とはいえ、Webコンテンツと「書籍」コンテンツの違いは絶対的なものではなく、相対的な違いではしかないと思います。ここでは、長さを1つの基準にしましたが、「書籍」コンテンツの影響を受けて「長くなるWebコンテンツ」が出てくるでしょうし、もちろんWebコンテンツの影響をうけて「短くなる書籍」コンテンツもでてくるでしょう。Webコンテンツと「書籍」コンテンツの境界線はどんどんあいまいになっていくことになります。
 従来のWebコンテンツと比較すると長い過ぎる、しかし、「書籍」コンテンツと比較すると短いと思えるWebと「書籍」の中間に位置するような、Webとも「書籍」ともカテゴライズできないコンテンツがでてくることに私自身は期待もしているのです。これについては一度以下のエントリで詳しく書いたことがあります。
「書籍」と呼ぶには短い電子書籍というコンテンツと従来よりちょっと長くなったWebというコンテンツの相対的な関係
 

【おまけ】ここであまり書かなかったこと

 このエントリでは「電子書籍的UI」の付与の仕方とその意義については述べましたが、「電子書籍的UI」についてはほとんど言及しませんでした。すでに長いこのエントリがさらに長くなるからというのが主な理由ですが、過去のエントリでも一度書いたことがあります。この長いエントリを読んだ後でもさらに読んでやろうという奇特な方がいらっしゃったら、一度お読みいただけると幸いです。
ぼくのかんがえる電子書籍リーダーのUI : 紙の書籍のUIを真似ただけでは足りなくて 
 

Webサイト化する電子書籍– HTML5電子書籍(2) –

 前々回はパッケージ化するHTML5電子書籍について紹介しました。そのエントリをご覧頂いた方からご指摘を頂いて、大幅な修正が2回入りましたが、そろそろ次の回ということで今回はWebサイト化する電子書籍について紹介してみたいと思います。
 

1. 「Webサイト化する電子書籍」とは

 この「Webサイト化する電子書籍」という言葉、これだけで理解できるほど自明なものとは思えませんのでまずは簡単に紹介します。
 HTMLコンテンツはHTML+CSS+JavaScriptで主に構成されます(CSSとJavaScriptは必須というわけではない)。例えば、以下のような構成のコンテンツがあったとします。読者にそれらを格納するフォルダごと渡して、その中にあるindex.htmlファイルを開いてコンテンツを読んでもらうという方法はいろいろと問題があるという話は前々回のエントリで話した通りです。
複数のhtml、css、JavaScriptを格納するコンテンツファイルのうち、index.htmlにアクセスする図
 ならばということで、前々回のエントリでは、パッケージ化して1つのファイルとして固める方法を紹介しました。今回は単純にいえば上のフォルダをパッケージ化もせずにそのままWebサーバーに上げてしまおうという話になります。つまり、やっていることはWebサイトをアップロードするのと全く同じです。読者にはURLを知らせて、そのURLからコンテンツへ誘導します。
前の図のコンテンツをそのままサーバーにあげて、index.htmlにアクセスさせようとする図
 コンテンツがWeb上に上げられると読者はURLを頼りにコンテンツを行き来することになりますので、そのコンテンツの構成をローカル環境ほど意識することはほとんどありません。さらにハイパーリンクによって他のコンテンツと行き来することも当然ありえますので、他とのコンテンツの境界線はかなり希薄になります。
 
 上の図では一例としてindex.htmlにアクセスしていますが、リンクを貼ることができるものであれば別に他のページでもかまいません。htmlディレクトリの中に001.htmlというコンテンツファイルが格納されているならば、直接、http://example.com/html/001.htmlというURLを指定して読者に誘導してもよいわけです。
 上だけだと、新聞社や雑誌社がコンテンツをサイトに掲載している従来のものとあまり変わりありませんが、さらに踏み込んでコンテンツに「電子書籍的UI」を付与し、読者にはWebサイトではなく、「電子書籍」を読んでいるという意識を持たせようと意図した動きが最近、見られるようになっています。
 
 そんな電子書籍コンテンツをここでは「Webサイト化した電子書籍」と呼ぶことにします。
 では、まずはWebサイトに「電子書籍的UI」を付与する方法から紹介したいと思います。
 

2.電子書籍的UIを付与する

 

treesaver.js

 treesaver.jsはHTML+CSS+JavaScriptでWebサイトを電子雑誌ライクなUIを実現するオープンソースのJavaScirptフレームワークです。
treesaver.js
http://www.treesaverjs.com/
  紹介動画を見ていただくとわかりますが、スマートフォンからデスクトップ版のブラウザまで様々なスクリーンサイズのデバイスに対応した電子雑誌なUIをもったサイトをつくることができます。

 
 2つのデモサイトが公開されています。

 

aside

 Web上に電子雑誌を公開することを提案しているサイトです。興味をもったら連絡しろぐらいのことしか書いておらず、利用する方法がよくわかりませんでした。個別に交渉なんでしょうか。
aside
http://www.asidemag.com/
  このasideのサイトそのものがそのサービスのデモサイトになっています。iPadで確認することができます。お持ちでない方も以下の動画でそのデモの紹介されていますのでご覧ください。

aside magazine Trailer from aside magazine on Vimeo
 
 ここまではどちらかと言うと「書籍」コンテンツをWebサイト化することを主たる目的としていますが、以下のCSS3ののGenerated Content for Paged Media Moduleは「書籍」コンテンツのWebサイト化に使うだけではなく、通常のWebサイトに「電子書籍的UI」を付与するために利用できそうな仕様になっています。 

CSS3のGenerated Content for Paged Media Module

 これはフレームワークではなく、W3Cが検討しているCSS3の仕様の1つです。プリントメディアの特徴をCSSを使用して実現することを目的としています。
CSS Generated Content for Paged Media Module
http://www.w3.org/TR/css3-gcpm/
 この仕様をブラウザが実装するようになれば、スタイルシートを指定するだけで、以下のような電子書籍的なUIを実現することができるようになります。

 
 といえ、この仕様はまだドラフトの段階で安定版のブラウザで実装しているものはありません。普通に使用できるのはもう少し先の話になりそうですが、Opera開発版では先行して実装されているので、それを使って試すことも可能です。
More fun using the Web, with getUserMedia and native pages – Dev.Opera
 このCSSを実装したデモサイトもすでに用意されています。上の開発版で訪問するとデモサイトに実装されたこの仕様を確認することができます。
Opera Reader: Paging the Web
※2012/6/18追記 
 先日公開されたOpera12でCSS Generated Content for Paged Mediaがサポートされるようになりました。
Opera の新機能

3.Webサイト化する電子書籍のメリット/デメリット

 AppleのApp Storeの審査がときおり問題になる現状を見ると、プラットフォーマーの意向に左右されずにすむことがWebサイト化の一番のメリットかもしれません。(HTML5に対応した)ブラウザがすべてそのコンテンツのビュワーになるわけですので、対応するデバイスが劇的に増えることになり、利用者層の拡がりも期待できます。また、コンテンツはサーバーで集中的に管理できますので、読者の読書環境を一元的に提供することも可能になります。
 しかし、一方でWebサイト化するならば、独自でサーバーを用意しなければなりません。場合によってはシステム開発も独自に行う必要があるでしょう。コンテンツを有料で配信するのであれば、その課金についてもなんらかの手段を用意しなければなりません。仮に用意できたとしても、サイトの無料化と有料化の間で揺れ続けている新聞や雑誌の動向を見ても、Webサイトの有料化は非常にハードルが高いと思われます。
 
 米国のPLAYBOYがウェブ雑誌としてWebサイトに移行しましたが、事例としてはまだまだ少ないようです。デメリットを勘案すれば、小規模なコンテンツプロバイダが既存のプラットフォームを捨てて、Webサイト化に移行するのはかなり高いハードルを乗り越えなけれなりません。当面はWebサイト化はブランド力をもった雑誌や大量の定期購読者を抱えているような雑誌、もしくは巨大なプラットフォームの間で行われるにとどまるかもしれません。
 しかし、一方で既存のWebサイトを例えば、iPadで見るときは「電子書籍的UI」で見せるといったWebデザインの延長として提供することは充分ありえることです。デバイスのインターフェイスにあわせて柔軟にUIを最適化させる、その最適化の手段の1つとして「電子書籍的UI」を組み込むということです。ブログや新聞、雑誌のようなテキストコンテンツが主となるWebサイトはその候補の筆頭だと思いますが、公的機関や大学、研究所がサイトで公開している報告書や広報誌もその候補になり得ます。また、メディアがサイトの有料化に踏み切る際に電子書籍的なUIを付与するという選択肢もありえるかもしません。 
 
 

iBooks Authorのibooks形式ってなんぞや– HTML5電子書籍余話 –

 先日の「HTML5電子書籍(1)」の続き、というよりも、(1)と(2)の間に入る余話になります。
 (2)を書いている途中であれの発表があったもので、そのまま続きを書いてよいものか調べておりました。それでせっかく調べたので、ということでまとめてみました。あのAppleの発表を実況サイトを追った範囲では、HTML5とJavaScritpばかりが強調されてEPUBには全く触れていなかった印象でしたからね。
というわけで、AppleのiBooks Authorです。

 

1. ibooks形式を作る

  まずはiBooks Authorでibooks形式の電子書籍を1つ作ってみます。といっても、ほとんどサンプルをそのまま使用したものにします。

 ファイル名は「ibooks_auhtor_test」にしました。スペルミスは一度笑ってスルーしてください。 
  
 このままサンプルをibooks形式のファイルとして書き出してしまおうと思います。
 「ファイル」→「書き出す」を選択すると以下のような画面がでます。

 ここで「iBooks」を選択するとibooks形式でコンテンツを書き出すことができます。
 
 
 これで、一応ibooks形式の電子書籍を作成できました。 
 

2. ibooks形式の中身を見る

 
 ではでは、ということで、ibooks形式の中身をのぞいてみたいと思います。
 
 拡張子のibooksをzipに変更して、そのzipファイルを解凍すればibooks形式の中を開くことができます。上で書き出したibooksファイルの中身を見てみると以下のようになっています。 

 中身を見ているとファイル構造そのものはほとんどEPUBです。コンテンツファイルがXHTML5で作成されたり、SVGや動画、音声ファイルに対応したりしているので、EPUBはEPUBでもEPUB2かEPUB3のどちらなんだろうかと迷うところもありますが、「ibooks.opf」ファイルがEPUB2のものなので、EPUB2かEPUB3かと言われると、EPUB2なのかなと思います。
とはいえ、
 
 トップレベルのディレクトリにある「minetype」ファイル(このファイルは〜形式であると宣言するファイル)には
 
application/x-ibooks+zip
 
とEPUBと異なるminetypeがしっかり定義されています。
 さらに各CSSの冒頭では

 
@namespace ibooks "http://www.apple.com/2011/iBooks"
 

と「-ibooks-」という独自の接頭辞が定義され、「-ibooks-」の接頭辞を持つibooks独自のプロパティが至るところで使用されています。
 
 つまり、ここまでの話を総合すると
 
ibooks形式=EPUB2をHTML5対応させて独自拡張したApple独自のフォーマット(読めるデバイスはiPadに制限)
 と言ってしまってよいかと思います。
 さらに@wakufactory さんが以下で紹介されているようにDashboardウィジェットというHTMLウィジェットで作成したウェブアプリを組み込むこともできます。
iBooks AuthorのHTMLウィジェットの作り方
 ウィジェットという形でウェブアプリを組み込めるならば、正直、使い方次第でもう何でもありになってしまいそうです。インタラクティブな機能はEPUB3の仕様が含有するそれの範囲を超えているのではないでしょうか。
 
 ちなみに・・・、なのですが、@commonstyle さんにお教えいただいたところによると、ibooks形式の拡張子を「.ibooks」から「.epub」に変更するとAdobe Digital Editions ver.1.72(ADE)では開けてしまうようです。
 実際に拡張子を「.epub」に変更して試してみると完全ではないようですが、一応、開けました。こういうところにEPUB由来を感じます。

 
 でも、ADEで開けても、肝心のiBooksでは開けないんですよね・・(レイアウトは崩れるが一応開けるEPUBビューワーはいくつか確認できました)。
 
 

3. ibooks形式のソースの編集する

 ところで、iBooks Authorで手軽に作れるのはよいとして、そのソースを直接編集できないのかという疑問も。
 上述のように中を開くことはできます。中のソースを直接編集してまたibooks形式に変換できるのかということですが、EPUBをベースにしているので、ibooks形式に固める方法もEPUBと同じ方法でいけるようです。つまり、以下のような感じで

$ cd ibooks_auhtor_test
$ zip -0 -X ../ibooks_auhtor_test.ibooks mimetype
$ zip -r ../ibooks_auhtor_test.ibooks * -x mimetype

と、minetypeファイルを除く形で圧縮をかけるとibooks形式のファイルに再度固めることができるようです。
 とはいえ、Appleの規約がそれを許すかどうかはよくわかりません(規約の拘束力がどれほどのものかも含めて)。
でも、一応、技術的には可能と。最も仕様が公開されないとどこまでいじってよいのかもよくわかりませんね。
 

4. itmsp

 itmpとはなんぞやですが、「ファイル」→「公開」を選択すると「itmsp」というファイル、というかいくつかのファイルを格納したディレクトリが作成されます。おそらくはiBooks Storeで公開する際に使用するものだと思います(未確認)です。
 今回の場合だと、「ibooks_auhtor_test.itmsp」というディレクトリが作成されるのですが、そのディレクトリには

 とibooksファイルとメタデータ、表紙画像が格納されています。メタデータと表紙画像はiBooks Storeの書誌画面として使用するんでしょうか(未確認)。メタデータと表紙画像は予め外部ファイルとして書き出されるですね。
  
 ここで終わってもよいのですが、 これを書きながら感じたことを余談として2つほど以下に書いてみます。そもそも余話であるはずのこのエントリに余談が許されるのかという問題はおいていて・・・

【余談 その1】 iPad上でEPUBは今、どこまでできるのか的な話

 iBooks上ではibooksもEPUBも同じWebkitを使用しているはず。EPUBにはさすがにHTMLウィジェットは組み込めないと思いますが、同じエンジンを使用しているならば、iPad上で読む限り、ibooks形式でできることはEPUBでもできるのではないかと思ったりします(未確認)。
 そう思わせたものが、米O’Reilly社から無料で公開されている以下の電子書籍(EPUB)です。 
 null
HTML5 for Publishers

By Sanders Kleinfeld
Publisher: O’Reilly Media
Released: October 2011
 この書籍では出版社を対象にしたHTML5の紹介がされているのですが、その中のCanvasの紹介で、お絵かきツールをEPUBファイルの中に組み込んでいたりするんですよね。一応、EPUB2なはずですけど。 

 仕様上はあまり推奨されませんが、iBooks上であれば、いろいろとできてしまいそうな気がします。
  で、同じWebkitを使用しているならば、全くとは言わないまでの、それに近いことはできるのではないかと(UIは除く)。
  時間があれば、ちょっと調べてみたいところです。
   

【余談 その2】 iBooksのEPUB3フル対応はいつなの?的な話(推測しか書いてません)

 
 ところで、iBooksのEPUB3のフル対応はいつなのかという問題ですが、Mobile SafariとiBooksがWebkitを(おそらく)共有している以上、iBooksのEPUB3へのフル対応はもう少し先になるかもしれません。
 EPUB3はW3Cの仕様としてまだドラフト段階のCSS3の仕様をいくつか組み込んでいます。EPUB3の仕様はすで確定し、その仕様には「-epub-」という接頭辞も用意されています。しかし、AppleはiBooksのためにだけにドラフト段階の仕様をiOSのWebkitに対応させる気がないのかもなあぁとこういうのいじってみて感じるところです。-ibooks-という接頭辞を用意して独自のプロパティを使用しているアップルさんではありますが。
 もしMoblie Safariと足並みを揃えることになるとしたら、iBooksのEPUB3フル対応はもう少し先になりそうですね。もう少しといっても次のiOSのアップデートまで、半年先とか長くて1年先ぐらいですが。
※2012/01/30 追記
iBooksはEPUB3にすでに部分的に対応しておりましたので、【余談 その2】を「対応」から「フル対応」へ変更しました。