パンくずリストを実装するための推奨アプローチ

13

ウェブサイトにブレッドクラムを実装したいのですが、今ではそれらを最適に実装する方法に苦労しています。

ユーザーは製品を検索できますが、製品カテゴリに移動して製品を見つけることもできます。製品ページで、ユーザーは製品カテゴリをクリックして類似の製品を見つけることができます。そのため、ユーザーには特定の製品/ページに到達するためのさまざまなパスがあります。

パンくずリストを実装するには2つのオプションがあると思います

オプション1： 訪問したすべてのページをパンくずリストに追加します。例：ホーム>検索結果>製品1>カテゴリー2>製品2短所：パンクラムは非常に長くなる可能性があります

オプション2： 特定の固定ブレッドクラムをすべてのページに指定します。例：ホーム>カテゴリ1>製品1問題：複数のカテゴリに属する製品をどうするか？

あなたはどう思いますか？見落としているオプション3はありますか？

web-development breadcrumbs

— vdrmrt
ソース

9

おとぎ話のように「パンくずリスト」と呼ばれていますが、パンくずリストの目的はブラウザの歴史を置き換えることではありません。そのため、オプション1はオプションではありません。

これらはむしろ、ユーザーが製品をどのように見つけたか、とりわけ、見つかった製品の「横」に論理的に配置されている他の製品をどのように見つけることができるかを示す道具です。

基本的にはオプション2です。

複数のカテゴリに属する製品がある場合、次の3つのオプションがあります。

製品へのすべての可能なパスを表示します。
ユーザーが製品にアクセスしたパスを表示します。（これには、製品IDの代わりに製品からカテゴリへのテーブルの主キーを使用する必要があります。）これは、ユーザーが検索時に「検索>製品」ブレッドクラムをほとんど役に立たないことを意味します。
表示されるブレッドクラムを決定する各製品の「メインカテゴリ」を指定します（ショッピングカートがあり、ユーザーがカートビューで製品をクリックした場合など、他の場所で使用されます）。

では、オプション1をダンプしましょう。ただし、検索ではなくても、ユーザーがどのように製品にアクセスしたかをパンくずリストで示すのは良い考えだと思いますか。例：ホーム>検索結果> product_1、ホーム> category_1> product_1またはHome> category_2> product_1

私が与えた3つの可能性から、私は好きではありません。アプリケーションによって異なります。「メインカテゴリ」がなく、パンくずリストに1つのパスだけが必要な場合は、ユーザーがどのように製品にアクセスしたかを示すことがおそらく唯一のオプションです。

1

パンくずリストは、ユーザーがどのようにサイトにアクセスしているかではなく、サイトのレイアウトを代表するものと想定されています。Amazonでこれを見たくない：

Home>Products>Home>PS3 Games>Call of Duty>PS3 Games>Funky Boxer Shorts->Add To Cart

私の閲覧履歴とOCDクリックを示すものの、サイトを代表するものではありません:)

製品カテゴリについて言及しているように、データベースバックエンドがあると思います。親カテゴリがある場合は、すぐに使用できる構造があります。フロントページがあると仮定すると、パンくずリストで「ホーム」と呼ぶことができます。次に、データベース内に次のようなものがあると仮定します。

table_productCategories
    _pkCategoryID
    _categoryName
    _fkParentCategoryID

製品カテゴリのツリーを作成できます：

Software
    Windows
        Apps
        Games
        Crash-To-Desktop
    Linux
        Servers
        3-Games
Hardware
    Laptops
    PCs
    Missile-Launchers

...製品ページにアクセスするたびに、製品が複数のカテゴリに属しているかどうかを心配する必要はありません。ユーザーがそこに移動し、dbクエリを使用してパンくずリストを作成できます。

Home > Software > Windows > Games > Aunt Dolly and the Scared Sheep

さらに、製品ではないページを作成します。「私たちについて」「お問い合わせ」など。CMSでは、これらのページのコンテンツはデータベース内にあり、分類されます。

table_contentCategories
    _pkCategoryID
    _categoryName
    _fkParentCategoryID

...あなたはアイデアを得る。これは、製品ではなくコンテンツを含むすべてのページもブレッドクラムできることを意味します。

Home > About > Finding Us in a web of backstreets

あなたの最初の声明は本当に狭いです。場所ベースのブレッドクラムを使用してサイト内の位置を示す人もいれば、パスベースのブレッドクラムを使用してユーザーがサイト内のどこに到達したかを示す人もいます。後者は「パンくずリスト」の概念により忠実であると思います。サイトのコンテンツは、どちらが優れているかを決定する大きな要因です。

同意した、おそらくそれはそのように出くわすでしょう。私は主に、「現在のページをパンくずリストに追加する」という提案に言及していました。

0

カテゴリまたは分類法（最も一般的なものから最も具体的なものにつながるカテゴリのネストされた階層など）には違いがあるため（私の理解では）、製品カテゴリ>製品サブカテゴリ>製品>モデルまたは車>セダン>シボレー>インパラ> x5000

4ドアセダンを検索して候補者のリストを見つけ、それらの1つ以上にドリルダウンする場合、カテゴリを昇順にするよりも、検索結果によって返されるリストに昇順することがより重要ですあなたが選んだ製品は何でも。（つまり、上記の例は、「車>セダン>シボレー>インパラ> x5000」ではなく、「ホーム>検索>シボレーインパラx5000」になります。

パンくずリストを使用して、あなたが行った場所のマーカーにすることは選択肢1と似ていますが、パンくずリストはパスを後方にたどるためにピックアップされることを意図しているため（そしてパンくずリストを拾うと、パス内の特定のポイントを選択し、そこからナビゲートするため、その後のカムブは削除されます。

「パンくずリスト」がここでいくつか提案されているようにカテゴリツリーである場合、なぜそれらを「パンくずリスト」と呼ぶのですか？パンくずリストの私の理解は、それらがモデル固有ではなくパス固有であるということです。

— ラリーミルズガル
ソース

あなたが尋ねる人に依存します。（彼らは実際には、リスト1つの以上のモデルがある。）この時点では、この用語は、基本的には第2の決定は、それらが使用しているどの実際の方法論として実装者によって作られていると、一般的な「X> Y> Z」視覚的なウィジェットの略。

— Su