カテゴリー: 電子出版

パッケージ化されたHTML5電子書籍 – HTML5電子書籍(1) –

kzakza

　EPUB3の仕様が2011年10月に確定してから3ヶ月ほど経過して、作成ツールやEPUB3リーダーなどがちらほらと現れてきています。ちなみにEPUB3ビューアーについては、以下にすこしまとめた一覧がありますので、参考までに。
・ブラウザ・ビュアー – epubcafé
　
　しかし、あえて今回はEPUB3ではなく、HTML5電子書籍について、2回にわけて書いてみたいと思います。
　と・・・いいつつも、まずはEPUBの話から始めます。　
　　

1. EPUB3でインタラクティブな電子書籍

　EPUB2ではJavaScript自体を「実行するべきではない」とされていましたが、EPUB3になって、JavaScriptの利用が可能になりました。これによって動的でインタラクティブな電子書籍が作成できるようになります。　
　

2.4 Scripted Content Documents
EPUB Content Documents may contain scripting using the facilities defined for this in the respective underlying specifications ([HTML5] and [SVG]). When an EPUB Content Document contains scripting, it is referred to in this specification and its sibling specifications as a Scripted Content Document. This label also applies to XHTML Content Documents when they contain instances of HTML5 forms.
from EPUB Content Documents 3.0

　
　ただし、EPUBは様々なデバイスで読まれることが想定されています。例えば、デスクトップのような、何でもできてしまうデバイスから、iPadのようなタブレット型ＰＣ、サイズの小さいスマートフォン、そして、E Inkのような電子ペーパー端末まであります。特に動画に強い液晶と異なり、動的なコンテンツに弱い電子ペーパー端末はインタラクティブなコンテンツに向いているとはあまり言えません。また、全てのEPUBビュアがJavaScriptに対応しているわけではないのです。
　そもそも・・・
　EPUB3の仕様ではEPUBビュアーのJavaScriptのサポートはオプション。
なのです。
　ですので、仕様の上でもすべてのEPUB3ビュアーがJavaScriptに対応するとは限らないのです。　
　JavaScriptによる動的でインタラクティブなコンテンツの作成する場合でも、JavaScriptに対応していないビュアーでもそのコンテンツが読める範囲内で使用しなくてはなりません。JavaScriptが使用できないとコンテンツが全く読めないとか、コンテンツとして意味をなさないといったものはEPUB3の仕様上認められておりません。
　　
で、ここからが、ようやくこのエントリの本題です。
　
　そういうわけで（かどうかはわかりませんが）、より自由に作りたいという動機からEPUBではなく、HTML5で電子書籍を作ってしまおうという動きがちらほらと米国を中心に見られるようになりました。
　
　この動きを大きく分けると以下の２つの動きに分けられると思います。

  • HTML5で作成したコンテンツをアプリケーションとしてパッケージ化
  • Webサイトの電子書籍化　-Webサイトとの境界線が曖昧化するパッケージメディア-

　このエントリでは1のHTML5で作成したコンテンツのパッケージ化された電子書籍を紹介します。2のWebサイト化の話は次のエントリで紹介しようと思っております。　
　

2. パッケージ化されたHTML5電子書籍

