Force Left Nav To at least 200 Pixels wide
Force Body To at least 500 Pixels high
SharePoint MindsharpBlogs > Timothy Calunod > Posts

 Single Post

Nov 11
Published: November 11, 2011 16:11 PM by  Timothy Calunod



In my previous post, we had completed examining syndicating a Choices set through the Managed Metadata Service's Content Type Syndication feature, which allowed us to centrally deploy and manage our Term Set while still allowing user-input to the Choices Set. However, to complete our examination, we need to also understand exactly how this new specialized column will work in our clients, since this will be the key buy-in for a user to adopt this configuration in the first place. Thus we should also examine at least some working activity regarding the clients that will interface with our Choices set. I will divide up the clients in three types: The Primary Client (the Browser), the Secondary Client (Office Applications), and the Tertiary Client (Design Applications).

The Primary Client would be the Browser, in particular, Internet Explorer, although all appropriate browsers for your work environment should also be examined. The Secondary Client would be Office Productivity applications such as Word, PowerPoint, Excel and SharePoint Workspace, since these are often the main clients that interface with SharePoint. The Tertiary Client would be Design Applications such as InfoPath Designer and SharePoint Designer. We could also include Access as one of the Design clients as well since it borders on design and productivity.

The Primary Client

Since SharePoint is a Web-based Platform, it makes sense that the Browser would be its Primary Client. Most of the productivity happens through this client, and so methods for working with data through the Browser should be examined. We will examine Internet Explorer, although testing against other important browsers such as Firefox, Safari and Chrome may also be necessary, depending on what is used in your environment.

Basic Operations

We begin our tests using only Browser-based views, such as Datasheet view. We have already seen that standard web form editing has worked as expected, so no further need to test this. In our scenario, we will use a Managed Metadata Column called Key Group that draws from a Grouping Term Set Choice Set.

After creating a Standard view, normal Sort, Filter and Group By views worked, however with Filters there are some Operator limitations, as noted here. Also, HTML Styles, such as boxed, newsletter and preview also worked without an issue. Furthermore, Metadata Navigation also worked.

We had also found from our initial test that Edit Properties worked as well.

Bulk Operations

When we shift to Datasheet view to create items using this view, we find the column to be Read-Only, which means we cannot use Datasheet view for bulk editing. Since this is essentially Access Web Database view, Access also restrained the column to Read-Only

However, the Inline Editing mode worked fine, and this can be an adequate substitute for the bulk editing lost from Datasheet mode.

Column Relationships

Since the Browser often becomes the frontline site designer, we should also check a few areas here. First, when using Calculated Columns, we find that Managed Metadata Columns are not supported.

With the Lookup Column, we also find that it is unsupported.


The Secondary Client

Because our Browser-based testing will quickly move into the Secondary Client, we may begin evaluating these. The Secondary Client is Office Productivity Applications, such as Word, Excel, PowerPoint and SharePoint Workspace. Access can also be considered in this group, although our Datasheet view had already shown that Access Views cannot edit these columns.

Basic Operations

The primary editing application through Office Productivity Applications is centered on the Document Information Panel. Since the Managed Metadata column has already been proven to work with this display, it is not surprising to find it works fine. This was no different for Word, Excel or PowerPoint.

For Outlook, viewing and editing custom properties in SharePoint did not seem supported, as indicated here and for 2007 here, but further research did not seem to surface a solution.

For SharePoint Workspace, we find a similar lack of support, as the custom columns are not displayed or available even for viewing, much less editing.

Also, for exporting to Excel spreadsheets, we find only Read-Only capability as expected, although at least it displays the properties.

The Tertiary Client

The last level of client is the Design client such as InfoPath and SharePoint Designer. Since these two are key tools in customizing and managing our SharePoint interface, testing against their capabilities becomes important for deeper customizations.

InfoPath Designer

Customizing List Forms in InfoPath for SharePoint is supported for SharePoint 2010, which means that managing list forms can be easier and more robust. However, even though the New, Edit and Display Web parts work as expected, customizing the form inside InfoPath did not.

This warning is not merely for opening in Design, it also indicates that adding fields or seeing fields through InfoPath is also not possible. Additional issues may surface if the column is required, as noted here.

SharePoint Designer

SharePoint Designer continues to be the key design tool for SharePoint, and as the List View and List Form Web Parts through Designer seem to work as expected. Not surprising then that new List View and List Form pages (New, Edit, Display) had no issues when being created. Data View and Data Form Web Parts again had no issues in custom pages.

While working with Workflows, a workflow working against the same list or a different list seemed to complete, but failed to perform any of the configured actions. Evidently the Workflow has an issue with uniquely identifying which piece of metadata to use, and thus requires an explicit, unique identification of the term that the Workflow will evaluate. For more information on this, review this information here.


Although we managed to create a centralized, managed Choice Term Set for our users, we find that many specific client uses had a surprising amount of disconnects and lack of support. In some basic cases with the Browser, full support was there with the exception of some filter operators, some columns and some views. For Office Productivity Clients, there was enough support through the Document Information Panel, but offline capability and integration with Outlook was not supported even for viewing.. Finally, while InfoPath could not use the Managed Metadata Column, it was still functional for SharePoint Designer, except when using the column with workflows due to the specific GUID associated with the term applied.

In our exploration of this possible solution, we have found many functional pieces but we have also discovered many areas lacking support, such as in client editing and viewing, that limits our application of this solution. However, it has succeeded enough that while it cannot cover every application, it can apply to a core.

This will bring this examination series to an end until my next blog post, where we will examine a new topic and continue in our quest to Solve for Y.

Special thanks to all the valuable additional information from the SharePoint community as a whole where I indicated in links throughout this article.


Stay tuned!


No comment(s) to show

 Add Comment

* Required Field
Your Name *
Your Blog Url
Message Subject *
Message Body *