SharePoint Designer includes a broad array of features and functions that make it a powerful tool, not only to "make it look less like SharePoint," but also to leverage and build upon a number of SharePoint's features. What does that mean? What is SharePoint? Remember that you (or your clients) are implementing SharePoint for a reason. In your efforts to customize its look, you must be sure you retain its feel — its core capabilities.
Many SharePoint elements can be configured to some extent through the web interface. Although you will have a much greater capability to customize them in SharePoint Designer, understanding this built-in functionality gives you a better foundation for your construction. Some of the useful building blocks you will find in SharePoint include its
Basic structure
Lists and libraries
Web parts
Navigation
Site management
Server architecture
On the surface, SharePoint is a fully functional web application. Out of the box, you get pages you can browse, places you can put information, and many ways to get that information back out again. Figure B-1 shows a basic SharePoint site.
Scratch that surface, and you find a whole lot more, including the capability to define new forms of information, to pick and choose what gets displayed on a page, and to create new pages. You can do it all without programming or even leaving the friendly confines of your web browser.
The first instinct of many web designers new to SharePoint is to create a site the way they always have, and then try to graft on bits and pieces of SharePoint functionality. Although that approach can create sites that are functional, it often presents challenges for maintainability, future expansion, and consistency.
SharePoint provides a number of functions for you (refer to Figure B-1):
Global navigation
Site-level navigation
Breadcrumbs
Personalization and social functions
Site and page titles
Logos and other branding
Administrative functions
Search
Site content
These are all features needed by virtually every website in one form or another. The default cosmetic aspects of these features may not be to your liking, but that doesn't mean you have to scrap them. This book shows you how to change those cosmetics without discarding and rebuilding the features themselves.
At its basic level, virtually everything that is displayed in a SharePoint site comes out of a list. A list is much like a database table, in that it is made up of rows of data, which in turn are composed of fields of different types. Many types of lists are predefined in SharePoint, but they fall into two main categories. One is simply called the list. The rows of a list are called items. The other category is the library. The fundamental difference is that a library's principal row element is a file, or document.
Almost any list can have a file as an attachment, but in those cases, the individual fields of the list are primary, and the attachment is just another piece of data in the list. In the case of the library, however, the file is considered the core element, and the fields are considered properties or metadata for that document.
Note
Although thinking of lists and libraries as tables is convenient for management and display purposes, their architectures are very different, as described in more detail in Chapter 6.
Depending on the template or site definition used to create a SharePoint site, certain lists are automatically created. The home page displayed in Figure B-1 shows several lists and libraries in the left navigation bar (also called the Quick Launch bar). You can access these lists through Quick Launch, or place views of these lists (or any others that might be defined on the site) in the content zones of a page.
You are not stuck with the lists and libraries created by default in a site. You can create new lists and libraries and delete existing ones at any time. When creating a new list or library, you can choose from several standard and custom types, and elect whether to display a link to it on the Quick Launch. In addition, you can display information from diverse sources both inside and outside of your enterprise with external lists based on the SharePoint Business Connectivity Services (see Chapter 7 for more about these).
SharePoint provides a number of standard list types. Anyone with sufficient rights can add new lists to a site at any time. The particular list types available depend on a number of factors, including the edition of SharePoint installed, the features activated, and the template used for the site. Figure B-2 shows some typical list types available in SharePoint 2010.
The page in Figure B-2 was accessed from Site Actions
Although they share many common elements, each list and library type has some unique characteristics — such as predefined fields, views, and custom actions that can be performed automatically on its items. For example, one of the most commonly used library types is the document library, which is primarily designed to contain documents such as those produced by word-processing, spreadsheet, and presentation applications, or final-form files such as Adobe PDF. It includes features suitable for that task, such as versioning, check-in, and check-out. The Shared Documents library in the default site shown earlier is a document library. Other list and library types may be available in your particular installation of SharePoint.
After a list or library has been created, it contains a number of characteristics that you can customize. You may alter some of the ones you need on a "day-to-day" basis via the ribbon. Figure B-3 shows the Library ribbon tab. In addition to the settings, the Library (or List, as appropriate) tab gives you quick access to many connection and sharing options.
Other settings don't need to be changed as often and are available through the List or Library Settings icon on the ribbon. Clicking this icon summons a page upon which these settings are arrayed, as shown for a document library in Figure B-4. Other lists and libraries may have other options available.
Although you can do a lot of customization through the web interface, certain settings, including hiding particular lists or libraries, can be set only through SharePoint Designer. They are discussed throughout the main part of the book. Some settings can only be changed in the web interface, and some settings can be changed in either place, though not all options may be equally available.
Each list or library contains certain default columns. Yousing them as is. Just as you can add and remove lists or libraries from a site, you can also easily add and remove most columns.
Note
You cannot remove key identity columns, such as ID and Title (Name in some lists), and administrative columns, such as Modified By, from a list or library.
You can add or remove columns via the web interface, as well as through SharePoint Designer. Figure B-5 shows some of the column types available out of the box. The available types may vary based upon the list or library template. You also can create and deploy custom column types via SharePoint features.
In a database, each table is defined with a particular schema, or set of columns. If you want to store a different kind of information, you use a different table. In SharePoint, you can store information with more than one schema in a single list or library, through a mechanism called content types.
SharePoint content types enable you to define a schema for a particular type of object, such as a news article or a contact, and use it wherever it makes sense in your site. Consider an inventory application for a hardware store. You can create a single list for your stock that includes a content type for paint, which includes columns for latex and oil base, color, and interior or exterior application, whereas a content type for lumber might include the type of wood, dimensions, and so on.
Each content type can have its own entry forms and workflow associated with it. When you create or edit items with different content types, the appropriate form — with the fields defined for that type — is shown. You can also create custom forms for individual content types.
Information from lists and libraries is typically presented in a view. A view consists of selected information from a list or library, presented in a particular way. You can choose a subset of columns, filter and group data, or even change the format of the information. Figures B-6 and B-7 show two very different views of the same data. You can apply several predefined view styles to various lists. You can present almost any list with a date column, for example, as a calendar.
One of the powerful features of SharePoint is the capability to personalize the user experience. To that end, a user can create views to be either public or private. A sales manager, for example, might want to see information grouped by region and ordered by total sales, whereas an individual sales rep would need a view showing the details of her closings for the month and would not be allowed to see the details for the other representatives.
Web parts are one of the primary means by which content is displayed in SharePoint. Publishing pages use a slightly different model, called layout pages. A web part may display static content, a view of a list or library, the interface for a business application, or virtually anything else.
A typical page in SharePoint consists of content zones into which a user may enter text, images, or place any of the web parts available on the site. Several page templates are provided with SharePoint, with varying sizes and positions of zones.
Figure B-8 shows a page in edit mode.
Like list views, most SharePoint pages can have a public and a personal view. You edit the public view by selecting Site Actions
Adding a web part to a content zone is as simple as clicking the Editing Tools Insert tab, then clicking the Web Part icon. You may then select from the many parts that may be available on your site, as shown in Figure B-9.
Note
You can have multiple instances of the same web part on a page.
After you add a web part to a zone, you can change its properties by selecting the web part contextual tab. Figure B-10 shows many of the contextual tabs available when editing a web part within a content zone.
Depending upon the web part, some properties can be set only through the web interface, and others may only be available, or offer significantly easier control, when using SharePoint Designer.
Web parts are more than just static display containers. Many web parts support an interpart communications mechanism called web part connections. Web part connections allow you to use the contents of one web part to affect the data displayed in another.
For example, selecting a client's name from a drop-down menu can filter lists of orders, contacts, and service calls. As long as all the parts support connections, it does not matter what the source of the data is — SharePoint, XML, or your corporate Customer Relationship Management (CRM) system. This allows heterogeneous applications to be developed with little or no code. Some people refer to this kind of application development as a mashup.
When combined with the Data View Web Part and SharePoint Designer, web part connections provide an easy yet powerful way to provide rich functionality to your users. Chapter 10 describes web part connections in detail.
In addition to editing pages and web parts, the designated owner can manage many elements of a site without the assistance of a server administrator or web designer. Figure B-11 shows the main settings page of a SharePoint site. You access the page with these functions through Site Actions
This book is not about SharePoint administration, so you don't need to worry about all the items on the list. Clearly, though, the user can manage many aspects of his site, from permissions to creating reports to determining the hierarchy of the sites in the collection. This section looks at how some of these administrative elements can (and should) play a crucial role in how you approach the design and customization of a SharePoint site. In particular, you'll see how you can simplify ongoing site maintenance by leveraging SharePoint's user management, navigation, and resource galleries.
One of the most important functions that you can delegate to site owners is the management of permissions for their sites. Most functions in SharePoint feature security trimming. This means that user interface elements are hidden for users who do not have permission to access the underlying data or function. For example, a site owner can typically see everything on the site, including administration and control functions. An average user, on the other hand, might see a subset of the content, and no administration features. Figure B-12 shows the site owner's view, while Figure B-13 shows the same site as viewed by a visitor. Note that in Figure B-13, the user has no access to the PermitRevenueYTD workbook or the Executive Summit site.
By making use of the standard SharePoint controls in your designs, you inherit this trimming, which makes site maintenance much easier in the long run, because you will not have to create separate pages for each user or role. Chapter 4 shows you how to incorporate security trimming controls into your site designs.
SharePoint can use any of the authentication methods supported by ASP.NET, including Windows-integrated, forms, LDAP, and even claims-based authentication.
Although configuration of authentication mechanisms is beyond the scope of this book, be aware that each membership provider requires its own web application zone to be configured (that is, Windows authentication on http://http://intranet, and forms authentication on http://intranet.pro-spd.com). Each zone will serve the same content. Therefore, wherever possible, avoid hard-coding server names into your pages when linking to other pages in the same namespace. Instead, use root relative references (that is, use "/sites/finance/default.aspx" rather than "http://intrantet/sites/finance/default.aspx") in your links.
Note
When using claims-based authentication, you can serve multiple zones without "extending" the web application.
Regardless of the authentication method, you assign permissions to users the same way. When assigning permissions to a resource, whether it is a list item or an entire site, you typically manually enter users' IDs into a web dialog, as shown in Figure B-14.
After you enter IDs, you can verify them against your membership providers by clicking the Check Names icon. If you are not sure of a user's ID, SharePoint provides a standard user browser, accessed by the Browse icon. Clicking that icon summons the People and Groups selector, which enables you to select users from whatever authentication providers may be installed, simply by entering a portion of the user's name. Figure B-15 shows the People and Groups selector window.
The most convenient way to manage permissions on a SharePoint site is by assigning users to groups. These may be groups created in your role provider. You can also use the dialogs described in the previous section to assign users or role provider groups to SharePoint groups, which are created within a SharePoint site and used to grant access to particular resources. For example, someone in a Site Members group might have permissions to modify the content of lists and libraries, but not to make any changes to their structure. The Site Visitors group might have read-only access to most of the site, but added permission to post to discussion boards.
Groups are each assigned permission levels — a set of default permissions constructed from a broad spectrum of rights that apply across the entire site, except where explicitly overridden.
Note
SharePoint groups are distinct from any groups that may be defined in your ASP.NET membership or role providers (for example, Windows domain groups), but may contain such groups as members.
When you create a SharePoint site, you also have the option to create certain groups and permission levels by default. The exact items created will depend upon the version of SharePoint and the type of site being provisioned. You can then add to, remove from, or edit the items in these lists. Figure B-16 shows a selection of groups created by SharePoint Server 2010 for a typical publishing site.
The default description shows the permission level associated with the group. You can see the groups available on your own site by starting from the Site Settings page, clicking the People and Groups link, and then clicking the Groups section header in the Quick Launch bar.
Note
The permission levels Full Control and Limited Access are defined by SharePoint and you cannot edit them.
Almost all sites require navigation, and SharePoint provides two primary navigation hierarchies: a global navigation bar, represented by default as a tab strip below the site title, and local navigation, represented by the groups of related elements in the Quick Launch bar, on the left of the page.
SharePoint provides a built-in capability for site owners to modify the items and their order. Figure B-17 shows the editor for the Quick Launch bar on a SharePoint Foundation site. SharePoint Server publishing sites have a more extensive editing capability. In particular, publishing sites support the easy editing of two-level navigation.
By retaining and styling the elements provided by SharePoint to match your vision, you can save yourself a lot of work when your customer comes back to you in six months saying, "I need to change 'Widget Construction' to 'Gizmo Assembly.'" In the case of navigation, this can simply be changed by the user in the navigation screens just described. On publishing sites, you can also create reusable content, which, when edited, will propagate to all pages in which that content is used. Chapter 5 shows you how to customize the look of these standard menus.
There are a few other "branding" related elements your users can control from the Look and Feel section of the Site Settings page.
The Site icon is the picture that (by default) appears to the left of the site title in the page header. Changing the image used is as simple as entering the URL of the preferred image in the Title, Description, and Icon form, accessed through the Title, Description, and Icon link. Of course, the text of the site title is edited on the same form.
The other key item to notice in this section is the Site Theme option. A SharePoint theme is a collection of images and Cascading Style Sheets (CSS) files that can be applied to a site at any time. Users can import theme definitions from Microsoft PowerPoint, and apply them to your site. Making your own styling elements compatible with this theming system is also possible.
You can easily make both subtle and drastic changes to virtually any element on a page. As long as those changes can be implemented via CSS, all of SharePoint's functions will operate correctly. CSS also offers powerful layout capability, which you can leverage in SharePoint Designer. Chapters 3 and 5 show you how to create and deploy custom CSS, themes, and master pages to brand a site thoroughly while letting your users manage them with all of SharePoint's power.
SharePoint galleries are lists or libraries of elements that are used throughout a site. Some galleries apply to an entire site collection, whereas others apply only to the current site and its children.
As a web designer, the galleries list most relevant to you is the Master Pages gallery. This gallery is essentially a specialized document library designed to hold — surprise! — master pages. Site owners can upload any number of customized master pages, which can then be applied to the content of the site. Other galleries relevant to users of SharePoint Designer are those for content types, site and list templates, and web parts.
After you make changes to a list or a site, whether through the web interface or in SharePoint Designer, you can save your changes as a template, either with or without data (content). These templates automatically go into the site collection's list or site template gallery, as appropriate. Site templates and exported workflows are stored as SharePoint Solution (.WSP) files, which you can transport to other sites directly, or even import into Visual Studio 2010 for further development.
Note
Site and list templates are keyed to site definitions and features. A site template can only be instantiated on a server that has the site definition upon which it is based installed. In addition, any additional features used by the template must be installed and activated. A list template can only be installed on a site that has the features the list depends upon activated.
As you have seen, SharePoint presents a consistent, unified face to its users and site owners. That all changes when you get to the server; it is here that the long and varied history, described in Appendix A, surfaces in the many different methods used to perform individual tasks. Although most common administration can be performed through the Central Administration web interface, other tasks can best be performed by editing configuration files manually, or using the SharePoint command-line tool STSADM.EXE. Still other tasks require some combination of these methods.
Also, SharePoint now fully supports the PowerShell command line management console. A vast library of commandlets is provided out of the box, making virtually the entire SharePoint API available to administrative scripting.
Again, the purpose of this book is not to explain all the nuances of SharePoint administration; however, you need to know certain things to make appropriate customization choices. This section presents an overview of a SharePoint Server farm. Details of particular configuration tasks are provided as needed throughout the rest of the book.
SharePoint Central Administration is the primary control panel for a SharePoint Server farm. Figure B-18 shows the Central Administration home page. If you think it looks a lot like a SharePoint site, you're right!
The Central Administration site is a custom SharePoint web application, created automatically with a random TCP port on the first server configured in your farm. It is called a farm because SharePoint's functions can be spread across multiple servers for performance and resilience.
Note
Even if SharePoint is configured on a single server, that one system is still referred to as a farm.
Although the exact functions available in Central Administration depend on which edition of SharePoint you have installed, these functions will be logically arranged in groups similar to those in the screen shot.
Many elements of SharePoint, such as search and Office web applications are managed through service applications. Service applications are functions that can be shared across multiple web applications, or even multiple SharePoint farms.
The Application Management section of Central Administration contains many functions relevant to SharePoint site customization. In particular, it enables you to create and manage the web applications and site collections that make up your SharePoint site. A web application is the logical top-level container for SharePoint content. A SharePoint farm hosts one or more web applications. Each web application contains one or more site collections.
Site collections are the primary units of granularity in the overall scheme of SharePoint administration. A site collection has its own permission groups, template galleries, and navigation hierarchy. Site collections cannot be split across content databases. In addition, the site collection is the smallest unit that can be backed up or restored with full fidelity. Most important, from the standpoint of this book, a site collection is the scope that can be browsed easily in SharePoint Designer.
Each site collection contains one or more sites or webs. The site is the working unit of SharePoint, containing the pages, lists, and libraries used to present content to your users. The first site created in a site collection is called the root. This root web has certain unique properties. For example, the root web of a site collection is where the site and list template galleries are stored. The root web may contain zero or more child webs, which in turn may be nested to an arbitrary level. Figure B-19 illustrates the logical hierarchy of content in a SharePoint farm.
The physical layout of files on a SharePoint server bears no resemblance at all to the logical content hierarchy described in the previous section. In fact, files critical to the operation of SharePoint are stored in up to four locations on the server, and that doesn't even count the databases! These four areas, in increasing order of relevance to the web designer, are:
The SharePoint installation directory — This is selected at install time for some editions of SharePoint Server.
The Windows Global Assembly Cache (GAC) — Typically this is C:WindowsAssembly.
The SharePoint website root — By default this is C:inetpubwwwrootwssVirtualDirectories.
The SharePoint root — Typically this is C:Program FilesCommon FilesMicrosoft Sharedweb server extensions14.
Note
Ironically, the path containing the files you most likely need to manipulate is the longest path. Even more, the SharePoint root itself contains very complicated folder structure, most of which resides in the .14TEMPLATE subtree.
Chapter 3 describes in detail the hybrid nature of serving SharePoint files, with each page being assembled at service time from a combination of information stored on the file system and in the content database. The TEMPLATE subtree contains the portions that are served from the file system.
Warning
Never open the files in the TEMPLATE subtree directly from the disk with SharePoint Designer. Many of these files contain tokens that only make sense to SharePoint Designer when opened in the context of a website, as preprocessed by the SharePoint server. When they are opened outside of this context, SharePoint Designer attempts to treat them as if they were on a website, and save them incorrectly, resulting in a corrupt template file.
With all the files and locations mentioned in the previous section, you might think that your content has to be in there someplace. Well, it isn't. At its heart, SharePoint is a database application, and it doesn't stop with just your content.
SharePoint uses several types of databases. The primary types you need to recognize are:
Content databases — These store all of your lists, documents, user details, and virtually everything else that exists inside your sites.
Configuration database — This contains most of the information related to the configuration of the SharePoint environment, as well as detailed information about your sites.
These databases can be stored on virtually any available SQL server in your environment, as long as it is running at least SQL Server 2005 with the latest service pack. The many factors involved in the selection and configuration of a SQL Server environment are beyond the scope of this book.
Alternatively, SharePoint itself ships with a limited version of SQL Server — SQL Server Express — which is used in the case of a Basic or Trial install. If this option is selected, the SQL databases for this edition are stored in a branch of the SharePoint installation directory.
The main things to remember about the configuration database are as follow:
Only one configuration database exists per SharePoint Server farm, and it defines the farm.
The configuration database is created when the farm is first installed, and cannot be changed, although it can be moved to a different server in most cases, with some effort.
The configuration database can be backed up, but not restored under normal circumstances.
All the site-specific information that is presented to your users comes from the content databases. Although one content database per web application is created by default, you can add more at any time. At minimum, each content database in use contains the information for a complete site collection — including its root and any child webs that may be created. If multiple content databases are created for a web application, new site collections are allocated to content databases in an unpredictable order, until the configured maximum number of collections for a particular database is reached.
Note
There is one exception to this unpredictability. If one content database has more "availability" (the difference between the existing, and maximum configured, number of site collections) than any other, and is not read-only, it will always be selected to host the next site collection you create.
Earlier this appendix mentioned how SharePoint lists and libraries, to a large extent, behave like database tables. Back in SharePoint Team Services (described in Appendix A), the metadata for each list and library was actually stored as a distinct table in a database; WSS 2.0 and SPS 2003 changed that, and introduced the content database structure that is still used — in expanded form — by SharePoint today.
In current versions of SharePoint, all fields, from every list and library, in every site, are stored in a single table. This table is preconfigured with every possible column/field, which may be defined in a SharePoint list or library. In WSS 2.0/SPS 2003, this resulted in hard limits to the number of fields of any given type that could be created. In later versions, the schema has been updated to use multiple AllUserData rows for each list or library item if more fields of a particular type than particular type than were predefined are required.
Because of this unusual, highly denormalized schema, direct user access to the database is problematic. In fact, direct access to any SharePoint database (except the reporting database) is considered unsupported by Microsoft in most cases, and is highly discouraged in the one case that is supportable (nonexclusive read-only queries).
One result of this architecture is of keen interest to web designers. A performance issue with the rendering (but not the querying) of large result sets can occur. In earlier versions of SharePoint, some people called this "The 2000 Item Limit." SharePoint 2010 includes several mechanisms that both raise this "limit," and make it far less likely for your users to hit it. The key thing to remember is that any large dataset renders more slowly than a smaller one. Use caution when designing pages and web parts that may result in large numbers of items being returned.