In our Exchange we use the RUS categorisation, that categorisation is flat (non hierarchical) and contains 8500 categories.
But that non hierarchical structure is problematic for the functionality "Browsing categories":
You are obliged to have one category that is "mother" of all the RUS categories, but that mother category does represent nothing.
When you go to the tab "Catalogs" under "Browse" we have one link (the mother category) and if you click on it, you receive a page with all the child categories = one page with 8500 links to the different RUS categories:
* That page takes a long time to be displayed.
* It is far of being user friendly!
So now we are trying to find a solution to that uncomfortable (for customers) situation.
What we have identified as potential solutions are:
* disable the browsing of category
* having a limited number of links (e.g. 20) on the page that you receive after having clicked on the mother category with button: next 20 categories and previous 20 categories...
The goal is clearly to avoid to have a page with a list of 8500 links to categories.
Regarding the fact that some other Exchanges are using RUS, we were wondering what solution did you found.
Thanks for your help,
Sarah, you bring up a good issue and thanks for moving your discussion to the community forum.
Here's a few recommendations:
1. Do not use browsing tree: Shopping page only shows the first level BROWSING
(aka navigation) categories. To avoid using the browsing tree, create item
categories (aka genus) only and do not link them to any parent (browsing)
category. In this case, no browsing tree will show on the shopping page.
2. Use multiple first level parent categories based on simple rules: I know that
some exchanges categorize item categories by the item category names' starting
alphabet. Limitation to this solution is it only work in one language (not
working in Chinese).
Development is actively looking into the enhancement of support previous/next page in the browsing category page. However, we don't know if it will be built. Also, OEX.com
has acquired a hierarchy from Requisite.
From an oex.com perspective, Requisite created a browsing structure for us. It's
really the UNSPSC hierarchy. It sounds better than what Belgacom is currently
dealing with but does have problems that we have yet to resolve. The biggest one
in outlined below.
1) Browsing and genus level category names cannot be the same and they are in
some cases. To get around this we attached the unspsc number to each browsing
category, but this number displays, without any indication to what it represents,
to customers browsing our catalogs.
Perhaps Worldcrest group can add their Requisite experience here. Are there others out there that can share their solutions?
Oracle Exchange Developmen
Our solution to this problem may not be necessary once the Requisite eMerge 3.0 is released. That will allow the transfer of the Table of Contents.
We now create a separate XML hierarchy file that provides browsing level categories. This allows us to create three levels.