Blogger で作ったブログを iOS デバイス対応にする

このブログを iOS デバイスに、とくに iPad に対応させようと試行錯誤を始めたのが 8 月の下旬。そろそろ一ヶ月になるが、ようやく iPad を中心に一群の iOS デバイスに対応させる作業が完了した。新しい iPod touch (→ 第4世代になるらしい)でも確認したから Retina ディスプレイを備えた世代のモノでも大丈夫だ。

デバイスを切り替える方法の調査から、スタイルシートを Blogger の外部に置く方法の調査やら考察に進み、Google App Engine (以下、GAE) を使う方法に気付く。さらには GAE アプリでスタイルシートを切り替える方法を採り、今に至っている。

細かなことになるが、Google Font API を試したことや、iPhone シミュレータを使って iOS デバイスでの見た目を確認することを思い付いたり、Redmine でプライベートな問題追跡を始めたのも、この作業の中でのこと。

ま、一番の苦労は、Blogger の(複雑な)テンプレートとの格闘だったけどな。ちなみに、そこでは Safari の「開発」メニューから起動できる「Web インスペクタ」が大活躍だった。これなくして、Blogger のテンプレートから生成される HTML の解析は困難だったろう。ましてやスタイルの定義は不可能だったに違いない。CSS によるスタイルの定義が、どう適用されているかの表示は、Blogger のスタイルを上書きするために、なくてはならないものだった。Safari、バンザイ ヽ(｀д´)ノ。

もっとも、Firefox にしろ、Chrome にしろ、最近のブラウザでは似たような機能は利用できるみたいだけどね。

スタイル定義における基本方針

多少、ブレたりもしたが、最終的には以下の方針に落ち着いた。

1. iOS デバイスに対応する
2. iPad (横向き)を基本サイズにする
3. iPad (縦向き) はサイドバーを表示しない
4. iPhone は向きに関係なくサイドバーを表示しない
5. Mac 以外のデバイスでは通信量を考慮に入れる

作業を始めた当初は、iPhone の横向き 480px を、iPad の縦向き時のメイン領域にして、サイドバーも表示させようと考えていた。しかし、これだと iPad の向きを変えたときに、一行に表示されている文字数が変化してしまい、見づらいことがわかった。これを避けるため、縦向き時と横向き時のメイン領域の横幅を同じにしたい。かといって、サイドバーがあまり細くなっては、これまた中身が見づらい。悩んだ末、縦向き時にはサイドバーの表示をあきらめた。結果として、サイドバーが見たければ向きを変えるというユーザ体験を導入したことになった。

デバイスの向きを変えるとメニューの類が表示されるというユーザ体験は、iPad 標準アプリの「メール」や「メモ」などのものに少し似ている。

メイン領域

iPad で縦向き時にはサイドバーを表示させないので、画面幅 768px はすべてメイン領域の表示に使う。そして、横幅 768px をこのブログでの基本幅とし、Mac 向けのスタイルでもそのまま適用する。

一方、iPhone に最適化する際は横向き 480px での表示を基本とし、縦向きでの見た目は最低限の調整に留めた。なので、iPhone でこのブログを見るときには、なるべく横向きにして見てほしい。

サイドバー

メイン領域が 768px だから、サイドバーは iPad の横向き時の幅からメイン領域を除いた部分に表示する。つまり、1024 - 768 = 256 で 256px になる。

メイン領域と同じく、サイドバーの幅 256px も Mac 向けスタイルにもそのまま適用する。

Mac 向けのレイアウト

iPad の横向き時と同じレイアウトになる。縮尺は正確ではないけれど、27 インチ iMac で表示させた場合、横幅 768px + 256px は、だいたい左図のようになる。

ちなみに、Mac 上の Safari で 1024px のウェブページを表示させるにはウィンドウのサイズを 1040px にすると良い(→ AppleScript を使って URL を Safari のタブで開く)。余分な 16px はスクロールバーの分だ。

通信量に対する考慮

大した量じゃないという気もするのだが、Google Font API を使うのは Mac のみとした。

