saeub / okra Goto Github PK

• Consistent use/omission of const in arguments
• Prefer required keyword arguments over many positional arguments in constructors
• Doc comments
• More sane type casting in JSON deserialization
• Rethink testing without assets (e.g. reaction time task)
• Increase test coverage
• Null safety
• Replace QR package (ML Kit?)
• Remove stopwatch?
• Fix stretched loading animation on AboutListTile
• Somehow prevent passing mutable objects as data when logging (logged values must be frozen); having to remember to put .toList() every time is not very nice (see b9594ad)
• Organize imports (relative within package, sorted)
• Use ApiError.retriable to consistently show retriable/unretriable error messages
• Use final instead of var whenever possible (good reason)
• Rename subtask to trial
• Put default/initial values for stateful widgets in field definition or constructor, use initState only if access context is required

Add an optional randomSeed to relevant task data:

• Digit span
• n-back
• Reaction time
• Simon game
• Trail making

• Sound effects (control or record volume settings)
• Graphics / animations on results page
• Temporary high score for repeated tasks

• Comprehension questions
• Ratings
• Instructions after task

• Support different fonts (per task?)
• Bundle Atkinson Hyperlegible via Google Fonts

• Description: https://en.wikipedia.org/wiki/N-back
• Example implementation: https://www.psytoolkit.org/experiment-library/nback2.html

• Update and extend integration tests
• Make them work in CI/CD
• Automatically take screenshots and upload them every release (see here or here)

Tasks should always be configurable to give the participant (immediate) feedback about correct and incorrect answers, but it should never be enforced. Currently, feedback is only supported for lexical-decision.

Think about backwards-compatibility. Communicate versions between API and client. Have clients reject APIs with incompatible versions.

What happens when a client or an API is upgraded?

All of these need to be done before the pilot study:

• Two stages in question answering (only text → rating → text + questions)
• Translate practice indicator
• Don't show ratings for practice tasks
• Better spacing in question answering (and larger hitbox?)
• Display context-aware message after finishing practice task
• Show participant ID in API settings
• Show loading animation while finishTask request hasn't finished
• Back button on instructions screen
• Don't enforce portrait mode for reaction time task (but lock orientation?)
• Make emoticon order in ratings configurable
• Use package_info_plus
• Fix Markdown scrolling performance issues → postponed until relevant
• Also store task results locally and have some way to access them, just to be safe → let's just risk it

Support an optional practice task per experiment.

• The practice task should be mandatory (at least) before the first task is started, and optionally replayable before any task.
• The task data should probably be included in the Experiment model.
• Might want to send results to the API anyway, even though it's a practice task.

Add configuration at the Experiment level for settings that apply to all tasks (e.g. readingType, showQuestionMark).

More configurability:

• Button labels in lexical decision task
• Number of Likert items

Detect lifecycle events:

• Android: https://flutter.dev/docs/get-started/flutter-for/android-devs#how-do-i-listen-to-android-activity-lifecycle-events
• iOS: https://flutter.dev/docs/get-started/flutter-for/ios-devs#how-do-i-listen-to-ios-lifecycle-events

Add an API endpoint /task/{taskId}/abort.

Require users to correct their answers until they are correct, measure number of retries.

As in Laban et al. (2021) (p. 8):

When submitting answers, participants received feedback on which were incorrect, and were required to re-submit until all answers were correct. This aligns the objective of the participant (i.e., finishing the task rapidly), with the task’s objective (i.e., measuring participant’s efficiency at understanding). This also gives a way to discourage participants from “brute-forcing” the task, re-submitting many combinations until one works.