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.

[Good] Communication is Key

Every now and again, a really fantastic opportunity to illustrate a best practice just falls in your lap.  The opportunity, just as occasionally, presents itself through inspiration found in the most surprising places.  In my case, I found this communication example in the men’s room at a client: 

This sign provides an excellent template to use when communicating with your audience: 

• It starts by presenting the message at the time when the recipient is engaging in a related behavior
• The messaging points out a very specific feature of the tool being used
• A statement of community support for that feature is provided
• An aspirational goal is included to (through implication) encourage a specific, future behavior
• All of this is followed by a polite.. thank you!

Ignoring the specific subject matter involved in this message, this could easily serve as a model for feature-obsessed technologists and enthusiastic Intranet managers on how to encourage intranet or technology adoption.

What do you think?

[EDITED TO CORRECT SPELLING AND WORD CHOICE]

The Wisdom of letting Users “Figure it Out”

Back in July of this year, Computerworld, Networkworld and CIO all ran an the article “Telecom Giant Takes to Web 2.0.”  It was about Alcatel-Lucent’s use of social media tools.   The article opens with a quote from Greg Lowe, Social Media Strategist and Global Infrastructure Architect.  Lowe stated that the CEO told the organization to be more “collaborative.”  What immediately struck me was the response: go buy/implement a technology.

Based entirely on Lowe’s title, it appears that he is a member of Alcatel-Lucent’s Information Technology group.  Unsurprisingly, it appears as if the first reaction to the CEO’s statement was to find a tool to “fix” the problem; based on the content of the article, it wasn’t clear exactly what the CEO meant and whether another tool would be a solution foundation.  However, the approach described was a typical pattern:

1. Find a tool that seems to enable individuals to solve a problem
2. Make the tool available
3. Let the user community figure out how to make the organizational changes necessary to actually solve the problem

The trouble with this general approach is that it is often a recipe for disaster. 

Much to the credit of Alcatel-Lucent, they seem to be successful in at least getting folks to use the new tool.  What wasn’t immediately obvious, however, was whether the tool solved the problem the CEO identified.  To be blunt, does tool usage indicate the problem was solved or just that people were using the tool?  In using the tool, does it mean that quality collaboration, that fundamentally improved an individual’s ability to complete their job tasks, occurred regularly?

To CIO magazine’s credit, they did link to an article that presented a similar situation at Phillips, called “My Enterprise 2.0 Rollout: 4 Keys to Success.”  Fortunately, this article presented a far more thought out and methodical approach to using the “2.0” technologies.  The difference between the two approaches boiled down to the following (even identified as “keys to success”):

1. Develop a good strategy
   Phillips spent time trying to understand what they wanted to accomplish – not just “we need to collaborate better.”  Specifically, what will truly make a difference in our business?  If a business can’t improve productivity, reduce expenses or improve revenue, why implement technology solutions at all?
2. Lead by example
   At Phillips, the executives lead by example and leveraged the tools in their own work.  This approach provides a fantastic benchmark for the rest of the organization.  As the article points out, it’s not about an edict from above, but rather a way for the leaders in the firm to demonstrate usage and, in a way, also publicly learn from those lower in the organization.  Frankly, if an enterprise wants to make any initiative successful, employees need to understand that management supports their efforts and their work won’t be wasted.
3. Work with the user community
   Unlike the Alcatel-Lucent example, Phillips actively worked with the user community to ensure success.  The work involved in and the problems solved by the tool aligned directly to challenges within the organization; there were clear metrics for success. 
4. Allow a bit of “organic” evolution
   The article calls this concept “loosening the reins.”  Phillips didn’t explicitly create policies to govern the use of the tool.  While it’s generally a good idea to incorporate governance into the use of these kinds of tools, the idea of allowing a bit of usage flexibility is critical.  In many cases, there is insufficient data to truly understand what might or might not work in the enterprise.  Further, a certain trust needs to develop between the firm and employees – the firm needs to trust employees will use good judgment and employees need to trust the firm is making the tool available to improve productivity.  Ultimately, to be successful, there needs to be a good mix of established, general guidelines for appropriate use, as well as flexibility to enable “out of the box” usage scenarios.

When contemplating how to approach implementing these collaborative technologies in your organization, consider the four points above. The "build it and they will come" approach to technology doesn't work. However, it is a pattern that many in IT use to mostly their detriment. It's time to change the approach.

User Surveys for Intranets

Dorthe Raakjaer Jespersen (sorry for the English spelling) at J. Boye recently posted a blog entry “New Intranet: do we really need user surveys?”  It was a good read about how user-centric research is an excellent foundation for a new intranet. 

