Archive

Author Archive

青空文庫リーダー開発技術戦争

2月 7th, 2009

wakasaです。

今回は、青空文庫リーダーという確立されたジャンルと言って差し支えないアプリ群の開発技術とその競争について触れたいと思います。
※ここでは個々のアプリの紹介は控えます。

青空文庫とは、著作権の消滅した文学作品、著作権者からの許諾のある作品が並ぶインターネット図書館です。
そのデータを利用したビューアとして、iPhone内でどう展開させていくかというアプリ同士の競争が熾烈を極め、まさに開発技術戦争と言えるものでした。

日本語の「組み」は非常に複雑です。
ルビや傍点、傍線、加えて踊り字など、iPhone標準のAPIでは対応しきれない「組み」が出てきます。

青空文庫リーダーも最初は、横書きルビ無しという単純なリーダーという地点からスタートします。
複雑な「組み」は置いておいて、まずデータを取得し表示するという機能しかありませんでした。
長い作品を読み込ませても落ちないか、データの取得/解析にかかる時間はどのくらいかなど、安定性や処理の効率化での競争をしていました。

その競争に「縦書き」という武器を持って挑むものが現れたことが、転換期となったように思います。
この競争の勝者となる目標が明確に定められたのです。

文庫本のように


いかに文庫本のような「組み」に近づけるか、近づいたものが勝者たるというものです。
もともと紙であった作品のデータですから、再び紙に近づけたいという欲求は当然のものです。
しかし「縦書き」そして「ルビ」対応への技術力、これはデータを取得し解析して、いかに効率よく表示するかといったものとは、全く違うものを必要とすることは明らかです。
句読点や括弧といった約物は横書きと縦書きでは違ってきます。
句読点(、。)ひとつとっても位置さえ変わってきます。音引き(ー)や括弧は向きが変わります。
文中の英文の扱いも考えると、縦書きにすることで処理しなければいけない項目は飛躍的に増えていきます。

「縦書き対応」は高い技術力として、誇っていいそのアプリの「売り」となりました。

縦書きに追従し、いかにルビを正確にふれるか、禁則処理は正確か、「組み」へ挑むことが「売り」となり、その技術を競い合いました。
しかし、文庫本に近づけるという命題そのものには、その技術力「だけ」では超えられない壁が立ちはだかっていたのです。

フォントの呪縛


iPhoneには日本語フォントはゴシック体しか入っていません。
このゴシック体だけではどうがんばっても「文庫本のように」とはなりません。
文庫本はたいていの場合、明朝体の活字が使用されています。
約物をどう処理し、ルビをどこに出して、禁則処理はこうすると、計算上、数値上では近づいたが、表示に関しては限界が見えてしまった。
でも無いものは仕方ない、そう誰しもが思っていたかと思います。

そこにその概念を打ち破るように、今度はフォントをアプリ内に同梱し表示するという方式を持ちこむものが現れました。
この方式はかなり革命的だったと思います。
最初にこの方式を持ち込んだのは辞書アプリだったと思いますが、システムの制約を超える表現を得ることができる道筋を示しました。

このシステムに無いフォントを使うという方式が青空文庫リーダーにも採用されはじめます。
この革命的手法で一気に見た目を文庫本に近づけることができたのです。
一見した印象的なところでは、ほとんど完璧に近いと言っても過言ではないでしょう。
熾烈な競争は一気に日本語縦書き表現の技術を押し上げたのです。

文庫本との戦い


文庫本という目指すところがあったからこそ、ここまで辿り着けたのだと思います。
しかしその大いなる目標に近づくことには成功しましたが、残念ながらiPhoneは文庫本ではないことは明らかです。
近づくことができたからこそ分かることですが、単行本の持つ質感、量感、それらをiPhoneの中で感じることは不可能です。

