Making Sense of the SharePoint World

Apr-212009

A Hidden Gem - the Preview Pane View in SharePoint

gems

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.

image

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.

image

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.

image

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

image

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

image

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

image

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

image

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

image

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:

image

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!


Published: Apr-21-09 | 4 Comments | 0 Links to this post
Tagged as: Administration, Customization, Design, Lists and Libraries, SharePoint, WSS

Apr-142009

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

MCj02337790000[1]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:

image

  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.

image

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:

image 

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:

image

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:

image

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:

image

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

Conclusion

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

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


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

Apr-62009

SharePoint Designer and Expression Web - Separated at Birth

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

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

NoSharePoint

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.

image image

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.

image

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.


Published: Apr-06-09 | 2 Comments | 0 Links to this post
Tagged as: Design, SharePoint Designer

Apr-32009

On Babies, Bathwater, and SharePoint Designer

MCPE02338_0000[1]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.

image

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.


Published: Apr-03-09 | 0 Comments | 0 Links to this post
Tagged as: Administration, Design, Governance, SharePoint Designer, SharePoint, WSS, Customization