Making Sense of the SharePoint World

Dec-282009

Looking Back on 2009

The Obligatory Year-end Report

It is now the last week of December, and you know what that means. Lying in wait among the crumpled wrapping paper, danced-out sugarplums, and pine needles (not to mention the feathers and other "presents" from all those birds your true love gave to you) you'll find year-end wrap-ups from every corner imaginable.

This is mine. :) I'll get to the more general stuff in a moment, but there was one personal SharePoint-related thing that stood out for me in 2009, and that happened the very first day.

I Became a Published Author

While I (along with Asif and Bryan) did all of the work in 2008, my book Professional Microsoft Office SharePoint Designer 2007 was officially released by Wrox Press on January 1st of 2009 (December 31st, 2008 in some markets). I'm honored by the very positive reviews, and want to thank everyone who has purchased it.

Ironically, its importance is going to continue on into 2010, and possibly beyond. While SharePoint 2010 is top-of-mind for many people right now, the fact is that SharePoint 2007 is going to be around for a long time to come. But, SharePoint Designer 2010 cannot work with SharePoint 2007 sites, so SPD 2007 will still be needed if you want to customize older SharePoint sites. Since SPD is now a free download, there isn't much in the way of printed documentation, other than (you guessed it) third party books - like mine.

The Year of the "Community Conference"

One amazing thing that stood out about 2009 was the popularity of independent SharePoint-related conferences and seminars. I personally presented at two - the "Best Practices SharePoint Conference" in San Diego, and the "SharePoint Technology Conference" in Boston.

But the big trend was the emergence of the "SharePoint Saturday" mini-conferences. These are one-day, free to attend conferences, that are held all over the world. Here you will find breakout sessions by the very same experts that present at the larger venues, like Tech-Ed and the official Microsoft SharePoint Conference. Check out the SPS site, and plan to attend one of these events near you!

And, of course, no mention of the "Community Conference" would be complete without mentioning the "Conference Community" on Twitter. This is a bit less formal, but essentially you will find a play-by-play for almost every conference being happily tweeted by the attendees with hash tags like #SPC09, or #SPSINDY.

SharePoint 2010

Of course, the big news was the announcement of Office and SharePoint 2010, and the availability of the public beta. The official release is currently set for the "first half" of calendar 2010. As many articles have pointed out already, much has changed. There will probably still be some significant changes between now and the final release, though what they might be, nobody can say.

Other Significant Events

Some of the other SharePoint things that happened to me in 2009

I became Michael Gannotti's very first "Backseat Driver"
I was once again awarded as a Microsoft MVP for SharePoint Server
I autographed and gave away almost 500 copies of my book while working the Microsoft Technical Learning Center booth at Tech-Ed in Los Angeles

SharePoint, the Target

No post about SharePoint in 2009 would be complete without some mention of another buzzphrase that started appearing in 2009 - "SharePoint Killer". Almost every new application that had the slightest thing to do with collaboration or content management seemed to earn headlines of "Is X the Next SharePoint?" or "Y will make SharePoint Obsolete". From Google Sites to Google Wave. From Drupal, to Alfresco, to the classic DotNetNuke. Yet while each may have one area where it shines, none of them really has the versatility or power to match SharePoint, assuming they are even truly comparable.

Blog Highlights

For those of you new to my blog, here are some of the articles I wrote this year that you might find particularly interesting:

Looking Ahead

With the planned official release of SharePoint 2010, 2010 the year looks like it will be just as exciting as 2009. One thing that is very clear is that Microsoft is putting a lot more effort into the supporting infrastructure for SharePoint. From native support in Visual Studio, to online documentation, to partner training.

While people may have been shocked by SharePoint's meteoric rise, nobody is going to be surprised by its continuing momentum.

Published: Dec-28-09 | 1 Comment | 0 Links to this post
Tagged as: General, Office 2010, SharePoint, SharePoint 2010, SharePoint Designer, Wiki

Apr-142009

Wiki-in-the-Box - Is SharePoint Wiki Really that Bad?

Today I'm going to get off the SharePoint Designer shtick, and go back to SharePoint basics. In particular, I want to take a closer look at SharePoint's built-in wiki functionality.

