It has always amazed me what some people have been able to do with the Content Editor Web Part (CEWP). Good examples of the possibilities include James Milne's SharePoint Page ToolBar and Todd Bleeker's Snow Web Part. The former adds printer friendliness and a few other tools to a web part page and the latter is a Christmas gimmick that makes it snow on your SharePoint site.
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.
20 March, 2006
13 March, 2006
Rollup web parts in SharePoint 2007
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.
Stay tuned to my SharePoint musings: Subscribe via email or RSS.
09 March, 2006
SPS 2003 with SQL Server 2005
I've been setting up a new single box environment with SPS 2003 installed against SQL Server 2005. I first installed SQL Server and then SPS. However, when I wanted to create my first portal site, I kept getting 'Portal creation failed. Please see the portal creation log for more details.'
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.
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
When not to customise the SharePoint UI
Most organisations rolling out SharePoint want the UI to be branded with their colours and logos. Some take this even further and want the layout of the pages completely redesigned. This is fair enough if we're talking about rolling out SharePoint as a new corporate portal, intranet or an external extranet. In these cases, there may be an important marketing aspect of the rollout justifying lots of UI customisation. However, there are scenarios where customisation might not be worth the effort.
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.
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.
Subscribe to:
Posts (Atom)
