SharePoint 2013 and WCXM

A lot has been written about and presented on SharePoint regarding it’s use as a WCM/WCXM tool.  My position, generally, is that unless you’re using SharePoint across the enterprise, it probably won’t be a good fit for the majority of firms as a WCM solution.   I reiterated this guidance in a SharePoint 2013 WCXM advisory paper and subsequent “Just how good is Web CMS in SharePoint 2013” web cast for the Real Story Group.

After I tweeted that little had changed between 2010 and 2013 WCM capabilities, Waldek Mastykarz suggested that I “didn’t get the memo.”  Waldek and I had a short twitter discussion on whether the latest release significantly improved SharePoint’s WCM capabilities.

Admittedly, there was some merit to his response, though I still maintain that for the majority of cases, SharePoint’s WCM capabilities are not significantly changed and the platform isn’t any better a fit for loads of WCXM scenarios than 2010.  However, I thought it would be interesting to post a set of questions I asked Waldek directly and let you hear what he has to say.   At Waldek’s suggestion, I’ve also included some additional commentary that he and I exchanged through e-mail.

1. In a blog post I published on the Real Story Group blog, I contend that not a whole lot has changed for WCM in the new SharePoint 2013.  You tweeted that I “hadn’t read the memo.”  Have I missed something really materially different?
   
   In SharePoint 2007 and 2010 the publishing model was based on Publishing Pages. One of the consequences was tight coupling between the physical location of the page and how it would appear in the site’s structure and in URLs. Additionally it was challenging in previous versions of SharePoint to reuse content across different sites. Finally it was maintenance-intensive to have an intelligent website which content and presentation would adapt to who the visitor is and which device he uses to browse the website. All of those can be now solved using the standard capabilities of SharePoint 2013.
   
   Next to the new search-based publishing SharePoint 2013 contains a number of capabilities that help you optimize your website for public search engines. In previous versions of SharePoint those capabilities had to be covered by third party solutions. Those are just two of the many WCM capabilities that SharePoint 2013 offers and that change how we think about and build websites on the SharePoint platform.
   
   [SHAWN’S NOTE] The search-based publishing features are not available in the Office365 version of SharePoint and only available on-premise.
   
   
2. You contend that search driven navigation is a major change in the WCM capabilities in SharePoint 2013.  How so?
   
   In previous versions of SharePoint the navigation was based on the physical structure of the website. If you wanted to publish a press release, you would navigate to that particular branch of your site and create a new press release page. With SharePoint 2013 search-based publishing and Managed Navigation this is no longer necessary. First of all we can leverage Managed Metadata and taxonomies to build more flexible navigation structures. Secondly using search-based publishing we can tie those taxonomies to the content and have everything published dynamically on the website. This not only increases web content management flexibility but also lowers the effort required to build and maintain websites.
   
   [SHAWN’S NOTE] SharePoint’s managed metadata service was available in 2010, though basing web site navigation on the term store is new to 2013; in 2010 metadata-based navigation was available for document libraries and presenting documents ordered by terms applied to those list items.
   
   
3. What are some of the other changes in SharePoint 2013, with regard to WCM, you think deserve highlighting?
   
   SharePoint 2013 contains many new and improved features for building public-facing websites. First of all it provides us with Search Engine Optimization features that we can leverage to optimize the website for public search engines. Next there are the Rich Text Editor improvements that make it easier for content managers to work with content. One of the common challenges in previous versions of SharePoint was working with content from Microsoft Word where all of the internal markup would be copied into the web page. In SharePoint 2013 this is no longer an issue as it automatically cleans the HTML of any Word markup. With regard to search-based publishing we can now leverage information about the visitor, such as information from social networks or his click-behavior, to personalize the content displayed on the website. With this we can build truly intelligent websites where the presented content is automatically tuned based on who the visitor is and what he did on the website.
   
   SharePoint 2013 also simplifies building websites optimized for mobile devices. Using the new Device Channels and Image Renditions capabilities we can now easier build websites optimized for different audiences using SharePoint 2013.
   
   Also, when it comes to scalability, because SharePoint 2013 uses enterprise-class search engine (previously known as FAST) as a fundamental piece of the content delivery mechanics, it is much more scalable than traditional database-driven approaches – especially if you take into account content personalization capabilities such as Recommendations and User Segments that are now a part of the standard functionality of SharePoint 2013.
   
   Another thing worth mentioning is that using the new and improved REST APIs it is so much easier to reuse content from SharePoint 2013 outside of SharePoint. With the new API you can very easily create native apps for Windows Phone, iPhone or any other device/OS that will interact with the content store in SharePoint. With the new APIs you not only get access to the static content but can also benefit of the powerful capabilities based on search-based-publishing such as recommendations and user segments which allow you to easily build apps with rich and dynamic experiences.
   Even though SharePoint 2013 has been released just recently, there are already some customers having their production websites live built using SharePoint 2013. One of the cases is available at http://technet.microsoft.com/en-us/library/jj822912.aspx and presents the implementation of the mavention.nl website which was the first website worldwide live on SharePoint 2013.
   
   [SHAWN’S NOTE] Search engine optimization features include improve URL readability (e.g. no longer necessary to have the “pages” library name in the URL in all cases) and the ability to inject arbitrary metadata into a page through SharePoint site settings.  I had noted editor improvements (specifically improvements in markup produced), though SharePoint still lags other editors like TinyMCE.  Device Channels and Image Renditions are improvements,  the capabilities represented by these two features were available 2010 (automated thumbnailing was a feature of an image library and the mobile capabilities of 2013 simply make configuring device channel easier, though there’s little improvement over 2010 and you’re still required to build an entirely new site to support specific mobile devices).  Finally, the FAST engine was available in 2010 and the capabilities represented, beyond search-based publishing, are little improved (if at all) in 2013.
   
   

   [Waldek’s Response] Image Renditions are more than the thumbnail capability available in the previous versions of SharePoint. In the past SharePoint automatically generated thumbnails for images. Those were however fixed and always sized (as opposite to cropped). With SharePoint 2013 you can specify yourself which kind of Image Renditions you want to use on your website and how every single image should look like for a particular rendition. This makes Image Renditions way more useful than the thumbnails from the past.
   
   [Shawn’s Response] I did point out that Image Renditions were updates to thumbnailing.  I understand that there are some additional capabilities with redition; as a developer, it does open up some possibilities that weren’t available OOTB in 2010.  However, I question, as the average IT buyer, how much value the feature adds over thumbnailing in the context of WCM.  For me, it’s not hugely consequential across the range of sites potentially “powered by” SharePoint (i.e. for product-oriented sites, image renditions could be very valuable; for the average marketing site, not as much – or at all).

   [Waldek’s Response] Device Channels in SharePoint 2013 are nothing like the mobile capabilities of SharePoint 2010. In the previous versions of SharePoint, whenever it detected you were browsing from a mobile device (detection was done based on User Agent-substrings and properties from the .browser files on the server) it always served you with a predefined experience that was challenging to customize. The only customization capability here was to use Control Adapters (custom code) to modify the rendering of various pieces of the website. In SharePoint 2013, with the introduction of Device Channels, this whole situation has changed. Not only we can distinct between multiple channels, but we can also use different Master Pages and content panels to optimize how the website is rendered on mobile devices. I also don’t agree with you when you say you need a whole separate website for mobile. In my opinion, when optimizing content for mobile you have three options: you can use responsive web design, build a mobile website or build a mobile app. With SharePoint 2013 you can make use of all those options (or a combination) but neither of them is a must.
   
   [Shawn’s Response] Again, my point was that mobile channels are an update and not a radical departure from 2010 capabilities.  I would argue that the variations feature, combined with the agent detection provided roughly the same capabilities as the 2010 mobile channels functionality (including control over master page and layouts).  Is it the same, no.  Are device channels easier to manage and control, perhaps.  However, for whom are these features relevant? I would argue they’re mostly for developers, not business users or even “power users.”  In the same way, I’m evaluating value to the end buyer.  This functionality will be useful to only a narrow range of customers and site within the context of WCM tool buyers.   Lastly, mobile channels are not available in all versions of SharePoint, most notably in Office365.

4. Would you say that improvements in WCM are evolutionary or revolutionary?
   
   Some of the new WCM capabilities provided with SharePoint 2013, such as SEO-related features or Rich Text Editor improvements, evolved with the product. As SharePoint matures more capabilities are added and the existing capabilities are being improved. On the other hand there are also some capabilities like search-based publishing that are new and that offer us new ways of thinking about how we manage and publish web content. Using search in SharePoint 2013 we can now build more dynamic websites where the content is displayed not only based on relationships known to content managers but also based on information that we have about the visitors ensuring that they see the most relevant content that the website has to offer.
   
   
5. Given SharePoint’s fairly heavy infrastructure requirements (e.g. disk space, RAM, number of servers to run the various services), do you believe that SharePoint can effectively compete with other, more pure-play WCM tools (e.g. SiteCore)?
   
   The exact hardware requirements depend on what you are exactly trying to achieve so even when you see some high numbers, it doesn’t mean that this is exactly what you need just be able to publish a website on SharePoint 2013. The only way to really determine what you need is to get a clear understanding of your requirements, test your website against them and make an educated choice about what kind of infrastructure you need to fulfill those requirements. Given the changes in how SharePoint 2013 is licensed for public-facing websites as well as what the rich Web Content Management capabilities it offers, SharePoint 2013 is a very interesting candidate to consider for choosing a web platform – even for organizations that don’t have SharePoint implemented yet. Compared to the past, licensing of SharePoint 2013 is very attractive now. Not only the price per server is lower but you also get best-in-class search capabilities as a part of that license.
   
   [SHAWN’S NOTE]  I’m not sure I agree that pricing is improved over 2010 and certainly the “it depends” answer on hardware is an appropriate response (I use that answer frequently).  However, “best in class” search is something you, as the buyer, should evaluate in the context of other available search technologies.  The Real Story Group has very deep research on Enterprise Search Technologies that will help you understand your choices and the trade offs.
   

I want to thank Waldek for participating in the discussion and hope that it has helped you, the buyer.

About Waldek

Waldek is Microsoft SharePoint Server MVP and works as SharePoint consultant at Mavention. Waldek participates frequently as a speaker and expert in community events such as SharePoint conference in London, SharePoint Connections, SharePoint Saturday and DIWUG. Recently Waldek became a Virtual Technology Solutions Professional for Microsoft Netherlands. In this role he answers customer questions around SharePoint Web Content Management (WCM).  Blog: http://blog.mastykarz.nl  Twitter: http://twitter.com/waldekm

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.

Multilingual SharePoint Sites–Part 2

Some months back, I wrote a post about the basics of multilingual sites in SharePoint.  The post was a good primer for anyone that needs to understand SharePoint-centric concepts regarding multilingual web sites.  Unfortunately, the post didn’t really describe important details outside of the SharePoint sphere.  In particular, the post excluded all the ASP.NET-centric details.  In this post, I want to share at least some of those additional details.

Globalization

One of the early design goals that Microsoft had for SharePoint was that ASP.NET developers would be comfortable creating SharePoint-based solutions.  The theory is that if you’re a competent ASP.NET developer, you can simply pick up the additional SharePoint API universe; SharePoint is a good .NET citizen, so this idea shouldn’t be a stretch. 

Whether or not you believe a good ASP.NET developer could easily pick up SharePoint, SharePoint does borrow very heavily from many .NET facilities.  With regard to multilingual sites, this includes the Globalization namespace. 

The Globalization namespace is a group of classes that are responsible for allowing ASP.NET applications to understand the numerous languages and cultures that applications can target.  It includes everything from calendar differences and languages to date/time formats and string comparisons (and a whole lot more).  It also, importantly, provides a facility to allow developers to create a resource pool of commonly referred to assets (e.g. element labels, images).  These assets are all referenced using standard labels, creating an index of asset variants for each culture.  At runtime, based on the culture of the current user (usually indicated by a browser setting), the .NET framework will dynamically select the appropriate asset/resource based on a generic label describing that asset or resource. 

