Project Proposal (redo)

High-level problem:

For my project, I want to do two things.  The first is to finish revamping the remix process and second, to look into the idea of personalized tutorials.  Therefore, my project proposal deals with two high-level problems.  First, what if a user cannot find the code that she/he is looking for, even after going through the tutorial for locating it?  When remixing, you are using another user’s code, and sometimes people may place code in spots that are not intuitive to you.  By using tools already available in Looking Glass, users can try to narrow down where that code may be.  My project would also deal with how to make the remix process in general, easier to use and understand.  The second high-level problem has to do with the second aspect of my starter project, which regards personalized tutorials.  Often in a program, tutorials are one-size-fits-all, which can lead to boring over-explanations to more experienced users, and under-explanations for beginning users.  Learning should not be one-size-fits-all, and the personalized tutorials would see to that being corrected.

Why it’s important:

Remixing is a very big part of the Looking Glass software; a process that sets Looking Glass apart from other programs designed to teach kids to program.  The aspect of reusing code from other users is something unique to Looking Glass.  If users are not able to find the correct line of lines of code for the actions they wish to capture, they lose a significant aspect of Looking Glass, that is why users being able to correctly and efficiently use this process is very important.

When going through the proposed starter projects, I was very interested in the idea of personalized tutorials, but did not have a chance to approach it in my first two weeks.  I would like to approach this subject in my subsequent weeks working with Looking Glass this summer.  As I stated above, tutorials are usually created to be applied to any and all users, however that might not be the best way we can do this.  The idea of more personalized tutorials would allow the user to still learn new things, as all good tutorials should do, but also learn them at their appropriate skill level.  If a user already knows how to create a new method/procedure, there is no reason to tell them all the steps how to do this in a tutorial using multiple procedures or something of the like.

What I’m doing:

Remix Stuff:

I went through two different possibilities of how to implement the help process.  One of them, like Kyle asked, was a wizard-type action, where it would guide users through the process, checking each step of the way if the code was what they wanted.  The second tries to get the users to interact more with the features of Looking Glass, instead of just hitting next a bunch of times, and waiting for the program to fix the problem for you.  It is more useful for learning.  The second version is like a tutorial itself.  It gives the user a list of possible scenarios in which their code might be, and instructs the user how to proceed.  I think after the user testing, I will have a better idea of what kinds of code placement scenarios kids have the most trouble with, and make sure the help program covers them.  I’m still in the process of figuring out exactly how this process is going to work, and whether a wizard-type application might be better or worse for users to use, and how to get users to use this process in general (possibly changing the name, and the location of this process).  Perhaps even a combination of the two?  Something that requires user interactivity so they won’t get bored, but also makes them use the feature of Looking Glass and doesn’t do everything for them.  Caitlin and I only decided on this general design on Friday, so I haven’t had much time to devote to picking this process apart, or possibly coming up with a better way to do it.  I’m not entirely happy with either solution so perhaps I can come up with something better in the future.   

Here's a possible design for the help dialogue

The next change I want to make is to the general Looking Glass interface, specifically changing the step forward/backward action.  Aright now it is set to step back and forth by miniscule time units, so you might end up having to press the button several times to move back even a second.  And even if we made the increment larger, a user might skip over an action they were trying to find.  I think that the best solution is to make the step back/forward button be based on changes made in the Right Now panel, so based on actions instead of time.  Users are looking for a time to find the action associated with it.  By making the step function action-based users can just skip a step!

 

Another usability change I would like to make is to add an “exit” button to the progress tracker in the Remix process.  While users can press the stop playing button that carries over from the “play and explore” interface, since the interfaces are the same, it would be easier if there was a clear “exit Remix” button on the progress tracker.  And perhaps we could consider not having these two things have the same interface?  Like removing the remix progress tracker when a user isn’t actually remixing, or removing the stop playing button when a user is actually remixing….Just a thought that occurred.

 

 

The progress tracker in Remix

 

 

Tutorial Stuff:

The tutorials will be based off of actions that a user remixes.  So, for every action a user remixes, the user can go through a tutorial that will show them how to recreate that action.  For any aspect of Looking Glass (Action ordering boxes, functions, procedures, adding details, creating methods, etc.) there are varying skill levels, and the material in the tutorials will reflect these different levels.  If a user has never created a method, if they need to create one in a tutorial, it will walk them through every step.  And likewise, if they are familiar with it, the tutorial will just tell them to create one and then move onto the next step in the tutorial process.

