SharePoint Content Types: Is this a lost cause?
Guest Author: PatCharles Iovanella
I work for a firm with over 44,000 SharePoint users. Of that, a little more 10% are actual site owners. As the Americas SharePoint Evangelist my focus is on end user adoption, best practices, site design and site administrator training. I have implemented diverse training methods and covered many topics to get that 10% using SharePoint to its full potential. Much of what I have preached has been widely accepted and implemented…except for content types.
I have demonstrated the awesome power of content types through our internal SharePoint newsletter, created training videos and conducted one-on-one training sessions. I designed and implemented a global online SharePoint Advice Center to answer all SharePoint related queries. We have had over 600 requests for SharePoint assistance. Not one of these queries was about content types.
We even had Mark Miller provide classroom training with key focus on content types. These classes ran for a good 10 months (2 per month) and were sold out for every session. In the labs, attendees were awed by the power of content types. They loved them. They saw the enormous benefit. But something happened the moment they went back to their workstations. Nothing. They seem to lose interest. Why? Are content types too difficult for the average site administrator to implement? Does going into the Site Content Type gallery evoke fears of destroying existing list and libraries? Is the concept just too “geeky”?
I have done a bit of pondering on this and tried to think like the average site administrator (Definition: Average site administrator- A person whose manager has made them a SharePoint site administrator)
I have concluded three things about my average site administrator:
- They don’t understand content types
- They don’t care about content types
- They don’t need content types
In my firm it’s most likely a combination of 1 & 3. But isn’t that the true power of SharePoint, its flexibility? SharePoint gives end users many different ways to achieve the same end goal. And at the end of the day, should I really be that concerned if they don’t understand or use content types? Should I let the average site administrator remain in ignorant bliss? Or should I continue to push them out of their comfort zones into a brighter, bolder SharePoint world?
Does anyone else have a similar situation with content types? Or maybe some other feature or function in SharePoint where the “buy in” or concept is just not catching on?
Guest Author: PatCharles Iovanella
PatCharles Iovanella works for major financial institution as the Americas SharePoint evangelist and subject matter expert delivering SharePoint business solutions to internal clients. You can contact him at [email protected].
on
I see the same thing. Content Types seem more of a necessity when consultants and/or developers are building out a consistent SharePoint experience or business process. Once left in the hands of end users (even power users) they don’t get used often.
Eric,
Yes, I see the same thing. Which makes me feel that the concept is beyond the “non – technical” user. Maybe we need a “Content Types in Plain English” video :)
Regards,
Pat
I’d suggest adding this to your list:
4. They understand and care about content types, but the benefit of implementing them does not offset the costs
One of the problems of large organizations is that a task which would benefit the organization does not benefit the person who would carry out that task. I would predict that a site administrator whose time is assigned 100% to SharePoint would implement content types. I would not expect content type creation from the average site administrator with fifteen other responsibilities.
FJ,
But there lies the problem; there are no 100% site administrators. And if there was I would tend to agree with you.
Pat
20 modules, Beginner’s Guide to Content Types (SharePoint 2007).
http://www.endusersharepoint.com/blog/wp-content/uploads/Video-BlogPosts/2008-06-25-BeginnersGuideToContentTypes/2008-06-19%20Creating%20Content%20Types.htm
Mark
Thanks Mark, I can cetainly post this link once again.
I’ll work on Content Types right after I get even one end user in my organization to abandon folders.
I’ve made some good progress in demonstrating filtering, grouping and views… but yes there are some who just can’t let go of folders
How do you make them deal with files with the same name if you’re folder-less 100% – I don’t want to start the whole debate on whether the folders are good or not – just this point…
Folders are a content type! Add metadata to them instead :)
Yes, but end users are utilizing them as Content Types. They are a bad habit from shared drives.
I meant “are not” untilizing
I have the same issue, Eric. Even though I’ve shown users how much easier (at least to me) it is to filter, group, and sort, the majority just MUST have folders and then they confuse themselves trying to upload documents to said folders.
As a SharePoint site admin, designer, trainer, (guru at my place of work), I’d be happy just to get users to login to SharePoint correctly for a full year! (every 3 months they forget their password… probably because their domain passwords have to be changed every 90 days!)
Had I known more about content types when I started designing our sites, I never would have taught users how to create folders in the first place.
Ahh well… it’s a living, breathing, entity (or at least it seems that way) and perhaps with time users will see benefits of doing thins “differently”….
There are a few things that I do, one is similar to yours in that I create some common content types and make sure they are usable from specific document libraries. The other, more important, thing I do is that while I explain the technical term “content type,” I always use a simpler term such as document template when talking about it in some specific applications. This takes away some of the friction towards undstanding, and then I can focus on simplifying the steps they need to create their own or modify the custom ones already made.
But yes, this is one of the harder pieces to teach admins, but rewarding as all get out when they get it.
Depending on whom I talk to in my organisation, I do not even mention the term “content type”, but rather do something like you and try to bring the meaning across. I also had better experiences that way
Pat, such a great post. In 3 big companies I’ve worked with here, (43 000 users, 28 000 and 8 000) – none of the IT nor Business teams either understood nor leveraged content types. In my experience it is not well known, well communicated nor educated – and can get really tricky to implement. The functionality is a 6 step process to get them activated on a document library basis – but who governs this and on what level?
I’ve seen countless consultants trying to pitch these solutions and while I certainly understand that for long term search purposes, that it’s the way to go – the message does not filter down to the people that need to use and manage them.
I’ve seen countless questions from business users go unanswered on LinkedIn on this subject, or alternatively seen it turn into a war.
The experienced specialists out there may scoff at this post, but it’s a very a valid question even today, because business users don’t get it. No are they often assisted enough to enable them to do so. In very large organisations, content types can become very overwhelming due to the governance aspect involved.
And I agree, if they get it – and have the resources to govern it – then great. But if not, it falls by the wayside.
“The functionality is a 6 step process to get them activated on a document library basis – but who governs this and on what level? ”
Those are among the two biggest issues I see with Content Types, they’re not easy to set up and proper governance should be followed. It took me some time to understand the benefits of CTs, where/when/how to use them, and even nowadays I encounter situations where I wonder if a CT is good or not. And I have the advantage of being the only one in my company (or at least here for our deployment in Asia Pacific) to define and manage the CTs. Not because I don’t think others could do it as well, but for the colleagues from Finance/Sales/Marketing/etc. it may just be too much to learn, and they’d rarely apply it.
Pat,
Could you elaborate on “the power of content types”, and the “enormous benefit”? Maybe provide some examples?
Honestly, I don’t see this at the site administrator level. Content types can be convenient, but there are other more straightforward and accessible ways to organize your content (for example create two lists instead of one list with two content types). Content types really make sense for large scale deployments, when they are served to the users as part of a template.
btw I made two assumptions on your post: 1/ by site administrator, you don’t mean site collection administrator (SharePoint sometimes uses “site” for “site collection”) and 2/ this relates to SharePoint 2007.
I respect your opinion a lot Christophe, but I have to disagree about Content Types being geared towards large scale deployments. One of your questions is to elaborate on the “power of Content Types”. A major Content Type ability comes to mind: I can attach specific workflows to a content type. This proves crucial to a project management app that I’ve built and has laid the ground work for each project type to have a well defined business process. Without these Content Types, I feel this application would have turned out to be a sub-par solution.
Maybe that’s the “enormous benefit” too… Would you agree?
Matt, you could as well have built one list for each type of project, and attached each workflow to a list. If you just do it for one site (which is the topic discussed here), I would not call this a major benefit.
I’ll also remind you that you are not the “average administrator”. Would the average site owner in your organization be able to do what you did on his own?
If I keep getting compliments like that, I’ll be doing SharePoint for NASA, soon enough ;-P.
I think I follow your thoughts now in regards to Templates and Content Types. To make a template out of the site I have built and allow sites to be created from this template, would make a much better solution for a large scale deployment. In my specific case, it was better for me to have one site and one list for all of my projects. You are spot on about an end user diving into some of the XSL I built up and workflow logic. It *would* be asking a bit much.
P.S. I did use EasyTabs!
Christophe, for me, the benefits of content types are around document management. You can assign different metadata columns to different content types to help you view, find and ease the process of uploading for different types of information as well as assign information management policies, templates and workflows. Content types allow you to maintain control over the use of information at a higher level level than document libraries do – one change of workflow, information management policy etc in a content type filters to all libraries utilising your content type. It’s a question of control and managing information.
For me, content types are not an end-user or site owner level feature, they are something an implementation team should be defining as part of the information architecture. Obviously they have advantages in self-contained solutions (such as the one Matt mentioned), but generally they are something that is used but not defined by end users. It would be great if site owners leveraged them, but defining them in the first place is very, very difficult in my experience, and this generally puts them off.
Nathan, this echoes what I and other commenters said, and you’re spot on when you talk about information architecture.
Where I would differ: for a large organization – as is the case for Pat – you cannot expect the implementation team to address all the needs. You may define company wide content types, but divisions or groups of a few thousand people will have specific requirements, that they can implement on one or a couple site collections, from the user’s side.
Here’s an example of a content types for a calendar that reasonates with my site owners.
Almost every team wants a single calendar to track their team’s out-of-office time, client events, mailing events, etc.
What they typically do is create a calendar, add every possible column that relates to any of these event types and then fill-in only the fields that have to do with the event they are adding. That means that they can’t require certain fields for certain events, and that they see unnecessary fields like Client Name; Event location, etc. when they are just trying to enter some out of office time.
I demo how to create a calendar with 3 different Content Types – Internal Event, Client Event, Mailing Event. Each content type contains different columns appropriate only to that type of event, and they can set which ones are required for that event type.
Sidenote: Now, if only I could rename Content Type to Event Type.
I won’t go into more detail because I think many here “get it”, but it’s a good example that most of my colleagues can wrap their heads around.
Do they rush back and create the Content Types? NO! It’s the same situation, they see the power but they’d like me to come create it for them because they have “a real job” to do.
Colleen – can users create/edit events in your CT-enabled calendar from the Outlook client? (How to get content type assignment into the outlook client, so that outlook-enslaved users can continue in their paradigm…?)
Colleen,
I love this example. It’s a great way to manage a ton of information, while being able to filter by event type.
When I create a calendar like this, I built a base content type from the “Event” content type, then created the child CTs off of that. Creating them this way allows a consistency in the base information, but gives the ability to add different types of columns for Asia vs US events.
Great idea.
Mark
We haven’t investigated that yet. Alas, that is a drawback because people love to live in Outlook. I would expect a custom form could be created or a SharePoint/Outlook add-in might be available.
We’ve done something similar for a number of our calendars, too, Colleen – great use of content types. And folks are really impressed when you use Christophe’s color-coding trick to make them pretty. Ah, it really is the little things ;0)
I almost mentioned Cristophe’s color-coding too. Great stuff. We went ahead and sprung for the Bamboo color-coded calendar to keep it simple for the users, but I use Cristophe’s color-coding extensively, especially for project sites.
Nice post.
In my experience content types are indeed a complex thing for end users. The problem with setting up content types is that you often have to think top-down and not buttom-up. The end user does not always know the complexity of what is happening on another (higher) level.
I try to use content types instead of folders (i know that folders are CT’s) but it is hard to convince the users!
Yes true. We’re still busy trying to get them to embrace metadata instead of using folders; content types is way too much info! :-)
The only content types I’ve seen Sort of being liked, is to put a blank PowerPoint and blank Excel document onto a document library along with the default blank Word doc. This encourages users to stay in SharePoint as they can create any new document and save it in the right place then and there. But even this is not widely adopted.
Another problem with proper content types alot of the time, is that they don’t have the right templates to begin with to attach to the content type. No-one can decide which ones should be the official ones, no-one wants to take responsibility for it. Enterprise CT’s is an enormous task, insurmountable most of the time. What puts them off too is the fact that if the template changes, it has to be manually changed on each site collection. 2010 is better with that, but it’s still going to be hard to manage in any big company. Is there ever standardisation in them? Seldom. They can’t even decide which Minutes template to use, never mind anything else more important.
Very Good Point!
LOL, this is sooooo true. Happens everytime…
In two years, we will be seeing identical posts with the term “Enterprise metadata” in place of today’s “content types”.
I think this will continue to be one of those hidden gems that will provide value to those who use it, but it won’t apply across the board.
I’d love to see a way to “attract” or “entice” site/site collection administrators to use content types by enhancing centrally-defined content types witih enterprise metadata attributes, and allowing a site collection administrator to “tap into” column types and web parts that are pre-built to leverage enterprise content types. This will be hard to do, I understand, for almost all enterprises, but if site collection administrators get content type training, and then are able to utilize centrally-defined content types for their first project so they aren’t faced with the “blank canvas” when they return to their cube, and they can create their own initial content-type enabled list, *then* the metadata seed may take root and germinate.
Trainers will end up differentiating themselves from other trainers by providing better post-training implementation enablers.
Spot on!
I’d like to echo the “Spot On!”
I REALLY wish that those original architects of our SharePoint implementation had known about and utilized content types. I think quite a few SharePoint noobs learn by reverse engineering (at least I know I did!). Having a place to start that is relevant to *your* organization can really provide some inspiration and confidence to consider Content Types when thinking of business process solutions.
~Tasha
Nice article, in my case the problem is mostly with “They don’t care about content types” and “They don’t care about SharePoint”. I do not know how to solve these… :)))
From technical perspective: In an ideal case I would love to see a stronger Word + My Documents + SharePoint integration where users could automatically create and save documents from their Word clients without worrying about background stuff. I think the current level of integration of these Application is still too complicated for End Users.
But you have to admit with Office 2010, it’s a lot better now.
It is, but needs to be even simpler for end user and with more options for admins.
If you could enforce your Enterprise Content Types instead as Word Templates and require them to use one from the list that would be cool IMHO.
Unless you happen to be in an organization that is still trying to push office 2007.
I’m in healthcare, so a many of our lists deal with Protected Health Information (PHI) Because of the beefed upauditing/policy capabilities that a content type provides, they are no longer an option on lists that might contain PHI, they are mandatory. I think it takes only a few practice runs (and a bit of reading here on EUSP) to really see the full potential of content types, but I’m not sure I would even encourage end-users to implement, at least not without formal planning and approval (not to mention education.) From experience I’ve seen what a mess can be made of building content types and site columns if you don’t know what you are doing – the cleanup is no fun!
Understood. But in my case these site administrators were given the training. 2 days fo drilling the concept. So, proper training was not the issue. I guess a poll after the course on why they have not implemented any content types may have added some extra insight into exactly why the concept did not cross over into thier site collections. “Fear” and “no time to test them would be a good guess.
Content Types are an abstract database design concept. It gets into classes, attributes, methods and instantiation. This kind of stuff necessarily stays under the hood for most users. Just as most users don’t need to learn SharePoint Designer, most users don’t need to know content types. They only know what kind of work they want to get done, and Content Types are a means to an end. It takes a pro to understand when and where to use them. “You want this document to automatically come up for review in 6 months? I know how to do that.”
Naturally it makes life easier if you have customers / coworkers who are willing to learn the concepts behind content types (or site columns, or even metadata), which would certainly lighten your load… but I don’t think there should be any expectations there. I’m happy enough when people are using the darn site at all.
Ok, this shows enough interest to have its own web broadcast. What’s the interest level in hearing a bunch of war stories told first person? I’ll set it up for this Thursday at 1:00pm EST if we can get 10 people to volunteer to tell their story. Pat, I’ll assume you’re in, since you opened this Pandora’s box. — Mark
I would love to sit in on this call. However, I dont have a story to tell as we are currently in beta testing for Office 365 and moving to SharePoint 2010. I’m interested to hear how migrating from 2007 to 2010 and if this was a manual process or automated. I’d like to hear all that entails so I can prepare.
Thanks!
I would love to but have a conflict on Thursday. Friday is good for me
Man, this is some great feedback. Should I even mention the word “taxonomy” ?
As an Administrator, I could not survive without my Content Types. Do the end users know anything about them? NO.
I have no expectation that they would, but we are heavy InfoPath here, and it all goes hand in hand. Further, my content types are tight with my custom columns and lookup lists.
This is database related stuff, and YES taxonomy.
I prefer my end users avail themselves of the Content type, but I believe its up to our SharePoint team to manage and deploy them.
My gut tells me that the only way to get people to use them is to make them part of the business process. This means that they have to be created beforehand.
I don’t see most SharePoint users particularly interested in customizing the system. They will work with what they are given.
I completely agree.
“at the end of the day, should I really be that concerned if they don’t understand or use content types?”
Just my personal opinion but while I would say you probably shouldn’t be concerned that they don’t understand or use content types I know it would bug the heck out of me.
“Should I let the average site administrator remain in ignorant bliss?”
Probably a little too late for that since you’ve invested time and effort in training and education on the topic.
I’m going to come off sounding lik ethe SharePoint Nazi here but what I do is essentially tell people flat out……..”No, you cannot create folders” and I turn them off every place that I can. I do tell them the reasons behind my stance but I don’t let them argue their way into using them.
If I get a request for a solution where folders are the only feasible answer then I’ll create the folders as part of the solution and when it goes live the option to create folders is set to “No”. Over the years I’ve seen too many folders named something like “My superduper long folder name that reveals nothing but tells all”.
Now back to content types in general, end users don’t need to know. They need to know that they have templates at their service that are used for specific purposes or that they need to provide certain pieces of information when they create a new list item, add a document to a document library or create a new calendar entry. They don’t need to know the mechanics behind the solution because ultimately they don’t really care. All they care about is “Is the system easy to use?” and “How many fields do I have to fill in?”
As for your site owners/administrators, they should care but obviously they don’t. The only solutions you have there is to either replace them (office politics alone will make that difficult), hold their hands every time they create a new library or list until they get in the habit of leveraging content types and/or site columns or do it yourself (doesn’t sound like an option in your case).
You could add verbiage in your governance policy that mandates that content types be used but then you get into issues surrounding compliance and how you address situations where someone has ignored the guidance. This is a potentially huge minefield if you have site owners/administrators that are actually making the members of their sites use them. You don’t want to alienate anyone so that they go down the “I’m going to take my ball and go home route”.
Lost cause? No
Extremely painful? Absolutely!
It’s hard to create predefined content types when teams, departments and divisions have different requirements and processes. So it has to be the burden of the Site collection administrator to build these targeted content types. Project Status and Phase may have different meanings or options to different departments. This is my world. It may not be yours.
“Pat’s World” best describes 95% of the information ecosystems out there – even the most comprehesively staffed and funded IT implementation teams cannot anticipate *all* of the end user scenarios that exist now – or may exist tomorrow. True Continuous Improvement can only be sustained if the end users are entrusted with the knowledge and ability to implement the tools.
Seems like much of the Sharepoint content out there ignores the interaction of BI tools (SSRS, PPS, Excel) with Sharepoint… We create pages with PPS, Excel Services and Reporting Services web parts (”reports”) which are stored in page libraries. We create Excel workbooks (aka “reports”) which must be stored in document libraries. We publish dashboards from PPS (aka “reports”) which are stored in document libaries even though they’re pages. To an end user, they’re all reports – views with data.
I’ve found plenty of examples to search across site collections but have yet to find a way that combines results from mutliple library types. I did find a way to tweak the CQWP to search by base list number (fortunately, document and page libraries have the same one!) which is okay. Using content types – each of the above being a child of “report” for example – would be much easier. Searching by a specific child or the parent combines all of them. To me, this is an advantage of content types that far outweighs most of the arguments I’ve seen against them.
Fundamentally there is a difference between leveraging content types in a couple lists/libraries, building their own content types at a site collection level and building out content types (or types of content) from a top down global level (think content type hub in SP2010).
There is also a massive difference in maturity/expertise from say a site administrator who administers their own search scopes, one that creates subsites, and a site administrator who administers libraries and lists in an existing site.
Here is the simplest explanation I can think of (rather than give a 10 page description):
If the user is at the search scopes level of maturity and the site collection or higher level of scale – Content Types = Very Valuable and will be used.
The second you go lower than that it becomes less and less effective, and quite frankly less and less useful from a creation standpoint (NOTE: This is where content type sprawl can happen – and is never good in my personal experience – and yes – content type sprawl can happen).
From a consuming standpoint it depends on the maturity of the organization as well as the maturity of the ‘consumption point’. The usage or consumption of Content Types is a really grey or ‘it depends’ conversation. But I feel like the creation one is a much easier discussion.
What do you think?
Another reason why content types may not be used so readily implemented is because many sites have been migrated from 2003 to 2007. Therefore, list and libraries have already been established and heavily used. So, switching an existing list/library to use a new content type is not practical.
As someone who meets your definition of the average site administrator (”A person whose manager has made them a SharePoint site administrator”), I have to say I don’t understand content types, and I’m intimidated by the thought of how complex and time consuming it would be to implement them on an existing site collection. They’re not used broadly within my company and no one has offered any guidance around them. While I suspect that content types would solve a number of headaches for me and provide us with some very clear benefits, I’m afraid to venture into that forest unescorted and perhaps not be able to call my IT team to rescue me.
But this discussion has inspired me to start exploring the edges of that forest. Thanks for sharing.
So…how do you know if you used content types correctly if you’re just a tiny little site owner like me? I just had to bring it up because it sounds like I’m using them…differently.
I used them in a project list for my team. We needed a way to track a lot of data about a lot different projects – most of which never have a word document associated with them and the bulk of my file types won’t fit or don’t belong on SharePoint (e.g. raw video and .indd files). I know I could have tried for some InfoPath forms but I wanted to keep it strictly within the browser and we don’t have that services function. Which was really important considering, not everyone I work with has InfoPath. So, that’s why I went for a list in the first place.
I didn’t want to bother with five lists for five different project types and aggregating that together so I could see my current workload. Thus, I opted for content types.
The list itself has five content types: Print, Graphic, Copy, Video and Team Administration. They share similar columns such as Assigned To and Status but that’s kinda where it stops. I thought they’d be the right way to go since I didn’t want certain columns to be available for every project type (e.g. quantity is print only, the video format drop down menu is video only, etc.). I need to be able to filter/group (and not forget key details) so a large but vague field to encompass that all wouldn’t work.
The list also seemed to be the easiest way to have a web part grab the data and make pretty charts for me.
So, the real question is this: did I miss something totally epic and only think what I did is cool because I’m ignorant? :)
Hi Pat, do you have a survey system that helps you to define where SharePoint is failing on your users?
I can’t teach my mom to use pivot tables even I’m sure she would get benefit out of them. It is not that she can’t learn, but she doesn’t find how to apply that to the important problems she needs to solve now.
Would be so interesting to ask your site administrators how do they think they could use content types and then after the answers run a survey on users to vote which one of the alternatives could really solve a problem they currently find as a priority.
Jose,
Not sure I would accuse SharePoint of failing my users. I don’t think it does. It’s more an issue of some site administrators not knowing the needs of their end users. And if they do, how to implement those needs using SharePoint to its full potential. But if, at the end of the day, SharePoint gets the job done, that’s all that matters to most site admins. And that brings me back to my initial post: As a SharePoint evangelist, should that be good enough for me to accept?
Hi Pat, I didn’t mean “fail” in that way. Sorry for that.
What I tried to say is: Where your users can find more use of SP, what kind of problems your users would find valuable to solve. And how the usage of Content Types could adapt to that kind of requirements.
I understand the role of an evangelist not only as letting know people what is possible, but more as where the value is. SharePoint holds a lot of value! but some language, like the case of content types, is not only geeky but it is confusing.
To answer your question I would say: Resignation is not an option. Finding the right value proposition should be the right thing to do. As you said, some admins aren’t aware of their users needs, and that is the root of the problem.
Because this site is “End User SP” I would suggest on building a “SP Geek” to English dictionary!
So Pat, maybe this is the issue: you expect 10% of your SharePoint users to have the skills of a business analyst (without training), and the abilities of a SharePoint designer (after a couple training sessions). And do all of this on top of their daily job, of course.
Owen Allen talked about post training implementation enablers, but I believe the pre-training phase is also key. Rather than a broad-based training, I find it more efficient to concentrate on the few people who display the required skills and motivation, and make them your SharePoint champions. Later, you can use these early adopters to build success stories that will motivate others.
Hi Pat!
As a french speaking person, expect strange sentences but i am sure you will decode my english.
Before using Content Type (I will speak for 2010 release), we must understand that the structure of data (list) have no meaning in SharePoint. From relational structure point of view, all your site data reside into a single table in SQL table (AllUserData). ContentType is about metadata structure model. Content Type provide inheritance and behaviors in total independence of is container (List/Library). A Content Type with all is behaviors can surface is data in many Lists of your site or a list can contains as many Content Type as you want applying behaviors to each Item of is CT.
Sharepoint 2010 is a application platform and to master it, you will have to look at it differently, don’t try to reproduce way you have done thing in the past.
Try to change the structure of one of your table in a database, I guaranty that the phone will ring. Sharepoint allow me to inherit of a existing Content Type, modify is metadata structure, change is behaviors true eventsReceivers and workflow, publish true a features and all that, with out disturbing existing structure and behaviors.
Content Type is hart and soul of Sharepoint for Apps development, but you are write on one thing, it is nothing from easy to master.
I come back to EUSP because it often shows me the right way to do things.
I’m joining this thread so if Mark ever gets the webcast going.
What I’d like to see is how content types have helped.
The problem is that this discussion is on too abstract a level. I don’t know if that can even be helped.
(need 15 more examples like the Projects List example, (5 CTs – Print, Video, etc.)
Content Types are inheritantly an abstract concept. Abstract thought is a challenge for a huge percentage of people. They aren’t stupid by any means but when when people want to discuss a solution they want to manipulate concrete concepts, usually the business concepts at the heart of whatever fire they are fighting at the moment.
Instead of expecting your admins to all be good at manipulating abstract concepts from scratch, offer to help. Sit with them and ask, “Is there something about the current solution that needs improvement?” Be a partner in the solution, which in this case means creating the Content Type for them to use and give you feedback. Eventually they will come back for more and eventually you’ll have so many requests that they’ll have to take a number.
Be the catalyst for change instead of expecting each user to change first.
Kelly,
I think I agree with you on your comment but I’ll just add my bit here:
I also think that Content Types are an abstraction also – but unlike Greg I think they are more than just a database design concept, they are far more abstract than that :-) – OO coding principles are the same for example.
I too wonder whether non developer/IT Pro people think along the same lines of abstraction/reuse? My experience is that they don’t – what ever gets the current job done is what gets implemented.
Let’s be clear here though, thinking in abstract is not easy and usually not 1st nature for lots of people – using the OO idea again, I well remember switching from procedural code to OO – it took time and effort to change the way I thought and coded – if I’d not been doing it full time I may not have got it or it may have took much longer.
So, can we expect people who aren’t admining SharePoint as their number one job to be able to get/implement content types? I think no and that Content Types will, on the whole, remain the domain of the IT professional.
I have to admit that I’m a little farther along than the “average SharePoint administrator” (as I’m responsible for the business side of our entire farm – approx. 100 site collections), but I have the hardest time wrapping my head around content types for documents, outside of the use Veronique mentions of having Word, PowerPoint, and Excel options on the New menu. The only success we’ve had in using content types in my organization (around 8,000 employees) is to use them for request lists and project management, with a few forays into using them to support a multi-step process (inspired by Laura Rogers’ article from EUSP, if memory serves). Even at our portal level with MOSS, we don’t use them, even though I know we probably should. The biggest benefit I see there is the use of the information management policies, which we sorely need to use.
I guess my real problem isn’t the content types themselves – it’s more an issue of classifying our portal content into standard categories that would benefit from common metadata, workflows, etc. I think our “average site administrators” have the same issue. It doesn’t help that many of our sites were just migrated from SharePoint 2003, or documents were just dumped into SharePoint as people panicked when Network Services got rid of our shared drives. So trying to implement a content type system would be quite a challenge in our current sites.
Our administrators (even those who really embrace their roles as SP champions for their groups) are doing well to just keep up with the daily ins and outs of their sites – to take on the development of a content type system would be a huge task that many of them just don’t have the bandwidth for.
Looking forward to further conversations on this!
I would agree with you that content types are under-appreciated. But then so are site columns and Content Query Web Parts; and like CTs, they all need some level of customization to make an SP solution sing. And this doesn’t even address why MS opted out of making filtered lookup columns a part of WSS, MOSS or Foundation or the difficulty of leveraging site columns in the promotion of InfoPath form fields. Any of these would greatly assist the end user to see the value of content types. But I would say the reason most folks don’t leverage CTs is they simply have other things to do that prevent them from the trial-and-error that would invetibly lead them to our conclusion. And while I love the product, it is clear to me that MS missed a couple of key opportunites to quickly demonstrate the usefulness of CTs by the omission of some pretty remedial capabilities from the OOB versions.
I started this discussion with the end goal of discovering if content types (as powerful as they are) are a necessary component for a SharePoint site collection. Is Content types a tool worth preaching over and over to site administrators? My answer is, yes. I will keep preaching from my soapbox about content types and all the other underutilized SharePoint features and functions because that is my job, and I love doing it. And if a site administrator finds one great tip out of a hundred newsletter articles, on- demand videos or classroom training sessions and that makes all the difference in a business process, so be it. That’s a successful SharePoint site!
Thank you all for sharing your thoughts and feedback. I have enjoyed reading all your posts. Many have been very insightful (some argumentative) and I value your opinions.
Pat, I’m in awe that your company sees fit to have a full time Sharepoint Evangelist. Even with some basic training on Content Types, I have only started venturing into them after reading this post, and I am finding that Microsoft designed them to drive normal people insane.
For instance, I’m trying to build a Contracts content type in SP 2010 as a list content type. (Why not a document contract type? Because that doesn’t fit with how real people do their work in this case). I want to be able to quickly and easily create custom Contract lists for different departments, so they can only see their own contracts.
I need a number of workflows to manage certain behaviors of my lists, and hence I have several columns in my master list that I don’t want ordinary users to see, but I do want site admins to be able to get at them when needed. When I mark those columns as Hidden in the content type, they disappear entirely and I can’t see them in the List Settings. Go figure.
I’m sure if I had the benefit of all the training Pat makes available to his people, I’d have less frustration. Even at that, my experience is that counter-intuitive, crazy-making topics like Content Type creation don’t stick with students even after training unless they use them right away.
My two cents worth.
Keith,
Congratulations for giving content types a try. What you should be doing is create a base Contracts content type with all the columns you want your end users to see. Don’t hide them. Then create another Contracts_Admin content type using the Contracts CT as its base. Here is where you can expose those extra admin columns you were trying to hide within the Contracts content type .
Give that a try
Pat, thanks for the hint. I solved my problem by leaving the columns as optional in the CT, adding the CT to the list, then editing the CT within the list to mark the admin columns as hidden so they won’t show on New, Edit and Display forms, but I can still see them in List Settings.
But having solved my problem, I’m now curious as to why you would suggest a base Contract CT and a Contract-Admin CT. If my base CT only has the fields the users are to see, how do I fire my workflows on the admin columns? I need the admin columns to manage the workflow looping required to give reminder notices to users at various intervals.
If I just add BOTH the base CT and the admin CT to the same custom list, what have I gained over including both in a single CT?
Keith
I put together a solution like yours about 18 months ago. CTs were indispensible but it took me a while to figure out how to use them effectively. And it wasn’t a simple task: I had to set up many of the contractual details via InfoPath forms, I had to build modular contract sections/forms (e.g.Terms & Conditions and and payment terms) that would update throughout the various contract sections based upon a single input (e.g. project manager updates, delivery schedules, contractor/vendor data changes, etc). It turns out I spent the bulk of my time simply arranging the metadata used throughout the process (dozens of fields) into distinct CTs. I kept the UI simple enough to have a cafeteria style contract builder and flexible enough for the more savvy project managers to mix and match contract sections (read: CTs) to meet their particular requirements. I rebuilt it three times before I got settled in…but it is alive and well (and even passed muster with the general counsel). My lesson was that no class would have replaced the dead-ends and false starts that preceded success. And I suppose that most folks new to SP would have to go thru a similar process to see the real utility of CTs.
DoubleD:
Thank goodness I’m not trying to create a contract authoring system, as it sounds like you did. It sounds like your experience confirmed that one doesn’t “own” knowledge of how to use Content Types until one has actually used them, and banged one’s head against the wall enough times in the process.
Pat,
An interesting problem. The question I would ask is: What is the benefit of using a content type in a certain situation? Can that benefit be cost-justified? What if you could save two days of the administrator’s time for training, plus the cost of the training room, trainer and travel? Could you avoid teaching a topic that is rarely used and apply that money to a better use?
What if, when a site gets provisioned, a person who DOES understand content types and their use in the organization, sits down (maybe virtually) for half an hour with the site owner/admin and gets an understanding for what the site is going to be used for and what content will be stored there. In many cases the decision may be: “This is simple, go ahead” (i.e. no content types required). Alternately, the decision may be: “This library is going to hold corporate assets (info) that needs to be managed properly, made easily findable, filterable, etc, and REQUIRES properly thought-out metadata/content types. In that case a (relatively small) investment will be made to get this done quickly (avoiding a bunch of ‘futzing around’ by someone who’s time is better spent elsewhere).
I am assuming that I’ll hear some people say: We have 10,000 sites! Do you know how much that would cost?!? My answer is: Don’t do it if you can’t see a (hopefully measurable) benefit. Do it only if it provides value.
Has anyone tried this approach?
Good thread!
Ruven
I’ve made an attempt to use CT when I was desgining a way to do a company wide employee review process, including salary list for all employees in SP without the use of any third party aps, and keeping the use of SPDesigner down to a minimum. Unfortunately, the use of CT’s did not help due to the extreme permission levels I had to create in order to prevent employees from seeing others reviews or their salary history. It would have been very beneficial if CT’s could be made permission sensitive. I could have saved many hours of development time to do the entire employee review process.
As an aside, it is hard for my users to learn how to add fields to a list, or to create views to a list unless they do it often enough, let alone trying to teach CT’s. Still, I think it’s worth trying to impliment – but the bulk of the effort will be on the site admin or a few power users to champion.
In your particular case, you could have tied a workflow to the content type(s) and allowed the workflow to set the permissions you need. Assuming that there was a logical method of applying the permissions.
I agree with you though, it’s something that would need to be implemented at a site administrator / developer level to be truly effective.
I don’t ever teach content types to site admins or business users unless or until they have a business need that calls for it. I have had several instances where users pick up and learn to really love their content types, however. Here’s an example of one content type implementation that’s caught on here:
Users need to create a “simple” list form for their customers and then want additional “for office use only” fields to display once a new item is submitted. Rather than setting this up via a custom form in SharePoint Designer, I use content types and a SharePoint Designer workflow to convert the content type value once a new item is created. The user ends up with 2 content types they can manage via the SharePoint web interface–one content type named “new item” and a second content type named “existing item.” Users get the concept of the content type as a template and find it easy to manage the fields they want to display on the new vs. existing items.
When I posted my comment (above), I was actually thinking of Sarah’s excellent presentation at the Best Practices Conference in Washington this year.
Sarah (an expert) evaluates the requirement for content types and then implements them where appropriate. The information asset is now appropriately managed, and time is not wasted attempting to train a user on something they will only rarely use and don’t have time to fully understand.
Not only that, but Sarah can show hard-dollar ROI for all of her work.
Ruven
P.S. If you want to see her speak about this, she’ll be at the Best Practices conference in La Jolla (San Diego) this spring.
Thanks, Ruven! Looking forward to seeing you in La Jolla as well :)