Making Sense of the SharePoint World

Jan-262009

Configuring Page Sizes and Browser Preview in SharePoint Designer

287613 cover.indd

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.

clip_image002[18]
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.

clip_image004[6]
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.

clip_image006[6]
Figure 1-13

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

clip_image008[6]
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.)

clip_image010[6]
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.

287613 cover.indd

Professional Microsoft Office SharePoint Designer 2007

Woodrow W. Windischman, Bryan Phillips, Asif Rehmani

ISBN: 978-0-470-28761-3


Jan-232009

SharePoint and the Laws of Physics

MCj02871310000[1]

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!

Getting your data from point to point over a WAN is channel limited, not SharePoint limited.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.


Jan-142009

Press F1 - SharePoint Help is on the Way

MCBD19644_0000[1]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:
    image
  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)
    image 
  4. Once the part is added, click the "open the tool pane" link in the part:
    image
  5. Instead of clicking the "Rich Text Editor" button, we're going to click the "Source Editor" button.
    image
  6. The Source Editor is just a text entry window, with a Save and a Cancel button.
    image
  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.
    image
  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:

    <script language="javascript">
     myHelpContext = '/MyHelpLib/ThisPageHelp.aspx';
    </script>

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!


Jan-82009

Selecting Editors in SharePoint Designer

MCj00885680000[1]

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.

image

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.

image

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:

image

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 image or image 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.

image

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

image

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.

image 

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.