2. Columns
The
specific authoritative fields or attributes that are used to “tag” each
SharePoint item are called Columns. Columns allow you to keep metadata
about an item consistent across libraries and lists and can be defined
at the Site Collection or site level and can be inherited by “child”
sites or defined locally in a library or list. Columns have a name and
a type, such as
Single line of text
Multiple lines of text
Choice (menu to choose from: drop-down, check box, radio button)
Number
Currency
Date and Time
Lookup (information already on this site)
Yes/No (check box)
Person or group
Hyperlink or picture
Calculated (calculation based on other Columns)
External data
Managed Metadata
The Managed Metadata type is new in SharePoint 2010.
Managed Metadata allows you to share a hierarchical set of attribute
values across your entire SharePoint infrastructure.
If you are not using Managed Metadata to share
values for Columns, you should still consider creating all Columns as
Site Columns at the top site in a Site Collection. Managing Columns
centrally allows you to automatically propagate new values to any
library or list that uses that Site Column. For example, if you
maintain a list of offices centrally in a “global” (Site Collection
level) Site Column called Office and you open a new office, you only
have to update the list of offices in one place if Office is a Site
Column at the top level of your Site Collection. You can also use
Lookup Columns with reference lists supplying value choices. Of course,
you may also want to manage Office as a Managed Metadata term if it
makes sense to share these values across multiple Site Collections.
Deciding the best structure for your metadata requires knowledge of the
domain, as stated earlier, but it is also possible to evolve your
metadata architecture over time.
Effectively
planning your Content Types and Columns can make or break the
effectiveness of your SharePoint solution. It’s very frustrating to
look at solutions in organizations that have been experimenting with
SharePoint by essentially throwing the platform at users without
providing any support for metadata architecture design. What typically
happens is that users tend to use the same structures they are used
to—folders—for organizing content rather than exploring the multiple
ways of collecting and organizing content that are enabled by assigning
just a few Columns and Content Types. While SharePoint supports the
concept of folders in document libraries, folders can be a restrictive
way of organizing content because a piece of content can only “live” in
one folder. By contrast, the same document can be classified into
multiple groups using Columns. For example, Columns allow you to group
the documents in your document library by Authors (to associate a
document that was written by Sue and Scott and then find all of the
documents written or cowritten by Sue) or all of the documents for the
West region or all of the documents written by Sue for the West region.
Folders may have a new role to play in your information architecture in
SharePoint 2010, but they are not necessarily the best organizing
principle for your content .
Table 1
provides a list of metadata Column best practices to help guide you in
the choices you need to make regarding metadata Column labels and
values.
Table 1. Metadata Column Best Practices
| Best Practice | Recommendation |
|---|
| Identify universal metadata applied to all content assets. | Many
organizations require a Records Retention Code for all document (and
some other content) assets. This is the most consistently applied
“universal” metadata attribute we see in practice. Some organizations
also find it helpful to require an “owner” and a revision date
attribute for all documents. This helps identify the person responsible
for the content (who may or may not be the “author”) and determine
content freshness. |
| Limit the number of required Columns in Content Types and lists. | One
of the most important “Column-related” decisions you will make is
determining which Columns should be required. The following are
recommended guidelines for determining which and how many Columns
should be required:
If the site is primarily used to publish
information (small number of content contributors with a large number
of “readers”), make all content classification decisions based on
whether or not the end user will use the value to find or filter
results. In this scenario, don’t worry too much about whether or not
you have too many required Columns. Remember, if users can find content
more easily with better content classification, the content owner or
manager will have fewer phone calls requesting information that
distract them from their daily work. Because it’s their job to provide
information, they usually won’t mind if they have to spend additional
time entering required fields for portal documents. If
the site is a collaboration site where the objective is to get users to
change their behavior from storing reusable assets on their local or
shared drives and putting them in team sites or publishing pages on the
portal, assume that most users will have about 30 seconds of patience
available when they are saving or uploading content. That means you’ll
probably be able to have, at most, 5 required Columns. When
applicable, include default values so that the user only has to enter a
Column value if his content is different from the expected norm. This
is an example of a scenario where you may want to consider creating a
folder structure for your content. For example, if you have a large
repository of project deliverables and each document needs to have an
associated Project Name, you can create a folder for each project and
assign a default value for Project Name that is unique for each folder.
This will make it easier for users to comply with a requirement to post
their deliverables in the repository because they will not have to add
Project Name as an attribute. This may seem contradictory given that as
a general rule, we don’t like to encourage the use of folders in
document libraries. However, as you can see, there are some scenarios
where the use of folders for metadata “inheritance,” a great addition
to SharePoint 2010, will give you a “best of both worlds” capability to
find and share content.
|
| Follow the basic principles of good data design. | Make sure that
Each metadata property is unique and that each property is really necessary to describe the content. List
values represent a single category of knowledge. For example, a Column
defining “color” might include values such as red, blue, and green, but
not an entry such as plaid. Instead, define a second category for
“pattern” to present values such as stripes, polka dot, and plaid. The list of values for an attribute is complete—so that users are not forced to pick an inaccurate field. Choice values in a drop-down list are mutually exclusive. Required Columns appear “above the fold” for data entry if they do not have a default value. Default
values are entered judiciously. Many users accept default values
without reading them. This unconscious choice can skew filtering and
search results. The use of “fill-in” fields in list choices is avoided where possible.
|
| Use descriptive, meaningful labels. | Try to use terms that your users will recognize. Do not make up a label value—use the “old” term if that’s what people know. |
| Use singular nouns for Column names. | For example, use Document Type, not Document Types. |
| Use a logical order in value lists. | For
the most part, list values should be in alphabetical order to help
users quickly scan items. If you need to sequence or sort lists using
another sort order, you can insert a number in front of a text term.
For example: 1-Design, 2-Development, 3-Train, 4-Deploy. Note that you
can create a custom display order for Managed Metadata, so this
guideline applies only to site and list Columns values that are not
derived from Managed Metadata term sets. |
| Avoid using None, N/A, or Other as metadata values if possible. | If you must use these options, add them to the end of your metadata list, even if the value is out of alphabetical order. |
| Consider using a Document Description in document libraries (and encourage users to complete it). | Adding
a brief description (abstract) to documents helps users figure out if
they should open or download a document when they are scanning
documents in a list. This helps avoid the extra time required to open a
document to actually see if it’s useful. |
Out-of-the-box
document libraries in SharePoint 2010 include the following Columns
that were also included in SharePoint 2007: Title, Created By, Modified
By, and Checked Out To. In addition, document libraries now include a
new Column called Managed Keywords.
In SharePoint 2010, there are three ways an attribute can be assigned to a document:
When a content contributor or editor selects
or adds a value in a Column defined by the content designer. This is a
form of authoritative metadata—it is assigned by the content
contributor in a structured field.
When a content consumer assigns a “social tag” to a document. A social tag can be any value entered by the user. As the user starts typing a
value, SharePoint provides a list of previously used social and managed
terms (keywords), and the user can select from this list. Because any
user can add social metadata, these tags (or keywords) are not
considered authoritative, but they can be used to filter content in
search results.
When a content editor
adds a Managed Keyword. Managed Keywords are authoritative tags because
they are added by users with content editing privileges, but the source
of their values includes both the managed terms for the site as well as
the social data values used by other content contributors and
“visitors.” You can think of Managed Keywords as social tags assigned
by a content editor. (Just to make things a little more interesting, if
you choose, you can prohibit users from adding their own Managed
Keywords to items by requiring them to select from existing values.)
Like any other Column, Managed Keywords help users
find content in a library. However, unlike other Columns, the values of
Managed Keywords are more flexible and less structured, which provides
a very dynamic way to quickly react to evolving terms, opportunities,
and emerging business needs.
More than one Managed Keyword can be assigned to the
same document by default; they act like a check box attribute. However,
there are some conventions that must be used to assign Managed Keywords:
Separate values with semicolons.
Do
not use commas to separate values. Commas in a list of Managed Keywords
will automatically be replaced with semicolons, so for example, if you
enter “X, Y, and Z” as your keyword, SharePoint will replace your entry
with three separate values (and the third will be called “and Z”).
Use an ampersand (&) or spaces to separate words that should be combined as a single keyword.
