Introduction

As a Front-end Developer with a background in designing I’ll show you how to make a graphical design that works for a default SharePoint-environment. If you want to take control over the front-end, don’t use any themes. Create your art by using style sheets!

Not all graphical designs for a portal will work in a SharePoint environment. There are a couple of limitations the Graphical Designer must know. A Graphical designer needs to know the scope of the graphical design. For example, if a Graphical Designer puts a border on an element like a table, that will take him about 3 minutes to design, but this simple border could take the Front-end Developer a few hours to implement.

It’s really important that the Graphical Designer and the Front-end Developer work together and have a clear communication about the graphical design. Making a graphical design specifically for a MOSS environment could save you days on the implementation! This article will give the Graphical Designers more insight into the effect of these design decisions.

This article assumes that the reader has SharePoint and basic HTML knowledge.

Process description

Communication flows

The communication between the Graphical Designer and the Front-end Developer is all about the graphical design for SharePoint and the ways to implement it.  The Graphical Designer discusses the design he wants to make with the Front-end Developer to check if his design ideas are implementable on a SharePoint environment. After the Graphical Designer has a first version of the graphical design, the Front-end Developer determines if it can be implemented in the available time. If the actual costs are higher than the estimated costs, the Graphical Designer and the Front-end Developer could look for another elaboration of the customers idea, one that is easier to implement, and more predictable.

The communication between the Graphical Designer and the Front-end Developer will continue like this until the graphical design is approved by the customer and the implementation can start. The communication between the Graphical DesignerGraphical Designer has in mind for its design. Decisions concerning the colors, fonts, margins, menu’s and links are transferred by a style guide. However, if there’s a lack of time frequently the style guide isn’t fully developed, so the Graphical Designer needs to explain the Front-end Developer about the styling guides. Disadvantage of this is that the Front-end Developer co and the Front-end Developer will change and will all be about the transfer of knowledge about what can be implemented and what can’t. It is important that the Front-end Developer knows exactly what the uld forget information or interpret it differently than the Graphical Designer has in mind, and the Front-end Developer cannot check it in the style guide. Therefore, be sure that there is always a style guide that is as extended as possible.

What can happen after the graphical design is implemented is that the customer decides to change a component in the graphical design. Depending on the change, the Graphical Designer must be consulted again, or the Front-end Developer can modify it, in consultation with the Graphical Designer. The ideal situation is to adapt the style guide too.

The style guide is made by the Graphical Designer. Since he has made the design and knows exactly how the design should look like and elements graphically should behave. Beside the style guide the Front-end Developer also needs the design files of the Graphical Designer to be able to implement the Graphical Designer, for example the PSD files.

Image of default homepage

Knowledge transfer

The graphical design is based on the requirements of the customer and its company, depending on the browsers to use and its users, and of course the estimated capacity and the creative ideas of the Graphical Designer. Graphical Designers which design for MOSS must have knowledge of SharePoint. Most Graphical Designer’s will catch the default (blue) graphical design of a MOSS portal as a basis for the graphical design. They can take the default or frequently used elements of MOSS and use them for their graphical design. They keep the location of the elements approximately the same to what they see on the default portal, their example. This is the most common way to start a graphical design for MOSS.

The Graphical Designer also needs to have some knowledge about how the designed elements of the graphical design will be implemented. He needs to know how the Front-end Developer will implement a graphical design. Because the Graphical Designer does not know of every table, div and so, it is important that the Front-end Developer informs the Graphical Designer about the possibilities of implementation, however the Front-end Developer does need to have this knowledge of course. Even if the Graphical Designer used a default MOSS portal for making the graphical design, it is possible that there are elements in the graphical design that cannot be implemented on a default MOSS portal, because the default HTML won’t let you. That’s why it is very important to communicate a lot and involve the Front-end Developer at an early stage of the graphic design.

Design decisions

In this part I will evaluate some design decisions. I will comment on a number of standard components of a SharePoint publishing portal and indicate per component how the element’ HTML has been rendered and the possibilities for implementing a design on that HTML.

Scaling pages

The Graphical Designer needs to know how the page will behave if the visitor of the portal gives another format to the browser window. In case of a portal the Graphical Designer will generally recommend to use the complete width of the browser window, because portals are all about displaying lots of information. It is desirable to be able to use the full width to place as much information on the page as needed/possible, and make it liquid. This is default by MOSS, when widening the browser window, the middle column will become wider and more space for content will be available. The left column with the menu will keep its width, just like the right column.

However it is possible that the customer chooses to let the scaling behave differently. For example by dividing the available space to the left and right column. In this case the fixed width of the right column is put on a certain percentage in the style sheet instead of a fixed number of pixels, mostly 20 or 30%. The middle column should also get a width in a certain percentage. For making another partitioning it is desirable to make a custom page layout.

Example of page with variable width

Example of page with variable width

Example of page with variable width

Header

