SharePoint design

There are some tools that my son's hand. He is five years and frankly there is no reason why they do not want to work with chain saws. Occasionally we need a chainsaw to cut a tree or cut a fallen branch. But it is a tool that asked him to use.
I feel the same about SharePoint Designer (SPD) - in the hands of and under the right circumstances, can be a powerful tool that can save organizations money. However, in the hands of others, can be a bad influence that makes it more difficult for organizations that are well governed and that the system uses.
In this article we will walk through a high level summary of characteristics of the SPD and how these features should and should not be used. At the end of this article should be able to identify situations that may be useful SPD and identify situations where the use of SPD may be more a hindrance than a help.

HTML Design

Within the context of SharePoint how does this help? SharePoint is made on top of the ASP.NET 2.0 framework and accepts both a maser pages and web form pages. Master pages offer a way to make a consistent look and feel across the site. The individual web pages allow for various layouts and structures to support the needs of the content. SPD is a capable editor of both of these three core file types in SharePoint.

Perhaps the most obvious feature of SPD is seen from the position of its Front Page inheritance. Even the product's predecessors were HTML designers. They were designed to make the performance of editing HTML more usable for the masses. Over the years the tools have "grown up" to include professional-quality editing support. While there's competing products in the HTML editing space, SPD (and its sibling, Expression Web) has a solid set of tools for editing HTML.

When you are using Microsoft Office SharePoint Server (MOSS) there is a terminology modify to be aware of. MOSS includes a feature called web content management (WCM). In this feature, there's page layouts to consider. These page layouts are the templates that content is put in. They are -- in essence -- the same web form pages that you might edit directly. The key difference is that they contain content placeholders in to which content will be inserted by the WCM subsystem. So pages in Windows SharePoint Services (WSS) -- & non WCM MOSS sites -- are essentially the same as Page Layouts for WCM.

In addition to HTML editing, web-site design today is controlled by cascading style sheets (CSS). SPD is a lovely editor of CSS sheets as well. In the SharePoint world CSS is important because much of what is displayed is styled with CSS sheets. A great deal of customization of the look & feel can be done without ever editing a master page or a page itself.

From the perspective of working with SharePoint, SPD's key feature is probably its direct integration with SharePoint. It understands the APIs & what to do in order to get pages & content & how to return them safely to SharePoint. In this integration, there's, however, some hidden concerns.

Site Collections and Sites

Some of you may be aware that there is a distinction within SharePoint from a normal site, which a developer is more apt to call SPWeb, and a collection of sites, which a developer is able to call SPSite. The difference is that a site collection is an object of limits. It defines the boundaries of different APIs and also storage. A site collection can only be stored in a database of content. A site collection is the limit for many APIs - for example, quotas, content consulting, etc.