フリックしてページを送ったところで、紙を1枚めくる質感にはとうてい敵うことが出来ません。
厚みという量感が無いのは、作品を読むインターフェイスとして致命的とさえ思えます。
ソフトウェア的に縦書きや明朝体の壁を崩していけても、そのハード面での壁は崩せるものではありません。

青空文庫リーダーというジャンルが次に持つべき目標は、電子書籍端末としてあるべき姿を描くことでしょう。
文庫本をいかに超えるか。今度は「文庫本そのもの」との戦いです。
頻出の単語のインデックス化など、作品の中身を動的に解析することなどは紙の文庫本では出来ません。
読んだ時間、ページをめくる時間、ユーザの取った行動を記録することもできません。
決定的な質感、量感という武器との差を埋め、超えることさえ出来る新たな武器の可能性は数限りなくあると思います。

次々と進化し続ける電子書籍端末はありませんでした。
日本ではハードウェアから押しつけの電子書籍端末はことごとく失敗しています。
(英語圏ではAmazonのKindleは成功しています。また、ケータイ小説を読む端末としての携帯電話は作品内容が特異としてここでは含まないこととさせてください)
iPhoneとAppStoreいうプラットフォームが電子書籍端末とは何を目指すべきなのか、それを探ることを可能にしました。

ソフトウェアでの競争が続いて行くのであれば、その何かはきっと掴めるはずです。
電子書籍端末の未来を描くことができる青空文庫リーダーに胸が躍ります。


青空文庫リーダー開発者の方々に敬意を表して。



文庫リーダー・「soRa」
文庫リーダー・「soRa」

青空本棚
青空本棚

iBunko
iBunko

SkyBook
SkyBook

wakasa 未分類

iPhoneDevCamp Japan 5月初旬開催

2月 7th, 2009

物理演算ライブラリBox2D公開

2月 3rd, 2009

物理演算ライブラリBox2DのiPhoneポーティングがオープンソースとしてsourceforgeで公開されています。
Rolandoなどを開発したHandCircus社のテストベットです。
iPhone port of Box2D Testbed now available


wakasa 未分類

RSSのリパッケージ 専用リーダーの展開

2月 3rd, 2009

エキサイトが一気に3本のアプリをリリースしました。
いずれもエキサイト内で展開するコンテンツの専用RSSリーダーです。
ITmedia専用リーダーの10万本突破などの成功を受けてのことかと思いますが、この流れは非常に面白いと思います。

情報を発信しているサイトでRSSを配信していないところはほとんど無くなりましたが、これを利用している層という面でとらえると、まだ多くがネット情報に長けているギークのものであり、『一般』での利用には至っていないのではないかと感じています。

RSSリーダーで購読しているギーク層にとっては、アイコンをひとつ余分に使うのも鬱陶しいというところかと思いますが、一般層にとってはこの専用リーダーとしてのリパッケージは意味のあることでしょう。

興味があるものをインストールして、読まなくなったら消せばいい。
このソリューションは、RSSリーダの設定をするという作業に比べ格段に『意味』が分かりやすいのです。

RSSリーダの設定のほうが楽だと言うのは、知っている人にとってはそうでしょう。
しかし「設定」するということはRSSというものがどういうもので、何をすれば何が得られるのかというそのものの概念から学ばなければなりません。
設定をするといことはそういうことです。
深いことまでは分からないまでも、これをこうすればこうなるということを知っていなければ「設定」はできないのです。

その人たちはRSSやそのリーダーについて知りたいわけではありません。
その発信されている内容に興味があるだけで、仕組みなどどうでもいいことなのです。

コンビニに並ぶ雑誌のように目についたものをその場で手に取る=インストールするというソリューションほど分かりやすいものはありません。

もともと他所での利用を想定していたはずのRSSを、自分のところで再利用しリパッケージして提供する。
自分が持っていたRSSにアプリというガワをつけるだけでリーチが延ばせるのならと、今後もいろんなところがアプリ提供してくることでしょう。

また、このエキサイトの専用リーダーは、広告のエリアを定位置に用意していました。
バナー広告のようなものが配置してあり、ユーザがクリックすることで全画面に拡大し詳細情報を提供します。
RSSの中に広告を含ませるという手法は以前からありましたが、エリアを設けるということはアプリにしかできないことです。
どちらがその効果が高いのか分かりませんが、新しいアプローチです。

ITmediaも3月から実験的に広告配信を行うようです。
いわば垂れ流しでロスリーダ的な側面のあったRSSを、どう利益を生む媒体に変えていけるかという面においてもアプリ化は興味深いところです。

wakasa 未分類

AdobeはiTunes AppStoreを崩壊させるか

2月 2nd, 2009

Adobe MAX Japan 2009 にてCTO ケビン・リンチ氏が、Flash for iPhoneについてコメントしたようです。
様々なデバイス上での展開を狙うFlash/Airにおいて、iPhoneの対応は必須条件であり開発中であるとのこと。


技術的なところに政治駆け引きが含まれるのかどうかは分かりませんが、Appleもいずれは乗せる決断を下さねばならない時がくるのではないでしょうか。


1)Appleの考える『フルブラウザ』とは、FlashLite(限定されたコンテンツ)しか見れないブラウザではない。
2)マシンスペック的に、Flashのフルバージョンを動作させるには厳しい。
3)Adobeが当然考えているであろう(iTunes AppStoreのような)SWFディストリビューション環境を持ち込まれてはAppStoreに悪影響を及ぼす。


など他にもいろいろな要因があって乗せないという決断に至ったと思います。
しかしながら、docomoが端末上でAirのデモンストレーションを行ったように他のスマートフォンは遅かれ早かれFlashPlayerを乗せてくるはずです。
Adobeも自分が抱えていた技術をオープンにし「標準」であろうと努力しています。

その波に押される形とはいえ、iPhoneのブラウザが『フル』を名乗るのであればFlashPlayerを乗せざるを得ない時がくるように思います。

1、2は時間が解決する問題です。
iPhoneの兄弟分であるiPodTouchの第2世代は1.5倍のスペックを持つと言われています。
iPhone3Gの第2世代は、同等それ以上のスペックを持ったものになることは間違いありません。
手の中でフルFlashを動かせるようになるのはそう遠い話ではないでしょう。



ただ3に関しては、Flashはもはやそれ自体が強力なプラットフォームですから、いったん乗せてしまえば、その進化を止めるができないというのが問題です。


HTML5のアプリケーションキャシュと連動させれば、SWFコンテンツをiPhoneAppと同様に使うことが可能になってきます。
現在でもWebAppと呼ばれるHTML5+CSS3で作られた、アプリと見紛うばかりのコンテンツが無償で提供されています。
経済的なエコサイクルの面で開発者がiPhoneAppに注力したため、iPhoneAppのほうが有利に働いていますが、そこにAdobeがエコサイクルを持ち込むとiPhoneAppの優位性は揺らいできます。


AppStoreはiTunesと連携したソリューションの絶対的素晴らしさはありますが、Object CとActionScriptでは開発者の分母が違います。
さらにFlashはプラットフォームに関係なく動いてしまう。デスクトップPCで使っていたものをそのままiPhoneで使えるようになる。
その世界にAdobeがエコサイクルを持ち込むことに成功すれば、開発者はそちらに流れてしまいかねません。
AdobeのSWFディストリビューション環境は、AppStoreの崩壊にもつながる強力なシステムなのです。


はたしてFlashはiPhoneに乗るのでしょうか。
AdobeはAppStoreを崩壊させるか。崩壊させることができるか。
Appleは守りきることができるのか。
両者の動向は目が離せません。


※こちら
http://www.itmedia.co.jp/anchordesk/articles/0902/03/news063.html
でも、同様の事が書かれていますね。

wakasa 未分類