The area positioning on a page consists out of several rows. First there is the header, then a content area and then the footer. All visual elements of SharePoint are in one of those zones. The elements of the edit console are underneath the header, they will be discussed later.

The header itself is also built out of rows, with in every row a few SharePoint elements. In the header every row has a class name or unique ID name. The header is built with tables, and nested tables, who together are responsible for the area positioning.

Global breadcrumb

The global breadcrumb, which is the first row of the header, contains two tables, each with its own class name. This aligns the text to the left and the meta menu to the right. Therefore the global links on the left side and the global links on the right side can be styled and positioned differently.

Global breadcrumb

The menu items of the meta menu can be styled separately. However, frequently it is desirable to style all meta menu items the same. The styling can be done by using the class name of the common parent element. This way the styling isn’t influenced by any nested tables or divs that may be in the menu table.

Customized metamenu

.ms-SPLink a:link,
.ms-SPLink a:visited {
                color:green;
}

The icon that is used for the help function can be styled too. Just keep the width and height of the new image the same as the original, so that a replacement can be done easily. Always keep a copy of the original image, for back-up.

Global title area

The global title area is the second row of the header. It contains a table with three cells, the global title area image, the site title and the search function.

Global title area

The global title area image can be used to display the logo, because this element has a link with a reference to home. Therefore it is important to hide the image, stretch the a-tag to the dimensions of the logo and make the logo disappear as the background image of the <a>-tag. Then, the text of the <a>-tag will be placed outside the view of the browser with a negative indent. This way the logo will still have a textual link for users that use screen readers.

Global Title Area Image

.ms-globalTitleArea {
    background:blue url(/_layouts/images/logo.gif) no-repeat left top;
}

 .ms-globalTitleArea #GlobalTitleAreaImage img{
    visibility:hidden;
}

.ms-sitetitle h1 a{
    display:block;
    height:30px;
    width:100px;
    text-indent:-2000px;
}

The last cell with the search functionality doesn’t have a class name or ID. To style the search function you’ll need to dig deeper into the HTML-structure. It is possible to style the search function in the header differently than the other search functions that could appear on the portal, even if they are built the same way. That’s why you’ll need to find a unique class name combination or unique ID name or a combination of both. It is possible to style the search function in the header differently, but the other search functions, in the content zone will be styled the same, since they have the same structure. Do not style the search engine absolute, since the search engine needs to come down in the content zone when searching advanced.

#SRSB{
	position:relative;
	top:100px;
}

The icon that is used to start the search request can also be styled. Keep the width and height of the new image the same as the original, so that a replacement can be done easily. Always keep a copy of the original image, for back-up. The easiest way to style the icon is to replace the default one on the file server. A result of this is that all search icons will change, through the whole portal. As mentioned above, it is possible to style the search icon in the header differently, but the other search icons will be styled the same, since they have the same structure.

Customized search engine

Banner Container

The third row from above is the banner container or oneidtopnavbar container. In here is the banner frame wherein there is a section for the top navigation menu, the banner and the site actions menu.

Top navigation menu

The top navigation menu is built out of a table, whereof the first cell contains the first menu item and the second cell contains a set of other menu items. In each of these cells is a table with a class name that marks it as topnav and if selected, it marks it also as selected. In the first cell of this table is the a-tag, the link. If the menu item contains any child elements, there is a second cell in this table to place the little arrow pointing down. This arrow is an indicator for any child menu items available, the fly outs.

The <td>’s of this table do not have a unique class name combination or ID. This means the <td> of the text link cannot be styled differently than the <td> of the arrow. This could lead to difficulties when implementing background images on the menu items. A background image cannot be placed on the <td>, because this will cause it to disappear twice. Once for the text link <td> and once for the arrow td. The image must be placed as a background image on the table. This means the image will be visible underneath the text link all the way to the arrow on the right. So there can only be one background image on a menu item. It isn’t possible to use two images, like when the left side of the menu item has a different ending as the right side of the menu item, when the image isn’t repeatable on the x axis. It isn’t possible to make two images out of one, so make it a background image of the table. It is always unsure how wide the menu item will be, and so how wide the background image must be. The arrow is rendered by the code, so you cannot style the arrow or replace it with an image, though.

It is possible to give the first menu item a different styling then the others, because this menu item is considered as the top level menu item and is rendered a bit different then the other menu items. For this menu item also counts that you do not know how wide the menu item will be, so be cautious about it when making the graphical design.

If you need to use background images on the top navigation menu, use images that are repeatable on the x axis and have the same pattern at the outer left pixels and at the outer right pixels. This of course also counts for the hover states and active states of the menu items.

Next thing to style are the fly outs. These child menu items are inside a table, and there is one table, <tr> and <td> for every child menu item. Only the table has a class name, so all the <td>’s, that is all the child menu items will have the same styling. The menu item that has a mouse hover can be styled differently though. For the fly outs there is the same rule, you do not know how wide the content inside it will become. Use that information wisely when making the graphical design. You can use these class names to style the fly outs:

.ms-topNavFlyOutsContainer{}
.ms-topNavFlyOuts{}
.ms-topNavFlyOuts a{}
.ms-topNavFlyOutsHover{}
.ms-topNavFlyOutsHover a{}
.zz1_TopNavigationMenu_8 {}

Banner

The banner <td> is empty, and does not contain anything. Therefore, it will not be discussed here.

Site actions menu

The cell that contains the site action button has a table with a class name for its own. Inside that, there is one cell wherein there are different kinds of nested <div>’s. The a-tag inside does not have a class name or ID, just like the nested <div>’s. But it could be referenced using this declaration:

Default siteactions button

.ms-siteactionsmenu div div div a {...}

The site action button usually isn’t restyled, but only made blank, by removing its colors and background image. Most of the time it is repositioned by giving the table a relative or absolute position. This button is only visible for users with editor rights, so only a select group of users will see the site actions button.

Customized site actions button

.ms-siteactionsmenu div div div,
.ms-siteactionsmenu div div div.ms-siteactionsmenuhover{
    background-color:transparent;
    background-image:none;
    background-repeat:no-repeat;
    border:0px none;
}

The fly out of the site actions button is a default SharePoint fly out, and usually isn’t styled. This fly out is reused throughout the whole portal, so styling it could give some unwanted results. In the next part, I’ll tell more about the menu’s and fly outs.

Web part zones

Underneath the header is the content part. In here are the left menu and the content container. The number of web part zones in the content container depends on which page layout is chosen when creating the page. Most of the page layouts contain two columns, a wide one in the middle and a smaller one on the right. Other page layouts do not contain a left or right column, just one big zone for the content.

Page layout

The partitioning of the web part zones depends on the page layout that is chosen. There are a few default page layouts in SharePoint, but these can easily be made custom.

Not all the default page  layouts have got a left and right separation; some page layouts use the whole width to show the content. The page layouts that do have a partitioning, not always do have a class name or ID on the <td> that separates the zones. The page is then partitioned by a table with two or more columns, were for example the first cell has a hard coded width of 70% and the second cell a hard coded width of 30%. If the cells do not contain a class name or ID, you cannot overrule the width and it makes it impossible to style them separately or give them another width.

Example of page layout with variable widths

Since these class names and ID’s are the hand dishes for the styling, it makes it difficult to style a particular column or web part zone. Not only the width but also the other styling like headers, links and content could need to be styled differently, dependent on which column or zone they are in. Creating a custom page layout has the advantage that you can style the columns or web part zones differently.

Web part zone

Except the fact that a columns separation can be made easily when creating custom page layouts, web part zones can be added if wished. It is possible to provide every web part zone width a class name or ID, which means that the web parts can be styled differently depending on the web part zone they are in. If web parts are dragged to another web part zone, they will adjust to the styling of that particular web part zone.

Two column page with two web part zones in the right zone

This cannot be done with SharePoint’s default page layouts. So if there’s no budget for creating page layouts, the Graphical Designer should take notice of that and style all the web parts the same. By default there’s no way to separate styling for particular web parts or web parts in particular columns.

Two column page with one web part zone in the right zone

Footer

The content container contains the columns with web part zones and the menu and is as wide as the whole page. Underneath this container is the footer. By default, SharePoint does not have a real footer. Actually there are a few table cells, which make the optical margin, just like the left and right margin of the page. These cells can be used to create a footer.

Position of the footer

The lower down cells of the page, the footer, always are down under on the page. Even if the page does not contain a lot of content and the content does not fill the page, the footer is always at the bottom of the page, against your browser window. It speaks for itself that the footer is also on the bottom of the page when there is a lot of content and the used needs to scroll.

The footer sticks to the browser

The footer is built like this:

Page Bottom Margin Left

Page Bottom margin

Body Area Page Margin

Page Bottom Margin Right

When you remove the background color and image of these cells, you’ll keep an empty space, which is a nice margin for the bottom of the page. It is also possible to use these cells for a footer image.

Example of footer with rounded corners

Since every cell has its own class name, it is possible to make a colored bar for example with small rounded corners. Such a footer can be placed underneath the menu and content, or just underneath the content. The width of the image depends on the cells you use to display the image in, as a background image. The height of the footer is also adjustable. To place text in the footer, the master page must be edited. Making the master page custom allows you to make the custom footer instead of using the default margin cells at the bottom of the page.

Next time in “SharePoint’s Branding Limitations”

Part two of this article will contain information about the menus. The meta menu and the top navigation with fly outs in the header and the quick launch menu and site actions menu. What are the possibilities for styling this menu’s? And how is it implemented? Stay tuned!

This post is from the SharePoint Magazine Partner Spotlight Week, where our featued partner is Tam Tam