When looking at ways of structuring information, there are many different possibilities. One of the ones that typically has the least amount of structure is a wiki. And this means that I hear clients suggesting all sorts of different uses for it, some of them more practical than others. Personally, I tried a few things with the wiki when I first started working with SharePoint but came to the conclusion that the lack of structure really just made it hard to find things and that most project based upon it end on a dusty metaphorical shelf.
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:
| Column type | Choice |
| Required | No |
| Choices | Facility Housing Real estate None |
| Display choices using | Checkboxes |
| Allow fill-in choices | No |
| Default value | [blank] |
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.
