"You Are Now Free to Upgrade Your Servers..."

Several weeks ago, Microsoft released Service Pack 2 for SharePoint. It was great! SP2 fixed many problems, large and small, as well as introduced a feature to scan your environment for potential upgrade issues.

There was just one problem. If you were running anything other than plain Windows SharePoint Services (WSS), SP2 would trip an expiration flag that made your computer think you were running an evaluation version. For many users this was just a little inconvenience. You could simply re-enter your product key, and the timeout would be removed. Unfortunately, users of Microsoft Search Server 2008 Express (MSSX) were in a pickle. For you see, MSSX doesn't have a license key.

Of course, MSSX user or not, Microsoft didn't plan for SP2 to do this. So they have been working diligently to come up with a patch to resolve the issue. As of last night, that patch has been released. You can read about the details, and/or download it, on the SharePoint Team Blog, or KB Article 971620.

So, install the patch, apply Service Pack 2, and the April 2009 cumulative update package, and you'll soon be SharePoint-ing your way into the future!

A Taste of "Professional SharePoint Designer"

I am pleased to announce that Microsoft has posted two chapters from "Professional Microsoft Office SharePoint Designer 2007" on MSDN. This is the book I spent the better part of last year writing, along with Asif Rehmani and Bryan Phillips. In the approximately six months since its release, Pro SPD has received excellent reviews, now you can see why for yourselves with the following chapters:

Chapter 11: Advanced Data Access: External Data and More

Chapter 15: Creating Workflow Elements in Visual Studio

These two chapters give you a taste of the breadth and depth you will find in the book, including creating views of complex hierarchical data from Web services, and how to extend the power of SharePoint Designer's workflow capability with custom Actions.

Now that Microsoft has made SharePoint Designer available as a free download, having good documentation available is even more important than ever. I'm sure once you have checked out the samples, you're going to want to buy the rest!

Congratulations! You've found my new site.

This article is just a place-holder while I'm waiting for DNS to update world-wide. Then I'll be able to update my RSS feed and get back into the swing of things. Until then, I've copied over most of my articles (even with their original publish dates). I'm still updating tags, my blog roll, etc... so you may see some more changes in the left column, but the main stuff is all here.

Enjoy!

Getting Ready to Move...

I've always been a proponent of sites about SharePoint using SharePoint for hosting whenever possible. In fact, The Sanity Point was hosted on SharePoint for a long time. A few months ago, though, I moved my site onto Office Live hosting and started using Live Spaces for my blog.

Now, Office Live is (sort of) based on SharePoint. The problem is, on OL, I don't have full access to the SharePoint functionality I want. For example, it doesn't include SharePoint blogging, hence the Spaces-sourced blog.

Now I'm getting back on SharePoint. I've got my host, and I'm starting to get things set up the way I want them. So, watch this space! Something new is on the way...

What a Week! - A Tech-Ed Wrap-up

Microsoft Tech-Ed North America 2009 is over, and despite the economy, it was another great show. I spent most of my time in the Technical Learning Center, or TLC, answering questions about SharePoint.

Most days I also, along with co-author Asif Rehmani, gave away and autographed dozens of copies of our book, Professional Microsoft Office SharePoint Designer 2007. All together, we (well, Microsoft) gave away almost 450 books. I want to take this opportunity to thank everyone who stood in the long lines, braving attacks by the flying monkeys, for their support and interest.

Speaking of flying monkeys, these were probably one of the most popular SWAG items at the show...

They came with three costume colors, Red, Black, and Blue. But their main claim to fame was that their arms are elastic, and when stretched and released, not only do the monkeys "fly", they also scream (don't worry, I'm a fan of the "silent" web - no sound effects will disturb your office here!)

The Big Announcements

Though you may have seen these before, no show report would be complete without the big Tech-Ed announcements:

• It is official - Microsoft SharePoint Server 2010 (no "Portal" or "Office" in sight) will be 64-bit only all the way through the stack. You will need to be running 64-bit Windows Server 2008 or Windows Server 2008 R2 in order to install it (no 2003 allowed). In addition, you will need 64-bit SQL Server (2005 or 2008) as well.
• All TechEd attendees will be included in a (semi?) private Technical Preview of the Office 2010 client applications.
• There will be a SQL Server 2008 R2
• Windows Server 2008 R2 is also 64-bit Only.
• The Groove 2010 client has been renamed SharePoint WorkSpace 2010. I'm not sure whether it is an attempt to pick up on the glow of the SharePoint brand, or there is some seriously tightened integration coming, but I'm looking forward to finding out!

So the watchword is, no more SharePoint installs on Windows Server 2003 or using 32-bits. Stop Now. Do it right, and save yourself the grief when the new version comes along.

Discovering the Setup User Account - A SharePoint "Whodunit?"

It was a dark and stormy night. There were SharePoint problems in The City. Lots of them. And it was my job to track 'em all down. I'm a consultant. No problem is too big or too small. It's what I do.

This is the story of one of those problems...

I was hard at work at my desk when the phone rang. Even before he told me, I could tell from the sound of the caller's voice that he had a big problem. His name was Steve. Not the problem - the caller. Turns out Steve's SharePoint guy, Ben, was on the lamb. Ben ran into some Girl Trouble, you see, and he wasn't coming back. Now all Steve had was a SharePoint farm, a scrap of paper, and some half-linked wiki pages.

While I couldn't do anything about filling out his content, at least he used a SharePoint wiki, so his users could pick up the slack there.

I turned my attention to the only clue - that scrap of paper. Turns out, it had a hand full of account ID's written down. It didn't take a genius to figure out that these were the accounts he used when setting up his farm. There were more than three of them, and it was good. Unfortunately, these were all code-name accounts like s23365, and k45321. No way to tell which account was which. That was bad. For all we knew, Ben had used the same account for all three of the major functions (Setup User, Server Farm, and Content Access). Or maybe they were all individual service accounts, and he had been logged in with his own account when he set up SharePoint.

The Big Deal

Why is this so important, you ask? Well, if you've read "Taking Accounts into Account", you'll know that the Setup User has special status - essentially this ID has full control over the SharePoint installation, even if you take it out of the administrator groups. Generally, it is also a good idea to use this same ID when update time rolls around.

The problem is, there is no way to tell directly which account was the Setup User. Sure, you can tell what accounts are used for the services, and Default Content Access is particularly easy, just go to the Search Administration page. But although you can see the accounts in the Farm Administrators group, as noted above these can be changed, so that doesn't necessarily tell you who did the setup.

It was time for the thinking cap. Brainwaves are generated by caffeine and sugar, so I sent Steve for some coffee and donuts while I hashed things out. Since SharePoint wasn't going to help me here, I had to go outside the box. Or rather, straight to the box. I harkened back to my Windows admin days, and thought about what is actually happening when you install software. Registry changes, folders created, files copied, etc...

Chasing a Wild Goose

Half a cup of Columbian and a French cruller later, I thought had it. Files! Folders! When you install a program - especially one as big and powerful as SharePoint, you are creating files left and right. When you put a file into Windows, loads of information about it gets stored - its name, when it was created, and who has access to it. But more than that - Windows "knows" who created the folders and put the files in them.

I started looking in the same place you look for almost anything related to SharePoint configuration. An infamous little hangout called the 12 hive. So I started Exploring. I followed a sort of convoluted path - "C:\program files\common files\microsoft shared\web server extensions", but in the end, I found what I needed. And there was my witness - an unsuspecting little folder, called simply "12". Sure, she was cute, but I knew under that simple yellow exterior bubbled a mass of information.

I decided to be gentle at first. I gave the folder a little right-click and whispered "Properties" in her ear. She was compliant, and engaged in a simple dialog. I changed the subject to security:

I knew I was getting warm when she let slip that she knew the Creator/Owner. But she wouldn't tell who it was. I applied a bit of "Advanced" pressure, and finally got her to fess up. She showed me the owners, and there was... the Administrators group. A dead end. I had high hopes for this one.

You see, the creator of the file or folder automatically gets ownership-level rights. This means that they can do anything to it an administrator can. This is also one reason the Setup User in SharePoint gets so much power. Since they are the creators of the files that make up SharePoint, they can always access them, no matter what SharePoint's internal permissions say. Unfortunately, Windows Server automatically assigns Ownership to the Administrators.

The Light at the End of the Tunnel

Then I had another thought. The other thin the Setup User does is creates the Central Administration web site. Like I said before, you can't just check the Farm Administrators group. But there is another way to check for "special" users. The STSADM command has a way to list users who have been assigned direct permissions to a site collection. Central Administration needs someone to access it before all of the groups are built, so I thought, why not see if the Setup User was hiding there.

I opened up a command prompt. Central administration is configured on a random port at setup, so first thing I did was look up the port that was in use with the command:

stsadm -o getadminport

Once I had that, I used  the "enumusers" operation. Since the name of the server with Central Administration on it was "canon", the command (including the port found above) was:

stsadm -o enumusers -url http://canon:8585

And there it was - a user explicitly granted permissions. It even had a reasonable id: "SPAdmin".

