Microsoft Enterprise Content Management (ECM) Team Blog : Customer Evidence

Building a real world extranet application with MOSS 2007 (Part 2 of 3)

ecmblog — Wed, 07 Mar 2007 08:43:38 GMT

Introduction

In the first installment of this blog series, we introduced the project and its requirements and started creating the basic site and content structure. In this installment, we’ll cover the customization and branding choices that we made, venture into the slightly gray areas that needed some additional thinking, and discuss some of our “off the beaten path” customization tactics.

Site and content customization (i.e. branding)

The new file management system was to replace an existing model, which users were already familiar with. This coupled with the fact that an already well established corporate brand existed meant that creating a consistent and familiar experience would be very important towards encouraging speedy user adoption of and efficient transition to the new system.

Once the UI was established visually, we began the process of matching best practices with both customer requirements and the new MOSS 2007 design and development experience.

The customization process was divided into two major sections in an attempt to offer maximum scalability while separating the majority of presentation from the content and code base.

Master Page Customization
Cascading Style Sheet Customization

The art of creating a custom Master Page in MOSS 2007

MOSS 2007 adopted the ASP.NET 2.0 master pages model, a model which allows you to separate the chrome (UI elements) from the content. The second major benefit of using master pages in MOSS 2007 is that you can control the UI of a site or entire site collection with a single page, the master page.

Before creating our custom Master Page, it was important for us to fully understand the following concepts:

Content Place Holders and Content Controls, and how they are used in MOSS 2007

There are several pages behind a rendered page that you would see in SharePoint. The Master Page which holds the UI chrome as well as content place holders where content can later be “plugged in” from other pages. These other pages, known as Content Pages have Content Controls with IDs matching those on the placeholders in the master page.
When requested, the content from the Content Control is merged into the Content Place Holder of the Master Page, finally presenting you with a single rendered page. Understanding this concept is very important when customizing a Master Page because removal of a content place holder that is later called on will result in an error. It’s important the content place holders exist on the page – even if not visible. For a list of content place holders, which reside in the default Master Page of a SharePoint site, see http://msdn2.microsoft.com/en-us/library/ms467402.aspx.

Creating a minimal Master Page

Unlike standard design, there is no blank slate from which to start a site in SharePoint. There is no magic “File New” button in SharePoint Designer 2007 that will allow you to just begin coding your UI and have the SharePoint functionality just work. Instead, you will need to understand how to work with SharePoint’s default Master Page and to minimize it by leaving only the placeholders that are required for SharePoint to function. Luckily for us, MSDN has been kind enough to post a minimal Master Page complete with comments, which you can use as a starting point for your own sites: http://msdn2.microsoft.com/en-us/library/aa660698.aspx.

Armed with information on the preceding topics and the tool of choice, SharePoint Designer 2007, we set out to create our custom branded application. SharePoint Designer 2007 allows you to connect to and work with your SharePoint sites, so the first thing we did was fire up SharePoint Designer 2007 and connected to our site via the File, Open Site menu.

MOSS 2007 introduces a new concept of “publishing features”. Publishing features represent the CMS 2002 integration into SharePoint, now known as Web Content Management or WCM. When enabled, publishing features allow you to do things like enable content approval workflow or change the Master Page and style sheet on the fly, both of which we utilized and proved useful in creating a custom branded application.

After combining our custom UI (graphics and code) with the minimal Master Page from MSDN, we uploaded our custom Master Page to the _catalogs/masterpage folder. This is a good time to point out that with a blank starting Master Page (and page layouts), we were able to vastly reduce the number of tables, and take advantage of our CSS based UI.

After uploading our custom Master Page, we added some final tweaks such as adding the company logo to the Master Page. While there is an out of the box method for adding a logo (Site Settings > Title, Description and Icon), doing this does not automatically carry the logo down to new sub-sites as they are created; instead, you would need to re-specify the logo on each site. This is by design just in case you want to specify a different logo on the subsites, which normally makes perfect sense, but in our project, a requirement was that all sites are to be created using the parent company’s corporate logo unless otherwise specified. To accomplish this, we created a custom picture library labeled “site images” and uploaded the corporate logo (named companylogo.gif) to the library. Next we replaced the default mechanism for switching the logo in the Master Page:

