Proposal

1) The Project:

Looking Glass is an IDE that allows users to reuse code written by other users. This occurs through a remix process where users can capture a particular animation from a different world and then Looking Glass will generate a tutorial to assist the users in implementing the code in their own world. The Looking Glass Community website currently displays information that shows one world has been remixed into another. To figure out what has been reused, a user has to view both worlds and do a comparison. However, a single world may contain multiple animations , each remixed into multiple different worlds. Looking Glass does not offer any way to track a single animation through all of its changes without examining all of the associated remixed worlds.

This summer, I hope to develop an interface and visualization that will allow users to more easily discern which sections of code or animations have been remixed. This will enable users to track the evolution of a particular component and its uses in a variety of applications. For example, if world 1 contains animations A, B, and C. Then the interface will allow a user to just follow animations remixed from 1A without having to sort through those from 1B and 1C. I believe that by providing an engaging visualization of the reuse history, users will be interested in exploring the code and discovering how it can be changed to suit the needs of their own programs. This visualization needs to be able to show the connections between the parent animations and each of their children animations. It could also provide a way for users to compare the physical code to better understand how changes in the code result in changes in the animation.

2) The Significance:

The addition of this feature to the Looking Glass Community website offers users another way to learn how to program. As it is currently, users learn about code through the process of emulation and trial-and-error. Users see a world with an animation they think is useful and can copy it into their own world. There are other people in the group working on developing a tutorial system to make the remix process more interactive and thought-provoking when users are remixing something. The visualization of the reuse history will hopefully show users how a single animation can be used in a variety of contexts.

A user can explore an animation from one world and see how it was altered from an animation in another world. Going in the other direction, a user can see all of the children animations of a particular animation. For example, a handstand can be changed into a variety of other animations, say handstand push-ups, a front flip, and a swan dive. The interface would facilitate the identification of these alterations because a user could see the direct relationship between the handstand in one world and the swan dive in the other. This will become more and more useful as users of Looking Glass gain experience. As they explore and build worlds that can contain a multitude of animations, they can track a single animation through all of its changes.

For beginning users of Looking Glass, being able to see how an animation has been altered may provide a sense of achievement when they see how other people have taken something they made and changed it into something new or unique. They can also look for inspiration in the evolution of the animation. For example, if a user is attempting to remix an animation into something new but gets stuck, they can examine the code’s children and find out what things other people have created from the same section of code.

One additional thing I was thinking of adding would be providing users with a library of their own remixes. This library can contain the many animations that they have appropriated over the course of their time on Looking Glass. It can serve as a collection of sources they can take from to put in whatever new world they are building. For example, if they have previously remixed a backflip, but still have difficulty creating the code on their own, they can easily find this remix in their library of animations and remix the animation into a new world again.

3) The How:

In deciding where to put this visualization, I thought it would be best if it goes under worlds as a page on the secondary bar that can appear beneath the primary bar. This connects the animations to the worlds themselves, so that they are not lost on the website. This can lead you to a general exploration page of remixes, perhaps to the animation library that was mentioned earlier.

Library.png*

The animation library could be something fairly simple where users can just store worlds that they see potential in remixing and their remixed animations. During the remix process, users have to name the animation, so the library could be organized by name or by the date they were remixed, etc. To appeal to the user visually, I imagined the library would be a bookcase where each “book” was a single remix or perhaps a world that contains a set of animations that are potential remixes. This would allow users to “browse” the collection and then selecting a “book” would bring up that world or remix. If a world was selected, then the website would show the animations that have been selected from that world. If a remix was selected, then the website would show the children animations of that particular remix. Clicking on one of the animations at the bottom will lead to the actual interface where the path of animations can been seen.

The basic things that the interface needs to see the reuse paths are the current animation, the parent of the current animation, and the children of the current animation. It would be most intuitive if these progressed from left-to-right, top-to-bottom because the English language follows the same rules. Thus, on the left should be the parent animations, in the middle is the current animation, and the children animations are beneath that.

Interface.png*

The interface is very straight-forward and can definitely be modified to make it more user-friendly and engaging. The parent animations on the left are organized such that each clip is the parent of the one below it, so if you click through from bottom-to-top, you can see all of the videos up to the person who originally wrote the code that was remixed. It follows that the current animation in the middle is the child of the clip at the bottom of the stack on the left. This is where the animation can be played paused, etc. Beneath this current animation are all of the animations that have reused code from within that particular clip.

If the user selects one of the children animations from the bottom, the animation in the middle will tack itself onto the bottom of the stack on the left. The selected animation will go to the middle, and all of its children animations will appear in the section on the bottom. On the other hand, if the user selects one of the parent animations from the left, the section on the bottom will refresh with all of the children animation of the selected animation, including the animation that was in the middle. The selected animation will appear in the middle and be removed from the bottom of the stack at the left. The children animations can be organized by the number of remixes that branch from each animation. This promotes worlds that other users have found useful and have remixed already.

This is what I how I currently envision the project going this summer. If everything works smoothly, this would be the point to have user testing to see if the feature works as I imagine it. From there, I could modify it to make it more user-friendly based on information from user testing. However, to get there requires one thing to happen still, which is the tagging of the AST nodes. It is a far more complicated process than it sounds because of the large code base we are working with and the trickiness of the classes that build the AST nodes themselves. I believe that getting the nodes built properly so that we have all the necessary information for the community website to put things in order will account for a majority of the difficulty of the project. However, once that is accomplished, I will be working on the community website building the web pages that I need to display this information. The sketches shown above will be the basis of the end user's visualizations. 

*Still having trouble with uploading images from files. The ones shown are uploaded to the wiki and then linked to the url.