Consejo Blog

Improve Code Reuse with Search

noreply@blogger.com (Shawn) — Mon, 21 May 2012 13:20:43 PDT

In past, I have been critical of simply crawling content with a search engine and using the basic keyword query approach to find things. However, there are some situations that do lend themselves to just this approach (though with a tad bit of “intelligence”). One of these situations is code reuse.

At Consejo, we use Subversion (coupled with VisualSVN Server) for source control. Subversion (or SVN) is an open-source source control system. VisualSVN Server provides a terrific web interface to the repository. Combined with the VisualSVN plugin for Visual Studio, we are able to very effectively manage our code production across clients with little or no cost. Unfortunately, with our team dispersed, it’s sometimes difficult to make everyone aware of what’s already been built for one client or another.

SIDE NOTE: I have personally been critical of using open source solutions and even wrote an article arguing against the open source model. However, it’s clear there are cases where open source makes sense (yup I was wrong). Further, we’ve been a financial supporter of SVN (through donations) since we started using the tool regularly.

Much of what consulting companies do is based on past work. It’s critical to how we work that every consultant is kept abreast of what the firm is doing, across industries, disciplines and clients. For example, we recently built two different applications, for two very different clients. Both applications, however, used the same licensed interface controls. In fact, many of the interactions each application’s user base had with their respective application were very similar. As a result, techniques we used, problems we solved and utility code (code not specific to a client or application) we constructed could be leveraged across both projects with minor updates. This saved both our consultants and our clients time and, more importantly, money. Unfortunately, since both projects overlapped, there was no a good way, besides knowing team members on both projects, to capture and surface code reuse opportunities in an automated way. Each team has to basically know what the other team was doing and ask specific questions (or discover reuse opportunities through happenstance). Not a fabulous nor scalable model.

While we solved this problem the “old fashioned” way, it’s not a good long-term solution. As projects get more complicated, team members more geographically or temporally dispersed, the “old fashioned” way becomes very burdensome and super inefficient. So what’s the solution?

Historically, we’d been looking for ways to effectively expose our SVN repository to our consultants, outside of Visual Studio and a web browser. The thought was that if developers were able to search for specific code constructs or even development pattern names, there was a reasonable chance of finding reusable code snippets or whole libraries (if they existed). And, while there are a few tools that help in this regard like FishEye and SvnQuery, neither was a perfect fit for our needs. Since VisualSVN Server presents the repository as a web site, why couldn’t we just use a standard search engine like MS Search Express, SharePoint or GSA (Google Search Appliance) to crawl the repository and allow consultants to query it like a web site?

The answer, as Kenneth Scott points out in his blog post on crawling VisualSVN with a search engine, is “not exactly.” The problem stems from the way VisualSVN renders the repository web interface (you should read his post for the details). However, Kenneth solved this problem through the use of an HTTP handler and gave us exactly what we needed. Using his utility, we can indeed use a standard search engine (take your pick) and then allow our developers to search for an example of an excel-like editing experience using a Telerik GridControl or discover if we’ve built a custom authentication provider for SharePoint; both of which we’ve done, but only one I knew about until recently.

You may still be questioning why this is a good idea? I’ve been critical of this kind of shot gun search approach in the past. Why should this work now? The reason is the very narrow information domain and the very specific terms developers use. Both work together in a way that makes finding content, using straight keyword queries, more reasonable. For example, if I want to find example of our use of the Telerik GridControl, I can simply search for the RadGrid class name. If I want to figure out if we’d built a .NET membership provider, I can search for the inheritance statement. In the first case, I may get an overwhelming number of results. However, they’ll all be examples of use, since the only time that class would appear is when I’m using it in code (in other words, relevant). The second example would produce far fewer results and likely give me exactly what I need immediately (and relevant and, probably, highly precise).

In the end, I’m only really disappointed that I didn’t discover Kenneth’s blog post sooner, but my past search queries were about SVN or Subversion, not VisualSVN (poor search strategy on my part). However, as we develop this code search feature inside of our intranet, I’m excited by the prospect of finding internal examples of code we can reuse.

