Posts Tagged ‘software’

Is your SharePoint team site a ghost town?

May 24, 2013

One of the best ‘unknown’ (to end users, anyway) features of SharePoint 2010 and SharePoint 2013 is ‘Site Web Analytics’, hidden away under Site Settings. This, out of the box, feature provides useful information such as the average number of site views per day, the average number of unique visitors per day, trends, as well as a listing by user names of the top visitors and the number of their page views. It’s a great way to see if a site is being used.

The default date range for Site Web Analytics is the past 30 days but the settings can be changed to the last day, week, month, quarter, half-year or year. Custom dates can also be set, and these reports can be exported to a spreadsheet for further analysis, including through scheduled reporting sent by email.

So, what does this have to do with the subject – is your SharePoint team site a ghost town?

Simply, Site Web Analytics tells you if your team site is being used – by your team. If it’s not used, then it’s a ghost town – and you need to understand why and consider changing or deleting it.

In many cases, the reason a SharePoint site becomes a ghost town is because users simply neither want nor know how to use it.

What makes a document management system popular?

My experience implementing and using many other document management systems (TRIM, Documentum, iManage, Alfresco) over the years, along with considerable anecdotal evidence, suggests that, unless there are legal or regulatory requirements mandating it, end users tend to baulk at using a document (and records) management system, especially if it:

  • Requires more than 20 minutes to learn. Some EDMS systems require hours of training – for end users!
  • Duplicates what they do already with network drives. More often than not it requires ‘saving’ an existing born-digital record to the recordkeeping system (AND leaving the original where it was stored).
  • Stores records of a business activity away from other, potentially rich, related records that are not documents.
  • Provides no obvious or little tangible business value for the user – it’s a ‘compliance overhead’.

A popular document management system is one that:

  • Users can start using the system with very little training. It should be intuitive and make sense at first glance. I often use the example of Facebook – no-one ever got training to use it and yet a billion people registered to use it.
  • Reduces (not necessarily eliminates) duplication of effort. Network drives can still exist to create and manage ‘working documents’ instead of final versions.
  • Can keep records in context with other related records such as calendars, lists, tasks, announcements, social networking messages, and so on.
  • Provides tangible business value for the user, with minimal effort. It’s hard to break the network drive habit but simple things like unique document IDs, versioning, hyperlinks, and the ability to email a link instead of a document help to break that habit.

What can turn a SharePoint team site into a ‘ghost town’?

Microsoft clearly put a lot of human-computer interaction (HCI) effort into the user interface design of SharePoint team sites (along with all their other products). Team sites in SharePoint 2013 are a design improvement over SharePoint 2010 but still maintain the same essential look and feel, which is:

  • Document libraries and lists on the left hand side navigation. It’s no coincidence that this is exactly where network drives and email folders are accessed from.
  • An editable main page that can be modifed as required to present additional information or options, including via webparts.
  • Default and modifiable views of documents and lists.
  • A simple search option on the top right.

Over 25 years of network drive use has conditioned users to navigating for documents from the left hand side, searching from the top right hand side, and seeing information presented in the middle of the page. Change this paradigm and you start to lose users.

I believe there are two main reasons why users don’t or stop using team sites (described further below):

  • The ‘plain vanilla’ out of the box functionality in a brand new team site.
  • Site pages that have been customised to the point where end users cannot work out how to navigate or access their information.

Out of the box generic functionality

Out of the box team sites include the two features which, if not addressed or re-configured (a 2 minute job), can negatively affect take up rates:

  • ‘Shared documents’ under ‘Libraries’. This to me is a ‘bookmark’ library that should be removed almost immediately and replaced with a library that has a name that makes sense, ideally named after a business activity. Otherwise, ‘shared’ is like ‘general’ in a network drive. If users have only one, generically-named library to choose from, they are unlikely to use it (compared to the rich tapestry of their network drives).
  • Folders. Unfortunately, while SharePoint folders look like network drive folders they don’t work the same way. They create unnecessarily long URLs and are often impossible to navigate. It’s not uncommon to hear users say they cannot find documents in a site because they cannot work out how to navigate folders (as they don’t include a + to guide navigation). My recommendation is to turn them off under Advanced Settings after the library is created. However, users inevitably want a way to categorise or group documents in a document library. Document Sets generally make sense to users and get quick take up but you can only have one level. A good site has a reasonable number of smartly-named document libraries – perhaps no more than 10, grouped as required by Headings – using Document Sets instead of folders. Another form of categorisation is using categories in the document metadata and then creating a view that groups the documents by those categories.

Customisation

