アプリケーションのプラットフォームとして、プラグインがユーザには良くない理由
初回投稿日時: 2010年08月21日17時26分14秒
最終更新日時: 2010年08月21日17時32分01秒
カテゴリ: Software 雑談
固定リンク: id=2010082103
SNS:
(list)
スラドのFlashが消え去らない 6つの理由を読んでていろいろと思うところがあり、まとめておこうかなと思いました。
以前Flashの完成度について批判的なことをこの日記で書いたときに、はてブかどこかで、前時代的で時代錯誤な意見であるというコメントがつけられていましたが、原理的にプラグイン上にプラットフォームをもう一つ作ってしまうというのは時代に関係無くユーザにとってはあまり好ましい話ではないと考えています。
通常、シンプルなアプリケーションというのは各プラットフォーム(OS、またはtoolkit)の提供するGUI部品と、そのAPIを利用して作成されます。これが、そのプラットフォーム全体での統一されたUI、使い勝手を手軽かつ、確実に実現してくれます。このため、そのプラットフォームを使い慣れたユーザからすればもっとも自然な使い勝手を体験することができます。
しかし、モダンブラウザはこのような設計はとれません。理由のひとつはクロスプラットフォームな設計が求められることです。これによりAPIを直接利用するということはできず、やや遠回りな実装を行う必要があります。また、各GUI部品は各プラットフォームごとに何らかの制限がありますが、これがHTMLやCSSの仕様要求を満たすことはできませんので部品自体を独自に実装する必要があります。Geckoのチームはとにかく各プラットフォームに馴染むように日々、見た目や挙動の修正を行い続けていますが、まだまだ道半ばといったところです。この微妙な差異はユーザに違和感であったり、使いにくさにつながったりします。つまり、この時点でひとつ、ネイティブな動作との乖離が発生してしまっています。
さらにこの上で動くWebアプリケーションがHTML/CSS/Javascriptで独自のUIを作ったとしましょう。この場合、オリジナリティ溢れるUIでさらにユーザに違和感を与え、それを不便と感じる人も少なからずいるでしょう。
さて、では本題、プラグインについて考えてみましょう。プラグインのUIには大きく分けて二つの形が考えられます。
ひとつはAdobe ReaderのようにWindowedモードのみに割切り、プラグインウインドウの上に、各プラットフォームネイティブのGUIパーツを配置してしまうプラグインです。ブラウザよりもよりプラットフォームネイティブな動作を実現できるのでブラウザの違和感すら消してくれる可能性があります。これは一部のユーザには好ましいかもしれません。しかし、ブラウザとプラットフォームの差異に慣れてしまったブラウザのユーザには、逆効果の可能性もあります。ブラウザのウインドウ内なので、ブラウザのGUI仕様で操作しようとしたのに、ブラウザとは違うプラットフォームネイティブの挙動を体験してしまうからです。考えていたことと違う結果になるのはストレス要因となるでしょう。
もう一つは、Flashに代表されるようにアプリケーションのプラットフォームとして、独自のGUIパーツをプラグインウインドウ上に描画し、動作するプラグインです。この方式であればWindowlessモードでも問題ありませんし、プラグインのクロスプラットフォーム化が容易になります。つまり、モダンWebブラウザと同じアプローチになります。ですが、ユーザからすると、プラットフォームとも、ブラウザとも挙動の違うGUIが提供されることになり、さらなる学習、不便を強いられることになります。
さらに、こういったプラグイン上でアプリケーションが独自にUIを提供してしまうと、さらに新しいGUI仕様ができあがり、ユーザにとってはさらなる負担になります。
表にすると以下のようになります。
| ユーザの体験するアプリケーション | そこまでのGUI仕様の移り変わり |
|---|
| - プラットフォームのみ
|
- 静的なWebページ
- 独自UIを提供しないWebアプリケーション
| - プラットフォーム
- Webブラウザ
|
| - プラットフォーム
- Webブラウザ
- Webアプリケーション
|
| - プラットフォーム
- Webブラウザ
- プラットフォーム
|
- 独自GUIのプラグイン
- アプリケーション独自のGUIを提供しないプラグインアプリケーション
| - プラットフォーム
- Webブラウザ
- プラグイン
|
- アプリケーション独自のGUIを提供するプラグインアプリケーション
| - プラットフォーム
- Webブラウザ
- プラグイン
- プラグインアプリケーション
|
基本的に、GUI仕様の移り変わりが多ければ多いほど、ユーザに違和感を与えることになると考えられます。
またGUIイベントを処理する各レイヤーごと(プラットフォーム、ブラウザ、プラグイン)にそれぞれバグを持っていると考えられます。つまり、よりユーザに近いレイヤーほど様々なバグを内包していることになり、問題が発生しやすくなります。これは食物連鎖の生物濃縮と似ています。
例えば、「ネイティブGUIを利用するプラグイン」を除き、GUIに発生したイベントはブラウザ経由で発生します(OOPじゃない場合はwindowlessモードではない限り、フォーカスを持っていれば直接発生します)。イベントが中継される場合、パフォーマンスの問題からブラウザ側でイベントの取捨選択が行われます。もし、ここに問題があると、IMEがwindowlessモードでは使えなかったりするような問題が発生します。つまり、プラグイン独自UIはブラウザのプラグインとの通信部分にバグがあると、それだけでうまく動かなくなります。なんらかの処理を行うレイヤーが増えれば増えるほど不利になるのは当たり前の話ですが、この話の場合、それが非常に顕著です。
アンフェアな話なので、プラグインを推したい人からすると不愉快な内容だと思いますが、プラグインがアプリケーションの実装の仕方として不利なのはその立場上、仕方のないことです。
プラグインがHTML/CSS/Javascriptでは実現できないことの解決手段であるというのは事実ですし、あるプラグインの普及率が高い限り、そのプラグインがこの目的で利用されることは十分考えられるので、プラグインが要らない世界、というのは永遠に来ないのではないかと思います。
ただ、上述のようにプラグインにはその立場上、技術的に不利な点が目立ちます。プラグインを利用せずとも実装できることはプラグインを利用しない、また、特に重要ではない何かをあきらめることで、プラグインを利用せずに済む場合もプラグインを利用しない、これがWebページの提供側にとって一番良い判断ポイントだと思います。
各所でのFlashに対する不満や支持に関するコメントを見ていると、ユーザはFlash(もしくはFlashとブラウザとの連携部分)に文句を書き、Webサイトの開発者は開発のしやすさから支持しているように見えます。もしこの印象が正しいのであれば、まるで「永田町の常識、世間の非常識」のように、ユーザの感覚がないWebコンテンツ開発業界という残念な状況あるのかもしれません。