年末年始に体調を崩して寝込んでいた時に何をしていたのかというと、この1年全く出来なかったソフトウェア関連情報の取得をiPod touchで見まくってキャッチアップしておりました。というのも客先では社外のネットに繋ぐ事が出来ず、更に僕はiPhoneを持っていないというかアレって要するに2年縛りで利用者にそれと気付かせずに借金をさせるシステムこそが携帯電話キャリアのうま味であり、そんなえげつない商売をしている孫正義が世のオヤジ共から高評価を受けているのは俺は日本のために投資してるんだとか言ってますけどそれってアホから金を盗んで自分が良いと信じている事に投資するという「義賊ねずみ小僧」的な貢献、という意味でのオヤジ共から高評価なのですか?
というわけで2年間で16万だかのお金をたかが携帯電話に掛ける事が出来ない低所得者の僕はテレビを付ければ芸能人のなんとかチャンがお薦めするiPad用ゲームベスト10はこれだ!みたいな王様のブランチが放送しておりまして、芸能人のなんとかチャンはついぞ「やっぱりOpenGL ES 2.0になってからのテクスチャサイズの拡大がグラフィックの進化をもたらしたわけでiPhone登場時に既にAndoroid系スマートフォンよりは上等なGPUを積んでいた事とJavaではなくObjective-CからCの世界への薄いラッパーを被せればゲーム開発者の勝手知ったるC+OpenGL開発の世界に変貌するのがゲーミングプラットフォームとしてのiPhoneの強みだったのでは」みたいな台詞は一切出ず、なんだかビートマニアの劣化版みたいなゲームで楽しそうに遊んでおりましたとさ。
今年から新聞を取らないウチがそれでも「ビューン」に慣れないのはそのアホな設計であり、おそらく誌面の1枚1枚をプログレッシブJPEGで送っている(確証なし)ものだから、以下の不満があります:
・容量が大きく、ダウンロードに時間が掛かる
・固定解像度以上には拡大できない
・JPEG特有のエッジがギトギトになる現象+固定解像度により、文字の認識率が悪い。固定解像度以上に拡大できない
・画像なので文字列の検索が出来ない
他にもいくつかiPhone系カタログアプリを落としてみましたが大同小異でした。
今でこそ搭載RAMが512MBのiPhone4/iPad2ですけど、ちょっと前までは256MB、更に前は128MBであったわけで、SafariからPDFを表示すると、ちょっと容量の大きいPDFならカンタンに落ちてしまうのが恐らく組み込み機器にPDFは荷が重すぎるのでこれは選択肢に入りません。
となるとHTMLで誌面を組んで行くのが一番になるわけですけど、「ビューン」がやりたいのは本屋で売っている紙の雑誌をそのまま電子版として読める、という一点であるので、これら新聞・雑誌の編集プロセスに「HTMLに変換」を加えなければ実現できません。Adobe InDesignの最新版には恐らくHTML5で書き出す、みたいな機能も付いているかと思われますが(確証なし) それですら完璧にレイアウトを再現出来るわけではないのでしょうから、多種多様な各雑誌編集部の誌面作成プロセスを統一する訳にも行かず、これからも「ビューン」はJPEG(か他の画像フォーマット)で送るしかないと思われます。
それでは紙媒体に囚われない電子専門の雑誌・カタログはというと、これは最初からHTMLで組んでしまえば問題なく、更に画像ファイルはJPEGでは既に容量が大きすぎ、Googleが普及につとめているWebPフォーマットがその代替になるな、とWebを見ていて思いました。画像のデコードも速いそうですし。
10年ほど前、JPEG2000なるフォーマットが、すわ、次のJPEGか!?と騒がれたものですがその後皆が黙ってしまったのは、その圧縮・展開の遅さだと思いますがiOS5になって今ごろWebKitがJPEG2000をサポートしたのはAppleが(Google主導の)WebPを推すわけには行かない政治的理由からだと邪推しています。
デジタルカメラがJPEG2000を採用しないのは、組み込み機器にとってJPEG2000のエンコードは荷が重すぎるようです。同様にiPhoneでもJPEG2000のデコードは、荷が重いのでは?
Microsoftが推している次世代画像フォーマットのなんとか(名前も忘れた)は、流行らないでしょう。あそこ、もう落ち目なので。
というわけでアプリ開発者の皆さまは勝手にWebKitでWebPを表示する仕組みを作ってしまえば、JPEGよりも40%容量を圧縮できる夢の世界、更には可逆圧縮にも対応しているのでGIFやPNGの代わりにもなる夢のフォーマットであると勝手に思っています。
HTMLは4だろうが5だろうが、本当は僕は嫌いです。「これからはHTML5だ」みたいな事を言わなければ葬り去られるのが今の時代ですけど、10年かけてオフライン動作や非同期通信やら、角丸エッジ程度で騒いでるんじゃねえよ未開人ども、と思ってしまうのはこれはアプリ開発者的視点であり、Webしか知らない若い世代にとっては革新的な出来事、らしいのです。更にはJavaScriptなんて、あの言語仕様でどうやって大規模開発するんだよ、と僕みたいなご隠居は、Netscape 2だか3だかの時代、画面下部に「現在の時刻は11時19分です」とテキストが流れる程度の小細工としてしかJavaScriptを認識していないので、アレですけど。更には僕らの世代はPCといえばWindows一辺倒であり、未だにAppleなどという邪道、外道、無道な企業の製品には触りません!という「信仰」をお持ちの、時代に付いて行けないロートル野郎がいますが一生やってろ未開人め葬り去られろ納骨してやる(以下100万行省略)。
しかしPDFが未だに組み込み機器にとって荷が重いフォーマットでありつづけている今、更にはJavaやらFlash(AIR)といったランタイム環境が当然ながらネイティブよりも遅いとなれば、消去法によりHTMLを選択するしかないのです。
電子カタログの最終的な目的はユーザーに物品を購入させる事でしょうけど、ここへきてAmazonを超えるEコマースシステムを作れ!と言われましても作れるものなら今ごろ僕が世界の小売り王になっている筈ですのでそれは無理として、もうちょっと、決済はクレジットカードといったEコマースと親和性の高いものを選択すると、認証にパスワードを要求したりして、こんなモン、昨日何を食べたか忘れてしまう僕の母親にとっては「パスワード」なるものを頭の中で生成するのもそれを記憶するのも荷が重すぎ、かといってiPadと接続する指紋認証機器といったものも無い現在、決済はオンラインでやらずにそこはアナログでやればいいんじゃないかなあと思ったり。
更には高齢者には「カート」って無理ですよ。コピー&ペーストもたぶん無理。脳内バッファが0KBの彼らは、画面に見えないものを記憶することができませんから。つまり画面上から彼らに「入力」させてはいけない。カタログは常にカタログとしての機能しか持たせない、と。
じゃあ商品の注文はどうするの?というと、そこはマークシートをプリンターから印刷させて、鉛筆で塗らせる。注文は?うーんどうしよう。スキャナーがあれば良いのだけどePrintの逆はできないし、紙のマークシートをカメラで撮影させてOCRで認識させちゃえば?無理か。本人確認の仕組みが無い。
ここ20年くらいの商売の目標は、PCを使えない最後の世代であるところの団塊世代にどうにかしてPCを使わせる事だと思います。