Resources and Resource Files (RESX)

Resources or multilingual assets are defined in a Resource File (RESX). There’s a resource file for each culture represented in the application. All resource files use the same labels to describe the asset, but with a culture-specific value.  For example, the text shown next to the text box where a user would enter their user ID to authenticate with the application would be an example of a reference resource. 

Figure 1 – Resource example for Login Page

In the RESX file, which is just XML, you’ll find the following entry

Figure 2 – Login_UserID label in the EN-US resource file

To add, edit or delete values, Visual Studio provides a “designer” view of the file.  In the designer, you have the ability to quickly and easily define the various labels and the corresponding values.  Figure 3 shows the Visual Studio interface for editing a RESX file.

Figure 3 – Visual Studio designer interface for RESX file

For every culture your application needs to support, you create a specific RESX file.  Each file would be named for the culture it supports and every file would contain the same labels, with values corresponding to the specific culture.  The example presented here, the RESX file is for the culture EN-US (US English). For more information on resource files, naming conventions and details on creating the files, take a look at this MSDN article on resource files. 

In SharePoint terms, the RESX would correspond to a specific variation of the same culture.  In effect, you will have at least one RESX file per variation.  These files define elements of the user interface that end users do not supply.  Whereas content on any given page is created and managed by content contributors, there are also elements, like the label for the User ID field on the login page, that are “baked” into the code of the application.  RESX files provide a mechanism to define what that label will say in the context of a specific variation or culture selection (usually set by the browser displaying the page).

Information Architecture and Visual Design

Beyond the somewhat mechanical processes for inserting culture specific content into a page, a more critical aspect of multilingual sites is Information Architecture (IA).  The IA defines the navigation paths (global navigation and its relationship to other sections and pages within the site) and the overall interface layout.  This means the decisions about where various interface elements are placed, what nomenclature is used and what sort of content is shown are all made through and by the IA (both the person – Architect – and their output – Architecture).

When developing a multilingual web site, consider that the interface will be at least slightly and potentially radically different based on the language being displayed.  The simplest example is word length.  If we compare an interface in German and one in English, it’s very likely that there will be different space needs for labels in the navigation, as well as content.  As a result, the IA must anticipate interface movement and allow for enough white space to accommodate an interface that will grow and shrink based on the language’s need.  This too is a challenge for constructing HTML and JavaScript, since both components of the web page may need to “react” to language differences.  However, beyond this relatively easy challenge, presenting content is matter of having the appropriate language-specific content.

A more complicated scenario is one involving differences in how a language is read.  For Hebrew or Arabic (as two examples), the languages are read right to left.  As a result, the whole orientation of the interface needs to shift.  The main navigation will need to start from the right, global navigation elements will be positioned in the upper left and text will flow from right to left within the content sections.  As such, you may require a unique master page and page layouts for these languages to sufficient accommodate the display differences.  The same is true for languages that are read vertically instead of horizontally as in Manchu.

Continuing with the above example, you also have the challenge of fonts.  Languages that utilize radically different character sets will require the IA and the designer to consider both font face and size choices. For example, for any font size choice in the cascading style sheet, will the text be readable across all languages represented by the site.  Most European languages have characters with relatively little detail compared with Asian languages.  Font sizes that are too small or font faces that carry too much embellishment may make detailed characters muddled or simply unreadable.  As such, these choices represent both a visual design and information architecture challenge, since font size differences will also present spacing issues to resolve.

Bringing it all together

With all of the details provided in the two posts of this series, here’s a quick review of the important parts:

• When developing your Information Architecture for a multilingual site, include the various cultures included.  Each culture, in SharePoint terms, will be a “variation.”  A culture, remember, is a combination of a language and a country, represented like EN-UK (English – United Kingdom) or PT-PT (Portuguese – Portugal).  This culture approach makes it easy to distinguish between two countries that share a broad language (e.g. Spanish), but differ in usage (e.g. Spain vs. Mexico).
• Developing an IA for a multilingual sites involves many more decisions and test cases to resolve than a single language site.  It’s important to explore the implications for your specific IA based on the languages that need to be supported and, when the visual design is complete, any challenges a specific design might pose based on the supported languages.
• Within SharePoint, decide what variation will act as a the “primary” or source variation.  This is the variation that will syndicate content to all other variations.  For example, if the source variation is German (from Germany), your content will start in German; once a page is approved, it will be copied to the other language variations in your site collection (e.g. EN-UK, PT-PT).  From there, each non-source variation will be responsible for translating, approving and publishing a language specific version of the German content.
• You will have at least one RESX file per variation.  If you have lots of different cultures, you will have as many RESX files and they must all contain the same labels.  Because labels are not evaluated during compile-time in Visual Studio, you’ll only discover missing (or conflicted) labels in a resource file at run time.  This is not, obviously, a good user experience.  As a result, you should thoroughly test and control the modification of RESX files.  Take a look at this blog series from Carel Lotz regarding one approach to effective RESX management: http://fromthedevtrenches.blogspot.com/2011/04/managing-net-resx-duplication-part-1.html
• Think carefully about the taxonomy (aka organization) of variations and labels.  As much as the IA process should define navigation, the overall taxonomy will drive label names and how labels are used in the application.  For the project example in this post, we used labels tied to interfaces (interface name prepended on label name).  This is one approach.  However, this approach neglects opportunities to leverage labels across interfaces.  Conversely, label use across interfaces can make maintenance more challenging as label changes will necessarily have different impacts across the application.  Here, experimentation and testing are key.
• A SharePoint multilingual site is really a combination of SharePoint variations and .NET globalization.  You must necessarily implement both; end users will leverage the variations component and your developers will have to provide matching RESX files for application-specific labels and static text.

As you may have surmised, there are a lot of details to consider when developing a multilingual web application.  SharePoint does provide decent facilities to enable basic multilingual sites and the .NET framework provides loads of flexibility in implementation.   Just be sure to consider the whole picture – it’s a combination of SharePoint centric constructs (aka variations), good information architecture/design and the technical “infrastructure” to make the whole solution work for end users.

Article: SharePoint 2010 and the Mobile Experience

Have you wanted to explore the mobile capabilities of SharePoint 2010?  I’ve just published an article on CMSWire that provides an overview of what you get “in the box” and your opportunities to extend the native functionality.

You can read “SharePoint 2010 and the Mobile Experience” on CMSWire’s web site.

SharePoint 2010 is not the Answer

The title of this post may be a bit surprising.  If you’re a regular reader, you know that Consejo firmly endorses SharePoint 2010 as an excellent platform upon which to build your intranet or extranet (internet sites are a different story).  However, we’ve worked with a few clients recently who seem very focused on the upgrade as a solution to their woes (mostly intranet woes).

Certainly, with every situation there’s always context.  I try not to preach to my clients (maybe a little) about why upgrading for its own sake is a bad idea.  Some may have very valid reasons for pursuing an upgrade.  Even when they don’t, many clients upgrade anyway.  However, to be clear, upgrading to the next version of anything is a bad idea if the only reason to upgrade isn’t directly attributable to platform capabilities.  SharePoint is no different.

Don’t get me wrong, SharePoint 2010 is a very robust product.  It has lots of advantages over 2007 and, if you’re a 2003 shop or an enterprise just getting started with SharePoint, I think you’ll be happy with 2010 (assuming the right implementation of course).  Further, 2010 is architecturally it is quite different from 2007 and far better at handling a more diverse set of infrastructure configurations.  It also has loads of goodies for the pedestrian user as well.  Be careful though: with all of this added capability and architectural robustness, there’s a price. 

In many ways, SharePoint 2010 is orders of magnitude more complicated to implement and not well suited for every environment (a 2007 failing as well).  There are new concepts like service applications, managed accounts, document labels, document IDs, content type hubs, external lists and a myriad of other very new and not so easily understood features.  Then there’s the idea that SharePoint can be all things to all people (e.g. a terrific web content management tool at the same time as it enables flawless document collaboration); it’s just not true.   SharePoint is good at a lot of things, but it’s not great or even capable at many more.

That said, clients, especially those in IT departments, seemed to be very taken with this new version.  Often they extol the virtues of managed metadata, better search, high count thresholds for document libraries, remote blob storage (eyes glaze on their business clients at this point) and better manageability (along with the other good stuff).  They heartedly recommend the upgrade to their business user clients and/or they simply say “if you don’t like your current intranet, blame SharePoint 2007; upgrading to 2010 will fix all of your problems and make you much happier.”  Inside of many clients, IT “owns” the intranet and issues an edict that they’re upgrading to 2010.  Worst yet, business users occasionally know that SharePoint powers their intranet and may have come to the potentially erroneous conclusion that SharePoint is the cause of their information management pain; this add further pressure to upgrade.

Honestly though, haven’t we all heard this before?  Wasn’t one of the arguments for SharePoint 2003 or 2007 that “the platform will fix all of your problems?”  Didn’t they (the ones pushing the upgrade) once tell you that SharePoint has loads of features you can use straight out of the box?  Even if part or all of the story was true, didn’t the move and/or upgrade cause you pain?  Don’t you and/or your colleagues, in some ways, have more complexity in your environment, more to manage and, potentially, more dissatisfaction with the intranet?  I suspect that at least some of you will answer “YES!!!” 

As yourself why.  Go ahead…. ask.

I suspect the answer is partially due to infatuation – SharePoint seemed (and seems) really fabulous (especially when that nice Technical Specialist from Microsoft showed you the Contoso Intranet or you attended an Strategy Briefing at a Microsoft Technology Center).  It’s also likely that you had a pretty broken intranet or a severe file-sharing problem.  Or could it have been that your organization had no previous mechanism for allowing various global business groups to share and collaboratively develop content together (save perhaps through very silly and uncontrolled file shares).  SharePoint seemed like it could work.  It seemed like “it” was simply the answer.

In practice, you now realize how much you didn’t know.  This is true for most things.  Martin White, of Intranet Focus, once quipped that “SharePoint demonstrated that most organizations didn’t know they had an information management problem because they never managed information before SharePoint.”  Once SharePoint was running, information management may have seemed even more out of control and users, in some ways, were even more dissatisfied.  This brings me back to my original point.  SharePoint 2010 is very likely not the answer to your intranet woes UNLESS you have very specific business requirements that can’t be immediately met with SharePoint 2007 (and potentially some combination of 3rd party tools); the new version is different, but it is still largely targeted at solving the same kinds of problems.

I’m not suggesting you shouldn’t upgrade.  In fact, if you can demonstrate that 2010 will actually solve your challenges in a way that 2007 and ISV products can’t, I would encourage you to upgrade.  We have a few clients that fall into this category and they’ve taken a very prescriptive approach to the effort.  Unfortunately, for most enterprises, this isn’t the case.

Here a few unjustified reasons I’ve heard for the upgrade and how I would (and have) respond:

• SharePoint 2010 has a better search engine and our search stinks
  I hear this a lot.  This is also the same argument, phrased differently, where search is generally the solution to findability.  Search is not the exclusive solution to findability and upgrading to 2010 (or, even better, 2010 and FAST) won’t help.    In many cases, organizations haven’t done the bare minimum to fix search with the tool they have.  This would include adding metadata (as basic as descriptive titles), creating a proper taxonomy, removed erroneous results from the index, created scopes, leverage pre-canned searches, gotten rid of outdated/irrelevant content or even provided search education to their end users (yes you need a little guidance to use search properly just like any tool).  Improve search first, upgrade later.
• SharePoint’s interface is hard to use; SharePoint 2010’s is better
  It’s true that Microsoft has radically changed the user experience for SharePoint 2010.  My colleague, Tony Byrne at Real Story Group, though questions whether the changes in SharePoint’s interfaces are really all for the better.  Even veteran users of SharePoint find the new ribbon challenging, much like the ribbon in Office.  Further, AJAX has made some interface more modern (and somewhat more reactive), much of what makes SharePoint, well SharePoint, is still very apparent.  You’ll also notice that there are still some exclusively IE features (though more compatible with Firefox and Safari), there are loads of forms for uploading things, the interface is still decidedly “SharePointy” and while you can create a theme in PowerPoint 2010, I’m not sure I would.  Good interface design should be handled by a professional designer and a good developer.  Also, end users are still going to need training (still).  You could/can create compelling interfaces in SharePoint 2007 and the approach isn’t much different in 2010.
