Thanks for the quick feedback.  I saw that 1.9.1RC6 was released this morning and I'm looking forwards to working with it.

I'll provide a few quick clarifications below (in <TomW/> blocks), and will move more detailed discussion into the bugtracker tickets once I've created them.


On Mon, Apr 11, 2011 at 9:49 AM, Marcel Minke (Limesurvey) <> wrote:
Hi Tom,

thanks for your interest und your offer to help us improving it. We are currently working on releasing a first stable version of Limesurvey 1.91. There was another relese candidate (RC) relesed recently wso I recommend to test this one to check which features you are missing.

Some comments about the features you are looking for:
(1) New Question-Type for Calculations:
-> Currently the approach we recommend our users is to code the calculation in Javascript and then store the result into a hidden question. This works great but only if the numbers for the calculation can be found in the same page.
I wouldn't try to create a new question type for this but make use of question attributes because then you won't have to implement import/export/statistics/... for this question type but can simply use a numerical question type and use certain attributes for calculations.

<TomW>Actually, the reason I wanted a special question type for Calculation is that I DO want to be able to import/export those values and run statistics on them.  I also needed to support Number, Date, and String data types for the calculations. I'll make sure to clarify this and show examples in the ticket.</TomW>

(2) Conditional Tailoring/Piping:  This is needed to change the phrasing of a question, conjugate verbs/decline nouns, and form complex reports.
-> Some users already worked on this but I think it was not yet integrated into 1.91 because it didn't work correctly and the GUI was irritating for the users. Maybe you just need to improve the old design/code and don't hgave to reinvent the wheel. If I remember correctly it was used to e.g. display messages like "Dear {Mr.}/{Mrs} xyz" to dynamically change texts. Please contact our project leader Carsten Schmitz ( for more detaisl.

<TomW>I'd like to see what has been done.  Perhaps a related discussion is how critical an operational GUI is to such functionality.  As you know, building the GUI is often much harder than supporting the features, so in my system, I skipped the GUI entirely and instead had a debugging environment that would validate the syntax, and let users test their equations and conditional tailoring (e.g. both by navigating back and forth through the interview, over-riding values to see how it changed behavior, plus a jump-to command so that they could skip to later stages in the interview instead of having to enter 1000 answer in order to debug the end of a long interview).  Although in the end, all of my users wanted to use the conditional tailoring capabilities (once they learned how and saw how it could help them), most regular users don't think of such functionality.  So, rather than requiring a complex GUI for such functionality, LimeSurvey could consider making this a PowerUser-only features.</TomW> 

(3) a) Alternative Way to Reference Questions: 
-> This should be easy to improve but it has to be discussed because "our" users are used to a different syntax.

<TomW>I'm not proposing that you replace your current syntax for referencing questions - it works for all of your current users. Rather, I'm suggesting a second way to refer to questions that can work in parallel with your current process.</TomW>

b) My users often had to add, remove, or  re-order questions and groups during both the design and production stages of their research,so the only safe way to refer to their questions was via the variable name.
-> This is a different topic because currently you can't add/remove question/answer from a running survey because the table to hold the answer data is fixed once a survey is activated. We also want to improve this so if you find a solution that would be great!

<TomW>I did build a instrument versioning process into my system.  The two central units of my model were Instruments and Items, where and Item is an entity that combines the ItemType (e.g. question vs. calculation), Validation criteria, the QuestionText, and the AnswerOptions.  Items were meant to be help support a bank of re-usable questions such that if the same Item was used in two different Instruments, it meant the same thing.  That was one way I dealt with changes in Instuments after deployment - I could always merge together data from the same Item even if in multiple different instruments.  I also tended to keep a development vs. Production database environment.  I'd clutter up the Development environment with lots of versions of instruments, and I'd only promote the ones I really wanted to Production.

The other way I addressed vesioning was by moving from a specific to a generic data model.  Early on, like LimeSurvey, for each deployed survey, I created a table with one column per variable and one row per respondent (plus some supporting tables to track how far the person was within the instrument).  However, I found that I needed a lot of extra metadata about each response, so augmented that with a separate, generic, data model that would support all of the instruments.  Each Instrument had X Items, one per question (I didn't support matrix-style, so this might not quite work for you).  Once and Instrument was running, the InstrumentSession table kept track of status within the instrument.  At instrument launch, I'd create X rows in the DataElements table, one per Item, which kept the final values for each question.  For each screen rendered, I'd add Y rows to the ItemUsage table (one per each question displayed).  Each time a user clicked "Next" or "Previous" to move off the screen, I'd update the ItemUsage rows with the selected answer, and update the DataElements table with the  now-current values for each Item (thus, ItemUsage would track the full history of answers someone provided, even if they changed values).  I'd also add a row to the PageUsage table (tracking timing information and to support navigation path analysis), plus add rows to the PageUsageEvents table (to optionally track the user click stream to help create response latency metrics).  MySQL didn't have any trouble with this approach, even in cases where I had 2000+ Items per instrument.

I can attach a data model to the ticket for this.  If that experience can help, your design, great.  However, it has its own warts, so you probably won't want to use it as it.

(4) Import from Excel or other flat-file format - ideally with one row per question. Although the LimeSurvey user interface is nice, once you get past a few dozen questions, it can become cumbersome; and for 3000 questions in a survey, it could get painful.
-> I think users will love this feature but we have to agree on a certain synatx

<TomW>I can share the Excel syntax I used.  I always wanted to, but never figured out how to, support matrix-style questions, so I'm not sure what syntax would work best for that.</TomW> 

Can you please link the tickets you have created here so we can join the discussion?

Best regards,
Marcel Minke
(Limesurvey Head of Support)