PCサイトは、幕の内弁当なり〜！

　最近、「モバイルファースト」を考える機会が多いのですが、そもそもデスクトップサイトというのは「いかに情報を詰め込むか」という、なりゆきで始まったと感じています。
　つまり限られたサイズの中で、いかに情報を効率よく詰め込み、ポイントを押さえるか。これは雑誌のレイアウトの原則だったのではないかと思っています。かつて、雑誌の編集者をしていた頃に、デザイナーのN親分が、教えてくれたことがあります。
「ただ詰め込んじゃダメ。なにがポイントかを考えてラフを描くんだ」と。

ビギナー編集者というのはどうしても要素を詰め込んでしまいがちです。「白スペース恐怖症」というのもありました。でも、こういうページは、「どこがポイントであるかどうか、わからない」からダメページにあるというのです。
答えとしては、「つまりポイントを作れ」でした。

今考えると、雑誌デザインは、雑多な要素に調和をといれた「幕の内弁当」だったともえいえます。この写真の場合、ポイントとなるのは、エビフライです。



さて、幕の内弁当デザインといえばヤフーです。

かつてのヤフーのデザインはこれでした。それが10年後にはこうです。

1997年　　　　　　　　　　　　　　　　　　　　　　　2010年

→　

どうでしょうか？
複雑化をつづけながらも、「そうじゃいけない、よりわかりすく、より多く」という「整理とポイントの歴史」を続けてきたといえるでしょう。
ヤフーの場合はレクタングル・バナー枠が「エビフライ」に相当するのでしょう。


モバイルファーストの時代は、ファーストフードの発想で。

モバイルファーストの時代になってくると、今度は、情報を最小化していく必要があります。幕の内弁当ではなく、「ファーストフード」に切り替える発想だとおもっています。

マクドナルト、吉野屋、Coco壱番屋、KFC・・・・・


『モバイルファースト』著者　ルーク・ウロブロスキーがいいます。
ユーザーに場所や、そのときのニーズ、つかい用途を考えてデザインしていく必要があると。

しかし、問題は、それをどう実践していくかが重要です。なにしろ我々は15年以上も「幕の内弁当」の発想でWebサイトを作り続けてきたきたわけですから、そう簡単には切り替えられないのです。シンプルで要素の少ないデザインをできるでしょうか。

雑誌デザインでいう「白スペース恐怖症」に似た、シンプルすぎる要素を
どう判断していくことになるでしょうか？
ぜひこれについて、ご意見お願いします。

モバイルファーストという言葉の意味？

モバイルファーストという言葉が使われ始めています。

この言葉は、元ヤフーUSAのチーフアキテクトであり、eBayでも活躍したUI/UXデザイナーのルーク・ウロブスキーが2009年に提唱した言葉です。

2011年9月には、彼の著書「モバイルファースト」が、米国で発売され、ようやく日本でもこの言葉が少しずつ使われ始めているようです。

　　　　　　　

モバイルファーストを簡単におさらいすると３つのポイントがあります。それは３つの社会変化といえます。

１）急拡大するスマートフォン端末の拡大
２）限られた画面における制約ーコンテンツフォーカスが必要
３）新しいテクノロジー　位置情報や音声認識などの登場


以上の変化が生活スタイルに関わってくるために、今後はPCによるデスクトップファーストではなく、モバイルを中心とした「モバイルファーストでの行動スタイル、コンテンツ様式が求められてくる」といいます。

このことを突き詰めていくと、
もはや重要視すべきなのは、モバイルサイトであって、
デスクトップサイトは、二番目に考えればいいという考えです。


すでに主婦層や若年層では、スマートフォンを中心とした行動様式のシフトが始まっており、PCサイトのモバイルからの流入率は　40％を超えようとしています。これらは欧米なみに、１年後には間違いなく５０％を超えてくる可能性があります。


バズワード化するモバイルファースト？

このモバイルファーストについての考えは、後述するとして、この言葉は、少々暴走気味に一人歩きをはじめている気配もあります。

　ある携帯端末会社のスタッフはいいます。自分たちのサイトはモバイルファーストで作ってあるから大丈夫です。話をしていくうちにちょっと定義がずれているのに気がつきまいた。彼らは、モバイル専用のサイトをスクラッチで作る。または、スマートフォン専用のアプリを開発するという意味で使われていました。