　HTML5コンテンツはHTML5+CSS3+JavaScriptで構成されます。もう少し具体的に言えば、Webサイトなどで公開されているHTMLで作られたコンテンツもhtmlファイル、css、JavaScriptで構成されるファイル群です。これらを全て1つのフォルダに入れることでコンテンツとしては一応成立します。
　とはいえ・・、例えば、以下のような構成のコンテンツがあったとして、読者にはその中にあるindex.htmlファイルからアクセスしてもらって・・・となるわけです。
複数のhtml、css、JavaScriptを格納するコンテンツファイルのうち、index.htmlにアクセスする図
　これは厳しい・・。少なくとも私は気分が萎える・・・
　読者が必要のないファイルをうっかり開いてしまう可能性も高く、コンテンツのソースを変更してしまって読めなくなってしまう可能性も低くありません。そもそもこの状態では権利保護のへったくれもありません（あ、でも、不可能ではないのか。）。
　そういうわけですので、コンテンツを配布するにはやはり以下にように1つのファイルとしてに固める必要があります。
前の図のコンテンツをアーカイブファイル化して1つのファイルとして扱えるようにした図
　1つのファイルとして固める。
　読者にはファイルの中身を意識させない・いじらせない。
　
　EPUBやKindle形式のようなフォーマットも、おおざっぱな見方をすれば上のようにhtmlファイルなどを固めたパッケージ用フォーマットとして見ることができます。
　EPUBやKindle形式のようなフォーマットとして固めるのではなく、HTML5として固める方法として、以下の２つを少し詳しく紹介します。

  • ネイティブアプリ化
  • ウィジェット化

　
　

2.1. ネイティブアプリ化

電子書籍をネイティブアプリ化することでパッケージ化する。つまりはアプリ版の電子書籍をHTML5で作るということです。iOSやAndroidのApp Store経由で流す場合はそれぞれのOSにアプリケーションとしてインストールすることになります。
ビュアーアプリを必要とせずに、単体でコンテンツを読むことができます。コンテンツと一緒にそれを読むためのビュアーアプリも一緒にバンドルされているというイメージになります（正確にはそのデバイスのもつレンダリングエンジンを使用すると思われるので、すべてがバンドルされているわけではない）。
　しかし、ネイティブアプリを作成する場合、たとえば、スマートフォンやタブレットPC向けに作成しようとすると

  • iOS: Objective-C
  • Android: Java
  • Windows Phone: C#/VB

という感じでプラットフォームごとに別々の言語を使用しなくてはなりません。
　ちょっとそれはやってられない・・・という方のためにPhoneGapというフレームワークがあります。

PhoneGap
　
　HTML+CSS+JavaScriptで開発したアプリケーションをネイティブアプリケーション化するフレームワークです。ネイティブアプリ化させることができるだけではなく、様々なプラットフォームに対応させることが可能になります。現時点ではWebアプリではアクセスができないデバイスのネイティブな機能にアクセスするAPIも多く提供していますので、カメラをつかったインタラクティブな電子書籍などもつくることができるようになります。　

Supported Features « PhoneGap
　　
また、これはiOS専用ですが、Bakerという電子雑誌用のフレームワークもあります。

Baker


Baker Ebook Framework 3.1
・HTML5ベースを使った電子書籍フレームワーク「Baker」 – MOONGIFT
簡単にいうと、Xcodeのプロジェクトです。コンテンツをいれるbookディレクトリ以外はすでに用意されているので、このbookにコンテンツファイルであるhtmlファイルやcssなどをいれてやり、コンパイルすればそれだけでできる。
<img src=”https://code.kzakza.com/wp-content/uploads/2012/01/baker1-e1326375184227.png” alt=”XcodeでBakersを展開している図” title=”baker” width=”450″ height=”442″ class=”shadow” size-full wp-image-1331″ />
　
上のBakerをさらに利用したLakerというフレームワークもあります。より動的でインタラクティブなものがつくれるようになっているのでしょうか。デスクトップ用ブラウザでも見られるコンテンツの作成も実験的にサポートしているようです。

Laker


Laker
・jQueryやHTML5を使ってiPhoneやiPad向け電子書籍を作成する為のフレームワーク・Laker – かちびと. net　
　
　電子書籍をネイティブアプリとして作成するメリットとデメリットは以下になるかと思います。　

メリット

・1つのファイルとしてパッケージ化できる。
・iOSやAndroidのApp Storeなどのプラットフォームにコンテンツを配信し、有料化することができる。
・PhoneGap等のフレームワークを使用すれば、ハードウェアの機能にアクセスすることができる。
　

デメリット