I gave Steve the good news - the Setup User wasn't one of the accounts on the scrap, nor was it Ben's own account. Fortunately, Ben hadn't used it for any of the services. He had used an easy-to-remember name, SPAdmin. I suggested that Steve change the password, but otherwise he shouldn't have any trouble.

Elementary? Not Really, My Dear Watson...

While the story you have just read is fictional and somewhat tongue-in-cheek, all of the technical elements are true. The Setup User is a very powerful account. It should not be assigned to any of the SharePoint services, and shouldn't be anyone's "day to day" account. And, as you have seen here, there is no way to determine with certainty what account was used to set up SharePoint after the fact.

What we did here was look for ways to infer the account name. I have tested this method on several different SharePoint installations, and it has been accurate on the systems I had available. While there may be other ways beyond the one I used, none of them (even this one) are particularly robust. For example, although it is almost never done, you can explicitly assign rights on Central Administration to other users, or remove the Setup User's default explicit permissions grant (Note, as described in the story, this is NOT in the Farm Administrators group, and does not actually remove the Setup User's power). This will change what users are returned by the enumusers operation.

The moral of the story is that you need to keep a log of the accounts you use in your SharePoint configuration.

Although I'm normally holed up in a little cabin in the wilderness of northern Indiana (well OK, Silver Lake isn't exactly the wilderness...), I do get out of the house from time to time. For those who are interested, I'll be appearing at a couple of conferences in the next few months.

You probably know by now, I'm doing a couple sessions at the SharePoint Technology Conference in Boston.

But now, I can also let you know that I'll be at the Microsoft TechED 2009 conference in Los Angeles next month. (May 11-16). Although I won't be presenting any sessions, I'll be working several shifts at the TLC (Technical Learning Center). And that's not all - Microsoft will be giving away copies of my book - Professional Microsoft Office SharePoint Designer 2007. We'll be set up for autographs, both from me, and from my co-author, Asif Rehmani.

Here are the details:

Professional Microsoft® Office SharePoint® Designer 2007 – Free Books and Signing by Authors:  Woody Windischman & Asif Rehmani

Where:  Microsoft TechEd 2009 – Los Angeles Convention Center, Level 1

South Hall G&H, Technical Learning Center (TLC) Yellow Area – OFC (Office & SharePoint)

Monday, May 11, 2009 - 3:30-4:30PM
Tuesday, May 12, 2009 - 1:30-2:30pm
Wednesday, May 13, 2009 - 1:30-2:30pm
Thursday, May 14, 2009 - 1:30-2:30pm

Note:  One book per person

A Hidden Gem - the Preview Pane View in SharePoint

Toward the end of my wiki article last week, I showed a web part added to a SharePoint wiki page. While people liked the idea of adding web parts to a wiki, what got even more reaction was the web part itself.

The web part, shown below, contains a list of the pages in my wiki. That's nothing new, but what got folks excited was the ability to roll-over the titles, and see a preview of the contents of that page. People are looking all over the place for the "Preview Pane" web part, and asking me where to find it.

Well, I have a confession to make - there is no "preview pane web part". Per se.

But wait - don't run away! I wouldn't be here very long if I went around faking up web pages to make a point. That view is very much a part of SharePoint - even WSS. I just said it wasn't a web part. And that's why people can't find it.

So how do you get a preview pane? Here's the secret - although the preview pane isn't itself a "web part", it is available as a style in almost any list view!

How to do it

The example in the other article was a wiki, but it didn't need to be. You can use a custom list as well. To show how this works, I'll start with a site's home page.

I select Edit Page from the Site Actions menu, and click Add a web part. I'm going to select the Songs list. This is just a custom list that has some content in it on my site. It could have been a wiki, Announcements, or any other list. This list just happens to have some useful content.

Notice that this is starts as simply a standard view of the list.

Now the fun begins! Select Modify Shared Web Part from the web part's menu:

In the task pane, select "Edit the current view." (Note: I also changed my toolbar type to summary, to make it smaller.)

On the Edit View page, scroll down towards the bottom, and expand the section entitled "Style". There you will see a number of display formats. One of them will be the "Preview pane":

Select it, and Click OK. Click OK in the task pane, and your view will be updated with the rollover and preview!

Other Aspects

Since this is just a view style, you can use it on almost any list or library. In addition, you don't need to create a web part first. You can just add this as a view on your list's settings page.

When you create the view, make sure you choose the "Standard" view as the base format:

Once you do that, you will see the same view settings screen described earlier.

Conclusion

SharePoint offers a lot of different ways to look at the information in your sites. One of the most interesting is the Preview Pane view. Although it doesn't show up as a web part on its own, you can use it in almost any list or library simply by modifying the view settings.

I hope this article has encouraged you to explore this, as well as some of the other view formats available to you!

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:

1. 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.
2. 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.
3. 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.

SharePoint Designer and Expression Web - Separated at Birth

As part of Microsoft's making SharePoint Designer available as a free download, they also announced a rough roadmap for its future, as well as that of another tool, Expression Web. You might wonder why Expression Web was designated a successor (from a licensing standpoint), when it doesn't have any ability to modify SharePoint sites.

To help you understand, I'm going to give you a little bit of history of these two tools, in the form of a "bedtime story." Then I'll talk about some of their similarities and differences, as well some of what I see as the ramifications of this change.

Once Upon a Time...

Once upon a time, when the Web was new, and the Internet was still wet behind the ears, there was born a little web design tool called FrontPage. FrontPage was blessed with many talents, from page editing, to web site management.

Yet in its youth, FrontPage also had many bad habits. It liked to do certain things its own way, and tended to enforce its will on unsuspecting developers. Often, the result was broken script. The developers did not find this habit endearing, and shunned FrontPage.

As FrontPage grew up, it matured and learned many new skills. It made friends with a new product called SharePoint. It also gradually put away its childhood arrogance, and learned the value of industry standards. Yet try as it might, its youthful indiscretions continued to haunt it, and it could not earn the respect of the community at large.

One fateful evening, FrontPage found itself at a crossroads, and was torn. One way led to greater integration with SharePoint, while the other promised great adventures with the industry standards. "Perhaps," it thought, "Perhaps I am trying too hard to be all things to all people." Yet it liked both its association with SharePoint, as well as its new-found friendship with the Standards. It gazed into the heavens and made a wish upon a falling star.

"I wish people could forget about my past, and see me as the wonderful tool I have become, both for designing SharePoint sites and expressing web standards!"

Then FrontPage fell into a deep, sound, sleep. Sometime during the night, a strange and wondrous thing had happened. When morning came, FrontPage had disappeared, and in its place were two new children - SharePoint Designer, and Expression Web. At first glance, while neither looked quite like FrontPage, they were still hard to tell apart. Both had stylish modern clothes, and found an understanding of CSS and ASP.NET came as naturally as breathing.

Yet there were differences. When SharePoint Designer wanted to talk about SharePoint, Expression Web just threw up its hands and wouldn't hear a word of it. On the other hand, when Expression Web tried to strike up a conversation about the joys of PHP, SharePoint Designer could only tilt its head and say "Huh?"

SharePoint Designer also found it easier to remember its old life as FrontPage. Expression Web was resistant, and needed some prodding to deal with that part of its past.

And so each began a separate journey, taking their respective paths from the crossroads.

That was Then, This is Now

OK, so now you know that SharePoint Designer and Expression Web are both descendents of Microsoft FrontPage. In many ways, they are very similar. How similar? Here are both of them side-by-side:

 
They share all of the same core page editing features. The same CSS handling, ASP.NET support, IntelliSense code completion, etc.. They both also share the ability to work with local XML and external databases on non-SharePoint sites. So, where are they different?

First and foremost, a key differentiator is SharePoint support. As implied in the fable, SharePoint Designer is fully aware of SharePoint and most of its features. Expression Web, on the other hand, will not even open a site based on SharePoint, whether you are using SharePoint features or not. If you attempt to do so, it responds with this alert:

Second, SharePoint Designer has more (and more obvious) support for "legacy" FrontPage functionality. In some ways, this follows from the previous point, as SharePoint is derived (at least conceptually) from the FrontPage Server Extensions. Expression Web suppresses any direct access to extensions based functionality. For example, the Insert menu in SharePoint Designer offers an option to insert a "Web Component", which is not present in Expression Web. The choices offered in the resulting dialog are mostly FrontPage pieces.

If you open a site which already contains FrontPage functionality, such as Shared Borders or Navigation/Link bars, SharePoint Designer lets you easily select editing options through the context menu, while Expression Web does not.

The first image above is from SharePoint Designer. Note the Shared Border and Link Bar properties options. See how they do not appear in the second image, which is the same page opened in Expression Web.

So it seems that Expression Web is just a subset of SharePoint Designer's functionality. But is that the case? Doesn't Expression Web have something to call its own?

It turns out that it does. Because Expression Web was intended to help you create sophisticated, standards-based web sites, it includes some templates for you to start with that SharePoint Designer does not. In version 1 of Expression Web, that was about it.

With Version 2, which has been out for a few months now, Expression Web added direct support for PHP.

Also notice the Media option. Expression Web now also supports the direct insertion and manipulation of Flash, Silverlight, and other media files. SharePoint Designer's support for media is not as well integrated, and it doesn't support PHP at all.

One other big difference between SharePoint Designer and Expression Web is in their online help systems. Not so much the system itself, but the content. SharePoint Designer provides a great deal of help on topics related to manipulating SharePoint Sites, and features such as Workflow and layouts pages, but almost nothing about how to use the basic editing features of the product. Expression Web's help, on the other hand, includes all of the basic features, as well as PHP.

Where Do We Go From Here?

So, SharePoint Designer and Expression Web are both descendents of FrontPage, and they have roughly equivalent, if differently focused, feature sets. SharePoint Designer is now free for the download, and Expression Web is the designated successor as far as Software Assurance licenses are concerned. You still can't use Expression Web to manipulate SharePoint Sites, so where does that leave us? What is next?

Microsoft has released a limited roadmap of the future of these products. They have said:

1. SharePoint Designer is free, but development has not stopped. It will remain free when the next version comes out, simultaneously with the next version of SharePoint.
2. SharePoint support will be added to Expression Web. (When? v.Next?)
3. Expression Web will continue to include tight integration both with the other Expression series and with Visual Studio.
4. Visual Studio is getting a big dose of SharePoint Friendliness in the next version.
5. Expression will be "where the action is" with regard to Silverlight integration.

Granted, there isn't a lot of detail there. But I suspect SharePoint Designer and Expression Web will continue to be very similar to each other - possibly even more so than they are now - for a long time to come.

On Babies, Bathwater, and SharePoint Designer

On April 2nd, as has been rumored for quite some time, Microsoft announced that SharePoint Designer is available as a free download. (Get it Here...)

Reaction to even the rumors of this has ranged from very positive, to downright horrified. So, what's all the fuss about? What is SharePoint Designer, and why should you care?

Just What is SharePoint Designer Anyway?

SharePoint Designer, at its core, is a web design and editing tool. Think of it as a word processor for Web pages. It gives users a roughly "what you see is what you get" (WYSIWYG) view of their web page as they build it.

This makes it very easy to create and edit web pages. But, because web sites can be much more complicated that Word documents, there are also a lot of options that allow the user to manage different bits and pieces of the site beyond the current page. Even if SharePoint Designer did nothing else, that would make it a very powerful tool for creating and editing web sites of all kinds.

Shameless Plug: You can get a nice overview of the basic Web-design features of SharePoint Designer from the freely-downloadable chapter 1 of my book. You can also read the Introduction to the book on this site, or at EndUserSharePoint.com. (Buy the whole book here.)

But Wait! There's More...

What makes SharePoint Designer different from virtually all other web design tools is that it is fully aware of SharePoint and its functionality - such as lists, libraries, and master pages - as well. In addition, SharePoint Designer gives you easy access to many powerful SharePoint features, such as the ability to integrate with external data sources Data View/Form Web Parts, that are not readily available in any other way.

Now How Much Would You Pay? ;)

The Price of Freedom

"The price of freedom is eternal vigilance." - Thomas Jefferson, US Founding Father.
"With Mogwai comes much responsibility." - "Grandfather", in the movie Gremlins.

When this version of SharePoint (WSS 3.0 and MOSS 2007) first came out, SharePoint Designer was released for sale for several hundred dollars. And it was well worth it! It is an extremely powerful and versatile tool. By making it available as a free download, Microsoft is bringing that power and versatility to a whole new audience.

This is certainly cause for celebration!

Yet it is that very availability which is also causing the horror mentioned at the start of this article. In untrained hands, and/or without proper safeguards, a power tool like SharePoint Designer can also cause a great deal of damage. So how do you, as a corporate IT person, manage the risks involved?

Fortunately, there are many ways to control the use of SharePoint Designer within an organization. The SharePoint Designer team at Microsoft has published a great article on the various control mechanisms available, and I also talk about them in my book. I'll just refer you there for the "how to". However, I do want to discuss a bit of the "why" side, or in some cases, the why not to, of implementing these controls.

First the "Not".

The control options described in the Microsoft article include hard-coding changes to SharePoint site definitions to block the use of SharePoint Designer on sites based on them. I believe that such a tactic is a knee-jerk reaction, overkill, and amounts to "throwing the baby out with the bathwater".

Blocking editors at the site definition level is asking for trouble on a number of different levels. Beyond the general cautions about making changes to site definitions (which are beyond the scope of this article), you need to be aware that this change impacts all users, forever. Even if you later decide that specially trained users should be allowed to make customizations with SharePoint Designer or its successors, they won't be able to. Just don't do it!!

The Right Way

Many enterprises use group policy to control what applications can be installed on users' desktops, and even what features are available. If your organization already controls software installation, this is a great first step. You can use these policies to decide just who can install and use SharePoint Designer.

On the SharePoint site itself, there are also many controls. The first line of defense here is, don't give administrator or web designer rights to users who don't need them. The default "member" or "contributor" roles available in SharePoint provide all of the access most users need. They allow users retrieve information through browsing and search, as well as add and edit documents or list items. Naturally, site owners will have administrative rights to their areas, and can further delegate enhanced rights to their users, but they can't override your group policies.

So, between those two configurations, you will have nipped in the bud virtually any casual hazard that "free" access to SharePoint Designer may present. These also represent general enterprise networking "best practices".

Finally, like any powerful tool, you should make sure that users are trained in SharePoint Designer's use before turning them loose. These users should understand not only SharePoint Designer itself, but the capabilities of SharePoint they are planning to modify. I have taken that into account in my book (which includes chapters on understanding SharePoint, as well as SharePoint Designer), and there are several other excellent resources available.

In Conclusion - The sky is not falling.

SharePoint Designer is a powerful tool, and Microsoft has just brought it to the masses by making it available as a free download. While caution on the part of IT managers is justified, there is a place for SharePoint Designer in the enterprise. Like any powerful tool, it is important to understand what SharePoint Designer is, and its true impacts on your systems. Users should be trained in its proper use before allowing it to be deployed. However, you do not need to "throw the baby out with the bathwater" by permanently blocking it from your organization.

Using legacy FrontPage functionality in SharePoint and SharePoint Designer to create a file "drop box".

SharePoint is a great tool for information sharing. Document libraries allow your users to upload and collaborate on documents of all sorts. Sometimes, though, you don't want to do things quite the way SharePoint does it.

Does this sound familiar?

"I want a place where users can upload a file, but I don't want them to see what everyone else has uploaded."

Your first thought might be no problem, I'll just set up a document library, but what about that bit about seeing what everyone else has uploaded? Now we're getting a bit messy. Document libraries don't have an "only their own" security option.

And what if this is supposed to be a "drop only" zone, such that they aren't even supposed to get back at their own files? (This is a more common request than you might think). Again, very difficult with the standard SharePoint document libraries. Savvy users can figure out how to get to their files based on the address of the forms folder.

While there are many ways to get around these issues, most of them involve a lot of work customizing the target library and its forms. Fortunately, there are some old, but little known, tools in SharePoint and SharePoint Designer that can make short work of the problem.

It's In There...

You may not realize this (unless you've been around a while, or read the Appendix to my book), but SharePoint is a descendent (at least conceptually) of the FrontPage Server Extensions (FPSE). Although there has been a lot of enhancement since then, many of the functions of these extensions still exist within SharePoint in a compatible way. SharePoint Designer, as a descendent of FrontPage, supports this FPSE functionality.

One of the things you may find surprising about the FPSE, is that most of its features are meant to be defined in "static" HTML pages. Specially crafted comments, called WebBots, were used to signal to the server that extra processing was to take place at either save or render time.

For this project, we're going to make use of the FPSE form handler WebBot to let the user select a file and upload it into a hidden document library on your site.

Making it Happen

The first thing you need, of course, is a place to put the files. As stated earlier, the natural target is a document library. So, let's create a library called DropBox.

Note: Most of these steps will take place in SharePoint Designer.

From the File menu, select New, SharePoint Content:

Select Document Library, and enter a name, such as DropBox. Click OK to create the library

Once the library is created, right-click it and choose Properties. Check the box "Hide from browsers", so that the library doesn't appear in the Quick Launch or All Site Content lists. Set the Use version history to Major Versions. (You want versioning enabled so you don't lose anything if users upload files that have the same name.) Since there won't be a default document type for this library, you can also uncheck the "Use a template" option. Click OK once the settings are correct.

Note: There is one library setting you may wish to make in the browser, to block the library from appearing in SharePoint Search results. Under the Document Library Settings, Advanced Settings, set the Search option to "no".

Once you have created your target library, you create HTML pages to use for your upload form and confirmation page.

From the File menu, select New ->HTML. This will create an html file in the design surface.

From the Toolbox task pane, drag an Input (File) control onto your page.

This will automatically create a Form element to surround it.

Drag an Input (Submit) button into the new form as well.

I'm using the SharePoint Designer split-view of my page to show both the code and visual layout. Now we need to make a slight change to the automatically created Form element. To do this, we'll click in the code area to place the cursor after the post statement. When you hit space, you will be presented with Intellisense options for parameters you can add to the form tag. In this case, we want to add an "enctype" parameter, and set it to "multipart/form-data", as shown below.

Without this change, the form will not be able to handle the binary file information we want to transfer. I'm also going to rename the Submit button to say "Upload" by double-clicking it and changing the Value/label field, and also place it on a new line.

