私は、ユーザーがビジネスのプロセスの大きなモデルを閲覧できるようにするシステムのインターフェースに取り組んでいます。このモデルの多くのアイテムは、「ネット」構造に配置されています。単一のアイテムを表示するとき(つまり、アイテムのすべての属性を一覧表示するページを表示するとき)、このアイテムが全体的な構造のどこにあるかをユーザーに明確にするにはどうすればよいですか?
クライアントは、アイテム間の関係を従来のツリー構造(アイテムのレイヤーが相互にネストされている)よりもネットとして説明する方が正確であると述べています。これは、モデル内のアイテムは、多くの異なるカテゴリのアイテムの「子」になる可能性があるためです-多数の親を持つことができます。
システムの最も重要な項目の多くは、従来のマルチレベルナビゲーションメニューからアクセスできますが、このメニューの項目(およびそれらの項目の構造)は管理者が手動で定義することで、最も重要な項目のみに簡単にアクセスできます。システム自体の構造を表すものではありません。 2つのモデルが競合し、ユーザーを混乱させる可能性があるため、これは別の潜在的な問題です。
ネットを介して各アイテムに到達するための可能なパスが複数あるため、従来のブレッドクラムは理想的ではありません。
システムを通るパスは1つしか表示されません。つまり、直接の親要素が1つだけ表示されます。アイテムに多くの親アイテムがある場合、1つだけを表示しても、ユーザーはすべての関連する「兄弟」アイテムを見つけることができません。
また、多くの可能なパスのうちどれを表示するかを決定するためのロジックも必要です。
これらのどれも理想的ではないようです。
これがすべて理にかなっているといいのですが。私が説明したUIの問題を解決するための提案や、あなたが認識しているより根本的な問題に対処するための提案をいただければ幸いです。
さまざまな階層がサイトで競合している状況はたくさんあります。サイトは、親子関係の有向グラフであり、循環型グラフではないことが望ましいと考えられます。
循環的でない場合は、部分的に順序付けられたセットです。しかし、まだ木とはほど遠い。
ブレッドクラムは、このグラフの有向パスです。そして、理想的な世界では、サイトのパンくずリストの組み合わせは、親/子リンクの一部を無視することで得られるツリーのようになるはずです。
つまり、優先順位を付けて、親子関係のどれがサイトにとってより重要かを知ることがすべてです。
しかし、これは、パンくずリストに入れることができる情報の量を増やすためのいくつかのトリックがあると言いました。
私は通常このようにそれについて行きます:
実際、エレガントな方法は後退することです。最初に直接の親(カテゴリまたは属性ページ)を特定し、次に親カテゴリ、またはすべてのカテゴリを一覧表示する概要ページを探し、そのページがどこかにあるかどうかを確認しますメニューをクリックし、ホームページに到達するまでメニューツリーをさらに上に移動します。
ここでは、競合する分類法が異なる可能性があるため、通常は困難になります。古典的な例は、製品カテゴリとメーカーと材料です。これを処理するにはさまざまな方法があります。
あなたは単に分類法の1つに焦点を合わせ、他のものを無視します。例えば。の一つ
ブレッドクラムは、蓄積されたフィルターを表します。
ラベルには "Bikes"Offroad"Acme"Aluminium"Model XYZ"と表示することもできますが、[Aluminium]をクリックすると、すべてのアルミニウムバイクが表示されるわけではなく、OffmeカテゴリーにあるAcmeの自転車のみが表示されます。
カテゴリリンクは「"」ではなくカンマで区切ります。例えば。
これは、それぞれのカテゴリが互いに親子関係にないことを示しています。
ここで「アルミニウム」をクリックすると、Acme製であるか、Acme製であるかに関係なく、アルミニウム製のすべての自転車が実際に得られます。オフロードのカテゴリにあります。
個人的には、パンくずリストはユーザーが以前どこにいたかに依存するべきではないと思います。これはブラウザの仕事です。
http://www.nngroup.com/articles/breadcrumb-navigation-useful/
「階層または歴史?」を参照してくださいこれが2007年のものであっても、私はNielsenに完全に同意します。
パンくずリストがそれほど意味をなさないサイトは確かにあります。 stackexchange、facebook、gmailについて考えてみてください。おそらく、パンくずリストはいくつかのサブセクション(ユーザー設定、ヘルプページなど)で理にかなっているかもしれませんが、構造化されていない情報の湖をナビゲートするためではありません。
この場合、あなたが望むのは
サイトがナビゲーションで親/トップが非常に重い理由はありますか?各コンテンツが多くの異なるカテゴリ(親)の一部になる場合、パンくずを完全に却下することはしません。
ユーザーがたどったルートを追跡する動的ブレッドクラムの作成を検討できます。ブレッドクラムの各ノードは、そのレベルの他の並列ページにリンクするドロップダウンにすることもできます。このように、それは適応的な歴史的見解です。
ブレッドクラムは、閲覧履歴だけでなく、サイト内のページレベルに基づいてスマートに表示できます。
ユーザーがアクセスした場合:別のページ>ホームページ>ページ2>ホームページ>ページ4>ページ5
それはページを別々の分岐したパンくずとしてセットアップします。
ページ2の場合、ブレッドクラムは次のようになります。ホームページ>ページ2
ページ5の場合、ブレッドクラムはHOMEPAGE> [PAGE4 v]> PAGE 5になります。
これにより、ページ4は並列ページのドロップダウンです。
ホームページのようなアンカーがあると、ユーザーの方向付けに役立ちます。
これは情報アーキテクチャの質問です。
まず、あなたの定義です。
あなたとあなたのクライアントが説明することは、私に接続されたコンポーネントを持つグラフのように聞こえます。そのため、垂直階層またはツリー関係のみを記述できるブレッドクラムによって効果的に定義されることはありません。
これは接線の問題です。私が思うに、サイトメニューはコンテンツ構造ではなく、サイト構造を示しています。連絡先情報、情報、FAQなどです。ここのサイトは、すべての関連情報を含むマーケティング資料であり、コンテンツは(並べ替えられた)情報の複合です。 、いずれかのメニュー項目の傘の下に保存できます。サイトメニューにコンテンツ構造を含める必要はありません。サイトメニューを主な構造である補助構造VSコンテンツ構造と考えてください。システムには両方が必要です。あなたは常にサイト上に存在する補助的なものを必要とし、主要なものは特定のポイントからアクセス可能であるか、普遍的でもあり、これはサイトの目的次第です。
先に述べたように、ブレッドクラムはツリーの垂直方向の階層を表し、操作するコンテンツには水平方向の接続があります。このため、ブレッドクラムでは構造全体を記述し、ユーザーを効果的にナビゲートできません。
ソリューション
最も効果的なナビゲーション方法を実現するには、以下の方法を組み合わせて使用する必要があります。それらの多くを使用することについて心配しないでください。複雑な構造は、ナビゲーションの1つの方法では説明できません。ユーザーを空港の人と考えてください。徒歩でのみゲートに行く必要はありますが、エレベーター、エスカレーター、高速トラック、徒歩の組み合わせの方がはるかに効果的です。
サイトメニューでカバーされているその他の付属品は既にあります。
垂直階層は、コンテンツアイテムの親子関係を表すブレッドクラムで覆われています。
カテゴリは、水平分割のためにアイテムをグループ化するのに役立ちます。事前定義していない場合は、コンテンツをいくつかの大きなグループ(3〜7)に分割するようクライアントに依頼してください。既存のカテゴリがコンテンツカバレッジに効果がないとわかった場合は、再編成することもできます。カテゴリは、垂直階層/パンくずリストに表示されます:ホーム>ビジネスプロセス>プラント/エンドユーザーイノベーション/データプラットフォーム>別の記事。
関連するものとしてグループ化された記事を検討してください。 3つすべての関連記事のリストは、表示された記事と同じページに、その下または横に表示できます。
キーワードはタグに似ていますが、同じものではありません。特定のキーワードをリンクに変換し、テキスト内で記事を相互接続できます。キーワードはSEOに最適です。 https://www.youtube.com/watch?v=XSqizj4MrUQ
検索は、ナビゲーションの基本的な方法の1つです。オートサジェストで最適に動作します。あなたが精通している場合は、自動提案にカテゴリを含めてください。 https://uxmag.com/articles/designing-search-as-you-type-suggestions
今後の参考資料として、O'Reillyによる「World Wide Webの情報アーキテクチャ」をお勧めします。
不明な点がある場合は、お気軽にお問い合わせください。
すべてのアイテムが事実上「レベル」の深さが1つしかない場合は、ユーザーがアイテムの詳細から「トップ」レベルに戻る方法を提供するだけで十分な場合があります。したがって、ユーザーは1つのレベルで「ズームイン」してアイテムの詳細を表示するか、またはすべてのアイテムを表示できる場所に「ズームアウト」します。
一部のアイテムが他のアイテムからのみアクセスでき(トップレベルからはアクセスできない)場合、明らかにこれは適切ではありません。この場合、おそらく、元の投稿のオプション3が最も役立ちます。
「ネット」を何らかの形でグラフィカルに(そしてインタラクティブに、ユーザーがアイテムを表示してクリックし、そのアイテムの詳細に移動できるように)表現することが可能であれば、それは適切なオプションとなるでしょう。ただし、これを実装するのは、現在のアイテムの直接の親を単に見つけて一覧表示することよりもはるかに困難であり、したがって、法外な費用がかかる可能性があると思います。
私があなたの質問を読んだとき:-あなたは全体的な構造を示したいです。・ネット構造になっています。
したがって、ミニマップナビゲーションを表示したい(ゲームのように)ようにします。
しかし、それはビジネスプロセスに関するものだとおっしゃっています。ここで、ビュー(およびナビゲーション)は、ユーザーの役割とプロセスの問題によって異なります。
プロセスマネージャー(および場合によってはディレクター)は、マップ全体を確認する必要があります。 (特定のプロセスの)プロセス所有者は、プロセスのサブセットまたは1つの特定のプロセスのみをフォローしたい場合があります。彼らは機能横断プロセスマップの最小化されたバージョンを必要とするかもしれません。
ワーカーユーザーは通常、プロセスを気にしません。プロセスステップの前後のプロセスステップの背後にいる人を気にします。
一部のアプリケーションを送信するユーザーは、いくつかのプロセスステップを実行します。 S /彼は彼らがどこにいるか、そして主に何をすべきかを知る必要があります。 (例:eショップのチェックアウトを考えてください。)
効果的なUXを提供するために、これらのプロセスとユーザーの役割についてもっと考えます。
私はそれが大きな問題だとは思いませんそれが誤解を招くような場合は特に)パンくずリストを持っていること==(ではない。
他の人が述べたように、ユーザーがどこから来て、次にどこに行きたいかという点で、基本的なユースケースを理解するために少し時間をかけてください。
「最近表示された」リスト(Amazonや他の製品ベースのサイトと同様)を提供して、ユーザーが簡単に後戻りできるようにすることができます。
さらに、関連トピックの「保護者のリスト」というアイデアで、おそらく正しい方向に進んでいることでしょう。