<SharePoint:SiteLogoImage id="onetidHeadbnnr0" LogoImageUrl="/_layouts/images/titlegraphic.gif" runat="server"/>

replacing it with some key new functionality in SharePoint 2007:

<asp:Image runat="server" id="Logo" ImageUrl="<% $SPUrl: ~site/site images/companylogo.gif %>"/>

What this change does is tell the image control to check in the site’s site images library for companylogo.gif. Because this is specified in the Master Page, the change is seen on subsites, which inherit this Master Page. Also, because we have specified the “site” site images library in SPURL, changing the company logo on a sub site is simply a matter of over writing the default companylogo.gif image in the specific site's site images library. We mimicked this approach when adding a header image to the page, allowing even further customization on a site by site basis.

To apply our custom Master Page, we went to the root site's Site Settings, Master Page section where we were able to select and apply it to the site and subsites right from the browser, completely transforming the UI into an intuitive and branded application.

Separating the presentation

To separate the content, mark-up, and presentation as much as possible, we opted to use the alternate style sheet approach. By default, the core style sheet, appropriately named CORE.CSS controls the majority of the sites, colors, fonts, and positioning.

To over-ride these default values, we took advantage of the “AlternateCSS”, an option which can be specified from the browser under Site Settings, Master Page, Specify “AlternateCSS” URL.

We started by creating a blank style sheet and saving it to the style library, a library created by default with all publishing portals. After adding our style sheet and specifying it using the method described above, any styles/properties we add which exist in the default (CORE.CSS) will be overwritten because our alternate style sheet is read last.

To figure out what classes we needed to override, we took advantage of a free tool from Microsoft’s Internet Explorer Team, the Internet Explorer Developer Toolbar. Download the beta here.

Using the “Select Element by Click” option in the IE Developer Toolbar, we were able to click on any element of our screen and instantly see what class should be changed in our alternate style sheet. In the example below, we clicked on the Recycle Bin link.

In the example above, we could add .ms-recyclebin to the alternate style sheet to change its properties. Tip: Make sure you copy all properties specified in the CORE.CSS; otherwise, they will not be overwritten.

Using “AlternateCSS”, we were able to isolate the presentation to a single style sheet, overriding the default styles when applied.

Because subsites can be set to inherit the Master Page and alternate style sheets of their parent, this method also allows for sweeping brand changes by editing a single file. Just as it can be set to inherit, you can also choose not to in which case subsites are free to use a completely different Master Page or style sheet.

In this installment, we covered the key customization methods which allowed us to brand our sites as well as keep a familiar and intuitive UI for our application. In the next and final installment, we will take a look at Search as well as how we overcame multilingual obstacles before wrapping up with a look at our template system and our finished product. We'll also provide a summary of the MOSS 2007 specific features that were utilized for our project.

Shane Perran – User Experience Lead, SharePoint MVP
Jared Rypkema – Lead Software Architect
Infotech Canada | Information Worker Solutions

Building a real world extranet application with MOSS 2007 (Part 1 of 3)

ecmblog — Sat, 17 Feb 2007 15:04:00 GMT

Occasionally, I ask SharePoint professionals, who have implemented real world solutions on SharePoint Server, to do a guest blog entry about their experience. This is one such case. Read on and enjoy.

Introduction

In November 2006, Infotech Canada (a Microsoft Gold Certified Partner) was approached by Microsoft and presented with the challenge of creating a web-based application with Microsoft Office SharePoint Server 2007 that would boost productivity for a major enterprise retailer through a shared extranet repository, which was to replace a system already in place.

This is the first of a three part blog series that will outline the experience of building the application with a focus on the customization and development choices that were made along the way.

Project Requirements

