 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IBM WebSphere開発者向け技術ジャーナル: WebSphere Portalによるコンテキスト・ポータルの実装動的ポータル機能を使用し、状況とコンテキストに応じてユーザー・インターフェースを適応させる |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Andreas Nauerz (andreas.nauerz@de.ibm.com), Software Engineer, IBM Boeblingen Lab レベル：中級 原文の掲載：2006年6月21日  原文はこちら (US)この記事では、IBM® WebSphere® Portalを使用してコンテキスト・ポータルを作成する方法について説明します。動的で機動性があり、インテリジェントなコンテキスト対応ユーザー・インターフェースは、ユーザーの状況やコンテキストに対応して、静的なWebサイトや静的なポータルが抱える制限および生産性の課題を克服します。WebSphere Portalの動的な機能を理解して活用することが、ユーザー・エクスペリエンスや生産性の向上につながり、結果的にポータル・サイトの価値を高めることになります。 この記事は IBM WebSphere開発者向け技術ジャーナル(US) からのものです。 はじめにコンテンツやアプリケーションを適切なコンシューマーを対象として作成することは、簡単な問題ではありません。ユーザーの業務遂行のため、十分な情報やアプリケーションを提供したい場合もあれば、それとは反対に、過度な情報を提供することにより従業員の注意を逸らせて生産性を低下させることのないよう、情報量を制限したい場合もあります。 この記事では、WebSphere Portalをどのように使用すれば、コンテキスト・ポータルという、より動的で機動性のあるインテリジェントなコンテキスト対応ユーザー・インターフェースを提供できるかについて説明します。いくつかのシナリオを例にとり、静的Webサイトと静的ポータルでは生産性がどのように制限され、前述のユーザー・エクスペリエンスおよび生産性の課題が、コンテキスト・ポータルの動的機能によってどのように克服されるかを説明します。コンテキスト・ポータルの概念を説明することにより、管理者、ポートレット開発者、ポータル開発者が、動的ポータル機能を使用してユーザー・インターフェースをユーザーの状況およびコンテキストに適応させる方法について説明します。WebSphere Portalの動的な機能を理解して活用することがユーザー・エクスペリエンスと生産性の向上につながり、結果的にポータル・サイトの価値を高めることになります。 この記事は、WebSphere Portalの基本的な技術を理解していることを前提としています。
コンテキスト・ポータルとはインターネット技術の価値を認識した企業はイントラネットを構築し、企業独自の情報に対する中心的なアクセス・ポイントを従業員に提供しました。当初のイントラネットは、従業員にとって最も価値が高く、広く使用される情報に対する迅速かつ効率的な情報へのアクセス方法を提供するものでした。しかし、アクセス可能な情報量が急速に増え、適切な情報を見つけることがますます複雑で時間のかかる作業になってきました。 多くの企業がポータルの導入に成功し、これにより新たな問題である過剰な情報の管理を行っています。ポータルにより、高度にパーソナライズされた方法でアクセスの中央ポイントが提供されます。ポータルを活用することにより、企業内でのユーザーのロールに基づいて情報やアプリケーションを提供できます。特定のユーザーのロールとその情報を理解することにより、そのユーザーを対象としたコンテンツを効果的に作成することができます。現在のポータルは膨大な量のコンテンツで構成されているため、特定の状況に対する適切な情報を検索してアクセスする場合に、非常に時間がかかることがあります。ここにきて再び、過剰な情報が生産性に対する脅威になりつつあります。今日のビジネス環境では、特定のロールのユーザーに関する情報のニーズは常に変化しています。ビジネスの変化を反映させ、高い生産性と効率性を保つために、最新のロールの定義を常にポータルに適用し続ける必要があります。 WebSphere Portalを使用してコンテキスト・ポータルを構築し、ロールの連続適用プロセスを改善することができます。コンテキスト・ポータルとは、動的ポータル機能を使用してユーザー・インターフェースをユーザーの状況およびコンテキストに適応させるという概念です。特定の状況で必要となるコンテンツへの容易なアクセスを実現する最初のステップは、フィルター機能を採用してパーソナライゼーションを実現することです(図1)。コンテンツは、アクセス制御ルールに従ってフィルタリングされます。このルールによってユーザーがアクセスするコンテンツの量が絞り込まれ、特定のユーザーが日常業務を行う際に必要なポータル・コンテンツ全体のサブセットにアクセスできるようになります。特定のユーザーがアクセスできるコンテンツの量が限定されると、無関係なコンテンツによってユーザーの注意が逸れることがなくなり、関連するコンテンツに素早くアクセスできるようになるため、より使いやすくなります。 通常フィルター機能は、ユーザーが操作しているコンテキストを認識しません。このような機能は、ユーザーのこれまでの動作から学習して、特定の状況において何を表示すべきかを判断することもありません。フィルタリング・ルール(アクセス制御ルールなど)については、多くの場合管理者が中央で管理します。こうしたルールの場合、ユーザーの動作を反映することもなく、ユーザーの動作が変化すると同時に自動的に適用されることもありません。 コンテキスト・ポータルの場合、フィルタリングされたポータル・コンテンツをさらに削減して、関連するポータル・コンテンツに絞り込むことができます。このコンテンツは、ユーザーが操作するコンテキストに基づいて選択され、特定のコンテキストに関連するコンテンツのサブセットのみがユーザーに提供されます。一般にフィルター操作に使用されるコンテキスト情報には、現在の日付、時間、最後に実行した操作、現在のナビゲーション位置、および他のユーザーのオンライン在席確認が含まれています。 図1. ユーザー向けコンテンツのフィルタリング操作の進化 コンテキスト・ポータルの場合、ユーザーとポータル間の対話からナレッジが収集され、収集されたナレッジがフィルタリングされ、フィルタリングされたナレッジが格納されます。こうして取得されたナレッジとコンテキスト情報は、今後のセッションで使用することができます(図2)。 図2. ナレッジの収集と適用についてのコンテキスト・ポータルのプロセス コンテキスト・ポータルの場合、コンテキスト情報を考慮してユーザーの動作から学習することにより、ユーザーの典型的な動作をサポートします。
現在のポータルとコンテキスト・ポータルとの違いここで、日常業務にポータルを使用する「ボブ」というユーザーを想定します。ボブは、世界各地に代理店を置く大手旅行代理店チェーンに勤務しています。ボブは、いくつかの代理店のWebコンテンツを管理し、顧客に対して飛行機、ホテル、レンタカーの予約を行っています。顧客は予約のリクエストを、メールや電話で、または代理店経由で直接行います。 次のセクションでは、4つのシナリオを例にとり、現行の静的ポータルの欠点を説明します。この記事の後半では、コンテキスト・ポータルを使用して同じ業務を行った場合にどのように違うのか、また静的ポータルの欠点を克服する方法について説明します。
静的ポータルでの作業
ボブの会社では、これまでに静的ポータルのデプロイを行い、ボブには業務上必要な情報やアプリケーションへの中央アクセス権が与えられています。ボブは、次のような業務をポータルで行います。
多くのポータルと同様、ボブが使用するポータルにも数百ページが格納されています。他の同僚の業務を手伝うことがあるため、ボブはほとんどのページに関するアクセス権を所有しています。ただし、定期的にアクセスが必要なページは、そのうちのごく一部だけです。この結果、何度も繰り返しクリックしなければならない複雑な階層のナビゲーションになっています。 一般に、このようなページにアクセスするナビゲーションを一度作成すると、その時点から静的なページになります。そのため、アクセスしにくい位置にあるコンテンツにアクセスする必要があるユーザーは長いパスをクリックしなければならず、何度も同じ操作を繰り返さなければならないという問題が発生します。 通常、ロールの少ないグループに属するユーザーの場合、静的ポータル内でアクセスしにくいコンテンツを完全になくすことは不可能です。これは、ポータルはロールの多いグループのユーザーを対象に最適化され、特定の個人に対しては最適化されていないためです。そのため、これはボブにとって業務のやりやすい状況ではありません。 静的ポータルの場合、各ユーザーの要件を完全に調整することはできません。すべてのユーザーの希望や動作(時間とともに変わることもある)を基にして最適化するには、ナレッジや時間が不足しているためです。 ボブの業務の1つとしていくつかの旅行代理店のWebコンテンツの管理があり、その中にドイツのシュトゥットガルトの代理店のWebコンテンツがあります。この特定の代理店のページにたどり着くためには、図3で示すような複雑な階層ナビゲーションを通してクリックする必要があります。 図3. シュトゥットガルトのサイトへのナビゲーション・パス もう1つのボブの仕事は、顧客に対して飛行機、ホテル、レンタカーの予約をとることです。顧客は、電話やメールでリクエストするか、代理店に足を運びます。 予約のプロセスの際に、ボブは基本フォームに関連情報を入力しなければなりません。例えば、飛行機の予約をする場合、次の項目を指定する必要があります。
操作サポート要素(基本フォーム・ポートレットに接続したポータルで、関連する入力データの収集をサポートする)が、基本フォームに入力する際に役立ちます。通常、これらの要素は同じページ(多くはメイン・フォームの横)に配置され、「Click-to-Action」機能が有効にされています(『リソース』セクションを参照)。 静的ポータルの場合、ページのレイアウトは一度定義されると、しばらくの間変わりません。このページを変更する場合、ユーザーは新しいポートレットを追加してこのページをより便利なものにしますが、通常ページが最適化されると、再度静的な状態になります。次に示すのは、ボブが飛行機の予約をするときに使用する追加のポートレットです。
上記の追加ポートレットをすべて同じページに配置すると画面がいっぱいになるため(図4を参照)、使いにくい画面なります。ボブの画面は、同時に表示されるサポート要素でいっぱいになっています。現在のフォーム入力には関係のないサポート要素などを含めてすべてのサポート要素が表示されている場合、現行コンテキスト内でどのサポート要素が重要なのかを認識することがより困難になります。 図4. サポート用ポートレットによって複雑になったボブのカスタマイズされたページ 例3. 静的ポータル: 情報収集 ボブは、操作サポート要素を使用せずに基本フォームを入力することがあります。サポート要素の使用は、飛行機を予約する場合には合理的ですが、顧客本人が直接代理店に来店し、飛行機、ホテル、レンタカーを一度に予約することがあります。このような場合、ボブはさらに大きなフォームを使用することになります。顧客の関心は常にホテル(正確な場所やその外観など)や車についての詳細な情報にあるため、ボブはポータル内の様々なアプリケーションにアクセスし、顧客にその詳細な情報を提供する必要があります。そのため、ホテルに関する情報を顧客に提供するための特別なページが用意されています。そのページには様々なポートレットが組み込まれ、場所に関する詳細な情報や具体的な写真などが掲載されています。 ボブはこの特別なページにアクセスし、飛行機、ホテル、レンタカーについての情報を入手します。こうした特別な目的のページにアクセスしている間、ボブは顧客の選んだ内容を記憶したりメモしておき、メインフォームに戻って予約を完了するときにこの内容を入力しなければなりません。ボブが感じているよりも、実際にこのシステムから得ているものは少ないのです。 例4. 静的ポータル: 通知場合により、例外的な業務を行う必要が出てくることがあります。例えば、不定期に開かれる会議に出席する場合などです。ボブはこれらの予定をカレンダーに入力しています。ボブがポータル・ページにアクセスするたびに、こうした例外的な業務を行う必要があるかどうかが、ポータルによって確認されます。会議がこれから30分以内に開始される場合、ボブが現在アクセスしているポータル・ページに小さいアラート・インジケーターが表示されます。これから開かれる会議の通知により、ボブの現行アクティビティーとは無関係にコンテキストが変更されます。ボブがこのアラートをクリックすると、該当するカレンダー・エントリーにリダイレクトされます。ここで、これからのイベントを確認します。 この方法を使用した場合、ボブは長期間ポータル・ページにアクセスすることなく、特定のページの情報だけを読み続けるということも起こり得ます。その結果、これからのイベントについて正確に通知されない可能性がでてきます。ページの更新につながる操作を実行した場合、システムによってアラートの表示のみが更新されます。
コンテキスト・ポータルでの作業ボブの会社は、ユーザー・エクスペリエンスと生産性の改善のため、コンテキスト・ポータル概念の採用を決定しました。新しいポータルでは、ボブの作業環境が変化しています。毎週月曜日の朝にポータルにログインすると、興味のない「ようこそ」ページではなく、カレンダー・ポートレットを含むページが自動的に表示されます。これにより、ボブはカレンダー・ポートレットに移動する必要はなくなりました。 コンテキスト・ポータルにより、頻繁に使用するポートレットが含まれているページへのリンクが、アクセスしやすい位置に自動的に配置されます。コンテキストに依存する方法で操作サポート要素が自動的に表示され、必要なときにオンデマンドでデータが提供されます。 ボブは、汎用的なコンテキスト交換メカニズムを使用し、いくつかのポートレットから取得した情報を格納してその情報を対象のポートレットに反映させることができます。つまり、何かをメモしたり暗記したりする必要が一切なくなるということです。 例1. 情報検索を繰り返すボブは、多数のページへのアクセス権を所有していますが、定期的に使用するのは一部だけです。現在はコンテキスト・ポータルの導入前であるため、複雑な階層ナビゲーションを毎日繰り返しクリックする必要があります。 コンテキスト・ポータルの設計者は、ボブのナビゲーションの動作を分析し、よく使用するナビゲーション要素(最も頻繁にアクセスする要素)やいつも使用しているルートについてのナレッジを取得することにより、ボブに固有のニーズに基づいて複雑な階層構造を最適化することができます。 ボブのユーザー・インターフェースを最適化するために、設計者は次のオプションを検討します。
ポータルのナビゲーションの「Quicklinks portlet(Quicklinksポートレット)」(図5)または「Quicklinks node(Quicklinksノード)」(図6)の部分から、お気に入りのページへ直接アクセスできます。表示内容は、ボブのナビゲーション動作の変更に伴って動的に変更されます。リンクを1回クリックすると、対応するページへ移動します。 図5. お気に入りのリンクへ簡単にアクセスできる「Quicklinks portlet(Quicklinksポートレット)」 図6. ポータルのナビゲーションに組み込まれた「Quicklinks node(Quicklinksノード)」 「Quicklinks portlet(Quicklinksポートレット)」の例では、WebSphere Portalサイト・アナライザーのログ・ファイルが提供するポータルの使用状況の統計を利用しています。これは、ポータルの使用状況の分析に使用可能なWebSphere Portalの統合サポートを提供するものです(『リソース』セクションから、WebSphere Portal Information Centerの『サイトの分析』セクションを参照してください)。 例2. コンテキスト・ポータル: 情報の入力ボブは、操作サポート要素(追加のポートレット)を使用してフォームを入力しています。ボブが顧客のバケーション・フォームに入力する際に使用するサポート要素の数は、単一ページに使用可能な方法で組み込むことができる数よりも大きくなります。コンテキスト・ポータルでは、操作サポート要素(ページやポートレットの可能性もある)は動的に表示され、ボブが操作しているコンテキストに基づいています。 コンテキストの変更は、基本フォーム内をボブが移動するときに暗黙的に指定できます。入力フィールドを選択すると同時に、コンテキストが変更されます。現在のコンテキストに便利な操作サポート要素が表示され、ボブはこのサポート要素を参照しながらフィールドの入力を行います。その際、その他のサポート要素は非表示になります。 実行時に、コンテキストに依存してオンデマンドで動的に操作サポート要素を表示する方法には、次に示すようないくつかの利点があります。
図8.サポート要素は、必要がある場合にのみ表示され、インターフェース上の不要なものは除去される 動的ユーザー・インターフェース(UI)は、コンポーネント化されたUIです。なんらかの動的な動作に基づき、このUI内でコンポーネントが表示されたり非表示になったりします。動的なUIアプリケーション・プログラミング・インターフェースを使用すると、一時ページや一時ポートレットをポータル・ユーザーのインターフェースに追加できるようになります。一時ページは既存のページの定義に基づいて作成され、コンテキスト情報とともにナビゲーションに追加されます。ポートレットの定義に基づいて一時ポートレットが作成され、作成された一時ポートレットは一時ページに追加できます。ポートレットは動的UIを起動するときにDynamic UI Manager APIを使用します。これは、WebSphere Portal V5.1.0.1で採用された動的UI 管理機能の一部です。その動的な性質のため、インターフェースはポータル・データベース内に留まることなく、ポータルでのユーザー・セッションのライフタイムが最大になります。セッションが終了する前に、インターフェースをプログラムまたはユーザーによって終了することができます。 前述のシナリオでは、動的ページのポートレットをオンデマンドで追加または削除するときに、動的UI管理機能を使用しています。 (『リソース』セクションから、WebSphere Portal Information Centerの『動的ユーザー・インターフェース』セクションを参照してください) ボブは、様々なアプリケーション(ページ)からデータを収集して、このデータを基本フォームに転送することがあります。 次に示すコンテキスト交換ソリューションの例(ポートレットとして実装可能)では、他のアプリケーションによってコンシュームされるコンテキスト関連情報(データ・エントリー・フォームなど)の格納および取得方法を説明します。 ボブは、必要な情報をすべて収集して格納し、コンテキスト交換ポートレット内で(対象ページの)メインフォームにフィードしました。必要な情報を提供する様々なポータル・ページにアクセスする際に、コンテキスト関連データ項目がコンテキスト交換ポートレット内に格納されます。累積されたデータは、基本フォームに自動的に反映されます。このプロセスを図9に示します。WebSphere Portalの連携ポートレット機能を使用すると、データをコンテキスト交換ポートレットに格納し、基本フォームにそのデータを反映することができます。 図9. コンテキスト交換ポートレットにより、収集したデータの自動転送が実行される コンテキスト交換ポートレットにより、複数の独立した累積データのセットをサポートすることも可能です。例えば、ファックスで予約をリクエストした顧客用にデータの累積を開始したとします。次に、ボブが勤務する代理店に顧客が来店し、別の予約をリクエストしたと仮定します。この場合、この顧客のリクエストの優先度が一時的に高くなります。目の前で予約をリクエストしている顧客に応対するため、最初の顧客(ファックスによるリクエストを行った顧客)のための作業をいったん中止します。代理店に来店した顧客の予約を完了したら、ファックスで予約した顧客の予約作業を続行します。このようにコンテキスト交換ポートレットは、通常業務を行っている際に何度も割り込み業務が発生するような環境で働く従業員にとって、便利な機能です。 コンテキスト交換ポートレットには、ボブが作業を開始したコンテキストに基づいてデフォルト情報をあらかじめ設定しておくことができます。例えば、名前、電子メール・アドレス、郵便番号などの情報を、ボブのユーザー・プロファイルから取得することができます。 追加の動的ポートレットとして、コンテキスト交換ポートレットをオンデマンドで表示できます。必要ない場合には、終了することができます。 異なるページから情報を収集して飛行機、ホテル、レンタカーを予約し、コンテキスト交換ポートレットのサイロにデータを格納してから、収集したデータを(対象となるページの)基本フォームに反映する場合のシナリオを、図10、11、12に示します。 図10.データを収集する際にポータル内の様々なアプリケーションを使用する 図11.収集した情報をコンテキスト交換ポートレットに対して使用する 図12.コンテキスト交換ポートレット内のデータを使用してフォームを完成する コンテキスト・ポータルは、現在操作しているコンテキスト内で本当に必要な情報をユーザーに提供します。不必要な情報でユーザーの注意を逸らすことはありません。 ユーザーに特別なタスクやイベントについて通知する場合は、標準のWebプログラミング技法を使用できます。例えば、Click-to-Action、連携ポートレット、その他のPropertyBroker技術を使用して、データ交換を行うポートレットを実装することができます。したがって、ボブが現在ポータルで作業していない場合でも、これから開かれる会議を通知することができます(例えば、ポータル・ページで新しいホテルの総合レビューを読んでいるときに通知することができます)。 図13は、特定のイベントが到着するとすぐに、アラートが画面のテーマ部分に表示されることを示しています。ユーザーがどこかをクリックしたり、何か操作を実行する必要は一切ありません。これらのアラートは、動的に到着(プッシュ・モデル)して表示されます。この例では、これからの予定がボブに通知されます。例えば、アラートがボブのカレンダー・エントリーに基づいていると仮定します。ボブがアラートをクリックすると、ポートレット内でカレンダーの対応するエントリーが表示され、詳細を確認できます。 図13.特別なイベントの通知 AJAX (Asynchronous JavaScript™ and XML)を使用して、こうしたアラートを(ユーザーに操作の実行を強制することなく)動的に表示することができます。現在表示されているブラウザー・ページのブロックやリロードを行うことなく、データはブラウザー・クライアントから非同期でプルされます(JavaScript呼び出しを使用)。現在表示されているHTMLマークアップに適用されたJavaScript DOM操作により、現在の表示ページにデータが挿入されます。
まとめポータル・コンポーネントやポートレット内で、WebSphere Portalの動的機能を使用して静的ポータルをコンテキスト・ポータルに変換すると、ユーザーの生産性およびユーザー・エクスペリエンスが向上します。コンテキスト・ポータルは、コンテキスト情報を考慮し、ユーザーやユーザー・グループのこれまでの動作から学習することにより、ユーザーの繰り返し動作をサポートします。 この記事で扱った4つのサンプル・シナリオは、静的ポータルに対して潜在的な拡張性を示し、コンテキスト・ポータルによってユーザーの生産性をどのように向上できるのかを説明しました。コンテキスト・ポータルにより、大規模で複雑なナビゲーション階層を通るナビゲートが軽減され、操作サポート要素の使用の最適化、より使いやすい簡潔なレイアウトの提供、アプリケーション間のコンテキスト(データ)交換が実行され、コンテキストの変更についてほぼ常時ユーザーへ通知することが可能になります。コンテキスト・ポータルを使用することで、情報やアプリケーションへの集中アクセスにより実現されるさらなる利点を、企業は十分に活用することができます。この利点は、静的なロールをベースとしたユーザー・エクスペリエンスを超えるものです。
ダウンロード
参考資料
筆者について（原文のまま）
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