そもそも、iPhone の場合で、common と iphone の 2つ CSS ファイルで約 18 KB ある。通信量のことを気にするなら、これ自体も十分ムダだよな。

まとめ

Retina ディスプレイ搭載の iPhone 4、iPod touch (4G) への対応に少し不満が残っているものの、ほぼ満足行くスタイルに仕上がった。iPad や Mac で見たときはもちろん、iPhone で見ても、コンテンツを見る分には十分だ。

サイドバーをふくめたナビゲーション全般で改良の余地はあるけれど、HTML と CSS でやれる範囲はここまでだろう。この先は、JavaScript の活躍する領域になる。ただ、Blogger のテンプレートとの格闘には良い加減疲れたので、これ以上手を加えることはないと思う。スタイルのバグ修正や、ちょっとした新スタイルの追加はするけれど。

むしろ、Blogger は記事の投稿だけに使って、記事を見るには別のアプリやウェブアプリを使う方が良いんじゃないか、と思い始めている。先のナビゲーションの改良なんかもやりやすい。特定のブログを表示するためだけの iPhone アプリがあっても良いじゃないか。ブログシステム全体を作るのは大変でも、見るだけに特化するなら HTML + CSS でやることの延長として考えられる。

関連リンク

• iPod touch (Wikipedia:ja)

関連記事

• ウェブページのスタイルを iPad に最適化する方法
• 外部ファイルの置き場所を求めて…
• 外部ファイルの置き場所としての Google App Engine
• GAE アプリによるスタイルシートの切り替え
• Google Font API を使ったフォントの表示
• iPhone シミュレータをウェブページの作成に活用する
• プライベートな問題追跡システムが欲しい
• Retina ディスプレイ搭載の iPod touch

twitter より (2010-09-20)

• 00:39  ふうむ。ウチの iTunes のミュージックライブラリは 21.9 GB になっている。落語を除いてこれだからな。
• 01:39  なんだ。HDR はやっぱり iPhone 4 専用か。iPod touch (retina) じゃダメなのか (´・ω・｀)
• 02:14  iPod touch、ケースはいらないけど、アンチグレアフィルムはやはり必須だな。旧モデル用のはサイズが合わないだろうし。パワーサポートが出してくれるのを待つしかないか。

Powered by twtr2src.

フリー ([著]クリス・アンダーソン, [版]NHK出版)

フリー―〈無料〉からお金を生みだす新戦略

クリス・アンダーソン
日本放送出版協会 ( 2009-11-21 )
ISBN: 9784140814048
おすすめ度:

物読みファイル (別館)で詳細を見る

MediaMarker

ぼちぼち読み進めてきて、もうじき読み終わる。改めてフリー(自由と無料)について考えさせられる内容だが、衝撃としては同じ著者による「ロングテール」ほどではない。正確に言えば衝撃を受けたのは「ロングテール」という本を読んだときではなく、ネットのどこか(誰かのブログだったのかな)でロングテールという言葉とその意味するところを知ったときだったけど。

フリーとフリー

英語の free という言葉は 2 つの意味を持つ。日本語ではそれぞれ「自由」と「無料」と訳される。著者はこの言葉をその語源から探り、2 つの意味をそれぞれ「奴隷からの自由」と「費用からの自由」と説明している。通常、ヒトが自由と口にするときは前者を意味する。もちろん、無料と言ったときは後者の意味になる。著者は、本書で扱うのは後者「費用からの自由」なのだ、と明言している(p.28)。

確かに、free と言う言葉が混乱を生む可能性があることは、21 世紀に生きるプログラマなら誰でも知っている。いや、20世紀の終盤を生きたプログラマなら、かな。ともあれ、free を語るとき、自らがどちらの free を念頭に置いているかを表明しなければ、誤解を生むことになりかねない。人は誰しも自分の立場で理解し、考えるからね。

一方で、本当に「奴隷からの自由」と「費用からの自由」を分けて考えられるのだろうか、っていう疑問もあるんだけどね。

フリーの形

なぜフリー(無料)が成立するのか？ 著者はそれを 4 つの形に分類している。

1. 直接的内部相互補助
2. 三者間市場
3. フリーミアム
4. 非貨幣市場

いかつい単語に幻惑されるが、それぞれの説明を聞けばどれも馴染みのあるものばかりだ。

1. は何かをとんでもなく安く(無料)にして、他の高い物を買わせる、という方式。スーツの量販店で 2 着目は無料です、と言われるアレだ。単純に言って、安い(無料)の方の価格が、そうでない方の価格に上乗せされているだけのものだ。

2. は TV の放送(と CM )でお馴染みだ。報道番組であれ、バラエティであれ、ドラマでも映画でも、無料で見られる代わりに CM を見せつけられるというやつだ。

3. は最近のネットサービスで多い。RTM も Evernote もみんなこの方式を取っている。金を払ってくれるヘビーユーザ(またの名を信者)のおかげで、それほどでもない一般ユーザは無料で使うことができる。

4. は...。フリーの形としては実はこれが一番重要なんだが、一番わかりにくいものでもある。言葉にすると、金銭とは別の形で支払っている、となる。けれど、この言葉ではとうていすべてを言い尽くせてはいない。本書でも第12章を丸ごと、この「別の形」で支払うことについて解説してくれているが、納得できないんだよねえ。

アトムとビット

上述の 4 つの形のうち、1. と 2. はどちらも以前から存在するものだ。2. について Google が事情を大きく変えたりもしたが(p.294)、新しい何かというわけではない。一方、3. についてはネットのサービスでもなければなかなか実現が難しいものだ。これが可能なのは、ネットサービスが著者の言う「ビット」の世界に構築されているものだからだ。

「ビット」とは複製が完全かつ容易なモノのこと。つまり、デジタルなコンテンツ(とくにソフトウェア)のことだ。

一方で、デジタルではない従来の物のことを著者は「アトム」と呼ぶ。アトム、すなわち原子であり、物理的な実体をともなった物であったり、人(の提供するサービス)がやったり取ったりされる世界のことだ。こちら側では、複製は高価であったり、そもそも不可能だったりもする。

両者の違いは何か？ つまるところ「複製可能性」と「複製容易性」になる。後者も重要だが、とくに前者が肝心なところ。というのは、ビットには可能なこれがアトムでは不可能だから。どれほど費用をかけたとしても、物(や人)の完全な複製はできない。根源的な稀少性がそこにはある。ビットではこれが可能で、かつこの数十年で複製の費用がどんどん低下してきた(だいたいは Intel のおかげ)。

単純に言ってしまえば、安価に作れる(製造できる)ものは、安価に提供できる、っていうことだ。もし、タダで作れるなら、タダで配ったって問題ない。もちろん、実際問題としてタダで作れるってことはないから、いくらかのコストが発生する。ただし、それはとても低い。とても低いから、従来は(アトムの世界では)、不可能だったり困難だったりした方法でもコストの回収ができるようになる。これが現在、あちこちで見かける「フリー」を支えているものの正体だ。

で、その(とても低い)コスト回収の仕組みを分類すると、上述の 4 つになる、というのが著者の主張だ。

本当にフリーなのは？

ただ、4. の形のフリーをどう考えるか、それが問題として残る。費用を注目と評判で回収すると言うだけでは、提供者の動機を説明し切れていないと思う。

これについては、またおいおい。

ま、結局のところ、経済活動のような複雑な行為のシステムはよくわからないってことかもしれないけどな。

おまけ

忙しい人のための著者の主張を手っ取り早く知るための読み方を提案してみる。

1. 『第2章 「フリー」入門』を読む
2. 『第16章 「お金を払わなければ価値のあるものは手に入らない」』を読む

この 2 つの章を読めば、まあ大体はわかる。とくに、第16章を読めば、著者の主張(と論理)の弱いところも見えたりしておもしろい。時間があれば目次を眺めて気が引かれたところを拾い読みするのも良い。

あと、キーワードとしての「稀少」と「潤沢」かな。「フリー」を加えた、この 3 つの単語を覚えれば、本書を読んだって言い張れる。

