Re:Code with Mu: a simple Python editor for beginner program...
by ntoll on Sunday July 29, 2018 @10:58AM
(#17638454)
Thank you!
The rational for deciding features is three-fold:
* A positive answer to, "is it going to make it easy for a beginner to write, execute and change code?" is the first requirement (we check this with user research -- I've observed lessons, code clubs and other beginner-related activities as well as interviewed teachers and learners to find out how they react).
* Alternatively, we checked the features the Raspberry Pi Foundation had feedback about. For instance, the zoom in/out buttons were one of the most requested features from teachers in feedback to the RPi education team. When I demoed this to teachers for the first time there were gasps of amazement (which made me smile, given what a simple / easy to implement feature this is). This is extraordinarily useful in a classroom situation and for learners who may have a visual impairment (such as older learners with bad eyesight... a group I had never initially thought would want to learn... but hey... I rather like the idea of Granny coding Python). ;-)
* Can we demonstrate an obvious progression from Mu's (simple) implementation to a similar feature in an editor to which the user is likely to graduate? For example, the visual debugger is very simple, but looks similar enough to a "proper" debugger in a professional IDE that a beginner graduating to such an environment won't feel out of their depth.
Once a feature is "in" a lot of time and effort is spent making it as simple yet useful as possible. This is likely to be the first time someone will have used such a feature and we need to ensure that the intention is clear, the use is obvious and the outcome useful from the perspective of the learner/teacher.
We also have a "rule of three" when it comes to "nice to have" features... if three people independently ask for something we try to implement it (a good example being toggling on/off of commenting).
The rational for deciding features is three-fold:
* A positive answer to, "is it going to make it easy for a beginner to write, execute and change code?" is the first requirement (we check this with user research -- I've observed lessons, code clubs and other beginner-related activities as well as interviewed teachers and learners to find out how they react).
* Alternatively, we checked the features the Raspberry Pi Foundation had feedback about. For instance, the zoom in/out buttons were one of the most requested features from teachers in feedback to the RPi education team. When I demoed this to teachers for the first time there were gasps of amazement (which made me smile, given what a simple / easy to implement feature this is). This is extraordinarily useful in a classroom situation and for learners who may have a visual impairment (such as older learners with bad eyesight... a group I had never initially thought would want to learn... but hey... I rather like the idea of Granny coding Python). ;-)
* Can we demonstrate an obvious progression from Mu's (simple) implementation to a similar feature in an editor to which the user is likely to graduate? For example, the visual debugger is very simple, but looks similar enough to a "proper" debugger in a professional IDE that a beginner graduating to such an environment won't feel out of their depth.
Once a feature is "in" a lot of time and effort is spent making it as simple yet useful as possible. This is likely to be the first time someone will have used such a feature and we need to ensure that the intention is clear, the use is obvious and the outcome useful from the perspective of the learner/teacher.
We also have a "rule of three" when it comes to "nice to have" features... if three people independently ask for something we try to implement it (a good example being toggling on/off of commenting).