Updates from Belen Toggle Comment Threads | Keyboard Shortcuts

  • Belen 7:34 am on July 24, 2025 Permalink  

    Survey data that makes sense 

    Imagine you’re running a course evaluation in which students select which topics they studied, then rate their confidence in each one.

    A common issue with most survey platforms that generate questions dynamically is that, when you download the data, it looks like this:

    StudentIDQ3_TextQ4_Response
    001Algebra, Statistics4|3
    002Geometry, Algebra2|5
    003Statistics, Geometry3|5

    Which rating goes with which school subject? You’ll need to do some work to figure that out.

    A Different Approach

    With GuidedTrack’s data::store, you can create columns based on what students actually tell you:

    *question: Which topics did you study this semester?
    	*save: topics_studied
    	*multiple
    
    *for: topic in topics_studied
    	*question: How confident do you feel about {topic}? (1-5 scale)
    		*answers: [1,2,3,4,5]
    		*type: slider
    		*save: confidence_level
    	>> data::store("{topic}_confidence", confidence_level)

    This will generate columns that tell you exactly what each number means and your data will look something like this:

    StudentIDAlgebra_confidenceStatistics_confidenceGeometry_Confidence
    00143
    00252
    00345

    Key advantages of using this feature

    • Clear column names: Instead of remembering what Q4_Response means, you see “Algebra_confidence.”
    • No predefined lists: If a student studies “Linear Algebra” or “AP Statistics,” those become column names automatically. You don’t need to guess every possibility upfront.
    • Flexible data structure: Your columns match what people actually studied, not what you thought they might study.

    Common use cases

    • Product feedback where customers choose features to rate
    • Event surveys where attendees select sessions to evaluate
    • Employee surveys where people rate specific departments
    • Complex academic studies where different participants answer different questions or see different stimuli
    • MaxDiff and Best Worst studies where participants see different sets of options and you need separate columns for each combination

    In short, this feature is helpful when your GuidedTrack program asks users to choose or enter a list of items, and you want to follow up with a question about each one they selected.

    How to use *data::store

    The syntax is:

    >> data::store(columnName, value)

    Just replace columnName for the name you want to see in your csv file for that column, and value for the variable containing this column’s value.

     
  • Belen 1:20 pm on June 24, 2025 Permalink  

    Tip: Use *experiment to run better studies with balanced groups 

    Picture this: You just finished running a study with 100 participants, each randomly assigned to one of three interventions, to compare how effective they are. You’re excited to analyze the results, but when you open your CSV file, your heart sinks. Group A has 45 people, Group B has 32, and Group C has only 23.

    Your beautiful research design just got a lot more complicated.

    If this sounds familiar, you’re not alone. Unbalanced groups are a common headache in research, and they can seriously mess with your statistical analysis. The good news? GuidedTrack’s *experiment feature solves this problem automatically.

    What makes *experiment special?

    In most survey platforms and research tools, getting balanced groups can be a nightmare. You either have to manually track participant counts, use complex external randomization services, or just cross your fingers and hope for the best.

    GuidedTrack’s *experiment feature handles all of this automatically by ensuring that group sizes never differ by more than 1 person. Here’s the basic concept of how it works. Suppose you have two groups in your study. Then, *experiment makes sure that the first two participants end up in different groups from each other (selected at random). The next two people also end up in different groups from each other. And so on. Each pair is randomized to one of the two groups, keeping the size of each group balanced.

    Real examples of *experiment in action

    ๐Ÿง  Testing Different Meditation Techniques

    Let’s say you want to compare three approaches to stress reduction:

    *experiment: Meditation_Study
    	*group: Visualization
    		For the next 10 seconds, visualize yourself in a warm, happy place.
    		*wait: 10.seconds
    
    	*group: Writing
    		For the next 10 seconds, write about a warm, happy place.
    		*question: My warm happy place is...
    	
    	*group: Control
    		For the next 10 seconds, just sit quietly and breathe normally.
    		*wait: 10.seconds
    

    With 90 participants, you’ll end up with exactly 30 people in each group. No more, no less.

    ๐Ÿ“ฑ A/B Testing App Interfaces

    Product teams can benefit from using *experiment to test different user interfaces:

    *experiment: Button_Color_Test
    	*group: Red_Button
    		--[...Set the button color as red...]
    	
    	*group: Blue_Button
    		--[...Set the button color as blue...]
    	
    	*group: Purple_Button
    		--[...Set the button color as purple...]
    

    Whether you get 47 users or 150 users, each version will be seen by roughly the same number of people.

    Advantages of using *experiment

    Statistical Power: Balanced groups give you the best chance of detecting real differences between your conditions. Unbalanced groups can hide important findings or make you think you found something when you didn’t.

    Easier Analysis: Most statistical tests work best with equal group sizes. You won’t need to worry about weighted analyses or explaining why your groups are different sizes.

    Professional Results: When you present your findings, balanced groups look intentional and well-planned (because they are).

    When to use *experiment

    Use *experiment when:

    • You’re comparing different treatments or conditions
    • You plan to analyze differences between groups
    • You want balanced sample sizes
    • You’re running A/B tests

    You might not need it when:

    • You just want variety in your content
    • You’re showing random examples or scenarios or you have a very complex randomization scheme (use *randomize instead)
    • Balance isn’t important for your goals

    Syntax of *experiment

    *experiment: Your_Experiment_Name
    	*group: Group_A
    		-- Content that only participants assigned to Group A will see
    
    	*group: Group_B
    		-- Content that only participants assigned to Group B will see

    When you examine the CSV file, you’ll see a column labeled with your experiment’s name in the header row. Each row beneath it indicates the group assigned to that particular run.

    Tips for creating studies with *experiment

    1. Name your experiments clearly: “Onboarding_Flow_Test” is much better than “Experiment_1” when you’re looking at data six months later.
    2. Keep groups meaningful: Don’t create 12 tiny groups when 3 larger ones would give you better statistical power.
    3. Document your hypotheses: Before you launch, write down what you expect to find. Your future self will thank you.

     
  • Belen 9:31 am on March 18, 2025 Permalink  

    Tip: Use *trigger to Keep Programs Responsive in Loops with Numerous Iterations 

    When a loop runs a large number of iterations without a break, it can cause the program to become unresponsive.ย  To prevent this, adding a *trigger inside the loop can help. Even if the *trigger does not perform any specific action, it interrupts the loop execution, allowing the program to continue running smoothly.

    Here is an example of how you would do this:

    *while: some_action
    	*trigger: meaningless_trigger
    	-- loop content here

    This simple addition ensures that the loop does not run indefinitely, preventing the program from freezing.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel