Denis,

I think you are much more technically advanced than I am, I am afraid that I cannot see the complete implications of what you propose, sorry.

I understand that you would like to implement a non-javascript solution.

Hiding by CSS is not really hiding, is it? Because the HTML is there, but by display:none; it is hidden? In the script that I used the hiding can be done via uncommenting a javascript statement. Is that bad?

What I learned from your mail: you can add a class to a question based on earlier values? So a class on a question can be defined via Expression Script? I had never thought of that, but that is great.

Tammo

 Hiding by CSS is not really hiding, is it? Because the HTML is there, but by display:none; it is hidden?

Usually "display: none;" is a form of hiding by CSS.

With many workarounds where Javascript is involved to place content into answer fields, you can only hide these fields visually, The content is still in the HTML code and still public.
The Javascript code needs the form elements to write the data into it. If you use the "Always hidden" function of LimeSurvey the fields are removed from the HTML code.
So the always hidden function in LimeSurvey is less and less useful, since without workarounds the feature gap to the competition is too high.

The enduser can inspect and manipulate the data hidden via the webdeveloper tools bundled with every modern browser. That is no longer possible to prevent, without bringing LimeSurvey back into the stoneage.

bugs.limesurvey.org/view.php?id=11665

Thank you Jelo, this is clear: hiding via css and/or javascript is still open for manipulation. I think that in many surveys this will not be a problem, but still, I see the need for a more robust solution where data will still be written to the database, without any possibility that it is shown on the screen.

I guess that what Denis is working on (a plugin of special question type) will be more robust.

I think that a solution where you van use a special type of short text question and fill it with a variable that is detected, like viewport-width or isMobile would be very good, since it opens the possibility to tailor the survey to the possibilities that the user has.
I also think that defining a multiple short text question would even be better, but far more difficult to define, since it would need a specific user interface where the user (developer of surveys) is shown what is possible with that specific question.

Tammo

I guess that what Denis is working on will be more robust.

Not sure what he is working on. Expanding the plugin.

The typical approach of other survey tools is to provide a function to the logic (e.g IsMoble).
The feature request for LimeSurvey would be to add a ExpressionScript function IsMobile.

Personally I would like to see a more flexible function, since the definition of what a mobile vs. desktop view is, can differ over time.
It's often only about the viewport and screen. A notebook often has a lower resolution than a smartphone. So a function in ExpressionScript with a viewport/screen estate check (e.g Width/Height).

You still have the JavaScriptcode somewhere. Perhaps a flexible approach would be to have a variable screen, where you could define not only URL mapping, but could enter JavaScript or predefined scripts and assign them to a variable.

wrote:

The typical approach of other survey tools is to provide a function to the logic (e.g IsMoble).
The feature request for LimeSurvey would be to add a ExpressionScript function IsMobile.

 

Possible in 4.X via plugin, not before (sample : github.com/LimeSurvey/LimeSurvey/tree/ma...expressionFixedDbVar )
Before : to have a value in ExpressionManager : you need a question.

Currently : i update Browser + add isMobile and isTablet optionnal question code globally.

I didn't make a question settings for this. Because current one work on 3.X and in 4.X and after : better to have new variables like you say : isMobile etc …

If anyone wants to dig a bit deeper about mobile screens, a look at
www.mydevice.io/#compare-devices can help.

You still have the JavaScriptcode somewhere. Perhaps a flexible approach would be to have a variable screen, where you could define not only URL mapping, but could enter JavaScript or predefined scripts and assign them to a variable.

Could you please explain what you mean here? I do not understand. Trying hard...

Tammo

That is a thought about a feature request.
To prevent further confusion let's wait till you have the "more robust" approach at your fingertips and then compare the different solutions.

It's not mire robust : since there are no real securtity issue : i don't think you need a PHP solution.

But with a PHP solution : you can (i think ) have whole group separation, use variable in 1st page etc …


About a variable for screen size : you mean the real screen size or the current screen size.

And with zoom or without zoom ?

etc etc …

All done
gitlab.com/SondagesPro/QuestionSettingsType/findUserAgentInfo

(need to create a plugin topic here)

Nice!

Hi Joffm,

this is a very nice solution to save the information about the device. Unfortunately, I am not able to adapt your adaptions for the multiple short text question (the one with the long free text works fine). I used a multiple short text question, replaced the part of the code and added 3 subquestions. But the text fields are still empty. Do I need to change something else.

I am using Version 5.2.10+220118.