oTree Forum >

Appearance of the radio select buttons

#1 by Charlie_T

Hi,

The short version is that the appearance of the radio select buttons from the RadioSelect Widget does not match the appearance of radio select buttons written in HTML. Is there a way to get them to match?  I have attached an example of the difference in appearance.  The first question is my basic HTML radio button, the second is the oTree widget version. Alternatively, is there a way to get a trigger for a javascript function into the python side of a code (specifically "onClick")? 

So as background for this question, I am creating a post-experiment demographic survey.  As part of that, I have several instances where I wanted to hide or show questions based on participant answers to previous questions.  One example is the attached image where I would like to follow up on political affiliation asking for the political lean of those who select 'Independent' or 'Other'. To do this, I created a basic show/hide function in javascript, which required that I write radio buttons in HTML that could trigger the show/hide function. This approach has worked but has resulted in the slightly different appearance of the radio buttons. Again if I can just get this implemented in the python end instead that would be preferred.   

Regards,

Charlie

#2 by ccrabbe

Hi Charlie -

For me the easiest way to do this with oTree would be not to use javascript to show/hide questions based on the user input, but rather split the questionnaire into several pages, and then change the subsequent pages depending on the data submitted in the first.

I would ask the first few questions (up until my next question would require a previous response) on the first page.  

Then, depending on the responses submitted on the first page (now stored in the model fields from the first page's form_fields) I would conditionally display either Page2 or Page3 (using the Page's is_displayed method), each of which has slightly different questions/wording depending on those first responses).

Or, for the second page I would change its content by conditionally set its form_fields with a get_form_fields method (which I could use if statements on the saved first page data to determine what fields to include)  https://otree.readthedocs.io/en/latest/forms.html#determining-form-fields-dynamically

And to answer your other question, the way that I would make custom html radio buttons look like those generated by oTree would be to use my browser's "inspect" feature to look at the class attribute generated by oTree, and assign those classes to my custom html elements, so that oTree's stack of styles is applied to my custom html like it is its own.

Thanks,
--Chris

#3 by Charlie_T

Hi Chris,

Thanks for the quick reply.  The inspect method worked.  By adding class = "form-check-input" to the html buttons, they now look like oTree's.

I did see the example code to have optional questions appear on a new page, but unfortunately I have about 4 follow up style question which would necessitate several possible follow up pages. I figured it was cleaner to have it all on one page.  Is there some other reason to recommend the use of a second page over a show/hide function in javascript?

Regards,

Charlie

#4 by ccrabbe

Hi Charlie -

Letting oTree generate the forms works out being cleaner to me, as I often need to remind myself of the id and class attribute requirements for custom html forms to actually have their data passed back to the oTree server (and in the past those requirements have changed with oTree versions, so in the past I've had compatibility issues with custom-html code).

Error messages are cleaner for me with oTree-generated forms, especially for quiz stuff where I am enforcing correct answers or keeping track of number of incorrect attempts, etc.  Also things like having answers persist if a player refreshes the page and things like that generally work out of the box with oTree-generated forms.  And server-side form validation is always harder for a subject to mess with than client-side.

The most common way I tend to work is a kind of hybrid mode where I always set label='' and then code the labels into my templates manually followed by an individual formfield tag (like {{ formfield 'fieldname' }}) instead of the {{ formfields }} tag, because styling isn't really available using the label attribute.

Good luck,
--Chris

Write a reply

Set forum username