当ブログは移行しました。

http://www.symmetric.co.jp/blogに移行しました。
5秒後に自動的に移動します。
移動しない場合はこちらをクリックしてください。

imgタグビーコン方式の問題点②高コスト

■ビーコン式ASPは高い

imgタグビーコン方式は通常ASPで提供され、決して安くはありません。有用なサービスを開発・運用しているので当然なのですが、携帯アクセス解析にとってはこれこそが最大の問題です。定常的な固定費のかかるシステムは敬遠される傾向にあり、場合によってはサーバやコンテンツ保守より高価になってしまうアクセス解析の普及の妨げになっていると思われます。

imgタグビーコン方式の問題点①SSL通信時

■ドコモ端末のSSL通信制限

完璧なようなimgタグビーコン方式ですが、ドコモ端末仕様の制限が立ちはだかります。ドコモ端末はSSL通信時に2つの制限があります。

★ドコモ端末におけるSSL通信時の制限
  1. ホストドメイン以外の画像へアクセスすることができない
  2. iモードID(キャリアユーザーID)を取得することができない
SSL通信領域は、会員情報登録フローや商品購入フローなど、コンバージョンに関わるWebで最も重要なページが含まれています。ドコモの制限があるとSSL通信時にはビーコンを飛ばすことができません。また、通信可能なホストドメイン上でさえユーザーIDを取得できないので、致命的な状況です。このため、多くのサービスではSSL通信には対応していません。

現在の携帯サイトのアクセス解析の方法

■方法1:アプリケーションでセッションパラメータを生成し引き回す

携帯サイトのアクセス解析ですが、クッキーが使えないのでPHPやJavaのセッションなどを利用して、これらの値を引き回してサーバーログにURLパラメーターとして記録してツールで取り込んだりします。このようなアプリケーションで頑張る方法は、開発・運用コストが高くつくことに加え、一度パラメータのセッションが切れてしまったら、次のアクセスは別セッションとなってしまう問題があります。切れてしまえばユーザーがリピーターかどうか判別するには、ログインさせる必要が出てきたりして、ユーザビリティの劣化が発生したりします。

携帯サイトのアクセス解析が特殊な理由

携帯サイトも当然アクセス解析が必要ですが、PCであればとりあえずアクセスログを解析ツールで読み込ませて基本的な解析を開始できます。webalizerやAWStatsなど無料のツールもあります。ただし、これらのツールはIPベースでユーザー識別するので、個人自宅からのアクセスはほぼ同じアドレスからアクセスされるのでよいのですが、ゲートウェイを経由する企業からのアクセスを考慮すると、セッション数(ユーザー数)などのデータには正確性に問題があります。問題はありますが、なんといってもコスト0で実現できる点は大きな利点です。

フォント問題は画像で解決できる

テキストには、フォントが不定かつ機種で異なるのでデザイン計算できないという異機種の問題と、1行の文字数は個々の端末としては固定であり自由ではなく、高さもいつも決まった分必要だという問題があります。後者は当たり前のことかもしれませんが、デザインを考える上では制約となってしまします。

ラウンドアバウトの下で画像を使って、TOPメインメニューを作れば、文字数もフォントも自由に、そしてどんな端末でも同じように見えます。下図の例は5つの画像を並べた例です。


携帯端末のフォント問題

昔の端末は1行が8文字~12文字と決まっていて大きさも変更できませんでした。しかし、現在の端末はサイズが選択でき、かつ組込フォントは機種毎に異なり画面幅も違うので、1行に何文字とは決められません。htmlではフォントサイズは指定できますが、表示を正確にコントロールすることはできません。そもそも、HTML自体がフォントを絶対的な大きさで表現する技術ではないので、コントロールできたところで本来あまり意味は無いのですが、携帯サイトでは事情が異なっています。

よくあるのがTOPメインメニューで、ユニクロの携帯サイトを例に取れば、

MEN|WOMEN|KIDS|BABY|HOME

となっています。このメニューの問題を挙げてみましょう。

2G端末の現状と対応

2Gも対応したいんです。と、要望される人も多いのですが、まずは数字から抑えることが重要です。

2Gサービス
1月末
4月末
7月末
ドコモPDC
666万
556万
461万
ソフトバンクPDC
275万
197万
150万
auCDMAOne
34万
31万
29万

ラウンドアバウトが実現するリッチな携帯サイト

最初にリッチの定義からします。

  • リッチ=ユーザビリティが高い

ユービリティが高いとは、コンテンツが見易く、欲しい情報に素早くアクセスし、正確な情報を得ることができ、操作に迷わないデザインです。最終的にコンテンツ制作者の腕にかかってくることですが、携帯サイトでは、様々な制約があることから、特殊な腕を要求していました。例えば...

  • トップメニューは項目を縦棒で区切る
  • タイトルのバックグラウンドカラーを設定して目を引く
  • 絵文字の使い方を統一する
  • 半角スペースで見出しの字数を揃える
とかとか。これらのテクニックはテキストの中で如何に目出せたり、綺麗に見せるかということを目的にしていますが、如何せん、テキストばかりなので苦労するほどの効果が得られません。テキストベースでサイトに装飾することには限界があり、問題もあります。ところが画像であれば、多くの問題を解決することができます。

携帯サイトのデザインが貧弱な理由

この業界にいる身としては悔しいですが、一般的に携帯サイトはデザインは貧弱と思われています。理由は、小さな画面、テキスト中心、単純なレイアウト(人によってはI型とか言う)などによるのでしょう。

小さな画面は仕方ないとして(携帯できないと意味ないですから...)、テキスト中心、単純なレイアウトになってしまう理由として、よく言われるのが
  • 携帯は画像の処理が苦手
  • 画像は遅いのでテキスト中心にすべき
  • 携帯は画面が小さいので、単純なデザインの方が好まれる
などですが、果たしてそうでしょうか?

携帯画像:ブラウザーキャッシュ容量問題:ラウンドアバウトの解決法

ラウンドアバウトは、コンテンツ制作からブラウザーキャッシュ容量の制約を完全に除去します。アプローチとして、ブラウザーのハードウェアの容量を上げられないのであればコンテンツの容量を下げるしかありません。ラウンドアバウトも他の一部のソリューションと同様に画像の品質をダウンさせることで、容量を削減しますが、根本的に違うところは次の1点です。

  • アクセス端末のキャッシュ容量内に収まるように、ページ中の全画像を変換する

携帯画像:ブラウザーキャッシュ容量問題:これまでの対策

ブラウザーキャッシュ問題は昔から携帯開発者を悩ませていた最大の問題です。ブラウザーキャッシュが10Kバイトのような時代には、テキストだけでも制限を越えてしまう場合もあり、1ページあたりの情報を少なくするしかありませんでした。しかし、今日の100Kバイト以上の端末がほとんどを占めるようになると、まずテキストでは超えない制限となったので、画像をいくつ載せるか、どのクオリティにするか、という問題に置き換わってきています。ですから、このBlogでもブラウザーキャッシュ容量問題は画像の話題としています。

携帯サイト画像:VGA問題

画像の問題のもう1つである容量の違いに触れる前に、新しい問題としてVGA対応について触れましょう。

これまでの3~4年間はQVGA(横幅240px)の端末が事実上の標準機であり、仕様上の上級機でした。より古い端末でも200pxを切るような端末は5~6年前でもほとんどありません。つまり、画面サイズは上位機種から15%程度の違いでした。このため、さらに古い端末をサポート対象にせず、単純なレイアウトだけであれば、220px程度を基準に作ることでデザインも概ね大きく崩れることがありませんでした。

このような状況の中でソフトバンクからVGA(横幅480px)の端末が2年位前に発売され、この5月にはドコモの新機種の大部分はVGAサイズとなりました。VGAはQVGA比で縦横2倍、面積4倍という大きさであり、これまでと全くスケールが違います。サイズが大きくなったVGA端末では、当然キャッシュ容量も大きく拡大されています(ドコモ500k,ソフトバンク300k)。このことから、新たな機種違い問題が出てきています。

携帯サイト画像:画面サイズ問題

携帯サイト制作の肝とも言える画像問題について考えます。根本の問題は2つです。

  1. 機種毎に画面サイズが異なる
  2. 機種毎に容量が異なる

ここでは画面サイズの問題にフォーカスします。歴史的経緯(?)から過去の端末において、端末のブラウザーからはみ出してしまうとエラーになり、表示されないという問題がありました。つまり、

  • 大きすぎて表示できない

ということです。この問題に対処するのが一般的な画像変換ソリューションであり、大きすぎてエラーになってしまう事態を防止します。
しかし

HTMLは何を使ったらいいのか?

全キャリア対応の携帯サイトを作る際に最初に決めなければいけないものが、使用するHTMLです。そして、ほとんどの場合、iモードXHTMLを推奨しています。もしサイトが2Gもサポートしたいのであれば、iモードHTML(CHTML)となるか、2G/3Gで2つの言語を出し分けることになります。

細かい仕様の違いは他の情報源を見ていただくとして、実は表現力の違いはiモードXHTMLとCHTMLにはあまりありません。大きなところで背景色が使えるところくらいです。そしてchtmlは2G/3Gで基本的には見れますが、xhtmlは2Gでは見ることができません。なのでxhtmlの時代ということを考えなければCHTML(ver.7)を利用するのは1つの合理的判断だと思います。

携帯サイト制作会社の意識の壁

ラウンドアバウトを紹介して回る先にモバイルコンテンツプロバイダー(MCP)は外せません。ラウンドアバウトの良さを一番に理解してくれる企業にでしょうから。様々なお付き合いの中で、開発現場の方から開発マネージャーや経営TOPに近い人まで多くの人に見てもらってきました。ほとんどの人からポジティブなコメントを頂いていますが、それは置いておいて、常ではないけどよく聞く期になる言葉があります。

Web制作会社と携帯サイト制作会社の間の深い溝

ラウンドアバウトが出来上がろうとしていた時期に、Web制作会社(携帯も作るがPCサイトメインの)へ製品紹介をしていた時の話です。そもそもなんでWeb制作会社へ行ったかと言えば、ラウンドアバウトは携帯の煩わしい問題を無くしてしまうので、業務の幅が広がるという話をしにいった訳です。そこで聞いた話は、この先何度も聞くことになるのですが、結構考えさせられるものがありました。要約すると...

「携帯サイト制作は実のところ、営業上できるとは言っていますが、あまりやりたくはないのです。大体、PC/携帯両方を希望するクライアントが多いのですが、その難しさとコスト及び効果を説明することで、時期尚早として2次開発などに変更して、結果的に受注しないようにしているんです」

ラウンドアバウトのコンセプトを公開していきます

モバイルWebプラットフォーム:ラウンドアバウトのオフィシャルではあるけど、製品サイトには載っていないような情報を、携帯サイト開発にまつわる話を絡めて公開していくBlogです。

ラウンドアバウトとは以下の製品のことです。


このBlogを通じてラウンドアバウトのコンセプトを広く知ってもらえるとよいなぁと思っています。そして、携帯サイト開発について色々な意見を聞ければよいなぁと思っています。