Survey Solution

[Ralphie]

Greetings all,

I am in the process of developing a survey solution that users can answer questions on a laptop and where administrators can display the survey results real time with a click of a button. In addition the survey questions will also be loaded on a PDA and survey takers will be able to gather survey information via talking to customers and entering the answers via the PDA. PDA data will then be imported into the laptop that houses the main database that has all of the calculations etc for displaying the data/results.

The main problem is that the people who will admin this survey tool know nothing about Filemaker. So my thought is to develop a frame work where the admin could develop questions on the fly and associate the question with a pulldown that houses criteria such as "Excellent/Good/Neutral/Poor/Bad."

A main requirement for this solution is that the admin needs to be able to develop the questions on the fly. I was toying with standard valuelists linked to predetirmined fields. To develop the questions that are displayed on the screen I would develop a layout that had several global fields that the user could type his/her question into. Each global field would have an associated field and value list. This is a rough way of doing it. However If I did not use all of the predetermined fields how would I keep them from displaying on the layout/screen when a customer is taking the survey?

More importantly....is there anyone out there that has had experience with a survey solution like the one that I am describing?

Sorry to be so long winded here. But I needed to explain the whole problem. And if anyone is interested I am not getting paid for this and I will gladly post any solution that I come up with for anyone who wants it.

Cheers

Ralphie!!

[CobaltSky]

Hello Ralphie,

There are a number of ways to structure such a solution. However given the requirements as you've outlined them, I suggest that you consider using two files - one with the 'master copy' of the survey questions and the other with an accumulation of answers.

The master file need only have a single data entry field per record, into which the users can enter the text of the question. The master file should also have a global field to enter the name of the respondent into, a serial number field (auto-enter) to identify the questions and an unstored calc field which concatenates the global field and the serial number field, thus:

Case(not IsEmpty(gRespondentName), gRespondentName & "-" & QuestionSerial#

The related file need only have two fields - a text field called Answer_key to hold the respondent name and question serial - and a response field which accepts the values from your 'Excellent/Good/Neutral/Poor/Bad' value list.

Then you need a relationship from the main file to the responses file which matches the calc field with the answer_key field, and has the option to 'Allow creation of related records' enabled. The response field from the related file should then be placed on a list layout in the main file, along with the question field.

Once all this is in place, entering a new respondent name will instantly generate a fresh answersheet and then entering answers into the response field will store them on separate records in the responses file, where they will accumulate.

In the main file you are likely to need at least three layouts. A 'start' layout where the name of the respondent is entered, plus a list layout where all the questions appear, ready to accept answers for the current respondent. A third layout should present the list of questions along with a summary of the responses received to date - ie the live stats review for admin. This will require some additional calc fields in the main file which aggregate the values from the related records for each question.

A basic set-up as outlined above can then be extended in any number of ways to add options and finesse. For example, support for multiple questionnaires, optional alterative answer scales, graphical summary output etc etc...

If you're interested, I've attached a very simple demo that shows the kind of structure I've described in operation. It's very basic, but should give you a feel for what is possible.

One thing you'll note in relation to the method I've described (and the attached demo) is that adding a question is as simple as creating a new record in the main file and typing the question. You can't get much more 'on the fly' than that!

Questionnaire.zip

[Ralphie]

Ray,

I'm impressed with your demo. Please allow me to take a look and study your work over the weekend. There are days that I am reall intimidated by the knowlege on this forum......today is one of those days. Thank You for responding so quickly to me post.

Cheers

Ralphie

[CobaltSky]

Hi Ralphie,

No need to be 'intimidated' - there are folks here at *all* levels of FileMaker knowledge and experience.

If you find the demo I posted useful, but get stuck on some of the detail, I suggest you post any questions here and I don't doubt I or someone else here will be happy to offer comments or explanations etc.

Cheers and have a great weekend.

[Ralphie]

Ray,

Have spent time looking at your advice and solution. I populated some questions etc. I noticed that you were using the "Auto Enter Serial Number" in the options for the question# field. This works well when youy are developing the questions for the first time. However, when you delete a question and enter another the Question numbers are no longer sequential. Example: I was putting in a question say #6. After entered I decided that I didnt want it any longer and deleted question 6. Later on I wanted more questions instead of just 5 and added a question. However....the questions go like this: 1, 2, 3, 4, 5 and then 7. I deleted question 6 for one survey and wanted to add a question 6 back in for another. I do have a manual way around it but thought that your automated idea was better. Any ideas to use a calculation field for question number?

There are a lot more questions that I want answered but this one is the largest issue right now. Should I e-mail you direct?

Ralphie

[CobaltSky]

Hi Ralphie,

The demo was meant as a very simple sampler to give a sketch of a possible structure, not as the definitive solution, so various aspects of it would need to be developed further before you'd have a satisfactory final 'product'. The numbering is one of many areas that would warrant further attention.

The serial numbering was simply a mechanism to get a working model happening. In a serious solution you would likely want to have scripts defined to add and/or delete questions, and the way the numbering would be handled would depend on the detailed requirements of the end-users of the solution.

If serial numbering were to be used at all, then at the least, a 'delete question' script would likely be required, and would perhaps be configured to re-set the serial numbering to re-establish continuity. However since a question being deleted may not be thet last, it is possible that renumbering all the questions would be required. If this were the case, it would be desirable to establish a the questionID which is separate from the question numbers to ensure that any existing responses would not be orphaned (or end up being related to the wrong question etc).

There are a number of other ways an issue of this type might be resolved, but it makes no sense to start mapping out such details unless the requirments are clear. For instance, if there is any prospect that such a solution might be required to handle more than one questionnaire at a time, a quite different approach to question numbering might be in order.