・ネイテイブアプリなので読者に「インストール」という「読書」にあまりふさわしくない行為をさせてしまうことになる。
・プラットフォーマーの意向に左右されやすい。
・プラットフォーマーに支払う手数料のコスト
・永続性の問題(プラットフォームのOSのバージョンアップをいつまでもサポートできるのか)
　
　既存のプラットフォームに乗せて課金ができる、コンテンツを有償で配信できるというのは、コンテンツプロバイダにとってなによりの利点かもしれません。デメリットのプラットフォーマーの意向に左右されやすいというのは、その利点の裏返しとも言えます。パッケージはしたいけど、プラットフォーマーの意向には左右されてたくないぞぉという人にとってはウィジェット化という選択肢もあります。
　
　

2.2. Webウィジェット

　ウィジェットはアプリ化と同じでHTML5+CSS+JavaScriptを一つのアプリケーションとして固めたものです。W3Cでかなり検討が進んでおり、ほぼ固まったと言える状態です。
・Widget Packaging and XML Configuration（勧告）
・Widget Interface（勧告候補）
・XML Digital Signatures for Widgets（勧告案）
　これらの仕様の詳細については以下のIBMの解説が詳しいのでこちらをご覧ください。
・W3C ウィジェットの構成とパッケージ化
　
　現在、どのブラウザがWeb Wedgetに対応しているかは私が調べた範囲ではよくわかりませんでしたが、Operaは対応しているようです。あと、iOSアプリのCloudReadersもWidgetをサポートしているらしいです。
・Opera: Widget packaging and configuration support in Opera Presto 2.7
　ただし、上で紹介したIBMの解説でも紹介されていますが、HTML+CSS+JavaScriptをパッケージ化するウィジェットがすでに複数のプラットフォーマーから提供されており、W3CのWeb Wedgetで一本化とはなかなかすぐにはいかないのではないかと思われます。
　

2.3. その他

その他、以下のようなフォーマットも存在します。ブラウザが主にサイトを一纏めにして保存する際の使用されるようです。

    　

  • MHTML形式（Firefoxはプラグインが必要になるが、他の主要なブラウザでは読むだけなら対応しているらしい。）
  • webarchive形式 (Safari)

WARC(Web ARChive) は違いますよね・・。　
　
　
　ウィジェットが選択肢になるのは、もう少し先になるのかなと思います。ただし、プラットフォーマーに左右されずにパッケージ化できるという点では非常に魅力的な方法であると思われます。一本化されるのがW3Cの仕様かどうかは分かりませんが、いずれはまとまるのではないかと思います。そうあって欲しいですね。　
　
　プラットフォーマーの意向に左右されたくない。しかし、Wedgetが使用できるのはまだ先かというところで、いっそWebサイトに移行してしまおうという動きも見られるようになっています。これについては、また次のエントリで紹介します。
　
　
※2012/01/11訂正
当初、このエントリはパッケージ化の手段としてネイティブアプリ化のみを紹介しておりましたが、W3C Webウィジェットの仕様やMHTMLなどについて、HTML5コミュニティ、EPUBコミュニティ、Twitter上でお教えいただきました(ありがとうございます！)ので、構成を変更してWebウィジェットなどの紹介も追加いたしました。
※2012/01/12訂正
Objective-Cを使わずともHTML+CSS+JSだけでXcodeを使ってiOSのネイティブアプリが作れるかもと書いていましたが、HTML+CSS+JSだけではできないと神崎渉瑠さんよりコメントにてご指摘を頂きましたので、「ネイティブアプリ化」の項を修正・加筆書しました。。そもそもiOS SDKも必要ではないか（ツッコミ）。その件をご指摘くださった神崎渉瑠さんのコメントも合わせてお読みいただけると幸いです。

Amazonの電子書籍の貸し出しサービスについて少し・・

kzakza

　まずは私の妄想から・・・。

  1. 借りた電子書籍をダウンロードできてローカルで読める。
  2. 借りた書籍には下線やコメントやその他もろもろなことができる。
  3. 返却。
  4. また借りる。
  5. 前回借りた時に引いた下線やコメントなどが表示される。そういった情報はクラウドで保存されているので。
  6. 自分が引いた下線やコメントやその他諸々は非公開にして自分だけが見られるようにすることはもちろんのこと、特定のグループに公開範囲を限定してグループ内で共有することも、全利用者に公開して共有することができる。ここでいう公開は他の人が読書中にその本文に自分の引いた下線やコメントなどが表示されること。
  7. グループはプラットフォーム内にいくつも作ることができ、利用者は複数のグループに参加することができる。読んだ本の下線、コメントなどの公開範囲も利用者は各グループごとに柔軟に設定することができる。

　つまり、読書をキーとしたSNS的なサービスなのですが、こんなサービスどうでしょうか。ゼミで共有したり、勉強会で輪読したり。こんなSNSなサービスを図書館が提供したら面白いと思っていました。以前、他のブログで少し触れました。
・電子書籍をテーマにこんなソーシャルなWebサービスはつくれないか。 | e-chuban blog
　しかし、Amazonが1から５までやったちゃいましたねぇ・・・。6以降も時間の問題か・・。
・hon.jp DayWatch – 米Amazon、電子書籍の貸し出しサービス「Kindle Owners’ Lending Library」を開始。月1冊、無期限で
　一定の会員料を払えば、コンテンツが使い放題的なサービスは結構ありますので、こういうサービスを展開すること自体は全く不思議ではない。もともとAmazonが提供するKindle Storeは電子書籍を販売するというよりもサービスを提供するという側面が強いなぁと思っていましたが、それがいよいよ強くなってきた感じがします。
　
　読者が引いた下線やコメント、そして、今回触れなかった他の書籍に対する参照情報（具体的にいうとリンクです。ハイパーリンク。他の書籍の本文に対するハイパーリンク）などはクラウドに依存せざるをえないものなのかという問い対する答えは私の中ではまだ出ていません。もし依存せざるを得ないなら、ソーシャルリーディングも学術情報に必須の参照も巨大なプラットフォームありきになってしまうのではないかという気もしますが、そうなるとプラットフォームごとにコンテンツが分断されて悲惨なことにならないようにきちんと関連する仕様や標準をつくっておく必要があるのではないかと思います。
　巨大なプラットフォームに依存しない方法で実現できる仕組みはないのか！という問いを投げかけたところで今日はおしまいにします。データの保存と共有を巨大などこか一箇所に依存しない形できないものか、そういうWeb標準な仕組みは検討されていないものかと。以下はやや関連がありそうで面白そうですが、どうなんでしょうね。
Unhosted: separating web apps from data storage
http://unhosted.org/　
　

ぼくのかんがえる電子書籍リーダーのUI : 紙の書籍のUIを真似ただけでは足りなくて

kzakza

　ファミコンが子どもの心を鷲づかみにしていた時代に誰しもノートに書いた「ぼくのかんがえるゲーム」。そんなノリで電子書籍リーダーのUIについて書いてみます。
　まず現状から申し上げると、iPadなどのタブレットPCがで利用できる電子書籍リーダーアプリのUIはほとんどが以下のような感じです。
iPadのiBooks UI
iTunes App Store iBooks　より
　基本的に紙の書籍のUIをベースにしているわけですが、
　
正直、いろいろと足らんと思うのです。　
　
　例えば、ですが・・

  • 複数の本を同時に開けない。
  • 複数のページを同時に開けない。
  • 上の２つと関係しますが、複数の本やページを見比べることができない。
  • ページ間の遷移が酷く面倒。19ページから67ページに移動とかそんなピンポイントな移動は「無茶言うな！」という気分になる。
  • 今日はあと一区切りでとおしまいにしようとか思っているけど、その一区切りがどれくらい先か、数値による表示はあるけど実際のところようわからない。←さすがに言いがかりか？
  • ブックマークとかしおり機能とか沢山つけてしまうと、後で使おうと思っても一杯になって整理も「はぁ、もうめんどくさい！」←ものぐさですいません。

　
　とかとかいろいろと不満がでてくるのです。本文と注を行ったり来たりする学術書は結構辛い、というわけで、電子書籍にあるべきUIとは何かについては、たまにいろいろと妄想したりするのですが、こんなUIどうでしょうということで、少し書いてみました。　
　

○複数の本やページを同時に開く

　ブラウザのタブのようなUIはどうでしょう。こんな感じで同時に開いてタブでコンテンツの表示を切りかえるのです。
ウエブブラウザのようにタブで同時に複数のページを開く電子書籍のUIの図。この図ではタブを4つ開いており、うち2つは同じ書籍の異なるページ、のこり2つは別のタイトルの書籍のページをそれぞれ開いている
　同じ本の複数のページはもちろん、複数のページを同時に開きます。タブを切り替えるとこんな感じで。
最初の図のタブを切り替えた図。タブを切り替えることで前に開いていたページを保持しつつ別のページを閲覧できることを示している。
　

○複数の本やページを同時に表示する

　電子書籍の大きな欠点は複数の書籍を同時に開いて見比べることができないことです。本ならば並べて見比べることもできるんですが。電子書籍でもやりたいですよね。EPUBやmobiはリフローでデバイスのサイズの制約をあまり受けません。だからiPadでもスマホでも読めるわけですが、ならばこんな感じで同時に表示させていはいかがでしょうか。一方はスマホサイズで表示させるとか。
同じ画面上で複数のページを同時に表示した図。ある本を読みながら、別のページを参照したいという場合の同時表示なので、後者についてはやや狭い領域に表示されている
　

○さっき見たページを行ったり来たりしたいんですよ

　ということで、以下のようなどこかでみたことのあるボタンは必要ですよね。履歴を使って行ったり来たりと。すでにこの機能も備えているものもあるようですが、Webブラウザと比較するとまだまだおまけという感じが拭えません。
ブラウザの戻るボタンと進むボタンに似たボタン
　
　このボタン、次で述べる検索機能が実現するとより重要になってきます。検索結果を行ったり来たりしなければなりませんので。

○目次だけでは足りません

　電子書籍の中を自由自在に動くにはパラパラとページを順番にめくったり、目次からリンクをたどって飛んだ行ったりするだけでは全然足りませんので、やはり以下のような検索機能は必須だと思います。目的地にはずばっと行きたい。
検索窓の図
　すでに上のような検索窓は現在の電子書籍リーダーでも備えています。しかし、WordやPDFリーダーの検索機能のようにヒットした結果を順番に見ていくという本当にただのテキスト全文検索なものが多くてあまり使う気になりません。
　検索といったら、やはり以下のように検索結果を一覧してほしい。できれば、読者にとって重要な順番で、というと曖昧ですが、線やコメントつけたものを上位に上げる、すでに読んだ部分を上位に上げる、逆に未読な部分を上位にあげるとかいろいろあると思うんです。今読んでいる箇所に関係が深い順とかでもいい。もっとソーシャルでもいいし、PageRankでもいい。
Googleライクな本文の全文検索結果一覧
　ちなみに上では今開いている本の検索結果を一覧していますが、同時に今開いている本やライブラリに登録されている本を検索してくれるとさらに嬉しい。上の図でもアンダーラインに靑地とかで表示してそれっぽく見せていますが、リンクが貼られて自由に検索結果を行き来できるとよいですね！
　
　

○電子書籍でパラパラページめくるのとか厳しいのでスクロールできるようにしてください