専用アプリがモバイルファースト？これには少々驚いてしましました。それは言葉として間違いないかもしれませんが、デバイス間の連携やコンテンツの流用＝ワンソースマルチデバイスなどはまったく考えられていなかったからです。


ルークの考えるモバイルファーストをあえてわかりやすくいえば、

「モバイルを中心にWEBサイトを設計し、それをマルチスクリーン対応にして効率化をはかること」

と理解します。そしていま注目されているのは、ユーザーはデバイス間で遷移をするということです。
　今後、明らかにされる、モバイルへの流入率、利用時間、滞在時間、Eコマースの伸びのデータの公表は、間違いなく、モバイルファーストに対する感覚を大きく変えていくことでしょう。

デジタルメディアは「計測できる」からこそ価値がある！

　今回は、コムスコア日本代表の前川洋輔氏にインタビューをさせてもらいました。

　コムスコアは、ニールセンなどと並ぶ米国のデータ調査会社です。私自身でいうと、2007年に、米国のGlamメディアの調査をしているときに、彼らがコムスコアのデータを利用して広告効果のレポートを出していることから、気になっていた会社です。


その前川洋輔さんは、こういいます。

「デジタルメディアは、計測できるから価値があるんです」

「マルチデバイス、マルチスクリーンの時代では、OneWeb＝１つのURLの発想で考えていかないと、その計測できるバリューにひずみができてしまうんです」

　みなさんは、この意味がわかりますか？ちょっと背景を説明すると、スマートフォンサイト対応には、いくつかの方法があるのですが、多くのソリューションが分離された別々のモバイルサイトを作ってしまう傾向があります。
　日本でも6割とされる「スクラッチ」でのサイト構築もそうで、URLはPCと異なってしまいます。また最適化コンバートを行うプロキシーソリューションでも同様で、ドメインに前に、ｍドットがついてしまいます。これらはOneWeb＝１つのURLではありません。

スクラッチで構築した場合：PC www.yourdomain.co.jp/　　　　　スマホ　　www.yourdomain.co.jp/sp/

プロキシーソリューションの場合：PC www.yourdomain.co.jp/　　　　　スマホ　　m.yourdomain.co.jp/

※スクラッチは個別でスマホサイトを構築するやり方。プロキシーソリューションは、プロキシーサーバーを使って、キャシュされた別のサイトをリダイレクションによって読みにいくやり方で、フューチャーフォンの時代から利用されていた方法です。


このURLの問題が何を表しているかがポイントです。
非OneWeb、つまりURLが別々になったときの問題としては、大きく下記の３つがでてきます。

1. SEO効果をだめにする。リスティング効果が半減
2. ソーシャル効果がダメになる。拡散、集客
3. マーケティング集計　ログ解析がダメになる。

１）２）も結構大きな問題だったのです。カンタンにいえば、領域が別になるわけです。Googleのクローラーは1つではなく、複数それぞれのサイトを走る必要があります。無理矢理サーバーサイドでURLを調整する方法もありますが、この方法でもサーバー内部でリダイレクションをかけているので、クローラーは１つではありません。

３）のアクセス解析の問題はどうでしょうか？　解析のテクニックでなんとか調整するという方法があるとは聞いていましたが、結構調整が大変、人為的なミスがおこりやすい、でてきたログが判読しがたい状態になるなどの面倒さがあります。つまり計測しにくいという問題がでてきます。


つまり、マルチスクリーン時代はOneWEBであることが必要です。Googleもそうだし、コムスコアでもデジタル分析の上で、推奨しています。

計測できない、または計測しにくいWebページであることは、WEBマーケティングの本来の役割を果たしていないともいえるのです。

「タブレットサイトへの対応を含めても、WebはOneWebでなければならない。
このコラムのタイトル「OneWebワールド」の価値を、改めて認識したインタビューとなりました。ありがとうございます。

エンジニアから見た、Mobifyの優れたポテンシャルと今後の発展性について

Inside Mobify

エンジニアから見た、Mobifyの優れたポテンシャルと今後の発展性について
　　　　　　　 ～技術アドバイザー・黒田正信氏に聞く

　今回は、サーバー系エンジニアである黒田正信氏に、Mobifyがもたらす技術のすばらしさについて語ってもらいました。
 というのも、見過ごしていた技術のポイントを黒田氏が、自らの饒舌に語りはじめたからです。彼のコーフンぶり、CEOイゴールとの熱い会話、エンジニア同士のやりとりの中で、Mobifyの真のポテンシャルが分かり始めたからです。