Too much customisation of site pages can also turn users off. As noted above, it’s worth keeping in mind that Microsoft spent a lot of effort (and probably dollars) on designing their standard team site user interface. Some of the common modifications I have seen on ‘ghost town’ sites include:

  • Using themes that make the site look completely different from all other sites. It’s important to maintain consistency in themes.
  • Using unnecessarily large font sizes on the page.
  • Using too many images or graphics on the front page.
  • Assuming the text or content on the page is actually of interest to the target audience. I usually suggest that Site Owners (note, there should never be just one) agree among themselves; if this is not possible, test the proposed page design on a user who has never seen it.

Avoid ghost town sites – keep users coming back

Remember, most users are familiar with using network drives and folders. Use document libraries with sensible names that are obvious to users, don’t use folders, and keep the front page content simple and easy to view, and you are more likely to attract users back again and again.

Advertisements

Understanding and managing access permissions in SharePoint 2010

March 19, 2013

By default, access permissions are set at the Site Collection level and then inherited downwards, to all libraries (and document sets), lists and documents on the main page and to all subsites and their libraries (and document sets), lists, and documents.

The default permissions are usually:

  • Site Owner (full control of the site)
  • Site Members (can add and edit)
  • Site Visitors (can view only)

Breaking the inheritance model of access permissions is relatively simple to do but can create confusion and, if not done correctly, make content completely inaccessible even to the Site Owner. Breaking the inheritance model on documents is particularly dangerous as there is no easy way to identify or manage access restrictions applied across the farm.

Simple access controls via de-inheritance

The simplest way to limit access to a site or the content on a site is to de-inherit the access permissions. To change this on:

  • Sites, go to Site Actions – Site Permissions
  • Libraries/Lists, go to Library/List – Library/List Permissions
  • Document Sets or documents, click on the down arrow next to the name and click on Manage Permissions

… then choose ‘Stop Inheriting Permissions’. If that option is not there, then the Site, Library/List, Document Set or Document may already have permissions on it. (You may see the following statement: ‘Some content on this site has unique permissions which are not controlled from this page. Show me uniquely secured content’).

But there’s a catch, creating the first layer of confusion. When you stop inheriting permissions, the same permission groups remain on the page. But didn’t you just STOP inheriting those permissions?

The reason I think Microsoft left the default permission groups there is so you don’t inadvertently lock yourself out of the Site, Library/List, Document Set or Document – if no group is left and you navigate away from that page, you will almost certainly be denied access. The really good thing to note is that, if you have realised you are about to make something inaccessible (and before you navigate away), you can click on ‘Inherit Permissions’.

So, after you stop inherited permissions the next things you need to do are (a) remove any groups you no longer want to access the site, and then (b) add or create a group you want to access the site. To do that, you click on ‘Grant Permissions’. The dialogue box that appears asks you to select users or groups, and then grant the specific permissions. A group must exist to add it and these are added at the Site Collection or Site Level.

Note that a created group does not on its own have specific permissions, it is only a group of names. You create the permissions when you give that group access to the site, library/list, document set, or document. If you have a group already, you can add new names to that group.

I’d recommend you create a group at the Site Collection level because it will appear there anyway and you need to understand what impact that has – any new group you create will have access to anywhere else in the site by default UNLESS you break the inheritance model.

Slightly complex access controls via de-inheritance and groups

The most common use case for slightly complex access controls are at the library/list, document set or document levels. That is, there is a business requirement to restrict access to one of those, or provide access to a specific document set and nothing else. For the sake of this posting, we will consider the case of a library, in a second level sub-site, that contains multiple document sets, each with multiple documents. The business area wants to restrict access to one of the document sets to a specific group of people.

This is where you need to exercise great care as, without careful planning, you could inadvertently allow all the members of that group to access anything else across the entire site collection where access is inherited. This is because, when you create an access group, the group will appear across the entire site collection.

To allow access to a document set only within a site collection (and assuming there are multiple sub-sites each of which inherit from the top level), you need to first understand access permissions already set.

First, break inheritance on all sub-sites; by default this will leave the default groups plus the new one you have created, so you you only need to remove that new group on all sub-site access permissions. This will remove the new group from all libraries/lists, document sets and documents on each site.

Second, you need to add the group to the specific document set. To do that, stop inheriting the permissions, which leaves the default access permissions, then add the new group by clicking on Grant Permissions.

Now, if you go to the site permissions, you will see the new group listed (which can be a bit disconcerting), and the statement (against a yellow background): ‘Some content on this site has unique permissions which are not controlled from this page. Show me uniquely secured content’.

What this means is that members of the group you have added:

  • Cannot access the site, or site collection (they will get an ‘Access Denied’ message).
  • Can see the document set they have been given access to (but no other document set or document in the same library)
  • Can see the site’s libraries and lists but cannot see any content in those lists. This is a good reason for being careful about naming those libraries.

As noted already, access permissions can be very difficult to manage and very easy to get wrong. Careful planning will help to ensure you don’t lock yourself out.