The application was to be built on top of Microsoft Office SharePoint Server 2007 due to its ability to enable content sharing and publishing in a controlled environment but still accurately represent a well established brand. The solution was also required to be highly reusable for effective implementation across 5 uniquely branded sister companies, which were all represented via their own websites.

The following technical requirements existed:

· Internet facing extranet portal.

· An intuitive “drill down” navigation allowing users to quickly locate files by browsing categories.

· Must support multiple image formats and allow for an intuitive grouping of different formats for as a single image group.

· Single click downloads of individual and groups of images.

· Multi-browser friendly.

· Must support multiple languages (English and French) for the user interface as well as content.

· Must be easily extendable via a template system.

· Must integrate with current Active Directory environment.

· Must represent several unique brands.

Timeline

The timeline for the project was one of the most challenging obstacles. We not only had to build an intuitive system on a new platform, but we had a very aggressive timeline with less than a month to plan, develop, test and implement the solution into a production environment.

The Solution (breaking it down into manageable modules)

With such an aggressive timeline, planning was incredibly important. We were able to break the solution into several major modules, which while very interdependent, were much more manageable and could be developed separately.

Setting the Stage - Creating the Site Hierarchy and Content Types

The initial site hierarchy consisted of a single site collection with the main corporate gateway at the top level and several subsites to represent other subsidiary companies.

Like most websites, some elements were able to be reused across all subsites/pages, and as such we were able to store them at the top level of the site collection in document libraries. We were able to share both the images and a single style sheet across all sites using this approach.

· The image content was stored in a picture library, with one library per company site. The categories for each image were represented as folders, with the last level in the folder structure representing a single image group. All of the different formats of that image were stored in the folder for that group. For example:

o Image Category A

§ Image Group 1

· Image1.jpg

· Image1.ai

· Image1.eps

§ Image Group 2

· Image2.jpg

· Image2.ai

· Image2.eps

o Image Category B

§ Image Group 3

· Image3.jpg

· Image3.eps

§ Image Group 4

· Image4.jpg

· Image4.ai

· In order to distinguish between the different types of folders, we created two content types that inherited from the Folder content type: Image Category and Image Group. These content types also contained extra site columns, so that we could associate metadata with the folders themselves. We created a site column for an optional field called French Name, that lets content administrators specify an optional French display name for any image category or image group. Another site column was added to the image group content type that allows content administrators to specify language of the image group as Multilingual: English or French. This approach allowed us to store all of the images in a common folder structure, and still allow for translated content when needed. Rather than having to maintain two separate folder structures, content administrators can simply translate the English folders by adding French names as metadata.

The Navigation

We were able to take advantage of the out of the box site map providers and navigation to create an interface that allowed users to easily navigate between the subsites. To navigate the image content, we built a custom navigation control that was aware of our custom content types as well as the current language. This allowed us to distinguish between the content types visually in the navigation and also display the extra metadata like the French Title when appropriate, all in an easy to navigate tree-view style menu system.

· A Dynamic tree view navigation menu built as a custom server control and implemented into the master page of each company site. This tree view, much like Windows Explorer enabled users to quickly locate files.

· Selecting Files from the menu triggered a web part to display customized results grouped by the category selected. Each image set is stored as a custom folder content type.

Custom Results Display

The end result of using the tree view navigation is the display of a set of results, which presents the user with the image groups in the selected category.

· If a .JPG file exists in the set, the web part displays the thumbnail that’s generated by SharePoint automatically.

· Each file in the set has a hyperlink to the file as well as a checkbox for selecting multiple.

Users can select multiple files to download at which point a .ZIP file is generated, complete with the folder structure and files of the set(s) selected.

In the next installment of this blog series, I will describe how we customized the master pages and style sheets to create a visually appealing website which was accommodating to multiple unique brands.

Shane Perran – User Experience Lead, SharePoint MVP
Jared Rypkema – Lead Software Architect
Infotech Canada | Information Worker Solutions

Building tylerbutler.com, Part 6: What Was Tough, and What’s to Come

ecmblog — Tue, 16 Jan 2007 05:23:00 GMT

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

This is part 6 of an ongoing series of posts about my experience building a custom site on top of Office SharePoint Server 2007. If you haven't yet read parts 1 through 5, I'd strongly suggest starting there.

In my last post, I discussed some of the final touches I put on my new site. In this post, I'll talk about things that I found particularly difficult during this project, and discuss some other ideas for features and functionality that might come in the future.

Content Query Web Part Limitations

I love the Content Query Web Part. It is pretty customizable in both result sets and presentation, it drives RSS feeds, and it generally solves the very real problem of aggregating content dynamically across a site. However, it has one core drawback that can be a bit annoying – it doesn't know where it is. What I mean by that is that a given CQWP doesn't know that it's in a specific subsite. In my site, I have a page layout for my rollup pages that includes a CQWP for the main content. I wanted to just add my CQWP to the layout and have it automatically aggregate content from only the current subsite. Unfortunately, because the CQWP isn't aware of its current location, you can't configure it that way. You must explicitly set a property on the part telling it what specific sites you want to aggregate content from.

While this is an unfortunately limitation, there is a way to make this work. You can write a small custom control that you add to your page layout that is aware of the current location and sets properties on the CQWP at runtime. This is the method I will be looking at pretty soon, because it also has the pleasant side-effect of letting me set web part properties at the page layout level. If my custom control sets the properties at runtime and lives in the page layout, then I can just modify it once and all of my rollup page CQWP's magically get updated. I'm not sure how this will impact performance of the part, so that's something to investigate if you're considering going down a similar road. The impact should be relatively negligible if you're making use of output caching.

Styling Issues

Another problem I ran into was around styling. Some things are pretty tough to style. The major culprits here are web parts. Web parts always want to inject their own chrome and color scheme into the page content. This was frustrating when using the CQWP, because I specified all of the markup I wanted in the XSLT styles, and then the web part would throw some random CSS style or table around itself when it rendered. You can still see markup like <td id="MSOZoneCell_WebPartWPQ2" valign="top"> and <div id="WebPartWPQ2" class="ms-WPBody"... in my page markup, even though I have the web parts configured to not output any of their chrome. Talk about annoying!

Most of this stuff ends up being pretty innocuous. However, some of the side-effects are that your CSS styles might not look right when content is being output from a web part, because your styles are cascading incorrectly because the web part (or more correctly, the web part zone) is throwing something extra into the markup. I got around this by adding some additional CSS class to make sure the web part CSS got overridden. For example:

.ms-WPBody a:link {

color:#888888;

font-family:"Lucida Grande",Helvetica,Arial,sans-serif;

font-weight:bold;

text-decoration:none;

}

This works, but it's very annoying that I had to go this route in the first place. One other trick you can use if your web part doesn't live inside a zone is to set SuppressWebPartChrome="true" on the web part. This suppresses almost all of the web part chrome from being rendered. Unfortunately, this only works on web parts that don't live in a zone, which means that you can really only use this for page layouts. In my case CQWP's won't serve RSS feeds unless the web part lives in a zone, so I couldn't use this approach in most cases.

Another area that was a bit frustrating from a styling perspective was the search control. I haven't managed to get it right yet. If you look at my site in Firefox, the search box is not right-aligned like it should be. IE6 renders it right aligned, but I think IE7 does it like Firefox. Anyway, this is just another example of what can be frustrating when controls output presentation elements that aren't easily overridden. I'm sure I'll figure it out eventually, but just like with the web part styles, I shouldn't need to. I want a clear, unified way to style my page and I don't want controls usurping my look and feel that I painstakingly crafted.

This project was a lot of fun, but it certainly didn't come about without a share of challenges. I toyed with several designs or options in various sections of the site before settling on the "final" solution, and things are far from done, and as is always the case, there are drawbacks to every solution. Some of the things I have written about in my posts have already been changed because I decided to try something different; no doubt more changes will come in the future.

In fact, I have a whole lot of ideas that I want to implement. Alas, time is short and I probably won't get to most of them, but I thought I'd mention a few because people might find them interesting.

Authoring in Word

Word 2007 has the capability to post to blogs using both the MetaWeblog and Atom APIs. The SharePoint blog template has a server-side implementation of the MWL API, so you can post to your SharePoint blog using Word, Windows Live Writer, or any other MWL-compatible authoring tool. But my site isn't a SharePoint blog. One of the core reasons I used the publishing features was because I had a specific look and feel I wanted for the site, and I wanted to be able to update that on a grand scale easily.

That said, there are a lot of features that blogs have that I would like to have on my site. One of those is the ability to create posts offline and post them later. To this end, I have been working on an implementation of the MWL API that knows how to post Publishing pages. I even have it working, though it's not ready for anyone else to use it or anything. If I manage to get it in releasable shape at some point, I'll put it on my site. But basically, my point is that with a little time and elbow-grease, you can make some services that extend the authoring capabilities of the system. George, another PM on my team, also built a prototype email handler that would create a publishing page based on incoming mail. There are lots of possibilities here, and the object model we have is robust enough to allow you to build you these sorts of things pretty quickly.

Forms Authentication, User Sign-up, and Comments

One of the things I'm missing from my old site is the ability for people to sign up for accounts and then either contribute posts or comment on existing posts. In order to support this, I need to switch over to use Forms Authentication (which is super easy because SharePoint has a pluggable authentication model) and build a sign-up page. Again, I have this working already, but it's not live yet. Once I make it live, people will be able to sign up for their own account, log in, and post content on the site (with my approval, leveraging the awesome workflow capabilities of SharePoint). If you're looking for more info on setting up forms auth, Andrew Connell has a great post at http://www.andrewconnell.com/blog/articles/HowToConfigPublishingSiteWithDualAuthProvidersAndAnonAccess.aspx.

Custom Layouts and Controls

I also have quite a few custom controls and layouts that I'd like to write. One big one is a custom DateTime control, because the default SharePoint one only allows you to set time in 5-minute increments. I demand more precision! :-)

I also plan to make a couple of controls for my music/movie/game/book reviews that will connect up to Amazon and load information about the item I'm reviewing. This should be pretty straightforward, since Amazon has an extensible web services framework.

Well, ladies and gents, I think it's time for me to bring this post series to a close. I hope that some of you have found the information useful. If you are interested in any future projects I do for the site, I encourage you to visit http://www.tylerbutler.com, or subscribe to a special RSS feed that is tailored to my more technical audience. This feed only has items from my Work and Projects sections. I figured some of you might not be interested in my poetry, music, or book reviews, but if you are, hey, there are feeds for that too. :-)

I doubt this is the last you've heard of me, though, so until next time...

Part 1 :: Part 2 :: Part 3 :: Part 4 :: Part 5 :: Part 6

Happy holidays as a bunch more MOSS-based Internet sites go live

LLiu — Sun, 24 Dec 2006 10:53:00 GMT

On behalf of the SharePoint product group (actually, our official name is the Office Business Platform Group), I wish you a wonderful holiday break and a very happy new year!

Here’s a bunch more MOSS-based Internet facing websites that have recently gone live (go here for a list of others mentioned in the past):

http://www.cegos.fr -- Cegos Group, the largest European learning and development provider with 28 offices in 15 countries, has adopted MOSS for their WCM and transactional needs. This implementation is the first production website that relies on MOSS 2007 and Commerce Server 2007.
http://www.shareview.co.uk -- Shareview is Lloyds TSB Registrars’ online portfolio service that helps shareholders and employees to manage their holdings. Lloyds TSB Registrars is the UK’s leading provider of share registration services. Lloyds TSB Registrars is a division of Lloyds TSB Bank plc and acts as Registrar for over 650 companies, including around 60% of the FTSE 100, managing some 24 million shareholder accounts.
http://www.infocision.com -- As a leading provider of call center solutions, InfoCision specializes in political, religious and nonprofit fundraising, and sales and customer care.
http://www.paulmitchell.com – I’ve been using Paul Mitchell’s excellent hair beauty products since, like, high school. Need I say more? J
http://www.speaktech.com – speakTECH is a Microsoft Gold Certified Partner focused on delivering solutions for demanding enterprise environments and growing small companies.
http://www.sharesquared.com – ShareShared is a premier provider of technology solutions for SharePoint, collaboration, and knowledge management.
http://www.satama.com – Satama is a leading European digital services company, based in Finland, with a global clientele and offers services and solutions for marketing, productivity, and mobility.

Of course, it would be inexcusably ironic for this blog to be hosted on anything other than SharePoint for too much longer. Hence, this blog will be migrated to a MOSS-based environment in 2007. More details will be forthcoming.

Again, happy holidays to you! Thank you for continuing to read this blog, and please don't hesitate to leave feedback via comments.

Lawrence Liu
Senior Technical Product Manager and Community Lead

More MOSS-based Internet corporate web presence sites go live

LLiu — Thu, 23 Nov 2006 02:17:00 GMT

The HedKandi website that was profiled here is indeed very cool, but most of you probably wouldn’t think of showing it to a CIO or a BDM/TDM as customer evidence or reference for SharePoint Server. J Now that we have RTM’d, there will be many more websites that will go live within the next few months. Here are three that you can tell your CIO about:

· ~~Monsanto UK’s (part of a~~ ~~Fortune 500 company) website:~~ ~~http://www.monsanto-ag.co.uk~~ [Oops: They haven't gone live yet!]

· Our first Chinese company (the Rui Jin Hospital in Shanghai) website: http://www.rjh.com.cn

· UCB's (a French bank with 5 million customers) e-banking website: http://www.ucb.fr

And a few more in French:

· http://www.oasys.fr

· http://www.revue-d-etudes.fr

· http://www.formextern.fr

Now, I just need to convince them to put the “Powered by MOSS 2007” badge on their home pages. J

Happy Thanksgiving (to those of you in the world who celebrate it)!

The “Powered by Microsoft Office SharePoint Server 2007” badge

ecmblog — Wed, 25 Oct 2006 10:48:00 GMT

As we approach the RTM milestone for MOSS 2007, many of our customers and partners (yes, that would be you J) are solidifying deployment plans for Internet facing websites that leverage the integrated WCM, portal, and search features of SharePoint Server. For those of you, who are especially proud of being an early adopter of MOSS, I have created the “Powered by Microsoft Office SharePoint Server 2007” badge for you to display on your website's home page.

You can download the standard and full sizes of the badge, or you can just use the following HTML snippet, which is used to display the badge above:

<a href=”http://office.microsoft.com/sharepointserver”>
<img alt=”Powered by Microsoft Office SharePoint Server 2007” 
src=”http://blogs.msdn.com/photos/sptblog/images/871296/original.aspx”></a>

Just leave a comment here with the URL of your website and send me an e-mail with your full name and shipping address. If I like the way your website looks, I will send you this very nice MOSS logo’d insulated tumbler. J

Moving from design to reality - building HedKandi.com in Microsoft Office SharePoint Server 2007

ecmblog — Sat, 30 Sep 2006 07:54:00 GMT

As mentioned in my blog entry from a few weeks ago, cScape Ltd, a Microsoft Gold Partner, recently launched www.hedkandi.com for Ministry of Sound using Microsoft Office SharePoint Server 2007. I asked Ben Robb, Technical Lead on the project, to write the following guest blog entry, which outlines how they took the out of the box functionality in MOSS and produced a radically fresh design for hedkandi.com in a very short period of time.

The Brief

In the past, most SharePoint developers would have run a mile when faced with an initial design brief like this:

While it had been difficult in the past to brand a SharePoint-based website with the kind of flexibility that marketing departments demand for their publicly facing websites, SharePoint developers can stop running right about now. This limitation simply disappears in the 2007 version of SharePoint with the support for ASP.NET 2.0 Master Pages technology.

So, how did we go about creating a site with SharePoint that looks nothing like a typical SharePoint site? Surprisingly, it didn’t involve lots of C# code or editing files we really weren’t supposed to be. We actually made use of a lot of out of the box controls, and in the main used XHTML, CSS and XSLT to achieve the output that our client required.

