The cliented wanted a list of frequently asked questions, which they could easily filter per category. Without using a custom solution, the best answer in MOSS 2007 would have been to create a page for each category, then place a CQWP to filter the applicable questions. This solution isn’t particularly satisfactory, as it is difficult to maintain.  The final solution was to use a managed metadata field to filter the query string, thanks to the new and improved CQWP in SharePoint 2010.

Step 0: Term store?

If you’re not too sure about taxonomies, please see my post on Understanding managed metadata. That will give you a brief introduction into what a taxonomy and tagging are.

One of the great things about SharePoint 2010 is the ability to work with a taxonomy – a central set of hierarchal terms which are reusable over multiple site collections. This structure is saved in the term store.  For more information on actually working with the term store and determining your taxonomy, please see Chris O’Brien’s Managed Metadata in SharePoint 2010.

Note that you can reach the term store via Central Administration or as an option on the site settings page of each site in your site collection.

Step 1: Fill the term store

We need to save the list of FAQ Categories somewhere. My current rule of thumb is that whenever there is a site column that I would normally use a choice or lookup for, I now use the term store and make it a managed metadata column. So I made a new term set with a few terms:

You can place something like this wherever it works within your own taxonomy.

Step 2: Creating the content type

In  my site collection, I created a content type which inherits from the content type “Article Page”. I used the Article Page content type because I want each of my questions to be its own page – you could do this within a list meant for something completely different if you want to.

In this case, the site columns in Article Page map nicely to most of the site columns that I will need:

Question -> Title
Answer -> Page Content

Finally, I created a new site column of the type “Managed Metadata”,  called FAQ Category. In the column settings, I linked it to the FAQ Category section of the term store.

Step 3: Create the page layout

This is an optional step, but it’s necessary for the things that I want to show later on in this post. So I made a simple page page which shows the title and page contents site columns, linked to my FAQ content type, with the FAQ Category column in the hidden metadata section. I implemented two columns, one is used for the already mentioned columns, the other will be used later.

Remember that to work with SharePoint 2010, you need SharePoint Designer 2010. It is not backwards compatible with SharePoint 2007, nor can you use SharePoint Designer 2007 with SharePoint 2010. You can download it for free from the Microsoft site.

Step 4: Add some content

I created a few questions just to have something to play with in the rest of this post. You might want to do so as well, considering it’ll make it a lot easier to test what you’ve done.

Don’t forget to add the content type to your page library and all that jazz.

Step 5: Showing related questions

Here is where that extra column on the page layout comes in: we’re going to show the related questions so that visitors can click straight through to more interesting information.

On the page layout, add a CQWP.  The easiest way to configure it is to right-click it and then choose “Tag properties…” from the context menu that appears. Configure it as follows:

Show items from the following list

I’ve specifically chosen the page library that my FAQ pages are in. This doesn’t matter that much, it depends on your situation.

Choose content type

Specifically choose the content type you’re using – in my case, FAQ. This ensures that pages which use other content types (such as default.aspx) won’t turn up in the query.

Additional filters

SharePoint 2010 introduces two new filters in the CQWP which are very useful.  Note that there is a question mark next to the title – this has a good summary which always helps me out when I can’t quite remember the syntax.

PageFieldValue – allows you to use the current value of a field on the current page.
PageQueryString – allows you to grab the value of a query string in the URL.

We’ll be using PageFieldValue to get the value of FAQ Category for the current page. Using that, we can filter out other pages in the page library which have the same category.  The correct form is [PageFieldValue: FAQ Category].

When you view your page layout, it’s perfectly normal that the CQWP only shows dummy content. It will be visible when you check your pages via a browser – you can see the pages that have the same FAQ Category.

You can edit the CQWP further, for example to limit the number of results returned, change the sort order, etc.

Step 6: FAQ overview page

We need a good way to show the available questions, so the last step will be creating a page as an overview. I’m just going to use a blank webpart page for this one, though you can make it as pretty as you wish with a page layout.

Summary link webpart

The first necessary webpart is the Summary Links Webpart. I’m going to put this in the right column. For each FAQ Category, I will make a link. That link will point to the current page, with a query string which is linked to the category.