I went through a couple different places to put the tutorials, but ended up on the decision to put a button at the top of the Methods Panel, by the Challenge, Share and Remix buttons.  I thought that having it up there with the other “Actions you can do in Looking Glass” buttons seemed like a logical place.  Another location could be in the Open World pane, and add a tab for tutorials.

Location of Tutorials pane:

I figured the tutorials dialogue box would look something like this:

It would have a spot to choose a world, and a sort option. Then I also thought it would be useful to add a Preview spot, and a spot where the full description is given.

Another idea regarding this process was which actions to make tutorials out of.  At first I thought to just make any action a user remixes available as a tutorial, but maybe they’d end up with an annoying amount of useless ones that would just clog up the list of tutorials and make it so they couldn’t find the tutorial they were actually looking for.  So the solution I came up with was giving users the option to make an action into a tutorial when they remix it. So, the best place I thought to put this option was in the final dialogue box to the remix process, where users name their action and cast characters.

Like so:

Closeup:

There are five different levels of “difficulty”, that is, five different skill levels for the tutorials.  The level will be based on the badges you earn, but I also wanted to make it a little independent as well by having the users need to use an action several times per level to reach the next one. (and not just level up because they got the badge for it, but have both the badge and multiple usages as requirements).

The levels are: beginner, intermediate, advanced, expert, and pro.  Descriptions of each level are as follows:

Beginner:  The user has never seen and never used that aspect of Looking Glass.  There has been no use of the actual code, in Remix or on their own.  So if someone was a Beginner in Do togethers, the tutorial would tell the user where it’s located, how to use it, and afterwards explain what a do together is.

Given this as an action someone remixed:



An example run through at Beginner levels:

Intermediate:  The user has seen said actions, and maybe grabbed it in a remix, but hasn’t actually manipulated the code themselves.  At this level, the tutorial will still tell the user where to find do togethers, but it won’t give them a definition, as they probably already know it by this level.

An example run through at Intermediate levels:

Advanced:  The user is familiar with the aspect, and knows where to find it.  They are more familiar with adding details, and changing inputs on actions like say, turn, etc.  They have remixed it, and maybe modified the action before, but haven’t created one themselves.

An example run through at Advanced levels:

Expert:  They had no help from tutorials or Remix, and created basic versions of this aspect by themselves.  This is the first level that users are given pre-created lines of code to drag into tutorials, since doing these would be tedious as they are already quite familiar with these concepts. (For example, a user could be given a line of code that already has a function assigned, a duration, etc.)  I also thought of getting rid of the stencil-cutout version of the tutorial at this level and up, to give users more freedom to choose what actions they want to do.  They are given the correct tools and code blocks to recreate the action, but maybe they want to change it a bit, or add something else, so they are given a layout where they can still edit anything they want.

An example run through at Expert levels:

Pro:  At this level, users are very familiar with the aspect.  They’ve created it themselves several times, and with varying levels of difficulty. (Like Reily’s badges, ex: nested loops, multiple details, custom variables, etc.)  This level also uses the “stencil-free” version of the tutorials, and users are given larger code blocks, instead of just lines of code.  It would break the methods up into manageable blocks that users could put in place.

An example run through at Pro levels:

Yes, I did accidentally skip using five....figured you still get the idea.

The way I’ve presented this makes it seem like there is only one broad skill level a user can be on, but I think it would be better to have each aspect have its own skill level.  So a user can be an Expert in the count action, a Pro in do togethers, and a Beginner in variables all at the same time.  I made an example of this, where a user is familiar with do togethers and do in orders, but isn’t very practiced with adding details.

Here’s that example:

Etc........


Another thing I thought of adding, but wasn’t sure where to put, was some sort of reward for adding comments to your code.  When going through the Remix process, one of the problems faced by kids unable to find the correct code was poorly named methods.  By giving the users some sort of prize, or experience points, or something of the like, when they add comments to their code, explaining what certain points do, perhaps the code can become easier for other users to understand.  Could be a possible solution to the poorly named methods problem.