The purpose of this project is to provide a survey system that can run from one location and allow for multiple users each with multiple surveys. To make this system a true web based survey tool will require several enhancements on the current version.
Currently the system lacks web based administrative functions. This covers several areas such as online survey creation, online password additions and online review of results by the survey owners.
First lets make some distinctions on the types of users. There are three types of users on this system. The 'survey takers' are the users who take the survey using an assigned survey code. The 'survey owners' are the users who create surveys, set passw ords for the survey takers and review the results of their surveys. The survey administrator(s) is the person who administers the survey system software and handles any problems that might arise.
The administrative side of this software will include several parts.
The survey administrator(s) should be able to add and remove survey owner userids from a web application. The survey owner userid's and password's would be put into a password file that is parsed similar to the existing survey taker password file along w ith two additional attributes (the persons full name and e-mail.) The userid is the key for this record. There will need to be a check to make sure the userid is unique when a new id is added. The administrator will have to log on to a webpage with a p assword and userid to add the survey owner userid's and password's however since there is probably only one survey administrator it could be hard coded into the perl script rather then read in from another file. One problem with this approach is that the password file for the survey owners is world readable (just like the survey takers password file) and has to be world readable to work with a web based program. However these userids and password are more sensitive than the survey takers password file a nd this could be a security issue. A more secure method might be needed.
Survey owners will access the administrative functions by 'logging on' to a webpage with their userid and password. Once logged on the owners should be able to create new surveys, add new survey taker passwords (only for surveys they own), view/download survey results (only for surveys they own) and change their personnel information (password, full name, and e-mail address.)
The process of creating a new survey will require several forms. The first form will ask for the title, filename, and number of questions in the survey. The next form will allow the user to specify the type of question (scalar, yes/no, open answer, 3 qu estion multiple choice, 4 question multiple choice, etc), the text for the question and other attributes such as whether or not it should have a comment box after the question. The owner will do this for each question (the owner specified the number of q uestions in the previous form.) The next form will allow the user to specify the specifics for the type of question chosen such as the range on a scalar question, the text for each answer of a multiple choice question, the text in the scalar question (st rongly agree or strongly disagree, etc.) The next form will display the survey in its final form for the owner to review. At this point the owner can accept the survey or use the back arrow to go back and revise it. When the user accepts the survey the contents will be written to a file and the datafile created. Also the survey file and data file need to have permissions set, but since the account is being accessed with world permissions, this can not be done. So either a way needs to be found so the se permissions can be set or this script needs to automatically send e-mail to the survey administrator requesting them to set the permissions. The downside is that the administrator might not be able to set the permissions right away and the survey woul d not be accessible until they are set.
Survey owners will also be able to add survey taker passwords for surveys they own. When a user logs on to the survey administrator page their userid will be passed in a hidden field from page to page as long as they are on the admin pages. When a user chooses to add new passwords to the survey taker password file the perl script will show a drop down box with the titles of the surveys they have created (not sure how this will work just yet, maybe place their names at the top of the .srv files in an htm l comment and have the perl script scan each survey when the add password option is chosen.) The owner then specifies the users full name, a password, and submits the form. It will then add the record to the survey taker password file after checking tha t the password is unique as this is the key for these records.
Survey owners will also be able to download the results from the surveys they own. When the user selects this option they will be presented with a drop down box of the surveys they own. They will then choose to view the results in raw form, download the file, or possibly have the results analyzed with a web based analysis package (this option is probably several versions away.)
The last option for the survey owners is simply to change their password, name, or e-mail address. The owners e-mail and name are used when surveys are created and will need to be kept up to date and the password needs to be changeable for obvious reason s.
This system also needs increased security with password files. They are all world readable and need to be in order for web based applications to interact with them however this could cause possible security risks.
The coding of the program is largely without error trapping and recovery. Future version will add this capability and the ability to write problems to a log file. This is especially weak in the area of file handling.
If you have any addtional thoughts or comments on what should be added to future versions please send e-mail to Kevin Epperson.