The “cat” is the query string variable. For each link, we’re saying “put the variable called ‘cat’ with the value ‘FAQ Category’” into the URL. This will be picked up on the page that the link goes to.

It is very important that the category that you put into the query string is exactly the same as the name of your category in the FAQ category managed metadata field.

Make a link in the webpart for each of your categories – each link needs to point to the current page.

CQWP

The next step is to place a CQWP in the left column. This will be picking up the correct FAQ pages for us.

The values for this CQWP are pretty much the same as for the CQWP when showing related information. Instead of filtering with the PageFieldValue, we’ll be filtering with the PageQueryString, to grab that variable out of the URL:

When you save/check the page in, the CQWP will be empty. Click on one of the links in your links webpart to see items from that category.

When you link to the page, make sure to include the query string with the category that you want to show by default, e.g. /default.aspx?cat=General info.

Conclusions

Managed metadata with the CQWP are powerful combination in SharePoint 2010. The examples shown in this blog post could not have been done this easily in SharePoint 2007, perhaps only with custom code.

Personally, I’m looking forward to having many more opportunities to use this functionality in the future!

I did the following:

1. Place a content query webpart on the page layout.
2. Configure the content query webpart as normal
3. Set up the filtering:

Note that it is possible to filter using the value of a field on the current page and/or using a query string variable (e.g. default.aspx?value=y).

Note: this only appears to work for managed metadata fields – when I tried it on normal single line of text fields, this extra option didn’t appear. And when I tried telling it to use [PageFieldValue: fieldname] as a filter value, the CQWP couldn’t be rendered.

A few weeks ago, a client came to me with a request. She wanted to use a wiki to educate colleagues from other units on what her unit actually does. She also immediately told me how she wanted it to work, which was great. Even better was that it worked in SharePoint in a way I had never thought of.

The case

The unit, Sustainable Solutions, has a number of topics that it wants to inform other members of staff about. Each topic would be placed on its own wiki page.

The client wanted there two be two ways to navigate to the topics: you could either choose a subject and get a list of topics per subject, or you could to go a page and see all of the topics ordered by alphabet.

It turns out that each topic could belong to one or more of three different subjects – though they might want to add more subjects later. The subjects were:
- Facility
- Housing
- Real estate

Part 1: modify the wiki library

The very first thing that needed to be done was make it possible to add a subject to a wiki page.

We did this by going into the library that stores the wiki pages and adding a new column, subject. Note that this is not a site column, as it was not necessary for this project.

The column was configured as follows:

One of the nice things about the wiki site is that any new columns will automatically show at the bottom of each wiki page. You will also be able to edit the contents of that column when you edit the page, meaning that it is very easy for users to apply.

Now is a good time to set your start page in the wiki to have “none” as a subject.

Part 2: view all articles

Ok, each wiki page now has a value for the column “subject”. But what does that do for us? It means that we can now make “table of contents” pages, according to the client’s wishes.

A wiki page has two edit buttons. There is one in the wiki toolbar, next to history and incoming links. This is the most obvious one. However, if you click on the Site Actions button, you also have an edit button. When you choose that edit button, you will see a webpart zone at the bottom of the page.

To create a page that shows all articles in alphabetical order, we did the following:
1. Create a new wiki page and set the subject to “none”.
2. Edit the wiki page via Site Actions.
3. Place a webpart based on the wiki library (one of the first ones in the list) in the webpart zone at the bottom of the page.
4. Edit the view of the webpart so that all articles where the subject is not “none” are shown, sorted in alphabetical order.
5. Set the chrome type of the webpart to “none”.

The webpart shows all of the pages which have a subject that is not “none”. It’s 100% dynamic – add or change a page and it will show up here.

Part 3: view articles by subject

To create the different overview pages for each subject, we did very similar actions to the alphabetical overview site, except with slightly different filtering options. Instead of filtering for all pages except those with a subject “none”, we filtered by each subject.

The nice thing about working with the checkboxes and allowing multiple choices is that we could have topic pages turn up on multiple overview pages.

Again, this is completely dynamic. The only time the client would need to change something is if a new subject is added. In that case, they would have to add a new option to the choice column, create a new subject overview page and then place and configure the webpart.

Notes

It took me longer to write this article than it took to implement the solution the client wanted. It wasn’t complicated or difficult at all.