If you have a similar feature inside your firm, I’d love to hear how it works and if it’s yield higher code reuse.

The Myth about SharePoint Browser Support

noreply@blogger.com (Shawn) — Wed, 04 Apr 2012 11:40:46 PDT

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

noreply@blogger.com (Shawn) — Tue, 06 Mar 2012 14:21:57 PST

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]

Why “Search” instead of “Find”

noreply@blogger.com (Shawn) — Tue, 31 Jan 2012 07:55:00 PST

In July 2010, I posted “Can search really solve information ‘finability’.” Since that post, I’ve run into a number of clients who continue to insist that they need to search (even if “search stinks” in their organization). Yet, almost universally, they report the search experience misses their expectations. This should be no surprise, as lots of firms struggle with this very problem. However, I’d like to suggest an alternate hypothesis: they actually want “find,” not “search.”

For better or worse (mostly worse), loads of folks closely associate the act of search with the expectation of locating desired content. Typically, at least outside of an organization, this means assuming they should navigate to Google or Bing (mostly Google). When they arrive, they enter a few keywords and press “GO.” At this point, they’re presented with a set of results from which they choose one that looks promising. In part, any perceived success is just that; they don’t necessarily expect to find what they want. If, however, they happen to find the object of their desire, they are pleased.

While both “search” and “find” are verbs, search does not imply a goal, simply an action. Search describes everything in the scenario I just relayed except the part where you’ve found the appropriate destination. Find, by contrast, is explicitly the goal and characterized by viewing your content. If you need a very concrete example, if child goes missing, the goal is not to search for the child. The goal is to find the child.

Therefore, in regards to content, consider changing the conversation. Use the word FIND instead of SEARCH. In doing so, you begin to think of the goal and not of one particular approach. Further, if we focus on finding content, we can also measure a success rate.

This orientation change opens up a whole world of opportunities. For example, start with the simplest model: place relevant content on the first page they see on an intranet. While this may seem wholly impractical (too much content, no context to judge relevance), this kind of solution is possible. Use what you know about your employees/users. If you know within what department they work, you can begin surfacing content from their department. Not specific enough? What about adding in the role they serve and surface content targeted to that role (NOTE: a good driver for metadata).

Beyond actually locating the content in plain site, try surfacing tasks associated with the desired content. For example, display tasks like “Submit an Expense Report,” instead of requiring users to search for the expense report form or “Fill out a Timesheet,” which links to the time reporting system (or simply an interface to immediately report time). In this way we’re presenting navigable elements that are easily understood and focus on actual tasks employees/users need to accomplish without the need to search.

However, if you really must provide search, give them help. Provide them with a targeted search facility that enables them to narrow the scope of the search (i.e. don’t return results from the entire enterprise if they’re looking for a project related document). Give them metadata to enable precise queries like “Author = Jane Smith.” Finally, give them “canned” or pre-developed queries created by “experts” who can construct search queries that ensure result precision. In this way, we’ve moved away from the simply keyword-driven approach to a more intelligent model that reduces “noise” and improves precision through carefully use of the technology. As an interesting alternative, execute these queries in the background and simply display the result like other navigation on the page; in this way, the user doesn’t actually have to execute the query and you’ve just saved them a step in finding content.

In short, search (as a tool) must necessarily become one of an array of techniques used to find content. However, it should absolutely not be the first or only approach. We must think in terms of FIND, not SEARCH. Find is the concrete goal and has a measurable success rate; search is simply an action that, while measurable, does not necessarily lead to your user’s goal.

Multilingual SharePoint Sites–Part 2

noreply@blogger.com (Shawn) — Tue, 24 Jan 2012 04:43:00 PST

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

noreply@blogger.com (Shawn) — Mon, 16 Jan 2012 01:12:34 PST

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

noreply@blogger.com (Shawn) — Fri, 07 Oct 2011 13:46:15 PDT

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:

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

noreply@blogger.com (Shawn) — Mon, 08 Aug 2011 14:10:01 PDT

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

noreply@blogger.com (Shawn) — Wed, 29 Jun 2011 09:16:54 PDT

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

noreply@blogger.com (Shawn) — Tue, 21 Jun 2011 08:27:38 PDT

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

noreply@blogger.com (Shawn) — Mon, 11 Apr 2011 07:44:33 PDT

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.

What to do with SharePoint when you’re not a Developer

noreply@blogger.com (Shawn) — Mon, 14 Mar 2011 08:43:00 PDT

Much of what is published and presented on SharePoint is aimed at a relatively technical audience. If you review the myriad of SharePoint conferences, SharePoint Saturday sessions and blog content, you’ll find very little content for non-technical folks. More importantly, much of the content that does exist, wants you to come to one conclusion – SharePoint is the right platform.

Unfortunately, if you’re a manager or an executive trying to understand the strategic choices related to SharePoint as a platform, or perhaps you’re trying to decide what to do with an existing implementation, it’s difficult to find good objective guidance. Worse yet, if you’re evaluating whether SharePoint is even the right platform for certain requirements, how do you effectively compare your options?

Recently, the Real Story Group and Information Today developed a new conference, the SharePoint Strategy Summit. This conference is specifically targeted at the non-technical manager or executive. The program, just a brief two-day affair, focuses on providing you with the information necessary to help you make the strategic decisions necessary for a successful SharePoint implementation (including helping you understand when SharePoint isn’t good choice).

During these two days, the conference covers topics including:

SharePoint as an Enterprise 2.0 platform

SharePoint might seem nearly ubiquitous as an enterprise collaboration platform, yet many organizations are still in the process of deciding whether or how to adopt it as part of a broader intranet platform. In the meantime, Microsoft is heavily touting new social and community services in the latest version, SharePoint 2010. Get an objective overview of what works well—and poorly—in SharePoint 2010.
Strategic alternatives to SharePoint

If you don't go with SharePoint, or chose to put boundaries around the platform, what other alternatives await you beyond Redmond? Learn the pros and cons of SharePoint alternatives.
Compliance and Records Management

Records management is not a SharePoint strong point. Large SharePoint deployments represent a particular challenge when it comes to the long-term retention, disposition, and discovery of information. This session explores the limitations of the platform and the alternatives you may want to consider. What sorts of steps do you need to take to batten down SharePoint so that it passes regulatory muster?
The Real Cost of SharePoint

The licensing structure for SharePoint has been a source of confusion for many customers. However, once you buy the software, the real costs of a solution begin. What should expect to spend?
Governance Models and Lessons Learned

Everyone agrees governance is critical—even essential—to long-term success with SharePoint. But how to do it and where to start? Join a panel of consultants and customers who will outline different ways that they’ve gotten SharePoint under control within their organizations. There’s no simple answer here—but you should come away with an approach that works for you.

Unlike other conferences that tend to be heavy on PowerPoint presentations, this conference has a pretty even mix of panel-style debates, moderated roundtable discussions and more traditional presented sessions. The goal is to create a very interactive experience and enable attendees to get closer to experts, as well as more deeply engage with other attendees.

If this sounds like the right conference for you, visit the SharePoint Strategy Summit registration page. The conference is just two weeks away and there are just a few remaining slots available.

Article: SharePoint 2010 and the Mobile Experience

noreply@blogger.com (Shawn) — Thu, 03 Mar 2011 07:13:00 PST

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

noreply@blogger.com (Shawn) — Mon, 28 Feb 2011 10:51:00 PST

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

noreply@blogger.com (Shawn) — Tue, 04 Jan 2011 12:35:51 PST

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.

Year in Review

noreply@blogger.com (Shawn) — Thu, 30 Dec 2010 09:30:48 PST

As we close out 2010, I wanted to reflect a bit on the past 12 months.

First and foremost, I want to thank all of our clients (new and existing) and our partners for a terrific year! We have had the opportunity to work with some fantastic folks on a number of very cool projects. We were fortunate to be involved in both SharePoint 2010 and 2007 projects, custom ASP.NET projects, work with our newest software partner EPiServer, continue our research work with the Real Story Group and spin up a fairly busy migration practice around Microsoft Business Productivity Online. In fact, working on the variety of projects with a diverse set of partners and clients is one of the reasons consulting is such an interesting business. For 2010, here is a sampling of the projects and firm types Consejo worked on and with:

A zoo on a custom-written management web site
A global media company on extensions to SharePoint Solutions ExCM
A scientific equipment manufacturer, a container manufacturer and a SaaS software vendor evaluating and assessing their SharePoint implementations
The Real Story Group, researching and writing about SharePoint
A hospital system on both the development of an intranet and a clinician portal on SharePoint 2010
With our partner Earley and Associates, we worked with a multi-national construction company on a global intranet design, taxonomy development and metadata definition
With our partner Alternative Productions, we created a dynamic flash component for a sales training company and integrated it into their EPiServer-powered public web site
A global horticulture company on an internal, custom-written management web site; our partner Graphic Insight developed the visual design and we worked with developers from i.c. stars
Continued to support a major league baseball team’s SharePoint 2007-base intranet we implemented for them in 2008
Providing SharePoint support services for a food services company
Working with our partner Strategic SaaS to migrate clients to Microsoft’s Business Productivity Suite Online (and soon Office365!)

In addition to client work, we also had the opportunity to speak at various events. 2010 was a busy year for conferences and we spoke at many events this year, including:

Hardlines Technology Forum in Schaumburg, IL
Midwest SharePoint 2010 Conference in Milwaukee, WI
SharePoint Summit 2010 in Montreal, Canada
Enterprise 2.0 in Santa Clara, CA
The J Boye Conference in Aarhus, Denmark
SharePoint Symposium in Washington, DC (co-located with KMWorld)

In all, our experiences with our clients, discussions with firms interviewed in our research and interactions with attendees at conferences have provided us with a wide-ranging 2010.

I would like to close this post by personally thanking all of our consultants, our clients and our partners (including the conference organizers of the various events) for a wonderful year. I wish you all a prosperous 2011 and look forward to continuing our work!

Happy new year!

SharePoint Influencer50

noreply@blogger.com (Shawn) — Thu, 28 Oct 2010 10:00:03 PDT

Recently, Global360 and KnowledgeLake sponsored a study by Influencer50 to identify the 50 most influential folks in the SharePoint space. If you follow SharePoint and the people who often blog, tweet or otherwise consult, you’ll know that trying to identify the 50 most “influential” individuals is no trivial task. However, that’s exactly what the Influencer50 study aimed to accomplish.

When the study was released, I was slightly surprised to be see my name among the 50. Though thrilled to be included with folks like Andrew Connell (Critical Path Training), Tony Byrne (Real Story Group), Tyson Hartman (Avanade) and Sue Hanley (Susan Hanley, LLC), the study got me thinking about what it means to be an influencer and how much weight to give to the study.

Rob Bogue was the first public critic of the SharePoint Influencer50 study that I’ve seen so far. In his post, he makes his argument along a few dimensions:

It’s challenging to measure influence
Difficult to gauge how a potential buyer will react to any influence given the sheer number of variables involved
Influence changes depending on the situation and, to point #2, there may be influencers that are “hidden”
You can’t be an influencer if you aren’t directly involved in the space
[Implied] Vendors sponsored the study (credibility issue)
[Implied] The firm conducting the study is using a potentially unsubstantiated methodology

Some of Rob’s arguments are compelling. I would wholeheartedly agree with items 1, 2 and 3. As Rob points out, it’s difficult to “predict the weather,” due to the sheer number of variables involved. The same is true of buying decisions; you just never know what factors are involved in getting someone to purchase software. Further, the influencers for a given buying decision will change; in the SharePoint space, I’d rely on an infrastructure focused consultant for Farm configuration best practice more than I would someone like me who tends to be more focused on development.

That said, I’m not sure all criticisms he raises are valid. I found the Amazon discussion regarding book sales a bit of a red herring; sales popularity does not imply fitness or validity. I also disagree that someone like Jon Powell from Alfresco can’t be influential. It doesn’t make sense that one would be influenced only by those folks who only support one position or another. I think it’s reasonable that potential buyers listen to Mr. Powell as much as a SharePoint MVP; his criticisms are at least as telling as positive statements from SharePoint pundits. Finally, while the study was sponsored by vendors, it shouldn’t be dismissed on that fact alone. While Rob is critical of the Influencer50 list (and “top” lists in general), he is a part an “elite” list – the list of SharePoint MVPs; a fact he promotes on his blog. Like the Influencer50, the SharePoint MVPs represent a group of individuals named by Microsoft and must fit a specific criteria.

Ultimately, any study or list should represent just a single data point in a collection of research. SharePoint is a very broad product with lots of capabilities and it’s unlikely that any singular list, whitepaper or study could cover everything. The SharePoint Influencer50 study is one way to discover potential sources of intelligence on SharePoint, but it’s not exclusive. I’d recommend using a few sources of information and draw your own conclusions.

The Wisdom of letting Users “Figure it Out”

noreply@blogger.com (Shawn) — Tue, 19 Oct 2010 05:00:01 PDT

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:

Find a tool that seems to enable individuals to solve a problem
Make the tool available
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”):

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?
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.
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.
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

noreply@blogger.com (Shawn) — Tue, 07 Sep 2010 14:11:57 PDT

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:

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.
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.
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).
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.
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.

Oracle Internet Directory Membership Provider (LDAP) for SharePoint

noreply@blogger.com (Shawn) — Mon, 30 Aug 2010 07:14:08 PDT

A while back, I posted an article on how to create a SharePoint membership provider for Oracle’s Internet Directory (LDAP). The post continues to be a relatively popular post and more than a few folks have asked for the source directly.

While I’ve generally tried to e-mail the membership class directly to anyone who requests it, simply posting it to the Consejo blog is probably easier on everyone.

Here’s a TXT version of the C# class. While I’ve refactored subsequent versions of this class a few times, this version is still pretty raw, but functional (read: it’s a good start if you have nothing). In this version, I used Kellerman’s Encryption Library to handle the MD4/MD5 hash format used by my client’s directory; interestingly they used one method for their test environment and one for their production environment. While the Kellerman library is quite affordable (and easy to use), there is an open source alternative on CodePlex called .NET Crypto (Devv.Core.Crypto) as well as Microsoft’s Enterprise library, which include cryptography functions.

Other notes on the code:

If you have a MOSS implementation, you don’t need this class. Microsoft provides an generic LDAP provider with the full server product. This was written for those who only have WSS and need something custom.
The original requirements for this class were for creating a single sign-on environment between an Oracle Portal and SharePoint (sign on to the Oracle portal and get straight in to SharePoint without authentication). As such, I didn’t write any code to handle password changes, resets or other management functions, since those would all be handled by Oracle’s product interfaces.
I’ve only overloaded the bare minimum necessary for the membership provider to work with SharePoint (see above bullet).
The lookup function for users requires exact matches. In hindsight, I could have implemented the query a bit better to improve operation with the People Picker component in SharePoint; I didn’t, but hopefully you will and share it with the rest of us…
This was originally written for WSS v3.0, but there’s no reason, with potentially minor changes, it couldn’t work for SharePoint Foundation (2010). If you get it to work in a 2010 environment, I’d love to see the implementation and hear your experiences.

Click HERE to get a copy of the provider class.

Mastering Workflow Reports in SharePoint 2010

noreply@blogger.com (Shawn) — Tue, 24 Aug 2010 06:08:39 PDT

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.

Managing SharePoint SandBox (User) Solutions

noreply@blogger.com (Shawn) — Tue, 13 Jul 2010 07:51:00 PDT

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

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

Can Search really solve Information “Findability?”

noreply@blogger.com (Shawn) — Sat, 03 Jul 2010 09:59:11 PDT

We’ve all heard the lament from end users and IT professionals alike: “I can’t find what I need in our … [fill in the blank here – network share, intranet, portal, etc].” The reason, virtually universally, is that: 1) there’s an unintelligible organization to the content and 2) using the internal search tool never seems to return the results people need/want. As a result, there’s a growing sentiment that “the solution” is to just get a Google appliance (or other inappropriately expensive search tool) and everything will be fine. It’s worthy of note that this sentiment comes from all levels in the organization – from executive business management to senior IT management and all the way down to the average joe/jane employee (IT or not) - making the statement carry that much more weight.

