Cognitive-Load Code Editor for Student Programmers

ISEF Category: Systems Software

Subcategory: Human/Machine Interface  ·  Difficulty: Advanced  ·  Setup: School Lab  ·  Time: Full Year

The Hook

Notifications break your focus fast. In coding, that can mean the difference between one clean solution and a pile of half-finished fixes. A smart editor that reacts to your typing and scrolling could protect your attention without needing a camera or biosensor. That makes this a real human-computer interaction problem, not just a coding trick.

What Is It?

This project studies a code editor that guesses when you are mentally busy, then delays or hides low-priority notifications. Instead of using a heart sensor or eye tracker, it watches signals you already create while coding, like typing rhythm, scroll changes, cursor jumps, and edit churn. Think of it like a quiet library assistant. If your desk is full of open books and notes, the assistant waits before interrupting you.

The big idea is cognitive load, which means how much mental effort you are using right now. When a task gets harder, your behavior often changes. You may pause more, edit faster, or jump around the file more often. A system can treat those patterns as clues and adjust the interface. Your job is to test whether those clues really predict when notifications should be suppressed, and whether that helps students work better on programming tasks.

Why This Is a Good Topic

This is a strong science fair topic because you can measure both behavior and performance. You can build a clear interface feature, then test whether it changes task time, error rate, perceived distraction, or code quality. The topic connects to real software design, since developers, students, and workers all lose focus from bad interruptions. You can also study a real human factor question, which is whether a system can infer workload from interaction patterns without asking the user directly.

Research Questions

• How does notification suppression based on typing rhythm affect programming task completion time?
• What is the effect of scroll and edit churn on predicting when a student is mentally loaded?
• Does a cognitive-load-aware editor reduce self-reported distraction during coding tasks?
• To what extent do typing pauses and cursor jumps predict performance drops on debugging tasks?
• Which combination of interaction signals best separates high-focus and low-focus coding moments?
• How does adaptive notification timing affect code accuracy compared with fixed notification timing?

Basic Materials

• Laptop or desktop computer with a code editor or browser-based coding environment.
• Logging software or editor extensions that record keystrokes, cursor moves, scroll events, and notification timing.
• Two comparable programming tasks for your test sessions.
• Survey form for distraction, workload, and task difficulty ratings.
• Screen recording software for checking behavioral patterns later.
• Spreadsheet software for organizing session data.
• Consent and assent forms for student participants.

Advanced Materials

• Development machine for building the adaptive editor prototype.
• Local server or event logger for capturing interaction events in real time.
• Database or structured log files for session data.
• Statistical software for within-subject analysis and model comparison.
• Python with data analysis libraries for feature extraction and classification.
• Optional eye-tracking device if you want to compare inferred load with gaze behavior.
• Institutional review materials if your school requires formal human-subjects review.

Software & Tools

• Python: Processes interaction logs, extracts features, and runs statistical tests or simple classifiers.
• R: Compares task outcomes across conditions and supports within-subject analysis.
• ImageJ: Can help inspect screen captures or measure interface changes if you build visual summaries.
• Jupyter Notebook: Keeps your analysis, plots, and notes in one place.
• VS Code: Provides a flexible environment for building and testing the editor prototype.

Experiment Steps

1. Define the exact coding task your participants will do, then choose one outcome you will measure, such as speed, accuracy, or distraction.
2. Decide which interaction signals count as your load features, such as typing pauses, scroll churn, cursor jumps, and edit density.
3. Build a baseline condition and an adaptive condition so you can compare normal notifications with load-aware notifications.
4. Plan a within-subjects order that balances learning effects, so each student tries both conditions in a fair sequence.
5. Design a scoring method that turns log data into numbers you can compare across sessions.
6. Map out the analysis before you collect data, so you know which patterns would count as a real effect.

Common Pitfalls

• Confusing coding skill with cognitive load, which makes strong programmers look like low-load users just because they type faster.
• Using notification rules that react too slowly, so the system mutes alerts after the student has already been interrupted.
• Collecting logs without matching them to task phases, which makes it hard to tell whether a pause means thinking, reading, or getting stuck.
• Testing only one type of programming task, which can hide the fact that debugging and writing new code trigger different interaction patterns.
• Ignoring order effects in a within-subjects study, which can make the second condition look better just because the student has practiced once already.

What Makes This Competitive

A stronger version of this project goes beyond a simple on-off notification rule. You could compare several load signals, test whether one feature set generalizes across tasks, or build a model that predicts interruption risk before performance drops. Careful controls matter here, especially counterbalancing, task matching, and a clear baseline. Strong analysis of effect sizes, confidence intervals, and false positives would make the project much more persuasive.

Project Variations

• Use debugging tasks instead of code-writing tasks to see whether interruption patterns change when students hunt for bugs.
• Compare keyboard-only signals with keyboard plus scroll behavior to test whether mouse and scroll churn improves prediction.
• Swap notifications for other distractions, such as message badges or pop-up hints, and measure which interruption type hurts focus most.

Learn More

• PubMed: Search for review articles on cognitive load, interruption, and human-computer interaction studies.
• NIH National Library of Medicine: Use PubMed and related databases to find research on attention, workload, and task performance.
• MIT OpenCourseWare: Look for free courses on human-computer interaction, software design, and user studies.
• ACM Digital Library: Search for papers on adaptive interfaces, interruption management, and developer productivity.
• arXiv: Search for recent preprints on user modeling, attention prediction, and code editor instrumentation.
• NIST/USGCRP human factors resources: Look for public reports on measuring workload, usability, and decision support.