A common approach to designing the content tree is to mirror the information architecture (IA) of your website. For example, your site’s information architecture may look like this:
I. Home
a. Products
i. Shirts
1. Men
2. Women
ii. Pants
1. Men
2. Women
b. Account Management
c. About Us
d. Legal
e. …
In this case, your information architecture includes a product catalog that organizes content first by the type of apparel (“Shirts,” “Pants”) and then by subcategory (“Men,” Women”). A first pass at developing your content tree might look exactly like your information architecture. When business users add a new men’s shirt, they will add it under /sitecore/content/Home/Products/Shirts/Men.
This is an extremely common approach to building the content hierarchy, and has at least a couple of advantages:
- Presentation elements such as breadcrumbs and navigation can be easily driven from the content structure.
- Simplicity and transparency; when the content tree and the IA are in synch, it is easy to understand the relationship between the two.
In addition to the above, this is a common approach because it leverages the work you have already done in defining the information architecture of your website. Through this approach, you are able to describe relationship through hierarchy. In other words, I know a product is a men’s shirt because it appears under Shirts > Men.
The limitations of this approach come up when the site implements a faceted navigation scheme (see http://en.wikipedia.org/wiki/Faceted_classification for more information). The consequence of faceted navigation is that individual content items may be displayed in multiple sections of the site. Consider the following information architecture:
I. Home
a. Products
i. Shirts
1. Men
2. Women
ii. Pants
1. Men
2. Women
iii. Men
1. Shirts
2. Pants
iv. Women
1. Shirts
2. Pants
Here, a men’s shirt could appear under Home > Products > Shirts > Men or Home > Products > Men > Shirts.
Even though it will appear in multiple places on the site, we don’t want business users to have to enter the content twice in the content tree. To this end, we need to define a content tree that is structured differently from the information architecture. In this case, we will define a content hierarchy that organizes products by season.
I. Home
a. Products
i. Summer 2007
1. Product 1
2. Product 2
3. …
ii. Fall 2007
iii. Winter 2007
iv. Spring 2008
Note that the content tree now looks completely different from the information architecture. Why organize products by season? This may or may not be the correct organizational heuristic, but the point remains: developers will need to create a logical content structure of some sort in the content tree. The structure of the tree in this scenario will be largely determined by other considerations.
Even in faceted schemes, developers may take a hybrid approach. While the “Products” section of the tree may be organized independently of the IA, the rest of the content tree may more closely follow the IA. Another hybrid approach could involve a mix of the IA and the faceted classification within the products section:
I. Home
a. Products
i. Men
1. Summer 2007
a. Product 1
b. Product 2
2. Fall 2007
ii. Women
1. Summer 2007
2. Fall 2007
There could be a number of reasons for choosing this organizational approach, such as ease of generating navigation elements, security considerations or publishing considerations. There could also be considerations here that are completely independent of Sitecore – you might choose a structure that mirrors your content taxonomy, reflects your business processes, enhances developer convenience or simply makes sense within the context of your organization.
When your content tree does not mirror your IA, your rendering logic must be more complex. But that is for a future post...
No comments:
Post a Comment