Interestingly, there’s a certain logic to this statement (perverse though it may be to people who spend their professional careers mired in trying to solve the problem of findability). When most people search for content on the web, they overwhelmingly use Google’s search technology. In my own experience, if the content exists, it’s likely I can find it with Google search. How Google makes is happen is a mix of complex mathematics, massive computing power and (seemingly to me) black magic, since even companies with vast resources invested in bettering search (like Microsoft) have yet to equal Google’s search success. However, isn’t Google’s success also partly due to perception and, frankly, low expectations?

By and large, research suggests that most people “hope” to find content when searching the web. If I execute a query using Google’s search site, I don’t actually know if the content I want exists. I hope that it does and, when I find it, I’m pleasantly surprised. By contrast, when I search for content internally, it’s not a question of “if” the content exist, it’s a question of where. I know that the content lives somewhere inside my … [again fill in the blank – file share, intranet, portal, etc], I just don’t know where.

When I use my portal’s search engine to execute a query, I expect to find the content I want. However, when the content I know exists doesn’t appear in the search results (or doesn’t seem to appear), I get very frustrated (can I get a Marine hoo-rah if you empathize??). If I’m feeling particularly persistent, I may execute another query, perhaps using different keywords, to see if I can find my content in a different way. This second attempt may or may not yield better results. In the end though, my perception is I’ve just wasted a bunch of time and I’m no better off. Worse yet, I have now come to two very harsh, though potentially inaccurate, conclusions: 1) Google rocks and I don’t understand why we don’t use it internally and 2) whatever search technology we are using internally stinks (I’ve heard clients use more colorful language, which I’ll spare you here). Also, and not any less important, I’m very deeply disappointed that I will be spending more wasted energy duplicating an effort to either recreate the content I can’t find or, at least, doing duplicative research to support the work I actually have to complete.

If you’re still reading, I suspect you not only empathize, but are hoping I’ll give you “the solution.” My honest response is that if I had a silver bullet solution, I would probably be very wealthy. I would be cruising the Atlantic on a large yacht, with a drink in my hand and not searching for anything in particular except perhaps the elusive lime to add a little something extra to my libation. Since my reality is that there is no silver bullet solution (and I don’t have a boat), I offer some truisms and suggestions about finding content in your organization and how to make that process better:

