homepage Welcome to WebmasterWorld Guest from 54.167.138.53
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Hardware and OS Related Technologies / Website Technology Issues
Forum Library, Charter, Moderators: phranque

Website Technology Issues Forum

    
Building a Taxonomy
What if there are upper levels missing from the click path?
pageoneresults




msg:3544081
 3:50 pm on Jan 9, 2008 (gmt 0)

Let me present a scenario. You are working on developing a taxonomy for a fairly broad site but all the products are related. The upper level taxonomy may be 10+ categories.

Under those top level categories, there may be 5-10 sub-categories. Then we have another level and then finally a product page. So, we have what looks like this...

www.example.com/top/middle/bottom/product/

Here's the challenge. The URI strings are currently dynamic. We are moving into a rewrite environment. With the dynamic environment, there is no /top/ level. Everything goes direct to /middle/bottom/product/.

That /top/ level to me is where the "meaning" of everything below it begins. In converting to a rewritten environment, there are some challenges from a site architecture standpoint that may make things a bit difficult. There is no corresponding page to /top/, it doesn't exist. Now we need it as it becomes an integral part of the click path and the overall taxonomy.

I can't remove /top/. If I do, then we run into duplication of sub-category names in the URI structure, that won't work. I cannot easily add a page to that level either although that is my suggestion from the beginning, it has to be there or we lose that first level of taxonomy.

I should point out that my goal is to minimize the use of hyphens. If I didn't see any, I'd be jazzed. But, I know there will be 1, 2 or 3 here and there but not all in the same level of the path. I just don't feel real comfortable when the URI strings get too long and more than 2 or 3 hyphens appear. So this...

www.example.com/top-middle/bottom/product/

Isn't really a suitable option for me either which is one of the suggested routes if we cannot add that top level page in the taxonomy.

What would you do?

In the process of all this, I was directed to a site to use as an example. Yuck! Someone took a database of a few thousand products and put almost all the product pages at the root.

www.example.com/keyword-keyword-keyword

They did include a second and third level but things are a little backwards. Totally outside of protocol, that's for sure. In reviewing that taxonomy, the first thing I found was that they imposed limitations on their file naming structure. Exactly how many damn products can you get at the root level before you run out of relevant naming conventions to avoid duplication?

I know why they are doing it. But, I also know what types of challenges they just imposed on themselves too. Personally, I would never leave file naming up to the user. That should be done automatigically from the database using the variables available from the product record. To have the user perform a second function which allows them to name the files might present some very sticky issues moving forward.

 

jtara




msg:3544296
 7:39 pm on Jan 9, 2008 (gmt 0)

Why is it necessary to put the product pages under a taxonomy at all?

Yes, it makes sense for pages that list product choices or product-category choices. But once you've drilled-down to the product, why?

What do you do about products that fall into multiple slots under the taxonomy? Do you duplicate the product page? Then which one do you select as the "main" one? (and "noindex" the others to avoid duplication penalties).

Now, I'm one of those who goes "fishing" for pages that might not be linked, by mucking with the URL. Say, I've got version 2.5 of a product, but a site only lists documentation for version 2.0 through 2.4. I'll guess that the 2.5 info might just be there and alter the URL. Or I'll guess that there might be something at an upper level of the taxonomy.

But how many people actually do this? It's not a given that sites are or have to be organized this way. I just take advantage of the fact that many are.

I realize that this doesn't solve your problem - even if you just file products under /products/<part number> I guess you've still got a problem with the product selection pages. Just giving you something to think about.

pageoneresults




msg:3544399
 10:08 pm on Jan 9, 2008 (gmt 0)

Why is it necessary to put the product pages under a taxonomy at all?

You know jtara, that's a really good question and one that I've been mulling over since you posted.

Let me start by saying that I'm from the camp that believes there is a place for everything and everything in its place.

Taxonomy provides structure. It provides semantics. Not only from a theoretical standpoint but also from a usability one.

For me, it is natural for a large scale site to have at least 3 to 4 levels of taxonomy, it's almost a given. Your limitations decrease exponentially as each level is added to the taxonomy.

Yes, it makes sense for pages that list product choices or product-category choices. But once you've drilled-down to the product, why?

I don't know, because its natural to do it that way? Its what I've learned in how to best present a large scale database to the visitor? This is natural to me...

/top/middle/bottom/sku/

This would not be natural to me but is an option that has been discussed...

/top/middle/bottom/ then to default product reference of /mfg/sku/

What do you do about products that fall into multiple slots under the taxonomy? Do you duplicate the product page? Then which one do you select as the "main" one? (and "noindex" the others to avoid duplication penalties).

This is the part that gets really tricky. You have to make sure that all references to that product are via one default URI path. The other entry points are off limits to bots.

Or I'll guess that there might be something at an upper level of the taxonomy.

Very good point. And then you said this...

But how many people actually do this?

I do. That's enough for me. :)

No really, from a maintenance perspective, it's a dream come true to have an intuitive taxonomy for all involved. Why? Because it is something that can be easily learned by those involved with design, development, etc. And, depending on your audience, they may notice it too. There are all sorts of usability and accessibility features involved here.

It's not a given that sites are or have to be organized this way. I just take advantage of the fact that many are.

There is a reason why many are designed this way. It's natural. What's unnatural is to force a change in the taxonomy when following a click path downward such as the example above where the destination URI changes in structure.