This results in a form that looks like the image below in the editor:

Now that my form has all of the information I want, I'm going to tell it where to place the files. Right-click the form, and select Form Properties. In the Form Properties dialog, select "Send to (Requires FrontPage Server Extensions)". Enter "_private/dropbox.xml" into the File name field. This is not where the files go. Rather, it will be a log of all of the forms that have been submitted. If you add other fields to your form, their values would also be stored in this file.

Now, we click the "Options" button, and click the File Upload tab. Click the Browse button and select our DropBox library. Click OK to implement the changes. (Don't worry about the other fields or tabs for right now.)

The first time you save your form, you may also get an alert telling you that files not saved in _private may be visible to others.

Save the page in the root of your site as "dropbox.htm" (you can move it later).

At this point, you can test the basic functionality of your form. Preview the page in your browser, and try uploading a file. You should see a confirmation page similar to the following:

And if you open the DropBox library in SharePoint Designer, you will see the file there as well (you may need to press the F5 key to referesh the view)

The only problem is that confirmation form - you've just told your user where you put the file.

Creating a Confirmation Page

You can also create a custom confirmation page for your form. Again, this starts as a simple, HTML page, so select File -> New -> HTML.

From the Insert menu, select "Web Component". This will summon a dialog box, in which you will select Advancved Controls as the component type, and Confirmation Field for the actual control:

Click Finish. You will be asked for the name of the control to use. Type Submit1 and click OK. (Submit1 is the name of the upload button in our form.)

Enter the following text after the form field:

complete!

Thank you for your submission. Click here to return to the form.

Highilight "Click here", and press <ctrl>+k. In the insert hyperlink dialog, select the dropbox.htm file. You should end up with something that looks approximately like:

Save the file as "DropConfirm.htm".

Meanwhile, back on the dropbox.htm page, right-click on the form and select Form Properties. Click the Options button, and select the Confirmation Page tab. Click Browse, and select the DropConfirm.htm page you created above.

Click OK to save the change, and also on the Properties dialog. Save the dropbox.htm page, and preview it in the browser. Upload a file, and ensure that your new confirmation page is displayed:

Using Your Dropbox

Once your form and confirmation page are working to your liking, you need to make them available to your users. The best way to do this is to use a "Page Viewer" web part. This web part allows you to display virtually any page within the context of a SharePoint web part page. We're going to use the standard SharePoint web interface to add this part.

To add the web part, Navigate to the page where you want the form to appear, and select Edit Page from the Site Actions menu. Click the Add a Web Part link in the zone you want. From the dialog, select Page Viewer Web Part. (It will usually be in the Miscellaneous section). And click the Add button.

This will add the part to the top of the zone you selected. Click the "open the tool pane" link.

That will open the Page Viewer Web Part's task pane:

Enter the URL path to your dropbox form in the Link field. I suggest using a "root relative" address (i.e. preceding backslash, but without the " http://server ").

In this case, I also changed the web part title, and set fixed height and width settings for the web part in order to prevent scrollbars (these numbers may vary on your site). Click OK to save your changes, and click the Exit Edit Mode link to see your final page. (You may need to check-in the page on MOSS Publishing sites.)

Summary

There you have it! A simple way to give give your users an "upload only" dropbox. You can easily change the destination location for the files, without needing to make any changes to the underlying SharePoint document libraries or their associated forms.

While this example only provided a simple form, you can enhance it with more text, or additional fields for the log file. You can, of course, format the text any way you like, or even make it a stand-alone page, copying all of the chrome from your site (not a trivial task, but possible.)

Until next time, Happy Dropping!

Note: This article is also posted on EndUserSharePoint.com

Hi Everyone! One of the things everyone likes to do while they're browsing for books in the store is read the covers and the introductions. While the listings for my book on the various sites include the back-cover description, and Wrox has posted the Table of Contents and Chapter 1 as PDF, the introduction hasn't been posted anywhere. I thought you might like to read it, so here it is - an Introduction excerpt from Professional Microsoft Office SharePoint Designer 2007…

INTRODUCTION

"Can you make it look less like SharePoint?"

Such a simple question, and yet, like someone opening the lid to Pandora's Box, the customer asking it can release a whole range of troubles into the life of a web designer. The latest release of Microsoft SharePoint products has taken the world by storm. Faster than anyone could have foreseen, businesses large and small have discovered that SharePoint addresses a range of needs, and have rushed to jump on the bandwagon.

SharePoint is not merely a web server. It is a large and complex application, with many moving parts. Some of them are easy to customize; others require a bit more finesse. Tools and guidance for that customization are few and far between. Fortunately for you, SharePoint Designer is such a tool, and this book provides the guidance. Together, they enable you to look your customer in the eye and answer with a resounding: "Yes!"

Yet SharePoint Designer can do far more than customize SharePoint sites. It is a fully-featured web design tool in its own right, with excellent support for many industry standards, as well as backward compatibility with a few nonstandard capabilities.

Who This Book Is For

This book is for anyone who has been asked the opening question. You may be an experienced web designer or a web application developer who has never used SharePoint. You may be a system administrator who needs to tweak a few things to match an existing standard. Perhaps you are a business analyst looking for ways to integrate some CRM information into the company's home page. All of you will find something useful here.

If your familiarity with SharePoint is limited, chapters 2, 3, and 4 will be indispensable for you. They cover the key features of SharePoint, and how they are viewed from the user's, administrator's, and web designer's perspectives, respectively.

This book is also for people upgrading from Microsoft FrontPage. SharePoint Designer is one of two direct successors to FrontPage. As a result, FrontPage users will find much that is familiar, as well as many things that have changed. In general, you will find that while you can edit existing sites that use legacy features, SharePoint Designer's function layout encourages a much more standards-compliant way to design new sites and content.

This book assumes you have a more than passing familiarity with designing applications for the web. A basic knowledge of JavaScript is assumed, as is an understanding of HTML tags. Some allowance is made for the rise of certain technologies in recent years. A few chapters deal with CSS, XML, and XSL, and a short introduction to each is provided where appropriate.

The book also assumes a certain willingness to explore. Although all of the core functions, menus, and toolbars of SharePoint Designer are described, this is not a Bible that explains each and every menu item and dialog tick in excruciating detail. If a program feature offers several options, a representative few are described, and one may be used in an example.

The book assumes you are familiar with basic Windows operations and applications. Where functions are common in many applications, they probably are not discussed at all. (You are shown where to find the Formatting toolbar, for instance, but your familiarity with the icons and meanings of Bold, Center, and the various bulleting options is assumed.) It’s also assumed that you know how to point, click, cut, copy, and paste.

The later chapters move out of SharePoint Designer and into Visual Studio. They cover creating extensions to SharePoint, SharePoint Designer, or both. Examples are provided in both C# and Visual Basic .NET. Although the source is discussed and/or documented in the text, no attempt is made to teach the languages themselves, so proficiency in one of these languages is desirable. Many readers may consider these chapters optional, although system administrators should at least pay attention to chapter 18.

What This Book Covers

This book covers Microsoft Office SharePoint Designer 2007, with an emphasis on using it to customize web sites based on Microsoft SharePoint products and technologies. You will learn about Master Pages, Themes, and various Web Parts that enable you to create powerful applications with little or no code.

A short overview of SharePoint is provided to ensure that you are not flying blind when you customize SharePoint sites. At the other end of the scale, you are taken outside the box with chapters that teach you how to use Visual Studio and other tools to extend the capabilities available in both SharePoint and SharePoint Designer.

Aspects of SharePoint Designer beyond SharePoint customization are not ignored, however. You will find sections that cover the basic web-editing features, generic application of the CSS editor, and site administration functions provided by SharePoint Designer. Many elements, such as data views, while described in the SharePoint context, are also relevant without a SharePoint environment.

How This Book Is Structured

This book is made up of 18 chapters, in five parts. Each part brings together related tasks and content. Part I is fundamental to everything else, but the other parts do not necessarily need to be read in a particular order. They are, however, largely progressive in their complexity.

Part I, “The Basics,” provides an overview of SharePoint Designer, SharePoint technology, and their relationship to one another.

Part II, “Customizing the SharePoint Look and Feel,” shows how to use SharePoint Designer to customize various aspects of your sites.

Part III, “Applications without Programming,” shows how SharePoint Designer can create many powerful applications that in the past would have required considerable programming effort.

Part IV, “Programming on the Client Side,” demonstrates some tools provided by SharePoint and SharePoint Designer to enable even more custom interactivity.

Part V, “Beyond SharePoint Designer,” takes you far past the built-in capabilities of SharePoint Designer with extensions, add-ins, migration, and conversion tools.

Web design is an intrinsically visual process, web designers tend to be visual learners, and SharePoint Designer is a visual tool. This book takes that into account by including a relatively high proportion of screenshots. There are also step-by-step exercises where appropriate. Finally, it wouldn't be a Wrox Professional book without sample code, and that is here in abundance. In this case, "code" is interpreted liberally to include markup, CSS, and scripting, in addition to compiled source.

What You Need to Use This Book

While you can learn much from this book simply by reading, to follow along with the exercises and step-by-step instructions, it will be helpful to have a few things. Most important, of course, is a copy of SharePoint Designer 2007. You should also have access to a SharePoint environment that you can use without adversely impacting production sites.

Certain examples make use of Web Parts that are only included with editions of Microsoft Office SharePoint Server 2007 or Microsoft Search Server 2008. The Express Edition of Search Server (MSSX) is available as a free download from Microsoft, and is a sufficient version of SharePoint to perform all of the exercises and examples in this book, except for those in chapter 8.

Chapter 8 describes Publishing layouts and content management. These are features exclusive to Microsoft Office SharePoint Server 2007. You will need access to this if you wish to follow the examples in that chapter.

To compile the example programs in Part V, you need Visual Studio 2005 or Visual Studio 2008, Standard Edition or higher. You also need to download the following add-ons from the Microsoft MSDN site:

· The Windows SharePoint Services 3.0 Software Development Kit (WSS SDK)

· The Microsoft Office SharePoint Server 2007 Software Development Kit (MOSS SDK)

· Visual Studio Tools for Office (VSTO)

· Visual Studio Extensions for Windows SharePoint Services (VSeWSS)

The SharePoint Designer add-in example in chapter 17 requires the SharePoint Designer 2007 Add-In project template from the Microsoft CodePlex site.

Most SharePoint designers and developers find it convenient to create a sandbox development environment containing all of the tools listed here (and other favorite development utilities) on a virtual machine (VM). All versions of SharePoint require Windows Server 2003 or Windows Server 2008, with at least 1GB of RAM to install successfully (2GB or more of RAM is recommended).

Related Products

SharePoint Designer is not the only Microsoft product created for manipulating web pages. It is closely related to Microsoft Expression Web, which sprang from the same FrontPage roots. In addition, Visual Studio is a useful tool for web designers of all stripes.

SharePoint Designer Compared to Expression Web

As with the mythical Hydra, who grows more than one head if the first is cut off, the end of FrontPage was the beginning several children. Like SharePoint Designer, Microsoft Expression Web is a direct descendent of Microsoft FrontPage. In fact, from a basic page-editing standpoint, SharePoint Designer and Expression Web appear virtually identical.

Scratch the surface, however, and the differences become clear. Nothing says it better than the dialog shown in Figure 1, which you get when you try to open a SharePoint-based site in Expression Web. Expression Web has no capability to work on a SharePoint site.

Figure I-1

SharePoint Designer, on the other hand, happily opens web sites created with most versions of SharePoint. In addition, SharePoint Designer offers more complete support for sites created using the FrontPage Server Extensions.

So, why use Expression Web? If you don’t need to work with SharePoint, Expression Web provides an excellent set of tools for creating standards-based web sites. It integrates with Visual Studio, supports PHP (which SharePoint Designer does not), and includes several web site templates that are not available with SharePoint Designer.

SharePoint Designer Compared to Visual Studio

The other tool you might consider for working with SharePoint is Visual Studio. In fact, there are certain things that cannot be done with SharePoint Designer. Some of these tasks are described in Part V, “Beyond SharePoint Designer.” The key is to remember that SharePoint Designer is generally used to customize SharePoint sites and manipulate existing features, whereas Visual Studio is used to develop new SharePoint functionality.

Professional Microsoft Office SharePoint Designer 2007
Woodrow W. Windischman, Bryan Phillips, Asif Rehmani
ISBN: 978-0-470-28761-3

No Assembly (or C#, or VB) Required

Searching Twitter from SharePoint has become all the rage since I originally posted my Twitter Search Federation articles (Part 1, Part 2). Federation is great if you have Search Server, or the Infrastructure Updates. But what if you are only using WSS? Or what if you just want to drop a Twitter search into any old SharePoint page, rather than a full Results page? And more critical - what if you don't have direct access to the SharePoint server in order to install binary web part and feature - with or without a Solution Package (WSP)?

Well, buried in Part 2 of my article was the the solution. A Data View Web Part (DVWP) that displays the results of a twitter search. In the original article, that DVWP was just an interim step on the way to Federation. For this article, a form of that web part is the actual goal. So, I'm going to start by re-using the DVWP section of the Federation article - with a tweak or two :). But then, I'll also show you how do two very important things - connect the web part to an input form (or any other web part), and export it for use on other SharePoint sites.

Note: You can find a link to download the Twitter Search Results Web Part at the end if this article.

A Data View Refresher

The Data View Web Part is a way to display information from virtually any source within SharePoint. Data Views are created in SharePoint Designer, in association with another feature called the Data Source Library. This is not to be confused with the "Business Data Catalog", or BDC. While both the Data Source Library and the BDC deal with presenting data from external sources within SharePoint, the BDC is a part of MOSS Enterprise, and allows a much deeper integration of the data with various aspects of SharePoint. The Data Source Library, on the other hand, is available in all editions of SharePoint - from WSS on up - and is primarily used to generate Data View/Data Form Web Parts.

Data Views and the Data Source Library are a very powerful combination - so much so that almost two whole chapters of my book are devoted to them. Obviously, I can't go into that kind of detail here, but while this particular example is fairly simple, it covers a lot of ground.

The link between Federation and Data Views is pretty close. In fact, prior to Search Server or the Infrastructure Updates, you could use a Data View to achieve very similar results. We're going to take advantage of this by building the look we want in a Data View, then transferring it into the Federated Location definition.

Creating a Data View

Before we can create a Data View, we need create a new item in the Data Source Library for our Atom feed.

To do this, Select "Manage Data Sources..." from the Data View menu in SharePoint Designer to summon the Data Source Library task pane. Atom and RSS feeds fall into the category of "Server-side Scripts" that return XML, so expand the Server-side Scripts section and click "Connect to a script or RSS Feed." You will see the dialog below. Fill in the URL with the same Twitter Atom query we have been using: http://search.twitter.com/search.atom?q=sharepoint (See Part 1 of the original article for details on how this was derived.)

The query parameter (q) will automatically be passed into the list as soon as you change the focus from the URL field. "SharePoint" will become the default parameter value, and give us something to see as we customize the look. If you are following along, you can replace "SharePoint" with any default query term that might be appropriate to your environment. Make sure the Runtime Parameter box is checked, otherwise you can't change the query later.

Now that we have the Data Source, we need a place to put it. This can be any web part page. While you can use the results page if you feel so inclined, because we aren't going to be using the Data View directly, it doesn't need to be.

Once you have a web part page open, select a Web Part Zone, and then pick "Insert Data View..." from the Data View menu. The Data Source you created above will have a drop-down menu associated with it. Select "Show Data".

You will see the Data Source Details task pane, with the structure of the Twitter Atom feed displayed.

I've maximized my task pane for this screen shot in order to show you how the SharePoint Designer data source displays the entire structure of the feed. Notice the folders and item scrolls for the various elements. The Twitter Atom feed is a "hierarchical" data source. This means that the data has nested, potentially (and in this case, actually) repeating, elements, which in turn may have their own nested elements.

For now, the primary entity we are interested in is the "Entry" folder. Look at the screen shot to the right. Highlight the elements in the "Entry" folder as shown, and select "Multiple Item View" from the "Insert Selected Fields as..." menu. (Yes, I know. It looks like a button, but trust me - it's a menu!)

A table will be inserted into the web part. That's got most of the information we want, but it isn't terribly pretty. So, let's fix it up!

The first column contains the "href" entity. Ironically, even though there is a separate entity for the Author, one of the two links listed for each user is the Author's avatar. The other is a link to the Twitter URL of the tweet itself. For our results, we really only want the avatar, so we're going to do two things - Change the display to show the image instead of the URL, and hide the other URL.

To change to an image view, click one of the URLs in the href column. To the right will be a little box with a chevron in it:

When you click it, you will have choices to modify the current field. Select Picture.

You will get a warning that URLs and Pictures can be dangerous. We know that, so click Yes.

The changes you make here will affect all of the items of that series. (You probably noticed that they were all highlighted in a different color when you clicked on any one of them.)

Once you have done that, to suppress the other image (which will show as a "broken" picture), Right-click the broken link and select "Conditional Formatting". In the Conditional Formatting task pane, select "Show Content" from the "Create" menu (another one of those "buttony" menus). In the Condition Criteria box, set the conditions like this:

The broken link will go away.

Next, we want to merge the rest of the cells in the row. This is just like any other table action - highlight the data cells (not the labels) for content, updated, name, and uri. Right-click, and select "Modify/Merge Cells". Now we're cooking! Just a couple more tweaks, and it will be there.

Select the tweet content text, and change its format to Rich Text (just like changing the image format above).

Select the date, and format it to your regional liking.

Notice that we have a link to the Author, the Author's name, and the Author's avatar. Wouldn't it be great to have the name and the avatar actually link to the Author's page? Well, we can. If you click the chevron by the link, you will see that the field being displayed is called "ddw1:author/ddw1:uri". For the text, change the format to Hyperlink, you will see the following dialog. You can use the "fx" icons to select the fields you wish to use in the hyperlink, or enter the values manually. In either case, you want the "Text to display" and "Address" fields to be set as shown:

Setting the link on the picture is easy, too. Just right-click the image, and select "Hyperlink" from the context menu. Set the address to the same token as you used above. Now you can delete the field that shows the text of the author link.

You should now have a web part that looks a lot more like what you would expect from a Twitter search:

Pretty good, but I'm still not satisfied. :)

Notice the chevron icon in the upper-right corner of the web part.

If you click it, you will summon the "Common Data View Tasks" menu:

Click Data View Properties. You will get this dialog:

Click "Show view header" and "Show view footer", then click the "Paging" tab.

Click "Limit the total number of items displayed to:" and enter a reasonable number for a search results page. (I picked 5). Click OK.

Display the Data Source Details task pane, and drag the first title field available into the newly created header. Click in the footer, and delete the Item Count. In the "link" group (above the "title" field you just used), make sure item 1 (rel = "alternate") is selected. Highlight the "href" and select "Item(s)" from the Insert Selected Field menu. Change its format to a Hyperlink. Leave the Address as-is, but change the Text to Display to "More Results..."

I'm going to delete the field name row, rearrange the fields slightly, and also apply the style "ms-searchChannelTitle" to the Header cell. This results in a part that looks like this:

Now I'll make one more change to this web part to allow it to respond to a URL query string. From the Common Data View Tasks menu, select Parameters. You should see this dialog, displaying the "q" parameter that got created when we built the Data Source:

From the Parameter Source menu, select Query String. This will add a field for you to enter the name of the URL parameter you will be passing. The standard for SharePoint Search keyword parameters is "k", so I suggest using this (without the quotes, of course). This allows you to use this web part on a standard SharePoint results page and have it respond appropriately. But you can also then use the k parameter in the query string of any SharePoint page you drop the part on!

Your Twitter Search Results web part is done! You can save the page and close SharePoint Designer.

The Twitter Search Results Web Part in Action!

When you display the page on which you created the Twitter Search Results web part, you will see the default result set:

To show that the URL Query string works, append a "?k=twitter" to the URL (again, no quotes), and hit the Enter key. The results will change to Tweets containing the word Twitter:

Notice also how the search form recognized the "k" parameter, and set it as the default keyword for an internal Sharepoint search...

Now that we know the part is working, delete the k parameter from the address bar and hit Enter to return to the default page. We need to do this because the query string parameter will override the web part connection we're going to be making. (You might want to keep that in mind, as there may be times you find that behavior useful in your own data views...)

Let's insert a "form" web part on the page. From Site Actions, select Edit Page. In one of your Web Part zones, click the Add a Web Part link, and select Form Web Part from the Miscellaneous section, and click the Add button:

By default, this form will have a text box, and a "Go" button, and will be called "Form Web Part". On your site, you will probably want to set the web part properties to give it a different label, such as "Twitter Search". For purposes of this article, I'm going move directly on to setting up the connection.

From the edit menu on the part you just inserted, select Connections.

From the fly-out submenu, select Provide Form Values To, and select the Twitter Results web part. You will get this dialog:

Select Get Parameters From, and click the "Configure" button. The dialog will then ask for the Consumer Field Name. Select "q" (the parameter name), and click the "Finish" button.

You can then also exit Edit mode on your page.

Now just enter a term into your form, and click "Go". You will get Twitter Search results for the term you selected!

You don't need to use a form for the web part connection. You can connect to almost any web part in SharePoint to get query parameters. For example, you could connect to a client list and use the company name as the search term. You could then just click on each client's record to see their Twitter buzz.

Exporting and Importing the Twitter Results Web Part

Important: Remove the web part connection created in the previous exercise before exporting! 

One of the great things about the Data Views you create in SharePoint Designer is that you can easily export them for use on virtually any SharePoint site that has access to the data used to define it. To do this, Use the little arrow in the top right corner to summon the web part menu, and select Export:

A standard download box will appear, allowing you to save the file to your local machine. In our case, the part will be called Twitter_Results.webpart. ".webpart" is one of two extensions you might see when exporting SharePoint web parts. (The other is ".DWP")

So, what do you do with the file once you have it? You import it back into SharePoint!. As mentioned earlier, it doesn't need to go on the same site - or in this case, even the same server! As long as the server you are installing the part on has access to Twitter, you can use this part.

There are two ways to import the part:

1. Directly importing onto a page
2. Adding it to the Web Part Gallery

To import it onto a page, start the same way as always: From Site Actions, pick Edit Page. Then click Add a Web Part over a Web Part zone. However, this time, you need to click the link on the bottom of the window: "Advanced Web Part gallery and options"

This will close the dialog and open the Add Web Parts task pane. At the top of the task pane is a menu. Select Import from the menu:

This changes the task pane to Import mode. From here, you can either type the path to the .webpart file, or use the standard Windows file dialog to browse for it:

Click Upload, and the part will appear on a list below the form. You can then drag it into the Web Part zone of your choice.

The down side of this method, is that you have to re-import the web part for every page on which you want it to appear. Fortunately, you can make it available to any page in your site by adding it to the Web Parts Gallery.

To access the Web Parts gallery: From the Site Actions menu, select Site Settings. On the Site Settings page, you will see the list of Galleries. Click the "Web Parts" link.

Essentially the Web Parts gallery works just like any other document library in SharePoint:

To add the web part, click Upload, and browse to the web part file. After you upload it, you can enter a full description, and determine the context(s) in which the part will be selectable.

Click OK to complete the Save process. From then on, your Twitter Results web part will be available from the standard Add Web Parts dialog box:

Of course, these techniques apply to almost any Data View or Content Editor Web Parts you create, not just this Twitter Search.

You can Download this part here!

]]>Woody WindischmanThu, 05 Mar 2009 19:15:00 GMTAdministrationCustomizationData IntegrationDesignSharePoint DesignerSharePointWSSSearchhttp://www.thesanitypoint.com/archive/2009/06/13/presenting-at-the-sharepoint-technology-conference.aspx/archive/2009/06/13/presenting-at-the-sharepoint-technology-conference.aspx

Another Boston "T" Party?

The last time I was in Boston, it was for TechEd 2006. When I wrote about the experience on my old blog, I called it the "Boston T Party". It was my first TechEd, and it was a real blast!

Well, I found out yesterday that I'm going back to Boston for another technology conference. I'll be presenting two sessions at The SharePoint Technology Conference, June 22-24. This "T Party" will be a much more intimate affair, focused on helping you get the most out of SharePoint.

The organizers have just finalized the agenda, and posted it to the site along with updated speaker bios.

I look forward to seeing everyone in Boston!

An excerpt from Professional Microsoft Office SharePoint Designer 2007
This segment also published in on End User SharePoint.

One of the most frustrating things about designing for the Web is the wide array of browsers and screen formats in which your site may be displayed. SharePoint Designer helps mitigate this problem by giving you several preview options.

First, you can fix the Design view to a set of dimensions. In the status bar, you can see the current dimensions of the window the Design view represents. Click the dimensions entry to see the menu shown in Figure 1-11, which allows you to choose from several page sizes.

Figure 1-11

If the selected dimensions are smaller than the current design window, the width of the working area is reduced to the horizontal dimension selected. The chosen vertical dimension is shown by a dotted line across the visible area of the page.

If the selected dimensions are larger than the current design window, the workspace is expanded horizontally, and the scroll bar at the bottom of the window is activated.

Note: The default page sizes represent Microsoft Internet Explorer in its default configuration. You can create your own set of dimensions to choose from.

When a fixed page size is selected, the dimension status shows the hash symbol seen in Figure 1-11. The Page Size menu is also available under the View menu.

Design view provides a close approximation of the rendering of your page, especially with the visual aids turned off. However, even with the fixed page size option, SharePoint Designer cannot perfectly reproduce the environment of a web browser. To resolve this, SharePoint Designer provides the option to preview your page directly in web browsers.

Not only can a page be rendered differently in a browser than within SharePoint Designer, but different browsers and even different versions of the same browser have their own ways of rendering pages. It is best practice, therefore, to test your pages in each of the browsers you expect to view your site. SharePoint Designer's Preview in Browser function enables you to select an exact environment in which to test your pages. Figure 1-12 shows the Preview in Browser menu as selected from the icon in the Common toolbar.

Figure 1-12 [f0112.bmp]

Internet Explorer and Mozilla Firefox are automatically detected by SharePoint Designer if they are installed on your workstation. In addition, you can select any other installed browser for live preview. Follow these steps to add another browser to the preview list:

1. Select Preview in Browser@@>Edit Browser List. The Edit Browser List dialog box appears, as shown in Figure 1-13.

Figure 1-13

2. Click the Add button. The Add Browser dialog box appears (see Figure 1-14).

Figure 1-14

3. Type a name to represent the browser.

4. Click the Browse button to open the Add Browser window (see Figure 1-15), and navigate to the .exe file that starts the application. (You may need to look at the properties of the application’s launch icon to find the file location.)

Figure 1-15

5. Click Open, and then click OK on the other two dialogs.

Note: A page must be saved before it can be previewed in a web browser.

Professional Microsoft Office SharePoint Designer 2007

Woodrow W. Windischman, Bryan Phillips, Asif Rehmani

ISBN: 978-0-470-28761-3

You mean there are limits?!?

I had an interesting Twitter conversation recently. Someone was shocked when told that a single SharePoint server could handle tens of thousands of users. As an isolated point of fact, this is true.

But, there is a "but". And it is a huge one. Such support depends both upon what those users are doing, and what that SharePoint server is doing. Microsoft now has some excellent performance and capacity planning documents for SharePoint, and if you look at the one for WSS in a collaboration environment, you will see that even under their "heavy" usage scenario, up to 15k users could be supported. Dig a little deeper, however, and you notice a big assumption: only 2% of that usage is document management (DAV reading and writing).

Many people envision using SharePoint as a replacement for their regular network file shares. While there are any number of good articles pointing out why that isn't a good idea (at least not without some serious planning), they all rely on talking about the SharePoint side of things - stuff like the "2000 document limit" (which isn't really a hard-cap, but that's fodder for a whole different article). Even taking appropriate topology and taxonomy steps, heavy file-based SharePoint usage is going to significantly reduce the "rated" capacity of a SharePoint environment.

SharePoint Itself is Probably Not the Limiting Factor!

Yet with the "I can consolidate these file shares/servers into SharePoint" stars in their eyes, many of the reasons these separate systems exist in the first place are forgotten. In a non-SharePoint file-sharing scenario, would you envision 15,000 (or more) users accessing a single server, let alone a single file share within that server, on a day-to-day basis? Of course not! Now consider if the users are geographically spread out. Would you want to channel all of the current file-server usage in your remote offices through a single WAN link? Maybe you could consider it - if you have point-to-point fiber. But otherwise? I didn't think so.

So take SharePoint, which itself resides on a Windows server, and stores everything in SQL Server databases, and consider what an all-out consolidation would mean. The articles I linked to earlier can help you with the capacity and availability considerations for SharePoint itself, but don't forget that SharePoint is only one piece of the total puzzle. Your network, your geographical distribution, and other factors, need to play as large a role in your planning for SharePoint as they do with any other system in your enterprise.

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:

1. Registration for the event
2. 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".

1. 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:
   
2. Select a Web Part Zone, and cick the Add a Web Part link.
3. 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)
    