• We don’t want to be too far behind Microsoft’s development cycle
  I get it.  You don’t want to be stuck on the equivalent of Windows XP ten years after it first shipped.  This is a valid concern.  However, SharePoint 2010 shipped less than a year ago.  Lots of organizations are still successfully using Office 2003 or 2007, as well as Windows XP.  To be fair, it’s far more difficult to upgrade 10,000 client workstations than a few servers and I don’t think there are very many people outside of Redmond that would defend Windows Vista.  However, the “old technology” argument only gets you so far.  SharePoint 2007 is very much still technologically current relative to Office deployments (though perhaps not too “Web 2.0”).  It fully supports the more recent versions of .NET and you can absolutely find vendors who support the platform with add-on products.  If this were February or August 2012, the argument works far better.  I’d also like to bring up my previous point about search.  Like search, few organizations really spent time or money on customized user experiences for their intranet or fully developed a true application on SharePoint.  They expected business users to simply use what Microsoft provided (more of the “build it and they will come” mentality).  In some cases this worked.  Mostly, collaborative sites experienced uncontrolled growth (causing much of the information management pain) and the larger intranet application languished unloved and underutilized.  This argument is a fallacy from the beginning and shouldn’t be considered a truly valid reason, unless perhaps you’re using IBM Displaywrite 4 (you could probably benefit from the upgrade to WordPerfect 5.1).
• We’ve already paid for the upgrade through our Enterprise Agreement with Microsoft
  This too sounds pretty reasonable on the face of it.  Your EA provides you with the ability to upgrade to the latest version of any included product; why not upgrade?  The reality is that unless you’re not going to renew your agreement during the next cycle, you’ll continue to pay regardless of what version you’re using.    It’s not going to cost you any more or less to stay put on SharePoint 2007 for a while longer (especially if you need to “fix” some of the more serious problems with your intranet).  In the end this argument is just a red herring to distract from the core issue at hand: your intranet doesn’t work for your employees.
• We have too many 3rd party tools for our SharePoint 2007 implementation; SharePoint 2010 provides [insert vendor here]’s functionality out of the box
  Really? I’d double check.  What appears, in some cases, like Microsoft may have covered a previously missing feature, they may not have completely covered it.  For example, metadata.  Microsoft implemented a new managed metadata service that goes a long way to helping enterprises implement a proper metadata scheme within their intranet.  The existence of the service would seem to eliminate the need for tools from companies like SchemaLogic, Smartlogic and more utility-like components from firms like Bamboo Solutions and Layer2.  However, these and other vendors not only appear to have a solid business for SharePoint 2010, they’ve found new opportunities.  If anything, the explosion in add-on products compatible with SharePoint 2010 would anecdotally suggest that SharePoint 2010 continues to have functional gaps.  In truth, there’s probably a better story for ISVs, not because SharePoint has gotten worse, but the platform improvements give these ISVs a far better foundation for valuable add-ons.  Do your homework and don’t get sucked in by good marketing.

Look, I’m on your side.  I love new stuff – especially that new DVD/download smell.  However, distracting everyone from the real problems plaguing your intranet by upgrading to SharePoint 2010 isn’t going to be productive.  An upgrade will likely not fix the real concerns people have about your intranet, nor will the upgrade process be satisfying.  In fact, upgrades usually tend to be migrations; painful, painful migrations.  You aren’t just replacing binaries on the existing servers and manipulating the content database schema.  “Upgrade” usually involves building brand new servers, buying more storage (get it while the gettin’s good), installing a net-new SharePoint farm, licensing brand new add-ons (yes there are still plenty of “opportunities”), licensing/using a migration tool (please don’t try it manually) to move content to the new farm and sending the IT team to training on the new stuff (developers as well as administrators).   Again, when all is said and done, core problems are probably still not addressed, nor have users significantly altered the behavior that lead to this “bad” place; there was simply too much to do getting the “upgrade” done.

In the end: fix what you have.  Get it right now, before you upgrade.  Prove it with real measures of success, then upgrade.  You’ll be happier.

Creating a Multilingual Sites in SharePoint 2010

As we start 2011 and reflect on 2010, one of the major initiatives for many clients was creating globalized, multilingual sites.   The message was especially clear when we spoke to attendees at events like the Enterprise 2.0 conference, KMWorld and J. Boye.  In particular, I was surprised at the number of attendees  planning or that have implemented “localized” or multilingual SharePoint applications.  Unfortunately, as I learned directly, the information available from Microsoft on all multilingual scenarios is uneven.
To their credit, Microsoft has done a relatively good job of making multilingual interfaces within SharePoint available.  Microsoft has released 40 language packs for SharePoint.  These language packs allow organizations to create sites and site collections in any of the languages supported by the language packs.    If your work involves intranet or extranet scenarios (externally facing collaborative sites for trust non-employees), the language packs will serve you well.  If you want a French or Arabic collaboration site, just create a new site and stipulate the language.  Individual users are free to contribute list items in the site’s language and see localized SharePoint interfaces.

NOTE: Tony Byrne, Founder of the Real Story Group, pointed out recently that one of the advantages of using software from larger software companies like Microsoft, Oracle and IBM is that there will be far broader and better tested multilingual support.  Many smaller vendors either don’t provide multilingual support at all or provide a far smaller set of supported languages.  Both issues could be particularly problematic for SharePoint deployments as many rely on 3rd party add-ons from smaller vendors.  You should do your homework on potential solutions to ensure they support the languages you will deploy.

