Square Sequence Recall

SuperLab SuperLab 4 Support
1

We have divided our screen into 16 squares (by xy dimensions). On a given trial, 5 boxes light up and disappear, one by one. It is the subject’s job to use the mouse to press the boxes on the screen that match both the POSITION (that is which box in the grid) and the ORDER (that is the precise sequence that each of the boxes lit up) from the previous trial. We’ve managed to program position, but we cannot figure out a way to program order. The subjects are free to click boxes and even clear the entire screen to start over if they feel a mistake was made. In addition, the subject may click a button that says “BLANK", which allows the subject to skip a box in the sequence that cannot be remembered, without compromising the recalled order of later boxes in the sequence. When a subject clicks inside a box, the box turns red and a number appears inside the box. This number corresponds to the order in which the box was clicked (Ex. The first box clicked will turn red and contain a 1, the second box clicked will turn red and contain a 2, etc.). When the “BLANK” button is pressed, the next number in the order is skipped (Ex. The first box clicked will turn red and contain a 1, the “BLANK” button is pressed indicating a skipped location/position, then, the next box pressed by the participant will turn red and contain a 3, for it represents the third box presented in the original sequence).

This interactivity with the matrix serves as a means for the subject to keep track of the position and order of the boxes he/she has previously clicked and for researchers to record all mouse clicks by the subject, with each click being recorded for correct/incorrect order. Because the subject can freely click any quantity of boxes in any order, we need to capture every possible box click that can be made the subject; that is, with 16 total squares, each box should have to potential to light up and present any number 1-16 according to the order in which it was clicked, regardless of whether it was a correct or incorrect answer according to position and order.

To reiterate, the subject also needs to be able to insert a blank placeholder to allow he/she to continue recalling box locations further into the sequence when he/she cannot recall a single box position. How can this interactivity be programmed using Superlab 4.0? Keep in mind that we also need to be able to record and view the data corresponding with both correct and incorrect responses for the position and order of boxes clicked in relation to the original trial.

Automated Symmetry Task-Square Recall Example.png

2

Hi, EWright. Welcome to the forums!

My first concern is to clarify whether or not you have posted under “SuperLab 4” instead of “SuperLab 5” by mistake.

SuperLab 4 cannot handle the amount of interactivity that you described.

The newer SuperLab 5, however, can handle this. If you purchased SuperLab on or after March 2013, then you have a free upgrade.

I am attaching an “sl5” experiment that demonstrates a subset of the features that you need.

To run the demo “t_2030_simple_demo.sl5”, you can download the 30-day trial of SuperLab 5 here: http://cedrus.com/superlab/download/

If you are unable to install the 30-day trial at this moment, then here is a screencast showing the running experiment in action:

http://screencast.com/t/uS8pxmsU

The key to maximizing interactivity in SuperLab 5 are the new features named:

  • Rules
  • Parameters

Below you can see a screenshot of a Trial Rule.

In order to fulfill the rest of the requirements you listed, we would simply add more rules to the experiment.

If you are willing to accept keyboard input in your experiment instead of mouse clicks, then it is even easier to design a memory task in SuperLab. To see why accepting keyboard strings simplifies the design, refer to the second attached experiment, “rudimentary_simon_says_demo.zip”. It is based on the classic toy/game “Simon,” explained here: http://en.wikipedia.org/wiki/Simon_(game)

t_2030_simple_demo.sl5 (8.32 KB)

rudimentary_simon_says_demo.zip (207 KB)

3

Thank you for your response,

I have indeed been programming with SuperLab 4.5. I do not, at the moment, have authorization to open the SuperLab 5 experimental package that you have attached; however, I will review your attachments as soon as possible, consult with my advisors, and reply with any additional questions that may arise.

We sincerely appreciate your help on the matter,

Emily

4

Good evening!

I have reviewed your experimental packages and thank you immensely for your help with this issue. I do have a few additional questions and clarifications, however.