In hindsight, I am impressed with the application of the wiki functionality. The client has an environment is very easy for her to update and maintain. Furthermore, it has a structure and navigation that we are all pleased with: something I didn’t think was possible within a SharePoint wiki.

Credit for the tip about implementing a column in a SharePoint wiki site goes to Supercharge your SharePoint wiki.

Taxonomy

In SharePoint 2010, Microsoft has started talking about taxonomy a lot. Taxonomy is defined by Wikipedia as:

Taxonomy is the practice and science of classification.

…

In addition, the word is also used as a count noun: a taxonomy, or taxonomic scheme, is a particular classification (“the taxonomy of …”), arranged in a hierarchical structure.

[ Source ]

It has its roots in subjects such as classification of living creatures such as plants, animals, etc.

The information architecture of a site consists of thing such as the navigational elements, site structure and taxonomy. Within SharePoint, you can also think of things like content types and site columns. The point of taxonomy in a website? Classifying a piece of information, such as an image or a page or even a paragraph of text into a certain category.

Metadata

A picture may be worth a thousand words – but not to a computer. To give an image context and make it possible for search machines to properly add it to their search indexes, metadata must be added. This is done in the form of having meta data fields available, such as a title, a description, the date the image was taken, etc. An image library in SharePoint 2007 and SharePoint 2010 works along similar lines.

Tagging in a folksonomy

In a previous paragraph, I mentioned that taxonomy is classification of information and is part of the information architecture of a site.

One of the best examples of tagging has been implemented by the picture management site, Flickr. When you upload an image, you are given the option of filling in metadata fields such as the title and description of the image. Flickr also allows for “tagging” of images: adding key words that you think are relevant to an image. This allows you to decide which terms make sense for that image, without having to add them to your title or description. This also makes it easier for searches later, as the search machine knows what the most important words are.

Flickr is a “folksonomy” because users can fill in any term they like as a tag. There is no hierarchy, no structure and really – no rules. The definition of the data is created by the people. This works well in a very unstructured environment such as Flickr.

Tagging with managed metadata

SharePoint 2010 now allows for tagging. In theory, you could allow users to create their own taxonomy by allowing any tag they want to use. However, SharePoint 2010 allows for managed metadata – create a centrally defined hierarchy of terms from which users can choose when tagging information.

An example for defining the location of where an image was taken could be defined something like: Continent < Country < City. When adding the metadata, it would be easy to see which terms are available. A user searching for images could then filter the images by continent, country or city.

Technet lists the following benefits of using managed metadata, which can be contrasted with Flickr’s unstructured metadata:

A little bit more explanation about the static versus dynamic properties: in SharePoint 2010, if you change the metadata definitions, the changes are applied to all of the items that are tagged with that tag. Furthermore, if you combine two tags to form a new one, these changes are applied to all items – plus when you try to choose the old tag, SharePoint will automatically supply you with the new tag.

Conclusions

Admittedly, there’s a lot more to tell about metadata in SharePoint 2010, but I need to save things for other articles.

Managed metadata adds a lot of functionality to SharePoint 2010. I am very much looking forwarding to adding taxonomy to new projects and seeing how it works in the real world.

For more information, I can strongly recommend An Introduction to SharePoint Managed Metadata and SharePoint Taxonomy Hierarchy.

XML
Extensible Markup Language
Purpose: Structured way of saving information
Sharepoint example: a list/library

XSL
Extensible Stylesheet Language
Purpose: Stylesheets for XML
SharePoint example: ItemStyle.xsl, with styles for the CQWP

XSLT
Extensible Stylesheet Language Transformations
Purpose: Translates XML to something understandable for people
SharePoint example: transformations done to variables within ItemStyle.xsl (e.g. date)

And of course…

XLS
File format for MS-Excel.
Purpose: structured way of editing data graphically
SharePoint example: erm…. edit in data sheet?

I think that the W3Schools article on XSL Languages explains it well, too.

The first thought is to just use an ASP include, which is server side and really the neatest solution. W3C Schools offers a very nice explanation on how to do this. However, when I tried to apply it, Sharepoint refused to show anything but an error screen, saying that I wasn’t allowed to use this include.

At first, I’d used a file with the HTML extension. I tried switching this to .txt and to .aspx, but the error stayed the same.

I tried using both the file and virtual include, as explained in the W3C article, but that didn’t help either.

The only potential solution I could come up with was putting the information in a Javascript file and then calling it via a script, but that gave two problems of its own:

1. The client would have to wade through the Javascript markup just to edit the HTML – way overdone.
2. The Javascript include doesn’t work too well with search engines like Google, which is a problem for a major external site like this one.

Finally I just decided to stick with the current solution. It looks like includes on master pages aren’t really possible.

One of our clients wanted to show their news items in the following manner:

[Article title]
[Publishtype], [Publishdate]

[Article title] is the name of the news article, really just the page title. The [publishtype] is a choice field to assign each article a category and the [publishdate] is an extra date/time field to show when the actual article being referred to was published, as this isn’t always the same as the date the news article.

Creating the setup for the client was no problem. They were already using a publishing site, this was just a question of setting up a new content type based off of article page and adding the new site columns. The interesting bit is changing the content query so that it showed the articles in the way the client wanted on the front page of their site.

As usual, I used Heather Solomon’s excellent article on Customising the Content Query Web Part and Custom Item Styles to remind me of how to make the new site columns accessible to the CQWP and how to do the basic editing of the ItemStyles.xsl.

On a side note: I was able to call the [Publishdate] column with simply the “date” and not “datetime” type, e.g.

<property name="CommonViewFields" type="string">Publishtype, Choice;Publishdate, Date</property>

So, within the actual output block of the XSL template, you get something that looks approximately like this (apologies for the lack of tabs):

<div id=”linkitem”>
<xsl:call-template name=”OuterTemplate.CallPresenceStatusIconTemplate”/>
<div>
<a href=”{$SafeLinkUrl}” target=”{$LinkTarget}” title=”{@LinkToolTip}”>
<xsl:value-of select=”$DisplayTitle”/>
</a>
</div>
<div>
<xsl:value-of select=”@Publishtype” />,
<xsl:value-of select=”@Publishdate” />
</div>
</div>

There’s just one major problem with this. The title and publishtype look just fine. However, the date is output in the standard XSLT format. So instead of being pretty, 1 December 2009 looks like this:

2009-12-01 00:00:00

I couldn’t show the client that!

So, with some help from an example explaining Calendar Rollup from Today Forward with Custom Styles, I figured out how to change the date format. And this is where the interesting part of this article starts.

Step 1: add the ddwrt namespace

The ItemStyle.xsl needs to understand how to change the date for you. So you need to give it the right name space. Add the following line to the top of your ItemStyle.xsl, somewhere between the currently named namespaces:

xmlns:ddwrt=”http://schemas.microsoft.com/WebParts/v2/DataView/runtime”

Step 2: transform the date

SharePoint delivers the variable @Publishdate. This variable holds the date, in standard XSL format. What we need to do is make it look different, by using an XSL transform.

Add the following block of code just inside your XSL template block:

<xsl:variable name=”Publishdate”>
<xsl:value-of select=”ddwrt:FormatDateTime(string(@Publishdate),1033,
‘d MMMM, yyyy’)” />
</xsl:variable>

What we’re doing is creating a new XSL variable called $Publishdate; the $ shows up when we call it later. We fill the new XSL variable with the value of @Publishdate (remember, the original SharePoint variable), which we tweak a little bit. It’s a number of steps all in one go.

The bit about 1033 is the localisation. 1033 is English. 1043 is Dutch. And I found out by accident that 1034 is Spanish… This makes sure that, for example, the month is printed in the correct language for the user that visits the page. Need more localisations?

Finally, we decide how the date is formatted in the ‘d MMMM, yyyy’ bit. Basically the current date is shown as a digit – the 1st of December is shown as 1 and not 01. MMMM means the entire month and yyyy means the entire year, so 2009. The comma just puts a comma between the month and the year. For more information on formatting the date, see the XSL Transformations @ W3C on Formatting Dates and Times; you will scroll down a little bit.

Right, we have $Publishdate. What now?

Step 3: show the new Publishdate variable

In the block of HTML within your XSL template, I originally used:

<xsl:value-of select=”@Publishdate” />

You just change that to:

<xsl:value-of select=”$Publishdate” />

