Search vs Metadata groupings

The Issue

SharePoint, particularly in Enterprise level settings (10000+ users), can contain thousands and thousands of data items, including documents, list items, external items, content and digital media.  Finding the specific piece of information the end user requires can be challenging.  There are three things typically done to make it easier to locate the correct information.

1. Site architecture.  Specific sites or areas for specific document types, usually related to department (payroll, human resources) or activity (specific projects, team events).
2. Search.  The "search" field that appears at the top of most SharePoint pages, and list specific searches configured for large lists.
3. Metadata Groupings.  The information is organized to make rapid location easier, ie, a list is grouped by assignee, so that a specific assignee's task is more rapid to locate.

The first two types of organization tend to be well understood.  It makes sense that users would look for payroll documents on the payroll departments website, or look for project related documents on a project site.  Search itself is also well understood, as it is included on almost every large public facing website, and the use of search engines such as google has made the end user comfortable with this process.

However, metadata groupings are used less, both because they are less understood by the end user, and because they require the intelligent analysis of the information being stored to come up with a good metadata scheme.

If we are able to explain to the end user the advantages of using a metadata based organization over the other two methods, then we are able to implement this improvement in production and see the efficiency improvements in the resulting system.

This blog post looks at a classic search scenario, and provides evidence as to why, in this case, a metadata grouping is the best answer.

Searching by Date Range

For this example, we are going to be looking at a payroll system that provides the end users pay stubs.  The paystubs are released to the end users on pay day, and additional paystubs may be added in correction or if an employee has more than one position, each requiring their own paystub.

Over time, a SharePoint list that simply lists paystubs is going to become cumbersome, once the list gets beyond a certain size locating the correct historical paystub can become more difficult and involve a lot of clicks.

The classic way to solve this issue is to come up with a date range search.  Here, you have an end user enter in a start date and end date, click "search", and see the results of the search.  But is this the most efficient way?

Let's take a look from the user clicks perspective:

1. User clicks start date field calendar.
2. User clicks "previous month" multiple times within calendar to get correct month (1+).
3. User types in year.
4. User clicks end date field calendar.
5. User clicks "previous month" multiple times within calendar to get correct month (1+).
6. User types in year.
7. User clicks "Search". Results are displayed.

This is a minimum 7 click activity, more if they have to manipulate the calendar more than one month or year in either direction. 

And, if the results they were looking for are not included in the date range, then they must redo all of the clicking above in order to create another date range that hopefully does include the paystub they were looking for.  There has got to be a better way!  Fortunately, their is.

Searching by Meta Data

If, instead of simply providing raw list data organized in rows, one row for each paystub, as the example above does, we group the records by date we can enable much more rapid location of a specific or multiple records within a date range.

In this case, we can add two fields to the pay sub list, "Month" and "Year".  These are calculated fields, extracted from the pay stub date.

We can then group our records by these fields, first by year, then by month.  SharePoint will sort months alphabetically so if we wish it to be in month order, we will have to apply the fix listed in this blog post:

http://stevessharepointnuggets.blogspot.ca/2014/12/grouping-by-dates-months-in-month-order.html

This grouping results in the following output:

Now, let's take a look how many clicks it takes to locate a specific record:

1. User clicks + sign by the year they are looking for.
2. User clicks + sign by the month they are looking for.

The results are displayed.  In only two clicks the user was able to locate the same pay stub record that was located with 7+ clicks above.

And, in the case where the first two clicks did not locate the correct paystub, they are one click away from being able to view any previous or subsequent month in the same year, or two clicks away from a different year.  A vast improvement over the classic date range search approach.

Best Approach is a Hybrid

This post outlined the importance of metadata when used for grouping records, and how it can be more appropriate than a custom search in specific situations. 

If you are successfully able to combine all three ways of accessing data, through site architecture, standard and custom searches, and groupings using metadata, you will see much greater efficiency finding information within SharePoint, increasing adoption and satisfaction with the platform.