Posted in Electronic records, Products and applications, Records management, Sharepoint 2010, SharePoint 2013, Training and education

Is your SharePoint team site a ghost town?

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.

Posted in Digital preservation, Electronic records, Legal, Products and applications, Records management, Retention and disposal, SharePoint 2013

SharePoint 2013 Site Disposal Policies

SharePoint 2013 includes the option to set a disposal date on site collections. This article describes how to configure a SharePoint 2013 site collection to include a site disposal policy.

Default settings

A site cannot be deleted (either manually or automatically) unless a Site Policy has been set up (exception – the SharePoint Administrator has permissions to do this).

Without a Site Policy, the default settings under the Site Closure and Deletion option (see below) are as follows:

  • Site Closure – ‘Close this site now’ click box default: greyed out.
  • Site Deletion – ‘This site will be deleted on:’ Default: ‘Never’.
  • Site Policy – Default: ¬†‘No Site Policy’.

Setting up a Site Policy

New site policies are created under Site SettingsSite Collection AdministrationSite Policies. Once created, the policy is applied under Site SettingsSite AdministrationSite Closure and Deletion. While you can create multiple policies, only one policy can be selected at a time under the Site Closure and Deletion option.

There are no default policies; the first time Site Policies is opened, the Site Policies section provides only one option – ‘Create’. Each policy must have a Name and may have a Description. The name and description can be the class description from a records retention schedule, using ‘after date created’ or ‘after date closed’ as the triggers (see below).

Site Closure and Deletion options

There are three options under Site Closure and Deletion:

  • Do not close or delete site automatically. The default option.
  • Delete sites automatically. This option deletes a site on a pre-defined date after it was created or closed.
  • Close and delete sites automatically. This option first closes the site and then deletes it on pre-defined dates.

In addition there is a check box ‘Site Collection Closure’ that allows the site collection to be made read only when it is closed.

Delete sites automatically

When this option is selected the following appears:

  • Set Deletion Event. The two options provided are ‘Site closed date’ and ‘Site created date’, plus n days, months, or years.
  • (Check box) ‘Send an email notification to site owners this far in advance of deletion:’ (i.e., to warn them of the pending deletion) – n days, months or years. Default setting is 3 months.
  • (Check box) ‘Send follow-up notifications every:’ (i.e., to remind site owners of the pending deletion) – n days, months, or years. Default setting is 14 days.
  • (Check box) ‘Owners can postpone imminent deletion for:’ (i.e., to postpone the proposed deletion) – n days, months or years. Default setting is 1 month.

Close and delete sites automatically

This option is identical to Delete Sites Automatically except that it also includes a date when the site can be closed – after which a deletion event date is set followed by the same three options above.

Site Closure and Deletion

As noted above, a Site Policy must exist before a site can be closed and deleted using these options. The Site Policy must be selected otherwise the default options (see above) apply.

  • If the Site Policy is based on the Delete Sites Automatically option, the option to ‘Close this site now’ becomes available. If the option ‘Site Closed Date’ was selected, the site will not be deleted (at the pre-defined time) until this option is selected. If the option ‘Site Created Date’ was selected there is no requirement to ‘manually’ close the site.
  • If the policy is based on the Close and Delete Sites Automatically¬†option, the option to ‘Close this site now’ becomes available. This allows the site to be closed earlier, otherwise the deletion date will be automatically calculated from the site policy setting and displayed next to the Site Closure and the Site Deletion options.
  • If no policy is selected, the default settings will apply; this means that the site cannot be closed.

Further reading

Overview of site policies in SharePoint 2013 (Microsoft).

Posted in Electronic records, Products and applications, Records management, Retention and disposal, Sharepoint 2010, SharePoint 2013

Managing Physical Records in SharePoint 2010

It is sometimes said by records managers that one of the drawbacks of SharePoint 2010 (and SharePoint 2013) is that it doesn’t manage physical records, or at least not very well.

This article describes how to manage physical records in SharePoint 2010/2013 using a list that includes barcodes.

Up front and out of the box, the main limitations are the ability to: (a) print labels for paper files and boxes (including labels with barcodes) (b) attach a portable scanner to scan barcodes and (c) maintain a chronological history of file movements. These limitations may not be a problem for many organisations seeking a low-cost way to manage mostly inactive files and boxes, especially if they currently use an Access database or Excel spreadsheet to do this now.

Options to address each of these limitations are discussed in this article.

Metadata options

There are almost no limitations on the type of metadata you can use to describe physical records. I would suggest having the following metadata:

  • Title (e.g., name on the file or box)
  • Record Type (drop down list – file, box, etc)
  • Reference ID (manually entered unless you use the default ‘ID’ option, possibly with a separate ‘year’ column)
  • Date created (date first registered, default system date)
  • Start date (start of date range)
  • End date (end of date range)
  • Business Owner
  • Current location (can be a custom list of pre-defined locations)
  • Date at current location
  • Record status (drop down list: active, inactive, missing, destroyed etc)
  • Internal barcode (if one exists)
  • External barcode (usually the one provided by a storage provider)
  • Records description (description of contents, usually of a box)
  • Box number
  • Box barcode (may be the same as the Internal or External Barcode)
  • Retention schedule (can be from a pre-defined list)
  • Disposal action (can be from a pre-defined list)
  • Date to be destroyed (manually entered based on retention schedule and disposal action)
  • Destroyed? (checkbox)
  • Date destroyed (manually entered date)
  • Legal hold? (checkbox)

If physical files are registered in the system, then only details of the box and disposal action would need to be entered. When the box is ready to be sent offsite, details from the offsite storage provider’s label (often provided in advance) can be entered in the external barcode and other metadata (including current location) updated.

An optional barcode can be obtained by checking ‘Barcode’ in the Information Management Policy settings for the list item. Once checked, the barcode appears when the item is displayed in view but not when it is edited or exported.

Printing labels

All list metadata (except the barcode) can be exported to an Excel spreadsheet, which can then be used to print labels. Microsoft provide details how to create and print labels for a list in Excel here:

Scanning

Using a portable (or attached) scanner to scan barcodes and update your records register, especially with a new location (or during a physical records audit) saves a great deal of time instead of entering details manually. It is possible to scan directly to an Excel spreadsheet however several steps may be required to match or validate the barcode with the details in the SharePoint list.

For example, if series of files are being scanned to a box (or location), the usual practice is to scan the box (or location) barcode first, then scan each individual file. If scanning directly to an Excel spreadsheet, you would do it the other way around – have the list of existing files in the spreadsheet, then scan the box or location barcode to the cell next to the file number. This detail can then be copied and pasted back to the SharePoint list.

Chronological movement history

The only option to maintain a chronological movement history, out of the box, would be to add versioning to the list. This means that each time the item is edited, a new version is created, keeping the previous details. The movement history will not display in a single view in the list but clicking on ‘Version History’ will show any changes made in single view. Only ‘major’ version numbers are supported in lists (i.e., 1, 2, 3, 4).