　今回のインタビューは、エンジニア黒田氏にとってのMobifyの技術的な感動を再度、ここで収録してみました。

プロキシー・ソリューションでは、まったく興味がなかった。

　最初、Mobifyを知ったときには、従来からあるプロキシー・ソリューションだと思っていました。プロキシー・ソリューションは、サーバー側でコンテンツをスクレイプしてキャシュして配信するという当たり前のやり方です。

　ところが、新しいMobifyクラウドは、クライアントサイドのデバイス本体にいろんなことさせるソリューションでした。
　つまり「スマホ本体の中で最適化を行う状態を作る」という。こんなやり方は、今までは考えられなかった。少し前のデバイスならばパワー不足で実現が難しかったやり方だったんです。
　これは画期的なことだと思います。



デバイスの本体で最適化というアイデアはすばらしい

　ボクが古いのか、Mobifyチームの彼らが天才なのか、アイデアそのものとしてもデバイス本体でも表示の最適化を行うという常識を変えたところが凄いと思いますよ。

　逆に、従来のプロキシーソリューションでは、まったく予想の範囲内だし、ガラケーの時代からあったやり方なんです。プロキシーソリューションだと、結構サーバーに負荷がかかります。しかし、Mobifyクラウドの解決方法は、逆にサーバー側に負荷がかからない仕組みなっています。これもエンジニアからみたら画期的ですね。つまり技術的にコストを下げていくことにつながる技といえるからです。


Mobify.jsの優れた素質と今後の活用法

　Mobify.jsは、Javascriptの新しい使い方を追求しています。デバイス側で非同期通信を行わせているわけですが、サーバーとの通信負荷を減らすことにもつながっています。
　
　Javascriptは、ここ数年でいろんな活用が萌芽した新しい技術であり、こうしたアイデア事態がコーフンしますね。
　またMobify.jsは、Googleの開発したNode.jsをベースにしていることも安心感を生みます。なにしろGoogle自体が、Javascriptをこれでもかと、徹底的に駆使してきたサービスをたくさん生み出していますからね。
　このMobify.jsは、CTOのジョン・ボクサールが開発しています。彼らが自分たちのMobify.jsをGoogleのラリーページに見せたそうですが、ラリー・ページ自身が「こういう使い方っていいね！」といってくれたようです。


オープンソースになったMobify.js

　Mobify.jsは、2012年の6月に、オープンソースとなりました。オープンソースを不安視する声もありますが、逆にその利点はいろいろあります。
　まず、多くの人の目に止まるようになることで、あらゆる問題点が浮き彫りになります。そのためバグ対応のスピードが加速化します。また解決方法が見つからなければ、「自ら開発してやろう」という人もでてきたりします。逆にいうと、クローズで開発しようとすると、社内リソースがいくらあっても足りないような作業を、フリーミアムで行える環境ともいえるのです。
　いまでオープンソースであることのほうが、たくさんの人が見て、開発やバグ問題を解消するという安心感や信頼感を生んでいます。こうした面でいうと、オープンソースであるということは、サービス面の改善でもリードしているといえます。



OneWeb＝同一URLを行うというのは、絶対必要だ。

　同一URLというのは、理屈でいえばURLがそろっていたほうがいいわけです。OneWebであらゆるデバイスを対応させるという。つまりなんだかんだと言って、URLが分かれていていいことなどありません。スクラッチの開発会社は理屈を加えるかもしれませんが、SEO対策、ソーシャル対策、マーケティング活用、分析の面で必要条件といえるでしょう。
　とくに、最近はFacebookやpinterestなどのソーシャルメディアによって、確実に売上げが上がるということが証明されてきています。これが別URLやサブドメインだと問題が起こるわけです。スマホでみたものがPCでみるとか、PCのサイトをスマホで見ることになるとか、不都合がたくさん生じてきてしまうわけです。しかし、この点も他のOneWebソリューションは、デザインをなくす方向で対応していますが、Mobifyの場合デザインをスポイルしない開発が可能な点もいいですね。



モバイルCDNのスピードを手軽に利用できる

