![]() |
ASP.NET Webアプリ開発の裏事情エピソード9:「モバイル対応」と闘う!―― すべてが確立されていない環境との闘い ―― 小田原 貴樹(ハンドル・ネーム:うりゅう)2005/11/16 |
Page1
Page2
|
|
ASP.NETならモバイル対応も完ぺき……?
ASP.NETで作成したショッピング・サイトを納品した、クライアントの経営者との打ち合わせで。
経営者:
|
「最近あれだねぇ、電車の中とかで携帯電話触っている女性が増えたよねぇ」 |
筆者:
|
「そうですね。もう当たり前のように携帯を使って、情報を見たりしていますね」 |
経営者:
|
「あれで、買い物とかもできるんだろう?」 |
筆者:
|
「ええ、このところ携帯対応のショッピング・サイトも盛んになってきました」 |
経営者:
|
「うちも作ろうよ!」 |
筆者:
|
「うっ、モバイル・サイトの作成ですか……。キャリアとか機種とかいろいろあるんですが……」 |
経営者:
|
「え? だってASP.NETならモバイル対応も自動で完ぺきなんだよね?」 |
筆者:
|
「ど、どこでそんなうわさを……」 |
モバイル・サイトの有効性については、それこそ6年前にi-mode対応の携帯電話が発表された時期から騒がれ続けてきた。ただ、筆者が現場で感じる感覚として、本格利用のにおいがしてきたのは昨年(2004年)であり、実際の結果がハッキリと見え始めてきたのは今年(2005年)からではないかと考えている。
今年に入ってからは、これまであった「もの珍しさ」を前提にした利用や、出会い系に利用されるような情報系コンテンツの利用を超えて、抵抗なく当たり前に一般利用者がモバイル・サイトを利用するベースが出来上がってきたように思われる。
こうした急速な普及の理由として、インフラの整備が急速に進んだということが挙げられる。各キャリアの第3世代携帯電話の普及が進み、携帯電話の性能や通信速度が大幅に向上した。また、「パケット定額制」などの本格利用には欠かすことができないコスト低下も同時に進行してきた。
モバイル・サイトはこのように、一般利用者にとっていろいろな意味で「使うだけの価値がある媒体」に成長してきているのだ。この傾向は今後の技術革新によってさらに高まっていくことは間違いない。PCをベースにした世界的なWebサイトの成長とはまったく別に、モバイルをベースにした日本独特のサイト文化が発展していくものと予測できるのである。
こうした現状に対して、実際のWebサイト運用元である各企業がついてこられているかというと、意外とそうでもない。
財団法人インターネット協会が監修している『インターネット白書2005』内の資料を見てみると、モバイル・サイトの開設状況のアンケートの結果として、「すでに開設している」と回答している企業は、全体のわずか5.5%にとどまっている。逆に「開設していないし、開設する予定もない」と回答した企業は77.2%に及んでおり、静かに火が付き始めている現状になかなか気が付けていないという実態が見えてくる。
また、同じインターネット白書2005内の別の資料では、「PCを持っておらず、携帯電話のみでWebサイトを閲覧している」というユーザーが、1千万に近い人口であると分析しており、そうしたことを考えれば、モバイル・サイトを開設することにはビジネス的に大きな意味があるといえるだろう。
さて、以上のように効果の程がハッキリと見えてきたモバイル対応サイトであるが、そのサイト制作工程が煩雑かつ難解であることは昔から変わっていない。
まず第一に、PCと比較して圧倒的に表示領域の小さな携帯電話では、モバイル専用の画面デザインを改めて制作する必要がある。それに付随して、現在のPCに搭載されているブラウザと比較すると、携帯電話に搭載されているブラウザは表現能力の面で大きく劣るという問題もある。
そして最大の問題として、ある程度の標準化が達成されているPCのブラウザに比較して、携帯電話の種類には「複数のキャリア、その下に複数の機種」が存在し、低レベルの標準化しか達成されていないということがある。この多キャリア・多機種の問題は後ほど詳しく解説するが、はっきりいってかなりの労力と精神力を必要とするのである。
そのうえで、われらがASP.NETのモバイル対応というのはいかがなものだろうか? まず、大前提として以下のことはハッキリしている。
「ASP.NETで制作された通常のWebサイトは、携帯電話では閲覧できない」 |
仮に、画面のデザインを携帯電話などのモバイル端末用に作成し、プログラムをVisual Studio .NET 2003(以下、VS.NET 2003)で「ASP.NET Webアプリケーション」として開発したとする。
このWebサイトは、PCのブラウザであれば何の問題もなく参照できるが、実際に携帯電話で表示しようとすると、かなりの確率でエラーが発生し、ページの表示は行われないはずだ。まれに「ページの内容」と「携帯電話の機種」の絶妙な組み合わせでうまく表示できることがあるかもしれないが、まず駄目だと考えて間違いない。これは筆者が実際にやってしまったミスなので経験則なのだが、どうもViewState(=一時的なデータをHTML内に保持する仕組み)として自動的に書き込まれる大量のコードが問題のようである。
こうした問題に対して、マイクロソフト側ではかなり以前からモバイルに対応するための特別な手段・方法を提供している。
昔はMMIT(Microsoft Mobile Internet Toolkit)として提供され、現在の.NET Framework 1.1/VS.NET 2003ではデフォルトでASP.NETモバイル・コントロールに統合されて提供されているのがそれである。これによりVS.NET 2003であればASP.NETモバイルWebアプリケーションというプロジェクト・テンプレートを使ってWebサイトを開発すれば、明示的に携帯電話対応のサイトを開発できるようになっている。
ASP.NETモバイルWebアプリケーションは先進的なコンセプトで展開されてきており、メーカーや機種による違いが大きいPDAや携帯電話などのモバイル端末に対し、特定の機種に依存しないWebアプリケーション開発を支援できる仕組みを持っている。
確かに、「ASP.NETモバイルWebアプリケーション」でWebサイトを開発すれば、ほぼすべての携帯電話端末で動作するものが開発できる。端末ごとの能力差も自動的に吸収する仕組みになっているし、キャリアごとに発生するタグの差異もかなり自動的に調整してくれているようである。
では、ASP.NETであればモバイル対応も完ぺきなのかというと、筆者のこれまでの経験では、残念ながらその答えは「否」なのである。
ユーザビリティが追求できない?
ASP.NETによって構築したモバイル対応サイトを公開した後の、クライアントの担当者との打ち合わせで。
担当者:
|
「小田原さん、モバイル・サイトの公開ありがとうございました」 |
筆者:
|
「いえいえ、いかがでしょうか?」 |
担当者:
|
「動作は確認しました、ちゃんと動いていますね。ただ、何点か気になるところがあるんですが」 |
筆者:
|
「はい、どういった点でしょうか?」 |
担当者:
|
「まず、漢字とかカナとか入力モードが自動的に切り替わりませんよね?」 |
筆者:
|
「そ、そうなんです。それをしようと思うと、かなり大変で……」 |
担当者:
|
「むちゃくちゃ、不便です。お客さんからもクレームありました」 |
筆者:
|
「そ、そりゃそうですね……検討します」 |
担当者:
|
「あと、画面のデザインが壊れてませんか? 背景が白くなってたりするんですが。入力フォームもおかしいし」 |
筆者:
|
「え、えーと、携帯電話の機能に合わせて自動的に変化する仕組みでして……」 |
担当者:
|
「いや、サイトとしておかしいでしょう。直してください」 |
筆者:
|
「そ、そりゃそうですね……努力します」 |
ASP.NETのWeb対応が完ぺきでない理由が、この会話に集約されている。
ASP.NETモバイルWebアプリケーションでは、モバイルWebフォーム上にASP.NETモバイル・コントロールを配置する形で開発していく。日本でモバイル・サイトといえば、携帯電話を用いることを前提にしがちであるが、実際には各種PDAなどさまざまなモバイル端末が存在する。これらすべての端末に対応しなければならないという観点のためか、ASP.NETモバイルWebフォームやASP.NETモバイル・コントロールには制約が大きい。
例えば、上記の会話内に出てきているように、携帯電話向けのサイトでは入力作業が非常に煩雑になることが想定される。少しでも入力の手間を軽減させるために、入力フォームの各テキストボックスでは入力モードの自動切り替えが実装されていることが望ましい。
実際、ドコモのi-mode端末用のタグでは「iStyle」という属性が用意されており、簡単に入力モードを指定できるようになっている。ところが、ASP.NETモバイル・コントロールのテキストボックスはこれに対応していない。プロパティに設定できないだけでなく、HTMLコード内に直接埋め込むこともできないし、通常のWebフォームではよく用いられる「attribute」による属性の追加も行えない。
基本的にASP.NETモバイル・コントロールでは、コントロールに搭載されているプロパティ・メソッド以外はまったく利用できないのである。コントロールの継承を用いて独自のテキストボックスを作成することで可能になるらしいのだが、そんなに気軽にできるような作業ではなくなってくるのである。
また、繰り返しになるが、どんな端末でも表示できることを目指しているため、サイトのデザインは自動的に調整されて表示されることになる。そのため、明示的にHTMLなどでデザインを指定したとしても、その指定どおりに表示されるかどうかは分からない。むしろ、たいていの場合は指定どおりにはならず、自動的に背景色が白色に変換されたり、文字色は黒色に変換されたりする。
さらには、ASP.NETモバイル・コントロールの配置のためにASP.NETモバイル・デザイナを利用することになるが、仕様上「1行には1コントロールしか配置できない」ようになっている。加えて、ASP.NETのポストバックなどの機能をモバイル上でも実装するためなのか、入力系のフォーム画面を制作する場合、デザイナ上では1ページに収まっていても、実際の表示ではリンクごと、ボタンごとに自動的に画面が分割されてしまったりして、デザインの結果はかなり予測しにくいのである。
社内ユーザー・部内ユーザーだけが利用するイントラネットなどの非公開系の業務用Webアプリケーションをモバイル対応として動かしたい場合には、それでも許されるところもあるだろう。だが、不特定多数が利用するインターネットなどの公開系Webアプリケーションのモバイル対応版としては、これでは非常に困ることになる。
公開系Webサイトでは何よりもデザインが重視されるのは、モバイルであっても変わりない。ましてや入力作業などの使い勝手も悪いということになれば、発注者(顧客)が納得しなくても仕方がないだろう。こうしたことから、ASP.NETモバイルWebアプリケーションは、ユーザビリティの面で相当に問題があるといえるのである。
![]() |
![]() |
INDEX | ||
ASP.NET Webアプリ開発の裏事情 | ||
エピソード9:「モバイル対応」と闘う! | ||
![]() |
1.ASP.NETならモバイル対応も完ぺき……? | |
2.まだまだ、未知の領域。あえて、ASPの利用も。 | ||
![]() |
![]() |
「ASP.NET Webアプリ開発の裏事情」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
![]() |
|
|
|
![]() |