エンタープライズアプリケーションのサイトマップを作成しています。
アプリケーションの1つのセクションには、カレンダーの編集機能があります。クリックすると、3つのセクションまたは異なるタイプのカレンダーが設定されます。
現在、ステップウィザードを使用してカレンダーを編集しているため、ユーザーは日付をその順序で設定する必要があります。
サイトマップで、各ステップを個別のボックスとして描画しますか、それとも個別のユーザーフローダイアグラムに入りますか?
図は、概念やアイデアを伝えるためのグラフィカルな手段です。ダイアグラムが意図した意味を明確に伝えている限り、それは仕事です。
グラフィカルな語彙は豊富です。いくつかの例を挙げると、概念はさまざまな色、形、矢印、太さ、位置を使用して伝えることができます。
通常、投入する量と明確さの間には反比例します。含めるほど、全体がはっきりしなくなります。
モナリザが非常に単純である場合、図のビジュアルは、いくつかのセマンティクスの単なる代理です。たとえば、長方形はページを示し、方向線は依存関係を示します。
ダイアグラムは両方の方法でオーバーロードできます。
図の最も一般的な分類の1つは次のとおりです。
sitemapは原則として静的な図です。サイトの構造を、通常はツリーレイアウトで示します。この構造は時間の経過とともに変化することはなく、サイトの動的な(時間の経過に伴う)側面を伝えることも意図されていません。
フロー図は動的な図であり、ユーザーが時間の経過とともにプロセスの進行状況をナビゲートする方法を示します。
そこにがあるハイブリッドであることに注目する価値がありますが、ほとんどの場合、境界が親(2レベルの深層構造)を示す動的図の形式です。
サイトマップにEdit Calendar
というタイトルのボックスが表示されるのは、少し意外です。編集はインタラクティブであり、動的モデリングの一部である必要があります。 Calendar
ページは、サイトマップにより適しているようです。
オプション2には、方向矢印があります(ここでも、通常は動的な図に表示されます)。サイトマップ用であることを考えると、無指向性の接続もあると思いますか?その場合、読者はこれら2つのタイプの意味を推測する必要があることを考慮してください。これは潜在的な過負荷の例です。
正確に何を伝えようとしているのかを考えてください。従来の意味でのサイトマップの場合、Edit
やフローセマンティクスを含めないでください。
[〜#〜]編集[〜#〜]
これが開発者向けである場合、タブからモーダル、公開されたdiv、ホバーインタラクションへのリンクまで、すべてのインタラクションに注意する必要があります。また、デスクトップとモバイル間で異なる相互作用がある場合、またはブレークポイントが異なる場合は、これらの違いを文書化する必要があります。機能フローとユースケースドキュメント/ Jirasなどを参照する必要があります...
これは時間がかかるので、多くの場所でそれはおかしな仕事しかしません。
// EDIT
サイトマップは、ユーザーが情報を見つけやすいように整理する必要があります。サイトマップは、おそらくWeb開発ビジネスに携わっていないエンドユーザー向けの開発者向けのドキュメントではありません。
たとえば、サイトマップはカレンダー機能があることを示しています。このカレンダー機能の機能に関する詳細情報を表示するdivがあるかもしれませんが、その詳細レベルは、おそらく前面と中央ではないはずです。
サイトマップには、WebサイトまたはWebアプリのさまざまなページが表示されます。 SPAの場合、サイトマップにはさまざまなセクションが表示されます。あなたの場合、「カレンダーの編集」の下に、直線的な順序の3つのステップがあるウィザードがあります。ワークフローのステップは、サイトマップには表示されません。手順をワークフロー図に分割し、[カレンダーの編集]ボックスに注釈を付けることができます。サイトマップは、アプリとそのさまざまなセクションの全体的なスキームを示すインデックスとして機能します。