今回は、よりiPhoneでの閲覧や操作に向いたデザインの作り方について説明していきます。
携帯サイト制作の実践ノウハウ：iPhone用の画像で操作性を一層向上させる
今回は、よりiPhoneでの閲覧や操作に向いたデザインの作り方について説明していきます。
携帯サイト制作の実践ノウハウ：CSSでiPhoneで操作しやすい携帯サイトを作るコツ
今回はiPhone向けにデザインや操作性を改善するCSSプロパティについて、少し詳しく説明していきます。
携帯サイト制作の実践ノウハウ：ラウンドアバウトでリッチで快適な携帯サイトをiPhoneにも
ラウンドアバウトでiPhoneに対応した携帯サイトを作る際、おさえておきたい制作のコツについて説明していきます。
●VGA基準で制作
iPhone対応に限らず、ラウンドアバウトで作る携帯サイトでは常にお勧めしていることですが、VGA端末をターゲットにページレイアウトを作ります。
iPhone のブラウザ幅（縦向き・portlaitモード）は320ピクセルです。従来では一般的なQVGA端末（横幅240ピクセル）では、iPhoneの画面で は全体的に小さい内容表示になります。480ピクセル基準で作った画像はラウンドアバウトが自動的に縮小してデザインレイアウトを保持するので、画面に 合った大きさで見せることができます。なお、ラウンドアバウトは、iPhone端末の画面サイズを320×480ピクセル（portlaitモード）とし て画像を縮小します。
●VGA基準で制作
iPhone対応に限らず、ラウンドアバウトで作る携帯サイトでは常にお勧めしていることですが、VGA端末をターゲットにページレイアウトを作ります。
iPhone のブラウザ幅（縦向き・portlaitモード）は320ピクセルです。従来では一般的なQVGA端末（横幅240ピクセル）では、iPhoneの画面で は全体的に小さい内容表示になります。480ピクセル基準で作った画像はラウンドアバウトが自動的に縮小してデザインレイアウトを保持するので、画面に 合った大きさで見せることができます。なお、ラウンドアバウトは、iPhone端末の画面サイズを320×480ピクセル（portlaitモード）とし て画像を縮小します。
携帯サイト制作の実践ノウハウ：iPhoneで携帯サイトが見たい！に応える
iPhoneには高性能なフルブラウザ（Mobile Safari）があるので、iPhoneからのアクセスはPCと同じとするサイトが多いようです。iPhoneには容量オーバーエラー（メガバイトレベルは別として）やマークアップ言語の差異といった携帯固有の問題が生じませんが、本当にPCとiPhoneが全く同じデザイン・コンテンツでよいと考えてもよいのでしょうか？
例えば下はiPhoneからアクセスしたPCサイトです。ページ上部のFlashコンテンツが表示できておらず、内容全体が一見しては読めないほど小さく表示されています。
iPhoneでは縦の場合約３分の１に縮小表示されるため、読みづらく指でのリンクやボタンの操作がしにくいということも、iPhoneで見るPCサイトによくある問題の一つと言えます。こうしたこともあってか、iPhoneに機種変更したことで（PCブラウザ拒否設定などにより）携帯サイトが見られなくなった利用者が、PCサイトでなく携帯サイトを引き続き利用したいと思うことが少なからずあるようです。
例えば下はiPhoneからアクセスしたPCサイトです。ページ上部のFlashコンテンツが表示できておらず、内容全体が一見しては読めないほど小さく表示されています。
iPhoneでは縦の場合約３分の１に縮小表示されるため、読みづらく指でのリンクやボタンの操作がしにくいということも、iPhoneで見るPCサイトによくある問題の一つと言えます。こうしたこともあってか、iPhoneに機種変更したことで（PCブラウザ拒否設定などにより）携帯サイトが見られなくなった利用者が、PCサイトでなく携帯サイトを引き続き利用したいと思うことが少なからずあるようです。
携帯サイト制作の実践ノウハウ：CSSで背景画像を付ける
ラウンドアバウトの画像変換は、img要素の画像に限りません。変換対象となる画像は次のとおりで、今回はラウンドアバウトを使った背景画像デザインを取り上げます。
背景画像のCSSプロパティですが、本当はdivやtable関連要素にも変換対応しています。ただ、ドコモがbody要素にしか背景画像のCSSプロパティに対応しないので、３キャリアで背景画像を使う場合は実質body要素だけということになります。
背景画像を使ったデザインは淡い色調のパターン模様がよく使われます。例えば、下の画面のように小さい画像を縦横にリピートさせて柄のようなデザインをします（このサンプルは絵柄をわざとハッキリさせていますが）。これを様々な機種で見たとき、気になるのが柄の大きさに違いが出てしまうことです。VGA端末向けに作るとQVGA端末では大柄、一方QVGA端末に合わせるとVGA端末では細かく見えます。サイズ違いを用意して出し分けを行うか、機種による見栄えの違いを受け入れるしかありません。
（VGA端末サイズに合わせて背景画像を作った場合）
（QVGA端末サイズに合わせて背景画像を作った場合）
- インライン画像（img要素のsrc属性）
- 背景画像
- background属性
- background、background-imageプロパティ
- フォームのイメージボタン（input要素のsrc属性）
- リストのマーカー画像（list-style-imageプロパティ）
- 画像へのリンク（a要素のhref属性）
背景画像のCSSプロパティですが、本当はdivやtable関連要素にも変換対応しています。ただ、ドコモがbody要素にしか背景画像のCSSプロパティに対応しないので、３キャリアで背景画像を使う場合は実質body要素だけということになります。
背景画像を使ったデザインは淡い色調のパターン模様がよく使われます。例えば、下の画面のように小さい画像を縦横にリピートさせて柄のようなデザインをします（このサンプルは絵柄をわざとハッキリさせていますが）。これを様々な機種で見たとき、気になるのが柄の大きさに違いが出てしまうことです。VGA端末向けに作るとQVGA端末では大柄、一方QVGA端末に合わせるとVGA端末では細かく見えます。サイズ違いを用意して出し分けを行うか、機種による見栄えの違いを受け入れるしかありません。
（VGA端末サイズに合わせて背景画像を作った場合）
（QVGA端末サイズに合わせて背景画像を作った場合）
携帯サイト実践ノウハウ：auで発生する「画像の隙間問題」を解消する
ブロック要素に背景色を付けるデザインは、ページにメリハリを付けるのに効果的なのでよく使われますが、auではたびたび「隙間発生問題」という意図通りの表示がされない問題にも遭遇します。
詳しくはsympleブログのエントリーで解説されていますが、このエントリではラウンドアバウトが用意している拡張タグ
詳しくはsympleブログのエントリーで解説されていますが、このエントリではラウンドアバウトが用意している拡張タグ
- <ra:field></ra:field>
- <ra:area></ra:area>
携帯画像変換・ラウンドアバウトの実力：価格の比較
機能が横並びで差別化しにくい商品であるほど、価格（安い）が売り文句になってしまいますが、携帯画像変換もその様相を呈してきています。価格は、機能・価格構成・隠れコストなどの違いがあり、単純比較は危険ではあるけれども、あえて２つの指標で比べて見ます。
なお、R.A.は、ラウンドアバウト従量版ライセンスを示しています。
このデータは最新のものを確認したわけでもありませんし、全てのプランでの最適化も図っていません。また、比較の為に単位を合わせたりもしています。ということで、あくまでレンジの目安程度の扱いです。月間100万AC（アクセス）という指標も不利・有利になるので、くどいようですが参考です。
なお、R.A.は、ラウンドアバウト従量版ライセンスを示しています。
このデータは最新のものを確認したわけでもありませんし、全てのプランでの最適化も図っていません。また、比較の為に単位を合わせたりもしています。ということで、あくまでレンジの目安程度の扱いです。月間100万AC（アクセス）という指標も不利・有利になるので、くどいようですが参考です。
携帯画像変換・ラウンドアバウトの実力：機能の比較
携帯画像変換の製品やサービスでは、色々な機能を謳っていますが、メイン機能となる自動変換機能と、必要であれば利用する手動（指定）変換の２種類に大別できます。
基本的に自動変換機能は、何もしなくても全ての画像に対して必要であれば施される機能であり、手動変換は必要な際に何らかの特別な指定を行って実現する機能です。
携帯画像変換・ラウンドアバウトの実力：方式の比較
実は、携帯コンテンツの開発に当たり、最もポピュラーなサービスは画像変換サービスです。コンテンツ変換は画像変換機能を含みながら、システム構成や料金レンジから別カテゴリーとして認知されてきました。しかし、ラウンドアバウトはシステム構造と新・従量版による料金体系から、携帯画像変換というカテゴリーとしても非常に魅力的な製品となっています。まずは、携帯画像変換の製品やサービスにはどんなものがあるか、分類してみます。
主な方式だけでこれだけあり、それぞれ一長一短があります。それぞれのシステム特性を見ながら比較してみたいと思います。
従量プランを定額化する、新・従量プラン
従量性のサービスは「使った分だけ払う」という点でリーズナブルですが、それでも３つの弱点があります。
- サイトの規模が大きくなるとどんどん固定費が膨らんでいく掛け捨て方式
- 費用が変動するので予算が組み辛い
- 料金レンジに対して無駄が発生する
●従量課金の問題点
●ラウンドアバウトの解決策
ビジネスリスクをヘッジする：種蒔きライセンス”Seed”
所有リスクは少なくとも「ビジネスリスクはクリア」している時の問題です。しかし、多くのビジネス、特にWebましてや携帯であれば、ビジネスリスクがはっきりしないことが非常に多いです。「まずは費用を掛けないでトライアルしてから投資判断したい」というケースが殆どではないでしょうか？
その時、コンテンツ変換製品を使えば、簡単にできたりもっと可能性を追求できたはずが、貧弱なプロトタイプの為にそのビジネスアイデアを正当に評価できなければ、非常に残念なことです。そこで生まれたのが、”roundabout Seed”です。一言で特徴を言えば、「無料」なのですが、ユーザーが蒔くビジネスの「種」、そしてシンメトリックとしては製品普及の「種」になるという意味から、”Seed”と名づけました。
所有リスクとコストを減らす：スモールスタート＆出世払いの新・従量モデル
「ラウンドアバウト導入済みホスティング」を選択できないケースでは、ソフトウェアライセンスを購入し導入する必要があります。Webサイトはビジネスが確立するまで時間が掛かり、爆発的にヒットする場合も、逆に場合によっては撤退するケースもある世界です。システム開発自体の初期コストは実際にかなり工数も掛かるので、工数が発生しない製品などは「出世払い」にして欲しいのが本音です。現状を図にすればこんな感じです。
初期のコストを考えれば役に立つ製品を使わない選択をするケースも多くなってしまいます。しかし開発・運用コストが上がってしまえば、利益モデルが確立する時期も遅れてしまいます。
ラウンドアバウトの新・従量モデルはこれを解決するライセンスモデルであり、一言で言えば、「出世払い」できるライセンスの利用形式です。
初期のコストを考えれば役に立つ製品を使わない選択をするケースも多くなってしまいます。しかし開発・運用コストが上がってしまえば、利益モデルが確立する時期も遅れてしまいます。
ラウンドアバウトの新・従量モデルはこれを解決するライセンスモデルであり、一言で言えば、「出世払い」できるライセンスの利用形式です。
導入・所有コストを無くす：だから、ラウンドアバウト導入済みホスティング
現在ITの世界でのはやり言葉、クラウド・SaaS・XaaSですが、その流れの中には「導入・所有コストの削減」が大きな目的になっています。salesforce.comが、”Success,Not Software”といって一定の支持を得ているのも、必要なものを必要なだけ使い、使った分だけ支払うということが、１つの流れになってきているのだと思います。
ラウンドアバウトはソフトウェア製品なので、”Not Software” だけだと語弊があって困りますが、実際に所有コストは非常に高くつくものです。これは、ライセンス・保守費などの見えるコストではなく、学習コストと同様に見えないコストです。
だから、ラウンドアバウトは、「ラウンドアバウト導入済みホスティング」を実現しているのです。
ラウンドアバウトはソフトウェア製品なので、”Not Software” だけだと語弊があって困りますが、実際に所有コストは非常に高くつくものです。これは、ライセンス・保守費などの見えるコストではなく、学習コストと同様に見えないコストです。
- 製品の調査・選定・見積・決済まで決定に至るプロセスの確定・承認コスト
- 購入後の発注・納品・導入・確認の入手・設定コスト
- ソフトウェア権利の保管・保守更新の事務コスト
- ソフトウェアのバグフィックスやデータ管理などの運用コスト
- 選択ミスまたはプロジェクト変更によって無駄になるリスクとコスト
- 資産計上や償却などに付随する会計コスト
「専門家が、最適な組合わせで、オススメする！」
だから、ラウンドアバウトは、「ラウンドアバウト導入済みホスティング」を実現しているのです。
導入容易性を上げるために：学習コストとビジネスモデル・ミスマッチ
製品開発の悩みの１つは、導入可能性と導入容易性のジレンマです。一般に強い支持を受けるほどターゲットは狭くなると思いますが、システムも同じで特定のシステムへの親和性を強めるとそれ以外のシステムでは使いにくくなってしまいます。
ラウンドアバウトが現在CentOS上のApacheモジュールをプラットフォームに選択したのは、Webサーバーの環境としては一番のシェアがあるからです。それでも日本でそのシェアは50%前後のようです。今は残念ながら残りの半分はあきらめるざるを得ません。RH系Apache環境では、Apacheと一体となって動くことで、システム的には圧倒的に高い導入容易性を誇ります。しかし、導入容易性はシステム特性ばかりではありません。ラウンドアバウトでは、４つの切り口でさらに導入容易性を高める施策を打ち出しています。
■４つの切り口
ラウンドアバウトが現在CentOS上のApacheモジュールをプラットフォームに選択したのは、Webサーバーの環境としては一番のシェアがあるからです。それでも日本でそのシェアは50%前後のようです。今は残念ながら残りの半分はあきらめるざるを得ません。RH系Apache環境では、Apacheと一体となって動くことで、システム的には圧倒的に高い導入容易性を誇ります。しかし、導入容易性はシステム特性ばかりではありません。ラウンドアバウトでは、４つの切り口でさらに導入容易性を高める施策を打ち出しています。
■４つの切り口
- 学習コスト ： 製品利用に対して必要とされる知識を身に着ける為のコスト
- ビジネスモデルミスマッチ ： 製品を使いたくても収益モデルと合わない為に使えない
- 導入・所有コスト ： 製品の調査、購入、インストール、設定、保守、ライセンス管理などのコスト
- ライセンス不使用コスト ：製品性能がオーバースペックの時、余剰分の性能に対するコスト
Apacheモジュールである圧倒的なパフォーマンス上の優位性
通常のWebアプリケーションにおけるHTMLはキャッシュできないので、Apacheモジュール型のラウンドアバウトは、サーバー型（リバースプロキシー型とも言う）に比較して圧倒的に有利です。更に言えば、多くのシステムのフロントエンドにはApacheが配置されています。つまり、ラウンドアバウトは既に起動しているプロセスの中で１つのファンクションコールとして動作するという、パフォーマンス上圧倒的な有利な位置にいます。
コンテンツ変換でHTMLキャッシュありのパフォーマンスは意味が無い
前回のエントリーで書いたように、同じコンテンツとして保証できない、またユーザーアクセスをアプリケーションに届けなければいけないために、HTMLはキャッシュしてはいけないので、変換後のHTMLキャッシュを基準にパフォーマンスを計測することは、意味がありません。
HTMLをキャッシュしてはいけない
コンテンツ変換システムでは、パフォーマンスを確保するためにキャッシュをどのように設計するかは重要な設計方針です。画像については幾つかのエントリーで触れていますが、ここではHTMLについて考えてみます。最初に単純な問いかけを想定します。
”http://ra.jp/index.html”というアクセスは常に同じコンテンツとなるか？
答えは”NO”です。
”http://ra.jp/index.html”というアクセスは常に同じコンテンツとなるか？
答えは”NO”です。
携帯サイト制作の実践ノウハウ：コンテンツ変換をカスタマイズする２つの方法
ここ数回のエントリーで、「PI機能」や「変換シート」を利用してコンテンツの表示コントロールをする方法を紹介しています。どちらもカスタマイズが可能なコンテンツ変換機能ですが、今回はこの２つの機能の違いや使い分けについて説明します。
●PI機能を使った変換イメージ
●変換シートを使った変換イメージ
まず大きな違いは、上の絵のように、「PI機能」はコンテンツの部分ごとに書き分けられるCASE式のようなもので、「変換シート」はサイト内で一括管理される変換設定である、という点です。
また、画面サイズやGPS対応/非対応など、機種スペックに応じた出し分けが可能なのはPI機能だけということも、決定的に違うところです。
●PI機能を使った変換イメージ
●変換シートを使った変換イメージ
まず大きな違いは、上の絵のように、「PI機能」はコンテンツの部分ごとに書き分けられるCASE式のようなもので、「変換シート」はサイト内で一括管理される変換設定である、という点です。
また、画面サイズやGPS対応/非対応など、機種スペックに応じた出し分けが可能なのはPI機能だけということも、決定的に違うところです。
携帯サイト制作の実践ノウハウ：破線や色付きの区切り線をhr要素で表示する
以前外部CSSでのエントリーでも触れましたが、区切り線（hr要素）はキャリアごとにCSSプロパティの効き方が異なるので、破線や色で装飾したhr要素を３キャリアで使うのは大変です。hr要素の代わりにいっそ画像を使うというのも一つのよい判断です。
しかし画像にしたらしたで、src属性を書くことでHTMLソースが長くなります。区切り線はサイトの中で頻繁に使うものなので、<hr />そのままの記述で簡単に画像が表示できたらなぁと思いませんか？
できます。ここ数日のエントリーでも紹介している、変換シートを活用することで可能です。
しかし画像にしたらしたで、src属性を書くことでHTMLソースが長くなります。区切り線はサイトの中で頻繁に使うものなので、<hr />そのままの記述で簡単に画像が表示できたらなぁと思いませんか？
できます。ここ数日のエントリーでも紹介している、変換シートを活用することで可能です。
携帯サイト制作の実践ノウハウ：キャリア別にメール受信設定リンクを出分ける
空メールを使った携帯サイトやサービスがよくあります。迷惑メールを懸念し携帯ドメイン以外のメールアドレスからの返信を拒否するユーザーも多いので、ユーザー離脱を起こしやすいです。こうしたユーザーに配慮し、ドメイン拒否指定をの解除がしやすいように、メール受信設定が行えるキャリアのURLにリンクを貼るなどします。
ラウンドアバウトのない静的なHTMLでは３キャリア分のリンクを列挙することになります。違うキャリア用のリンクを踏むとエラーになるので、ユーザビリティを考慮して出し分けしたいところです。
前回書いたように、ラウンドアバウトではPI機能または変換シートの２つの方法で出し分けをすることができます。
ラウンドアバウトのない静的なHTMLでは３キャリア分のリンクを列挙することになります。違うキャリア用のリンクを踏むとエラーになるので、ユーザビリティを考慮して出し分けしたいところです。
前回書いたように、ラウンドアバウトではPI機能または変換シートの２つの方法で出し分けをすることができます。
携帯サイト制作の実践ノウハウ：プログラムレスで全角カタカナを半角カタカナに変換・表示する方法
PCでは見やすい全角文字も、携帯では表示可能な幅が小さい関係上、縦に長くなりやすく見難くなるので、半角カナがよく使われます。全角を半角に変換する作業を人手で行うのは大変です。特にPC・携帯でデータソースを共有したりコンテンツ量が多い場合は、変換処理を行うアプリケーションが必要になります。
ラウンドアバウトでは変換ルールにカスタムルールを追加することができるので、こうした全角カタカナを半角カタカナに一括置換することもプログラムレスで可能です。
ラウンドアバウトでは変換ルールにカスタムルールを追加することができるので、こうした全角カタカナを半角カタカナに一括置換することもプログラムレスで可能です。
携帯サイト制作の実践ノウハウ：マルチキャリアで見えるコピーライトマーク（©）の出し方
コピーライト「©」や登録商標「®」のような文字参照は、auでは「C」「R」と表示されます。下のように英字テキストと接したところが「R」や「C」になってしまうと、ユーザーに正確な情報が伝えられないので困り者です。
（W61Kでの登録商標マーク、コピーライトマークの表示）
携帯サイト制作の実践ノウハウ：ドコモ絵文字を本来の色で見せたい
デフォルト（青）以外のリンク色が設定されたページで、リンクテキストに絵文字を使うと、ドコモでは絵文字の色がリンク色と同じになります。リンクに限らず通常のテキストに色指定した場合も同様のことが起きます。これでは絵文字の装飾が際立たず、見栄えもしません。
本来の絵文字の色に戻すには、下のソースのようにspanタグ（XHTMLの場合）かfontタグ（CHTMLの場合）で文字色を指定する必要があります。
本来の絵文字の色に戻すには、下のソースのようにspanタグ（XHTMLの場合）かfontタグ（CHTMLの場合）で文字色を指定する必要があります。
どこまでも拡張できる超大規模システムを目指して
"THE MAGIC ROUNDABOUT"というものがあるそうで、ラウンドアバウトがいくつも連結しています。
大きな地図で見る
運転するとなれば、これはちょっとびびりますね...
携帯コンテンツ変換のラウンドアバウトでは、大規模システムをターゲットした製品です。大規模システムに要求されるシビアな品質と拡張性こそ、ラウンドアバウトが実現している比類なき特性です。
大きな地図で見る
運転するとなれば、これはちょっとびびりますね...
携帯コンテンツ変換のラウンドアバウトでは、大規模システムをターゲットした製品です。大規模システムに要求されるシビアな品質と拡張性こそ、ラウンドアバウトが実現している比類なき特性です。
快適な交差点→安定して高速な変換システムを目指して②
通行量が適切であると、実際のラウンドアバウトでは不思議なくらい、うまく機能するようです。
携帯コンテンツ変換のラウンドアバウトでは、大量の通信が発生しても常に安定的なサービスが出来るように不断の努力をしています。
携帯コンテンツ変換のラウンドアバウトでは、大量の通信が発生しても常に安定的なサービスが出来るように不断の努力をしています。
快適な交差点→安定して高速な変換システムを目指して①
パリの凱旋門はもしかしたら一番有名なラウンドアバウトかもしれません。
大きな地図で見る
そこでも、交通量が増えてくると、ノロノロの渋滞も起きるようです。
携帯コンテンツ変換のラウンドアバウトでは、このようなことが無いように設計・実装されています。
大きな地図で見る
そこでも、交通量が増えてくると、ノロノロの渋滞も起きるようです。
携帯コンテンツ変換のラウンドアバウトでは、このようなことが無いように設計・実装されています。
事故の無い交差点→ロバストなシステムを目指して
本当のラウンドアバウト（交差点）の運転は、最初は非常に難しいらしい（人伝の話ですが）です。なかなか入れない、下手をすればグルグル回ったり、違うところへ出ちゃったり...経験が無くても想像はつきます。
最悪、事故になることもあります。
でも、コンテンツ変換エンジンである製品では、事故はどうしても防がなければなりません。これが「ロバストなシステムを目指す」の意味するところです。
最悪、事故になることもあります。
でも、コンテンツ変換エンジンである製品では、事故はどうしても防がなければなりません。これが「ロバストなシステムを目指す」の意味するところです。
“ラウンドアバウト（roundabout）”という名の由来
「ラウンドアバウト」という名前は多くの日本人にはなじみ名の無い単語だと思います。なぜこんな名前をつけたか、名前に込めた意味を書こうと思います。ラウンドアバウトとはイギリスなどにある交差点の形につけられた名前です（回転木馬と言う意味もありますが）。こんな交差点です。
そう、最近のラウンドアバウトBLOGの表紙のGoogleMapで表示されているものです。動きますので、拡大していけばどこだか分かります。
そう、最近のラウンドアバウトBLOGの表紙のGoogleMapで表示されているものです。動きますので、拡大していけばどこだか分かります。
携帯サイト制作のヒント：クローラーをキャッチしSEO対策をしやすくする
カスタマイズ可能な端末グループの１つ、「クローラーグループ」は、携帯サイトのクローラー対策に役立つ端末グループです。
クローラーのUser-Agentを設定ファイルに書いておくと、クローラーからのアクセスが判別でき、PIやアプリケーションでクローラー向けの処理を書くことができます。
●クローラーグループの設定
クローラーグループを設定するファイルはCSV形式のテキストファイルです。
クローラーのUser-Agentを設定ファイルに書いておくと、クローラーからのアクセスが判別でき、PIやアプリケーションでクローラー向けの処理を書くことができます。
●クローラーグループの設定
クローラーグループを設定するファイルはCSV形式のテキストファイルです。
クローラーグループ名,ユーザーエージェントパターン
携帯サイト制作のヒント：端末グループを使いこなす
PI機能で使える条件式には、ラウンドアバウトが持つ機種情報の項目名以外に「端末グループ」を使うことができます。またリクエストヘッダ「X-RA-Device-Group」から取ることもでき、アプリケーションの開発サポートとしても活用できる機能です。
端末グループはいくつかの機種をグループ化したもので、デフォルトではラウンドアバウトが定義するグルーピングだけの状態ですが（システム端末グループ）、この他にユーザー定義のグループを作ることができます。
端末グループはいくつかの機種をグループ化したもので、デフォルトではラウンドアバウトが定義するグルーピングだけの状態ですが（システム端末グループ）、この他にユーザー定義のグループを作ることができます。
- ユーザー端末グループ
- クローラーグループ
携帯サイト制作のヒント：PI機能で表示コントロール
ラウンドアバウトの機能の１つに、アクセスした機種の属性に応じて、コンテンツ内の表示の一部を切り替える機能（PI）があります。出し分けたい内容をHTML上に記述すれば、条件にマッチする機種にのみ表示させることが可能です。
PIとはProcessing Instructionの略記で、XML文書中に特定のソフトウェアへの命令を埋め込む、処理命令のための記述です。<?ターゲット 処理内容?>で表され、PHPではこのPIが使われています。ラウンドアバウトの表示コントロール機能はこのPIを利用しているので、表示コントロール機能のことを「PI機能」と呼んでいます。
PI機能の利用シーンの一部
PIとはProcessing Instructionの略記で、XML文書中に特定のソフトウェアへの命令を埋め込む、処理命令のための記述です。<?ターゲット 処理内容?>で表され、PHPではこのPIが使われています。ラウンドアバウトの表示コントロール機能はこのPIを利用しているので、表示コントロール機能のことを「PI機能」と呼んでいます。
PI機能の利用シーンの一部
- 待受画面幅・高さに応じた配布する待受画像ファイルを切り替える
- 対応アプリの種類やバージョンに応じて配布アプリを切り替える
- Flash Liteバージョンに応じてFlashコンテンツの表示をコントロールする
- GPS対応状況とキャリアに応じて位置情報送信用のコードを出し分ける
携帯サイト制作のヒント：2ペインレイアウトをするには？
ページを縦に分割する２ペインレイアウトは、一目で多くの情報を見せることができ、ユーザビリティ向上に効果的なレイアウトです。PCサイトではdivなどのブロック要素にfloatプロパティを指定することで２ペイン・３ペインのレイアウトをしますが、携帯サイトではdivにfloatが効かず横に並べられないので、テーブルを使います。
携帯サイト制作のヒント：綺麗な箇条書きを実現するには？
箇条書きリストは情報を整理して見せるのに効果的ですが、PCサイトでは一般的でも携帯サイトでは使われません。下の例のように字下げ幅やマーカーの見た目の違いが大きいことや、ドコモはCSSプロパティでアレンジできることがほとんどないことから、見た目をアレンジしたくても３キャリアで同じような表示ができないのです。
（画面：左からdocomo 904i、au G9、SoftBank 920P）
ラウンドアバウト・ホスティングの存在理由
ラウンドアバウト・ホスティングは、「コンテンツ変換製品やサービスは高すぎる」「携帯サイトを手作りするのは大変だ」という中で、もっと安く素晴らしいコンテンツが作れないと「モバイルはこれ以上発展しない」という危機感から生まれています。サービスコンセプトは次のようなものです。
今やクラウドという時代にあって、サーバーや製品を個々のユーザーが購入する時代ではなくなってきています。そのような意味からもホスティングに組み込まれているのは、ユーザニーズにマッチした形といえるのではないでしょうか？
携帯コンテンツ変換ASP：プロキシ型携帯変換の限界
敢えて単刀直入に書けば、次のようになります。
「ドコモ端末用にコンテンツを作っているので、ドコモ端末は変換を通さずにアクセスする」という一見理に適ったように思える構成でも２つの疑問が生じます。
「ドコモ端末用にコンテンツを作っているので、ドコモ端末は変換を通さずにアクセスする」という一見理に適ったように思える構成でも２つの疑問が生じます。
- ドコモ端末に生じる問題は解決してくれないのか？
- であれば、ドコモ端末での問題は自分で解決しなくてはならないのか？
キャッシュ容量制限や端末毎の画面サイズ違いを吸収せず、CSSの使えないドコモが基準だとすれば、コンテンツ変換エンジンとしては、今後も多くの生産性向上は望めないことになります。
携帯コンテンツ変換ASP：プロキシ型の２URLとドコモ無変換の問題
プロキシ型携帯コンテンツ変換ASPでは、２つのURLが存在します。１つは元のコンテンツのあるWebサーバで、もう1つが変換プロキシサーバです。多くの場合、まず本当のURLを持っているコンテンツサーバにアクセスし、au/softbankの時は変換サーバにリダイレクトされます。そして、この事がこの方式の問題となるケースがあります。
携帯コンテンツ変換ASP：コストと運用面の比較
ASP利用では導入コストが低くても、運用コストが高ければ元も子もありません。課金体系について、ラウンドアバウト・ホスティングと変換プロキシ型ASPでは大きく異なっています。
| 基本月額料金 | 従量超過課金 （1PV換算） | |
| ラウンドアバウト・ホスティング | 2～3万円（共用）、10万～12万円（専用） ※サーバ、メモリ、ディスク、回線等のホスティングサービスを含む | なし |
| プロキシ型変換ＡＳＰ | A：7.5万円（10万PV程度） B：25万円（100万PV） | あり |
携帯コンテンツ変換ASPの種類
ラウンドアバウトや他社競合製品を導入する場合、自ら選定・テスト・購入・導入する必要が生じます。その手間を省くことができるのが、ASPです。ASPであれば、利用したい期間だけ使えたり、製品テストなどをする必要が無いので、気軽に導入が図れます。そして、携帯変換にもASPがあり、2種類あります。
携帯サイト制作のヒント：行間が詰まって読みにくいので改善したい
新着情報など一覧でテキストを見せるようなページで、行間が詰まっていると読みにくい印象を与えます。背景色の付いたボックスと接する箇所は特に余白が欲しくなります。
PCサイトではCSSのline-heightやmarginプロパティを使えばできますが、携帯サイトの場合、最も普及するiモードブラウザ1.0のFOMAではこれらのプロパティが効かず行間を調整できない事情があるので、画像を使った何らかの方法でしか余白を調整することしかできません。
PCサイトではCSSのline-heightやmarginプロパティを使えばできますが、携帯サイトの場合、最も普及するiモードブラウザ1.0のFOMAではこれらのプロパティが効かず行間を調整できない事情があるので、画像を使った何らかの方法でしか余白を調整することしかできません。
携帯サイト制作のヒント：アイコンを使ったわかりやすいナビゲーション
PCサイトではアイコンと言えば画像ですが、携帯サイトではアイコンに絵文字を使うことが一般的です。なぜなら、文字と同じくらいの画像を常に配置しておくことが難しいからです（画面サイズの数だけの画像と、それを切替える仕組みが必要）。
ラウンドアバウトを使うと画像は画面のサイズと連動して縮小するので、PCサイトのような多彩なアイコンを自由に使うことができるようになります。その時のアイコン画像の作り方・使い方について説明します。
ラウンドアバウトを使うと画像は画面のサイズと連動して縮小するので、PCサイトのような多彩なアイコンを自由に使うことができるようになります。その時のアイコン画像の作り方・使い方について説明します。
携帯サイト制作のヒント：回り込みはできますか？
ページレイアウトを工夫する際画像のテキスト回り込みは携帯サイトでもよく見られます。ドコモ・ソフトバンクはCSSのfloatプロパティ、auはalign属性とキャリアによって方法が異なり、一般的にはベタベタに両方を書いたりキャリアによって記述を分けたりします。
ラウンドアバウトなら言語変換と外部CSSで簡単にワンソースで回り込みができます。外部CSSに対応しないiモードブラウザ1.0のFOMAにはCSSプロパティをインライン展開し、floatプロパティが効かないau向けにはalign属性に言語変換します。
ラウンドアバウトはサンプルCSSファイルに回り込みと回り込み解除用のクラスセレクタを用意しています。これを利用しワンソースで回り込みする例をお見せします。
ラウンドアバウトなら言語変換と外部CSSで簡単にワンソースで回り込みができます。外部CSSに対応しないiモードブラウザ1.0のFOMAにはCSSプロパティをインライン展開し、floatプロパティが効かないau向けにはalign属性に言語変換します。
ラウンドアバウトはサンプルCSSファイルに回り込みと回り込み解除用のクラスセレクタを用意しています。これを利用しワンソースで回り込みする例をお見せします。
携帯サイト制作のヒント：外部CSSは使えますか？
一般的に、３キャリア向けXHTMLページを作るには外部CSSを使用せずstyle属性を使ったインラインCSSを使用する方法が推奨されています。
これは、auとソフトバンク、iモードブラウザ2.0搭載のドコモは外部CSSに対応するが、現在最も普及するiモードブラウザ1.0のFOMAでは外部CSSに対応せずインラインCSSだけという事情によるものです。
ラウンドアバウトはiモードブラウザ1.0のFOMAでも外部CSSを使った携帯サイトを見せることができます。class属性に名称（セレクタ）を書けば、ラウンドアバウトが外部CSSファイル中の該当するCSSプロパティをインラインCSSに展開するからです。ページの装飾に関する記述をXHTMLのそこかしこに散らばすのでなく外部CSSファイル一箇所に集められることのメリットは大きいです。
これは、auとソフトバンク、iモードブラウザ2.0搭載のドコモは外部CSSに対応するが、現在最も普及するiモードブラウザ1.0のFOMAでは外部CSSに対応せずインラインCSSだけという事情によるものです。
ラウンドアバウトはiモードブラウザ1.0のFOMAでも外部CSSを使った携帯サイトを見せることができます。class属性に名称（セレクタ）を書けば、ラウンドアバウトが外部CSSファイル中の該当するCSSプロパティをインラインCSSに展開するからです。ページの装飾に関する記述をXHTMLのそこかしこに散らばすのでなく外部CSSファイル一箇所に集められることのメリットは大きいです。
フリースタイルな携帯言語変換：フォーム入力モード
フォームの入力モードを内容に応じて自動で切り替える入力補助機能は、テンキーで操作する携帯サイトにとって使い勝手を大きく向上させるので、是非取り入れたいものです。生年月日や電話番号のように数字入力を要求しているのであれば、初めから数字入力モードになっていて欲しいものです。
指定方法はキャリアやXHTMLかHTMLかによって色々です。それにキャリア互換があるとかないとか、キャリアによって動作が合わないだとか、とにかくもう実にややこしいことになっています。
指定方法はキャリアやXHTMLかHTMLかによって色々です。それにキャリア互換があるとかないとか、キャリアによって動作が合わないだとか、とにかくもう実にややこしいことになっています。
フリースタイルな携帯言語変換：絵文字
携帯絵文字はキャリアごとに種類や数も異なり書き方や互換性もバラバラなので、何らかの絵文字変換ソリューションの導入がコストを抑える手段と考えるのが一般的です。
元コンテンツに最も使われやすいのはドコモのiモード絵文字です。絵文字入力ツールが用意され入力が容易なことや、絵文字の種類が最も少ないのでマッピングを考えたときiモード絵文字をベースに考えるのが最も都合がよく、逆を取るのは高コストになるからでしょう。
こうした理由からか他の変換ソリューションの多くは変換元絵文字をiモード絵文字としているので、携帯サイト開発の現場で使うことのできる絵文字は自ずとiモード絵文字に限定されます。
元コンテンツに最も使われやすいのはドコモのiモード絵文字です。絵文字入力ツールが用意され入力が容易なことや、絵文字の種類が最も少ないのでマッピングを考えたときiモード絵文字をベースに考えるのが最も都合がよく、逆を取るのは高コストになるからでしょう。
こうした理由からか他の変換ソリューションの多くは変換元絵文字をiモード絵文字としているので、携帯サイト開発の現場で使うことのできる絵文字は自ずとiモード絵文字に限定されます。
携帯コンテンツ変換の選定基準：お試し変換ソース
携帯コンテンツ変換の導入を考えているなら、実際にどんなソースが動作するのか、試すことが必要です。開発や運用の負担がどれくらい減るのか、どの程度の表現力があるかは試さないと分かりません。
ここでは、ラウンドアバウトでの特長が分かり、おそらく他のソリューションでは機種毎に見え方異なるだろう、シンプルでプレーンなhtmlを提示します。製品検討時には、是非こちらを試してみてください。
ここでは、ラウンドアバウトでの特長が分かり、おそらく他のソリューションでは機種毎に見え方異なるだろう、シンプルでプレーンなhtmlを提示します。製品検討時には、是非こちらを試してみてください。
フリースタイルな携帯言語変換：DOCTYPE宣言
XHTMLでページを作る際XML宣言の他DOCTYPE宣言の記述が必要ですが、何も見ずに空で宣言をタイプする人は少ないと思います。そこでDOCTYPE宣言の内容を書籍やインターネットから調べるのですが、「携帯 XHTML DOCTYPE」で検索すると、各キャリア向けのDOCTYPE宣言を解説するページがヒットします。キャリアごとに推奨するものが異なり、iモードの場合さらにiモードXHTMLバージョンに応じて記述が変わるので、「まとめ」と称しながら、種類が多くなっています。これを読んだサイト開発者としては結局どれを書けばよいのか悩んでしまうでしょう。またどれか一つDOCTYPE宣言を決めたら、記述するXHTMLもそれに従うべきなのか？と、さらに開発者を迷わせることになります。
フリースタイルな携帯言語変換：マーキー
携帯コンテンツを作る際、マークアップ言語は何を使ったらよいのか？ラウンドアバウトでは次のように考えています。
- XHTMLなら何でもOK
- CSS利用可能
古い端末を非対応にしたい→RA非対応端末リダイレクト機能
一応、もしかしたら使っているかもしれない古～い端末があります。どんものがあるのでしょうか？
・ドコモ
P501i 1999年発売 白黒表示 96x120ピクセル表示 5KBキャッシュ SSL非対応
N502i 2000年発売 4色表示 118x129ピクセル表示 5KBキャッシュ SSL非対応
・ソフトバンク（2000年当時はJ-PHONE）
J-T04 2000年発売 256色表示 96x90ピクセル表示 6KBキャッシュ SSL非対応
J-T04 2001年発売 256色表示 118x124ピクセル表示 6KBキャッシュ SSL非対応
・au
A3013T 2002年発売 65536色表示 144x135ピクセル表示 9KBキャッシュ SSL対応
A3012CA 2002年発売 65536色表示 125x147ピクセル表示 9KBキャッシュ SSL対応
・ドコモ
P501i 1999年発売 白黒表示 96x120ピクセル表示 5KBキャッシュ SSL非対応
N502i 2000年発売 4色表示 118x129ピクセル表示 5KBキャッシュ SSL非対応
・ソフトバンク（2000年当時はJ-PHONE）
J-T04 2000年発売 256色表示 96x90ピクセル表示 6KBキャッシュ SSL非対応
J-T04 2001年発売 256色表示 118x124ピクセル表示 6KBキャッシュ SSL非対応
・au
A3013T 2002年発売 65536色表示 144x135ピクセル表示 9KBキャッシュ SSL対応
A3012CA 2002年発売 65536色表示 125x147ピクセル表示 9KBキャッシュ SSL対応
携帯サイト開発の高コスト構造
携帯コンテンツ変換ソリューションの導入の大きな目的はコスト削減です。どのコストがどの位削減されるかは、前提システムやコンテンツによって大きな差がでますが、開発・運用全体のコスト構造を考える必要があります。一般に開発費以上に保守費が大きな問題とされます。ラウンドアバウトのコスト削減に対するアプローチ、それは...
- 開発・保守を誰でも可能とし、専門知識を不要にすることで、人件費を抑える
携帯コンテンツ変換の選定基準：環境構築と問題の切り離し
携帯コンテンツ変換を検討するに当たり、機能や性能の他に考慮すべき事項に環境構築と問題発生時の対応があります。
■環境構築について
通常、４つの環境が関係してきます。
■環境構築について
通常、４つの環境が関係してきます。
- 本番運用環境
- 本番試験（ステージング）環境 ... 本番とほぼ同じ状態に保たれている試験環境
- 開発環境 ... 開発現場の結合テスト環境
- 開発者ローカル環境（PC）
携帯コンテンツ変換の選定基準：変換エラーと変換アーキテクチャー
コンテンツ変換システムにおいて、変換仕様はもちろん重要ですが、
正しい記述で変換仕様にのっとった例）
<FONT color="black" >Hello</FONT>
→ <span >Hello</span>
実は、変換仕様「外」の振る舞いも、負けず劣らず重要です。
間違った記述の変換仕様外の例）
正しい記述で変換仕様にのっとった例）
<FONT color="black" >Hello</FONT>
→ <span >Hello</span>
実は、変換仕様「外」の振る舞いも、負けず劣らず重要です。
間違った記述の変換仕様外の例）
- <FOMT color="black" >Hello</ont> （存在しないタグ）
- <FONT >Hello (閉じてない)
- <FONT colorblack=" >Hello</FONT> （属性記述に間違い）
- <FONT color="black" ><div>A</div>Hello</FONT> (インラインタグ内にブロックタグ)
携帯コンテンツ変換の選定基準：スループット
パフォーマンス（1アクセスの平均レスポンスタイム）と並んでユーザにとって重要な指標がスループット（1秒間あたりの処理数）です。「同時接続数はどれくらいですか？」などとよく聞かれます。スループットはサーバ台数に直接に影響を与える数字です。当然、サーバ台数が少なくて済むように、より高い性能であることが望ましいです。
１/スループット＝パフォーマンス
なのですが、両者には別の相関関係があって、アクセスがスカスカの状態ではパフォーマンスは非常に良く、アクセスが増えてくれば徐々にパフォーマンスは劣化し、アクセスが増えすぎると両方落ち込みます。コンテンツ変換製品でもスカスカの状態では、パフォーマンスの違いは、あまり出ないかもしれません。問題はアクセスが増えてきてからで、どこまでスループットを上げることができるかが重要です。スループットが最大のときのパフォーマンス比較ができれば、信頼できる製品性能比較になるでしょう。全エントリーのパフォーマンスUPの方法はスループット向上にも役立つので今回は設計の話ではなく、実際の２つの計測データを提示してスループットについて説明していきます。
携帯コンテンツ変換の選定基準：パフォーマンス
携帯コンテンツ変換エンジンは、システムのフロントに位置し、常にレスポンスが通過するので、そのパフォーマンスは非常に重要です。パフォーマンス・データはコンテンツや環境や計測方法に非常に大きく依存し、客観的な方法は存在しないので分かり難いものです。良いデータを出しすぎてユーザからクレームをもらうのも好ましくなく、悪いデータを出すこともできず...とベンダー側も悩みます。
ラウンドアバウトでは、多少のリスクをとってパフォーマンスデータを公開しています。また1,000/秒のスループットも表明しています。画像キャッシュがある状態で、ノーマルなサーバで１ページ10画像程度のコンテンツで試せば、HTML/画像を合わせて、秒間1,000アクセスは控えめに言っても出るでしょう。ただ、他製品では「独自な技術で高速」というだけで、データも中身が分かりません。
携帯コンテンツ変換の選定基準：ネットワーク設計とセッション
携帯コンテンツ変換を選定する際、重要なポイントの１つは製品自体がセッションを使う処理をするかどうかです。携帯コンテンツ変換製品がセッションを使う機能がある場合、ネットワーク設計に大きな制約が生じます。セッションを使用する代表的な機能が、「ページ分割」と「クッキーエミュレーション」です。
セッションを使うと次のような制約が発生します。
セッションを使うと次のような制約が発生します。
- アクセス端末は常に同じ特定変換サーバを通過する必要がある
- このため単純なラウンドロビンが使用できず、パラメータ等による振分けが必要となる
- アプリケーションもセッションを利用し、特定サーバでの処理を要求する場合がある
- この時、１つの携帯からは特定変換サーバと特定Webサーバを通過するように、ネットワーク設計しなくてはならない。
携帯コンテンツ変換の選定基準：ネットワーク設計
コンテンツ以上にネットワーク構成はシンプルでなくてはなりません。複雑なネットワークはトラブルを招き易く、コストも高く、変更リスクも高くなります。ネットワーク設計・設定といっても、ルータやロードバランサ、DNS、HTTPサーバなど様々なレベルのものがあり、１つの課題を解決する方法も多種多様です。ネットワーク技術に長けたエンジニアは少なく、基本的に高コストです。そのため、ネットワークをシンプルにすることはシステム設計上の最重要項目の１つです。
負荷分散とフェールオーバーを考慮した複数台のサーバ構成をする場合、サーバ型とラウンドアバウトではネットワーク構成が大幅に異なります。
フェールオーバーを考慮したサーバ型とラウンドアバウトのシステム構成
携帯コンテンツ変換の選定基準：サーバー台数
ラウンドアバウトと他社製品の一番の違いは、サーバー台数です。もっとも違いが分かりやすいのは、変換サーバーをハードウェアとして提供している製品です。
例えば、Webサーバーが3台ある環境で、ハード提供型は3台の変換サーバーが必要で、合計6台となります。一方ラウンドアバウトはWebサーバーに組み込まれますので3台のままです。
例えば、Webサーバーが3台ある環境で、ハード提供型は3台の変換サーバーが必要で、合計6台となります。一方ラウンドアバウトはWebサーバーに組み込まれますので3台のままです。
サーバー型とラウンドアバウトの台数の違い
携帯コンテンツ変換の選定基準
携帯コンテンツ変換を導入を検討するに当たり、どのような点を選定基準とするか、まとめていきたいと思います。ラウンドアバウトコンセプトというBlogの中では中立性を保つことはできませんが、ここで触れる内容こそラウンドアバウトのコンセプトそのものであり、その違いを示すことができればよいと思います。
常に製品は、様々な機能の有無を○×付けて評価されますが、実は”×”であることにも強い意味がある場合もあります。製品のコンセプトを理解してもらうことは、その製品の最も有効な使い方や将来性について、ユーザーに安心して製品を使ってもらうために大事なことだと考えます。
コンセプトは製品の外殻であり、この殻が内側に位置する色々な機能の性質・性能に決定的な影響を及ぼします。ユーザーからすれば最小限の機能さえ満たせれば、コンセプトから生じる製品の基本特性が一番重要です。それは製品を選定する上で最初に必要な情報でもあるので、ここで選定基準としてまとめていきたいと思います。
常に製品は、様々な機能の有無を○×付けて評価されますが、実は”×”であることにも強い意味がある場合もあります。製品のコンセプトを理解してもらうことは、その製品の最も有効な使い方や将来性について、ユーザーに安心して製品を使ってもらうために大事なことだと考えます。
コンセプトは製品の外殻であり、この殻が内側に位置する色々な機能の性質・性能に決定的な影響を及ぼします。ユーザーからすれば最小限の機能さえ満たせれば、コンセプトから生じる製品の基本特性が一番重要です。それは製品を選定する上で最初に必要な情報でもあるので、ここで選定基準としてまとめていきたいと思います。
フットプリントの導入意義
フットプリントについては詳しい機能の説明や使えるツールなどはHPを参照してください。
- 携帯サイトのユーザー認識できる生ログが記録できる
これがフットプリントの今までに無い価値なのですが、ではフットプリントが無ければどうなるのか、検証してみたいと思います。
新しい携帯サイトのアクセス解析の方法：フットプリント
もうすぐラウンドアバウト製品ファミリーである、ラウンドアバウト・フットプリントがv1.0.1となってリリースされます。フットプリントプリントはその名の通り、アクセスログに足跡をつけるツールです。ですから、これ単独ではアクセス解析はできません。しかし、このツールは携帯アクセス解析に大きな進歩をもたらすことができる製品です。
■背景
以前はあまり携帯ではアクセス解析は必要ありませんでした。なぜなら公式サイトが中心であり、アクセス数が多ければ公式メニューの上位に表示され、これがさらに入会を増やす（売上UP）というサイクルだったからです。ところが携帯でもECやコミュニティなどの勝手サイトが台頭する流れの中で、キャリアがTOPメニューに検索を設けるようになりました。検索エンジンも携帯サイト用のクローラーで情報を集めるようになり、ここに至って携帯サイトでもSEOやSEMが必要とされるようになりました。公式サイトでは試してもらって入会するまでが勝負ですが、勝手サイトではPC同様に常にユーザの行動分析をしないとアクセス（利益）が増えません。このような状況下で、携帯サイトでもアクセス解析の重要性がどんどん大きくなっています。
■フットプリントはなぜ開発されたか？
アクセス解析はWebの草創期から様々なツールが有料・無料であり、それぞれ発展を遂げているのですが、非常に有名なツールであっても携帯には使えませんでした。それは先のエントリーでも詳しく書いていますが、一言で言えば「使える正確な生ログが無いため」です。携帯アクセス解析は、生ログが無い中でどうするか？という問題とも言い換えられます。
■背景
以前はあまり携帯ではアクセス解析は必要ありませんでした。なぜなら公式サイトが中心であり、アクセス数が多ければ公式メニューの上位に表示され、これがさらに入会を増やす（売上UP）というサイクルだったからです。ところが携帯でもECやコミュニティなどの勝手サイトが台頭する流れの中で、キャリアがTOPメニューに検索を設けるようになりました。検索エンジンも携帯サイト用のクローラーで情報を集めるようになり、ここに至って携帯サイトでもSEOやSEMが必要とされるようになりました。公式サイトでは試してもらって入会するまでが勝負ですが、勝手サイトではPC同様に常にユーザの行動分析をしないとアクセス（利益）が増えません。このような状況下で、携帯サイトでもアクセス解析の重要性がどんどん大きくなっています。
■フットプリントはなぜ開発されたか？
アクセス解析はWebの草創期から様々なツールが有料・無料であり、それぞれ発展を遂げているのですが、非常に有名なツールであっても携帯には使えませんでした。それは先のエントリーでも詳しく書いていますが、一言で言えば「使える正確な生ログが無いため」です。携帯アクセス解析は、生ログが無い中でどうするか？という問題とも言い換えられます。
imgタグビーコン方式の問題点②高コスト
■ビーコン式ASPは高い
imgタグビーコン方式は通常ASPで提供され、決して安くはありません。有用なサービスを開発・運用しているので当然なのですが、携帯アクセス解析にとってはこれこそが最大の問題です。定常的な固定費のかかるシステムは敬遠される傾向にあり、場合によってはサーバやコンテンツ保守より高価になってしまうアクセス解析の普及の妨げになっていると思われます。
imgタグビーコン方式は通常ASPで提供され、決して安くはありません。有用なサービスを開発・運用しているので当然なのですが、携帯アクセス解析にとってはこれこそが最大の問題です。定常的な固定費のかかるシステムは敬遠される傾向にあり、場合によってはサーバやコンテンツ保守より高価になってしまうアクセス解析の普及の妨げになっていると思われます。
imgタグビーコン方式の問題点①SSL通信時
■ドコモ端末のSSL通信制限
完璧なようなimgタグビーコン方式ですが、ドコモ端末仕様の制限が立ちはだかります。ドコモ端末はSSL通信時に２つの制限があります。
★ドコモ端末におけるSSL通信時の制限
- ホストドメイン以外の画像へアクセスすることができない
- iモードID（キャリアユーザーID）を取得することができない
SSL通信領域は、会員情報登録フローや商品購入フローなど、コンバージョンに関わるWebで最も重要なページが含まれています。ドコモの制限があるとSSL通信時にはビーコンを飛ばすことができません。また、通信可能なホストドメイン上でさえユーザーIDを取得できないので、致命的な状況です。このため、多くのサービスではSSL通信には対応していません。
現在の携帯サイトのアクセス解析の方法
■方法１：アプリケーションでセッションパラメータを生成し引き回す
携帯サイトのアクセス解析が特殊な理由
携帯サイトも当然アクセス解析が必要ですが、PCであればとりあえずアクセスログを解析ツールで読み込ませて基本的な解析を開始できます。webalizerやAWStatsなど無料のツールもあります。ただし、これらのツールはIPベースでユーザー識別するので、個人自宅からのアクセスはほぼ同じアドレスからアクセスされるのでよいのですが、ゲートウェイを経由する企業からのアクセスを考慮すると、セッション数（ユーザー数）などのデータには正確性に問題があります。問題はありますが、なんといってもコスト０で実現できる点は大きな利点です。
フォント問題は画像で解決できる
テキストには、フォントが不定かつ機種で異なるのでデザイン計算できないという異機種の問題と、1行の文字数は個々の端末としては固定であり自由ではなく、高さもいつも決まった分必要だという問題があります。後者は当たり前のことかもしれませんが、デザインを考える上では制約となってしまします。
ラウンドアバウトの下で画像を使って、TOPメインメニューを作れば、文字数もフォントも自由に、そしてどんな端末でも同じように見えます。下図の例は５つの画像を並べた例です。
ラウンドアバウトの下で画像を使って、TOPメインメニューを作れば、文字数もフォントも自由に、そしてどんな端末でも同じように見えます。下図の例は５つの画像を並べた例です。
携帯端末のフォント問題
昔の端末は1行が8文字～１２文字と決まっていて大きさも変更できませんでした。しかし、現在の端末はサイズが選択でき、かつ組込フォントは機種毎に異なり画面幅も違うので、1行に何文字とは決められません。htmlではフォントサイズは指定できますが、表示を正確にコントロールすることはできません。そもそも、HTML自体がフォントを絶対的な大きさで表現する技術ではないので、コントロールできたところで本来あまり意味は無いのですが、携帯サイトでは事情が異なっています。
よくあるのがTOPメインメニューで、ユニクロの携帯サイトを例に取れば、
MEN｜WOMEN｜KIDS｜BABY｜HOME
となっています。このメニューの問題を挙げてみましょう。
よくあるのがTOPメインメニューで、ユニクロの携帯サイトを例に取れば、
MEN｜WOMEN｜KIDS｜BABY｜HOME
となっています。このメニューの問題を挙げてみましょう。
２G端末の現状と対応
２Gも対応したいんです。と、要望される人も多いのですが、まずは数字から抑えることが重要です。
| ２Ｇサービス | １月末 | ４月末 | ７月末 |
| ドコモPDC | 666万 | 556万 | 461万 |
| ソフトバンクPDC | 275万 | 197万 | 150万 |
| ａｕCDMAOne | 34万 | 31万 | 29万 |
ラウンドアバウトが実現するリッチな携帯サイト
最初にリッチの定義からします。
ユービリティが高いとは、コンテンツが見易く、欲しい情報に素早くアクセスし、正確な情報を得ることができ、操作に迷わないデザインです。最終的にコンテンツ制作者の腕にかかってくることですが、携帯サイトでは、様々な制約があることから、特殊な腕を要求していました。例えば...
- リッチ＝ユーザビリティが高い
ユービリティが高いとは、コンテンツが見易く、欲しい情報に素早くアクセスし、正確な情報を得ることができ、操作に迷わないデザインです。最終的にコンテンツ制作者の腕にかかってくることですが、携帯サイトでは、様々な制約があることから、特殊な腕を要求していました。例えば...
- トップメニューは項目を縦棒で区切る
- タイトルのバックグラウンドカラーを設定して目を引く
- 絵文字の使い方を統一する
- 半角スペースで見出しの字数を揃える
携帯サイトのデザインが貧弱な理由
この業界にいる身としては悔しいですが、一般的に携帯サイトはデザインは貧弱と思われています。理由は、小さな画面、テキスト中心、単純なレイアウト（人によってはI型とか言う）などによるのでしょう。
小さな画面は仕方ないとして（携帯できないと意味ないですから...）、テキスト中心、単純なレイアウトになってしまう理由として、よく言われるのが
- 携帯は画像の処理が苦手
- 画像は遅いのでテキスト中心にすべき
- 携帯は画面が小さいので、単純なデザインの方が好まれる
などですが、果たしてそうでしょうか？
携帯画像：ブラウザーキャッシュ容量問題：ラウンドアバウトの解決法
ラウンドアバウトは、コンテンツ制作からブラウザーキャッシュ容量の制約を完全に除去します。アプローチとして、ブラウザーのハードウェアの容量を上げられないのであればコンテンツの容量を下げるしかありません。ラウンドアバウトも他の一部のソリューションと同様に画像の品質をダウンさせることで、容量を削減しますが、根本的に違うところは次の1点です。
- アクセス端末のキャッシュ容量内に収まるように、ページ中の全画像を変換する
携帯画像：ブラウザーキャッシュ容量問題：これまでの対策
ブラウザーキャッシュ問題は昔から携帯開発者を悩ませていた最大の問題です。ブラウザーキャッシュが10Kバイトのような時代には、テキストだけでも制限を越えてしまう場合もあり、１ページあたりの情報を少なくするしかありませんでした。しかし、今日の１００Kバイト以上の端末がほとんどを占めるようになると、まずテキストでは超えない制限となったので、画像をいくつ載せるか、どのクオリティにするか、という問題に置き換わってきています。ですから、このBlogでもブラウザーキャッシュ容量問題は画像の話題としています。
携帯サイト画像：VGA問題
画像の問題のもう１つである容量の違いに触れる前に、新しい問題としてVGA対応について触れましょう。
これまでの３～４年間はQVGA（横幅２４０px）の端末が事実上の標準機であり、仕様上の上級機でした。より古い端末でも200pxを切るような端末は５～６年前でもほとんどありません。つまり、画面サイズは上位機種から15%程度の違いでした。このため、さらに古い端末をサポート対象にせず、単純なレイアウトだけであれば、２２０px程度を基準に作ることでデザインも概ね大きく崩れることがありませんでした。
このような状況の中でソフトバンクからVGA（横幅４８０px）の端末が２年位前に発売され、この５月にはドコモの新機種の大部分はVGAサイズとなりました。VGAはQVGA比で縦横２倍、面積４倍という大きさであり、これまでと全くスケールが違います。サイズが大きくなったVGA端末では、当然キャッシュ容量も大きく拡大されています（ドコモ500k,ソフトバンク300k）。このことから、新たな機種違い問題が出てきています。
これまでの３～４年間はQVGA（横幅２４０px）の端末が事実上の標準機であり、仕様上の上級機でした。より古い端末でも200pxを切るような端末は５～６年前でもほとんどありません。つまり、画面サイズは上位機種から15%程度の違いでした。このため、さらに古い端末をサポート対象にせず、単純なレイアウトだけであれば、２２０px程度を基準に作ることでデザインも概ね大きく崩れることがありませんでした。
このような状況の中でソフトバンクからVGA（横幅４８０px）の端末が２年位前に発売され、この５月にはドコモの新機種の大部分はVGAサイズとなりました。VGAはQVGA比で縦横２倍、面積４倍という大きさであり、これまでと全くスケールが違います。サイズが大きくなったVGA端末では、当然キャッシュ容量も大きく拡大されています（ドコモ500k,ソフトバンク300k）。このことから、新たな機種違い問題が出てきています。
携帯サイト画像：画面サイズ問題
携帯サイト制作の肝とも言える画像問題について考えます。根本の問題は２つです。
ここでは画面サイズの問題にフォーカスします。歴史的経緯（？）から過去の端末において、端末のブラウザーからはみ出してしまうとエラーになり、表示されないという問題がありました。つまり、
ということです。この問題に対処するのが一般的な画像変換ソリューションであり、大きすぎてエラーになってしまう事態を防止します。
しかし
- 機種毎に画面サイズが異なる
- 機種毎に容量が異なる
ここでは画面サイズの問題にフォーカスします。歴史的経緯（？）から過去の端末において、端末のブラウザーからはみ出してしまうとエラーになり、表示されないという問題がありました。つまり、
- 大きすぎて表示できない
ということです。この問題に対処するのが一般的な画像変換ソリューションであり、大きすぎてエラーになってしまう事態を防止します。
しかし
HTMLは何を使ったらいいのか？
全キャリア対応の携帯サイトを作る際に最初に決めなければいけないものが、使用するHTMLです。そして、ほとんどの場合、iモードXHTMLを推奨しています。もしサイトが2Gもサポートしたいのであれば、iモードHTML（CHTML）となるか、2G/3Gで２つの言語を出し分けることになります。
細かい仕様の違いは他の情報源を見ていただくとして、実は表現力の違いはiモードXHTMLとCHTMLにはあまりありません。大きなところで背景色が使えるところくらいです。そしてchtmlは2G/3Gで基本的には見れますが、xhtmlは2Gでは見ることができません。なのでxhtmlの時代ということを考えなければCHTML（ver.7）を利用するのは１つの合理的判断だと思います。
携帯サイト制作会社の意識の壁
ラウンドアバウトを紹介して回る先にモバイルコンテンツプロバイダー（MCP）は外せません。ラウンドアバウトの良さを一番に理解してくれる企業にでしょうから。様々なお付き合いの中で、開発現場の方から開発マネージャーや経営TOPに近い人まで多くの人に見てもらってきました。ほとんどの人からポジティブなコメントを頂いていますが、それは置いておいて、常ではないけどよく聞く期になる言葉があります。
Web制作会社と携帯サイト制作会社の間の深い溝
ラウンドアバウトが出来上がろうとしていた時期に、Web制作会社（携帯も作るがPCサイトメインの）へ製品紹介をしていた時の話です。そもそもなんでWeb制作会社へ行ったかと言えば、ラウンドアバウトは携帯の煩わしい問題を無くしてしまうので、業務の幅が広がるという話をしにいった訳です。そこで聞いた話は、この先何度も聞くことになるのですが、結構考えさせられるものがありました。要約すると...
「携帯サイト制作は実のところ、営業上できるとは言っていますが、あまりやりたくはないのです。大体、PC/携帯両方を希望するクライアントが多いのですが、その難しさとコスト及び効果を説明することで、時期尚早として２次開発などに変更して、結果的に受注しないようにしているんです」
ラウンドアバウトのコンセプトを公開していきます
モバイルWebプラットフォーム：ラウンドアバウトのオフィシャルではあるけど、製品サイトには載っていないような情報を、携帯サイト開発にまつわる話を絡めて公開していくBlogです。
ラウンドアバウトとは以下の製品のことです。
このBlogを通じてラウンドアバウトのコンセプトを広く知ってもらえるとよいなぁと思っています。そして、携帯サイト開発について色々な意見を聞ければよいなぁと思っています。
