Enable statistics to be presented with the form or as a block

Whoops. That last sentence should read:

"The idea is to display key, user-defined statistics about previous form submissions to the user."

It seems something that would be rather superfluous to include in the module, compared with the amount of settings space it would likely take. Would an API for getting the results of a single component suffice?

I suppose there's no reason this couldn't be a sub-module versus integrated into the Webform module.

Could you describe a possible interface for something like this?

Your Webforms collect info from users (surveys, for example). However, providing a means to display selected parts of the data (not the entire collected data set) doesn't appear possible. Say you want to display how many respondents filled out a particular form. How is that reportable in real-time? Or how many respondents selected a certain value in one of the survey fields? Reporting information like this in real-time is inherently useful.

So my initial suggestion was to use Tokens. It seems like a given form with N "select" fields could use the Tokens module to automatically create N named tokens that aggregate totals.

For example, there is Webform "survey1" with a select field "field1", with two options "yes" and "no". The tokens could be named "survey1_field1_yes" and "survey1_field1_no", each producing respective totals for all respondents. These tokens can then be used anywhere else in the website to talk about what's happening on that survey1 form. For completeness, you can also have a token "survey1total" which will return the total number of respondents for that survey.

Again, I think the ability to provide selected real-time data statistics to the user about a given form has inherent utility.

I know where you're coming from, and I agree it's a fine (but definitive) line between Webforms and site content. However, I still assert that providing some type of statistics on the data submitted on the webform is a necessary feature. Just because there's a need to automatically extract and display some information about form data, it doesn't mean we're magically crossing that line into what should be site content. Do you agree?

I agree that you shouldn't be recreating a node system, and you aren't. But this is an important module because you're precisely providing a means to NOT create site content. However, this doesn't mean we should prohibit supporting functionality that reports information about submitted data.

When I hear about people pulling out submission data and aggregating it, it's usually because they should have been using nodes to begin with.

I disagree. Perfect example is an RSVP form. I am having an happy hour, and I want to collect certain information about attendees. So I use a webform. I should *not* use a new content type + CCK because this RSVP list is only valid for this event. When a new event comes along, I need to collect different information, and thus create a new content type + CCK. None of this information should ever be searchable, so again it shouldn't be site content. Now I want to extract some meaningful information from the RSVP's, such as who replied YES to attending the event, versus who said NO, or MAYBE. This is why I suggested using the SELECT field to capture this information because the input state space is known. At any given time, an attendee should be able to see how many people are in each category, and [at some point] a list of those responses for each category. The latter portion may indeed use Views2 as you suggested, but the former information should be available without relying on another module.

I think this particular example use of Webforms demonstrates the need for automatic statistics generation.