Project Management

Building a MOSS-based website is very similar to any other website project. You can use any of the formal process driven methodologies such as the Microsoft Solutions Framework or one of the Agile methodologies. Due to the fairly tight timescales and a very close working relationship with the client, we used an iterative Agile methodology to ensure that what we delivered met expectations. We managed risks, issues and general documentation via an extranet team site running on WSS 3.0.

Below is a step-by-step guide for how we ran the project:

Step 1 – Define your basic site map and designs

As in many web projects, the basic site map and designs informed the development teams of the basic functional requirements. The site map provided us a list of all of the different types of pages on the website, and the designs told us what features we were going to need to use. These both changed as the project progressed, but provided us with a useful baseline to start with.

HedKandi’s distinct designs were delivered to us already converted into flat XHTML and CSS, and this saved us time later in the project.

Step 2 – Define your Content Columns and Content Types

Content Types are a great feature of SharePoint and provide the underlying structure to the whole site. Time spent at the start of the project to properly define the content types you require on your page layouts and your lists is always well spent. You don’t have to be exhaustive in your definition, but the more you do at the start, the less you have to rework later.

For better manageability, we created two new Content Type groups – “HedKandi Page Layout Content Types” and “HedKandi Custom List Content Types”. This allows for a better user experience when end users are creating views, and also allows us to easily distinguish between out of the box content types and ones we have created.

Step 3 – Define your Custom Lists

Lists are the backbone of the HedKandi site; rather than free-text content blocks, we invested in a number of Site Collection level lists to ensure consistency and content reuse. An example of this is the Venue list, which is used by the HedKandi Events pages to provide information about the location of a HedKandi event. Since many of the HedKandi events will use the same venues, we wanted to improve the user experience for content authors when adding a new event to the system. By creating a custom list, and adding a field to the Page Layout, we allowed content authors to select from a drop down list of available venues. When the page is then viewed by the end user, information from the selected venue was pulled through from the custom list and formatted appropriately.

Step 4 – Create the basic Site Hierarchy

The basic site hierarchy in HedKandi is fairly small, so we created this via the user interface under Site Actions. In larger scale sites, where a full site hierarchy has been worked out in advance by an Information Architect, we would recommend using the stsadm -o createsite command, or writing a simple application to automate the initial structure creation via the API.

Step 5 – Add your images and CSS files

So, once you have your basic site hierarchy, your custom content types and your lists, it is time to start building the site to make it look like your design. This is the point where we fire up Office SharePoint Designer (SPD) for the first time. Using SPD, we were able to add our custom CSS files very easily. As with the Content Types, we wanted to ensure that we knew which files were “out of the box”, and which were added during the project, so we created a new folder in the Style Library list – called HedKandi, and within this created folders called CSS and Images. We placed our images and CSS files within these folders.

Step 6 – Build your Master Pages

We had a number of pages which demanded quite different layouts, and since they were in different locations in the site, we chose to use multiple Master Pages. Having done the groundwork with the flat XHMTL we were able to quickly create new Master Pages. Since we also wanted to make use of existing page layouts in our site, we made sure that we maintained the same naming convention for our <asp:ContentPlaceHolder> controls.

Step 7 – Build your Page Layouts

This is where we really saw the benefits of pre-defining our Page Layout Content Types and having our XHTML mockups to hand. Building a flat page layout is remarkably quick to do when you have done the groundwork – mainly because of the integration that SPD’s toolbox has with SharePoint. Adding a content field into your page is a matter of picking it up from the toolbox, and dragging it into your page – whether in Design mode or in Code mode. This is a great timesaver on your project – if you have defined your content types well, and described them properly, your developers do not have to keep referring to documentation to know what field controls are for, and what format those controls should be.

At this point, we had a working site, which looked fairly close to the designs, and allowed our authors to start the process of entering content into lists and creating new pages based on our Page Layouts. This streamlined our testing processes, since it meant that we were able to catch missing fields or functionality early in the project.