SharePoint's wiki has taken a lot of grief online lately. Some people look at various dedicated wiki systems, then at SharePoint, and come to the conclusion that SharePoint's wiki just doesn't measure up to the "best of breed". There is a big difference, however, between "not the best" and "totally inadequate".

The Real Question

If you use SharePoint in your company, and are considering whether to purchase a third-party wiki replacement, the question you really need to ask isn't, "Is SharePoint's wiki the best there is?", but rather "Will SharePoint's wiki do the job I need done?"

To help you answer that question, we'll take a look at what a wiki is, what you might want it to do, and what SharePoint's Wiki offers "in the box" to answer those needs. I'll also check out what simple enhancements are available (both within SharePoint, and via add-ons) to extend that built-in functionality.

Just What is a Wiki, Anyway?

Creating pages for the web has historically been a complicated process. It required page creation and editing on a client computer (usually with a specialized tool), and then uploading the finished pages to the web site. Linking required knowing where the target pages were going be relative to the current page.

Wiki-wiki is Hawaiian for "quick". The first wiki was designed to make it quick and easy to create and edit web pages, as well as the links between them. Rather than force users to understand HTML markup, and site structure, a wiki lets them create a link, and if the target page doesn't exist, it will be created automatically when the link is clicked for the first time. Combined with in-place editing, this effectively makes a wiki a form online content management system.

As noted earlier, a user doesn't need knowledge of HTML markup to use a wiki. However, because wikis historically have used plain text boxes for entering content, over time conventions have developed for a "wiki markup" for such things as bold and italic text, intra-page section headings, etc... I'll talk about this in more detail in the next section.

Note: WikiWikiWeb, the software created by Ward Cunningham for that first wiki, used a different syntax from most modern wikis when it comes to links. WikiWikiWeb used compressed text (i.e. Leading-cap words with no spaces between) to indicate text was a link. Current wiki markup convention calls for intra-site links (also known as wiki links) to be defined with [[double square brackets]].

In addition to being quick and simple, there is another, non-technical, aspect to a wiki - something of a "wiki philosophy". This philosophy holds that a wiki should be open to modification by anyone who has something to contribute - even anonymously. Most public wikis hold to this philosophy, however it is not without its problems. For example, while the desired benefit - people with actual knowledge of a subject contributing and correcting inaccurate information - is clearly achieved, it is just as easy for others to post deliberately incorrect information, or even vandalize sites.

While such defacement is just as easily corrected, most modern wiki systems do incorporate certain safeguards - such as authentication, change logs, and approval processes - which can be implemented at need. Indeed, even WikiPedia, the most prominent wiki site on the internet, treats authenticated and anonymous contributions differently, and allows article (page) creators to prevent anonymous edits.

SharePoint Wiki - On the Surface

Now that you know basically what a wiki is, and how they were created to make it easy for non-technical users - and particularly subject matter experts (SMEs) - to create and manage web content, let's take a look at a SharePoint wiki site.

Note: SharePoint has two things called "wiki". The Wiki Library, and the Wiki Site template. A Wiki Library can be created on almost any SharePoint site, and is accessed through quick-launch just like any other SharePoint list or library. When you create a Wiki Site, a Wiki Library is created in it automatically, the site is set to use the Wiki Library's home page as its default, and a Wiki Pages section is created in the Quick Launch bar. The behavior of the Wiki Library itself is otherwise identical.

In most respects, a SharePoint Wiki is very similar to any other SharePoint site, as shown below. However, when you look a little closer, you start to see some differences:

Wiki Toolbar - The wiki toolbar gives you direct, 1-click access to editing a page, viewing its change history, or discovering what other pages in the wiki link to it.
Quick Launch Bar - Notice the Wiki Pages section. This is created in a Wiki Site only. Other "normal" sections (e.g. Lists, Discussions, etc...) are generated as needed if you add them to the site. On non-wiki sites to which a Wiki Library is added, this section is not created automatically.
Recent Changes Bar - The Recent Changes bar lists the last five pages that have been updated.

Whether stand-alone, or part of a wiki site, two pages are created by default in a SharePoint wiki library - the Home page (shown above), and "How to use this Wiki" (the text varies slightly to reflect the library or site context). While wikis, by definition, are very easy to use, a quick glance through the "How to" page can still be very helpful. It provides quick tips on the two elements of a SharePoint wiki that are not "obvious", especially to new users - the [[double bracket]] wiki link syntax, and how to create new pages.

To help prevent the creation of orphan pages (those with no incoming links), users are encouraged to grow the site organically, by editing an existing page and adding wiki links. Recall that, if you create a wiki link to a page that doesn't exist, a new page will be created when that link is first clicked.

Getting Started

The first thing you will probably want to do, is edit the home page to reflect your purpose in creating the wiki site, and create some "seed" links to get your users started.

Notice how I have "set the stage" for my users. I haven't actually entered any information yet, but by creating these links and a description, I have let people know the purpose of this site. Now, anyone with write permission can click on one of the links with dashed underlines, and they will be able to create content.

Which brings us to the first area of concern in many environments - if "anyone" can go in and modify these pages, what if someone totally messes things up? This is where the page history comes into play. By clicking the History button in the wiki toolbar, I can easily see what changes have been made over time. For example, in the screenshot below, you can easily see the changes I have made to the home page from the default, with added and deleted text highlighted in different colors from that which was unchanged:

Because in most environments SharePoint is used with authentication, you will know not only what changes were made, and when, but by whom.

The Editing Experience

One of the complaints often leveled against SharePoint's wiki is its lack of support for "wiki markup" beyond intra-site page links. While this is true as far as it goes, it doesn't consider what that markup is designed to do - compensate for the plain-text editing features of most wiki systems. For example, to make italic text in many wiki systems, you enclose the text in ''double apostrophes''. Yet while there are some conventions, there is no true "wiki markup" standard.

Here is an example of the page editing experience in a SharePoint wiki:

Notice that SharePoint's wiki actually provides a full rich-text editor, with direct toolbar-based access to text formatting, external hyperlinking, etc... The results from these tools are stored as standard HTML markup. This strongly mitigates the need for specialized wiki markup beyond the already included internal linking.

Note: Out of the box, the rich-text editing experience is only provided for users of Internet Explorer. If you have many non-IE users, I strongly suggest that you download and install Telerik's RadEditor Light. This is a free tool, the use of which is fully supported by Microsoft. I have provided a detailed write-up of it in an earlier blog post. Even if you do use IE, RadEditor Lite provides many other features that are particularly useful in a wiki environment.

Digging Deeper

So, looking at the "wiki" features of SharePoint's wiki, we see a very easy to use system, which, while it may not offer everything a competitor's wiki has, isn't too bad. But the story doesn't stop there. The other side of the "SharePoint Wiki" equation is SharePoint itself. As a part of SharePoint, the wiki library comes with a number of very useful capabilities, especially around site management.

Much of the "SharePointiness" of the wiki library is suppressed from the default page views. Nevertheless, it is in there, just below the surface. The easiest way to access it is to click the "View All Pages" link in the Recent Changes bar. This brings up a standard SharePoint view of your wiki library:

From here, you have access to all sorts of abilities:

Setting Alerts to be notified of changes
Setting the permissions of the library, or even individual pages
Adding metadata fields - for example, subject tags, or even links to supporting documents
RSS feeds
Requiring approval and document check-out for changes.
Creating different views of the information

In addition, because wiki pages are considered individual files by SharePoint, they have individual URLs, making it easy to provide "friendly" links to users, as well as get detailed usage reports.

Because a wiki page is a "page" in SharePoint, you have a second editing option, under the Site Actions menu. This edits the SharePoint, rather than Wiki aspects of the page, and allows you to add web parts to a page in your wiki. These parts will only appear on that specific page, but can be used for virtually any purpose. For example, here I've added a web part that is a view of the wiki library which displays a page preview when you roll over a title:

Content in a SharePoint wiki is also automatically included in SharePoint searches, making it easy to find information even if you don't know exactly where in the wiki it is.

Conclusion

SharePoint's wiki features are a bit like Rodney Dangerfield - they "don't get no respect". Yet, while on their own they may not be best-of-breed in the wiki world, they are still quite useful. In addition, they do something no other wiki system does, they bring the rest of SharePoint, with all of its power and flexibility, along for the ride.

If you are considering deploying a wiki in your company, and you are already using SharePoint, look beyond what a wiki purist might see as perfection, and consider your actual needs. You will probably find that SharePoint's wiki will fulfill them.

Published: Apr-14-09 | 2 Comments | 0 Links to this post
Tagged as: General, Governance, Wiki

Jan-142009

Press F1 - SharePoint Help is on the Way

Giving Your SharePoint Users Site-Specific Online Help

"Press F1 for Help" has been ingrained into the psyche's of PC users since even before Windows. OK, WordPerfect users originally had to press F3 instead, but the concept is the same.

In any case, SharePoint allows you to take advantage of this convention through its page event model. Page-level scripting in SharePoint has received a big boost in attention recently. Ever since Microsoft has announced its endorsement of JQuery in Visual Studio, articles are popping up all over as people learn to leverage this new framework. This is not one of those articles.

Introducing the WPSC

Instead, this is about one use of a component that has been a part of SharePoint (under various names) since it was called the Digital Dashboard Resource Kit - The Web Part Page Services Component (WPSC). I devote a whole chapter in my book to using this and other client-side components, but briefly, the WPSC is a set of JavaScript objects and functions that allow Web Parts to communicate with SharePoint, each other, and your users.

One of these functions allows you to register for events. These events can be defined in other Web Parts, or pre-defined by SharePoint. This example uses one of the pre-defined events - "onhelp". In essence, the WPSC watches for users to press the F1 key, and then raises this event so that any interested components on the page can respond to it.

Making it Happen

In general, working with a WPSC event requires two things:

Registration for the event
A function to execute when the event is raised (this is called an "event handler" or a "callback function")

For a help function, you will also want a page to contain the help information. You can create this page any way you like, but you might find it useful to make a Wiki Library for your help files. This makes them easy to update and expand as needed. For purposes of this example, let's assume you have a Wiki Library called "MyHelpLib", and the primary help page for this topic is "MyHelp.aspx".

The first thing you need to do is add a Content Editor Web Part to your page. From the Site Actions menu, select Edit Page:
Select a Web Part Zone, and cick the Add a Web Part link.
From the Add Web Parts dialog, select the Content Editor Web Part, and click the Add button. (It will probably be in the "Miscellaneous" section)
Once the part is added, click the "open the tool pane" link in the part:
Instead of clicking the "Rich Text Editor" button, we're going to click the "Source Editor" button.
The Source Editor is just a text entry window, with a Save and a Cancel button.
The code shown in the screen shot is correct, but here it is in plain-text form, which you can copy and paste into your text-entry window: <script language="javascript">
function showMyHelpPage() {
window.open('/MyHelpLib/MyHelp.aspx','MyApplicationHelp')
}
WPSC.RegisterForEvent("urn:schemas-microsoft-com:dhtml","onhelp",showMyHelpPage);
</script>
Click Save.
There is one more change to make before we're ready to exit edit mode. So that this web part doesn't show up on the page, you want expand the Appearance section of the task bar, and change the the "Chrome Type" to None.
Click the Apply button, and the Exit Edit Mode link.

At its most basic, that's all there is to it! Pressing the F1 key on your page will now summon the help page you defined.

Taking it Further

Of course, that doesn't prevent you from getting even fancier. For example, you may want to set some parameters so your help window is a certain size, and centered on the screen. Once you have the basics set up the way you like them, you could export the Web Part to a .DWP file, and add it to the site's Web Part Gallery. Or, instead of using the script in a Web Part, you might put it into a master page, so it is available throughout your site without further intervention.

The following script is one you might place in shared Web Part or a master page. It adds the formatting parameters, but it also uses a variable for the "help context".

This myHelpContext variable allows you to override which page is displayed by setting it on individual pages. In a web part, you just edit the myHelpContext variable for the page you are on. If the main script is embedded in a master page, you would just add a Content Editor Web Part (as described above) with a very short script block:

In either case, pressing F1 gives that page's help.

