Re: [Quexf-discuss] QueX__ integration with LimeSurvey

[Carlos N. C. <car...@gm...>]

Hi Adam

I am who hac to be grateful for your support these days.

I understand what you say and it's perfectly normal. That's is how 
things have to be.

Of course we and my company are interested in developing integration 
between LimeSurvey and QueXF, also we're thinking in a CATI integration 
and VoIP too, as I've told LimeSurvey guys. Problem is always the same: 
funds ;-). We're looking for some type of public ICT programs that 
perhaps could help us to open some type of collaboration. You guys seem 
the perfect people to do things possible. I'm only an economist with 
statistical tendencies :-) who is interested in new technolgies.

In the meanwhile I'll continue this experiment using QueXF with the PDF 
I could generate, testing OMR and OCR and providing feedback on your app 
for you.

Thank you very much

Carlos


Adam Zammit escribiu:
> Dear Carlos,
>
> Thank you for discovering these bugs and assisting in fixing them.
>
> I am glad that you have finally got a PDF instrument generated.
>
> I understand the issues that you mention with the LimeSurvey -> queXML 
> process. The Limesurvey -> queXML process is not complete, and was not 
> written to handle multiple language cases and to handle all question 
> types.
>
> The reason for this is that we have not had a need to do this 
> internally. Also, the intention of queXML is to be the base instrument 
> which is then converted into (not out of) Limesurvey, and also to PDF 
> or to a CATI instrument.
>
> We released this code as open source in the hope that others will add 
> the kind of functionality that you require themselves and then release 
> it back to the community.
>
> As we do not require the kind of modifications that you request 
> internally, I could not justify working on those kind of modifications 
> in my normal work time - but if you are interested, DCARF (see 
> http://www.deakin.edu.au/buslaw/dcarf/contact/ ) can provide a very 
> reasonable quote for my time to implement the features you require, 
> and of course, these would be released back to the community.
>
> Regards,
> Adam Zammit
>
> Carlos Neira Cortizas wrote:
>> Dear Adam,
>>
>> Finally I've been able to create my first PDF questionnaire starting 
>> from a LimeSurvey instrument. Thank you for your support.
>>
>> However, I found several problems. From my point of view these 
>> problems don't allow general using of LimeSurvey & QueXF together. I 
>> explain this sentence in the next points, but it's all about the 
>> conversion process, not because of LimeSurvey or QueXF applications 
>> themselves.
>>
>> 1. Customization of paper form:
>>
>> Process involving conversion QueXML file to PDF through XSL:FO is not 
>> customizable (or it's not easier for a general user). It's not about 
>> the aesthetycal apparence of the questionnaire (it's ok and it's 
>> possible to define font syze and margins) but other things such as:
>>
>> - The localisation of the texts in titles, presentation and 
>> instructions. They 're in english.
>> - The logo selection. The PDF conversion tries to find a Deakin 
>> University logo in a linux path that not exists in the local machine. 
>> In addition changing the logo it it's not possible.
>>
>> The only solution for this is disabling cover page and first 
>> (instructions) page in QueXML Tools when exporting QueXML to XSL-FO.
>>
>> 2. Multilanguage questionnaire:
>>
>> Since LimeSurvey has this option it seems convertion process doesn't 
>> allow manage this type of questionnaires.
>>
>> - A bilingual survey produces a PDF that includes twice the same 
>> section, twice the same question (at each section), and twice the 
>> same answer option (in each question at each section). Text for both 
>> languages is presented, first the base language and then the other 
>> one. Everything results in an extraordinary lenght for the PDF 
>> questionnaire (and file size of XSL-FO file it's been created from).
>> - In addition, there is a problem on moving the language selection 
>> question/section to paper. It seems that each language selection 
>> option 'creates' or 'defines' a section in the paper form. This 
>> question, first in my LimeSurvey questionnaire after presentation, 
>> generates two Sections in the PDF (A and B). Under each one of these 
>> sections the text for the questions appears twice, this is four times 
>> in total. It's clear that there is no sense in translating this 
>> question type to paper. What is needed is to allow selecting one or 
>> other language before creating (or printing) the XSL-FO file.
>>
>> The only solution I see now is creating a monolingual survey. If more 
>> languages are needed the 'easiest' way of proceeding I know is 
>> exporting the monolingual survey and editing the copy adding the new 
>> languages. Then use the copy for web interviewing and the original to 
>> produce the paper version with only one language. If many languages 
>> are needed fisically then many monolingual versions have to be 
>> created in LimeSurvey.
>>
>> 3. Question types not yet implemented
>>
>> In QueXML export. Survey designer must consdier this before creating 
>> a survey. It's direct that a ranking question type is not translated 
>> to paper as-is, but for example I easily forget not to use free short 
>> texts question type, because PDF only includes the question text but 
>> not the answer for this type.
>>
>> 4. Improved questionnaire:
>>
>> These are other bugs I found, or some improvements I think they 
>> provide basic functionality:
>>
>> - Section description is limited to only one line. If there is a 
>> longer text in LimeSurvey, with two or more lines, all they appear 
>> one over the other in the PDF, resulting in a illegible text. There 
>> is not line feeding.
>> - Both section number and question letter don't use the codes from 
>> LimeSurvey. Sections are lettered A,B,C... and questions A1,A2,A3....
>> - Number of cells in the answer for a numerical question type. It 
>> seems that there are always 10 cells or spaces in answer for this 
>> type of questions. For example: for asking the age only two (or 
>> three) are necessary. In LimeSurvey I've defined the 'maximun_chars' 
>> attribute with '2' and the 'text_input_width' with '3', but none of 
>> they are used.
>> - Something similar happens with short text question type. There are 
>> always 24 cells, no matter if I've defined a lenght of 40 or 12 in 
>> 'maximum_chars' attribute.
>> - Same thing with free hugh text. There are always 10 lines one with 
>> its 24 cells. No matter what number is at 'display_rows' attribute.
>> - Dropdown adn radio lists question types produce vertical listings 
>> in the PDF that are very big and rob a lot of space. Using 
>> 'display_columns' attrribute in LimeSurvey don't change the final 
>> appearance.
>> - Comment texts in aswers for many qustion types remains in english. 
>> 'Yes/No' in this question type, and 'Yes/Uncertain/No', when english 
>> language is not the base language too.
>> - Conditions are not visible in the form. No indent, no lines or 
>> marks that indicate an optional question.
>>
>> Sorry for the extension. I only tried to help documenting the 
>> application bugs and how it applies to my needs. Hope it will be useful.
>>
>> Regards.
>>
>>
>