関連書籍

ロングテール アップデート版―「売れない商品」を宝の山に変える新戦略 (ハヤカワ新書juice 4)

クリス アンダーソン
早川書房 ( 2009-07 )
ISBN: 9784153200043
おすすめ度:

物読みファイル (別館)で詳細を見る

MediaMarker

関連リンク

• The Long Tail (著者クリス・アンダーソンのブログ)

関連記事

• フリーランチの時代 ([著]小川一水, [版]ハヤカワ文庫JA930)

twitter より (2010-09-19)

• 03:25  すぐに英語での表現を忘れるのでメモ。「稀少の経済」の方が "The Economy of Scarcity" で、「潤沢の経済」の方が "The Economy of Abundance" 。→ http://bit.ly/adU0IW
• 05:24  Redmine の使い方、あれこれ。→ http://forza.cocolog-nifty.com/blog/redmine/index.html
• 05:28  Redmineのissue(チケット) にはbug, feature, suportの3種類が標準で定義されている。bugとfeatureは自明だけど、「supportって何？」と思ってググって見つけた。なるほど「その他のタスク」か。→ http://bit.ly/dub0yP
• 05:30  ソフトウェア開発のプロジェクトには、機能(の設計と実装)、バグの修正以外にも、やらなくてはならないことがあれこれある。そういうのを support として issue 発行するわけか。開発環境やテスト環境の構築もそうだし、リリース作業なんかもここに入れれば良いね。

Powered by twtr2src.

Retina ディスプレイ搭載の iPod touch

発表されてすぐに発注したのが 9/2 の早朝、出荷は 2 〜 3 週先だと言われしょんぼり。待つこと 2 週間。出荷を知らせるメールが届いたのが 9/16。上海からやって来るとわかる。待つこと、さらに 3 日。ようやく、今日、新しい iPod touch をゲット。

まずは、写真をいくつか載せておく。

iPod touch、到着

薄い！ (； ゜Д゜)

背面は iPod 伝統の鏡面仕上げ

電源、オン！

アクティベーション完了

ファーストインプレッション

やはり一番のオドロキは、その薄さだ。iPhone 3GS と並べて見ても一目瞭然。こんなに薄くて大丈夫なのか、と心配してしまうほど。初代の iPod のことを思い出すと嘘のような薄さだ。

最近は、iPhone しか使っていないし、その前でもすでにウチの iPod の主力は nano に移っていた。だから久しぶりに鏡面仕上げの背面を見て、これが iPod だよな、と思い出した。指紋がベタベタつくし、ケースに入れずに使うと傷だらけになったりするけど、それも iPod らしさってもんだ。

まだ、アプリを同期させていないので、ebook を表示させたときの Retina ディスプレイの見え方なんかは試していないけど、それはおいおい。

ウェブページを Retina ディスプレイ搭載機器対応にする

デバイスの検出

すでに、このブログは iPhone (3G/3GS) 対応になっている(iPad 対応はそれなり)。その仕掛けの主要部分が GAE アプリによるスタイルシートの切り替えだ。その肝になっているのが、リクエスト機器が送ってくるユーザエージェント文字列によるデバイスの検出だ。こう書くと大袈裟だが、やっていることはユーザエージェント文字列の中から "iPhone" や "iPad" といった文字列を探しているだけだ。

iPod touch 対応にするため、まずは上述の仕掛けの中で iPod touch を検出する。そのためには iPod touch が送るユーザエージェントの文字列を知らなければならない。調べれば(ググれば)わかるだろうが、ここは実機で確かめることにした。そのためのテストプログラムがこれ。

(useragent.cgi)
 1: #! /opt/local/bin/ruby1.9 -w
 2: # -*- coding: utf-8 -*-
 3: 
 4: # useragent.cgi: check the user-agent string sent by client devices.
 5: # Last modified: 2010-09-19
 6: 
 7: require 'cgi'
 8: 
 9: cgi = CGI.new
10: 
11: puts "Content-type: text/plain"
12: puts
13: 
14: print cgi.user_agent
15: STDERR.puts cgi.user_agent