Step 8 – Customize your Content Query webpart views

Content Query web parts were the one of the most commonly used webpart on the website. We used them all over the place to aggregate content from lists, and we found very quickly that we had to move away from the standard set of views given by the web part in order to meet the designs we had been supplied. We were able to create custom XSLT templates to cater for these views, by modifying the itemstyle.xsl file, which is found in /Style Library/XSL Style Sheets in your Site Collection’s root site.

A really great feature of this is that simply by adding a new XSLT template to the itemstyle.xsl file automatically adds it to the dropdown list in the Web Part Properties screen and is therefore instantly available to authors on the site. This is a great timesaver, but be warned that syntax errors in this file can cause all instances of Content Query webparts in your Site Collection to break.

Additional Work: Page Comments

One of the key requirements for Ministry Of Sound was to allow page level comments on certain types of web content page. To resolve this requirement we turned to the design pattern shown by the Comments functionality in the Blog site template.

In the blog comments example, there are two lists – a Posts list, containing the blog posts themselves, and the Comments list, containing the comments. The Comments list has a column of type “Lookup”, which is configured to use the Posts list as its source. When viewing a blog post, a ListView and ListForm webparts are used to provide a view of the comments and a form to allow users to post new comments. This form automatically populates the lookup column with the correct Post.

We used exactly the same mechanism to provide comments for pages in the HedKandi site, except we used the Pages list instead of the Posts list.

Conclusions

While there was a fairly large learning curve to overcome during this project, the fact that our developers were experienced in both SharePoint and MCMS technologies did reduce the curve dramatically. Working closely with our clients meant that we were able to rapidly develop and deliver the project – in a timescale of weeks rather than months.

We found MOSS itself to be generally stable -- even at Beta 2 -- with only a few quirks here and there. Site creation and configuration were simple (although the menus weren't always intuitive -- we see some training issues ahead for our clients). The integration with wider .NET concepts, such as Windows Workflow Foundation, forms-based authentication, membership and navigation were all very good and very powerful and ultimately proved to be real time-savers. One particular point for this project is that we used ASP.NET's membership provider and migrated all of the existing Hed Kandi registration details into the ASPNET database, and we configured it all to integrate with MOSS in less than a day.

Ben Robb

Lead Technical Consultant

http://www.cscape.com

A few public websites have already popped up on MOSS Beta 2

ecmblog — Sat, 02 Sep 2006 13:28:00 GMT

Although the B2TR release of MOSS (along with the rest of the 2007 Office system) will be publicly availability within the next couple of weeks, a few public websites have already been implemented on MOSS Beta 2. Since Microsoft does not provide production support to any customers running Beta 2, I would discourage anyone from doing so for a business critical function. Nevertheless, the following websites have been running Beta 2 for a few weeks or more without any significant problems.

· http://www.wssdemo.com

· http://new.culminisconnections.com

· http://www.alphamosaik.com

· http://www.hedkandi.com

Although Microsoft will still not provide production support for B2TR sites except for a (very) limited number of customers in our Technology Adoption Program (TAP), I suspect that shortly after people get their hands on B2TR, many more sites will pop up even at the risk of not getting any support from Microsoft. So, if you have a public site built on MOSS 2007 or WSS V3, please leave a comment here with its URL and mention whether or not you’re part of the TAP.

Of the sites listed above, I’m most impressed by http://www.hedkandi.com simply because it looks nothing like a typical SharePoint site. I call it “a SharePoint site with extreme branding.” A few days ago, I found out that the site had been developed by a Microsoft Certified Partner, who’s a member of the TAP, so I’ve invited them to do a guest blog entry here with details on how they used SharePoint Designer and various features (content types, field controls, content deployment, etc.) of SharePoint Server to implement the site. Expect to see it in the next week or two.

You can also expect to see some relevant and detailed blog entries from the MOSS Web Content Management feature team over the next few weeks.

[Update 09/10: A little bit more info about the Hed Kandi website can be found here.]