Re: [limesurvey-developers] LimeSurvey 2.0 Prototype Architecture

[Macasek, M. A. <mma...@mi...>]

Mike,

Thank you for your comments/suggestions. Currently we already have a
likert scale question type which is capable of supporting at least 2
choices and technically up to an infinite number of choices (although
we should probably cap it at some point as infinity is a little much ;)
). If you have some time check out http://design.limesurvey.org where
there is the start of a "question library". This "question library"
will be the baseline of what we hope to support in LS2. Currently there
are some CSS issues on the Question Library but it should give you a
sense of where we are heading.

As for some of the other scale varieties you are looking for, if you
can provide us with some examples we will try our best to work them
into the system. We also intent to support custom question types where
LS users/admins can define their own question types which will allow
for new question types to be added to the system if the default set
does not meet your needs. We hope to support as many question types as
humanly possible!

Thanks again for the feedback.


Michael


-----Original Message-----
From: lim...@li...
[mailto:lim...@li...] On Behalf
Of Michael Thomas
Sent: Wednesday, November 14, 2007 5:59 PM
To: lim...@li...
Subject: Re: [limesurvey-developers] LimeSurvey 2.0 Prototype
Architecture

Very through overview thank you.

You may have covered this--my interest/view is as a user not a
developer. I want to advocate answer scales (scales) as a separate
function than LS's current "question type" convention. A survey
question is simply a statement or question--requiring no type.

Scales comes in many varieties, (likert, open ended, etc.) having a
scales feature as a separate component would allow users more options.
Currently, to change a scale in a survey I am required to edit each
survey question. I have not been able to get labels sets to work for
my use.

With scales as a separate function users would be able to edit scales
and apply them to categories/groups in one step. Just as questions
come in libraries--survey scales could come in libraries as well.

Mike T


On Nov 14, 2007 4:19 PM, Macasek, Michael A. <mma...@mi...>
wrote:
>
>
> LimeSurvey 2.0 Prototype Architecture
> 14.November.2007, Doc v0.01
>
>
> This is a high level overview of the LimeSurvey 2.0 architecture
based on
> what currently exists in svn.
>
>
> Core of the system:
> A survey consists of at least one survey_section. A survey has
> * a name that identifies it and
> * serves as nothing more than an entry point to the survey contents.
>
>
> The survey_section consists of questions via the
> question_survey_section_map. Questions are tied to the survey_section
in
> this way to allow for their reuse.
>
>
> The position of a question in a survey_section is imposed in the
mapping via
> a position field. Although it is not yet currently supported in the
code,
> survey_sections can contain survey_sections.
>
>
> There are currently two types of survey_sections:
> * normal
> ** normal indicates that nothing special is to be done with this
section
> and
> * page_break
> **  page_break survey_section indicates that this particular
survey_section
> is the last one to be shown before the end of the current page the
user is
> viewing.
>
>
> templates and template_params are used to define the UI layout of
questions
> and their components. Currently, they do not apply to surveys or
> survey_sections but may in the future. We need a way to store layout
in the
> database but not overly complicate the data model. We created generic
> templates associated with 'types' (question_types, input_types,
> test_section_types, etc) that defined the layout. The template is an
XML
> string that contain nodes for layout components (divs, spans, etc)
and for
> section components (inputs, text labels, etc).
>
>
> Each object that is associated with a given 'type' uses the template
> associated with that 'type' as a baseline layout. The layout can then
be
> modified by template_params. Template_params:
> * only allow for the customization of the section components and
> * are a comma-separated list of key value pairs.
>
>
> In most cases, the key/value is passed through to the generated html
element
> (e.g. class=3Dsome_class). One cannot modify the layout components
through the
> template_params.
>
>
> Questions are reusable and can exist in multiple surveys. They are
made up
> of three main components:
> * text_question_sections
> * input_question_sections and
> * media_question_sections.
>
>
> These sections can appear in any order or number. When the questions
are
> pulled from the database, they are put into a single ordered list
(queue)
> based on each of their positions. They are then consumed in order as
> dictated by the template.
>
>
> Input_question_sections are reusable components that are tied to the
> questions via the input_question_section_question_map.
> Input_question_sections may consist of one or more inputs which are
> interpreted differently depending on the 'type' of the
> input_question_sections. For example if the type was
'radiobuttongroup' or
> checkboxgroup' the list of inputs are interpreted as the option in
the
> groups. If it was a 'textarea', the first input is interpreted as a
default
> value and all other inputs are ignored.
>
>
> Rob Thew will lead the discussion/explanation of condition_sets and
> condition_atoms.
>
>
> The responses and progress objects track user progress on a
particular
> instance of a survey. A 'Response' is the response the user has given
for an
> input_question_section on a survey for a given progress. A 'Progress'
is the
> object that encapsulates all the information related to an
individual's
> survey-taking activities. A user can have multiple progresses, which
> indicate that the user has taken the survey multiple times. However
only one
> of those progresses can be marked as not completed. The progress
tracks a
> users progress in a survey allowing them to leave and come back to
the same
> spot in the survey. It also indicates if the survey is complete and
allows
> you to view all the responses associated with that time the survey
was
> taken.
>
>
> Users are members of groups, which can be hierarchically defined.
Groups are
> then assigned to a survey. The assignment defines the start and end
dates of
> the survey as well as other metadata such as if the users should get
email
> reminders and other alerts.
>
>
> The data model is missing:
> * email_templates,
> * languages,
> * user/group roles,
> * metadata and custom attributes, and
> * versioning, just to name a few.
>
>
> The difference between metadata and custom attributes is that:
> * metadata is data that will de directly associated with an object (a
field)
> this consists of information that every LS admin will track such as
full
> name of a user, email address of a user, etc.
> * custom attributes will allow for LS admins to add additional
metadata that
> is related to their particular domain to objects.
>
>
>
>
> Quick tour of the code base
>
>
> Every data model object has its own model in the app/models folders,
which
> also sets up the relationships to other objects as defined by the
foreign
> keys on the tables.
>
>
> There are two sql files of note in app/config/sql:
> * limesurvey_mysql.sql and
> * question_library.sql
> which are in mysql syntax (port these to other dialects will be
required).
> In the app/controllers folder there are the controllers for the
application.
> Before any action is invoked, the LS service checks to see if the
user is
> logged in and if not, they're directed to the users/login action.
>
>
> The surveys controller is the main controller, which governs how a
survey is
> presented and how the results are recorded.
>
>
> Located in the app/views/helpers directory are helpers for parsing
and
> generating a survey.
>
>
> App/controllers/surveys_controller/survey action and
> app/views/surveys/survey.thtml
> are the main actions and view for displaying a survey. This is where
the
> parsing and generating of the survey HTML begins.
>
>
> This is just a start (v001 of the architecture description).
> If there are any questions, fire away.
>
-----------------------------------------------------------------------
--
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> limesurvey-developers mailing list
> lim...@li...
> https://lists.sourceforge.net/lists/listinfo/limesurvey-developers
>
>

-----------------------------------------------------------------------
--
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
limesurvey-developers mailing list
lim...@li...
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers