There should be an option to re-evaluate (and re-display) a state when you loop back from the same state

[GoogleCodeExporter]

Right now, looping back to the same state is treated differently than state 
transitions to different states: the state text does not get re-displayed, and 
the param changes do not get re-evaluated. This makes sense in most 
applications so far, since most of the time a looping back represents a lack of 
progress, but sometimes the looping back is actually meant to represent a 
"true" transition from a state to itself.
For example:
suppose I'm making a binary search game, where the exploration tries to guess 
what number you are thinking of. The central state in this exploration* updates 
the min and max of the range of possibilities, then picks the number in the 
middle of that range, and guesses it. The player then says if his number is 
smaller or bigger than the guess, and the state loops back. In this loop back, 
I do indeed want to update the max, min, and guess, and re-display the text 
(i.e. make another guess)

I think there should be a check box that allows the loop-back to act as a 
"true" state transition.

*this is actually a bit of a simplification: I had to copy this state into 
three, because I can't do parameter changes in state tranistions, so I had to 
have additional "last guess is smaller" and "last guess is bigger" states.
But I still have to loop back in roughly half the cases.

Original issue reported on code.google.com by yana...@google.com on 8 Aug 2013 at 8:47

[GoogleCodeExporter]

Follow-up question: do you think it would also be a common need to have the 
displayed text be different in the two cases of (a) first-time visit to that 
state, and (b) subsequent visits to that state?

Original comment by s...@google.com on 8 Aug 2013 at 10:10

[GoogleCodeExporter]

I think that could also be useful in many cases, although it can be more easily 
faked by having (1) "duplicate" states that represent the first time/other 
times and act slightly differently, and/or (2) feedback text that comes out on 
the *transition* to that state - Typically, the first time you get to the state 
is through a completely different path than the subsequent times.

I was also briefly thinking that it might be useful to have some of the choices 
in a multiple choice widget only show up *after* the first time, or to only 
enable certain classifications the second time around (although this will be 
possible as-is once we have the ANDs and ORs in rules stuff)

Also, for both of those things, we could potentially have the decision be based 
on a custom parameter, instead of just whether this is the first time the state 
is entered. For example, "only offer this choice if Knows_Concept_A is true"

There are probably quite a few things we can do to minimize duplicate/similar 
states, but I think it's possible to go to far here and offer too much 
customization of a single state, at which point it could be confusing to the 
content creators, *and* make the exploration flow less obvious from just 
looking at the graph. But the alternate text thing is probably quite useful.

Original comment by yana...@google.com on 9 Aug 2013 at 6:47

[GoogleCodeExporter]

Re a bit to allow loop-back to act as a true state transition, widget's 
'sticky' field does something similar so we should integrate them together. The 
sticky bit currently works as:
- Only for the widget (not for the messages or param eval).
- Defaults to reload (i.e. treats loopback as real state transition).
- State transition to another state with the same widget is treated similarly 
to loopback.
The last one might be a problem if we try to consolidate these booleans tho.

Original comment by kash...@google.com on 9 Aug 2013 at 7:15

[GoogleCodeExporter]

yeah, I think because of that last one (and the different defaults, possibly, 
if there's a reason for that) they should stay as two separate 
booleans/checkboxes.
I think it's quite valuable to have a sticky widget throughout a series of 
states.

Original comment by yana...@google.com on 9 Aug 2013 at 7:18

[GoogleCodeExporter]

I agree it's valuable to have a sticky widget persist throughout multiple 
states, so I also think the two bits are somewhat different.

We should be careful to pick something flexible and conceptually sensible here, 
in order to avoid schema changes down the road. I see two possible designs; it 
feels to me that (1) is probably more intuitive, but I'd appreciate additional 
opinions on this.

(1) Add a checkbox alongside 'Non-Interactive Content' that says something like 
"Show this text every time the user loops back to this state". Its default 
state is off.

(2) Break the non-interactive content bit into two:
    - Text that is shown on first entry
    - Text that is shown on every entry

-------------------------

Incidentally, the loopback behaviour is currently fairly localized in terms of 
the code. It is hardcoded in the reader controller:

   https://code.google.com/p/oppia/source/browse/core/controllers/reader.py

(search for 'state_has_changed').

Original comment by s...@seanlip.org on 11 Aug 2013 at 8:40

[GoogleCodeExporter]

One more possibly tangential idea -- we can also mark the out link instead of 
the state for re-evaluation.
I.e. have a checkbox on a rule. The checkbox should be enabled only for self 
loop rules.
We can then have multiple self-loop rules some of which can be soft-transition 
(the current default behavior) and others hard-transition (do everything 
non-self loop transition does).

Original comment by kash...@google.com on 12 Aug 2013 at 4:36

[GoogleCodeExporter]

Sean, I think either one makes sense, and (1) is simpler for the content 
creator.

Koji, I was just thinking the same thing - it would actually probably make a 
lot more sense to tie that choice to the transition instead of the state. In 
fact, in the dropdown where you choose where to transition to, we could just 
add the option of "[this state name](reevaluate)" to go along with the existing 
[this state name][loopback symbol]".

Original comment by yana...@google.com on 12 Aug 2013 at 6:23

[GoogleCodeExporter]

After discussion with the Yana, Koji and Stephanie we're going with the 
following:

- Parameter changes will always happen (this is something that Yana will fix).
- Figuring out what to do with regard to displaying the original content can 
happen later, since it's easy enough to scroll up a bit to see what the 
original prompt was, so we'll punt on it for now. If we do decide to do it, 
then the suggestion in Koji's comment #6 seems to be the best one, because it 
makes sense to put that decision in the place where it's actually being made, 
and it is more flexible.

Original comment by s...@google.com on 16 Aug 2013 at 6:26

[GoogleCodeExporter]

So, loopbacks are hard.
Turns out that:
1) parameter changes already get recalculated anyway
2) for my particular case at the moment - the *exploration* trying to guess the 
*reader's* number - I do need the "is it {{guess}}?" text to be displayed as 
the state text, not the feedback text, because of the timing: it needs to be in 
between the parameter recalculation and the player answering the question.

I found a somewhat hacky workaround for now so I'm not blocked at the moment, 
but the exploration would probably be a little prettier with this feature 
(among others)

Original comment by yana...@google.com on 18 Aug 2013 at 1:38

[GoogleCodeExporter]

Question of clarification: when you say "the exploration would probably be a 
little prettier with this feature", exactly which feature do you mean? I'm 
asking because I thought the feature we were going to add here was "ensure that 
parameter changes get recalculated each time", but it seems like that is what 
already happens.

Original comment by s...@seanlip.org on 18 Aug 2013 at 7:28

• Changed title: There should be an option to re-evaluate (and re-display) a state when you loop back from the same state

[GoogleCodeExporter]

Right, it works as-is with the already existing "always do parameter changes" 
feature. It would be prettier and less hacky with the "re-display state option" 
feature.

Original comment by yana...@google.com on 18 Aug 2013 at 8:54

[GoogleCodeExporter]

Original comment by s...@seanlip.org on 26 Apr 2015 at 2:19

• Added labels: Priority-Medium
• Removed labels: Priority-High