組織階層とラベル
企業向けの位置追跡アプリを構築しています。組織には、CEO→部門長→地域→州→市のような階層があります。親グループの誰もが、そのすべての子に対して可視性を持っている必要があります。 CEOは組織を完全に可視化する必要があります。
チームを編成する方法は2つあります。
1つは、組織ツリーのようなツリー構造を構築することです。
チームを編成するもう1つの方法は、CXO、Department、Region、State、Cityなどのタグを使用することです。これはStackExchangeラベルに似ています。情報を検索するために、ユーザーはタグを選択できます。
チームを編成するためのより良い方法はどれですか？
何らかの方法で可能な場合は、ラベルをお勧めします。私の意見では、階層ツリーにはいくつかの厄介な問題があります：
- ツリー内のアイテムの検索には問題があります。ユーザーは、関連する結果のみを表示することを期待します。しかし、これは、アイテムが階層のどこに属しているかに関する重要な情報を除外します。
- これに対処するには、強調表示されたアイテムの直接の祖先を含むツリーのサブセットを表示することができます。これは混乱する検索結果につながり、ユーザーが自分で無関係な情報を除外するように求めます。
- ツリーが大きくなった場合、すべてのアイテムを一度にユーザーインターフェイスにロードしたくない場合があります。これは通常、ページネーションを使用して対処されます。しかし木の場合、ページネーションはひどいです。どこでページを分割し、次のページが階層に関連してどこから始まるかをどのように示しますか？
- ロード時間を短縮するために、最初にツリーの一部を折りたたむこともできますが、ツリーの折りたたまれた部分にある可能性のあるアイテムを検索すると、混乱を招く動作につながります。さらに、アイテムの閲覧は面倒になり、ユーザーは何度もクリックする必要があります。
私が参加した最近のプロジェクトでは、最初は組織階層を表示するときにツリーがありましたが、結局それは悪い結果になりました。レイヤーとユーザーはそれほど多くありませんでした（約100ユーザー）。何かしなければならないことに気づいたので、（パンくずリストのような）ラベル付きのフラットリストを選びました。新しいリストを見たときに、ユーザーが古いツリーを元に戻すことを望んでいませんでした。
アイテムをフラットリストにしておくと、より明確で柔軟性が高くなり、多数のアイテムに適切にスケーリングされます。
編集：
プロトタイプの例を含めました： 
シカゴの営業所では、次のページで簡単にサブ組織を増やすことができます。親組織との関係はまだ明確です。
検索する場合、関連する組織のみを表示する必要があります： 
検索結果が階層のどこに属しているかはまだ明らかです。
同じツリー内で場所とタイトルを混在させないことをお勧めします。例として、部門の頭が地域に直接関連付けられている場合でも同様です。データ型が類似したセットである場合、大規模なデータセットでは親子関係は困難です。同じツリー内でタイトルと場所を混在させて可視化すると、不必要に複雑になる可能性があります。
役割ベースの権限付与では、特定のデータセットの制御を制御するための頭痛の種をすでに作成しています。問題を再考するのに役立つ2つの代替方法を提案します。
- 自己組織化チーム。これは業界によっては厄介なことかもしれませんが、チームに「芝生」が何であるかを判断させ、特定のユーザーを管理ステータスで設定して、自分にとって重要なチームを自動的に選択できるようにする柔軟性がある場合は、アプリですべてを制御できます。
- 真理値表を作成します。 2つ以上のブール値が制御を争っている状況になったら、どの相互作用が真または偽を証明するかを示す値の長い形式 真理値表 を構築する必要があります。