Where documentation for multilingual sites falls short is in the internet scenarios – specifically creating multilingual “publishing” sites (think about the typical corporate web site).  There is some limited content in blogs, technet and MSDN.  However, this content either discusses language packs and variations abstractly or, in the case of most blog content, applies to SharePoint 2007.  All of it falls short of the quick reference needed by many organizations deploying publishing SharePoint sites. 
In an effort to provide some small assistance to other folks implementing multilingual sites, here is a quick reference list of sorts that provide details on some of the basic setup.
Variations
Publishing sites (SharePoint sites created using the “Publishing” or “Publishing with Workflow” site definitions) use a concept called “Variations” to enable the presentation of site content in multiple languages.  This concept has little to do with language packs and more to do with a basic copy process.  When you setup a multilingual publishing site in SharePoint, you designate a root site, a “source variation” site and other “variation language” sites.  As you create content in the source language site, a SharePoint timer job copies content (e.g. pages) and site structures (e.g. sub sites) from the source variation site to each of the other variation sites. 
The root site is merely the default URL for your web site; when web users navigate to the root URL, they are automatically redirected to the variation site that matches their browsers language setting.  As a developer, you can even change the logic used to redirect users to a specific language site by modifying the variations landing page called VariationsRoot.ASPX.  In doing so, you can enable SharePoint to handle other redirection processes like redirecting based on a previously selected language preference stored in a cookie or redirecting based on profile data (e.g. you know the user is based in Belgium and prefers French over Dutch).
Finding the Variations Setting and Beginning the Setup
There are two settings that control variations at the site collection level.  Both settings are found in Site Settings under Site Collection Administration.  To begin the process, you click on the Variations menu option.

By clicking on Variations you begin setting up how variations will be configured for your site collection.  In the subsequent interface, the “Variation Home” is what is called “Root Site” in this post (and what Microsoft typically calls it as well).   The variations interface is shown below:

Variation Labels
Once you’ve setup the global variations feature, you need to setup each variation label.  Variation labels represent every variation site you want to include in your public web application, including the source site.  For example, if you want to have a French (France), German (Germany), English (UK) and Arabic (United Arab Emirates), you’d need a total of four variations.  Of those variations, you’d pick one to be your source variation; the rest would receive content created in the source. 
When you create the labels for the first time, you start by creating the source label.  In our example, we’ll call our UK English site the source.  There are a few fields to complete:

Field Name	Description	Example Value
Label and Description	This is essentially the portion of the URL that designates the site. If your web site URL was http://www.mywebsite.com/ the label portion would be inserted after the last slash like http://www.mywebsite.com/[variation label].  In most cases, the label is going to be the two-letter ISO code for the language, followed by the two-letter ISO code for the country.  Wikipedia has a complete list of the current ISO language codes  and ISO country codes.	en-gb
Display Name	This field is what will be used to not only describe the variation in the management interface, but it will also be the default name of the site when the variation site is created.  Typically the display name is the localized title of your web application.  If your web site was called “My Web Site” in English, you would enter that value for our UK English site.  For French, you might enter a display name like “Mon site Web”	My Web Site
Locale	Use this setting to specify the language represented by a specific variation.   There are numerous languages show in the drop down and potentially multiple versions of any given language (e.g. Spanish in Spain vs. Mexican Spanish).  You should choose the appropriate language that fits your needs.  This setting is used by SharePoint to match a user’s browser language setting to the appropriate variation.	English (United Kingdom)
Hierarchy Creation	This setting determines what portions of the source variation SharePoint will replicate to other variation sites.	Publishing Sites and All Pages
Source Variation	This sets whether the variation you’re currently defining is the source variation.  This setting is something that is set once on a specific variation and can’t be changed after you’ve created the hierarchy.  This option also sets the specific site definition used in creating all variations.  NOTE: only publishing site definitions (e.g. Publishing Site) are there by default.	Publishing Site with Workflow

Here’s a screen shot of the form in SharePoint:

Other Language Variants
After you’ve setup your source variant, you setup the other language variants you want to represent.  The setup process is similar to setting up the source variation, except that the check box indicating the variation is the “source” will be greyed out and disabled.
Once you’ve completed creating the other variants, click the Create Hierarchies button to begin the creation process.  NOTE: Creating the hierarchies is handled by the timer job.  As a result, you will either have to wait for the timer job to run or manually initiate the job to see the variations.  This is also true of other timer job-dependent activities like site structure and page propagation.   More information on timer jobs is provided below.
Timer Jobs
Technically there are multiple timer jobs that each handle a different aspect of the propagation process.  Each timer job runs on a different schedule.  Here is the list of variation timer jobs and the default interval:

Timer Job	Description	Default Execution Interval
Variations Create Hierarchies	This job creates the hierarchies defined in the variation labels section of the variations settings.  As you add new labels, this job takes care of creating the corresponding variation site	Every 24 hours
Variations Create Site	This job creates variation sites if the automatic creation setting is disabled in the Variations section of the site collection settings.	Every 5 minutes
Variations Propagate Site	This job creates variation sites if the automatic creation setting is enabled in the Variations section of the site collection settings.	Every 5 minutes
Variations Create Page	This job creates new pages in each of the variation sites once the page has been created in the source site.	Hourly
Variations Propagate Page	This job updates existing pages in the variation sites once an update has been made to a source page.	Hourly

Depending on your needs, you can modify the default interval to match your publishing schedule.  For example, if you publish pages frequently, you may want to increase the timing of your page propagation and creation to 30 minutes instead of an hour.
Keep in mind that there’s a version of these timer jobs for every SharePoint application (think URL).  This means that you’ll have 3x the number of application configured for variations to manage.  Thankfully, Microsoft provides a view of timer jobs per application.
A screen capture of the time job definitions for a sample site is shown below:

Additional Notes
Like much in SharePoint, the choices you make should be based on your specific requirements; there is usually more than one way to satisfy a need and multiple ways to develop a solution.  To that end, here are some notes about variations setup to help you make these decisions.

• Variations can be used for more than just language versions of content.  Microsoft documentation points out that the logic to redirect users to specific variations could be used just as effectively to redirect a client to a mobile device.  In this case your label could simply be “M” for a mobile version of your site.
• The timer jobs do not replicate other lists or libraries from one variation to another.  This means that you must create lists and libraries in each variation manually after the hierarchy is setup.  This is also true of content in those lists and libraries; the timer jobs focus on structure (e.g. sites and sub sites) and pages.  However, if secondary lists are important for your solution, consider creating a custom timer job.
• Variations are site collection bound.  This means that all variation sites are housed in the same site collection.  If, for some reason, you think you may need more than one site collection, you’ll have to recreate your variation setup for each site collection.  Each site collection would be managed independently.
• When possible, use features and feature stapling to modify the nature of any particular variation (if necessary).  For example, if you need a specific SharePoint list or library created in each variation, use a feature and staple it to each variation as it’s created to ensure the list exists.
• Content contribution is a bit trickier with variations, since each variation is essentially it’s own “web site.”  As such, you will need to spend more time training content contributors and more time supporting them.
• If you use the new managed metadata feature in SharePoint, you’ll need to provide translations for terms as well.  Since all variations are housed in a single site collection, you can even use managed metadata bound to a column vs. enterprise managed metadata to isolate terms that may be specific to your site.
• You are required to setup a root SharePoint site for the site collection.  However, once variations are setup, no one will likely see the root site (since the VariationsRoot.aspx page will be set to the home page of that site).  As such, you don’t have to do much with it.  However, you could use the site to store more global resources, like images and documents, for use across all variations.
• Especially during development, you should execute the timer jobs manually by going to Central Administration, go to the Monitoring section and click on Timer Job Definitions to find the right job.  When you click on a specific timer job, you’ll have the opportunity to run the job manually.  Manually running the timer jobs will allow you to see what’s actually happening within your sites without having to wait for the job to run automatically.

Please share your experiences with multilingual sites and what challenges you’ve had through comments on this post.  There is a lot more detail to setting up and managing variations, so the more feedback the better.

Continue to part 2 of this series

Mastering Workflow Reports in SharePoint 2010

One of the challenges for SharePoint administrators is getting insight into what’s actually happening within the farm.  One element of management is workflow.  It’s not easy to discover what workflow processes are running, are there exceptions for a given process and how often is a process being used.

In the August edition of the SharePoint eZine, I discuss how to leverage workflow reports in the new 2010 version.  The various reporting and management interfaces make it relatively easy for administrators to better understand what’s happening.  While there are shortcomings in the available data (e.g. no whole farm reporting), what Microsoft provides does immediately provide value.

Does SharePoint Destroy Intranet Design?

In the latest blog entry from Jacob Nielsen, he asks an interesting question: does SharePoint Destroy Intranet Design? The question is interesting in that we get a variation on that question frequently from clients: what sort of design can I use with a site running SharePoint (i.e. what constraints are there on my visual design)?  The answer to both questions is: no and anything you’d like.

In Nielsen’s article, he points out that 4 of the top 10 winning intranets from his 2010 survey use SharePoint.  In fact, this is a trend that has continued from the 2009 survey, where 5 of the top 10 used SharePoint.  Nielsen even has screen captures in his article latest article (and in the reports) showing pretty varied designs across each of the winners.  More evidence of different visual designs (and experiences) can be found in the SharePoint Sites on the WSS Demo site (interestingly, this site is now using SharePoint Foundations 2010, so it’s technically not a Windows SharePoint Services demo…).  So why all the trepidation?  I’ll blame the out of the box experience from SharePoint.

Regardless of whether you’re implementing an intranet, an internet or an extranet site, the SharePoint siren’s call of “out of the box” is very strong.  Microsoft has provided “good enough” standard site definitions, visual designs and functionality; that out of the box design experience is actually (pardon the pun) by design – Microsoft hoped to save people time.  Unfortunately, you can’t please everyone.  As a result, many organizations want to change the visual design and experience.  In the SharePoint community, this is called making SharePoint look less “SharePointy.” (I’m not sure who first coined this expression, but it now seems like common vernacular).

If you’ve come the place where you’re questioning how to improve the visual design of the application you’re building on top of SharePoint or being questioned by others about “constraints” or “restrictions,” here some key advice:

• There are no restrictions on visual design when using SharePoint
  It’s true that there are some elements that should be included in your new design, like the ribbon (in 2010) or the page editor toolbar (in 2007).  However, neither should stop you from creating a design that fits your organization.  Just keep in mind that SharePoint controls (e.g. web parts and the elements that appear during editing) may not render the way the rest of your design does.  I would recommend rigorous testing to ensure everything works as you expect.  Design what you like and apply it to your SharePoint application.  Really.
• You don’t have to start with a Microsoft-supplied Site Definition
  Since SharePoint ships with so many site definitions (and visual designs), most firms assume that you have to start there and then customize.  This is far from the truth.  In fact, you can create a custom site definition from scratch.  This option requires lots more work, but you may need to head down this path for any number of valid reasons.   If you decide to create your own definition, just remember that you’ll have to enable the specific SharePoint features that make sense for your design (e.g. the publishing feature or search).
• If your visual design isn’t complex or matches the “L” navigation natively in SharePoint consider a theme
  SharePoint themes are often a good way to create a unique visual design without the work involved in creating new master pages or, with more effort, site definitions.  Many sites, though visually distinct from the standard SharePoint design, can achieve their design goals simply with a theme.   Consider this: a theme takes a competent developer approximately 8 to 10 hours, while a master page could take two to three days and a site definition could take a week or more (depending on complexity).   If you don’t need the “extras” don’t spend the time.  Another benefit is the reduced testing and maintenance required, since themes are just CSS.

While there are some considerations when developing an intranet solution on SharePoint, the product does not destroy or adversely impact intranet design.  In fact, as Nielsen points out, platforms like SharePoint are optimized to create a solid intranet foundation.  In many ways, SharePoint improves intranet development productivity by reducing the design or implementation effort in other areas of your project.

Getting to know SharePoint