　紙の書籍だとページをぱらぱらめくりながら、内容をざっと確認しつつ、目的のページに移動とか簡単にできますが、全く同じことを電子書籍でやるのはビジュアル的にはともかう、実用的ではないと思います。それで、紙の「ぱらぱら」の代わりにスクロールはどうでしょうかと。
　
　コンテンツの遷移の方法にもいろいろありますが、ここではスクロールとページングの２つを比較してみたいと思います。完全に主観ですが、この２つ、こんな違いがあるんじゃないかと。
・スクロール
　コンテンツの内容を確認しながらすばやく遷移することができる。しかし、スクロールするとコンテンツ全体が動くので、次に目で追うべき文字を一瞬見失う、もしくは見失わないような注意が必要になる。コンテンツを遷移する度に感じる小さなストレスは長い文章をじっくり読みたい時には堪えるかもしれません。しかし、まるごとコンテンツが入れ替わるページングと異なり、少しずつコンテンツが遷移していくので、コンテンツの前後の確認がしやすいことは大きな利点です。
　段落の間は空けましょうとか、フォントサイズに強弱つけるなどのWebならではの文章作法はスクロールしながらでの読みやすさを追求した故かもしれません。　
スクロールによるコンテンツ遷移の図　
・ページング
　ページングとはコンテンツを1ページ単位で分割して表示する方法です。つまり、1スクリーン単位でコンテンツを分割し、次のコンテンツに遷移する場合は今表示しているコンテンツと続きのコンテンツとまるごと入れ替えることになります。コンテンツの次の開始点が縦書なら右上、横書なら左上と決まっているのでページが切り替わっても次に目で追うべき文字を探す必要がないので、スクロールで感じるようなストレスはあまりない（はず）。長文をじっくり読むことに向いていると思います。
ページングによるコンテンツ遷移の図
　iPadのInstapaperアプリがスクロールとページネーション、どちらも使えるようになっているのでiPadをお持ちの方は試されると面白いかもしれません。
　　
　つまり、

  • じっくり読みたいときはページング
  • 紙の本のようにパラパラ内容を確認しながらすばやくコンテンツを遷移させたい場合はスクロール

がよいのではないかと。だから、電子書籍リーダーには両方使えるようにしてほしいと思うのです。　
　
　
　

○現時点でのまとめ

　つまり、これまで上げたUIについてまとめると　

  • ブラウザのUIを取り入れてください。　
  • Webのナビゲーションも取り入れてください。

となります。こういうことを書くと、　　
　
　
電子書籍はいずれWebに吸収されるとでも考えているか
　
　
とか言われそうですね。しかし・・
電子書籍がWebに吸収されるという考えを持っていると思われるのは私の本意ではありません。Webも電子書籍も今後、その有り様から変わっていくだろうと考えていますので、どちらか一方がそのまま残って片方を吸収するということはないのではないかと考えています。
しかし、UI的には電子書籍はブラウザやWebに学ぶところが多々あるはずです。紙の書籍と電子書籍とUI的観点から比較して今でもはっきり言えることは、　
　
電子書籍には物理的なUIがない
　
ということです。　
　紙の書籍には本の厚さ、紙質、本の重さ、さらにいうとコンテンツに特化した装幀などがあります。コンテンツに直接触ることができるUIを持っているのです。それを前提としての紙の書籍のUIなのですが、電子書籍にはそれがありません（紙の書籍のUIについては一度別のブログで書きました）。電子書籍はナビゲーションを1つのスクリーン上で実現しなくてはならない。物理的なUIを持つ紙の書籍のUIを真似てはいろいろと足りないというのはそういう理由です。
　物理的なUIは使えない、1つのスクリーン上で全てを実現しなくてはならないという点ではWebも共通しています。ならば、そのWebの閲覧ソフトであるブラウザ、そしてコンテンツであるWebには学ぶべき点は多いのではないかと思うのです。Webブラウザは1つのスクリーンですべてのナビゲーションを実現しなければならないという制約下で20年以上試行錯誤してきたわけですから。　
　

※上の図で書籍の本文の一例として使用させていただいた書籍

・河口慧海『チベット旅行記』（青空文庫）より
・宮本百合子『しかし昔にはかえらない』（青空文庫）