　Mobifyはその変換方法やロジックに注目されていますが、モバイルCDNの存在も忘れてはいけません。
　Mobifyでは、EdgeCast(エッジキャスト)というCDNを利用していますが。これがとにかく速い。計測してみると、CDNを利用していない場合のWebサイトサーバー本体よりも、Mobifyほうの応答速度ははるかに上回っているのです。
　
　つまり、PCサイトよりもレスポンスが速いわけです。モビファイサービスの場合、こうしたCDNの費用が月額利用料に含まれるわけですから、どう考えてもオトクでしょう。
　単体でCDNを利用しようとすれば、設定も大変だしコストもかかることになってしまいます。パッケージとしてインクルードされていることは大きいと思いますよ。


スクラッチ工法やCMSで対応することはどうなんだろう？

　スクラッチで開発したり、サーバーサイドのテンプレートで対応することって、まだまだ一般的ですよね。ただ、こうしたやり方でやり続ける限りいろんな不具合ができてしまいます。まずスクラッチだと作業が別途別にかかり続ける。これはあり得ないわけです。コストが無尽蔵に増えることは企業としてだめですから。またサーバーサイドのテンプレートでいえば、設定を細かくすることはできてもキリが無いわけです。
　
　それにOSや新機種のバージョンアップのたびに右往左往する可能性がでてきます。それもサーバー単位で細かく修正するというような。１つや２つならまだいいですが、複数単位やぺージが増えると大変です。これがMobifyの場合、システム上で調整が効きます。この点も大きいでしょうね。　


セキュアまで標準で対応している。

　Mobifyのクラウドは、セキュア対応が標準で対応しています。というか、PCサイトのセキュア対応に準じます。多くのプロキシーソリューションが、SSLサーバーを介してセキュア対応をしているわけですが、プロキシー自体がセキュアに向いていないリスクを抱えています。
　その点Mobifyは通信そのものをPCとスマホを直結したカタチで、画像関係だけをセキュアに関係なくコントロールしています。つまりデータ漏洩が発生しない。ほかの方法ならばいろいろ設定が必要な場合が多い。それがないだけでもすばらしいですね。そもそも2年前にPCDに問題からプロキシーソリューションに限界を感じたことから生み出されたクラウドと聞きます。この点にも注目ですね。

黒田正信氏　第四企画代表　サーバー系エンジニア

制作側は、スクラッチでのモバイルサイト構築に「罪の意識」を持つという。

スクラッチでのモバイルサイト構築に「罪の意識」を持つ？


あのですね。スマートフォンサイトをスクラッチで作っていると、
やっぱり「罪の意識」を感じてしまうですよ。
あるWeb製作会社の友人ですが、突然彼は、私にそう告白してきた。

　　　「！　」　　................................　　　どうして？

 それは、やっぱりムダじゃないですか？　PCサイトがあるに、まったく別のサイトに同じものを載せるという行為そのものことですよ。

スクラッチでモバイルサイト作るということは？

現在、スマートフォンサイトを作る上で主流となっているのが、このスクラッチ（マニュアル構築）で、専用のモバイルサイトを作る方法である。つまり、PCのコンテンツがあるのに、同じコンテンツを複製するような作り方をしたり、または、モバイル専用の別のサイトを作るというやり方だ。（北米ではセパレートサイトという言い方をするようですが。）

　この方法だと、コストもかかるし、更新作業も面倒だし、チェック作業や時間そのものに結構タフさを要する。なにしろ、ページが置かれている領域そのものがことなるため、
１．SEO対策は再度直す必要があるし、２．Facebookなどのソーシャル共有などで、正しい表示が難しくなります。この問題はもっと奥の深い問題があるのですが、スクラッチ構築の表面的な作業問題だけでも悩みや尽きません。

「ダメダメダメの連続なんですが、 商売と考えると手っ取り早し、しっかり製作費をもらえるからなんだかんだで、結局、スクラッチで作ってしまうんですが、やっぱり心の奥で「罪悪感」を感じてしまうんです」

　彼は、古くからの友人だが、実直な男で曲がったことが嫌い。非常に真摯な人間だから、なおさら彼の言葉が気になる。

「それにですよ。iPhone5とか、iOSとか新製品がでたり、OSが切り替わってしまうと、
以前のブラウザの問題と同じように、表示崩れがおこったりするんですが、それがスクラッチでやると、細かい微調整をそれぞれに応じて個別やらなければならないんですよ」

　実は、こうして発生してしまう不具合に対して、その対応費をいただく。これが、スクラッチを行う製作会社の稼ぎの部分となっているようだ。そしてそこにいる自分のやり方に許せないというのだ。つまり「確信犯」という罪の意識である。

 わかっていながら、古い手法で対応する

　なるほど。制作とは、不条理を抱えながら稼ぐ世界もあるという。この現状を広告主（クライアント側）もある程度、わかっている部分もあり、そうしないと
製作会社もうまみがないだろうからと、いまは、目をつぶっているような節もある。

ある大手の広告代理店の製作部門の担当者は、我々のコンバートサービスをみて、非常に興味を示してもらったものの、次のような質問がでた？

「それでどうやって儲ければいいのでしょうか？」

また別の大手SIベンダーの担当者は「コンバートサービスもいいのですが、5000万円のCMSを納品したほうが利益が大きいですよね」とも答えてくれた。

  この世には、もっといいやり方や手法があるのに、それを見ないで（見ようとしないで）、古いやり方で押し通そうとする世界がまだまだ存在するようだ。
公共事業の道路工事が何度も掘り返し、埋めているやり方に非難がでたこともあったが、ちょっと近いだろうか。

ともかく、我々は業界の異端児だから、正義を信じよう。もっとより効率的にする、コストを下げる、スピードをあげる。そして最良の結果が得られるように、サービスを提供して行こう。

【ウラジオストク対談】 マルチデバイス対応には、OneWebとアダプティブで対応していく！

はじめに。
ここ極東の果てのウラジオストクで、私とMobifyのイゴール・ファレッツキー社長と一緒に、連日のように、新しいモバイルサイトの対策について話し合っています。

というのは、従来の「最適表示」という問題に大きな変化が起こっているからです。もはやスマートフォンサイト対策だけでは、不十分であり、7インチを含めたタブレット対策という問題が目前にせまっているからです。ネクサス７に始まり、iPad Mini, Kindle Fire,さらにサムソンの新機種など、さまざまなサイズのタブレットが登場してきています。

サーバーサイドテンプレート調整の問題は、コストと、小回りが効かせにくい調整作業

占部雅一（以下 マサ）：
　マルチデバイス対応なんだけど、結局、我々が取り組もうとしているOne Web以外の方法で、ほかにいい解決策があるのだろうか？　CMSのサーバーサイドでのテンプレート調整では同等の対策をすることもできるが、この方法についてはどう思う？


イゴール・ファレッスキー（以下、イゴール）：
　CMS＋サーバーサイドテンプレート調整のコントロールをやれば、インフラのコストも含めて3倍～5倍のコストがかかってきてしまう。それはクライアントにとってたまったものではない。我々は、オープンソース化したMobify.jsを使い、かつ我々が用意したクラウド・サービスを使う。そのほうが、コスト的にはるかに安上がりになるのは間違いない。モバイルCDNなどを個別で用意したら、いったいどれほどのコストになるかを試算してみるといい。

マサ：結局、OneWebにするにしても、サーバーサイドのテンプレート調整では、結構手間になるようだし、いまはタブレット対応は、まったく考えられていないようだね。

イゴール：　タブレット対応は、サーバーサイドのテンプレート調整でやる限り、コストがかかり過ぎる。またテンプレート調整では小回りはきかない。なのに内部のエンジニアは、トータルでコントロールしたいから、どうしてもこの方法に目がいくようだ。

レスポンシブウェブデザインは理想的だがコストに加え、エラーが発生しやすい

マサ：　では、レスポンシブウェブデザインという方法はどうだろうか？OneWebを実現する上では、すでに古典的な手法で、もう何年も研究がされている。しかし、これらの「トラディショナルなレスポンシブウェブデザイン※注１」では、本当の意味での解決策にはつながらないのではないか？

イゴール；　そのとおり。コストが合わない。

マサ：　つまり、手間がかかりすぎる。構築の時間、コスト、メンテナンス、更新性など、どれもやっかいだよね。レスポンシブウエブに取り組むチャレンジャーのデザイナーでさえ、半分は諦めている感じがする。なのにムーブメントだけは熱い。クライアント側に対しても、トライアル後には「こんなに大変ならやめたほうがいい」という声も聞く。


イゴール：アメリカにもレスポンシブウェブデザインに対しては、熱烈なフリークがいる。彼らの取り組みといえば、CSSの芸術的なアプローチを追求し、そのジーニアス（天才的）な手法にこそ未来を見ようとしているうようだ。