Taxonomy is required (really)
If you want people to find content, in any repository, you must (I don’t use this work lightly) apply some sort of organizing principle to that content (“organizing principle” is synonymous with taxonomy). You don’t have to look much further than your physical file rooms (organized alphabetically), biology (order, genus, species, etc – you remember high school biology no?) or virtually any other repository of stuff to figure out that if it’s not organized you’ll have a slim chance of finding what you need. To provide a very concrete example, look at Best Buy’s navigation for a technology category approach that helps you find the product you want; if you can’t find what you want, let it stand as an example of how poor taxonomy can confound someone. That said, I recently had a CIO tell me that he didn’t “get” the value of taxonomy and that we all live in a “search-based world.” Again, though I respect this particular CIO and I get the sentiment, it’s just not reality. You must develop a way to organize your content and make that organization (taxonomy) infinitely clear to the people for whom it will be the path to finding content nirvana. Frankly, not everyone will use search to find content and a poor taxonomy will impact your search tool’s ability to return relevant results.
Google is good, but it’s not likely to work internally
It’s true search technology has improved tremendously. Google is clearly the leader. However, their success is not actually magic and probably won’t translate to internal search success; public search and “enterprise” search are different beasts; Google is very good at public search, but haven’t fared any better than any other search company within the enterprise. Also keep in mind that, Google’s dominance in general public web search stems from a number of factors, most of which do not exist inside of any singular company (a few of those key dimensions are listed here):
- An overwhelming volume of content that can imply topic relevance through cross-linking (keywords in one document and/or site that are linked to other content and/or sites that imply authority for that keyword)
- Massive computing power that can be used to execute complex algorithms (their specific “secret sauce”)
- Search analytics that help create patterns of relevancy based on actual user click behavior (result select or re-query)
- Legions of Google staffers that constantly improve Google’s algorithms over time (based on content data and analytics). Despite what you may have heard about what Google does for a living, it’s all about search (not phones or collaboration software). No other part of their business comes close to generating the amount of revenue (obviously through ads shown with search results) or has the same amount of resources devoted to it.
- Like Microsoft had “help” from IBM becoming a dominant player in the PC operating system business, Google had a similar giant help them early on – Yahoo. When Yahoo was the most popular site on the web, guess what search technology they used? That deal made it much easier for Google to supplant their patron, in later years, as the leader in search.
Search is not the exclusive answer to findability
Even if someone could create the perfect search engine that returned very precise and relevant results, why do you want to force your user community to execute a search just to find content? Doesn’t the mere act of search introduce yet another set of clicks and keystrokes? Isn’t the goal to “get there in less than two clicks” and “provide answers quickly?” Think about your own experiences with search. How long does it take to formulate the appropriate query? To review the results? To find the right result, click on it and validate it’s actually what you want? Wouldn’t it be easier to create a very clear path to the right content? Better yet, don’t you already know a good deal about your employees and couldn’t you predict at least some of their content needs? If so, why not just surface that content on the home page of your portal (or other appropriate location)? Better yet, wrap those items in an RSS feed and deliver them through a desktop gadget (works on both MACs and PCs). Do you think I’m crazy? This technology surely couldn’t exist you say (or it’s too complicated to implement). Have you ever visited your iGoogle page? Have you ever ordered anything from Amazon? These sites aren’t doing anything that revolutionary in the year 2010. They’re simply using data they already know about you to automatically find what might be relevant (or asking you to choose topics for the taxonomy that you are interested in viewing). Is it perfect? No. Does it save time in the long run? Absolutely. Does it provide you a somewhat “searchless” content findability experience? You bet. Could you still supplement this approach with a search tool? Of course.
Successful search experiences require constant work
Just because you spun up a Google appliance, SharePoint search (or FAST) or implemented Autonomy, you’ve only just begun. Like anything else in this world, success comes from discipline, dedication and an ongoing effort to ensure success. Search is no different. More than one of our clients has called and asked for our help in improving their search experience. Unfortunately, virtually all of them have done next to nothing, beyond installing the software, to make search work properly. Whether it’s not excluding common navigation items on a web site (the same navigation shown on every page messes with relevancy for those keywords), avoiding the application of metadata on documents (like no title or descriptions – not even counting the “fancy” stuff like author, department, main topic area) or leaving patently irrelevant content in the repository past it’s expiration (like the snow day policy from 2001 that for some crazy reason is the most relevant document when using “snow policy” as a query), clients frequently thwart their own best intentions. To make search work, you must do a bare minimum, like excluding content that should never be a result (like a home page), apply metadata with appropriate values, perform periodic “gut check” searches that should yield consistently relevant results and monitor the behavior of your users by actually looking at analytic data (you’d be surprised how many queries return zero results or where no one clicks on a result). If you just do this minimum, your search experience will dramatically improve.

If I’ve prattled on too long in this post and you’ve missed my point about findability, here’s the short version: search is not the exclusive answer to finding content; you must start with a taxonomy that everyone understands (and fits your content), implement search properly and monitor progress (making changes when necessary). Anyone who says differently is either selling a search tool or has been sold a bridge in Brooklyn.

Does SharePoint Destroy Intranet Design?

noreply@blogger.com (Shawn) — Mon, 07 Jun 2010 13:09:46 PDT

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.

Inserting Arbitrary Links in a SharePoint Calendar

noreply@blogger.com (Shawn) — Tue, 11 May 2010 08:09:52 PDT

Some time ago a client hired us to build a custom web part that, among other things, would color code events based on a category assigned to an event, embed an “information” link into each date of a 30 day calendar view and provide a printable view for a specific month. At the time, SharePoint 2007 was relatively new, as an organization Consejo had been building custom extensions for SharePoint 2003 for some time and it just made sense to continue down the path of a custom web part. Interestingly, the task of build a custom calendar web part that would properly display events in an event list is harder than you might think (another story).

First, I would always recommend trying to buy before building; as a developer it’s tempting to build, but usually less expensive long-term to buy. And, while there were at least one or two commercial web part options that provided color coding (Bamboo’s calendar plus web part was something we seriously considered), nothing gave our client the ability to embed their information link. The goal for this link was to create a “light” integration between the SharePoint event calendar (where they posted all of their corporate events) and a 3rd party application that would display information related to catering for that date. Essentially, when you clicked the information link, a new browser window opened to the URL of the event application with the date associated with the specific icon the user clicked. Pretty simple and easy.

After a far-too-long development cycle to complete, the web part has been generally working within that client’s environment for some time. However, they recently approached us for an update. The request kicked off another round of investigation and an epiphany of sorts.

While attending SharePoint Summit 2010 in Montreal, I had the good fortune of attending Mark Miller’s (End User SharePoint) session on enhancing the SharePoint interface through jQuery. Coincidentally enough, very little of Mark’s talk was about jQuery specifically, though he did share a few examples. What he did show were numerous ways that you could manipulate the standard SharePoint interface using other JavaScript bits, including color coding a calendar, creating a printable interface and creating a tabbed interface. Many of these scripts were developed by Christophe Humbert from Path to SharePoint.

After attending the session, trying the color coding script myself (really a combination of a calculated column and JavaScript) and seeing the possibilities, I decided to try my hand at recreating the custom web part we developed using just JavaScript and calculated columns. While Christophe’s approach helped with the print view and the color coding, he didn’t have an example for the information link. Fortunately, a little experimenting on my part produced the script shown below.

<script type="text/javascript">
/*
Insert the event icon script
Written by Consejo, Inc.
Questions: info@consejoinc.com
*/

var iterator = document.getElementsByTagName("td");   
try 
{   
  var i = 0;
  var thisNode;
  while (i<=iterator.length - 1 && iterator.length > 0) 
  {   
    thisNode = iterator[i];
    var moreNodes = thisNode.getElementsByTagName("div")
    if(moreNodes != null && moreNodes.length > 0)
    {
        for( var x = 0; x < thisNode.attributes.length; x++ ) 
        {
            if( thisNode.attributes[x].nodeName.toLowerCase() == 'class' && (thisNode.attributes[x].nodeValue.toLowerCase() =='ms-cal-topday' || thisNode.attributes[x].nodeValue.toLowerCase() =='ms-cal-topday-today')) 
            {
                try
                {
                    var onClickEvent = thisNode.getAttributeNode('onclick').nodeValue;
                    var origEventDate = onClickEvent.substring(16,37);
                    var cleanUp = new RegExp(/^([1-9]|1[012])+\\u002f+([1-9]|[12][0-9]|3[01])+\\u002f+\d\d\d\d/);
                    var cleanEventDate = cleanUp.exec(origEventDate)[0];
                    cleanEventDate = cleanEventDate.replace(/\\u002f/g,"-");

                    moreNodes[0].innerHTML  += "<a href=\"http://www.videodetective.com/dvdcalendar.aspx?week=\"" + cleanEventDate + " style=\"font-size:8px;position:relative;right:-45%;\">Event Info</a>";
                }
                catch(err){}
            }
        
        }
    }
    i++;
  }
}    
catch (e) 
{   
  alert( 'Error: ' + e ); 
}

To implement this script, simply copy and paste this JavaScript into a Content Editor Web Part loaded after the calendar view web part. If you want to enhance the link, simply insert an IMG tag where the text is shown.

The link in the script is to a site that shows what DVDs were released on the date extracted from the SharePoint calendar’s onClick event; a little regular expression work helps to extract the value provided by SharePoint. Obviously, you should change the URL in the script to something that meets your needs, unless you really want to know what DVDs are to be released.

I very much want to thank both Mark and Christophe for demonstrating a very light-weight approach to adding new functionality to the SharePoint interface. Next time, I’ll think twice about writing mountains of C# when trying to achieve a client’s goals.