Logic and Personalization

Events, Actions, and Conditions

12 min readUpdated

Make lessons respond to learner behavior with triggers, logic, feedback, and branching.

This is where Berdee becomes interactive in a meaningful way.

New to behaviors? Start with the guided behaviors flow — select a widget, press ⚡ Behaviors, and build your first "When… then…" from ready-made ideas. This page explains the full system underneath it.

An easy way to think about the system is:

  • An event is what happened
  • An action is what Berdee should do next
  • A condition decides whether that action should happen

Events: what can trigger behavior

Different widgets can react to different moments, including:

  • When a learner hovers
  • When a learner presses or taps
  • When a scorable widget becomes correct (the On Correct event)
  • When all correct choices are selected
  • When a wrong choice is made
  • When a draggable item is dropped in the right place
  • When a timer completes
  • When a rain game ends or receives a correct or incorrect click
  • When a word search finds a word, or finds every word
  • When a learner counts an object in a counting collection (On Object Counted), or answers how many (On Answer)
  • When a learner places, flips, moves or removes a counter in a ten frame (On Counters Change)
  • When a learner raises or lowers a finger on a fingers widget (On Fingers Change), or taps its Done button (On Done)
  • When a learner places, moves or removes cubes in connecting cubes (On Cubes Change), or taps Done or answers a Compare question (On Done)
  • When a learner adds, moves, turns or removes a block in pattern blocks (On Blocks Change), or taps Done in Get and build (On Done)
  • When a quick look card is covered (On Card Covered), or a learner answers how many they saw (On Answer)
  • When a learner closes a shape on dot paper (On Shape Closed), or taps Done (On Done)
  • When a learner cuts or shades an equal shares shape (On Cut, On Shade), or taps Done, Yes or No (On Done)
  • When a learner traces a stroke of a number tracing numeral (On Stroke Done), finishes tracing it (On Traced), or taps Done on their writing (On Written)
  • When a learner fills or changes a box in a number sentence (On Box Change), or the sentence is checked (On Check)
  • When a learner finds a region in a find in picture widget (On Found), taps a "Not this one" region (On Wrong Tap), finds every region (On All Found), or, when it's checked at Done, taps Done (On Done)
  • When a spin wheel lands on a particular segment (configured per segment, not per widget)

Not every widget uses every trigger. The important question is whether the trigger supports the learning moment.

On Press and On Hover

On Press and On Hover work on every widget a learner can point at — buttons and images, but also questions, games and media players. A press is a click or tap anywhere on the widget, or pressing Enter or Space on it with the keyboard. The widget still does its own job first, then your behavior runs: tapping a multiple choice option picks that answer, then On Press runs.

_Example: On a multiple choice question, add a Play Sound to On Press so every tap on an answer makes a gentle click._

On Hover runs when a mouse pointer moves onto the widget. It never runs on a tablet or phone, which have no pointer to hover with, so don't hang anything a learner must see on it.

A widget set to Draggable tells a tap from a drag. A quick tap that doesn't move it runs On Press. Pressing it and moving it is a drag: nothing on On Press runs, and When Dropped in the Right Place takes over when it lands. Holding it down for more than half a second without moving doesn't count as a tap either. From the keyboard, Enter runs its On Press and Space picks it up. If it has no On Press behavior, Enter picks it up too.

_Example: On a draggable picture of an animal, add a Play Sound to On Press so a tap plays the animal's name, while dragging it into the right habitat still sorts it._

Two kinds of widget don't offer these two events, because a learner can't press them:

  • A container — it has no look of its own. Add the behavior to a widget inside it.
  • An audio or read-aloud player with the Invisible layout.

When Dropped in the Right Place

A draggable's When Dropped in the Right Place runs when the learner drops it on one of its Valid Targets. On a drop bucket, it runs only when the item is one of that bucket's Correct draggables — a drop in the wrong bucket doesn't count. To react to every drop, whatever landed, use the bucket's own When Widget is Dropped Here.

On Correct

Any widget with Scoring enabled gains an On Correct event. It fires the moment that widget becomes correct — as the learner interacts, before they submit — and fires again if the answer leaves and re-enters the correct state. Use it to reward a right answer in place, for example to play a confetti effect (Play Effect), reveal a praise message, or set a "got it" variable. Because it is driven by the widget's own grading, it works the same way across every scorable widget type — multiple choice, fill in the blank, matching, number input, and the rest. This is distinct from scene-level pass/fail handling under Scene Settings, which runs only when the whole scene is submitted.