4. Once the part is added, click the "open the tool pane" link in the part:
   
5. Instead of clicking the "Rich Text Editor" button, we're going to click the "Source Editor" button.
   
6. The Source Editor is just a text entry window, with a Save and a Cancel button.
   
7. 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>
8. Click Save.
9. 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.
   
10. 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".

    <script language="javascript">
     var myHelpContext = '/MyHelpLib/MyHelp.aspx';
    function showMyHelpPage() {
     var width  = 500;
     var height = 400;
     var left   = (screen.width  - width)/2;
     var top    = (screen.height - height)/2;
     var params = 'width='+width+', height='+height;
     params += ', top='+top+', left='+left;
     params += ', directories=no';
     params += ', location=no';
     params += ', menubar=no';
     params += ', resizable=no';
     params += ', scrollbars=no';
     params += ', status=no';
     params += ', toolbar=no';
     newwin=window.open(myHelpContext,'MyApplicationHelp', params);
     }
     WPSC.RegisterForEvent("urn:schemas-microsoft-com:dhtml","onhelp",showMyHelpPage);
    </script>

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!

Note: This article is also available on the online blog/magazine - End User SharePoint...

Human beings are creatures of habit. Once we become accustomed to certain ways of doing things, we want to keep doing them, even if "something better" comes along. I firmly believe that SharePoint Designer is one of those something(s) better. So much so, that I wrote a book about it.

Microsoft Office SharePoint Designer 2007 is a very powerful editing tool for most of the files you can find on SharePoint sites. It includes fully integrated editors for HTML, ASPX, CSS, and various others, with features such as WYSIWYG and IntelliSense.

Yet, you may have your own favorite editor that you want to continue using for certain file types. Fortunately, SharePoint Designer gives you the option of configuring which editors are used for the different file types.

Opening with an Alternate Editor

When browsing through a site in SharePoint Designer, you double-click a file and it opens in the "default" editor. But you also have the option to right-click the file, and select "Open With", to display a list of the available editors configured for that file type.

Notice that you also have the option to "Choose Program..."

This produces the standard Windows file association (Open With) dialog, listing the programs available on your PC.

At the bottom of this dialog, you have some persistence choices. If you want to use your selected application to open the file "just this once", uncheck both boxes. If you want the program you select to always be available as an "Open With" option for the type of file you have highlighted, check the first box (Associate...). Finally, if you have chosen to associate the program with the file type, you are also given the choice to "Set as default", which means that SharePoint Designer will thereafter use that program any time you double-click on a file with that type.

Configuring Editors "en Masse"

You aren't limited to configuring your editors on a file-type by file-type basis. SharePoint Designer also gives you direct access to configuring the editors it uses. To get to that option, from the Tools menu, select the Application Options entry.