Early in the article, she points to somewhat typical exchanges between intranet managers and company management; the archetypical intranet manager management thinks surveys will help the intranet team better understand the needs of the users.  The equally archetypical manager thinks they need to start building immediately – surveys will take far to long to complete.  Dorthe goes on to provide an excellent set of talking points intranet managers can use to encourage management to agree to use surveys and highlights some of the potential risks in forging ahead without the user data.

However, once you’ve gotten approval, what’s next?  What questions do you ask?  What sort of feedback should you expect to get from your end users?  How many individuals should be included?  The answers to all of these questions do depend on what you need from your user community, the size of your organization and the scope of your intranet.  To help you get started, here are a set of basic questions we would recommend you include in your survey:

1. In what department do you work?
   This question provides context to the answers.  Expect every department to have different needs and desires.  The question may also give you a picture of future departmental participation and support, as well as an early indicator of departmental adoption.
2. What is your age range?
   This sounds like a question you’d want to avoid.  However, the answer will help you evaluate responses.  Many organizations we’ve worked with recently have somewhat older populations.  The age of an employee tends to affect what features of an intranet are compelling.  Your Intranet should reflect the population age average.  If you have a somewhat younger workforce, social features like status updates or blogs may be more compelling.  Older workforces will likely be drawn to a more “traditional” informational Intranet.  Keep in mind that you cannot and should not over generalize; age, in and of itself won’t tell you a lot.  However, the data will provide another useful dimension to the analysis.
3. How often do you use the Internet to support your work?
   In some organizations, the existing Intranet is little used or there’s no Intranet at all.  In its place, many employees will turn to public sources of content and information.  This specific question will help you gauge how much external vs. internal sources of information help people get their work done.  In fact, the answers to this question should be a limited list of options like: no access, my work is paper-based, I know the right person to ask, not interested, etc.   A side benefit of this question may be the discovery  of what services to offer through a newly designed intranet (assuming you follow-up this question with one that asks about their specific usage).
4. How often do you use the existing Intranet?
   It’s likely if you’re checking your server logs, you already know the answer to this question.  However, getting direct feedback is helpful is validating your objective data.   Where possible, include a list of selectable ranges of time like: once a day, once to twice a week, monthly, etc.
5. What functionality, types of information or content is important to you?
   Provide your survey participants with a list of functionality (e.g. applications), content and information that you’re either considering or have surfaced through the Intranet.  Let them choose what’s most important to them.  Use the answers to help guide your development.  More than one of our clients has chosen features or content poorly without this data (leading to community dissatisfaction with the Intranet).  Further, the answers can help validate or invalidate the inevitable “nice to have” functionality that often is introduced during development; if it wasn’t important to your user community, it shouldn’t be important enough to get included in the Intranet.  You can also follow-up this question with a free-text question allow people to suggest items that weren’t included in the list.

The preceding five questions should really be the start of about a ten (10) question or less survey.  In all cases, try to make survey questions very specific to your organization.  For example, you could ask about the location of the employee (if you have multiple physical locations), ask a matrix question that allows the participant to agree or disagree with various statements regarding your intranet (or what they’d like to see) and ask about usage outside of work (e.g. at home or through a mobile device), if those access methods are important. 

The survey should be one of the first exercises you perform when gathering requirements and/or intelligence on a new or redesigned intranet.  They generally provide very valuable insight into user behavior and needs, plus has the added benefit of allowing you to validate features, functions and “requirements” against direct user feedback. 

In closing, here are some other tips:

• Surveys should be only one of a few data sets used to evaluate your needs.  While it’s a good foundational insight source, it can also be misleading; if someone doesn’t have a good answer for a specific question, they may simply make something up.  As a result, the size of the survey population has to be significant enough to counteract errant responses.
• When designing the survey, keep the overall survey length to no more than 4 to 5 “pages”
• The survey should take between 10 to 15 minutes to complete; longer surveys may work, but you’ll get lower response rates.
• As mentioned earlier, the surveyed population should be significant, but also representative.  If you 10,000 employees, interviewing 50 people is insufficient as it represents less than 1% of your population.  Further, if you have a mix of factory employees and corporate, desk-bound employees, be sure to get people from both communities to participate.
• Ask relevant follow-up questions.  For example, if you ask about access methods (e.g. from home, mobile devices, etc), ask if they access the Intranet from home, because they have no access in the workplace (e.g. many factory workers have restrictive work rules that may prevent access to PCs during their shifts).
• Offering incentives for participation will greatly improve participant involvement.  Some clients offer gift cards for all participants, while others use the “win an iPod” approach with a participant chosen at random.  What you choose should reflect your culture and drive the sort participatory behavior you desire.
• Follow-up this survey with a similar version post launch.  A follow-up survey will give you very clear measures of improvement and help to establish basic metrics for judging on-going success.  For a discussion of other Intranet metrics, see a great article by Toby Ward on Intranet Metrics.