Coming in May of this year, the new SharePoint 2010 promises to be a vast improvement over the existing 2007 version.  Like the transition from 2003, organizations are struggling to make key decisions about when to move to the latest version and what advantages it might provide.  In many cases, the answer greatly depends on your needs.    For enterprises that don't yet have SharePoint, but are evaluating the tool, the environment is probably even more confusing.

In an effort to help clients better understand both the upcoming version and the ecosystem in general, Consejo will be presenting at several regional and international events over the coming months.  If you're looking for greater insight into how SharePoint may or may not be a fit, I would highly encourage you to attend one of the following upcoming events:

1. "What's so special about SharePoint" (webinar) hosted by the Real Story Group, 6 April 2010, 1 to 2 p.m. EST.
   The buzz around Microsoft SharePoint has grown steadily since the product's introduction in 2001.  With the advent of SharePoint 2010, the buzz has reached a cacophony.  This raises the question: what's so special about SharePoint.  Shawn Shell, Principal and Founder of Consejo, Inc.  and Tony Byrne, Founder of the Real Story Group will present a one hour webinar to help organization separate fact from fiction and help organizations figure out if SharePoint is right for them.
   
2. SharePoint Summit 2010, 12 to 14 April 2010 in Montreal, Canada
   Shawn Shell, Principal and Founder, Consejo, Inc. will be presenting a session on "Managing a successful SharePoint Project" and participating on a panel discussing findability in SharePoint ("Findability to be or not to be").
   
3. Midwest SharePoint 2010 Conference hosted by Imerge Consulting, Milwaukee, WI, April 15, 2010
   Shawn Shell, Principal and Founder, Consejo, Inc. will be presenting a session on "SharePoint Tips, Tricks and Traps" to help organizations take advantage of all that SharePoint has to offer, as well as helping them avoid potential pitfalls.
   
4. Hardlines Technology Forum hosted by American Hardware Manufacturers Association (AHMA), 18 to 21 April 2010 in Schaumberg, IL
   Adonis Latham, Consultant at Consejo, Inc. will be presenting a session on leveraging InfoPath forms to help enhance SharePoint implementations. 

As the year progresses, there will certainly be more conference opportunities.  If you can't make it to one of these events, subscribe to our RSS feed to ensure you're aware of future events that may be of interest to you.

Getting Value from SharePoint Foundation 2010

There has been a lot of new content on the latest version version of SharePoint.  However, most (if not all) of the coverage has been on the licensed version SharePoint Server and little on SharePoint Foundation.  As one of the key factors in the overall platform success, it’s important to understand just what value you can get from the the upgrade to Windows SharePoint Services.

Like it's predecessor, SharePoint Foundation will be shipped as a free download from Microsoft’s site.  And, like WSS before it, Foundation provides all of the basic features found in the licensed SharePoint Server product.  If you work in an organization that can only take advantage of the non-licensed version, here are some of the features you get with Foundation:

• Basic document management
  You don’t need SharePoint Server to enable some of the basic document management features.  Foundation allows you to create sites, document libraries and manage the update of various types of binary files (e.g. Word docs, PowerPoint, PDFs, etc).
  
  
  Figure 1 – Working with a PowerPoint Presentation in a Document Library
  
• Blogs, Wikis and other Information Management
  The latest release of the basic SharePoint framework continues to include features like blogs, wikis and a wide array of other information types, like tasks, contacts and events.  Like the basic document management features, information management is a strength of SharePoint Foundation.
  
  
  Figure 2 – Editing a Wiki page in Firefox 3.5
  
• Integration with Office
  By far, one of the biggest strengths of SharePoint is its integration with Office.  Whether you have Office 2007 or Office 2010, you can save, edit, work with versions and manipulate metadata directly within the client.  You can also create other sites directly from the Shared Workspace task pane (Office 2007) or in the new Backstage (Office 2010), which exposes extended data about the document, the SharePoint library where it’s stored and other functions like viewing previous versions.
  
  
  Figure 3 – Backstage in Word 2010
  
• Working Offline
  In this release, SharePoint Foundation (with the help of SharePoint Workspace or Outlook) allows you to take content offline.  Whether you are connected to the web or disconnected on a plane, you can work on both documents and list items.  Editing list items is a significant upgrade from Groove 2007 and Windows SharePoint Services where only documents were available.
  
  
  Figure 4 – SharePoint Workspace showing a SharePoint Site offline
  
• Connection to External Data
  In the SharePoint 2007 timeframe, connection to external data was only available in the Enterprise version of MOSS.  In 2010, SharePoint Foundation has a basic version of Business Connectivity Services.  This means that Foundation users can take advantage of external data in SharePoint just like its server brethren.   All you need is SharePoint Designer 2010 (which is free) to create the connection and define what you want to expose.  Once defined, the data can be used to add content to columns or you can even manipulate the data through the familiar SharePoint list interface (if the data source supports that functionality).
  
  
  Figure 5 – Defining a new external content type in SharePoint Designer 2010

While these five features are not the whole of the new SharePoint Foundation product, it’s important to note that the latest release provides quite a bit more functionality than the previous version.  It also important to mention (again) that there’s no license fee for these features.  NOTE:  You must have a licensed copy of Windows 2008 R2 (64 bit) and you will need SQL Server (though you can use the Express version for no fee).

If you’re looking for a basic collaboration platform that is inexpensive and can be deployed inside your organization, you would do well to review what SharePoint Foundation offers.  If you need help with that deployment, Consejo offers a Fast Track to SharePoint solution that will help you get you running in about a week.

SharePoint 2010 Metadata and Taxonomy Management Overview

 

Stephanie Lemieux wrote a terrific article on metadata and taxonomy management in SharePoint 2010.  In fact, she’s referring to one of the new, key Service Applications that ships with the new product.

Like Stephanie, I’m interested in getting deeper into the details of how SharePoint handles metadata.  However, it’s clear that Microsoft did hear the challenges customers were facing and invested significantly in the new service.  It was one of the key areas of improvement I wrote about in the CMS Watch advisory paper on SharePoint 2010.

If you’re interested in learning more about managing taxonomy in SharePoint (either 2007 or 2010), be sure to check out the KM World 2009 pre-conference workshop that Stephanie and I are presenting.