Note: There is also a "Page Editor Options" choice on the Tools menu. While intuitive, this actually is not the item you want. This choice is for configuring options in SharePoint Designer's built-in editor.

Once you have selected Application Options, click the Configure Editors tab. You will get the dialog shown below:

On the left is a list of file types (Extensions), and on the right are the editors associated with the currently selected type. Or types. Notice that for popular graphic files, several file types are listed together, separated by spaces.

Many Microsoft Office applications have the ability to save files as HTML. The checkbox at the bottom of the Configured Editors tab gives you a blanket option of letting SharePoint Designer invoke the creating application when you try to open a file.

You can add or delete extensions and editors using the or icons over the appropriate column. Clicking the add icon will summon an "Open With" dialog similar to the one shown earlier. For extensions, there is an additional field to enter the extension itself. The other difference is, since it is summoned from a dialog who's purpose is association, the association check-boxes are not present in these cases.

A Real-world Example

Let's say that you want to open graphic file formats with Adobe Photoshop. You would first highlight the graphic extensions as shown in the earlier dialog. Then click the add icon, and select Adobe Photoshop from the list of programs - browsing to its location on the file server, if needed.

When you click OK, it appears in the Editors list. You can then use the buttons in the dialog to change its presentation order, and/or set it to be the default editor for your graphics files (the top item in the list automatically becomes the default).

From that point forward, Photoshop will appear in your options for opening an image file, and if you set it as default, it will open automatically when you double-click one.

Summary

SharePoint Designer provides an array of powerful, built-in, editing tools for many different file types. Yet, you may have files in your site that SharePoint Designer cannot edit "out of the box", or for which SharePoint Designer's included support is weak. Maybe you have your own favorite editors. Rather than forcing you to change your habits, by allowing you to associate different applications with your files, SharePoint Designer adapts to you.

Driving Through Flyover Country

2008 should theoretically have been a boring year for SharePoint. The current version (WSS 3.0 and MOSS 2007) was released in 2006. The next version wouldn’t be out until 2009, if not later. The software equivalent of flyover country.

Yet, if you (like me) have actually driven through this so-called flyover country, you will know that there is a lot going on in that vast middle ground:

You have “tourist traps” like Wall Drug, and the Corn Palace.

You’ll find Natural wonders like Devil’s Tower, Wyoming, and of course Yellowstone. Legends like Deadwood, South Dakota – just a stone’s throw from that ultimate in stone carving – Mount Rushmore.

Not to mention the over-all beauty of this great land.

The same is true with SharePoint in 2008. In what could have been a year of coasting, those following The SharePoint Road found plenty to be excited about.

Among the sights:

• We welcomed a pair of new members to the family – Search Server, and the free Search Server Express
• Infrastructure Updates brought Search Server’s enhancements to MOSS, along with some much needed improvements to Content Management
• Not to mention, Service Packs and the other “normal” updates that occur.

But even more impressive than the evolution of the product itself has been the reaction of the community:

• SharePoint became a Billion Dollar Product.
• A huge ecosystem has grown up around SharePoint.
• Books, Add-ins, training, documentation, and other support material has proliferated

In fact, opportunities to get “up-close and personal” with key players in the SharePoint world have been many:

• The Microsoft SharePoint Conference 2008 was a sell-out, and had the greatest attendance of any SharePoint-only event to date.
• Beyond Microsoft, SharePoint Connections, and the SharePoint Best Practices conference were also huge hits.
• Users Groups and user-inspired events have sprung up everywhere, and are growing fast.

A taste of “14”. Some tidbits about the next version have come out recently:

• “Microsoft SharePoint Services” for the Cloud, shown as part of Windows Azure
• Fully interactive, web-based versions of Office applications. Will these be part of the SharePoint Family?

Looking Forward

So, you see, 2008 has been anything but boring in the SharePoint space. But what about next year? What does 2009 hold?

Predicting the future is never an exact science, but I think, even with the down economy, we can be certain that there will still be more excitement in the SharePoint world:

• More Conferences and Events:
  • Connections is a occurrence.
  • Of course, SharePoint will always be well-represented at Microsoft’s TechEd and the Professional Developers Conference (PDC).
  • The next Best Practices conference is the first week of February – Don’t Miss This one! (And I’m not just saying that because I’m going to present…)
• More Updates:
  • Service Pack 2 should be out early next year.
  • Constant growth in the number of add-ins available, both in the marketplace, and on CodePlex
• Betas? Customer Previews? The Real Deal? Well, I wouldn’t hold my breath on getting final code next year, but it wouldn’t surprise me at all to see something come out that we can play with.

There you have it. My version of a retrospective on 2008, and a look towards 2009. I hope you have enjoyed travelling the SharePoint road with me this year, and I hope to have you along for the ride next year!

Gift-wrapping Web Applications with the Page Viewer Web Part

With the Holidays upon us, everyone is putting things in boxes. Boxes are very convenient – they let you just drop something into them without having to change anything about the item being packaged.

As you start to deploy SharePoint in your organization, you will often find people wishing that they didn’t have to bounce from one web site to another all of the time. With Data Views, Search Federation, and other tools, you have seen how easy it is to get the information from other systems and applications into SharePoint. However, there are times when you just want to be able to get to another application directly within your SharePoint page.

Fortunately, there is a web part made just for such a situation – the Page Viewer Web Part. The Page Viewer is nothing more nor less than a box in which you can place and display content from another location.

You add a Page Viewer to your page just like any other Web Part.

The initial web part doesn’t have anything in it except instructions on how to add content:

Once you click the link to open the tool pane,

You can select a web page, a folder (file share), or specific file. Unlike some other web parts, this file is NOT accessed by the SharePoint server as an intermediary. It is retrieved and rendered directly by the user’s browser. Because of this, make sure you are specifying a location that is accessible from your expected users’ client PC’s.

Note: Technically, what you are doing is feeding an “iFrame” – essentially a browser within a browser.

You will probably want to adjust the settings of the "Appearance” section in order to make sure the web part is big enough to show the critical parts of the page you are selecting.

Then, once you hit “OK” and exit page edit mode, the external page is living happily inside your SharePoint site!

Of course, it is helpful if the site you are embedding in the Page Viewer offers a mode without a lot of extraneous “chrome”. Some applications offer a “portal mode” page, just for such usage.

So, that’s it. Very “back to basics”, but also potentially quite useful.

I hope you enjoy this little gift, in a little box, from SharePoint.

I wish you all a Merry Christmas!

"When it Absolutely, Positively, has to be Found."

One of the key features of Microsoft Office SharePoint Server 2007 (MOSS), and Microsoft Search Server 2008 (MSS) - including Express (MSSX), is Enterprise Search. What you may not realize is that SharePoint actually includes two fundamentally different mechanisms for providing search results to your users. I'm not talking about WSS versus MOSS/MSS search. Rather, I'm talking about a second, parallel, system that returns results to user queries - often on the same page as the "regular" search engine.

So, what is this "shadow" search mechanism? Keywords and Best Bets. Although you may have heard of them - possibly even used them on your sites - you probably didn't know that they were completely independent of your main Enterprise Search corpus. This independence brings with it a number of ramifications. While mostly positive, it is important to understand them in order to both avoid potential pitfalls, as well as take maximum advantage of this powerful capability.

Enterprise Search - Not Enough on its Own

Enterprise search is a great tool to help your users find the information they need; however, a search system alone cannot solve all problems related to true "Findability". Bill English's series on Findability and SharePoint details many other factors, such as corporate culture and information architecture, that play a major role. Still, the technology of search itself can be a limiting factor.

Most people are aware of how the basic search functionality works - you define a content source, and SharePoint crawls it - interpreting and indexing the contents of the files it encounters. Then, when your users enter a query into a form, the server looks in this index and returns results that match. Of course, this relies on several things being true. Among them:

• The information exists
• The information is in a content source being crawled
• The terms being queried are contained in the crawlable properties of the information
• The information has actually been crawled and compiled into the index at the time of the query (lag time)

Even where this is true, the user still may not actually "find" the information that is needed. Perhaps there are a large number of similar documents containing the chosen query term, or the desired term has special meaning in your organization, but is also used differently in other contexts. (This is also discussed in Bill's article series.)

Note that this weakness is not unique to SharePoint search. Any system you put into place - whether it is MOSS, the Big Yellow Box, or some other system - is going to be faced with the same issues. (While the others may also offer comparable capabilities, I'm focusing on the SharePoint/Search Server version here.)

All of this adds an element of risk to the search process. Like spinning the roulette wheel, you might hope you get the result you want, but there is always that element of doubt. Fortunately, in this case, you are actually "the House", and therefore have the ability to control the odds. In fact, you can stack the deck to ensure that the right information always comes out on top.

Place Your (Best) Bets!

The Keyword and Best Bets feature in SharePoint works very differently from the primary search. This is a completely manual system. You enter the terms you expect your users to use, and the results those terms should generate. No crawling, indexing or other "automated" processes need to take place. No services need to be reset. Results are available in queries immediately, and you know what the results will be, because you have defined them.

In many respects, this makes Keywords system more of a direct lookup system than a "search" system per se. But "search" is still the action your users perform, and "find the right information" is the desired result. Let's see how to make that happen.

Configuring Keywords and Best Bets

Keywords and Best Bets can be easily configured by a site collection owner. As always, you start with the Site Actions menu, and select Site Settings. Since Search is configured at the site collection level, if you are in a sub-site you will need to click through to "top level site settings" in order to get the page below.

Click the "Search Keywords" link. This will bring you to the Manage Keywords page.

The Manage Keywords page looks and operates much like a SharePoint list. You have the toolbar with its Add button, for example. Notice though, that it has a somewhat different search bar. Search can be very important here because you could end up generating a lot of keywords. The "where" dropdown gives you the ability to look up keywords various ways.

In addition, there are some predefined views listed in the Quick Launch area. These provided an appropriately reduced list based on information entered into the keyword definition. When you click Add Keyword, you are presented with this form, which is also used to edit existing keyword definitions.

Again, it looks a lot like any other list form in SharePoint.

There is only one required field - the keyword itself. Of course, a keyword alone doesn't do much to help your users. The Synonyms field allows you to register other terms your users might enter which should bring up the same results. For example, if your company president's name is "Selma Superior" you might have that as a keyword, with synonyms of CEO, Managing Director, President, or even Big Cheese. From that point on, any of these terms will return the entry associated with the keyword.

Note: Remember that the keyword/best bets system is independent of the primary search service. Synonyms you enter here will not affect regular results. To achieve a similar effect there, you need to edit the Thesaurus files on the SharePoint Servers.

Once you have used a term as a keyword or synonym, the system knows it has already been used, prevents you from using it again in another keyword definition. This can help you avoid creating ambiguous results.

The best bets are links to the actual pages or documents you want your users to find when they enter the keyword or its synonyms. When you click "Add Best Bet," you will see the form listed below.

In addition to the link itself, you can provide some descriptive text. You can have multiple best bets on a keyword. You can also associate the same best bet with multiple keywords. Using the earlier example, one of the Best Bets for the CEO might be the Executive Committee's Newsletter/Blog. That location could be equally valid for the CFO and CIO.

You can enter some descriptive text, which will be shown along with any matching results. You can also use the keyword feature for time-sensitive information by entering a start and end date for the keyword's display, and review date to ensure the content is still valid. The contact information allows you to distribute ownership of different keyword entries, as well as automatically notify people when entries are due for review.

The results from keywords and best bets are displayed on the default SharePoint results page above the results from the standard search.

The keyword search system has its own web parts for displaying results. If you are creating your own results page, you will need to add either a "Search Best Bets" or "High Confidence Results" web part to that page.

More Ways to use SharePoint Keywords and Best Bets

Earlier I pointed out that most of the fields in a keyword configuration are optional. While it is true that a keyword "by itself" isn't very useful, there are a lot of ways you can use keywords that go beyond highlighting particular pages and files in your corpus. This is one of the big benefits of the system being independent of the primary search. Here are just a few examples:

So, What's the Catch?

Of course there's a catch. Administration.

As a manual system, you need to be careful that information is not only entered correctly, but also maintained. If someone moves a document flagged in a best bet, you need to manually change the entry in the keyword system. You should be careful to include review dates and contact information on as many keywords as possible. Use the views provided for keywords that have expired or are due for review, and check them regularly.

Conclusion

The keyword and best bets system in SharePoint and Search Server gives you a powerful tool to increase the findability of information within your organization. However, it is not a panacea. Like any other aspect of SharePoint, it requires careful planning and long-term commitment to ensure that you get the most out of it. But if you double-down, do the legwork, and keep up with the maintenance, you will find you have a system that will put your users on a winning streak.

"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:

1. Wiki pages, by default, are basically one big rich text field, making screen shots easy to get and understand.
2. 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.

1. Extract the WSP from the ZIP file
2. Add the solution to SharePoint:
   stsadm -o addsolution -filename {path you extracted to}\RadEditorMOSS.wsp
3. 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.
4. 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:

1. Use RadEditor to edit List Items
2. 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

<tool name="MOSSLinkManager" />

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

<tool name="LinkManager" />

I would also add one of the following lines:

<tool name="AjaxSpellCheck" />

or

<tool name="SpellCheck" />

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?

I would like to thank Mike Gannotti for allowing me to be the first guest on his "Backseat Driving with Michael" video blog series. In this episode, I demonstrate one of the samples from my new book - Professional Microsoft Office SharePoint Designer 2007 - which should be hitting the shelves any day now. The example uses the Data View Web Part to create a "mash-up" between SharePoint and the Zune Social music service.

Click here to check it out!