Web屋のネタ帳

スマートフォンは普及期に達しつつある、なんて話は今さら？ では、「いまあなたが仕事で関わっているWebサイトをiPhoneやandroid端末で見たとき、その見栄えは実用に値するレベルですか？」と聞かれると黙ってしまうそこのアナタですよアナタ。まあ聞いてくれ。

mixiの例をひもとくまでもなくWeb屋にとってケータイ対応は避けて通れない。PC向けに加えてガラケー3キャリア対応までやるヒマも予算もビジネス的勝算も無いからと見て見ぬフリするような姿勢は遠い過去のものだ。スマートフォンの普及が状況をワープさせた。

話はそれほど難しくはない。

TIP 1. まずガラケーを切り捨てる

「ちょｗｗ待てｗｗ」とかそうおっしゃらず。

絶対わざとだろってくらいCookieに対応しなかったクソdocomoの肥溜めをさらうためにセッションIDのURL埋め込みやら契約者固有IDやら危なっかしい実装で綱渡りをしつつ一歩でも間違えると穴が丸見えとかわけわかんない新聞ネタにされるリスクをかかえたまま試験端末のレンタル屋に通いつめて両手に端末持ってチマチマいじりながらそういえばそもそもC-HTMLなのXHTMLなのCSSは外部なのインラインなの？．．．

そんな不毛かつ100%消え行く運命のノウハウを議論し実装し続けるくらいなら、もっと本質的なこと＝自分のサイトのコンテンツやサービスそのもの＝にヒトモノカネのリソースをあてるっていうのが予算の有効活用というものだ。決して言い過ぎじゃないと思う。 ガラケーは、いまこそ清算してしまうべき技術的負債というやつなのだ。

cookieやjavascriptが使えるようになったiモードブラウザ2.0があるじゃないかって？ ご存知の人はご存知の通り、iモードブラウザ2.0はかなりのいわくつきである。

• i-mode2.0は前途多難 - ockeghem(徳丸浩)の日記 (2009/5)
• 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - i-mode2.0セキュリティの検討 - 徳丸浩の日記 (2009/8)
• P-07AでもJavaScriptが再開され、あらたな制限がみつかった - ockeghem(徳丸浩)の日記 (2009/11)

ある程度の仕様の共通性が保たれるべきJavaScriptに対して、やれalert()は使わせないだのなんだのと、登場直後から大慌てでバカバカしい技術的負債を膨らませてしまっているのだ。理由を明かすこともできないまま。いつかツケを払うことになるだろう。

そうそう、先に言うべきでしたが、今回お話をする5つのTIPSではWebデザインの観点とWebアプリケーションの観点が少々ごっちゃになっております点をご容赦下さい。

TIP 2. 問題はPCかスマートフォンかではなく、画面が大きいか小さいか、だ。

とにかくガラケーをぶった切れば、あとはPCとスマートフォンのことだけを考えればいい。そうなるとCookieもJavascriptもHTMLも仕様はほぼ共通。だからこそ、考え方を改めよう。ＰＣかスマートフォンか、ではなく、「ユーザーの画面が大きいか小さいかの違いに対してこのWebサイトはどう対応するのか？」そこに本質がある。

iPadは今でこそ1024x768＝その辺のノートPCと同じ＝だけど、違うモデルもそのうち出るだろう。iPad以外にもなんだか中途半端な大きさの端末だって出ている。それに、孫の写真を収めたメモリーカードごとおばあちゃんにプレゼントしたデジタルフォトフレームには実は無線LANとchromeブラウザが搭載されてますなんていう未来はそう遠くない。その画面サイズはいったい何インチ何ドットなんだろう。

なお、新型iPhoneは驚きの解像度で小さな文字も鮮明に見えるらしい。それを考えると画面自体の大小だけでなくその解像度もWebデザインに大きな影響を与えると言える。とはいえ、解像度に頼るアプローチはもう限界に達した。液晶画面の解像度の向上は見込めても人間の目の解像度はこれ以上向上しないからだ。

