You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most steps in the course are verbatim steps, meaning the user has to enter exactly the code they are told to. 'Exactly' means that the AST must match - there can still be differences in whitespace, the type of quotes used, or comments, but the structure and logic must be identical. There are some problems with this:
We want users to type code in, rather than copy and pasting it. If they type something in incorrectly, they don't get any feedback. We could perhaps do some kind of fuzzy matching between the user's code and the expected code. If they're very close, we could show a message indicating which parts of their code don't match. However we have to be careful to do this unobtrusively because they might just be experimenting with some code they wrote in a previous step before tackling the current step, which we want to encourage. Perhaps the hint bulb could suddenly appear and clicking it would show them the problem.
Sometimes the code they need to type in isn't directly shown, when users are told to make a small change to existing code. We don't show the code because it would add redundant clutter and would lead to more mindless copying instead of thinking about what they're changing. But if they misunderstand the instructions, they're stuck. These steps generally don't have hints and thus users can't access the solution. In any case the usual solution reveal would be out of place, we would probably just want to show the whole thing immediately. But to avoid people jumping to this, maybe it should only show after 2 failed attempts?
Steps often start with declaring some 'input parameters'. For example in this step:
sentence is a parameter, and users shouldn't have to write it exactly. In fact exercise steps already allow this. In most cases, the same flexibility would be good in verbatim steps.
Similarly, maybe variable names could be flexible?
These kinds of flexibility already exist in a couple of ways:
If you type in everything correctly except the case is wrong, e.g. something is uppercase when it should be lowercase, there is a message warning about case sensitivity in Python.
If you type additional statements after the part you're supposed to type in, they're ignored and you still pass.
The text was updated successfully, but these errors were encountered:
Most steps in the course are verbatim steps, meaning the user has to enter exactly the code they are told to. 'Exactly' means that the AST must match - there can still be differences in whitespace, the type of quotes used, or comments, but the structure and logic must be identical. There are some problems with this:
sentence
is a parameter, and users shouldn't have to write it exactly. In fact exercise steps already allow this. In most cases, the same flexibility would be good in verbatim steps.These kinds of flexibility already exist in a couple of ways:
The text was updated successfully, but these errors were encountered: