Pointed out to me by a colleague (ages ago!) – Ton Stegeman’s ‘Content by Type‘ web part. A good way of rolling up content of diverse types, without lots of XSL. If your content type structure is right, may well be other ways of doing this (the content query web part and data view may work) – but this is quite a nice looking tool, and simpler. Need to download and have a play sometime soon.
I’ve just downloaded (from codeplex) and had a look at the Polling Web Part by Phil Wicklund. We’ve a customer who wants exactly this sort of functionality – surveys are too heavy weight; they just want a little radio-button panel. That’s what the Polling Web Part does:
Cool. And it shows it’s results as:
Hmm. So how does it store it’s data? Well, that seems to me a little strange – each poll, options and responses are a single row in a list:
Bit strange if you ask me. Some consequences of this are that:
I must confess that I’d have considered having different polls in different lists, and reading the values available out of a Choice column on that list. Each response would be a List Item, so you’d know if someone has already created one. Still, Phil’s approach is probably quicker to process.
Other thoughts – well, it’d be nice to have bar chart rendering too.
All of which is, I must point out, quite picky. It does what it does well, and is free, and the source code is available; I may try and have a look at that at some time.
I just had a really weird error – I’d built some search pages for a customer. There was a custom results page, and a custom ‘Advanced Search’ page. When I went into Edit mode, to change the web parts, they didn’t have a title bar – including the ‘Modify this web part’ link. WTF?
Well, they’d been customized using SharePoint Designer, so I figured I’d copy their code from the customer system into a VM of mine, and check that the pages broke on my system. They didn’t. WTF x2 ?
So, the page page code, inside the same master page, in two different systems works differently. To check I wasn’t going nuts, I tried a WinMerge compare on the two files – and found this chunk of XML in my non-working version on the customer site:
<!--[if gte mso 9]><xml>
<o:CustomDocumentProperties>
<o:PublishingContactPicture msdt:dt="string" dt="string">, </o:PublishingContactPicture><o:PublishingContact dt="string"></o:PublishingContact>
</o:CustomDocumentProperties></xml><![endif]-->
Yes, although I’d cut and pasted the code, it was different. I came to the conclusion that this code is created or used by SharePoint Designer itself. I decided to delete it, save the changes to the customer’s page, and refresh my pages. It worked; now when I edit the page, lo, there are titles and the ‘Modify this web part’ menu. I have no idea what this XML is about, but I’m about 70% confident that it’s the culprit. I reckon that there’s a 30% chance that it was just being customized in SharePoint Designer again that fixed it, but I couldn’t see anything else related to the code that was likely to be a problem.
So, previously I’d described using a Web Part Property of an ArrayList to store a list of things. In that demo, I’d been just storing strings.
Well, my requirements got a little more complex, so I started trying to store my own objects in there – really, just objects storing data, no logic. However, when I added things to the property and ran .SetPersonalizationDirty() my data wasn’t saved. Worse, the values of other (unchanged) web part properties were lost! They kept coming through as null, rather than the values I’d set previously. There was no indication of error.
Well, here is Andy’s tip for folks who manage to forget the basics of C# development – don’t forget the [Serializable] attribute.
Without it, my data objects can’t, well, be serialized – that is, saved. So it’s unsurprising that my data wasn’t saved! What was unfortunate and threw me off the sent was that there were no errors shown, and that wiping out the values of the other web part properties did rather thrown me off the scent! I guess I was really having an off day when I wrote that…
Like Heather Solomon, I’m sometimes asked about styling individual web parts differently to the rest. I didn’t know of any way of doing this; instead, we’d typically style particular web part zones differently, but this meant that all web parts in that area looked differently.
Well, Heather has now posted ‘Controling single web parts with CSS‘. Neat. I didn’t know you could do that attribute selection.
The downer about this technique is that you have to set a DOCTYPE – and I can see that causing all sorts of grief as stuff breaks… …so it’s probably not something you’d do unless you’re building reasonably custom master page.
We have a customer who wants a custom web part similar to the Summary Links web part – that is, editors can add links in this web part (along with some other metadata). For various reasons, a ListView web part and a Links library weren’t what they were after.
Now, the Summary Links web part seems to me to be a bit unusual. Most web parts access and use data stored elsewhere – lists, web services, databases, etc.. However, the Summary Links web part stores it’s data internally. How does it do that, and can I do the same? Continue reading
So, what what content roll-up web part to choose? Well, typically (for SharePoint) it depends.
Bamboo’s List Roll-up Web Part is the most feature rich, but a bit tricky – certainly it’s a bit too complex if you’re wanting to allow users to set up their own roll-up. The use of CAML is also a big no-no for allowing basic users to set up their own. It’s a shame; it really is let down by this complexity, although it’s still simpler than using SharePoint Designer.
Using the Dataview Web Part directly has the same problem as Bamboo’s List Roll-up – complexity. It also requires SharePoint Designer. It’s harder to generate the Data View Web Part, but to be honest (given that you can do the same things as Bamboo’s List Roll-up web part) I suspect that most organisations would be fairly willing to live with that.
For me, it’s main problem is that it doesn’t pick up new lists automatically; you have to modify the data view web part to add the new lists. For that reason, I think you can only use this approach when you have a fixed set of lists to aggregate over.
The Content Query Web Part is pretty good, and there is a reason that it’s so often discussed in SharePoint Solutions. The web part itself is fairly straight forward to use – but using custom metadata in the display is a bit too complicated. Again, I think this solution is out of the range of the ability of typical users. I don’t like the lack of pagination options, either.
Lightning Conductor is the only one of the web parts that struck me as being simple enough that a non-technical person would be able to set up and use for content roll-up. It had many of the more complex features that we’ve seen (e.g. using XSL for formatting the results), but you didn’t have to use them, and the user interface exposes things that seem missing from the CQWP – like the ability to select the fields you want in the display! I’ve got to say, this is my favourite of the solutions I looked at.
So which one should you use? Well, as I said, it depends. The main factors involved seem to be:
I guess you weigh those up and take your choice.
Edit: One questions I was asked was if it’d be difficult to write your own. Well, there’s no reason why you couldn’t; with the SPSiteDataQuery it wouldn’t even be hard. Programming around the configuration would take longer, and as we’ve seen, this can make a big difference to the usability of your solution. What I would observe is that both the 3rd party solutions were pretty cheap; it’d be diffult to write your own for as small a cost.
Edit 2: A good post on when to use the CQWP vs the Lightning Conductor Web Part from Lightning tools…
And the final content roll-up web part I examined is Bamboo Solutions List Roll-up Web Part.
This web part is a little strange; indeed, I’m not sure how to describe it. As I understand it, basically it’s a web part to generate a data-view web part, and add it to the page. Sound strange? Well, it is a little bit. Let’s have a look:
As you can see, this is a big web part on page. It’s user interface is much more complicated than the Lightning Conductor. I couldn’t help but notice that to do filtering by metadata column values appears to require writing CAML – which really is a bit much for many users.
This web part then generates an output Dataview Web Part:
(In that example, it’s only aggregating from one list – ‘cos I forgot that gave my lists different names, and then told the view to roll-up by list name).
So, it’s advantages:
And it’s disadvantages:
In short: Probably the most powerful and feature rich of the web parts, but not as easy to use as some of the others. Really, more of a developer tool than a user tool.
So, on to the conclusions…
From Lightning Tools, the folks who brought us the BDC Metaman (awful name, good product) comes their ‘Lightning Conductor’ web part. Again, a slightly strange name (it isn’t copper and it doesn’t poke out from the top of a church roof). So what does it look like:
Okay, so it looks similar to the data view web part (apart from the ‘trial version’ message!), but it has the same sorts of roll up options to the Content Query web part. One of the things that impressed me about this web part was actually the configuration screens in SharePoint:
The main settings form is a well laid out, clear (if somewhat long) form. It just looks right.
The other significant administration screen with it is selection what columns you want to show, and their order, and any sorting or grouping.
Now that is much easier than displaying extra columns in the Content Query Web Part (or the Data View Web Part, come to that. Again, quite a long form, but clear, and trust me, easier than writing XSL 
I did have a couple of little problems with it, though. Firstly, for some reason it didn’t seem to want to show me my Project or Project Status columns in the ‘Filters’ section, so I couldn’t restrict my view by these fields. I may have configured something wrongly that this wasn’t possible.
The other thing that struck me was that while the web part does have column headings that the user can click to sort by, there is no icon to tell them what column they’re sorting by already, or whether it is sorting ascending or descending.
So, it’s advantages:
It’s disadvantages:
In short: It’s what everyone really wished that the Content Query Web Part actually was.
So, I’m quite impressed by the Lightning Conductor Web Part, but what of the other commercial option I’m reviewing – Bamboo’s List Roll-Up Web Part?
The Data View Web Part is sort of the Swiss-army knife of displaying data in SharePoint. It’s an Out-of-Box web part, and while it is typically focussed on showing items from a single list, it is capable of showing data from merged lists.
Here’s an example of a Data View Web Part showing the same data as our examples from the Content Query Web Part
It’s advantages are:
It’s disadvantages are:
In Short: Flexible in the views it presents, but it’s actual ability to roll up data is limited and could require constant maintenance. Requires someone fairly technical with SharePoint Designer to set view up. Continue reading