20 March, 2006
Now Todd Bleeker has released a CEWP that will add a section to your Quick Launch bar with a list of subsites underneath the current site. This is a very sought after feature and this is a great solution for it. It works perfectly and it is highly customisable.
The beauty of using a CEWP is that no assemblies need to be installed. All you need to do to install the web part on a virtual server is to drop the .dwp file in the 'wpcatalog' folder. The Sub Webs On Quick Launch web part can now be added to any web part page from the Virtual Server Gallery. I do recommend to change the defualt heading from Subwebs to Subsites to be consistent with the terminology used in the SharePoint UI.
13 March, 2006
The SharePoint Team Blog has released some information on new rollup web parts to be included in SharePoint 2007. This is great news as the current version of SharePoint has practically no out-of-the-box options in terms of aggregating content from various team sites.
The new web parts allow you to roll up all the documents created, modified or checked-out to you as well as including all the tasks assigned to you. It is not quite clear from the post how configurable these web parts will be but it appears that they are limited to documents and tasks and based only on content relating to the current user.
I agree with Robert te Kaat's post that more flexible rollup web parts are desirable. For example, it would be nice if a parent site could display a list of all tasks aggregated from all the child sites or an aggregated list of high priorty issues. This is currently achievable with FrontPage and the data view web part, but a standard web part for this would allow numerous quick wins when SharePoint is used as a project management tool.
09 March, 2006
After messing around for a while I realised I had forgotten to install SPS Service Pack 2 which solved the problem.
Have a look here for an overview of the performance gains when using SQL Server 2005 with SPS 2003.
01 March, 2006
If SharePoint is used as an internal productivity tool only, you should seriously consider to go with the standard look and feel. Just like you do with the other Office applications. You wouldn't even consider skinning Word or Excel to reflect your corporate brand. The focus is entirely on functionality and usability, not aesthetics.
There are some drawbacks of customising the SharePoint UI extensively. You end up with a non-standard implementation that is harder to maintain and support and there are also unknowns about how well a heavily customised implementation will come across to future versions of SharePoint. I'm not saying that branding SharePoint is a bad idea, but you should only engage in considerable customisation of the UI if the branding is really important. It might not always be worth it.
Using SharePoint as a productivity tool in internal teams should be seen as an extension to the other Office applications. It behaves like Office and it looks like Office. Yes, it does look boring if you've spend a lot of time with out-of-the-box SharePoint installations, but so does Word, Excel and the rest of Office. Like with any other deviation away from standard configuration, have a good reason before you do it.