Making Answers objects?

0 views
Skip to first unread message

Deichi

unread,
Nov 25, 2008, 4:28:08 AM11/25/08
to PloneSurvey
Hello,

I recently altered PloneSurvey for kind of a "wizard" that leads users
of the "survey" to a certain "page" dependant on what he selected as
his answers.
( see also http://groups.google.co.uk/group/cmfquestions/msg/4655d57a1fd5b1b6
)
I used PloneSurvey for that, because we need statistics about what
answers were chosen during the use of that wizard. And there's a
question on how useful that wizard was if it led to a success (yes, I
know... that only selects the people that were successful as base for
the statistics ;) )

What I found a bit difficult to implement at first was the fact that
the branching works "the other way round"(tm)
So you don't select what question was next regarding to the answer,
but you select the question that you want to be dependant on in the
next question and enter the answer you want to be entered in the
question before.
I see the advantage in that too (for example that you won't need to
enter all the questions that follow first or return later), but the
flexibility (yes... and the complexity while entering them...) would
be higher if answers were their own types that have their own "goto"
links
I am not sure if one should make 2 Products of both ways... or just 2
types...

Please throw in some thoughts.

Regards,
Sven Deichmann

Yuri

unread,
Nov 25, 2008, 9:28:23 AM11/25/08
to PloneSurvey


On 25 Nov, 10:28, Deichi <deichm...@werkbank.com> wrote:
> Hello,
>
> I recently altered PloneSurvey for kind of a "wizard" that leads users
> of the "survey" to a certain "page" dependant on what he selected as
> his answers.
> ( see alsohttp://groups.google.co.uk/group/cmfquestions/msg/4655d57a1fd5b1b6
> )
> I used PloneSurvey for that, because we need statistics about what
> answers were chosen during the use of that wizard. And there's a
> question on how useful that wizard was if it led to a success (yes, I
> know... that only selects the people that were successful as base for
> the statistics ;) )
>
> What I found a bit difficult to implement at first was the fact that
> the branching works "the other way round"(tm)
> So you don't select what question was next regarding to the answer,
> but you select the question that you want to be dependant on in the
> next question and enter the answer you want to be entered in the
> question before.
> I see the advantage in that too (for example that you won't need to
> enter all the questions that follow first or return later), but the
> flexibility (yes... and the complexity while entering them...) would
> be higher if answers were their own types that have their own "goto"
> links
> I am not sure if one should make 2 Products of both ways... or just 2
> types...
>
> Please throw in some thoughts.

You can change the branching behaviour in the getNext function.

About "the two ways", the flexibility is the same, I think.

Deichi

unread,
Nov 27, 2008, 3:57:47 AM11/27/08
to PloneSurvey
No, it actually is not. Especially if you have "routes" that split and
resync later.
It works the way I changed it, but the user interface is very
inconvenient.

One example from my current work:
Q1) a) -> Q2 b)-> Q2 c)-> Q2 d)-> Q3 e)->exit page
Q2) yes -> Q4, no ->exit page
Q3) yes -> Q2, no ->exit page
Q4) yes -> Q5, no ->exit page

It is possible with my modifications to make Q4 depend on Q2)a),b),c)
and Q3)yes, but it is not nice

Yuri

unread,
Nov 27, 2008, 6:40:35 AM11/27/08
to PloneSurvey


On 27 Nov, 09:57, Deichi <deichm...@werkbank.com> wrote:
> No, it actually is not. Especially if you have "routes" that split and
> resync later.

I also do this. You've to change getNext to be mode flexible, not
checking if the next subsurvey has that question. That permits me to
do subsurvey that rejoin, so we can have workflows "only forward". I
think your checks makes you jump everywhere, so your seems more
flexible.

Deichi

unread,
Dec 4, 2008, 3:39:00 AM12/4/08
to PloneSurvey
Well you could probably even make it go back and try again... thats
very flexible, but probably unwanted ;)
Reply all
Reply to author
Forward
0 new messages