The CQWP is my absolute favorite out of the box web part. There are so many things that you can do with it. There are lots of great blogs out there describing how you can present information to your end user with the CQWP, but did you know that you can also use it to determine how your content owners are using their sites? Are they entering the type of data that you expected them to when you created your form? Do content owners understand the importance of certain processes, such as clicking on “Publish” to make a page visible to readers? Did your users really “get” the training that you gave them?
The current project I am working on is getting ready for a huge launch. It is a publishing site with minor and major versioning turned on for Pages and Document Libraries. It is one parent site with 100+ sub-sites, each containing hundreds of pages and documents. We created a custom web part for content owners to link to other pages in the site collection. This web part is really cool in that it shows the name of the page or document, the date it was reviewed, user ratings, a brief summary of the content and a link to the page or document. We want to give the reader some useful information about the link before they decide to click on it.
With so much content in the site, we are relying on content owners to enter information about the content in a field that will be displayed in FAST Search and will also be displayed in the custom web part to link to related content. The web part respects security, meaning a user must have access to the content in order to view the description in the web part. With a big launch coming up, I wanted to do a content check to see how we are doing. I don’t have time to go randomly clicking around on all these sites, so I created a couple of CQWP’s in order to see how the site is being populated. They also ended up helping our development team complete a final review of our work.
If you’re new the CQWP, it is a web part that you can add to a web part page that can ask all of the sites in your site collection to give you a certain kind of information.
For example, if this wall of candy dispensers is your site collection, with each dispenser being one site:
Then this is the CQWP:
It has done all the work for you and grabbed multiple types of candies for you to consume quickly. Yes, I could go to each tube and grab a little from each…but that just takes way too long and I want my candy NOW J. With the CQWP you can filter your candy to get the specific ones that you need (if you don’t want the brown ones you don’t have to have them).
The CQWP is out of the box when the publishing feature is turned on, and it’s pretty quick to configure, especially with practice. Here are some examples of how I was able to spend a few minutes looking at how the users are using the site and avoid deployment issues. All of these queries were done in a browser, with no .xslt edits. Each took no more than 15 minutes to configure, check, adjust, check, etc. to show exactly what I want on the page.
· Check on published versions
o Created 2 queries, one for all “Pages” libraries and one for all “Document Libraries” across the site collection, filtered by version is less than 1.0 and displays the last person that modified the content.
o Problem Avoided: Users not being able to access pages with page not found error, access denied errors and empty custom web parts
§ In order for a site reader to see a page or document the user must publish a page, or check in a major version.
· This makes the version 1.0 (or 2.0, 3.0, etc. as you publish major versions…drafts always have a decimal). A document that does not have a published version will have a version less than 1.0, which is why I filtered for by version.
§ There were over 400 pages and documents that did not have a published version just two weeks before go live
· View user-completed fields
o Created 2 queries, one for all “Pages” libraries and one for all “Document Libraries” across the site collection, which display the page title and our custom summary field and the content owner.
o Problem Avoided: Poor search results, poor cross-site link descriptions
§ There were over 300 items with “-“, an incomplete description or a duplicate description in the summary field that is displayed in our custom web part and search results.
· Validation or unique values were not viable options in this case.
· Discover users storing documents in wrong locations
o Created one query for all sites, grouped by Page Layout, which showed users were putting Word and .pdf documents in their Pages Libraries (since they had no page layout)
o Problem avoided: Documents stored in wrong locations would not display correctly to the end user
§ We created Pages Libraries for publishing pages and Document Libraries for all stand-alone documents. All documents are presented with a custom page that displays certain properties, taxonomy, user comments and ratings.
The overall outcome of these CQWP’s is that we were able to target the users that needed additional training tips in order to make sure their content is not only visible, but findable for end users on launch day.
Additionally, CQWP’s helped our development team to create a better product:
· Monitor page layout usage and react
o This was a unique project where editors were adding content while we were developing the site. By creating CQWP’s that grouped all Pages by Page Layout we were able to:
§ View how users are actually using the page layouts we designed with content and adjust as needed
§ Allow our front end developer to make changes to design based on usage
§ Allow our back-end developers easy access to test the pages and how they worked with our custom controls and actual content
If you’re not familiar with the content query web part, I strongly recommend spending some time getting to know this very powerful web part. It has been the fastest way for me to get feedback on what’s going on in our sites, so that we can address training issues, user adoption and design before they become a problem.