しかし、我々自身がスターバックスやideeli（アイデリー）で取り組んだように、Adaptive（アダプティブ）ウェブという手法を提案している。

これは、PCサイトはそのままに、モバイル側だけでレスポンシブウェブデザインの対応を図るというコンセプトだ。

マサ：　レスポンシブ・デザインの最大のネガは、リニューアルをしないといけないという点につきる。ここが大きなハードルです。また構築コストも約２～3倍かかってしまう。100万円でできるサイトに、だれが300万円もの大金を支払うだろうか。


イゴール：しかし、北米ではEコマースを中心にレスポンシブウェブデザインが主流になるとも言われている。Googleがこの方法を推奨しているからであり、SEO対策、ソーシャルシェアやアクセス解析の点でも問題がないからだ。また、実際にクローラーがひとつで済むというもの大きな点だ

「アダプティブ」とは、レスポンシブ・デザイン＋Mobify　というハイブリッドの対応策

マサ：　実際のところ、「アダプティブ」こそが最良策だろう。レスポンシブ・デザイン＋Mobifyを組み合わせたハイブリッドな手法が、実はもっとも現実的だとおもう。それは先のリニューアルが不要なため、それに早く対応できることだ。
しかし、それなのに日本では、ハイブリッド策は、邪道と思われている節もあって、ピュアな開発者たちは、関心を寄せてくれない。

イゴール：アメリカでもそう。インハウスの技術者たちは、すべて自分たちでの解決を求める傾向があるんだ。スクラッチしかり、レスポンシブウェブデザインしかりだ。しかし、こうした方法でやればやるほど、構築コストとメンテナンスコストは跳ね上がってしまう。それは結果的に、クライアントに大きな負荷をかけるはずだ。

マサ：では、いま我々が取り組んでいる解決策、アダプティブウェブしかないんじゃないだろうか？つまり「Mobify.jsとクラウド」を使うことで、本当の意味の解決策はなるという。　イゴール、ほかの方法は、まだあるんだろうか？


イゴール：ないと思う。おまけにFacebookの急進がOne Webでなければならないことを押し上げている。口コミにしろ、モバイルコマースのコンバージョンがそれを証明しているしね。

マサ：　とすると、僕らのPRが足らないということじゃないかな。でも、こうした結論にたどりつくまで結構時間がかかってしまった。なにしろ、どれも手探りだからね。

イゴール：　これからは、アダプティブがいいでしょ。





マサ：　そうだね。PCサイトはそのままにして、モバイルサイトのみをレスポンシブウェブデザインで対応させる。しかもスマホだけでなく、タブレットもやってしまう。

PCサイトの全面リニューアルは大変だから、そのままにしておく。過度的な解決策かもしれないが、ここ2年くらいは現状サイトが残るだろうから、企業サイトがモバイルファースト化するまでの執行ゆうｙと思う。


イゴール：ともかく、ここロシアでもユーザー率は２５％と、日本と同様だけど、街中には日本以上にWifiが多いね。日本は街中のインフラが少なすぎると感じたよ。どこにもアンテナが立たないのが問題だ。　北米のユーザー率は、来年には６０％を越えるだろう。まもなくタブレット市場が活性化するとおもっているんだ。

マサ：、もっとOneWebを理解してもらうように、がんばりましょう。



※注１　トラディショナル・レスポンシブデザイン　→　CSSの技術を駆使して構築するオーソドックスな構築方法。反対に、レスポンシブ・デザインにMobifyのクラウド技術を加えて対応する方法を「アダプティブ」と呼んでいます。この方法だと、PCサイトはそのままに、モバイル側を対応することができるため、大がかりなリニューアルをする必要がありません。

※注２　One　Web　（ワン・ウェッブ）　→　PCサイトやスマートフォンサイト、そしてタブレットサイトをひとつのページ、すなわちOneWebの絶対パスのページで対応する方法。この方法だとあえて、複数のページを作成する必要がなく、集客や拡散の上でも大きなメリットがある。とくにFacebookが伸張している時代において、口コミによるリコメンドの存在は大きく、モバイルEコマースにおいては欠かせない条件と言われている。また同様にSEO効果にも都合がよく、、マーケティング分析の上でも無理のない仕組み。これらは、スクラッチやプロキシータイプのソリューションでは解決しにくい課題となっている。