Yes, I really just changed the @ to a $ – by doing that we call the variable that was changed instead of the original SharePoint variable.

Summary

So, a quick overview of how that was done, after all that explanation:

1. Make sure your extra site columns are included in your CQWP

2. Add the namespace to ItemStyle.xsl
3. Add the transformation to the XSL block in ItemStyle.xsl
4. Call the new variable with a $ instead an @

There is, however, a third option. On most Sharepoint lists, you can set the item-level permissions. These are special permissions found under the list settings and advanced, allowing for users to only be able to read their own items or only edit their own items. These settings are applicable to all items within the list – and you don’t have to do it by hand!

Item-level permissions are incredibly useful. Think of, for example, a guest book. A user has to have rights to create an item and potentially to edit their own item… but you certainly don’t want them editing other peoples’ items. The item-level permissions are great for this.

However. And this is a big however. The possibility for item-level permissions is always available in the object model of the library – which means it’s always there. However, as explained on PointBridge Blogs, Microsoft has chosen to hide the UI option for document libraries and issues lists. Nobody seems to know why it is, but the fact is: you cannot set item-level permissions on document libraries or issue lists from the UI.

The author of the blog has written a tool that can be run on the actual server to change the permissions via a command line script. I didn’t actually test it, though there appear to be good

There’s a second however, too. These permissions are cool and useful. But. They are not true permissions. It’s more of a pseudo view which simply changes things for certain users. You can get around it by using Explorer view, for example. Let me reiterate that: even if a user has no rights to read other peoples’ documents via item-level permissions, if they open the list in Explorer view, they will be able to read all documents that they have normal rights (read: list level rights) to. This is something that you definitely want to keep in mind.

It’s interesting and useful functionality. Just keep in mind that it’s not all smooth sailing with item-level permissions.

As you know, OneNote is built hierarchically: Notebook > Section Group > Section > Page > Subpage. The nice thing about this is that you can set up your own structure, whatever works for you. So I tend to have a work notebook, in which I stick everything about work. Each client project gets its own notebook, with different sections like communication, design, functionality – whatever I happen to be responsible for within that project.

One day, I wasn’t happen with how I’d organised a set of sections. It just didn’t make sense. So I grabbed all the pages from one section and stuck them into another section. That worked. The only thing was that I suddenly had all the pages that had originally been in the section, then all the pages that I’d just added. So instead of being neatly sorted by the date I’d created them, it was a mess.

As a solution, I looked at OneNote Power Toys. They’re exactly what they sound like, add-ons for OneNote. There aren’t a whole lot that I found useful, but I stumbled across the Table of Contents Power Toy:

Nani Courten of the OneNote Testing Team has created a Table Of Contents PowerToy.

It creates a new Table Of Contents page for the section with hyperlinks to all the pages. It also shows the creation date, last modified date, and sorts them by last modified at the top.

Just to give you an idea of where the button ends up, as I didn’t actually realize at first:

So, for my incredibly messy and chaotic section, I was able to create a Table of Contents page with one click of the button, getting an overview of all of my pages in that section.

You can see exactly what it did via the screenshot, creating a table consisting of all pages sorted by last modified.

I have found no way to change this power toy so that it sorts by creation date instead of modification date. Even so, I find it a useful addition to OneNote.

Do you use any power toys?

The really great thing about Office 2007 is that it has a number of tools which can help with this enormously. Think about things like tagging, search folders, etc. Enter PIFEM, an email system set up by Microsoft Australia employees to manage their email and time in a more efficient way.

From Ian Palangio’s Business Productivity Blog:

PIFEM uses the out of the box Outlook 2007 features of flagging and categories to manage emails that you don’t want to action/complete immediately. Once you date/time flag an item it is no longer clogging up your brain with secondary thoughts. If you manage it well… you can eliminate a lot of distractions from email, and focus on your highest priority items with laser focus.

For those who are curious as to what it is based on, PIFEM uses Outlook functionality in combination with Getting Things Done and the 4 D’s of email management.

Ian has put together a OneNote notebook explaining how to configure Outlook to pull the whole system together. You can grab it from his post, here.

I’ve been using it for about a year now, though I’ve modified things here and there. I wouldn’t know how to work without it anymore.