We are supporting a client with intranet content migration. Like so many others, they are moving to SharePoint. In my limited time on the project I’ve worked with at least three other firms contracted to the project â€“ many chefs involved.
One point of disagreement among the contractors is handling of metadata and taxonomy relative to page layouts and portal structure. One firm thinks that metadata dictates layouts and templates. I and another firm disagree. We think the two are easily separated. And should be.
This is particularly true in SharePoint. SharePoint handles structure and navigation through the building of sites and pages. Taxonomy is managed in what SharePoint calls the “term store.” Metadata can be added to anything and improves search results. In SharePoint, even users can add tags that guide search.
Because SharePoint is very list driven â€“ pages, articles, links, etc., are often items in a list â€“ it’s very easy to add metadata. Think of the list as a table. Need users to filter by a product? Add a column for that with a drop down of options. Want this to be required? Make it so and the creator can’t save or publish without completing.
The crux of the argument is this: do you create page layouts or portal structure based on metadata needs? If I list all the metadata I want to be available with a news article, for example product name, keywords, industry, what would I change about my page layout based on such a list? Probably nothing. Why? Because metadata and taxonomy influence search results, not necessarily what a user needs to see on the page to facilitate navigation.
There is one place where the metadata affects page layout and that is when you deliver content based on a user characteristic, such as the location in which the user works. You need to know what content will be called for and how it will display.
But in the case of this project, the company has no immediate intention of doing this. So, page payout can be dictated by the nature of the content or task and user needs relative to that content or task.
This has been a rather simplistic explanation in the hopes it will help many who don’t want to be technical experts, but still have to work on intranets, have a valuable conversation with the technical folks.