On Wrong Selected and On All Correct Selected

Multiple choice and matching have two more events of their own.

  • On Wrong Selected runs every time a learner picks a wrong answer they hadn't already picked: each wrong option they tap on a multiple choice question, and each wrong pairing they make on a matching activity. A learner who guesses wrong twice gets your hint twice. Un-selecting an answer, or tapping the one that's already selected, isn't a new pick, so nothing runs.
  • On All Correct Selected runs once, when the answer becomes fully right, and again only if the learner changes it away and back.

_Example: On "Which of these is a mammal?", add a Display Message to On Wrong Selected that says "Look for the animal that feeds its young milk." Every wrong guess gets the nudge until the learner picks the whale._

On Correct Selected and On Wrong Selected (dropdown)

A dropdown holds one answer at a time, so it has its own pair. On Correct Selected runs when a learner picks an option you marked correct, and On Wrong Selected runs when they pick one you didn't. Each runs for every new pick, including a switch from one wrong option to another. Picking the option that's already showing isn't a new pick, so nothing runs.

_Example: On a "Choose the past tense" dropdown, add a Display Message to On Wrong Selected that says "Look for the -ed ending." Each wrong pick gets the hint._

A behavior whose event the widget no longer offers

Sometimes a widget has behaviors on an event it doesn't offer, for example a lesson made by Ask Berdee or imported from elsewhere. Those behaviors still run (except On Press and On Hover on a widget a learner can't press, described above), and they stay in the Behaviors list so you can edit or remove them, even though Add Behavior doesn't offer that event.

On Press runs on every tap too, right after the answer is picked. On a hotspot, that includes the tap that switches it back off.

Actions: what can happen next

Common built-in actions include:

  • Navigate to another scene
  • Delegate to a router, which picks the destination from its rules
  • Set a variable
  • Increment a variable
  • Toggle a yes or no variable
  • Clear a variable
  • Display a blocking message over the scene
  • Submit answers
  • Reset answers for another try (clears the answers on screen too; submitted answers stay locked, and points a learner earned from a scored button are kept — a press is not an answer). Let students check their work and start over pairs it with a Check my answers button
  • Play a celebration or reaction effect

This means you can move beyond simple “next button” lessons and build experiences that react to learner choices.

Every navigate action you wire here shows up as an arrow in the Lesson Graph, where you can see the whole set of paths together and edit any one of them on the map.

Display message

Use Display Message when the learner should pause, read feedback, and dismiss it before continuing.

A display message appears as a modal overlay on top of the current scene. It stays up, and blocks the scene behind it, until the learner chooses Dismiss (or presses Escape). It never disappears on a timer, so every learner can take as long as they need to read it. Screen readers read the message aloud when it appears, and keyboard focus moves to Dismiss, then back to where the learner was.

Display messages can use three styles:

  • Normal for neutral instructions, reminders, confirmations, or checkpoints
  • Success for positive feedback, completed steps, or pass messages
  • Failure for retry guidance, incorrect-answer feedback, or support prompts

The message text supports the same variable/template syntax used in scene text, so a message can include learner-specific or lesson-specific values.

Common uses:

  • A button displays a short direction before revealing the next task.
  • A correct selection displays a success message without leaving the scene.
  • A failed submission displays retry guidance before the learner tries again.
  • A timer completion displays a "time is up" message before another action runs.

Use Display Message for feedback that must be acknowledged. Use a normal text widget with conditional visibility when the feedback should remain visible on the canvas while the learner keeps working.

Conditions: when behavior should apply

Conditions let you say “only do this if...”

Conditions can check:

  • Grading state
  • Variable values
  • Widget state
  • Or grouped logic using all or any rules

Example uses

  • Show a hint only if the learner has not answered correctly yet.
  • Navigate to a success scene only if the current scene meets the passing score.
  • Reveal a reflection prompt only after a learner presses a specific button.

Adding a condition to a behavior

Every behavior starts with no condition, so it always runs. To gate it, press + Add Condition beneath the behavior's actions — the same place you'd press + Add Action. A condition row appears where you pick what to check (a widget's state, a variable, or the scene's grading) and the comparison. Remove every row to make the behavior unconditional again. When a condition checks a yes/no variable, you compare it against Yes or No.

Several behaviors on one event

A single event — say On Press — can hold more than one behavior, each with its own condition. Press Add Behavior and choose the same event again to add another. Berdee checks each behavior independently when the event fires and runs every one whose condition passes. This is how one button can branch: one behavior navigates forward when the learner has answered correctly, while another shows a "try again" message when they haven't.

Every behavior is checked against the lesson's state at the moment of the press — all together, before any of them runs. So a behavior that changes a variable or navigates can't accidentally flip whether a sibling behavior fires. You can safely write mutually exclusive branches like "navigate when the scene is passing" and "stay and show a hint when it isn't" on the same button: exactly one fires, decided by the state when the learner clicked.

Conditional visibility

Visibility is one of the most practical places to use conditions.

Widgets can be:

  • Always visible
  • Always hidden
  • Shown when a condition is met
  • Hidden when a condition is met

This makes it easy to create:

  • Hints
  • Layered explanations
  • Unlockable content
  • Success states
  • Retry states
  • Differentiated scaffolds

Submission and grading logic

One of the most useful actions is submit answers.

That action lets you grade:

  • The current scene — every graded question on it, with any the learner skipped counted as 0 (questions hidden from them aren't counted)
  • The whole lesson — this finishes the attempt
  • Or a custom group of graded widgets — only that group's widgets, on any scene the learner has visited; the rest of the scene stays open

The submit action itself only grades — it does not carry a destination. Where the learner goes next on a correct result is set separately, on the scene's own Progression (in the Scene Settings panel), not on the submit action. There is no automatic "on incorrect" destination — an incorrect result just leaves the learner on the scene, so add a regular button (labeled something like Try Again) if you want a way back to attempt again. See Scene Progression for how Progression works.

A practical pattern:

  1. Learner completes the activity.
  2. Pressing a button submits answers.
  3. On a correct result, the scene's Progression sends them to a feedback scene. On an incorrect result, they stay put — a Try Again button gives them another attempt.

This is often cleaner than trying to manage every answer outcome manually.

A real-world example

Imagine a vocabulary lesson:

  • The learner picks answers in a multiple choice widget
  • A Submit button triggers submit answers
  • The scene's Progression is set so passing navigates to a celebration scene
  • A Try Again button lets learners who did not pass attempt the scene again
  • A variable increments each time they attempt the task
  • A hint appears only after the first unsuccessful try

That is a strong example of using logic in service of instruction, not complexity for its own sake.

See Submit and branch for the full recipe.

Scene navigation rules

Berdee enforces two rules on every scene-navigation action — navigate_to_scene, and the "correct" destination set on a scene's Progression:

  1. A scene cannot navigate to itself. Self-targeted navigation is always a mistake — it either silently does nothing or creates a loop with no progress for the learner. For a scene's Progression, choose Stay instead of selecting the current scene. For other stay-on-scene effects, use the matching action — display_message, reset_answers, set_variable — rather than re-navigating to the current scene.
  2. A scene can only navigate to another scene. A layout, for example, is a shared backdrop, not a learner step, so it can never be a destination. Pick the specific scene you want the learner to land on.

These rules are enforced in two places:

  • The Studio's edit pipeline rejects any save that would introduce a violation, with a clear error.
  • The publish validator blocks Publish if a violation slips through (for example via an imported template).

If you see a validation:self_navigation or validation:folder_navigation error, open the scene named in the error, find the widget by ID, and pick a different navigation target.

Best practices

  • Start with one event and one action before building larger chains.
  • Use conditions to reduce clutter, not to make the lesson mysterious.
  • Keep scene flow understandable even when branching.
  • Use celebration effects selectively so they still feel meaningful.
  • Celebration effects respect reduced motion. A learner whose device has "reduce motion" turned on sees no confetti, fireworks, or emoji burst at all — the effect is skipped rather than shortened. Never make a Play Effect the only signal that something went right; pair it with a message, a score change, or a scene move so the meaning survives without it.
  • Test the full learner path in preview, not just isolated pieces.

Learn by doing

Was this article helpful?