Objective

We want to have a way to create forms, surveys, questionnaires, and ballots on the intranet. Uses could be as simple as an RSVP, or as complex as an application form or a ballot with attached CVs in PDF format.

Solution

The basis would be an object that would have some similarities to the SurveyPoll. To avoid confusion with the existing SurveyPoll, I'll suggest that we might call it a DataForm, or InputForm, or  WebForm, or just Form.

I think people generally know what "form" means in the context of the web, and since we've got simple names for object types like Folder and Image, I'm leaning towards calling it simply a "Form."

A Form object would define the questions and layout of the form, and would contain one or more instances of the form.

Each instance would allow you to customize any blocks of display text and optional attached files, as well as the text of the questions. Instances would not let you alter question types or the values of multi-value questions.

Instances would contain their responses, and would be able to list and display them in a number of formats.

Form object details

View:
The Form's default view would be a list of it's published instances. My first thought is that you should be able to specify how that list looks in much the same way you specify a folder's display options: should the Form's title and description be visible? For the list of instances, should it show them in a table or a link list? Should the instances thumbnails, titles, dates and/or descriptions be visible?

That would seem to imply that there should be an Appearance option for the Form. But, since I seem to recall that we decided that trying to subclass Folders was a bad idea, that would mean copying all the Folder's mechanics for that feature, so that may not be the way to go. Maybe just include those choices on the Properties option, or (I think I like this better) have an Appearance option, but just show the display option settings form, and omit the fancy drag-and-drop stuff.

Instances:
This would be similar to the Folder's Contents option, and perhaps it should also be called Contents. I like Instances because that's all it would ever show, and that way the link tells you exactly what you'll be seeing. On the other hand, would most people understand the term? Do we need to come up with some other term to refer to an instance of a form? (I'm not keen on a "Run".)

Like a Folder's Contents option, this should show the status (draft, published, archived) of the instances, sort options, a button to add an instance, and perhaps a button to close all instances as well.

Appearance:
If we decide that we need it. Or this could be just a version of the Display Options form that's in the dialog you get when setting the Form's appearance when placed on a Folder's Appearance.

Template:
This would let you build the form in much the same way as the SurveyPoll does. A drop-down menu of question and display object types, a way to reorder them, and edit forms for each type.

This might be a good time to introduce Admin-only fields. These could be used for administrative processing of forms. The admin would be able to see and edit them, but users wouldn't.

We may also want to introduce a file-upload question type, so users can submit things like resumes. (Would this create security problems?)

Ideally, I think this should work like the Portal or Folder Appearance, with some Google calendar features added. You'd have a palette of icons along the top, and would add a question or display object by dragging its icon to where you wanted it to be on the layout. When you drop it, it would render the add form in that spot on the form (with Save and Cancel buttons). You'd fill out the values and save, at which point an Ajax call would be sent to the server and the block would re-draw itself as it will look to the user. Each object could be dragged around the form, multiple columns would be possible, and clicking on an object would let you edit it in place.

That would be the ideal. I'd settle for a Preview Form button for now, though.

Properties:
This would be the basic set of properties, plus ones modelled on the SurveyPoll object, which has these:

•   unique_user_filter
•   include_timestamp
•   acknowledgement
•   close_survey
•   closed_message
•   submit_button_text
•   page_css

I think that unique_user_filter and include_timestamp should definitely be properties. Brian and I had talked about just using the publish/archive dates, but that wouldn't prevent someone who had the URL from taking an archived form unless we changed the archive behavior for this object.

At lunch today we hit on this plan: Forms have the usual Publish Date and Archive Date properties that will control whether or not the Form is visible in lists. Instances will have Open Date and Close Date fields that control whether or not to let users fill them out.

(Brian: I think we may want to include the publish fields on instances, too. There may be times when you'd want people to see recent instances when viewing the Form's list of contents, but not be able to take them. I'd think that the link to the instance should be clickable, but there should be something in the list that indicates it's closed, and if you click it you get the closed message. I don't think it would be more confusing than having a published HTML Doc inside a Folder that's archived, which can happen now.)

As for the acknowledgement and closed_message properties, I'd prefer to have something that's friendlier than editing raw code in a small textarea. Our suggested solution: break the Acknowledgement and Closed Message onto separate options screens and use the FCKEdit applet to let you create the pages.

Acknowledgement:
WYSIWYG editing of the acknowledgement page.

Closed Message:
WYSIWYG editing of the page that's returned when the form is closed.

Notification:
Properties for confirmation emails and notification to administrators.

Instance object details

View:
  - The Instance's default view would be the rendered form, acknowledgement, or closed message, depending on the circumstances.

Responses:
A list of the submitted forms. We discussed giving the admin a choice between seeing the results in a table the way the SurveyPoll shows Results, and listing out the submitted forms in something like the actual form's layout, so that they can be printed in a friendly manner. Both views would include a link to view an individual response.

By using the neat CSS page-break options that Brian mentioned, and perhaps doing some Javascript re-writing of stylesheets or Ajax calls, we could offer the admins options for printing the fully-rendered version with one response per page, or as one continuous document.

We could also offer a way to show, hide, and maybe even reorder the columns on the table view, so you could print abbreviated reports from it. Checkboxes on the left could let you select only a subset of responses to print or view, hiding the others.

Printing options like these, along with admin-editable fields, could be very helpful. 

Template:
This would let you customize the default values in the Form template. Text blocks could be altered, file links could be changed to point to specific files within the Instance, and question titles could be changed. (But not values, so the Form could be made to do reporting across all its instances.)

Properties:
All the same properties as Form, except (maybe) publish and archive dates. As with all these option pages, if you don't customize something at the Instance level, then the Form's value is used as the default.

Acknowledgement:
WYSIWYG editing of the acknowledgement page.

Closed Message:
WYSIWYG editing of the page that's returned when the form is closed.

Notification:
Properties for confirmation emails and notification to administrators.

Example structural outline:

DT = Display Text,
DF = Display File
Q = Question
AF = Admin Field
I = Instance
R = Response.

Form
    - DT1
    - Q1
    - Q2
    - DT2
    - DF1
    - Q3
      Instances (folder)
           - I1
           - I2
                - DT1 (overrides Form/DT1)
                - DF1 (overrides Form/DF1)
                  Responses (folder)
                      -R1
                          - Uploaded File