とにかく、端末の機種やブラウザやOSやそのバージョンによってWebデザインを変えるというのはあまりいい作戦じゃない。

function is_mobile () {
    $user_agents = array(
      'iPhone',         // Apple iPhone
      'iPod',           // Apple iPod touch
      'Android',        // android
（以下、延々と書き加えることになる）

こんなクソコードはあくまでも最後の手段であって最初から取るべき方針ではない。 ではどうすべきか？

TIP 3. CSS Media Queriesと metaタグのviewportを使った新種のリキッドデザイン

Webサイトとそのユーザーの間で画面サイズの違いを自律的に仲立ちしてくれるデファクトな仕様は、実はこの二つしかない。今のところ。

CSS Media Queries とviewportの詳細については各自ググっていただくとして、ここではまずサンプルを示したい。

1. 何の変哲も無いよくある2段組CSSデザインのページ（HTML4.01)が、
2. スマートフォンで見ると、こう見える。（画面キャプチャ）
   

通常のPCではよくあるデザインにしか見えないHTMLだが、スマートフォン上ではcss media queriesによってヨコ並びのdivブロック自体がタテに並んでいる。ある意味、リキッドデザインである。また、viewportのscale設定によって、自動縮小されること無く読み始められるレベルの文字サイズでいきなり表示される。

最近、xperiaがピンチ操作（二本指操作で画面を拡大縮小）できなくて残念だという話題があったが、これはスマートフォンで通常のWebサイトを見るとほとんどの場合にかなり小さく縮小された状態で表示されてしまうので何も読めないというストレスの裏返しなんじゃないだろうか。上述の通り、css media queriesとviewportをうまく使えば一気にこれを解決できる。

TIP 4. 「おいおい、つまり、PC向けのページも含めたWebサイトデザインの完全リニューアルってことじゃないか。これのどこが低予算でのスマフォ対応なんだ！」

それは、いつかは全面CSS化しなきゃならなくなるだろうと薄々わかっていたくせにズルズルとtableタグでの幅固定デザインのままここまで来てしまったあなたの愚痴いや責任である。

1. PC向け、ガラケー3キャリア向け、スマフォ向け、いつか登場するであろうなんだかわからないジャンルの端末向け、といった感じで複数種類のデザインテンプレートとアプリケーションコードを開発しUser-AgentやキャリアのゲートウェイIPアドレスのリストをメンテし続ける手法。自由度は高いがコストはすごく大きい。しかもこれは、Webサイトデザイン的に見てもWebアプリケーション的に見ても、技術的負債を雪だるま式に膨らませることになる闇金エンジニアリングである。
2. 基本デザインはひとつのままで、画面サイズに合わせてCSSを調整あるいは（media queries的な意味での）分割をするだけで済ませる手法。デバイスに合わせてのデザインの自由度はやや低いがコストは小さい。アプリケーションのコードもほとんど統一できるだろう。技術の進化を素直に享受しつつ自分のビジネスにおける真の課題と向き合う時間を増やすことができる。

2010年11月現在から数えるとして、むこう2,3ヶ月ならともかくむこう1,2年以上のスパンで見れば、上のどちらの方針が最終的に高いコストパフォーマンスをもたらすのか、明白なんじゃないだろうか。

TIP 5. ところで、広告の位置とサイズどうする？

実はこれが一番問題になるんじゃないだろうか。広告といっても自社広告やらadsenseやらそのサイズもいろいろあるのでコレといった共通手段がない。viewportで言うところのdevice-width等の実際の値をjavascriptで拾ってそれにあわせたサイズの広告を出すようにコントロールするとか？（無理だろうな）。そもそもPCと同じサイズ／数の広告をスマートフォン等の小さな画面に全部出せるわけもないので、いくつかの広告表示用のブロック要素をdisplay:noneするようにCSSに書くしかないのかもしれない。 各自の健闘を祈る。