2012年11月6日　（ウラジオストックでのモバイルサミットにて）

【北米モバイル通信】iPad Mini 向けWeb デザイン対策の５つのポイントとは？

iPad Mini 向けのWeb デザイン対策の５つのポイントとは？

これは、iPad　Mini対応のWebサイト製作のためのヒントです。ほとんどの人が意識してこなかった最適化対策です。キンドルではどうする？ネクサス７ではどうする？　日本では、スマホ対策が急務ですが、これだけでは終わらないのです。7インチタブレット対策をどうするのかが、今後の重要な課題および研究ポイントになってきます。

1.      タブレットで見るPCウェブは時代遅れ

iPad Miniへの対応が注目されています。現在のサイトが、スマートフォンフォンサイトならば、拡大し、PCサイトなら縮小して対応することはできます。どちらを選ぶとなると、モバイルサイトを拡大する方が最適化の出発点としては無理がありません。

しかし、これも一時しのぎです。世界はすでにマルチスクリーンの時代です。Googleの発表では、「９０％の人はスマートフォン、PC、タブレット、テレビと、それぞれのデバイスを使いわけている。」と言います。

ウェブサイトをさまざまな人々に見てもらいたいと考えるなら、すべてのデバイスに適応させる必要が迫られているのです。

2. タブレットデザインのガイドライン

では、 iPad Miniのような小型タブレットのためには、どうデザインしたらよいのでしょうか？下記は、タブレットデバイスのためのガイドラインです。

iPad Miniは、7.8インチの新しい画面サイズです。まず、1024 x 768 ピクセルサイズの画面 (iPad 1や 2 と同じ) であることを確認し、デザインを開始します。

• 大きなテキスト-読みやすさのために、14 ピクセルにフォントサイズを大きく。
• パッドするために-PCより幅や高さを増やし、リンクのタッチ精度をあげます。

特にこれは、フォームやカレンダー 、ドロップダウンメニューに意識しましょう。

• マウス動作　-可能な限り、マウスによる動きを削除します。
• コンテンツ-タブレット画面サイズの600 x 1000 （ピクセル）の、　固定でのページ幅の修正ではなく、全範囲をカバーするように柔軟な設計を検討します。
• フラッシュの削除– iPad やタブレットでは、フラッシュを削除する必要があります。
• ポジショニング-［positon:fixed］の設定はコンテンツのロードを遅くするので、外してください。

大事なことは、これらのガイドラインとともに、実際にユーザーとしっかり話をして分析をしましょう。最近の事例では、タブレット対応でテキストサイズを変更したことで、ユーザーは老眼鏡の必要がなくなり、コンバージョン率向上にもつながったケースもありました。

3.   サプライズ！： ユーザーは常に変化しています。

iPad Miniの画面比率は、1 億台以上販売されてたiPad と同じ4：3 ですが、まったく別物です。iPad MiniはiPhone と iPadの中間に位置します。7 インチ デバイスは、iPad より携帯しやすく、iPhone や iPod Touchよりもパーソナルなデバイスになりうると予想します。

大きさの違いは、iPad Miniの特質を意味するのかもしれません。iPad Miniは、ハンドバッグ、ラップトップ バッグ、財布やキャリー ケースに簡単に収まり、通勤や旅行に手軽に持ち運べます。ユーザーは 電子書籍、映画およびビデオ、ゲームやそのほかのエンターテイメント、FacebookやTwitterのようなソーシャルメディア やショッピングや商品検索など多岐の用途に使うことでしょう。

もちろん、彼らの行動を詳しく研究する必要があります。そのために、モバイルフォン利用の3 つの基本を再確認しましょう：

• 繰り返し：ユーザーは株価、スポーツのスコア、オークション出品などの定期的なリアルタイムの情報を求めて接続します。
• 退屈な時：ユーザーは時間つぶしや気晴らしを求めてFacebookやTwitter、またはメールやその他のエンターテイメントを利用します。
• 緊急な時：ユーザーは緊急時に、検索エンジンやニュースでどこで何が起きているかの情報を求めます。

4.   パフォーマンス: オプションにあらず！

iPad MiniはWifiiと３G回線、LTEなどに接続しますが、性能はデスクトップ ＰＣよりもスマート フォンに近いのです。開発においては、コンテンツ配信やコンテンツ運用で、パフォーマンスの制約に注意をする必要があります。ここでは、いくつかのケースを紹介します。

