다음을 통해 공유


A graphical summary of site metadata options for SharePoint

As we know, there’s no direct options to have site metadata with SharePoint.  However, I do often get the question on how to do it, the pros/cons of using a central or local list to each site, etc.  I posted a solution framework a few months ago, available here, that allowed for simple site metadata management through a Web Part.  This is the 4th option outlined in this post.

I’ve been trying out the Balsamiq mock trial tool and ended playing around with it for a presentation on options for site metadata for SharePoint.  So here’s what the breakdown is (and you can download the whole thing in a single PNG by clicking on it).

Site Metadata Options

 

Here’s the breakdown (in my own SharePoint in pictures way!)

Option #1 : Central list

Mock look & feel of Option #1

Option1-Pros

Note that option #1 can pose a security risk by showing list information to users who do not have access to the list.

 

Option #2 : Custom list in each site

Option2-look

Option2-Pros

Note: Decent option with limited development if 2010.  More difficult with maintain content types with 2007/WSS3.

 

Option #3 : Using the Publishing features with a Page Layout

Option3-look

Option3-Pros

Note: Best option for look & feel, limited development required.  More difficult with maintain content types with 2007/WSS3.

 

Option #4 : Custom dev, Web Part with site information on home page

Option4-look

Option4-Pros

Note: Interesting option for both 2007/2010 for limited data types.  It's a simple Web Part that can be added to web pages that will show site metadata.  Model can be defined with Features or custom code.

 

So what would I choose?  Option 3’s the most visually interesting if you have SharePoint Server; Option 2’s just about the same but with list items and somewhat more awkward for editing.  Option 4’s good for both 2007/2010 environments and allows for updates through simple feature upgrades, but it’s custom and doesn’t support a lot of data types.  My personal choice would be #3 if you can, and I’d definitely stay away from option #1 almost all the time.

 

I’ll detail Option #3 in a follow-up post.

 

Maxime

Comments

  • Anonymous
    December 06, 2010
    Heh. Thanks for this. I have been trying to figure it out and funnily enough I basicly came with these options as well. Always nice to have some affirmation of your own thoughtbends. Pretty handy to have to pros and cons for each option too.

  • Anonymous
    June 27, 2011
    Hello. Another great post!  Could you possibly expand on option 3 a little bit?  I'm not familiar with publishing features so I can't quite figure out how it would work.

  • Anonymous
    June 27, 2011
    I have to take the time to write a full post on it, but in a nutshell, you need to activate the SharePoint Server Publishing Feature (site collection feature).  This allows you to have WCM pages. You then need to create a feature that brings a Content Type + Page Layout so that you can have that nicer look & feel page.  Optionally, you can use the Content Type Hub to push the changes to that content type, which would allow to add new properties, however the Page Layout wouldn't follow (there are multiple ways to do something about this, hence why I need to package a solution and post a solution when I can). After your next crawl on a site that has one of these pages, you will have your new properties as "crawled properties" in your search engine.  You can make these as managed properties and use them for your search queries. Maxime

  • Anonymous
    June 27, 2011
    Hello Maxime, thanks for the quick response. I look forward to your more detailed post, when you get a chance. In the meantime, just another point of clarification: I'm not sure about the connection between a page layout and the crawled properties. Do the fields on the page layout create META tags and those are crawled? Are there specific types of fields to use on the page layout? Thanks again.

  • Anonymous
    June 27, 2011
    Hi Mel, I'm assuming you are using SharePoint search or FAST for SharePoint of course, otherwise it would work only if the other engine understands SharePoint columns. in the case of SharePoint search or F4SP, whenever it crawls a SharePoint list, it will crawl its columns as well.  They become available in the Search Service Application as Crawled Properties (under the metadata properties menu on the left, then 2nd tab up top). All SharePoint fields will be crawled.

  • Anonymous
    November 30, 2011
    Hello, I eventually got around to implementing option 3, content type + page layout.  It works neat, but how to I get search results to link to teh site's home page? My results are linking to the publishing page that holds the site info. Thanks.

  • Anonymous
    November 30, 2011
    Hi Mel, it's actually the point, but re-reading the image, I can see what's misleading.  The idea is that doing this gives you a link to the workspace directly, not a list item that's outside of the site.  But yes, it will point to that publishing page.  You could have that publishing page as your home page (i.e.: with different display in edit versus display modes). As an alternative, it would be possible to add a control on that page to redirect to the home page if the referral is coming from search. Maxime