Siolon

Counting Content Types

Stephanie Lemieux wrote an inter­est­ing post about the opti­mal amount of con­tent types to use in Share­Point. This is an inter­est­ing dis­cus­sion, because I’m now fix­ing the con­tent type tax­on­omy for a client because the orig­i­nal design firm didn’t give them enough gran­u­lar­ity in their con­tent types or meta­data. I dis­cuss along these lines with every poten­tial client explain­ing and jus­ti­fy­ing the time nec­es­sary to do a proper con­tent type taxonomy.

Unlike the author’s rec­om­men­da­tion in this post I would ven­ture on the side of over-architecting then under archi­tect­ing. Let me jus­tify it by the fol­low­ing reasons.

Nec­es­sary Granularity

Cre­at­ing con­tent types that are generic work very well as par­ent con­tent types that you can lever­age the power of meta­data inher­i­tance on the chil­dren, but it doesn’t do jus­tice to the vari­ety of con­tent most Share­Point instances con­tain. For instance, asso­ci­at­ing a con­tent type enti­tled “News Story” to all sub-sites where a depart­ment can have their own con­tent greatly increases con­tent query com­plex­ity. You could add a meta­data col­umn spec­i­fy­ing the depart­ment or query the library, but what if HR decides they want a cus­tom expi­ra­tion pol­icy that the other depart­ments don’t need? A new con­tent type is nec­es­sary to sup­port this.

Con­tent Types for Each List/Library

Stephanie ques­tions Shawn Shell in the arti­cle on a few points one of which being lim­it­ing a list/library to a sin­gle con­tent type to avoid con­fu­sion to the user. First, it needs to be estab­lished that every list comes OOTB with at least two con­tent types which are a folder con­tent type and the generic con­tent type for the con­tent (doc­u­ment, item, etc). While you want to not asso­ciate a lot of con­tent types to a library I see no rea­son a sin­gle con­tent type to a library is a bad solu­tion. I would be care­ful about cre­at­ing 20 con­tent types and then by appar­ent neces­sity cre­at­ing 20 doc­u­ment libraries, because Share­Point pro­vides us the abil­ity to attach mul­ti­ple con­tent types. Shawn warns against this by being aware that the con­tent types then guide clas­si­fi­ca­tion. While it’s true that con­tent type archi­tec­ture has a direct rela­tion­ship on clas­si­fi­ca­tion you can’t make a blan­ket deci­sion such as every con­tent type deserves its own list/library.

Main­te­nance Complexity

Shawn makes a good point that con­tent types are site col­lec­tion bound and hav­ing to mir­ror con­tent types between site col­lec­tions can be an admin­is­tra­tive night­mare. I attempt to mit­i­gate this by ensur­ing that as much as pos­si­ble that a cer­tain type of con­tent is bound to a sin­gle site col­lec­tion. While this isn’t always the best solu­tion, often a con­tent type such as “HR Pol­icy” will be bound to a sin­gle instance to store these con­tent items to reduce con­tent man­age­ment overhead.

Choos­ing the Right Designation

I also believe that a lot of the con­fu­sion around where con­tent goes in Share­Point can be greatly reduced when you take the time to cor­rectly name both the list/library and the cor­re­spond­ing con­tent types. Noth­ing makes me cringe more than a generic “Doc­u­ments” library with noth­ing other than the default con­tent types. The user is then forced into the same folder struc­ture they had on a file share. While this might be an easy tran­si­tion for an end user it’s not the opti­mal solu­tion in the new Share­Point par­a­digm.

Con­clu­sion

All of the peo­ple in this con­ver­sa­tion wish to opti­mize the user expe­ri­ence of Share­Point as well as uti­liz­ing all the great capa­bil­i­ties inside of the plat­form. While each Share­Point IA is unique I would favor more con­tent type gran­u­lar­ity for the rea­sons stated above.