• HTTP 要求の削減。タブレットはノートパソコンに近い画面領域がありますが、その処理能力はモバイルに近いのです。「Facebook Connect と Google +1」 のような要素を削除すればパフォーマンスがよくなります。
• 画像の最適化。 iPad Miniは非常に美しい高解像度表示を誇ります。デバイスへのイメージ最大化や縮小化にも配慮されています。しかし、注意が必要です。余計なデザイン化は、ユーザーエクスピアリアンスを損ないます。
• スクリプトとスタイルの管理。JavascriptやCSSは、ページ内に書かれているものはすべて読み込まれます。不要なスクリプトはリソースを消費するだけなので、Jazzcatのようなサービスで、JavaScript と CSS を統合してみてください。http://www.mobify.com/mobifyjs/docs/jazzcat/
• CSS の選択。アニメーションの荷は高く、JavascriptではなくCSSを選択してください。

つまり、iPad Mini対策では、簡単にＰＣサイトを綺麗に表示させることはできません。では、どうやってiPad Miniに最適化させればいいのでしょう？

5. レスポンシブを超えるアダプティブ

レシポンシブデザインは、マルチデバイス　スクリーン用に構築する1つの方法です。しかし、レスポンシブデザインは、CSSを取り入れる適応可能なアプローチの1つに過ぎません。

ブラッド・フロスト氏は、プレゼンテーション：（Beyond media queries: anatomy of an adaptive web design）:の中で、次のように述べています。

レスポンシブウェブデザインとは、可変グリッドデザインです。メディアの柔軟性があり、非常に幅広い適応可能な哲学/戦略の一部です。言葉が先行してしまった気配がありますが、マルチデバイスのウェブ構築のために定義されるべきです。

レスポンシブデザインだろうと、最適化を施されたサイトだろうと、重要なことは One Web アプローチです（http://www.w3.org/TR/mobile-bp/#OneWeb）。つまり、Web標準の HTML、CSS、JavaScriptを利用し、ひとつのＵＲＬを通してユーザーに提供するということです。

もし、ウェブサイトが複雑でなければ、レスポンシブデザインを使用し、よりシンプルに可変性グリッド対応ができます。しかし、ウェブサイトが複雑に変化した途端、大きな問題を発生させることになります。

• イメージ管理と最適化－さまざまなデバイスへの画像表示を可能にしますが、レシポンシブデザインのイメージの管理は困難です。http://dev.opera.com/articles/view/responsive-images-problem/
• リソース管理と最適化－画像管理を越え、全体的なリソース管理 – 画像、スクリプト、CSS はレスポンシブデザインなど、に大きな影響を与えます。
• コンテンツのリフロー －レスポンシブ　デザインは、コンテンツを非表示にするなど、限られたコンテンツでコントロールが必要です。。
• ユーザー インターフェイス (UI) 　– 多くのデバイスは、独自のUIが求められ、フォーム入力、メニューは、デバイスに応じたUIが必要です。
• データのテーブル　－画像とコンテンツをデバイスに適応させた後もテーブル要素の扱いはやっかいです。下記URLにいくつかのソリューションがあります。

http://filamentgroup.com/lab/responsive_design_approach_for_complex_multicolumn_data_tables/

レスポンシブ・デザインはフロント エンドのレイアウトにはすばらしい技術です。しかし、多くの課題も抱えています。今後は、理想と現実に対応できる高度な機能が必要です。

レスポンシブ　ウェブサイトの86％は、単純に同じＨＴＭＬページ（すべて同じ関連画像、スクリプト、コード、リソース）の配信です。そのため、それ以外を行うことは難しくなります。複雑な動作をさせることで、それぞれのバイスに最適配信ができますが、それがブラウザー上でしっかり動くかどうかはわからないという現状があります。。

iPad Miniの登場は、マルチデバイスの時代が訪れたことをさらに意識させます。今後のコミュニケーション・プロジェクト成功は、最適化のアプローチをいかにうまく行っていかがポイントになってくるでしょう。

補足：Domobiは、レスポンシブデザインをさらに拡張するできる機能を持たせることが可能です。よりパフォーマンスをあげ、構築期間とコストを抑え、さらにメンテナンスをしやすくすることができます。

（James Sherrett, October 24 2012）