How We Did It: Australia National Native Title Tribunal website - advanced web content management
Overview
The National Native Title Tribunal of Australia assists people to resolve native title issues over land and waters. Set up under the Native Title Act 1993, the Tribunal is an Australian Commonwealth Government agency and is part of the Attorney General's portfolio. The Tribunal needed to upgrade its website, and the Vivid Group, a Microsoft Gold Certified Partner, was selected to develop the new website using MOSS 2007.
The Tribunal website needed to provide access to government records related to the native title process. The records have complex content types with thousands of pages based on each, and many pages also link to other images and documents that would be available to download. MOSS 2007, with its flexible support for content types and advanced web content management functionality, was a very suitable candidate for a tough job like this.
Here's a list of the content objects and how many of each were ultimately implemented on the website:
| Content Objects |
How Many |
| Custom Content Types |
14 |
| Custom Site Columns |
253 |
| Native Title Applications |
1,773 |
| Native Title Determinations |
109 |
| Registration Test Decisions |
1,154 |
| Indigenous Land Use Agreements |
331 |
| Future Act Applications |
13,662 |
| Future Act Determinations |
2,416 |
| Media Releases |
465 |
| Other Content Pages (Publications, Employment, Hearing Lists) |
80 |
| Documents - PDF, DOC, RTF and other document formats |
~6,000
|
Create a Custom Site Definition
A custom site definition was developed based on the out of the box publishing site template. The site definition referenced custom Features containing customisations developed for the website.
Develop Master Pages
One primary Master Pages was developed, which is used throughout the website. Other Master Pages were developed to provide "print friendly" views of the page and a text-mode version. These Master Pages are switched on the fly using a custom base Publishing Layout Page class, which switches the Master Page based on query string parameters. We utilized the following technical articles to develop our Master Pages:
BlendTrans meta tags were added to the Master Page to smooth transitions between pages and reduce "refresh flicker" when browsing through the site using Internet Explorer.
<meta http-equiv="Page-Enter" content="blendTrans(Duration=0)" />
<meta http-equiv="Page-Exit" content="blendTrans(Duration=0)" />
Certain SharePoint files were also removed from the Master Pages to avoid end users downloading unnecessary JavaScript and CSS files they do not use, such as core.js. These files are required for content authors but not for the anonymous viewer of the website. Reducing the page size results in faster page load time, which is critical for visitors, who have a low bandwidth Internet connection. We utilized the following technical articles to optimize the Master Pages:
- How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance
http://msdn.microsoft.com/en-us/library/bb727371.aspx
- HttpContext.Current.Request.IsAuthenticated is false when the user is anonymous, so this can be used to detect and control what is sent to the browser for a Master Page.
Plan Content Types and Site Columns
Content that is stored in SharePoint Libraries or Lists can be based on Content Types and Site Columns defined at the Site Collection level. Content types and site columns can be defined and deployed via SharePoint Features. Developing with Features allows all work to be stored in a source control system like Microsoft Team Foundation Server. You also have full control over the internal name used for Site Columns, which is not provided when manually creating them on the website. We utilized the following technical articles to implement our Features for deployment:
It took quite a while for us to work through the Content Types and Site Columns for the website, and we continued to rework them as we migrated the content across many times. We utilized the following technical articles to define our Content Types and Site Columns:
When planning Site Columns, it is likely that some may be common and used across many Content Types. Some columns can be based on lookup fields to SharePoint Lists, which provide a way to easily manage the values available to be selected for a column. When any new values are required, they can be added to the appropriate List and then automatically reflected in all respective Site Columns. The NNTT website required over 250 custom Site Columns to support all of the various Content Types and Page Layouts used throughout the website. All Site Columns and Content Types were deployed as Features.
We originally documented all the Content Types and Site Columns in the "requirements gathering" phase of the project into requirements documents. We then stored all Content Type and Site Column information in a custom List to help us manage the "schema definition and development" process because multiple people were doing the work over a period of a few months. We found that using a series of custom SharePoint Lists was better than tracking the entire process using Excel spreadsheets.
Plan Page Layouts
Page Layouts are page templates that are associated with a Content Type which defines the fields of information that can be stored within a Publishing Page. A Page Layout needs to handle multiple page modes -- two of which are Display Mode and Edit Mode.
Display Mode: The rendered view of the page, which an anonymous visitor would see. The following screenshot shows a typical page on the website in read-only mode.
Edit Mode: The rendered view of the page, which an authenticated content author/editor would see. The following screenshot shows the same page as above but in Edit Mode with controls that allow the user to add or update data in the available Page Fields.


Lookup field controls were used heavily to simplify content authoring by controlling the values that can be set in various Page Fields. The Display and Edit modes are quite different for the website, so two sets of controls were used to render the different modes to the user. You can programmatically detect the form mode by checking the SPFormContext of the current SPContext as described in the following technical articles:
Content Migration
With a new website replacing an old one, the migration of content from the old to the new website was required. Not only did HTML/text content need to be migrated but so did hundreds of images and thousands of documents to which hyperlinks also needed to be updated to reflect their new paths in SharePoint document and picture libraries. Having gone through the migration process, we learned 3 key things:
- Data migration method depends a lot on the source system - for instance, access to an API or the source database.
- Migrate content into MOSS 2007 Publishing Pages if you want content authors to have the ability to edit that content in MOSS 2007.
- You can optionally integrate other systems via web service APIs or custom SQL Server databases.
We also learned that data migrations into a new system never worked completely the first time, resulting in the need to run migrations many times with incremental bug fixes and other adjustments until all content has been correctly migrated. There was also a need to go back and validate that the Content Types and Site Column schema of the new website has been defined correctly to accommodate the migrated data.
Website Functionality
Menu navigation, page content navigation, and search navigation were implemented with custom server controls or web parts.
Custom menus were developed with the MOSS 2007 Publishing Navigation Providers used as a data source so that the menus would be configurable via the built-in Modify Navigation feature.
Field controls were used to provide the ability to edit of page content and configure page level settings. Several Page Layouts had custom Adobe Flash Field Controls, which allowed content authors to embed Flash-based multimedia content in the pages.
Flash-based maps were developed to provide drill-down into Australian States, which also triggered contextual content searches by encoding the appropriate parameter in the search page query string.
Search was very important due to the large volume of content and the complexity of content types with many attributes per document or page. The following section provides more details on how we implemented content search.
Content Search
SharePoint's Enterprise Search capabilities provide keyword search across many varying sources of content such as pages, documents, databases, and more. Developer documentation for SharePoint Search is well documented at:
We used the Business Data Catalog and custom developed stored procedures to implement search against data stored in SQL Server databases. SQL Server 2005 contains an optimised function (ROW_NUMBER) for quickly returning specific pages of search results.
We used CAML queries for searching page content in various custom advanced search pages. Paging was implemented with CAML queries to optimise the performance of queries. More information on paging can be found at:
We controlled the number of items returned from CAML queries by specifying a number for the RowLimit property of SPQuery. SPQuery also has a ListItemCollectionPosition property that is used for controlling paging of CAML queries.
Mailing List Integration with Microsoft CRM 3.0
Microsoft CRM 3.0 was used to handle the back-end mailing list for the website. Custom CRM entities were developed to support mailing list integration with SharePoint. Custom web forms were then developed to capture information from end users to push information into CRM.
The web forms generate the XML required for InfoPath form submissions, so when a user fills out the web form, a complete InfoPath form is programmatically generated and submitted to the InfoPath form library, allowing Tribunal personnel to process and update the form using InfoPath, which provides a much richer user experience than the browser.
The Vivid Group Development Team
http://www.vividgroup.com.au