I realize that this doesn't solve your problem - even if you just file products under /products/<part number> I guess you've still got a problem with the product selection pages. Just giving you something to think about.

Your input is most valued. Tis a pretty deep subject, even for myself. And, the more products you have, the deeper the damn subject gets! Pun intended of course. :)

Hey, I'd love to have /mfg/sku/ as the destination for all products and that is an option and should be for most sites. Which URI you choose as the default for the product is the choice that needs to be made.

Do you do /mfg/sku/

Do you do /top/middle/bottom/sku/

Keeping in mind that each level of the taxonomy has meaning in the overall scheme of things. There are naming conventions to consider, keyword in URI benefits, etc.

lammert




msg:3544423
 10:51 pm on Jan 9, 2008 (gmt 0)

Taxonomy provides structure. It provides semantics. Not only from a theoretical standpoint but also from a usability one.

Taxonomy only provides structure in a world where you can define a 1:N relation between your elements. Like 1 top category linking to X sub categories and 1 sub category linking to Y products.

Unfortunately this is not how items are related in most situations. Even in simple situations like shops we can often see a few:N relation. I.e. an item can be listed in category->sub->item, but also in newitems->item, christmassales->item, etc. Would you duplicate the item, or allow two different paths to that same item, breaking the strict structure?

It becomes even more difficult with M:N relations where every item has many relations with others. An example of this is wikipedia where it is very difficult to find a taxonomy. You normally don't walk through wikipedia via strict taxonomy paths, but via direct links between related items. These links can be either one, or two-way.

I have a few good performing sites which uses M:N relations between the pages. There is no taxonomy or menu structure and people navigate via links embedded in the text (like wikipedia) and hand-picked quick links in the margin to pages with related content.

I have found a number of positive effects of this:

  • Quick navigation for the visitor requiring less pages to load before he reaches the page he needs
  • Better pagerank diffusion throughout the site because there are no pages high in the tree without info that eat away a large share of PR
  • Good indexing by the search engines because every page has a number of links pointing to it.
  • Good ranking because pages with related content link to pages with other related content

Personally I think that these are the main reasons why wikipedia is ranking so high in the Google SERPs.

My motto: Build chaos and let the search engines and visitors sort out the structure they like.

There is one difficulty which makes it difficult to implement large taxonomy-less sites. The relations between all items have to be manually defined for optimal matching and that can take a huge amount of effort.

I have been in 2007 mostly in a place with a 33k6 modem connection over prehistoric telephone lines. That's why I didn't post much. But I am now back on ADSL, so duck and cover :)

pageoneresults




msg:3545078
 5:07 pm on Jan 10, 2008 (gmt 0)

Taxonomy only provides structure in a world where you can define a 1:N relation between your elements.

Isn't that how most ecommerce structures are? Isn't there ususally a "root" or "default" relationship between the product and a particular category?

Unfortunately this is not how items are related in most situations. Even in simple situations like shops we can often see a few:N relation. I.e. an item can be listed in category->sub->item, but also in newitems->item, christmassales->item, etc.

Ah, you answered my questions above.

Would you duplicate the item, or allow two different paths to that same item, breaking the strict structure?

That is what I'm trying to avoid. I can't allow two different paths to the same item, not for the bots anyway. The visitor can have all the paths they want, but the bot only gets one.

I have a plan to eliminate duplicates out of the box but it doesn't work with an existing architecture that cannot handle the changes required to make that plan work.

It becomes even more difficult with M:N relations where every item has many relations with others.

Tell me about it! That's where most ecommerce sites (dynamic) are suffering. They are using a URI driven architecture (based on taxonomy) and creating multiple entry points for each product.

I have a few good performing sites which uses M:N relations between the pages. There is no taxonomy or menu structure and people navigate via links embedded in the text (like wikipedia) and hand-picked quick links in the margin to pages with related content.

I'm not too certain that you could apply a Wiki structure to an ecommerce environment successfully. I don't know, I never attempted it.

There is one difficulty which makes it difficult to implement large taxonomy-less sites. The relations between all items have to be manually defined for optimal matching and that can take a huge amount of effort.

Bam! Can you believe that is an option too? Not me, I wouldn't want to work under that type of environment, too high maintenance. I'd rather let the dynamics and natural structure of the site do its thing.

lammert




msg:3545145
 6:03 pm on Jan 10, 2008 (gmt 0)

My M:N structure sites are not ecommerce and have content which is rather static in nature. This makes it a little bit easier to maintain than an ecommerce site where you have to change prices and products at an almost daily basis.

But I still feel that even in an ecommerce site interlinks at a deep level may be a benefit, both from the SE perspective and for the visitor.

If I go shopping in the real world, I first make a category descision: furniture, food, household, etc. Every category is a different shop.

The next decision is a sub-category. If my category is food, there will be a meat corner, vegetables corner, canned food corner etc. Until here your category approach works. If I want two items from two different sub-categories in a normal shop, I will walk to two different locations.

But the third level of shopping is where the decision takes place. Will it be Dutch gouda cheese or Danish blue? Hmmm, why not take the French brie? Psychology tells us that making decisions during buying is an iterative process. Looking at one product, than the next, back to the first, comparing prices and specifications. That is where interlinking can be a benefit. The visitor has the possibility to jump to related products to come to an decision. If you don't offer interlinking between related products, you might end up in a situation where the visitor will not compare your products on your site with each other, but your products with products from another store. In that case you might lose a sale.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Hardware and OS Related Technologies / Website Technology Issues
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved