List Filtering: Coding vs. Native Functionality Considerations
Over in the MSDN SharePoint – Design and Customization Forum, I was answering some questions about how to best provide filtering capabilities on a List View Web Part. McGeeky wanted to put filtering dropdowns at the top of the page to "improve the user experience".
My stock answer to this is to user Data View Web Parts (DVWPs):
As for the linking, I would forego Web Part Connections, as I’ve seen too many people have issues with them. Simply add a "Go" (or "Submit" or whatever) button which gathers up the filter values and passes them back to the same page on the Query String. Then have your "main" DVWP filter based on those values. You may need to write a little XSL to make the filtering work correctly. Once you dive in and see how much you can do with DVWPs, you may want to, anyway! ;=)
I understand on the usability question for the column headers. Of course, you’re trading training for coding. That and the fact that everywhere else there is a list displayed in SharePoint, the filtering is available on the headers (if it is enabled in that instance). This means that the users won’t know about this great capability unless they stumble on it. It might be worth explaining this to your customer a little.
And that second paragraph is what I want to expand on a little in this post. SharePoint provides a wonderfully consistent user interface. In that interface, most List View Web Parts have filtering and sorting capabilities exposed in their headers, if enabled. My point above was that, just because the "customer" wanted it to work differently, it wasn’t necessarily a good idea. The coding vs. training trade-off can actually be very expensive in the long run if your users don’t understand the native, pervasive functionality of SharePoint.
If you read the whole thread, it turned out that this was for an outwardly-facing customer site, so creating more obvious filtering mechanisms makes total sense. But when you have a "customer", whether internal or external who wants to develop fancier functionality on top of or to replace the SharePoint native functionality, it’s a good idea to have the coding vs. training discussion early.
Don’t get me wrong: I love doing this type of stuff with DVWPs. Sometimes, though, the cheaper up-front answer (not coding something new) may be the right long term answer as well.
