モバイルコンテンツ作りに於ける推奨事項について解説します。
現在、モバイルコンテンツに於ける推奨事項を纏めた文書としては、ウェブ技術標準化団体・W3Cが策定中のモバイルウェブ・ベストプラクティスがあります。
「.mobi」ドメインを管理しているmTLDも、ドメイン運用の際の推奨事項としてこのモバイルウェブ・ベストプラクティスに準じた約束事を.mobi スイッチ・オン！ ガイドにて公開しております。
ここでは、モバイルウェブ・ベストプラクティスの中からモバイルコンテンツの作成の際に特に抑えておきたいポイントについて、解説する事とします。
この文書では、推奨事項のうち、特に実践すべき項目を撰んで解説しております。
また、一部項目で日本の携帯電話事情には必ずしも当て嵌まらない面もありますので、その点に関しては補足させて頂きました。
モバイル端末では、フレームを処理出来ない端末が少なくありません。
モバイルコンテンツでは、フレームは絶対に使わないで下さい。
ポップアップウィンドウを出す機能が無い端末もあります。
いや、そんな機能があったとしても、狭い画面をポップアップウィンドウが占領したら閲覧の邪魔にしかなりません。
以上の理由から、モバイル向けのコンテンツではポップアップウィンドウを使わないで下さい。
また、デスクトップ端末向けコンテンツみたいにリンクを別ウィンドウで開くような機構も使ってはいけません。
携帯端末は、デスクトップ端末みたいにカーソルを三百六十度自由に動かせない端末が大半です。
また、スクロールの概念の無い端末も否定出来ません。
いずれにしても、モバイル向けコンテンツではイメージマップを絶対に使ってはいけません。
リフレッシュとはHTTPの機能の一つで、リソース表示後一定秒数が経過したら指定されたりソースを取得すると言うものです。
本来、コンテンツ配信時に附与するHTTP応答ヘッダで指定しますが、多くの場合<meta>要素を用いてHTML文書内で指定します。
しかしながら、この機能には幾つも問題があります。
以上の理由から、リフレッシュは使うべきではありません。
MIMEタイプとは、コンテンツの型を示すデータです。
HTML文書のMIMEタイプは text/html となっておりますが、通常のXHTML文書では application/xhtml+xml とする事が推奨されております。
一方、XHTML モバイル・プロファイル文書の場合、特別なMIMEタイプとして application/vnd.wap.xhtml+xml が指定されておりますが、application/xhtml+xmlでも良い事とされております。
XHTML モバイル・プロファイルを策定したOMA(オープン・モバイル・アライアンス)では、在来HTMLの型である text/html も認める事を求めておりますが、W3Cでは text/html はなるべく使わないように求めております。
以上の点から、以下のいずれかのMIMEタイプを使用する事が求められます。
application/vnd.wap.xhtml+xmlapplication/xhtml+xmltext/htmlapplication/vnd.wap.xhtml+xml は原則として扱えません。また、XHTML世代より前のブラウザでは、デスクトップ端末/モバイル問わず application/xhtml+xml も扱えず、text/html で配信するしかありません。正しいMIMEタイプを設定するにはサーヴァの知識が必要になりますが、多くのサーヴァでは、好ましくはないものの text/html を送出するようになっている筈です。
text/html に固定されるのは已むを得ないと思われます。端末はサーヴァにコンテンツを要求する際に、ACCEPT-CHARSETフィールドで対応している文字コードを通知します。
ここで指定された文字コードを使って配信しないと、文字化けなどが起こる事になります。
ただ、日本ではｉモードなどが仕様でシフトJISコードを指定しており、ACCEPT-CHARSETフィールドを送信しない端末もありますので、静的なコンテンツの場合にはシフトJISコード限定としたコンテンツ作成は已むを得ないでしょう。
尚、XHTML(を含むXML一般)では、UTF-8コードを使う事が推奨されており、海外端末も殆どの端末がUTF-8コードに対応しております。
このため、本来はUTF-8コードでコンテンツを作成して配信する事が望ましいと言えますが、日本では上記の理由からUTF-8コードは使えません。
それでも、サーヴァサイドで文字コードを変換出来るようにしておけば、海外端末にはUTF-8コードに変換する事で海外の方にも日本語コンテンツの閲覧が可能になる事が期待出来ます。
<img>要素にalt属性を与えるのは基本中の基本ですが、モバイルの場合には特に有用となります。
通信料の節約のため、或いは通信時間の削減のため、画像を非表示にする事は充分予想されます。
また、通信速度の遅い端末や、処理速度の遅い端末では、画像を表示し切るまでに時間が掛かる場合もあり、表示されるまでにテキストで情報を与えておく必要があります。
alt=""属性)を与えておきましょう。デスクトップ端末では<img>要素へのwidth属性及びheight属性は必ずしも必要とは言えないとされております。
しかしながら、モバイル端末向けのコンテンツでは<img>要素にはwidth属性及びheight属性を是非与えておきたいものとされております。
理由は端末の通信速度の都合で画像を表示し切れない場合でも、表示領域を確保してそこから先のレンダリングを継続出来るようにしたいからです。
とは言うものの、日本では旧型の低解像端末や現行のQVGA端末など、端末に合わせて適切な解像度の画像を動的に配信すると言った事が行われており、そのような場合には静的なHTML文書ではwidth属性やheight属性が付けられないのは已むを得ないかも知れません。
は、サポートされない端末もあります。
また、これらの機能が利用出来る場合でも、端末の処理能力を奪ったり電池消耗を早めてしまうと言う問題もあります。
これらの事を考えると、埋め込みオブジェクトやクライアントサイドスクリプトは使うべきでないとさえ言えます。
どうしてもこれらの技術を使いたい場合でも、使えない環境で問題が起こらないコンテンツ作りを心掛ける必要があります。
具体的には、対応していない端末向けに代替コンテンツを記述するなどの方法があります。
XHTML モバイル・プロファイルには、<b>要素などの物理要素が導入されておりますが、これらを利用する事で確実にページの容量を増やしてしまいます。
ページを軽くするために、スタイルは全てスタイルシートファイルに纏めてしまいましょう。
スタイルシートを使うべき理由を考えれば、<style>要素やstyle属性も使わないようにすべきなのは言うまでも無い事でしょう。
また、スタイルシート自体にも容量があり、従って読込の際に通信時間及び通信料が掛かる事になりますので、スタイルシートはなるべく小さく纏めるようにしましょう。
CSSでのスタイル指定に於いて、フォントの大きさや余白幅などをcmなどの絶対単位やピクセル数で指定するpx単位は携帯端末に対しては非常に危険です。
日本国内でも旧型の低解像度端末や現行のQVGA端末などを較べるまでも無く、液晶の解像度やサイズは機種に依りさまざまです。
ある端末で最適に表示出来ても、別の端末では読む事すら適わないという事態になり兼ねません。
フォントの大きさや余白幅などは、px単位以外の相対単位で指定しましょう。
オープンウェーヴ社端末のCSSの実装では、displayプロパティとfloatプロパティが使えません。
現在、オープンウェーヴ社のモバイルブラウザは最もシェアが高い事を考えると、displayプロパティとfloatプロパティは使わない方が安全と言えます。
また、これも基本中の基本ですが、スタイルシートに対応していない環境でもリソースの閲覧には支障が出ないようにしなければなりません。
背景の色と文字の色を明確にして、閲覧の妨げにならないようにしましょう。
また、背景画像を使う場合でも、
特に、携帯端末の場合、表示出来る色が限られる場合があるので、不用意に背景画像を用いると全く読めないという事態になり兼ねません。
背景画像は絶対に使うなとは言いませんが、以上の点を考慮して使うようにしましょう。
携帯端末はさまざまな表示能力があります。
色, フォント, 文字の大きさ, 太さなど、CSSなどで指定しても、CSSをサポートしていないなどの理由に依り指定通りに表示されない場合もあります。
「赤い文字で書かれた箇所」とか「太字の箇所」等と言う表現では、内容を理解出来ない恐れが非常に高いと言えます。
画像の幅が大きくなり過ぎたり、テーブルを使用している場合に横スクロールが発生する事もありますが、ｉモードなど横スクロールが絶対に出来ない端末もあります。
スクロールは一方向(通常は上下方向)のみとしましょう。
W3Cが定めた推奨事項では、ページサイズは最大10キロバイト以内を想定しておりますが、日本国内の端末事情を考慮した場合にはそれでもまだ大き過ぎます。
旧型機でも閲覧出来るようにするには、5キロバイトに収める必要があります。
現在の日本はQVGA端末が主流のためこの条件は当て嵌まらない場合が多いのですが、逆に旧型の低解像度端末では150ピクセルズ×200ピクセルズでは大き過ぎるでしょう。
要は端末に合わせたサイズにしなければならないという事です。
また、画像形式としては、W3Cでは最低GIF画像とJPEG画像が使えるものと想定しておりますが、日本では逆にGIF画像が使えない端末もありますので、その点に関しても考慮する必要があるかも知れません。
表(テーブル)に関しては、以下の点に注意して下さい。
可能なら、テーブルで表現されているコンテンツも、リストなどで同等の内容になるようにすると良いでしょう。
デスクトップ端末では<a>要素などにaccesskey属性を附与しなくても余り困る事はありませんが、モバイル端末ではaccesskey属性はぜひ活用したいものです。
特に、ページの何処を見ていても利用され得る重要なナヴィゲーションリンクには、ダイヤルボタン一つでアクセス出来ると言うのは非常に便利です。
画像やスタイルシートなど、HTML文書以外に必要なリソースは余り多くならないようにすべきです。
これは、外部リソースの取得には通信時間や通信料などの"コスト"が掛かるからです。
具体的な値は指定されていませんが、十個未満に抑えると良いようです。
構造的なマークアップを行う事で、スタイルシートのサポートの無い端末でも、適切にレンダリングされるでしょう。
特に<h○>要素に依る構造化は欠かせないと言えます。
<title>要素の内容は、ブックマークでも利用されます。
ブックマークの一覧には登録したページのタイトルが並びますが、大抵一行以内に収められて一行を超える分は切られてしまうでしょう。
長過ぎず、かと言って分かり難くならないように適切な表題を与えるようにしましょう。
モバイル端末の場合、ページ内でも手早く移動する事は困難です。
このため、ナヴィゲーションは大き過ぎないようにする必要があります。
具体的には最低限の階層に沿った最低限のリンクのみを用意すると良いでしょう。
基本的なリンクを一行で表すと良いとの事です。リスト形式で表したくなる方もいるかも知れませんが(制作者もその一人です)、それだと複数行に及ぶためスキップするのが大変になると言う事でしょう。
また、これらのリンクにはaccesskey属性を与えておく事で、ページの何処を見ていてもボタン一つで移動出来るようになります。
特にアクセスキーでの移動を容易にするには、予めアクセスキーの機能を知らせる必要があります。
そのためにはナヴィゲーションバーはページの冒頭に置き、各リンクに与えたアクセスキーも明示する必要があります。
また、ページの先頭(すなわち、ナヴィゲーションバーの先頭)には、それをスキップ出来るようなアンカーを設けておくと良いでしょう。
ページ内の項目間の移動も、携帯電話ではかなり面倒です。
そこで、項目間の移動を容易にするために、ページ内ナヴィゲーションを用意します。
具体的には、ページ内の各項目を<h○>要素を用いて構造的にマークアップして、すなわち、各項目には必ず見出しを付けて、各<h○>要素の直後に前後の項目に移動出来るリンクを設けます。
このため、各<h○>要素には適切なid属性を与えておきます。
携帯端末の容量制限だけでなく、スクロールを伴う閲覧はかなり面倒である事からも、最低限の内容に絞るようにしましょう。
また、長い文章や分かり難い言葉はなるべく使わず、手短かつ明確に表現するようにしましょう。
