Test Editor Interface: A Reimagining
- Jul 11, 2012
- 2 Comments
A script author should be able to see the world she is writing a script for. So, it’s illogical that the test editor interface be a wholly different perspective than the edit code interface. Rather, an overlay stencil that allows for toggling between a world’s code and the test editor interface is a more optimal solution. This interface is not unlike the code reuse interface.
Well, it seems the overlay stencil idea is impractical...
Below are two 'back of the napkin' sketches depicting the latest interface design.
This new design provides the script author the ability to view a world's code. In practice, the author will refer to the code, as needed, during the script authoring process. The author will be able to view which constructs and statements have passed and failed his or her script via checks and x's included in the world code view. This feedback replaces the passing and failing constructs boxes.
In order for a child receiving a suggestion to be provided a useful tutorial, the community must know what the child should add to his or her world. The community receives this information via the test authoring process. The script author, before authoring tests, will edit her child's world to reflect the world's more optimal version (essentially, the child's world with the suggestion implemented).
The second image depicts the IDE's mentor-view when a mentee has uploaded a world. Mentors will be provided with their mentees' worlds as well as a list of scripts that have suggestions for the worlds. Mentors will mark these tests either as an appropriate suggestion for their mentees (in which case the suggestion will be sent to the mentees), a good suggestion but not appropriate for their mentees or problematic. If the mentor finds that no tests are appropriate for her mentee, she has the ability to edit a preexisting test or create a new test.
Note: the sketches and the conceptual content of this post are the product of a discussion I had with Caitlin today. That said, some of the ideas are established while others aren't even a day old.
Comments
kyle said:
<p>Patrick... I love where you are going with this. You thinking about all the right things and asking the right questions. Actually putting the code status test on the code constructs... totally fits your use case. Great ideas!</p> <p>I'm really close to getting ready to get you working with the community API. We need to talk about the database tables... let's try to do that tomorrow morning... so you can start doing that while I still work on getting the java process to run.</p>
caitlin said:
<p>Patrick, this looks great! Thanks for sticking with the design parts and pushing through to something that has the potential to support the process really well.</p>
Log In or Sign Up to leave a comment.