Making the channel9 video was fun, and it was over before we knew it. Basically it was as casual and real-time as what you saw. Some of the comments about the video on channel 9 were to the effect that we spent too much time talking about blogs and wikis and not enough time talking about the SharePoint that everyone knows; lists, document libraries, meetings workspaces etc. I am the first one to agree that the video is not representative of the investments that we made, but I’m not quite sure what 20 minute video we could have made that did justice to the work we’ve done over the past couple of years! Before I abandon the topics of blogs and wikis and broaden the discussion to other WSS enhancements, it’s probably worth taking some time to explain *why* we’re adding blogs and wikis to WSS.
It would inaccurate to say that when we started work on 'WSS v3' (my working title - not the real name) 2 years ago, we were thinking a lot about blogs and wikis, but during our customer visits, we observed a number of WSS v2 deployments being used in conjunction with related collaborative tools such as internet blogs and wikis. We even found some customers that were experimenting with blogs and wikis inside their enterprises, but this was/is still at quite an early stage. At the beginning of the summer, we took a very hard look at both technologies with a view to finding a good fit for the capabilities within the context of WSS. The wiki template was easy to rationalize with respect to WSS; it’s simply another way of organizing a set of loosely coupled pages (content) within a site structure. We decided not to make the whole team site a wiki, but rather to host the wiki within the team site. By doing this, we hope to encourage the free-form page creation and casual linking of wikis, but within the structure of WSS. A WSS wiki has some key benefits for WSS users; I won’t describe all the wiki features that we support in this entry, but our goal was to bridge the concepts familiar with wikis (rapid page authoring, easy linking, versioning etc.) with related WSS capabilities (security, search, page editing, forms, views etc.). The result is a very lightweight page authoring model that benefits from the flexibility of a wiki and the security, structure and robustness of a WSS team site. We built the wiki on our document library infrastructure, so it inherits all of the WSS v3 document library capabilities (security, versioning, rich views etc.) One capability in WSS wikis that we have found quite appealing during our internal testing is the ability to extend the schema of a wiki page in quite a non-wiki way by allowing metadata to be added to the wiki page and all future pages. The most logical use for this in a wiki is to categorize pages. Adding metadata that describes the page classification enables rich WSS views over page collections, and its proving to be quite powerful in our testing to date.
Blogs were somewhat more challenging since they are typically used today (like this blog) to put forth individual ideas and views, not necessarily the edited and collective wisdom of the combined membership of a team site [:)]. We spent some time thinking about their uses within teams and our analysis of existing team sites uncovered a number of sites using the ‘Announcements” list as a mini-blog. It was positioned on the home page of the site and acted as the authoritative public face of the site to visitors. In some cases, the rest of the site was blocked off to casual visitors and the only information they saw was the Announcements list on the home page. A blog on a team site homepage would be a better fit for this scenario, and it is perhaps the most obvious potential use of a blog within a team site. However, with a SharePoint Portal (SPS) deployment, there are personal sites (called MySites) that represent a public, personal home page for each portal user. This page is a perfect place to host a personal blog, and in fact, it’s totally in line with the goals of MySites within SPS.
Of course, a blog wouldn’t be a blog if it didn’t support RSS. Not only will WSS v3 support an RSS feed on its blog template, you can generate an RSS feed from any list in WSS. Outlook ‘12’ is integrating an RSS aggregator (as is IE7), and you will be able to use these clients (or any other RSS aggregator that can consume RSS 2.0) to subscribe to the RSS feeds from WSS lists. The owner of the list can configure the RSS feed to determine which fields are included in the feed.
In summary, a key goal of WSS is to help individuals and teams capture and manage all the content necessary to do their jobs. In this context, adding blog and wiki templates to WSS seems like a logical extension to the content set that individuals and teams care about. They are not a replacement for email (more about this later), document libraries or lists, but they do provide a new way to capture, manage and present content that’s relevant to the team and the organization. By putting that content in WSS, it can be managed, archived, searched, secured etc. along with all the other collaborative content in the organization.