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.

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.

SharePoint Conference 2011– Good Reminder, Few Surprises

Microsoft wrapped up their SharePoint Conference 2011 on Thursday this week.  In attendance were some 7,600 people, all seemingly enthusiastic for the phenomenon that is SharePoint.  While there were few surprises, Microsoft did remind everyone why the platform is so popular.

If you’re interested in a complete review of the conference, check out my posts on the Real Story Group blog:

• SharePoint Conference 2011 day one
• SharePoint Conference 2011 final wrap up

It’s fair to say that we haven’t seen the crest of SharePoint popularity or growth.  Microsoft even made an out of character announcement regarding another SharePoint conference in 2012 being held in Las Vegas.  Two conferences in two years – sounds like something new may be announced.  Stay tuned!

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.

Does Microsoft need a SharePoint App Store

Yes and no.  You see, its just not as easy as a black and white response.  You could argue that SharePoint needs an app store because there are far too many specific use cases for which it’s out of the box experience is ill suited.  However, SharePoint does ship with a number of “apps” (Microsoft calls them “Site Definitions”) that can satisfy relatively simple needs with little or no work.  The challenge is whether the out of the box archetypes like “team sites” or “document workspaces” in Foundation or “publishing portal” or “search center” in the Standard/Enterprise versions are sufficient; could Microsoft or a 3rd party effectively create additional, purpose-built archetypes to improve end user adoption and overall usage?

To illustrate this point, let’s suppose you need to create a web-based collaboration space to work on a document with a small team of people inside your company.  It’s actually quite simple to use what SharePoint provides immediately. You’d likely start with a “document workspace” (shown in Figure 1).  The workspace can be provisioned while you’re reviewing the document from within Microsoft Word (or another Office product) or from SharePoint’s web-based interface. You can even invite your colleagues from the same interface (within Word) or, again, through the web interface, without any trouble. Once the workspace is provisioned, you’d automatically have a library to store the document (and the document would already be waiting there for you and your team members). In addition, the workspace would show who was participating in the workspace through the members list (with direct links to their individual profile by clicking on their names), a task list to assign & track responsibilities, an announcements function to communicate with your team and a discussion thread for working exploring topics relevant to the document. All of these features are packaged up and provisioned automatically. So what’s the problem?

Figure 1 – Typical Document Workspace in SharePoint 2010

What happens when you want to create a quick, web-based file sharing site and “invite” others inside or outside of your organization?  You’ll quickly find the standard SharePoint site definitions fall a bit short.  SharePoint does have features that support file sharing through sites and libraries; users could even access and edit those files through Office on your desktop or use Office web app through a browser.  There’s also the possibility to let non-employees access the site.  Unfortunately, the collection of features, along with the requisite security model are not available in a shipped SharePoint site definition.   As a result, an end user would have to start with an existing site definition, like a “blank site,” then add a combination of lists and libraries to create the environment they want.  Next, they would grant internal participants access to the site, applying library/list-specific or document-level permissions as necessary.  If the users aren’t in Active Directory (like the non-employees), SharePoint allows you to use SQL Membership to store those non-employee IDs in a SQL database.  However,the non-AD authentication configuration work requires you to manipulate machine-level settings in an XML configuration file, create databases on a SQL server and grant specific application pool identities access to the database.  Most of this effort is typically outside the expertise of an average end user; even if they weren’t, because of the changes necessary to the farm, most administrators wouldn’t want end users changing these settings.

Ultimately, there’s little evidence that SharePoint is wholly unsuited for collaboration needs inside the enterprise.  If fact, you could argue that SharePoint, given its breadth of functionality, has no equal in the collaboration space.  However, there are well-documented challenges in creating you own applications on SharePoint.  Remember that SharePoint, by Microsoft’s own admission, is a platform and not a product.  This means companies are either left developing their own applications or buying from a 3rd party.  This begs the question: should Microsoft devote some of their R&D budget to developing applications on top of SharePoint?  Further, wouldn’t building applications on SharePoint, in fact, be more useful to a greater number of people than adding new features to the platform?  This approach would certainly go a long way to blunt attempts by companies like Huddle, 37 Signals, Box.NET, HyperOffice and others to discredit SharePoint for purpose-build solutions.  Microsoft has demonstrated, historically, their willingness to drive down this path with new site definitions like the “Fab 40.”  Unfortunately, some of these applications were just silly (like the Baseball Team management portal) and they never followed-up with equivalents on SharePoint 2010.

