The Myth about SharePoint Browser Support

Microsoft posted a blog entry today that pointed readers to SharePoint’s browser support page on TechNet.  In this post, they detail what browsers SharePoint supports and any specific support limitations.  However, I want to raise an important point that seems to be missing from the conversation: browser support isn’t entirely about SharePoint.

Unfortunately, what most everyone fails to mention is that browser support is actually a combination of what Microsoft supplies and the solution that you’ve built.  In other words, Microsoft’s support, or lack thereof, for specific browsers is limited to Microsoft-supplied interfaces.  Depending on the type of solution you’ve developed, much more of your solution’s browser capability could be dependent on your development than on Microsoft’s.

Here’s a quote from TechNet:

“For publishing sites, the Web Content Management features built into SharePoint Server 2010 provide a deep level of control over the markup and styling of the reader experience. Page designers can use these features to help ensure that the pages they design are compatible with additional browsers, including Internet Explorer 6, for viewing content. However, page designers are responsible for creating pages that are compatible with the browsers that they want to support.”

Obviously, this quote relates specifically to publishing sites; primarily those internet-facing sites that are primarily content serving sites as opposed to more collaborative/intranet/extranet kind of sites.  However, even in the case of sites built with other site definitions (like Team Sites), browser support can and will be affected by new master pages, custom web parts or other components supplied by you or 3rd parties.

The myth here is that SharePoint’s support for specific browsers is somehow exclusively Microsoft’s domain.  In fact, true browser compatibility is a combination of Microsoft supplied interfaces (that are used in your solution) and those solution-specific interfaces that you or a vendor create.

The [Tools are] too much with Us

As 2012 starts in earnest, I am reminded of the poem from which the title of this post has been taken “The World is too much with Us” by William Wordsworth.   In this poem, Wordsworth laments how out of tune with nature people had become during the first industrial revolution.  In much the same way, I see too much focus being placed on tools in the era of SharePoint.  Business users and Information Technology folks seem to be so enamored by the tools and technology, they forget that the focus should be on needs and solutions.  This is especially true when discussing SharePoint and, as I said many times, SharePoint is not the answer.  

Instead, SharePoint, like any technology, needs only to be included insofar as it provides the basis for creating a solution to a specific problem (or problems).  For example, if you needed to manage documents, SharePoint could provide you with a Document Library for storing the files.  Further, you could leverage Content Types and Information Management Policies to enable more precise management of a document’s lifecycle (if that were a need).  However, your specific use of these features should and must be governed by the solution – the overall set of features, functions and the specific solution implementation  in the context of your needs and goals.

When considering how to proceed with your SharePoint project, consider this one piece of advice: start with the problem or challenge first.  Ignore SharePoint and don’t speak of it again, unless you’re discussing how some feature in SharePoint can support a solution.  Even then, try focusing on the solution (give it a name if you have to) and not the tools or features involved.

Migrating your Content to SharePoint

Many clients want to take advantage of the on-premise or cloud-based power of SharePoint. However, many struggle with creating the ideal process to migrate their content. Questions like what steps are involved and how can you ensure success can be a challenge to answer without proper guidance. To assist our clients in making good decisions and to help ensure migration success, we’ve created a formalized migration process. 

If you’re interested in better understanding how to manage a content migration, read our Migrating your Content to SharePoint white paper or simply give us a ring.

Managing SharePoint SandBox (User) Solutions

In SharePoint 2010, Microsoft has provided new functionality called “Sandbox” or “User Solutions” that allow administrators and Site Collection owners to upload new functionality scoped to a single site collection. This means that site collection owners can host bespoke code or 3rd party add-ons that are useful to them without affecting others on the same farm. This functionality is incredibly useful in situations where organizations have shared SharePoint farms that serve the needs of various groups. It’s also very useful if organizations are looking to leverage services like SharePoint Online or Microsoft Business Productivity Online (both services offer a SaaS-based version of SharePoint), but have historically been prevented from including custom code.

In the May issue of SearchWinIT’s SharePoint E-Zine, I discuss the management controls and shortcomings of this new feature.