Add additional text input to existing options field.

[elabx 496]

Hi everyone!

I am working in an application for gathering information from customers. Basically it's a bunch of questions, each one a field and each new answered questionnaire is a page with template "questionnaire". 90% of the questions are yes/no (using SelectOptions field) and all must  have an optional comments field.

Since I don't want to add a comments field for every question I have, would it be possible to "mass add" this extra comments field through a hook? Or is making a new fieldtype/inputfield the way to go here? If the latter, would anyone point me to an existing example if there is one?

[Jonathan Lahijani 787]

Are they filling out this form on the frontend of your site or through some sort of protected backend?

If frontend, are you building the form using FormBuilder, the PW Form API, or custom?

How many questions are there?  If it's like 10-50, that means another 10-50 extra fields for the "Comments" fields related to the question field as you stated.  Why not just make those individual fields in ProcessWire (assuming I understand your question correctly)?

[elabx 496]

Just now, Jonathan Lahijani said:

Are they filling out this form on the frontend of your site or through some sort of protected backend?

If frontend, are you building the form using FormBuilder, the PW Form API, or custom?

How many questions are there?  If it's like 10-50, that means another 10-50 extra fields for the "Comments" fields related to the question field as you stated.  Why not just make those individual fields in ProcessWire (assuming I understand your question correctly)?

You understood correctly.

Users will fill them as normal pages in the backend, this is a kind of private portal. I want to leverage ListerPro and it's export to CSV capabilities, basically this extra functionality is what discarded FormBuilder. 

It's around 50-60 fields per questionnaire, could scale to more.

Doing the 50 extra fields felt like non-optimal solution, so instead of having extra 50 tables why not just an extra column in a custom Inputfield maybe, with a nice text input hidden and revealed with it's own javascript logic and i think it would be easier to add/remove question  in case I want to change the questionnaire.

But maybe I am overthinking it, since I am not very experienced into making Fieldtype/Inputfield modules. What I imagine is a combined Options field with just an extra input that can get toggled to be shown only if necessary.

[Jonathan Lahijani 787]

Yea, it's going to create a lot of database tables.  I don't see how any Profields would help in this scenario either.  I suppose a custom field would be optimal, although I've never had to create one in my 4+ years with PW.  But optimal might be a relative word... 100 questions might still be manageable?

Also, one thing to be careful about is if you remove a question (as in remove the field from the template), it will delete any saved data associated with it, which you may need to keep.  Maybe hiding it (but still keeping it assigned to the template) would be an alternative approach to preserve data.

 

[adrian 10,623]

Why not do each question as a child page. And each answer as a grandchild. I have done this before and it works really well - it's infinitely scalable!

Questions
---Question 1
-------Answer 1
-------Answer 2
-------Answer 3
---Question 2
-------Answer 1

 

The question template would have just a title field.

The answer template would have these fields:
answer (select options): yes / no
body (textarea): comments or even a real comments field type if you want, although probably not appropriate in the backend

[elabx 496]

13 hours ago, Jonathan Lahijani said:

Yea, it's going to create a lot of database tables.  I don't see how any Profields would help in this scenario either.  I suppose a custom field would be optimal, although I've never had to create one in my 4+ years with PW.  But optimal might be a relative word... 100 questions might still be manageable?

Also, one thing to be careful about is if you remove a question (as in remove the field from the template), it will delete any saved data associated with it, which you may need to keep.  Maybe hiding it (but still keeping it assigned to the template) would be an alternative approach to preserve data.

 

I do agree it could be manageable. From the business perspective, questionaires won't change often. And yes and pretty aware of the removing fields/data problem. Thanks for your thoughts!

11 hours ago, adrian said:

Why not do each question as a child page. And each answer as a grandchild. I have done this before and it works really well - it's infinitely scalable!

Questions
---Question 1
-------Answer 1
-------Answer 2
-------Answer 3
---Question 2
-------Answer 1

 

The question template would have just a title field.

The answer template would have these fields:
answer (select options): yes / no
body (textarea): comments or even a real comments field type if you want, although probably not appropriate in the backend

Really dig this approach, though how would you handle the saving of the data and then displaying it on a ListerPro?  Think this is the part where this soultion could fail me.

[adrian 10,623]

2 hours ago, elabx said:

Really dig this approach, though how would you handle the saving of the data and then displaying it on a ListerPro?  Think this is the part where this soultion could fail me.

Actually I think it could actually work really well. 

The predefined filters would be: template=answer - that would get you limited to all the answers. Now you just need to limit to the parent with the question they are interested in.