If you’re searching for specific applications on SharePoint today, you’ll need to look to the myriad of 3rd party vendors like Bamboo Solutions, Coras Works, SharePoint Solutions or the app store concept from the larger SharePoint community called Sharevolution.  Unlike Apple and Google (or even Microsoft’s own online store for everything from Windows to XBox to non-Microsoft hardware), Microsoft has not created that one-stop-shop to find specific solutions built on SharePoint.  One can only hope that, in the future, Microsoft does something more creative than simply redirecting the domain sharepointapps.com back to the SharePoint product site on Microsoft.com. 

Technology Just Gets in the Way

The idea that most folks in IT, and even some  on the non-IT side, spend way too much time worrying, thinking and generally kvetching about technology is almost passé these days – everyone knows it true, but they still get wrapped up anyway.  Incredibly, most people tend to see the process of solving business challenges exclusively through the lens of what a specific tool can solve.  This condition is never more obvious than when firms start discussing SharePoint. 

Inevitably, there are discussions that start out well – focused on business needs and what users have to accomplish.  Then, for some strange reason, things go seriously awry.  In the words of Ace Ventura, Pet Detective – “Gee, Chuck, the date started out good. Just before we got to the party she seemed to tense up.”   Perfectly rational people start discussing if SharePoint’s wiki has sufficient functionality, can the firm really use the out of the box search, are the records management features robust enough for the entire enterprise?  All of these questions are very reasonable to ask if two conditions have already been met: 1) you know what problems you’re trying to solve and 2) you have well-defined goals and corresponding metrics to measure if you’ve successfully met those goals (notice I avoided using the word “requirements”).  Unfortunately, most organizations fail to satisfy either condition before pushing head long into a “how do we implement SharePoint” discussion.

If you regularly read this blog, you’ll know that I’ve already said SharePoint is not the answer.  However, this is true of any technology if you haven’t clearly defined what you want to accomplish.  No matter what tools you might be considering, you must be clear about what you’re trying to accomplish AND ensure that your goals are achievable.

Published on the Word of Pie blog, there’s a great post about taking a break from ECM that illustrates this point perfectly (though through the broader lens of ECM).  In the post, Laurence Hart (@piewords) describes all of the challenges with ECM implementations.  He does such a terrific job that I’ll end this post with only one bit of advice; read his post.

Education and Training are Required

The title of this blog is a bit of a mix of themes from Mr. Nielsen’s latest post to his Alert Box.  However, the underlying message was that users don’t actually know how to find content (broadly) and that as search improves, their abilities actually deteriorate.    The implication was that insufficient training and education (both) are provided to users related to information technology.

This scary conclusion was based on research he and his firm have been doing in Asia-Pacific.  He stated that they watched “more than 100 searches for a broad range of tasks.  Only once did I see a user change strategy.”  If you immediately thought, after reading this quote, that changing keyword terms is a change of strategy, Mr. Nielsen offers this retort: “… simple query reformulations don’t count as a strategy change because they were essentially variants on a single approach.”  In Mr. Nielsen’s example, his search research subject was trying to find the differences between a cold or influenza using the symptoms as search terms.  The actual change in strategy is when the research participant started searching for the disease rather than the symptoms.

In our work, many clients try to rely too heavily on search.  They believe good content organization (taxonomy) and tagging (metadata) are unnecessary.  With many of them implementing SharePoint, they often immediately want to install FAST because of a misplaced perception that the standard search technology is inadequate.  In fact, the real challenge is that most users don’t understand how to use search in the first place and most firms don’t invest sufficiently in good content organization.  Further, clients also haven’t provided any education or training as to the use of search, taught their users how to leverage a taxonomy to find content and/or don’t leverage features of the search engine that could improve results or reinforce the right sort of search behavior. 

As Mr. Nielsen points out, search does not solve the findability problem.  And worse yet, as engines get better at figuring out what users want, those same uses continue to degrade their ability to truly engage in research on the web.  

Firms need to invest in education for their workforce if they hope to successfully use technology (any technology).  They also need to invest in training.  The difference?  Training imparts a skill within the context of a specific situation, where education teaches a concept that can be applied in many contexts.   To be truly successful, organizations must provide both.  Then and only then will firms begin to really extract the value they’ve created with the tools they’ve implemented.