[Part 1]  [Part 2]  [Part 3]  [Part 4]

Greetings and welcome to the fifth and final post in this series describing the news management and delivery service we built on Microsoft Office SharePoint Server 2007 for our internal employee communication portal, Microsoft Web (MSW). I wanted to wrap up this overview by talking generally about our approach, how things are going, some challenges we had, and what's next.

How it's Going

Generally, we (and the MSW business team!) have been very happy with how the overall solution worked-out. We were able to address a number of challenges and short-comings with how publishing was done previously and streamline or eliminate many of the daily manual activities. Since the solution was built on pre-RTM bits a lot of our design decisions were made based on what we knew about the product at the time. There was definitely a lot of trial-and-error and leaning on members of the product team in the absence of documentation.

As I stated in my first post, it was our goal to use and showcase as many of the new features as possible. To take advantage of these features really requires understanding your content and how MOSS handles it. Depending on how your content is created, where it is stored, and how it needs to be made available may require content organization or business process changes. Centralizing content under consistent content type definitions makes subsequent organization, tagging, and data roll-up easier. Library support for multiple content types - and CQWP querying on content type - permits reducing the number of libraries required to store a lot of content. Content moderation, coupled with workflow and expiration policies makes it easier to create, update, and remove content in a more controlled and automated fashion. We have been able to take advantage of all of these features and gain many benefits, but it has required business to change their processes, too. Sometimes these changes are difficult, but where it can help standardize (and streamline) the publishing steps it has been worth it.

I would also add that our solution approaches content management in a specific way, but this is really a broad problem space that can be tackled many ways. That said, since developing the solution we have worked with several other teams and despite their different needs, they all boil down to understanding the content up-front and understanding MOSS2007 publishing features to inform content design and inevitable business process changes.

A Few Challenges

While we made lots of improvements to our publishing process with the new features, there remain aspects that still aren't as easy as they could be - and in some cases, required us to develop custom components. Data import to a SharePoint list is challenging and not easy to automate, which is why we had to develop the custom feed import application. Our service is flexible enough to support a variety of consumers (currently this tool can consume from XML or databases), but not without configuration work and coordination with operations when changes are required. Ideally, this would be an easier step in the cycle.

Search services have been greatly improved in MOSS 2007, but to support our editor's content discovery needs we really needed a richer query interface. We launched with the out-of-box advanced search, but the UI has limited sorting options, doesn't support nested queries, and the UI can't display the property's values. Our custom search solution builds on the OM and addresses these requirements. We have since made other improvements to this extended search solution and plan to make the binaries available to the community in the future.

 As I previously described, moving data between the raw source list and the tagged candidate list uses a custom action, but we'd prefer to have a configurable workflow here instead. Also, because SharePoint lists are flat this candidate list requires several duplicate tagging fields for each newsletter - and with fourteen newsletters currently being published, the list is a bit unwieldy.

We are huge fans of the Content Query Web Part as a delivery mechanism and use it extensively in this solution and in variety of other content scenarios. However, the web part is pretty limited in the results it can show without additional configuration of its advanced web part properties (see the MSDN topic on Content Query custom properties). Consequently, we have extended the web part to expose some of these more common properties and even enable it to filter content dynamically based on query string parameters. This source code is available on CodePlex for your use: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=sptoolbox&ReleaseId=11150

The delivery of content stored in SharePoint really favors RSS - and while this is a great improvement, one which we take advantage of for most of our content delivery - there remains strong business need to email a HTML-formatted newsletter to a list of subscribers. As I explained in my last post, we ended up building custom solutions to address this requirement and outside of some on-going formatting challenges between IE and Outlook they have both worked pretty well.  

What's Next

Since our initial release we have learned a lot more about the product and, working with other teams, gathered additional requirements. We have continued to make improvements to many of the specific custom components mentioned above, primarily around making them more extensible or easier to configure, but we also want to look at the design as a whole and see how we can streamline it even more.

One aspect that our solution doesn't take enough advantage of is workflow. We'd like to extend our use of this feature to make content moves, updates and even editorial notifications more seamless. We'd also like to extend this use into a richer information management policy. Currently, we just have basic item expiration on the news lists, but we'd like to enrich this step with user input and a better item archiving story. A few other areas we're kicking around for future enhancements include more flexible newsletter templates (perhaps ones that support offline or client authoring), better content auditing and reporting, and ways to retain history of dynamic pages.

Well, that's it for now. I hope you found this information useful and it aids you in your own efforts. We'll keep the community apprised of components we roll-out to CodePlex and continue to share news on our projects. Until next time!