You could add another ready filter for parent.name which they could use to enter the name of the question. The catch of course is that it's not friendly for the user, so what I think I would do is create a simple Process Module (or even an AdminAction) that lists all the questions and links to the Lister view that shows all the answers for the selected question. There are other ways to make links to Listers, but this module (https://modules.processwire.com/modules/process-page-lister-urls/) might make this really easy (I haven't tested it). Another option would be to add a custom page list action button (like edit, view, etc) that links to a lister view of all the answers for the clicked question.

This won't help you right now, but I think I nice addition to Lister Pro would be to define a selector for providing a list of child pages to choose from, rather than having to manually type a name/title/id, etc

 

[elabx 496]

From what I understand, your proposal focuses on the answers, rather than the WHOLE questionnaire, I would have imagined a ListerPro where the rows are a set of answers corresponding to the questionnaire.

But you got me thinking, what if I related answers with a single page.

Questions

---Responses

--------Response 1 <- This has a page field which has a relation to an answer per child question., eg. (has=question1_answer1,question2_answer1)
---Question 1
-------Answer 1
-------Answer 2
-------Answer 3
---Question 2
-------Answer 1
-------Answer 2

[adrian 10,623]

5 hours ago, elabx said:

I would have imagined a ListerPro where the rows are a set of answers corresponding to the questionnaire.

It's late and I must be tired, because I think that is what my proposal will give you. I suppose it is the answers to a single question, rather than an entire questionnaire - maybe that is the difference you are referring to? But surely you need to look at one question at a time?

I don't really understand how the response page reference field will help, but maybe I am just not getting it?

Of course the other option is to build your own Process Module interface (instead of Lister Pro) which shows exactly what you want - still pulling questionnaires, questions and their answers from the page structure I suggested. This would be the most flexible option. This is where you could make use of a page reference field to choose a questionnaire - pass the selected option to the rendering of the questions and their results. Should be quite easy to set up and completely flexible - I think that is what I would do. If they are mostly yes/no answers you could even build a graph inline showing to visualize results.

 

[elabx 496]

7 hours ago, adrian said:

It's late and I must be tired, because I think that is what my proposal will give you. I suppose it is the answers to a single question, rather than an entire questionnaire - maybe that is the difference you are referring to? But surely you need to look at one question at a time?

I don't really understand how the response page reference field will help, but maybe I am just not getting it?

Of course the other option is to build your own Process Module interface (instead of Lister Pro) which shows exactly what you want - still pulling questionnaires, questions and their answers from the page structure I suggested. This would be the most flexible option. This is where you could make use of a page reference field to choose a questionnaire - pass the selected option to the rendering of the questions and their results. Should be quite easy to set up and completely flexible - I think that is what I would do. If they are mostly yes/no answers you could even build a graph inline showing to visualize results.

 

Haha, I think I am too. And MAYBE my understanding of the word questionnaire is messing with my life right now (maybe the phrase, submissions of the questionnaire was missing) . I decided to make a quick processwire sketch of original Plan A:

The way submissions look in the tree:

The questionnaire template:

The ListerPro of questionnaire submissions:

What I like from plan A is is that the problem is solved all the way, from representing the questionnaire, to the Lister/Export functionality. The thing is that i don't feel it's very end user friendly and the data deletion problem.

Hope there was a way to set "field templates" and work with them kind of in a way you work with parent/children template rules in the page tree.

Then again, I could do my own Process module I could base on the process module that enables this screen in a much simpler way.

Quote

I don't really understand how the response page reference field will help, but maybe I am just not getting it?

I kind of didn't understand how to relate answers among themselves since they exist under their corresponding question. For example, I need to relate Answer 1 of ALL questions, they are the answers to a single questionnaire submission.

Thanks a lot for your patience!

[adrian 10,623]

The problem I see with your approach is that you need a new field for each question - I actually did this on my first ever PW site - it works, but it's a lot of fields to maintain and requires a dev to add new questions. If you make each question a page, then anyone can add new questions.

I would also be worried about that lister view - won't there be a lot of horizontal scrolling if there are lots of questions?

[elabx 496]

21 hours ago, adrian said:

The problem I see with your approach is that you need a new field for each question - I actually did this on my first ever PW site - it works, but it's a lot of fields to maintain and requires a dev to add new questions. If you make each question a page, then anyone can add new questions.

I would also be worried about that lister view - won't there be a lot of horizontal scrolling if there are lots of questions?

I see the problem too and fully agree on you observations.

I think I will follow your advice on the questions. I will make my own custom lister. The big horizontal scrolling doesn't worry me as much, the main features I want to take from the listers are the filtering , the CSV export and the "bird eye" view it gives, so those features I think I can handle in a Process module to keep the data structure maintainable which is what in the end worried me the most haha

Thanks again for the help!