CGI を実行できるフォルダ(Snow Leoaprd の Apache なら標準で /Library/WebServer/CGI-Executables)に置いてブラウザからアクセスすれば良い。iPhone や iPod のようなデバイスだと、ブラウザの画面から Mac にコピペできないので、標準エラー出力にもユーザエージェント文字列を書き込んでいる。こうすると Apache のエラーログ(Snow Leopard の標準設定なら /var/log/apache2/error_log)に書き出される。

ついでなので、iPod touch 以外のデバイスでもユーザエージェントを調べてみた。

各種デバイスのユーザエージェント文字列

Device	OS	User-Agent
Mac	Snow Leopard 10.6.4	Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; ja-jp) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
iPhone 3GS	iOS 4.1 (8B117)	Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; ja-jp) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7
iPad	iOS 3.2.2 (7B500)	Mozilla/5.0 (iPad; U; CPU OS 3_2_2 like Mac OS X; ja-jp) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B500 Safari/531.21.10
iPod touch (Retina Display)	iOS 4.1 (8B117)	Mozilla/5.0 (iPod; U; CPU iPhone OS 4_1 like Mac OS X; ja-jp) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7

iPhone と iPad を "iPhone"、"iPad" で検出したように、iPod touch も "iPod" で検出すれば良いことがわかる。

Retina ディスプレイの検出

iPhone にも 3G/3GS と 4 があるように、iPod touch にも Retina ディスプレイを搭載している新モデルと旧モデルがある。これら新旧のモデルの区別には、今のところ CSS のメディアクエリーを使うしかないようだ。

「iPhone 4 の CSS を切り替える方法」にあるように -webkit-device-pixel-ratio: n で新旧モデルを切り替える。n = 1 なら旧モデル、n = 2 なら Retina ディスプレイ搭載のモデル、となる。

あれ、どちらも 320 * 480 なんだけど……

実際にスタイルを定義し始めるまでは、上述のようにして Retina ディスプレイ搭載モデルを検出すれば、640 * 960 の画素数の画面として扱えると思っていた。しかし、新モデルも、Safari から見ると、デバイスの画素数はやはり 320 * 480 なのだ。1/2 ピクセル単位で指定できるのでない限り(できる？ できないよね？)、スタイルを定義する観点から言えば、新旧モデルに差はないということだ。

「iPhone 4 の CSS を切り替える方法」の最後に少し書かれているように、JavaScript を使って、viewport を書き換えるという方法もある。ただし、このページに載っているコードそのままだと、iPod の向きを変えたときに width が変わらない。もう少し、工夫が必要らしい。

小さい文字がくっきり見える

CSS の定義上は変わらないと言っても、実際に見比べれば Retina の解像度には目を見張るものがある。はっきり言って全然別ものだ。わかりやすい例を挙げると、Retina ではより小さなポイント数の文字がはっきりと読める。iPhone 3GS では 10 pt より小さいと見えにくくなるが、Retina の iPod touch なら 9pt でも余裕で読める。

この違いならスタイルに反映させることができる。つまり、Retina モデルでは少し小さい文字を表示に使うというものだ。実際の表示を写真で示す。以下の写真を iPhone/iPod touch 等で見るときは、本体を横向きにしてほしい(サムネイルを 400px にしてあるので)

文字表示の比較

iPhone 3GS { font-size: 11pt; }

iPod touch (Retina) { font-size: 10pt; }

iPhone 3GS { font-size: 11pt; }

iPod touch (Retina) { font-size: 10pt; }

iPod touch のフォントを 9pt にしていないのは、さすがに目が疲れそうだから。くっきりと読めるということと、楽に読めるということは別物だからね。

関連リンク

• メディアクエリー (2010年7月27日付 W3C 勧告候補の日本語訳)
• iPhone 4 の CSS を切り替える方法 (Fonland)

関連記事

• twitter より (2010-09-02) (新しい iPod touch の発表されたストリーミングを見ながらのつぶやき)
• GAE アプリによるスタイルシートの切り替え
• ウェブページのスタイルを iPad に最適化する方法