amyjko/gidget

Computing education through playful debugging

gidget's Issues

use experiment variable to vary Gidget's words

Gidget's words should vary by condition. In particular, the GIDGET.experiment.condition flag should be checked to vary the text in text.js.

Mike, this is yours!

when things are in the first row, their names are not visible

The current workaround is to never put something in the first row that has a name. Could we just make it so that names appear on the bottom when they might get clipped?

create an experimental condition global variable that causes text and other media to change

The experiment we're running should support three conditions, it, he, and she, all resulting in different graphics and text. Our media should be checking this variable and changing the text accordingly.

animate NAME changes

Currently, the name is just modified with no fanfare. Should it be more apparent that it changed?

most recent version of code should be used if there is one, in case someone loses their place and returns to the page

When a user edits a level's code and then returns to the level later, the user's version of the code should appear, not the default code for the level.

Phantom Gulls need to be able to set energy of Gidget when at the same location

If a gull is enclosed within walls, a "phantom" (that we can't see), will continue to pursue gidget. He does not "avoid" this phantom gull, resulting in failure.

Example: Uncommenting some of the walls in Level 34 (relaseGulls_bug) will produce this behavior. Level 34 also exhibits Gidget not avoiding correctly with or without the walls.

code version history should be stored in local storage

This way, we can track what changes the user made to each level and when.

Analyze

ANALYZEing an item has gidget state:
"I analyzed X. Now I can make it do things!"

Analyze does the following things:

1. Let's gidget see attributes (e.g. the rock is RED)
2. Let's gidget see functions (i.e. API calls) (e.g. the battery can ENERGIZE)

Currently:

1. User can mouse over an icon in Gidget's "memory" to see attributes (e.g. this rock is RED)
2. There is no way the user can know what commands an object can execute (e.g. there is never any record, mouse-over, gidget speech, or otherwise, indicating that ENERGIZE is a legal command).
3. There is no clear indication that mousing-over an analyzed object will show attributes.

Possible solutions:

1. Have gidget state: "I analyzed X. It is RED and I can ask it to ENERGIZE!"
2. Have gidget state: "I analyzed X. It has special attributes, I can check my memory banks to see what they are."

After data is successfully uploaded, an MTurk code should be provided to the user.

Need to ask Parmit about how she's handling code generation.

verify the correct execution of *every* possible parsing error

The process for this should be to go through each possible parsing error, as enumerated in text.js, and produce a program that produces the error. We want to confirm that there aren't any errors in any of these cases.

execution of Gidget goal should be visualized, just like normal code, to explain goal execution semantics

This will help deal with confusion about what the goals mean and how they are evaluated.

create a speak command, which allows things to have thought bubbles

This way, things can have a bit more personality.

Multi-scan/analyze in "memory"

SCANning or ANALYZEing an item more than once continues to add multiple instances of itself to Gidget's "memory," i.e. the "scanned" and "analyzed" lists on the right column.

This potentially makes it appear as if there are more instances of things than there actually are in the world.

provide feedback about why code can't be edited during program execution

For example, a flash, a popup, and perhaps a highlight on the "the end button".

all levels should now use world.addMissionText("state", "text") to indicate mission text.

This allows missions to be stated in multiple paragraphs with different affects.

Gidget should better explain conjunction semantics of "is" operator

gCode (Gidget code), executes correctly and goal should be completed successfully.

GOAL: "rock on gidget is red"

goal success and failure messages should refer to the results stack

This will improve the explanation of why the goal succeeded or failed.

play button animates code but not goals

This was a condition I overlooked when implementing the code to animate goal execution.

Level 16 - Play must be pressed more than once to complete level.

Executing "play" stops after executing the first line. Program will continue (and finish) only after playing "play" again.

This appears to happen in levels with "gulls" in them. Another example is Level 29 (getTwoRocksGulls).

create an analysis script that displays and visualizes results

It should grab all of the JSON files from the server and display useful results about the study.

after GIDGET.ui.quit() is called, no more Turk codes should be given out.

If we leave the quit button active, a person could submit the data multiple times and receive multiple codes.

need to choose a more visible place and style for the "I quit" button

Currently, it's next to the world label. Maybe outside of the whole content area, on the right or left? It should be really obvious how to quit and get the MTurk code, but now it's kind of hidden.

gidget's "memory" window is not removing past "focus" and "results" consistently

Gidget's memory window is adding multiple instances of the same "thing" in his 'focus' and 'results' lists.

This happens consistently in any level where gidget is SCANning and GOTOing to multiple things. Level learnCompounds (currently level 8) is a good example.

Visually, in "focus," multiple instances of the same things are added to the same list. In "results," it looks like a new list is being made for each insatnce of the thing.

first level ground should be grass

To be consistent with the introduction.

execution buttons are conceptually inconsistent with the idea of collaboration

Currently, it feels like Gidget is talking at the user, but the user isn't talking back. Are there ways we can present the play, next, next line, and end buttons more as a response to what Gidget is saying, rather than some user interface control?

One of the challenges of this from a UI perspective is that if we put them below Gidget's text, they'll keep moving, which will make the 'next' button difficult to click repeatedly.

implement TAG and UNTAG commands

TAG and UNTAG will be used to give things attributes that can be checked with the IS command. We don't have a use for this at the moment, but I anticipate it being a nice feature for level design.

experimental condition should be persisted in local storage

Currently, the experimental condition is reset on every page load. It should be saved in local storage.

store uploaded level data in a database

Currently, finished.php doesn't do anything with the uploaded data. It needs to store it for later in a database somewhere.

check for canvas and local storage support and show fail screen if unsupported

This should happen in the initialization step.

need a more effective way of visualizing the height of a thing

For example, perhaps we could just use graphics, allowing things of height 2 to be rendered two cells tall, so they look tall and things can go behind them. The current shadows just don't work very well.

Unspecified "beneficiary" when energizing in gCode stops program execution

In level "useObjectEnergize," having an unspecified "beneficiary" in gCode halts the rest of the program from executing.

Example gCode for bug replication:
ask battery to energize

Console Message:
"TypeError: Result of expression 'arguments[argIndex]' [undefined] is not an object."

if something is already grabbed, it should be removed and added to the new things list of grabbed things

For example, Gidget grabs a rock and the blackhole grabs it from him.

offer correction suggestions for parsing problems

For example, if the parser complains a comma is missing, offer to add one. If the parser complains that a name is missing for a command, ask what it should be.

Level 01 - Gidget's sense of self

SCANning gidget causes some unexpected behaviors:

1. First line is not highlighted during execution using "next line" button.
2. Goal complete successfully, independent of whether gidget was scanned. Examples:
   A) (no code) == success
   B) "scan gadget" == success

need subtle, non-invasive pastel pastoral background instead of black

Background for page.

Gulls blocking a path

If a gull is blocking the only path to an object that Gidget is trying to "goto" while "avoiding," it will cause him to fail.

Example: Level 30 (getTwoRocksGull_Bug).

gidget goals should be presented in paragraphs to facilitate points with different affect

For example, he may be happy about one thing, then sad about another. Each paragraph might be tagged with a certain affect, in the way execution actions are.

vary Gidget thought font by condition

Fixed width for control, Verdana for experimental.
Control condition with no rounded corners, black with green terminal text.

Blocked "rat" doesn't move, even after a path opens up.

This is probably related to the Gidget problem we had earlier (his giving up if there is no valid path). This is not an essential feature and can be prioritized lower since the level can be redesigned if this feature doesn't work.

In level, learnAll (currently level 20), rats are initially barricaded inside walls (i.e. no path to Gidget). Gidget proceeds to press a button which lowers the walls and opens up a path. Currently, the unexpected behavior is that the rats don't move out of their initial position (probably because their initial "goto" failed and they aren't executing it again). GOTOing to a rat drains Gidget's energy as expected.

Intro animation - Feature requests

Feature requests after trying to implement movie in current animation script:

1. Animation area resolution to support 640x480px image (i.e. background --> currently loaded as a sprite).

---

Optional (let's discuss):
2. Sprite rumbling/shake animation (like we saw in the Nintendo DS example - can be used in the "boom" sequence and/or when Gidget lands on his/her/its head).
3. Sprite rotation (CSS3 compatibility with older browsers may be limited)
4. Glide ability from (x1,y1) to (x2,y2) for sprites (can be used for Gidget's falling sequence, factory workers running out of building, and possibly for helicopters.)

---

If we choose not to implement the optional section above, we might not have to actually "animate" anything. Instead, we could just use the current code, as-is, and have it go through the storyboard frames (much like the MOV file I uploaded). However, depending on the number of frames we implement, this can appear choppy.

center and size the introductory movie canvas container

Currently it appears offset to the right and the div doesn't fit to it's size.

create interface for quitting that uploads the localstorage data set and provides the MTurk code

I'm imagining a big button that says "I'm finished", which uploads the data set and provides a code.

blackhole needs to be able to grab things that pass over it

Perhaps my code is wrong here, but I am trying to have "blackhole" "grab" gidget's items if he passes over it.

Possible outcomes after item is stolen:

1. Gidget can "grab" it again if on top of it
2. Gidget cannot "grab" it anymore - level must be restarted.

edit focus isn't clear sometimes causing backspace to go back in browser

Potential solution is to make the focus much clearer and more obvious.

parsing error messages need to be factored out for experiment

All of the runtime messages are factored out, but I haven't factored out the parsing error messages.

when a thing is placed, it should recursively place all things that it has grabbed

For example, if Gidget has grabbed a rock and a car has grabbed gidget, and the car moves, everything should move.

track when the program is run, stepped, etc. in local storage

This will allow us to know how many times the user ran the program. This should all be stored in the levelMetadata object stored in local storage.

avoid only avoids one thing with a matching name

Mike's words: " "avoid" does not work consistently with more than one thing to dodge. E.g. if you uncomment some of the code I left out in Level "learnAvoidPassive," Gidget does not avoid the blue goops. This is consistent with "avoid"ing multiple rats."

Gulls on an object

It appears if a gull is on an object, gidget will not "goto" it if "avoiding".

Example: Level 31 (getTwoRocksGull2_Bug)
[Gidget sees two rocks, but only goes and grabs one.]

GIDGET.ui.quit() needs to reveal a demographics questionnaire

The questionnaire should ask about prior programming experience, gender, age, etc., and be part of the form submission.