Closed (fixed)
Project:
Webform
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
6 Jun 2004 at 12:31 UTC
Updated:
8 Mar 2005 at 21:48 UTC
Jump to comment: Most recent file
Getting a reporting tool for submitted information.
This should be able to make both summeries of the submited data (for questioner type forms) and to present sorted lists of submited data (for contact/applications type forms).
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | webform.inc_3.txt | 41.38 KB | jnt |
| #18 | webform.inc_2.txt | 40.73 KB | jnt |
| #17 | webform.inc_1.txt | 29.51 KB | jnt |
| #16 | webform.inc_0.txt | 25.59 KB | jnt |
| #15 | webform.inc.txt | 17.38 KB | jnt |
Comments
Comment #1
(not verified) commentedWhat is the status on this bug? Do you plan to implement it anytime soon. I am a novice in PHP but not in programming. If you think it is going to be simple enough I can try to take a lead on this.
Otherwise, what is the database where the data is stored.
Comment #2
ullgren commentedThis bug is kind of waiting on [0]#7999 since saving the submissions in this form would make it alot eaiser to generate reports.
I'm working with #7999 right now and will hopefully commit some changes in a week or two.
As it is now submissiona are saved in a XML formated string in the table webform_submissions (field data).
If you like to take a lead on it I've been thinking along the lines of using something like [1]JPGraph but I'm not sure about there licenses since [2]QPL is non-GPL compliant and as such it can not be used together with GPLed software such as Drupal. One might persuade the author to grant a special exception for use with GPLed software. Better yet would be to use a fully GPLed alternative (which is also some thing on my wish/todo list).
[0] http://drupal.org/node/view/7999
[1] http://www.aditus.nu/jpgraph/index.php
[2] http://www.fsf.org/licenses/license-list.html
Comment #3
echos commentedThis would be a great function. I look forward to seeing any progress you might make in this direction.
Comment #4
(not verified) commentedI am also looking forward to the Report Tool, because using the MySQL admin is not really convenient. Sorry, I am not a programmer, so my contribution will be limited I guess. Thanks to the people that are developing the Report Tool.
Comment #5
pegmonkey commentedI'll add my voice to this request too. I'll start writing some simple forms that should work for what I need, but I'm new to php and it might take me a bit to get something working.
Comment #6
ullgren commentedA simpel list mode is now implemented in the CVS release.
Comment #7
jnt commentedHere is some code that does some basic tally statistics on checkboxes and radio buttons.
I will post it here in case ullgren would like to use it and make it a patch or something.
It has co-opted one of his menu hooks and only handles checkboxes and radio buttons. It is not part of any official fork so I stress it is unsupported and try if you like.
It may not sit with his future design philosophy.
There are two files: webform.inc, webform.module
I will post the second in an immediately following post.
Comment #8
jnt commentedHere is the second file. The code is invoked from the "analyse" option from the webform menu.
Comment #9
ullgren commentedThanks!
I'll have a look at it tonight (Central European Time) and will probably add it to the CVS,
Comment #10
jnt commentedIf you like it and it's not duplicating work being done elsewhere, let me know and I will improve it a bit.
Having a look at it now I can see it could have perhaps percentages in place of tallies and maybe a little character based analog bar to give people faster relative proportions.
There is a tiny bug that was caused by a foreach throwing an exception on a zero length array. This occured if you did not tick any boxes in a group of checkboxes.
It is fixed in the attachment.
Comment #11
jnt commentedMy error. It is fixed in this attachment.
Comment #12
ullgren commentedPatched CVS.
Please send further patches in patch format or ziped.
Drupal.org seems to serve all .module and .inc files as coloured HTML and this makes them pretty hard diff =)
It might be sufficent to rename the files to .txt or something
Comment #13
jnt commentedWill do, I am travelling at the moment so I have no Unix tools.
I shall tidy the code, pull out the superflous commented code and make it a bit more efficient. There is a JOIN there that is not needed etc.. and I can see a couple of unnecessary range checks...
Are you happy for me to expand the analysis section in that format? I personally would prefer to see the reports done as a tab off the main page. ie, where it currently has sub-tabs on the main form page: /drupal/node/xx
"View Edit Outline"
I would like to add "Results"
Under this you would have a submenu with "submissions, analysis, tables, download, clear" etc... which would be for THAT forms submissions only. Permissions would be set so this results section is only viewable by appropriate persons, same as is done for "edit".
That way, the whole "Webform" menu option would dissappear, but if you liked you could have another "create content" option which would allow the adding of one or more tailored survey reports to the site. Again with appropriate permissions. One of these reports could be an "all webforms" which would list them all much as /drupal/webform does now.
Comment #14
ullgren commentedI look forward to your contribution. This feature is really something that i've been meaning to implement but never gotten the time to sit down and do. =/
About the tab idea:
I have also considered this solution and at first I thougth of it as a great way to do it.
BUT (isn't it allways a BUT) if you think about it from a administrative point of view:
I might have a site with quite afew webformnodes under a few diffrent catagories. If I'm a administrator that need to get the current state of the questionarie and just after the report, I don't want to navigate to the webform (and by that also adding a false hit in the statistic for the node) and then have to choose a tab (and then possible a subtask). In bestcase (webform node linked on the first page) this would end you up with 3 clicks as I count it.
Instead I would want a easy to access listing of all webforms available on the site from where I can get all my reports with as few as possible clicks. The current menu options gives you any given report with 2 clicks from _any_ point on the website. In the future the webform listing might also give me some stats about last submission and number of submissions, so I know if there are any new once since the last time I looked answering the question "Do I really need to check the submissions ?". This is also why I added the webform menu item to the "top" of the menu and not as a administer sub-item.
So the tab solution is a nice layout feature but from a admin point of view I really see the current approach as a better one.
My vote would be to keep the "webform" menu option and the list (and even expand it) and _also_ add the tabs. Both would direct you to the same report pages in the end so it would only be some changes in the _menu hook (?).
Comment #15
jnt commentedI still think you could get down to two clicks if you attached the reporting node to the books outline. Then you would simply get there through the top menu "books".
My intuition is that the statistics etc on forms will rarely be of interest to everybody and so should not take up menu real-estate. When they are of most interest to people is when "they" have just done the form.
I'll do a bit of research, in the meantime, here is another cut. See what you think. Feel free to hack at your leisure. There are many areas I am sure I am un-drupal and I am not strong with PHP.
There is some cases where the output needs to be more theme controlled for better layout management and there are a few magic numbers scattered about.
Comment #16
jnt commentedA few improvements:
Comment #17
jnt commentedA few more improvements:
The Covariance Matrix
I added this to allow webforms administrators (ala me) to quickly identify cross relationships between user answers. The table should be read left to right. The column and row numbers corresponding to the (now labelled) options on the Results Table.
The lighter colors (it is currently set as greyscale) have a higher correspondence with white indicating a 100% correspondence. This corresponds to the verbal statement: "Everybody who entered X also entered Y".
Similarly, darker shades indicate low correspondence with a black square making the statement: "No-one who entered X also entered Y".
The correlation calculation is done on an individual basis and the results normalized.
The diagonol white stripe follows because everyone who entered X also entered X.
However, the results are not a simple reflection about this diagonal given that "everyone who voted for X also voted for Y", does not mean "everyone who voted for Y voted for X". If you see hot spots on your default values, for example, it may mean people are just passing over them and you may be well served to make the question mandatory or have an explicitly non-comittal default, ie "Prefer not to answer", makes a good default.
I experiments with various colors, many highlight better than greyscale, but they either give a headache or will discriminate against the color-blind. I have left it as greyscale, there is one other commented out in the code.
I think that just about wraps up the "analysis" side of the webform unless anyone particularly asks for more. I would argue however, that any deeper analysis, should be done by a proper stats package after downloading the data. This is simply to give you a fast look at the responses so as to better design the questions.
Ullgren, how are you going with the 'txt' extensions on these. Are they working?
Comment #18
jnt commentedHi, I have added a download to csv under the "download" link on the Webform page. I made the csv flat so it is pretty easy to format under Excel or similar.
Feedback please.
Comment #19
ullgren commentedHello again (been really busy at my daywork the last couple of weeks).
Thanks for all patches. The .txt extension works great.
I guess this last file conatians all you additions ?
Comment #20
jnt commentedYes, that last file contains *all* my webform.inc stuff for your comments.
The major changes being:
I would appreciate your help with this last download function, the code is working as far as the users are concerned however throws a warning in the watchdog logs. Presumably something un-PHP/drupal I am doing. I posed a question and more description about it on the drupal forums at http://drupal.org/node/16926 but have not received any replies.
Comment #21
jnt commentedHi, one improvements and one bugfix to my report patch.
If anyone is using this patch, please give feedback.
Comment #22
pamphile commentedOK this might sound like a stupid question... but here goes...
How do I add this patch ?
Just save webform.inc in the same folder with webform.module ?
Where do I browse this data ?
Thanks
Comment #23
jnt commentedYes, just backup your existing copy of webform.inc and download webform.inc_3.txt and rename it to webform.inc It should be in the same folder as webform.module
Make sure you back up the old one so you can go back if you don't like it...
If you have any problems, let me know.
Comment #24
ullgren commentedAdded the file to cvs (with some cleanup)
Comment #25
jnt commentedI see the cvs output and the analysis section, coupled with what was there, as the bulk of the report section. As these are now in place am marking this as 'fixed'. Additional sub-report elements can have their own threads.
Comment #26
(not verified) commentedOK I added the webform.inc...
I submitted test data...
Now how do I see what was saved ? Where do I go ? Thanks again !
Comment #27
ullgren commentedBetter get the complete CVS release instead.
http://drupal.org/files/projects/webform-cvs.tar.gz
After installing this version a menu item called "webform" should show up for all users that have "maintain webform" privileges.
Comment #28
ullgren commented