Ruven’s SharePoint Blog

When you search the net for SharePoint answers, how do you know if what you find is a good answer or not? Sometimes a post that’s been around a long time comes back much earlier in the results, even if newer and better approaches have been documented or discovered.

Into the fray jumps StackOverflow.com where people can vote answers up or down. This site is targeted mostly at developers, but even though it only launched recently it already has over 200 SharePoint questions many of which are not directly about programming.

Some of the nice features are how the site is very reputation driven: People who have built up more reputation have the power to do more things, like edit questions or answers; answers that become outdated can be voted down, allowing better answers to float to the top over time.

It’s still early days for this site, but it looks really promising to me.

Today, Joris Poelmans (of JOPX on SharePoint) wrote a post against the use of folders in SharePoint. Now don’t get me wrong, I too spend a good deal of my time explaining to customers why folders should be avoided in SharePoint. As Joris says: “NOOOOO …. metadata is the way to go in SharePoint”.

However, there are some cases where folders are absolutely the way to go and I want to tell you about my favourite example.

My customer has a team-site used for collaboration by the Human Resources teams in Toronto, Hong Kong, and Los Angeles. Most of the content on the site is shared among all groups, but there are some documents under the control of the VP of HR that are specific for each location. These documents should not be seen by anyone other than the targeted groups.

We already know that audience targeting is not an answer when security matters.

The solution is to create three folders, one for each location, and secure each folder so that only members of the appropriate groups can see them. This means that only members of the Hong Kong group can see the Hong Kong Folder. The VP of HR of course has access to all three folders, so that he can add/edit/delete documents from any folder.
The final step that makes this really work, and avoids an extra click for the user, is to create a default view that is a “no-folders view”. With a no folders view, all the documents are displayed in “flat” format, with no folders in the way. However, the security that you’ve applied to the folder is still in effect, so you will only see files that you have the rights to see.

When you create the view, expand the “Folders” section and select “Show all items without folders”.

The bottom line is: Never use folders in SharePoint, except where they simplify or enhance functionality.

SharePoint’s people search is a SharePoint feature that many organizations want to take advantage of. (I’ve heard stories of people sitting for weeks within 25 feet of a new co-worker, and even having e-mail conversations with them without realizing who they are.)

However, at the time that most SharePoint deployments “go live”, the users have not yet had an opportunity to fill-in their My Site data. This especially applies to the employee picture. Adding pictures is an element of My Sites and people search that adds great value.

 
(Some random staff pictures)

It’s pretty boring for your new users if the first time they do a people search, they just get a bunch of placeholders.

Steven Van de Craen stepped in with a great solution: He wrote an event handler that gets attached to a picture library.

• - The document library is loaded with headshots, each named with user id (account name) of that person (e.g. Bob Smith’s picture is named bsmith.jpg)
• - The event handler updates the profile picture URL property for that user’s profile
• - For our client, we used everyone’s security badge headshots as the default picture. As most people HATE their badge headshots, this is ample motivation for them to get into their MySite to change the picture.

Note: You can prevent your users from changing the image, but I’d recommend against this. You should educate your users with ground-rules around their pictures (no “back of the head” shots, or holding up things that obscure the face: The image must be recognizable).

The only problem with Steven’s solution is that it can be tricky to install and configure. To the rescue comes Itay Shakury who wrapped the event handler into an easy to deploy feature.

We’ve used this at a client, and it worked out really well: The day we went live, every employee had a profile picture (and a strong desire to go into their My Site and replace it!).

I can’t finish this post without sending out a thank you to my colleague, Brian Lalancette who discovered and implemented this solution.