私の例はWebベースのアプリケーションですが、これは何にでも当てはまると思います。同じアクションの複数のエントリポイント、良いか悪いか?
私の例:
サプライヤー(ベンダー)に対して製品を追加する。
これは潜在的に以下を介して行うことができます:
すべての有効なエントリポイント(1つだけを使用する場合)には、エクスペリエンスを向上させるかユーザーを混乱させる長所と短所があります。同じアクションへの複数のエントリポイントがあることで、何か間違い/混乱はありますか?
一般的なユーザビリティの原則として、開放性と柔軟性を提供し、ユーザーがいつでも好きなときに好きなことを行えるようにする必要があります。これは、ユーザーに知らないか、忘れた、または考え方と一致しない可能性のある単一のパスのみをたどるのではなく、複数のエントリポイントを提供することを主張しています。
懸念事項は、複数のパスがより複雑なメニューと情報アーキテクチャを意味し、混乱を追加し、ユーザーを迷わせ、混乱を引き起こす可能性があることです。これを緩和できる変数がいくつかあります。
オブジェクト中心の構造
まず、アプリがより複雑になり、可能なタスクとパスが増えるため、一般的なウィザードのようなタスク中心の構造ではなく、 object-centered structure を採用することで、メニューとアーキテクチャの両方の複雑さを制御できます。ウェブアプリ。オブジェクト中心の構造では、各ページは1つ以上のオブジェクトクラスを表し、それらのクラスに関連するすべてのタスクを実行できます。タスク中心の構造では、各ページは単一のタスクまたはタスクの単一のステップを表します。
オブジェクト中心の構造では、すべての製品を一覧表示した製品ページがあり、各フィールドのサプライヤが(ユーザーがソートできる)フィールドに示されています。または、すべてのサプライヤーをリストするサプライヤーページがあり、ツリーまたはマスター/詳細レイアウトで特定のサプライヤーの製品が含まれています。どちらの方法でも、すべての情報が1つのページにあるため、メニューとアーキテクチャが最もシンプルになり、複数のエントリポイントの必要性がなくなります。
ページ間での複製(ページではなく)
第2に、2つの異なるページにコマンドを複製することは、同じページの2つの異なる場所にコマンドを複製することほど問題ではありません。後者の場合、ユーザーは2つのコマンドが本当に同じかどうか疑問に思うでしょう。対照的に、ユーザーは、同じコマンドが異なるページ(サイドバーメニューなど)に表示されることを期待することがよくあります。
サポートする必要のあるタスクによっては、オブジェクト中心の構造であっても、製品ページとサプライヤーページの両方が必要になる場合があります。ただし、製品とサプライヤページの両方に[製品の追加]メニュー項目があることはおそらく問題ありません。 Product and Suppliermenusの下にAdd Productメニュー項目があることはおそらくありません。
一貫したラベルとルール
第3に、同じラベルを使用し、同じ基本的な相互作用の規則に従う場合、複数のエントリポイントの複雑さが最小になります。オブジェクト中心の構造とほとんどのデスクトップGUIの場合、基本的なルールは、ユーザーがそれを見ることができる場合、ユーザーはそれを操作できるということです。ユーザーが[製品]ページと[サプライヤー]ページの両方に製品を表示する場合、ユーザーは、製品への追加を含め、それらと対話できることが期待されます。これは、Webサイトで引用されているコンテンツへのリンクを提供することに似ています。
一貫したラベルは、別の場所にある同じコマンドであることをユーザーに知らせるのに役立ちます。そのため、ある場所では「製品を追加」ではなく、別の場所では「製品を挿入」ではなく、常に「製品を追加」と呼んでください。
シンプルで一貫性のあるルールは、メニューを簡素化することもできます。アプリがオブジェクトフォーカスをサポートしている場合(主従関係に必要)、追加する必要があるのは[追加]メニュー項目のみです。 (どちらかのページの)製品に焦点を当てている場合は、製品を追加します。サプライヤーに焦点を当てている場合は、サプライヤーを追加します。
情報アーキテクチャの面では、ファセットナビゲーションは、ユーザーが希望するタスクまたはページにユーザーを導くための正当なアプローチです。
ユーザーのメンタルモデルに合わせてサイト構造を最適化しています。
別の簡単なメモとして、別のエントリポイントから環境(サプライヤー名など)から情報を収集する場合は、その情報を使用してフォームに事前入力します。
HTH
マット
通常、複数のエントリポイントは、ユーザー間の混乱を招く可能性があります。同じアクションに進む可能性のある複数の方法が見られる場合、2つのアクションの間にどのような違いがあるかについては不明である可能性があります。
とはいえ、答えは実際には状況によって異なります。すべての状況には、対処する必要がある独自の小さな癖があります。 2つの異なるユーザーベースがあり、2つの異なるビジネスフローがある場合、同じ場所に到達するために2つの異なる方法を使用することは完全に理にかなっています。
私は最初の2つだけを許可します。それらは製品<->サプライヤーの関係では論理的に見えます。
私は常に目標を達成するための複数の方法を提供しています。しかし、私にはそれに対する構造があります。物事についてユーザーを混乱させたり、別の用語を使用したりしないでください。
ここに何が起こるかです。
私の経験では、これは明確であり、100%はい。言語の一貫性を維持しても、ユーザーを混乱させることはありません。
興味深いトピック
1つ以上のパスを介して特定の宛先に到達できることは一般的です。例:ユーザーは、場所(パースなど)でのアクティビティ(ゴルフなど)に関する情報を見つける必要があります。
この例では、ユーザーは次のいずれかの方法でここに到着できます。
1)場所に移動してからアクティビティを選択する2)アクティビティに移動してから場所を選択する
どちらのシナリオも同様に可能性が高いので、その周りに情報アーキテクチャを設計することはできませんnot。このタイプのユーザー動作の問題は、ブレッドクラムトレイルがバラバラになり、別のディメンションを追加しないと機能しないことですが、それは別の話です...