To reiterate my current issue, I am attempting to determine how we can program the recall screen to allow each square in the matrix to turn red and present its order number when a series of squares are clicked as a recall measure. However, upon reviewing the experimental packages you created for our guidance and comparing them to the task at hand, I am unsure how to translate these methods for our task, for there is a disconnect between the ability to use rules and parameters to change font color when a number is clicked and my ability to present color in a square determined through pixel size in the response creator page (The difference being that Superlab can change font color when text is clicked while it does not seem to be able to change the color of a determined location on the screen when it is clicked).

I have attached my own experimental package (although it’s a bit messy from my playing around with new features), in case I have confused you as to how this task ought to work. The experimental packages you created for us were immensely helpful in introducing the new rules and parameters features. I am just wondering if it will be possible for each square clicked in the recall screen to turn red and present its corresponding order number within the program, or if it will be necessary for me to create separate images outside of Superlab displaying each possible 16-square recall order and upload them separately as feedback in order to maximize the level of interactivity required, since mouse-clicks rather than key responses is required for this task.

Thank you for your help and please let me know if you require any additional information regarding this task and my inquiry.

Best Regards,

Emily

AutoSymTask5.sl5 (52.3 KB)

5

Sorry, I realized I attached the file, not the full experimental package.

AutoSymTask.zip (797 KB)

6

Hi Emily,

Your experiment package was very helpful. Thank you for posting that.

The earlier demo experiments that I uploaded were indeed a simplified, “under-designed” illustration of something roughly similar to your needs.

I am glad that you are now using SuperLab 5 and are ready for further tips!

There are two issues to be solved:

[LIST=1]

  • changing the color of a square
  • presenting a dynamic sequence number in a clicked square [/LIST]

    I am attaching a new demo today. My latest demo (t_2030_demo_4x4.zip) shows one method for presenting the sequence number inside the clicked square.

    Changing the color of a square is still going to be tricky. You are correct that there is no direct way to set an action to “colorize a clicked area” or to set a pixel location for a dynamic color-change later on.

    On the other hand, I recommend against creating separate images outside of SuperLab. That would be infeasible, because there are thousands of ways for a participant to fill in the 16 boxes one-at-a-time. (For example, by my count, even if you only made grids
    showing different arrangements where 3 boxes are red, there are 560 different grid configurations with 3 out of the 16 boxes colored red.)

    I do have an alternative idea regarding how we could color the squares.

    However, I recommend that you look over this new demo first. Perhaps you will find that this new demo is actually quite adequate. Or, maybe this demo will reveal other design challenges that take priority over the coloring issue.

    There is a lot of logic that needs to be managed with this 4x4 clickable grid. This new experiment uses:

    • 4 Block Rules (in the Block Editor)
    • 22 Trial Rules
    • 16 Mouse Responses
    • 3 Keyboard Responses [B](See note below)[/B]
    • 16 Position Trial Levels
    • 2 Stimulus Lists
    • 20 Counter Parameters

    (Note: This current demo uses clickable squares, but it still uses keyboard keys for one portion. To convert this into a mouse-only experiment, you need to define 3 more clickable areas, and then edit the trial rules that check for the “clear/blank/exit” responses.)

    Anyone attempting to edit this experiment will almost certainly break some of the logic unless he or she studies the entirety of the design before making changes.

    The first thing I recommend is that you just run this demo. That part should be fun and easy.

    Then, as you work through the design elements listed above (rules, responses, parameters), here are some preemptive answers to questions you might have:

    Q: Why is it true that this demo performs the view-and-recall-sixteen-boxes task exactly 4 times?
    A: There are important Block Rules on the block named “recall - interactive.” These rules cause two blocks (“present 16” and “recall - interactive”) to be repeated 4 times. These rules also use the parameter “total recall sessions desired”, which is set to 4. Go to the main menu, “Experiment” >> “Parameters…” and you can set “total recall sessions desired” to a value that is bigger or smaller, if you want to change the repetitions to something other than 4.

    Q: What is the weird-looking content inside the Text Stim List named “sequence parameters”?
    A: Each item in the list is a placeholder for a parameter value. All the parameter values begin at “0”, which is why you first see a grid filled with zeroes.

    Q: How does each number value in the Text Stim List named “sequence parameters” get displayed in a separate box of the grid?
    A: Open the Event Editor for the event “box labels”. Click “Settings >> Position.” The position is set to the trial levels “boxes, number positions”, which advance sequentially.

    Besides understanding the above facts, the most important thing to understand are the Trial Rules. Please look over them in the Trial Editor.

    Lastly, you might try editing some parts of the experiment to verify your understanding of the outcomes that are possible. You can always come back and download this copy from the forum if you mess anything up.

    Enjoy!

    t_2030_demo_4x4.zip (74.1 KB)

    • 7

    Unicode character U+25A0 for painting a square

    Here is a “hint” about one possible way to show red boxes dynamically for each click:

    If your computer has Unicode fonts installed, then you can make a “box” by using text instead of image files.

    The screenshot below shows a SuperLab Text Event that displays a “box” which is actually a letter in a Unicode font.

    I accomplished this by finding Unicode shapes online (such as here: http://en.wikipedia.org/wiki/Geometric_Shapes#Compact_chart ) and then copying-and-pasting the text into SuperLab.

    One way to hide and show a colored box, then, would be to use a Text Parameter in SuperLab. To hide the box, set the parameter to “” (an empty, blank text snippet). To show the box, set the parameter to “[box]” (a copied-and-pasted symbol of your choosing).

    Before you delve into Parameters any further, I highly recommend that you peruse the very friendly (short and sweet) SuperLab Manual: http://cedrus.com/superlab/manual

    8

    Words cannot express how much we appreciate all that you have done to help us with this matter. Your demo has been an overwhelming help and we could not have progressed without your service. I do have a few questions regarding the demo. I have extensively reviewed the material you provided and applied it to my own experiment. I have found that you were correct in stressing the sensitivity of the logic necessary for full interactivity to take place. I have implemented the same rules and parameters that were illustrated in the demo and have created the full matrix, complete with zeroes present in each box.

    My issue is, when I click on the boxes, the screen flickers, but I see no increase in the counters within the clicked box. I have checked all of my rules and parameters and don’t see any evidence that I have broken logic. The only obvious difference between mine and the demo is that I have converted the Blank, Exit, and Clear keys to on-screen button clicks; however, I do not suspect that this is the issue. My current clicks ought to increase the sequence of matrix incrementally, according to what I have computed so far, but they do not. I will attach what I have done for any additional reference, but do you have any ideas, in general, what might be the issue with the clicks? I initially suspected that there was something missing in my settings of “current click” or the “wait for click” trial and event, but I do not see any problems.

    Thank you again for your attention and aid!

    Emily

    SymmetrySpan.zip (813 KB)

    9

    Hi Emily,

    You did a very thorough job of transferring the logic into your own experiment. That required an expert eye for detail, and you conquered it. The remaining issue turns out to be a minor issue. I’m sorry that a minor annoyance cast a shadow on the wonderful work you did.

    The issue is with the mouse response named “Left Mouse Click.”

    The Short Answer:

    • Select "Left Mouse Click" in the Participant Input window, and then click "Move Down" 18 times, to place "Left Mouse Click" at the bottom of the list of responses.

    That’s the fix. :slight_smile:

    However, I am sure you are curious to know how I arrived at that fix. Therefore, I also offer an extended answer (below).

    The Long Answer:
    The approach that I followed in order to diagnose your experiment went as follows:

    (In short, you have to “reason backwards.”)

    Problem: The counter parameters are never increasing past 0.

    Question 1: What part of the experiment is in charge of increasing the counters?
    Answer: The rules attached to trial “Wait for Click.”

    Question 2: What is the expression in the trial rules that needs to be true in order to trigger a parameter change?
    Answer: The expression in the relevant trial rules takes the format:

    • "If last participant response is [B]Square #n[/B]"

    Hypothesis: Since the above expression never seems to be true, then perhaps the response is never “Square #n.”

    Question 3: When we expect the response to be “Square #n,” how can we know whether it got registered by SuperLab as the response “Square #n” or as some other response instead?
    Answer: We need to save the data and look in the datafile.

    Therefore, I ran the experiment (saving data), and I clicked on a few different squares, and then I clicked the buttons.

    The saved data (shown below) is an important clue. Note that the buttons (clear/blank/exit) show up correctly in the saved results. However, every time I thought I was clicking a “Square” area, the datafile shows the response named “Left Mouse Click” instead!

    (Screenshot taken using our free “Data Viewer” http://cedrus.com/superlab/dataviewer/ )

    At this point, we can at least confirm the stated hypothesis: the rule is not triggering any counter increase, due to the response never getting registered as Square #n.

    Final Question: Why doesn’t any click ever register as Square #n?

    To answer our final question, open the Participant Input window and look at the list of the 22 mouse responses that are defined. You should see a note in the Participant Input window that says: “SuperLab compares a response against this list in the order that the responses are listed.” (This note was added in version 5.0.3. If you have 5.0.2 or older, the note is absent.)

    Remember that every response except for “Left Mouse Click” is a small-rectangle response limited to a small subsection of the computer screen. “Left Mouse Click” is the lone exception. “Left Mouse Click” poses a problem because it is set to match clicks anywhere on the entire full-screen rectangle… and—catastrophically—this response appears on the list prior to the appearance of the Square #n responses.

    Summary Diagnosis:

    In other words, “Left Mouse Click” is like a wildcard that matches anything. Once a click is matched and labelled as “Left Mouse Click”, then SuperLab stops searching the response list. Therefore, no click will ever match anything that appears after “Left Mouse Click” in the list.

    Placing “Left Mouse Click” at the bottom of the list allows the “Square #n” responses to work as intended.

    10

    Good evening!

    That solution, as you showed, completely fixed my issue and I cannot thank you enough for the help you have given me to get through such a complicated portion of my task. I do have a small inquiry in follow up, however:

    In the examples we have worked through, all 16 squares are presented from the stimulus list at once. However, in the real task, the aim would be to present a randomized select number of squares from the larger stimulus list. It seems that Superlab only allows for the presentation of all 16 squares at once, rather than only presenting an initial 3 squares from the larger list. Considering that the task must be adaptive, I need to be able to present an initial select number of squares, then increase and decrease this presentation based on the performance of the participant. I noticed another current thread that has addressed this issue, but I have not found that that solution worked when applied to my task. Not to continue to ask a number of questions, but do you have any ideas for how I may be able to present a select number of squares from a larger list in random order? Thank you for your time.

    Emily

    11

    additional requirements for dynamic experiment behavior means additional rules :slight_smile:

    Hello! I am so glad to hear that the mouse-click fix was successful.

    Also, I am relieved to hear that you plan to start the experiment with a phase that shows only 3 squares. I was really struggling to memorize the random sequences of 16!

    With your latest question about limiting the sequence, we have come full circle. Back in October, I foreshadowed: “In order to fulfill the rest of the requirements you listed, we would simply add more rules to the experiment.”

    Time to add more rules!

    (Sidenote: Your experiment has an ambitious amount of logic involved. I hope you will find that the SuperLab 5 Manual is your ally.)

    Here is what you need now:

    [LIST=1]

  • Create a new counter parameter for tallying.
  • Create another new counter for "current maximum length."
  • The initial value of the tally is 0, the initial value for "current maximum length" can be something like 3.
  • Create a trial rule that is only used by the list-trial that displays the "matrixN.bmp" files. Call this rule something like "tally the images."
  • The rule for tallying simply increments the tally parameter by 1 each time, unconditionally.
  • Create a second rule that is also only used by the "matrixN.bmp" list-trial. This rule checks whether the tallying counter has exceeded the "current maximum length." If so, then exit this block. [/LIST]

    [SIZE=“2”]Here is what the second rule should look like:[/SIZE]

    If you make sure that “current maximum length” has an initial value of 3, and you follow the above-listed steps, then you will observe that the sequence is now a short random sequence each time.

    However, there is still the matter of when to increase “current maximum length” from 3 to 4, or to 5, 10, or anything else.

    It is up to you to choose what type of rule to create that takes charge of incrementing that length. It is up to you to determine the criteria for that rule.

    Because your experiment is fairly intricate, you might want to spend an hour building some throwaway practice experiments, simply to gain greater familiarity and dexterity with using Counter Parameters and Trial Rules. I recommend this (for practice), since your current experiment already contains over a dozen rules (mostly for managing the interactive number labels on the grid).

    As you venture further into the techniques of creating rules, I also recommend that you regularly enable the “save collected data” checkbox when doing test-runs of the experiment. This is helpful because all the counter parameters appear in the data, and (by perusing the data) you can get a better sense for how the counters change value over the course of the experiment.

    • 12

    Thank you for your help in making this task adaptive and select in the square presentation portion.

    I have one additional question that should be the last of the troubleshooting:

    Previously, I followed the demo with Square Recall Matrix logic we previously discussed and we worked through some fine-tuned adaptations. Now that we have secured the understanding of the logic, I have noticed one minor setback when constructing my blocks.

    The overall task should feature 12 Experimental Trials (3 trials each of 3, 4, 5, and 6 square presentations where one square is presented, then a symmetry image, then another square, etc. until the desired number of squares have been shown). When the square stimuli and background stimuli are shown, the recall page is presented and when a participant exits the recall page, it takes them to their feedback (which is currently being placeheld but will soon show feedback to the number of squares correctly recalled and the number of symmetry images correctly determined as well as, ideally, a running percentage of number of symmetry correct). My issue, however, is that once the participant clicks out of that feedback slide, he/she is taken directly back to the recall matrix, rather than progressing to the next sequence of stimuli.

    My question is as follows:

    -How may I adjust my rules to progress the participant to the next block of trials? Whenever I adjust my number of trials desired and/or flag of trials completed to reflect that the number of trials (1) is completed, it still takes me back to the recall page. Alternatively, it does not seem to be possible to force my feedback slide to move to the next block with the rules set in place.

    As always, thank you for your patience.

    Emily

    AutoSymTask5.zip (1.19 MB)

    13

    Hi Emily,

    Thank you for exercising such painstaking care in describing the goals of this experiment.

    By emphasizing your main current question, you made my work easier!

    I understand that the current question is strictly pertaining to making the experiment proceed through all blocks (and not get stuck in the recall matrix).

    Nonetheless, I can pinpoint at least four additional as-yet-unmet design goals based on your summary. They are:

    • (A) experimental trials that increase difficulty through: 3-series, 4-series, 5-series, 6-series levels of difficulty
    • (B) alternating between: one square, one symm-image, one square, one symm-image, etc
    • (C) dynamically computing how many squares are correctly recalled
    • (D) dynamically computing how many symmetry judgements were made correctly

    Item (A) will be solved whenever you choose and implement your strategy for incrementing “Current Maximum Length” (as discussed in my prior post).

    Item (B) should be a simple matter of linking a symm-image event to the trial named “Square Practice Presentation”.

    Caution: I must warn you that item © might be impossible. If it is possible, it will require you to create so many new parameters and rules that it takes up a great deal of your time and becomes very unwieldy to debug/proofread.

    Item (D), while similar to ©, is actually much simpler. The symmetry judgement is a YES/NO answer, whereas the recall response is a series. SuperLab records the participant’s response series in the datafile (such as: square-8, square-3, square-15), and you can therefore readily score the correctness when you analyze the completed datafile. However, there is no built-in “series of three” or “series of four” response type that you can use for on-the-fly feedback.

    You might remember (from back in October), I mentioned that “keyboard strings” are another option for memory experiments in SuperLab. (see this post: http://community.cedrus.com/showthread.php?p=6741#post6741 ) On that post, I uploaded the “rudimentary_simon_says_demo.zip” experiment package. The “Simon Says” demo indeed does successfully provide on-the-fly feedback about a “series of four” response. However, this is a “trick” that is facilitated by using keyboard strings for input. Your current experiment seems pretty solidly based on mouse input (which doesn’t provide the same “trick” as keyboard strings).

    Now back to the easy part!

    Here is a quick video walkthrough showing the two simple changes that are needed to avoid getting stuck in the recall matrix:

    http://screencast.com/t/VVqWoyx8zf

    It all boils down to the rule “Recall Sessions Are Done”. That rule has the job of deciding when we quit repeating the recall matrix. The condition it tests is whether “Total Recall Sessions Desired” have been fulfilled. For you, it sounds like you need to set “Total Recall Sessions Desired” to 12. For the sake of the short video screencast, i set it to 3. The action triggered by this rule needs to force us into a later block. The rough-draft version of this rule only presents an event, which is not sufficient to cause a definitive exit from the block. You can see in the screencast that I deleted that old action and used a new action to jump ahead to block “Symmetry Practice”.

    If the edits that I demonstrate in the screencast still are not quite what you had in mind, then feel free to adapt as needed.

    14

    Greetings,

    We are so close to concluding the programming to this task; however, there are a couple issues regarding our trial construction that my colleagues and I cannot seem to figure out.

    Previously, I misunderstood the adaptivity of the task. I believed that the task was adaptive based on subject performance; however, I reviewed the literature and found that the task is naturally adaptive by constructing a series of trials that are progressively hard. Beyond the practice, participants must complete 12 trials total (3 of 3 squares, 3 of 4 squares, 3 of 5 squares, and 3 of 6 squares to recall) that follow the single square-symmetry-single square pattern with the recall measure at the end).

    Attached is the experimental package for the task. Currently, there are two major issues that must be addressed for successful construction of the trials:

    1. The most obvious is the unintended looping at the end of the “Both Practice” Recall Matrix. Upon the completion of the recall, it should continue to simple feedback, then the practice conclusion instructions before the real trials; however, it seems to revert back to the “Symmetry Practice” portion of the task, which follows the first Recall Matrix from which the Both Practice Matrix was initially copied. I have changed the order, so that it should move sequentially, but I’m wondering if, by copying earlier blocks/trials/events, Superlab is confusing it with the earlier Matrix order; however, I am uncertain that this is simply the issue, if you consider the following point #2.

    2. The “Both Practice” Recall Matrix has been copied verbatim from the previous recall matrix, as far as the logic is consider (excluding areas in which it would cause the very same loop that is somehow present); however, it is currently non-interactive, which it does affect the overall flow of the experiment may also contribute to the looping of the trials that follow.

    As always, we appreciate your help. These trials are tricky due to the complexity and interwoven nature of the stimuli preceding the recall matrix, so we are desperate for a place to start.

    Thank you immensely,

    Emily

    AutoSymTaskPackage.zip (1.2 MB)

    15

    There might be more problems than what I am about to describe, but this is what I have been able to determine so far.

    The block “Square Practice Recall” uses four rules.

    The block “Both Practice Recall” happens to use those exact same four rules.

    This is bound to cause trouble, because two of those rules contain actions that specify proceeding to a specific block. The rules direct the experiment to go to block “Feedback” in some circumstances (“Feedback” with no suffix, as opposed to other copied-and-numbered blocks that start with that same word). The other rule directs the experiment to go to “Square Practice Presentation”.

    Again, remember that you currently have your “Both Practice” block using this rule – a rule that directs the experiment to go to “Square Practice Presentation.” I do not think you ever intend to proceed from the “Both” section back to the “Square Practice” section. If you do not intend that, then you need to unlink the “Both” block from these rules. (Then you probably need to devise appropriate rules for that block.)

    When you copy and paste a block, you also copy its “links” to which rules the block will trigger. Note that these are “links” to rules – rules themselves are never copied.

    Likewise, when you copy a trial, you copy “links” for what trial rules will be triggered by the trial.

    Let me know if that is enough information to get you back on track, or whether you would like me to take another look next week (and perhaps take a look at a newer attachment you might have by then).

    16

    Thank you for your fast reply, as always. Your guidance was very helpful in getting me back on track. In the experimental package I have attached, you can see that the first 6 trials have been created. There are two noticeable issues that must be ironed out in order to finally complete the task, as creating the trials themselves have been more or less a breeze so far (although some amendments may need to be made in order to fix the issues I am about to describe).

    1. The feedback screen “Thank you for your participation” seems to play twice following the Recall Matrix (the “Both” Practice Trial seems to be the best trial to display this error). This seems to be due it playing once through our established Recall Block Rules, and again as the Feedback Block plays following the Wait for Click Trial; however, if I were to remove the rule and have only the Feedback Block play sequentially after the Wait for Click portion, the task does not progress to the next trial. Is there a way around this issue?

    2. When I copied the Trials pertaining to the Recall matrix (Recall Matrix, Labels, Wait for Click, etc., I have seen that despite the identical logic from the practice matrix from which is was copied, the matrix in Both and Trial 1-6 skip forward to the feedback screen upon initial click into the matrix; however, when playing the block by itself, the matrix is fully interactive as intended and progresses forward as anticipated. Is this due to the position of the Rules Reset Trial? I am unsure of what could be causing this issue outside of the Recall Block, which seems to work perfectly, indicating that it is not an issue of the matrix’s rules of the trials within the selected block.

    As always, thank you for your continued patience and support.

    Emily

    Automated Symmetry Span.zip (1.2 MB)

    17

    Here is the updated experimental package for the task, with all trials completed and more descriptive item titles. I hope the added detail helps.

    AutoSymTask-CompleteTrials.zip (1.21 MB)

    18

    Sorry to keep you waiting. Both (1) and (2) turn out to have relatively simple answers – or rather, answers that are easy to explain, at least. So that’s good!

    (1) It seems like in your latest copy of the experiment, somebody already figured out how to prevent the “Thank you” slide from appearing twice in a row. In an older copy of the experiment, the problem was that a Trial Rule (in the Trial Editor) named “If All Completed” contained two actions, and one of the actions was to present “Thank you.” I would have recommended simply deleting that action (but keeping the rest of the rule as-is). However, it seems like in the latest copy, somebody did that! Which is great. Congratulations on solving that.

    (2) Here is the reason why the recall matrix wants to “give up” right away (in all but the first appearance of the matrix): it “gives up” because nothing is ever setting the parameter “Count Recall Session” back to zero. Making sure this counter goes back to zero just prior to each new recall session will fix the problem. Why? Answer: because all the block rules with names like “Recall Sessions Are Done…” are examining that counter, treating it like a flag to signal an exit from the recall matrix. Thankfully, there is a very easy one-step fix for this. In the trial editor, go to the rule named “Reset Parameter (Part 2)” and add a new action to the list of actions. The new action is “Reset: Count Recall Session”.

    There is a general technique that I find helpful for problems like (2). Save the data when you run the experiment, and then examine the columns in the datafile that track the parameters. If you notice that a parameter “gets stuck”, then that might tell you where to begin investigating. In the present example, when I looked at the data column for “Count Recall Session”, I noticed that it went from 0 to 1 just as the practice matrix block ended, and then the value stayed stuck at 1 from that point onward.

    (Of course, not all “stuck” values will be wrong. Sometimes you can have an experiment that is designed to stop manipulating a counter at some known point in the experiment.)

    Also, once you notice something is “stuck”, you have to consider your particular experiment to know whether resetting the counter to 0 is the proper fix, or whether we perhaps need to “unstick” the value by incrementing it even higher and keep it counting upwards.

    Hopefully learning to read the parameter columns in the output can lead to insights for many future experiments.