Conclusion

In this article, I have given you a taste of the power available to you with the SharePoint client-side scripting model, and the Content Editor Web Part. We used the event model to provide traditional, F1, Help to your users. But the Web Part Page Services Component (WPSC) gives you access to many other functions as well. You can find many of them documented in the Windows SharePoint Services SDK, and you can see more examples of how to use them in my book. I hope you will take this to heart, and discover even more ways of using the SharePoint client-side programming model!

Published: Jan-14-09 | 3 Comments | 0 Links to this post
Tagged as: Customization, Design, Programming, SharePoint, SharePoint Designer, Training, Wiki, WSS

Dec-82008

Cross-browser Rich Text Editing and More in SharePoint

"It's not just for Firefox anymore"

Today I'm going to talk about one of the earliest enhancements that was available for the current release of SharePoint. It has been around for so long, that it has either fallen off folks' radar, or has never made it onto the screen for newer users. That's a little sad, because it has always been a very useful component, and in its latest release is even more so. What is this magic add-on? The Telerik RadEditor Lite.

Considering the complexity of the markup SharePoint generates, its out of the box cross-browser compatibility (though not perfect) is pretty good. One area of weakness for non-IE browsers, however, is rich text editing. Recognizing this, Microsoft came to an agreement with tools vendor Telerik, whereby they would produce a version of their RadEditor that could be downloaded and used within SharePoint sites - without cost, and without sacrificing supportability. (They had a similar deal for Content Management Server, or CMS.)

That was the state of affairs in 2007, which is all well and good. But, time marches on, and it is almost 2009. If you are new to SharePoint, or if that early release was the last time you evaluated (or updated) the RadEditor Lite, you could be missing out on some nice improvements that go beyond cross-browser compatibility.

Note: Almost everything in this article applies to all "rich text" experiences within SharePoint, from Announcement lists, to MOSS Publishing Pages (the original purpose). I'm going to be using a SharePoint's Wiki here for two reasons:

Wiki pages, by default, are basically one big rich text field, making screen shots easy to get and understand.
One of the primary complaints about the SharePoint Wiki feature is that it is too hard for users to incorporate images into their pages. As you will see, the RadEditor Lite makes this problem go away.

The Basics

Consider the default SharePoint experience. For most users, just browsing the site, things are pretty consistent, regardless of whether you are using Internet Explorer (left) or Firefox (right):

(Click on the image to see the full-sized screen shots, if desired.)

But click the "Edit" option, and you can see the problem -

In IE, you get a traditional editing toolbar, and everything looks pretty much like it does on the read-mode page:

But in Firefox, all you see is plain text, with embedded HTML markup:

Not exactly the experience you want for a typical, non-technical, user - the kind that Wikis were intended for.

Installing the RadEditor Lite Control

The first step, of course, is to download the control from Telerik's web site. It isn't exactly high-profile for them these days, so you'll either have to dig for it, or just follow the download links I've provided on this page.

That that will get you is a ZIP file containing an EULA document, the solution package (RadEditorMOSS.wsp), and a very extensive help file. Since I'm not going to go into all of the customization details possible with this control (and there are a lot of them), you might want to keep this in mind.

This control does not provide an automatic installer, so you will need to manually add the solution to your farm.

Extract the WSP from the ZIP file
Add the solution to SharePoint:
stsadm -o addsolution -filename {path you extracted to}\RadEditorMOSS.wsp
Deploy the solution to the web applications where you want to make this control available. You can do this either through the Operations tab of Central Administration, or by using the STSADM command with the deploysolution operator.
Note: This solution is deployed on a per-web application basis, not farm-wide.
Activate the feature on the web sites where you want to use the RadEditor Lite.

Notice the granularity allowed in the deployment. The feature activation itself takes place at the Site, rather than Site Collection level. You also have two options for activation:

Use RadEditor to edit List Items
Use RadEditor to edit List Items in Internet Explorer as well

Once you have activated the first feature, you will see that FIrefox now shows a much richer editing experience, complete with all of the expected toolbars:

If you using RadEditor Lite on MOSS, you're done! Maybe (see the next section). If you are using it on WSS, there are a couple more steps to perform on your server. This is because, by default, the RadEditor Lite relies on some controls that are part of MOSS. However, it does have its own built-in controls that perform similar functions, so you just need to adjust an XML configuration file. (You can use RadEditor's native controls on MOSS, too, by making the same adjustments.)

The XML configuration file is usually located at:

c:\Program Files\Common Files\microsoft shared\Web Server Extensions\wpresources\RadEditorSharePoint\4.5.4.0__1f131a624888eeed\RadControls\Editor

"4.5.4.0__1f131a624888eeed" above is the version of the control you are using, and so may vary.

You need to edit the file named "listtoolsfile.xml"

Find the line

and edit it to remove "MOSS", resulting in a tag reading:

I would also add one of the following lines:

The tool provides spell checking, so why not use it?

Progress is Progressing

There are a couple of questions you might be asking yourself at this point:

Why are there two separate activation options? and
Why would I need to use this control in Internet Explorer, when it already supports rich text editing?

The answer to the first question is this - when the free RadEditor Lite was first released for SharePoint, it was officially licensed for one purpose - to provide rich text editing to non-Internet Explorer browser users in MOSS Publishing sites. That is because the agreement with Telerik was carried over from a similar agreement relating to Content Management Server (CMS), and MOSS Publishing was the direct replacement for CMS functionality. It wasn't until much later that the agreement was expanded to allow use on WSS and for non-Publishing scenarios in MOSS. The original activation option allows for full compatibility with the pre-expansion scenario, while the second activation allows for the answer to the next question.

The second answer has a few different facets. The first is simple consistency. You may have noticed from the screen shot that the RadEditor uses the browser's default font, rather than the SharePoint styled font. By using the RadEditor in IE as well, you get the same experience for your users, even if it isn't "perfect".

The other piece is related to the spell-check activation I advised above. Even though it is limited compared to their paid version, the RadEditor Lite has a lot of features the default SharePoint rich text editor doesn't provide. By activating the component for Internet Explorer, you gain access to all of these features. Spell checking is just one of them. Another is that its tools for inserting tables and images are much richer. Look at the comparison below of the Image insertion dialog.

First is the default SharePoint's. You can type in a URL to an image, and enter an alt tag. That's it.

Now look at the RadEditor's image manager:

Not only do you get an easy browser, including image preview, notice the "Upload Image" tab. That's right, you can upload images to your site while editing a page! Besides cross-browser editing, Image management and spell checking have been some of the biggest complaints about SharePoint wikis, and the RadEditor Lite makes them all obsolete.

Summary

The Telerik RadEditor Lite is one of the oldest free add-in components available for SharePoint. It is also a very mature product, which has gone through a number of revisions over the years. It offers a lot of functionality to SharePoint users, developers, and administrators, no matter what the browser. Not only that, its use is fully endorsed by Microsoft. (See the SharePoint and ECM Blogs.)

Who could ask for anything more in a free download?

Published: Dec-08-08 | 5 Comments | 0 Links to this post
Tagged as: Administration, Customization, Design, Governance, Lists and Libraries, SharePoint, Wiki, WSS

Woody Windischman - The Sanity Point

Search

Categories

Links

Blog Roll

Archives

Making Sense of the SharePoint World

Looking Back on 2009

The Obligatory Year-end Report

I Became a Published Author

The Year of the "Community Conference"

SharePoint 2010

Other Significant Events

SharePoint, the Target

Blog Highlights

Looking Ahead

Wiki-in-the-Box - Is SharePoint Wiki Really that Bad?

Wiki-in-the-Box - Is SharePoint Wiki Really that Bad?

The Real Question

Just What is a Wiki, Anyway?

SharePoint Wiki - On the Surface

Getting Started

The Editing Experience

Digging Deeper

Conclusion

Press F1 - SharePoint Help is on the Way

Giving Your SharePoint Users Site-Specific Online Help

Introducing the WPSC

Making it Happen

Taking it Further

Conclusion

Cross-browser Rich Text Editing and More in SharePoint

"It's not just for Firefox anymore"

The Basics

Installing the RadEditor Lite Control

Progress is Progressing

Summary