BASPUG May 2014 - Taming Your Taxonomy in SharePoint

Editor's Notes

• #5: Good Evening… I’ve been coming to BASPUG for quite a few years now, so it’s nice to be presenting to you tonight and I hope we’ll get into some good conversation. We’ve got about 60 minutes or so… We’re going to do some quick getting-to-know each other, then I’m going to give you a bit of an orientation. We’ll get into the nuts and bolts, attempt a live mini-design exercise using some of what we learned, and finish up hopefully with some extra time for Q&A SOUND GOOD?
• #7: VERY BRIEFLY about me…
• #8: Currently I’m with a really great company here in Boston—you may have heard about them 30 seconds ago… I’m about a year into this role; I’ve had about four years of consulting under my belt and previously I’ve been in a corporate role as well Been working with SharePoint for coming up on nine years now I’m not a developer! Major focus is on wrestling with all the ‘m’ acronyms… DM, ECM, WCM, KM… Here’s how to ping me But enough about me…
• #9: Let’s find out a little about all y’all.
• #10: Just so I get an idea who I’m talking to… Do we have any Developers? Administrators? Business people/end users? What made you come tonight? What do you wanna know?
• #12: You may have heard SharePoint does this thing called CM—whatever flavor it may be
• #13: Why are we talking about this? SharePoint tells us that it can handle a LOT of different things—many more not up here on the screen. Well… Do you want to turn all this stuff on and hope for the best?
• #14: The goal is to create Pleasantville.
• #15: But you’re going to end up in the Wild West if you don’t think carefully about some of the stuff we’re going to talk about tonight.
• #16: To start off, we’re going to get into these 2 things, find out what they are, and how they relate to each other. Hint: The answer is already up there.
• #17: We have this term out there, CONTENT ARCHITECTURE. What is that? It’s about Content Management Here, we’re looking at two parts to the whole 1. A specification. What’s that? It’s an outcome 2. Activities and outputs. We’re talking about a process
• #18: It’s part of a process which is going to help you achieve your content strategy and will form the foundation for content management But let’s get to the ‘big’ word for today…
• #20: We’re here to talk about taxonomy… What is this thing called TAXONOMY? Simply… OK so we’re going to be categorizing our stuff. Cool.
• #21: Even more simply…
• #22: In talking about these big concepts—content architecture and taxonomy--What are the common threads here? What does taxonomy as part of content architecture look like? It’s structuring And organizing How are we going to get there? We’re grouping things To be able to classify and categorize Why do we work with taxonomy? Again, findability And usability CONTENT
• #23: It’s also about your USERS. It’s about half and half. Some people like to follow a map and street signs along the way to get to where they want to go. Others like to search for their content and expect it to come up pretty high in the result set. What kind of person are you? Think about your email. If you’re a filer and have tons of nested folders that you put your emails into, you’re probably an green ‘navigation’ person. If you’ve got all your emails in your Inbox and anytime you want to find something you type in a keyword or you group and sort by sender, you’re probably a purple ‘search’ person. You have to consider both approaches in building out your taxonomy.
• #24: Once you’ve located some content… We want some qualitative data about the content to differentiate it from the sea of other documents
• #25: The goals, again, are helping users FIND their stuff and USE it effectively.
• #26: To recap… Taxonomy is part of the bigger picture; shouldn’t be examined in a vacuum. Other parts of your content architecture will include policies, workflows, etc.
• #27: Remember that content architecture is the foundation for CM Taxonomy is the map; the plan; the blueprint in SharePoint My major point here is: You must plan ahead if you want to get all the way there
• #28: This stuff is not black and white or one-size-fits-all. I cannot tell you today an exact process to follow that will work for everyone in every case for all content. And if you approach your users or whoever you’re working with on this stuff with the same solution every time, you’re doing it wrong.
• #29: At the same time, working through this stuff should consist of two complimentary objectives. We saw this in the definition for Content Architecture… You’re going to embark on the process because you have a desired outcome. But, your outcome is going to be influenced by undertaking that process.
• #30: So everyone’s on the same page… Going through the process Helps people ideate Can remedy bad things that didn’t work out in the past Therapy session Gets users to feel a sense of ownership; they’re going to help build it—not just be delivered something they didn’t have a part in shaping At the end of your process You should end up with documentation You should also have some things that aren’t written out in sentences, like spreadsheets and charts that help illustrate the plan All this stuff applies way beyond SharePoint But… we’re at a SharePoint User Group meeting, so we’re going to stick to SharePoint.
• #31: I just met with a client today that is looking at this exact problem. They’ve gotten their hands on SharePoint online, Office 365, they’ve played around with it a little, and they have a user community that has been starved for attention for years. They want to let them in and provide some value as soon as possible, in a largely self-service paradigm. We had a lot of conversation today around drawing up a plan for the foundation before they start building the house. You get ahold of SharePoint. You’re about to send out the email telling everyone the day has come and all their problems will be solved. STOP. As easy as it looks, as tempting as it may be… Don’t do it.
• #32: If you don’t go through this process and plan ahead and communicate across all of the participants, stakeholders, sponsors, etc…
• #33: I’m going to be throwing a lot of information at you. Please, not for my own sake… go read this white paper. Planning Documenting Inheritance
• #34: OK here we go!
• #35: We have ALL these things to build with in SharePoint, and more… How do we do it right?
• #36: Let’s start off with the basics. We’re going to review what content types and site columns are We’re going to put them together to be able to track metadata on our content
• #37: We’ve going to have our content types and site columns. Together we’re able to associate metadata appropriately with our content. We’re going to have our sites, libraries, and lists (a.k.a. our containers in SharePoint) That’s going to get us context, the logical architecture, for our content. Deciding where to use all of our tools is what will bring our taxonomy to life.
• #38: 60 minutes is not a lot of time. We’re going to pretend…
• #40: SharePoint has two main constructs that we’re going to focus on at the outset: content types and site columns. This is Microsoft’s definition right off of TechNet of a content type in SharePoint Big word here: REUSABLE Pay attention to the words in purple; these are reasons/qualifiers for why you would consider using a content type and for creating different content types And notice our key term here about categories of items A content type is not just a tag
• #41: Out-of-the-Box Content Types They’ve always been there behind the scenes; you may not have realized you’ve been using them the whole time since SharePoint 2007 Some things to notice here… There is a parent-child relationship model here These things aren’t just one-offs All things derive from Item (ultimately System) Some are super special SharePointy things
• #42: Let’s take a look at the common OOTB ones that you interact with all the time. Notice the parent-child relationship. A picture is a further developed kind of document A document set is actually a kind of folder (I simplified some of the relationships here.)
• #43: Two major branches—item-based and document-based Where an item is basically a row in a list SharePoint content is all stored in lists. Libraries are lists. They’re just designed to store document-based content types. Document-based content types are designed with the primary element being a file. An item can have a file attached to it. Item Contact Event Document Self-explanatory Folder A thing that holds documents Document Set A super special ‘binder’ but it’s a folder on steroids
• #44: Show the default content types Show enabling content types in library; show Document content type
• #46: Content Types have a scope in a site structure within a site collection. Content Types are only visible downward.
• #47: Let’s take a sample site structure and a few example content types. I could just define these in the topmost site… But, instead…
• #48: Content Types inherit properties from parents This is why you might want to consider what I call an abstraction layer Transactional vs. Abstraction
• #49: Let’s use this sample list of content types again
• #50: This is perfectly valid. But it doesn’t follow our directive to plan ahead. This is going to get unwieldy when the list grows to more than a half-dozen content types. You’ll want to introduce a level of abstraction.
• #51: Here I’ve grouped the documents that have to do with human resources under a parent content type of ‘HR Document’ This is your abstraction layer. I’m never going to USE this content type transactionally, meaning I won’t enable it in a library and assign this content type to a file. Thinking ahead, I may want to put even more abstractions in place.
• #52: What does this get me? The Ad is just one content type; why abstract it already? You can’t insert a level in later on.
• #53: In fact I always insert one ultimate abstraction point just below Document so I have that place to influence all my custom content types without modifying the out of the box
• #54: Keep in mind the reasons I might want to instantiate another content type. For example, I may want to isolate a workflow. Let’s say I have this snippet of my content type hierarchy. Obviously this inherits downward from document or form… These are all transactional content types; I will be using these for real documents or forms. This is certainly a valid model. What you want to be careful of when inheriting a transactional content type directly from another transactional content type are any deviations downward that you may have to account for. For example, I could set up a workflow for all shipping requests here. That will apply downward to all 6 other content types But let’s say I have a different approval process for expedited shipments. I could set up a workflow on only that content type. BUT, do I want BOTH of those to run? No. So I have to remove the other one. OK… BUT what happens when I update the shipping approval workflow settings and I need to propagate those downward to the 5 other content types that need it? Let’s say I have yet another workflow I need to perform on things that are shipped internationally; I need to get some sort of authorization to export out of the country. OK… I can set up a workflow here, and another workflow here. Do I have to remove the other workflow? Maybe not because both actually need to run; they’re separate processes. BUT (depending on how I set this up as reusable workflows/list/library workflows…) these may end up being two copies of the same workflow. Not the best way to manage that because I have to make changes twice. What could be a better way of setting up these content types?
• #55: I’ve added several abstraction layers here. I can now define all three of my workflows in only one place, and all the content types that require them will have them and the ones that don’t won’t. I’ve even thought ahead and split up the standard and non-standard request types because perhaps in the future I can foresee a separate workflow being needed for those. Now this may not be ideally appropriate for OTHER settings like metadata. I’ve now lost my inheritance between the 2 air freight content types and the inheritance between the 2 ocean freight content types. You need to figure out what’s best for the business problems that you’re trying to solve and balance that with the setup and maintenance
• #56: Changes that you make at a certain level could be overridden List/Library content type is linked but is just an instance/copy; they’re not one in the same This could work to your advantage or your demise Workflows
• #57: This is sometimes a good way to not have duplicate copies of the same document if it is needed in different places.
• #59: OK; next we’ve got site columns Again, we’ve got TechNet to tell us the medical explanation Again, notice the word REUSABLE
• #60: OK; next we’ve got site columns Again, we’ve got TechNet to tell us the medical explanation Again, notice the word REUSABLE
• #61: There are types of columns in SharePoint; they each have their own unique characteristics and field controls—the way the column is rendered in a newitem or edititem .aspx form
• #62: So, like content types, site columns have a scope—downward The same rules apply
• #63: Like content types, there are instances/copies of site columns in libraries/lists UNLIKE content types, you can instantiate a column in a library/list, but that’s not a site column and only has relevance to that container only Required
• #64: One of the decisions you often have to make is when to employ one of these types for giving users a selection of things to pick from
• #65: Choice Easy text Never updated
• #66: Lookup Can’t use across site collections Has a scope If you need to store additional metadata ABOUT the choices Can help you with things called projected fields Not all columns will project
• #67: Scope applies to lookup columns as well and can be used to your advantage.
• #68: Managed Metadata Got this in SharePoint 2010 Only way OOTB to use a consistent set of terms across site collections—even web applications and farms What’s altered this decision a bit is SharePoint 2013’s managed metadata extended properties.
• #69: Show sample MM hierarchy
• #70: You want to track data that will actually be of value. Just because you can set up a column for your document approver’s shoe size doesn’t mean it’s relevant. You can have too many columns and it will be laborious for users to adopt the practice of providing that data to the system. If your data has a low likelihood of ever being populated, perhaps because it’s not required, it can lead to bad data and the items that did have the field filled in become less valuable because it wasn’t done consistently. This is a balancing act.
• #71: SharePoint’s going to refer to your column differently depending on how you’re referencing/accessing it Programmatically UI Central Admin - Search
• #72: Show column properties
• #74: What is METADATA? Simply… You’re already using it and may not realize it.
• #75: Outlook
• #77: iTunes
• #79: From your Camera…
• #80: In SharePoint… At the very least: Created Created By Modified Modified By And an item always has Title A document also has a name, which is the filename
• #81: We ASSOCIATE the site columns WITH the content types to get metadata
• #82: How do we decide where to set up the columns in our hierarchy?
• #83: For example… The same goes for other settings on these content types, by the way. Remember that we can isolate workflows, for example. We could set a retention policy. The same consideration applies to these.
• #84: I want to discuss how the components and concepts we’ve talked about so far progress and feed into your taxonomy. We’ve got our content types and site columns. Together we’re able to associate metadata appropriately with our content. Nothing happens with these until we instantiate these in particular containers within SharePoint. Deciding where to do this with what building blocks is what brings your taxonomy to life.
• #85: Why do we care about all of this stuff? Content Types, Site Columns, Metadata Our content types and our site columns are building blocks that can be used/instantiated in different places to effect different results and support our goals of finding content and making it usable within SharePoint
• #86: SharePoint gives us several layers to work with from the farm all the way down to individual items. It’s important to understand what can be configured where and the scope of those decisions. Line of demarcation On-Premise vs. the cloud
• #87: So in understanding your taxonomy and how it’s going to work and support your business processes, manage your content, comply with your security requirements… you need to understand the holistic view of how all of these things will work together in SharePoint.
• #88: To make it very basic…
• #89: Work your way up the layers Again, there’s that line of demarcation.
• #90: OOTB we’re given several very different site templates.
• #91: OOTB we’re give several different library templates.
• #92: OOTB we’re given several different list templates. These will all accelerate you getting started.
• #93: A few words about Content Type Publishing and the Content Type Hub… This allows you to trump that line of demarcation we just saw, with your content types, and have consistent definitions and settings across site collections, web applications, and even farms.
• #95: It is incredibly important to consider and plan out the organization of the content that you’re going to manage. SharePoint has certain constructs built-in to set you up properly for being able to employ many of its features.
• #100: I want you to understand not only what taxonomy is but that it’s part of a bigger idea.
• #101: I want you to understand the tactics for working with your taxonomy.
• #102: I want you to understand the goals for working with your taxonomy.
• #103: I want you to think about this stuff BEFORE you let your first user into your site.
• #104: Governance can be a whole week’s worth of other sessions and discussion. I encourage you to do a lot of research or call us for help ;-)
• #105: If you do…