Allow the option to navigate to the same state as a new 'card' about oppia HOT 14 CLOSED

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?

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.

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.

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.

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').

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).

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]".

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.

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)

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.

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.