Here are some general ideas I've been mulling over the last few days.
I've chatted a bit with Arma about them and some of his own ideas. I hope
this is a good amalgamation of them, but any discrepancies and errors are
my own.
If we are trying to make sdoc fairly readily usable, we also want folks
to be able to use it. I'm thinking specifically about those folks who are
using html editors (I'm one - the source will indicate good ol' Mozilla
as my editor), which have the nasty habit of hiding the contents of the
tags. Keeping the tag text itself as short as possible and the info for
the tag outside of the tag proper will make the programming job more difficult,
but I think that the clarity the user would have when building an sdoc-based
survey (and hence the greater likelihood of it being used frequently) would
be worth the effort.
Two general syntaxes are proposed:
<QUESTION %type% [="info"]> [other text] [</q> as separator] [</QUESTION>]
<QUESTION %type%> [info </q> as separator ][other text] [</q>
as separator] [</QUESTION>]
The first tag would be used to tell sdoc whether a draft or final version
is being used. A draft document would get parsed to produce solely the
HTML of the document, whereas the final document would have the back end
(database and cgi's) produced along with the document. In the case that
the tag is not specified, a draft document is assumed.
1. Status of Survey Document
<QUESTION STATUS="Draft">
<QUESTION STATUS>Draft</Q>
Also, the parser can leave a comment code to give some indication to
the user that the document has not been completely built:
<!-- 12 Jan 1998 14:25 final survey doc
not specied: See http://www.seul.org/sdoc for details>
<QUESTION STATUS="Final">
<QUESTION STATUS>Final</Q>
... would inform sdoc to create
the survey document and infrastructure. Once piece of information is still
required, however: The name of the script required to process the
form. To that end, another tag could be used to indicate the name of the
script (the survey document would already have a name by the time it was
sent to the parser).
<QUESTION SCRIPT="penguin">
<QUESTION SCRIPT>penguin</Q>
... would create a script called
penguin.cgi
to be placed inside the <FORM> tag when the page is built:
<FORM METHOD=POST ACTION="/penguin.cgi>
2. Checkbox
<QUESTION CHECK=%A% NAME=%B%>
<QUESTION CHECK>%A%</Q>%B%</QUESTION>
Where
%A% = The text of the question between quotation marks in
the first example.
%B% = The name of the question between
quotation marks in the first example.
<QUESTION CHECK="Check here if you like
Foo." NAME="LikesFoo">
<QUESTION CHECK>Check here if you like
Foo.</Q>LikesFoo</QUESTION>
... Check mark box. Simple stuff. The above
resolves to...
<INPUT TYPE="checkbox" NAME="LikesFoo">Check
here if you like Foo.
RESULTING DATA TYPE: BOOLEAN (0/1)
3. Yes / No question
<QUESTION YESNO=%A% NAME=%B%>
<QUESTION YESNO>%A%</Q>%B%</QUESTION>
Where...
%A% = The text of the question between quotation marks in the
first example.
%B% = The name of the question between quotation marks in
the first example.
<QUESTION YESNO="Are you a laptop user?" NAME="Laptopness">
<QUESTION YESNO>Are you a laptop user?</Q>Laptopness</QUESTION>
... radio buttons with Yes and No next to the two buttons. These would
be side to side. This would resolve to...
Are you a laptop user? <INPUT TYPE="radio"
NAME="Laptopness" VALUE="1">Yes <INPUT TYPE="radio" NAME="Laptopness"
VALUE="0">No<P>
RESULTING DATA TYPE: BOOLEAN (0/1)
4. Multiple Button (Range) question.
<QUESTION BUTTON=%Z% TEXT=%A% NAME=%B%>
<QUESTION BUTTON=%Z%>%A%</Q>%B%</QUESTION>
Where ...
%Z% indicates the number of buttons to present (integer)
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
... X radio buttons, choose one, no text next to radio buttons (putting
text to radio buttons would require <QUESTION GROUP> below). The survey
text would indicate the significance of the range of responses. This approach
would likely be most useful where there is no ambiguity permitted (ie.
where 'don't know' is not an option).
Please indicate how important you think the following factors are to
your success (from Very Important to Not Important):
<QUESTION BUTTON=3 TEXT="Cooperative spirit" NAME="btnCoop">
<QUESTION BUTTON=3>Cooperative spirit</Q>btnCoop</QUESTION>
... would resolve to:
Please indicate how important you think the
following factors are to your success (from Very Important to Not Important):
<BR>
Cooperative Spirit:
<INPUT TYPE="radio" NAME="btnCoop" VALUE="1">
<INPUT TYPE="radio" NAME="btnCoop" VALUE="2">
<INPUT TYPE="radio" NAME="btnCoop" VALUE="3">
[Would a space code be needed between the
radio buttons?]
RESULTING DATA TYPE: BYTE (0-255) is suggested.
5. Multiple Number (Range) question.
<QUESTION NUMBER=%Z% TEXT=%A% NAME=%B%>
<QUESTION NUMBER=%Z%>%A%</Q>%B%</QUESTION>
Where...
%Z% indicates the number of buttons to present (integer)
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
... as ButtonX, but buttons are numbered starting from 1. The survey
text would indicate the significance of the range of responses. This approach
would likely be most useful where there is no ambiguity permitted (ie.
where 'don't know' is not an option). In a situation where the survey builder
wants to use a different number sequence, the <QUESTION GROUP>
tag below could be used instead.
On a scale of 1 to 5, please rank the importance of the following (high
numbers indicate higher importance):
<QUESTION NUMBER=5 TEXT="A stable operating system:" NAME="numStabOS">
<QUESTION NUMBER=%Z%>A stable operating system:</Q>numStabOS</QUESTION>
... would resolve to:
A stable operating system:
<INPUT TYPE="radio" NAME="numStabOS" VALUE="1">1
<INPUT TYPE="radio" NAME="numStabOS" VALUE="2">2
<INPUT TYPE="radio" NAME="numStabOS" VALUE="3">3
RESULTING DATA TYPE: BINARY (0-255 is suggested)
6. Radio buttons with several options.
<QUESTION GROUP=%A% NAME=%B%>%C1%</Q>%C2% [... </Q>%CX%]</QUESTION>
<QUESTION GROUP>%A%</Q>%B%</Q>%C1%</Q>%C2% [... </Q>%CX%]</QUESTION>
Where...
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
%C1%, %C2% ... %CX% indicates the text to be put for each
of the options
... This would set up a list with several options with radio buttons.
Two behaviours would be implicit: the buttons would fall next to each other
if there were no text in the first button position (sdoc would assume we've
set up the question for a continuum of responses like 'How important is
OS Stability, from Extremely Important to Extremely Unimportant', and yet
still allow us to have the option of 'unsure' at the end of the line),
or the options would fall one under the others. In
all cases, the buttons should come before the text (less confusing and
it would be more consistant that way for the options). An example of the
first behaviour (eg. like the <QUESTION BUTTON=5> tag but with
the 'Unsure' or negative answer) would be:
<B>How important are the following to you,
ranging from Extremely Very Important to Unimportant</BR>
<QUESTION GROUP>OS Stability:</Q>numStab</Q></Q></Q></Q></Q></Q>Unsure</QUESTION>
... which would resolve to:
OS Stability:
<INPUT TYPE="radio" NAME="numStab" VALUE="1">
<INPUT TYPE="radio" NAME="numStab" VALUE="2">
<INPUT TYPE="radio" NAME="numStab" VALUE="3">
<INPUT TYPE="radio" NAME="numStab" VALUE="4">
<INPUT TYPE="radio" NAME="numStab" VALUE="5">
<INPUT TYPE="radio" NAME="numStab" VALUE="6">Unsure<BR>
... and an example of the second (one option below
the other) would be:
<QUESTION GROUP>Which one of the following
would you say is the most important for your own computer use:</Q>numImport</Q>Very
stable OS</Q>Availability of Application Source Code</Q>Newsgroup
Support</Q>Cute Penguins</Q>I have no idea.</QUESTION>
... which would resolve to:
Which one of the following would you say is the
most important for your own computer use:
<INPUT TYPE="radio" NAME="numImport" VALUE="1">Very
stable OS<BR>
<INPUT TYPE="radio" NAME="numImport" VALUE="2">Availability
of Application Source Code<BR>
<INPUT TYPE="radio" NAME="numImport" VALUE="3">Newsgroup
Support<BR>
<INPUT TYPE="radio" NAME="numImport" VALUE="4">Cute
Penguins<BR>
<INPUT TYPE="radio" NAME="numImport" VALUE="5">I
have no idea<BR>
RESULTING DATA TYPE: Binary (0-255 suggested,
with options referenced in another table)
7. Option Group with Single Selection.
<QUESTION SELECT=%A% NAME=%B%</Q>%D1%</Q>%D2%
[... </Q> %DX%] </QUESTION>
<QUESTION SELECT>%A%</Q>%B%</Q>%C1%</Q>%C2% [... </Q>
%CX%] </QUESTION>
Where:
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
%C1%, %C2% ... %CX% indicates the text to be put for each
of the options
... Similar to the <QUESTION GROUP> tag
in that you can select one option, but this time using a drop-down menu
box, which this would have the added advantage of seemingly shortening
the survey since we would use fewer vertical inches for any given question.
This example substitutes the given option names with
numbers in the returned info to the database; this should help keep the
size of the beast smaller and more manageable for analysis (but I could
be mistaken). Two examples:
<QUESTION SELECT="What OS would you say
you use the most?" NAME="sglOS">Linux</Q>OS/2</Q>MacOS</Q>Windows
95/98</Q>Windows NT</Q>Unsure</QUESTION>
<QUESTION SELECT>What OS would you say
you use the most?</Q>sglOS</Q>Linux</Q>OS/2</Q>MacOS</Q>Windows
95/98</Q>Windows NT</Q>Unsure</QUESTION>
... which would resolve to:
What OS would you say you use the most?
<SELECT NAME="sglOS" WIDTH=300>
<OPTION VALUE="1">Linux
<OPTION VALUE="2">OS/2
<OPTION VALUE="3">MacOS
<OPTION VALUE="4">Windows 95/98
<OPTION VALUE="5">Windows NT
<OPTION VALUE="6">Unsure
</SELECT>
<P>
[I'm forcing a substition mapping of the VALUE
tag for a number, as it will reduce the size of the database; this data
can be added and JOINED from another db table ... more work, but it will
keep the db easier to analyse. Suggestions, comments?]
RESULTING DATA TYPE: BINARY (0-255 is suggested,
with the options stored in a linked table)
8. Option Group with Multiple Selections.
<QUESTION MULTIPLE=%A% NAME=%B%</Q>%D1%</Q>%D2%
[... </Q> %DX%] </QUESTION>
<QUESTION MULTIPLE>%A%</Q>%B%</Q>%C1%</Q>%C2% [...
</Q> %CX%] </QUESTION>
Where:
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
%C1%, %C2% ... %CX% indicates the text to be put for each
of the options
%X% (below) is an integer within quotation marks inserted
by the parser.
... Similar to the <QUESTION GROUP> tag
in that you can select several options, but this time using a scrolling
menu box, which may not be as efficient as saving space than the former
tag; it may be more difficult for novice users to properly complete questions
with this tag. Again, this example also substitutes the given option names
with numbers in the returned info to the database; this should help keep
the size of the beast smaller and more manageable
for analysis (but I could be mistaken). The %X% below is an integer
in quotes, which I suggest be set to approximately half of the number of
entries in the list (as calculated by the parser) Two examples:
<QUESTION MULTIPLE="Which Operating Systems
do you use?" NAME="mplOS">Linux</Q>OS/2</Q>MacOS</Q>Windows 95/98</Q>Windows
NT</QUESTION>
<QUESTION MULTIPLE>Which Operating Systems
do you use?</Q>mplOS</Q>Linux</Q>OS/2</Q>MacOS</Q>Windows
95/98</Q>Windows NT</QUESTION>
... which would resolve to:
What OS would you say you use the most?
<SELECT NAME="mplOS" SIZE=%X% MULTIPLE
WIDTH=300>
<OPTION VALUE="1">Linux
<OPTION VALUE="2">OS/2
<OPTION VALUE="4">MacOS
<OPTION VALUE="8">Windows 95/98
<OPTION VALUE="16">Windows NT
</SELECT>
<P>
[This will probably be the hardest to build, as
there can be many answers; perhaps this problem can be resolved by taking
all the answers and putting them into a table, and giving each a bit of
a binary number such that a single integer can be built from the choices
(00001 could be 'linux' in the above example, 00003 could be both linux
and OS/2. Just a thought. Suggestions, comments?]
RESULTING DATA TYPE: Binary (0-255) is suggested,
with each option chosen representing one bit; user id would be linked 1:many
to an intermediate table where chosen options would also be linked many:1
to a table containing the options text.
9. Text Box question.
<QUESTION TEXT=%A% NAME=%B%>
<QUESTION TEXT>%A%</Q>%B%</QUESTION>
Where...
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
... this tag would be useful where a non-constrained
response is required, such as personal information (name, email address,
etc) or such. It should be noted that there is a limit to the number of
characters that can be entered into the box, and the longer the field the
more space the information takes up in the database (particularly when
there are a large number of respondants) and thus the current example does
not implement any sizing information, giving a default of 35 characters:
this should be enough for most text entry (pretty much all email addresses,
for instance).
<QUESTION TEXT="What is your email address?" NAME="strEmail">
<QUESTION TEXT>What is your email address</Q>strEmail</QUESTION>
... would resolve to:
What is your email address?
<INPUT TYPE="text" NAME="strEmail" SIZE=35
MAXLENGTH=30><P>
[Should we allow the user to set the field
length or just leave it default (or leave it as default if the user does
not specify a length?]
RESULTING DATA TYPE: TEXT. This can be stored
in the main database table as long as the text string remains short (30
chars or so).
10. Paragraph question.
<QUESTION PARA=%A% NAME=%B%>
<QUESTION PARA>%A%</Q>%B%</QUESTION>
Where...
%A% indicates the text of the question within quotation marks
in the first example, and
%B% indicates the name of the question within quotation marks
in the first example.
... this tag would be useful where an essay-type
question would be called for. The ROWS=%W% and COLS=%Y%
attributes could be added within the tag (in the first example, or between
</Q>'s in the second), or the parser could use a default setting
for this question type. It goes without saying that this is probably the
single most 'expensive' question type to include in a database, as it will
cause each record to swell, and taken repetitively, make the entire database
to grow very, very quickly, even when an answer is really short or just
isn't given.This could be farmed out to another linked table, so that less
space would be taken up.
<QUESTION PARA="We would greatly appreciate
any suggestions you might have to improve this survey." NAME="paraText">
<QUESTION PARA>We would greatly appreciate
any suggestions you might have to improve this survey.</Q>paraText</QUESTION>
... would resolve to:
We would greatly appreciate any suggestions
you might have to improve this survey.
<TEXTAREA NAME="paraText" ROWS=10 COLS=50
WRAP></TEXTAREA>
RESULTING DATA TYPE: TEXT. This text should
be stored 1:1 outside of the main table. This should keep the table fast,
and not waste info if respondants don't answer this box.
11. Submit button
At some point, the user will have completed filling out the
form and the data can then be checked and submitted into the database.
This is a very simple tag; seems like the user can I'm suggesting that
sdoc just give a default setting here. If the survey builder wants different
text, s/he can build the appropriate tag.
<QUESTION SUBMIT>
... would resolve to:
<INPUT TYPE="SUBMIT" VALUE="Submit Answers">
12. Clear button
Same as above, but to clear all answers on the survey. It goes
without saying that sdoc would also insert generic text onto the button,
so the survey builder wanting a different wording
here could do it on their own.
<QUESTION CLEAR>
... would resolve to:
<INPUT TYPE="SUBMIT" VALUE="Clear Answers">
|