 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| リッチクライアント選択のキーワード | ||||||||||||
|
では、リッチクライアント製品を選択する際のポイントとはどこになるのでしょうか。リッチクライアントを語る場合、前項であげたようにまずは大きく「インターネット向け」と「イントラネット向け」に分けて考えることができます。インターネット向けのものはいわゆる「表現力」が求められ、イントラネット向け（業務向け）のものは操作性を中心とした「生産性」が求められます。 ユーザの視点ではなくSIer・開発者の視点から見ると、「開発生産性」というのも強く求められます。 そもそもコンピュータが各種業務そして生活に用いられるようになったのは、利用者の生産性を上げるためであり、リッチクライアントに限らずITの最も基礎的な共通基盤として位置づけられます。ところが本当に「生産性」が重視されてきたのかといわれれば、そうとは言い難い部分もあります。 そもそもリッチクライアントというアーキテクチャが生まれた背景として、「HTMLクライアント」があまりにも操作性が悪く（特にデータエントリ系の業務には馴染まず）、それでもシステム化したがゆえに生産性が低下したことがあげられます。 |
||||||||||||
| ユーザにとっての生産性 | ||||||||||||
|
業務システムにおけるユーザの生産性の評価例として、「ファンクションキーなどを使い、キーボードのみでスムーズに入力作業ができるかどうか」ということがよくあげられます。ブラウザではキーボードの自由度が低く、さらに一項目の内容をチェックするだけでも画面に表示されるすべてのデータをサーバと通信しなければならないなどと、エントリ系の業務で致命的な欠陥を持っています。 これに対して、ブラウザ型／スタンドアロン型のいずれのリッチクライアントもキーボードへの対応は当然サポートしています。またIdbAもJavaベースであるため、キーボード操作に対しても柔軟に対応することが可能です。 上記以外にもユーザの生産性を向上させる方法は多々ありますが、IdbAにおいて特徴的なのは接続先や機能をコンポーネント単位で配信／組み合わせができるという点です。アプリケーションの実行中においても、そのときの必要に応じて必要な機能が追加可能で、アプリケーションを再起動することなく使えるようになります。また接続先のサーバも、そのサーバへの接続コンポーネントを追加すれば画一的に接続・操作することができます。 では具体例を見てみましょう。図1はIdbAによるアカウントアグリゲーションのサンプル画面です。  図1：アカウントアグリゲーション （画像をクリックすると別ウィンドウに拡大図を表示します） アカウントアグリゲーションとは、インターネット上の銀行口座・証券口座などを一元的に管理するサービスです。IdbAではアクセス先の銀行などの口座情報の見方（個別表示・合算表示などの機能）をコンポーネントとして提供します。 ユーザは自分に必要なコンポーネントのみ（自分が契約している銀行や証券会社の接続コンポーネントや表示機能コンポーネント）をコンポーネント配信サーバなどからドラッグ&ドロップで追加して利用することができます。 そして、これらは接続先が異なっても同一の操作で利用できるため、操作方法を新たに覚える必要がありません。これにより、アカウントアグリゲーションのようにサービスが横に展開する場合でも、ユーザの生産性が落ちることはありません。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
