当初、このエントリは「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を真似ただけでは足りなくて　
　

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

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

　この「Webサイト化する電子書籍」という言葉、これだけで理解できるほど自明なものとは思えませんのでまずは簡単に紹介します。
　HTMLコンテンツはHTML+CSS+JavaScriptで主に構成されます(CSSとJavaScriptは必須というわけではない)。例えば、以下のような構成のコンテンツがあったとします。読者にそれらを格納するフォルダごと渡して、その中にあるindex.htmlファイルを開いてコンテンツを読んでもらうという方法はいろいろと問題があるという話は前々回のエントリで話した通りです。

　ならばということで、前々回のエントリでは、パッケージ化して1つのファイルとして固める方法を紹介しました。今回は単純にいえば上のフォルダをパッケージ化もせずにそのままWebサーバーに上げてしまおうという話になります。つまり、やっていることはWebサイトをアップロードするのと全く同じです。読者にはURLを知らせて、そのURLからコンテンツへ誘導します。

　コンテンツが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をもったサイトをつくることができます。

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

• Nomad Editions’ Real Eats Sample Issue
• ICIJ Looting the Seas Investigative Report

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を付与するという選択肢もありえるかもしません。