My first week at Washington University involved a lot of orientation, to the city, the University and to the Looking Glass project. After a welcome to all of the REU students, I began to get acquainted with the Looking Glass software by creating my own story. Looking Glass is a programming learning tool that allows you to choose place characters and objects into a scene, and then create a story or a game using tools based on programming skills, such as loops and events. By doing this, I learned how the tool works and the kinds of ideas Looking Glass helps to teach.
The next step was becoming oriented to Looking Glass' code. In terms of the overall project, one of the goals is to make it easy for users to share their projects online so that other users can download them and reuse parts for their own projects in order to help them learn new skills. I was given the task to create a button in the Menu of Looking Glass that would give users an easy way to share their project. In order to do this, I first spent time thinking about what the dialog box for this function should look like.
Beyond the necessary fields such as username, password and title, but there were questions about which other fields would be the most useful and relevant. Because we will want to categorize projects on the website, there needed to be some way to group or label the project. I thought there should also be a description of it. After much thought, the description box was changed into "Director's Notes," "Special Features," and "Instructions" sections, with Instructions only existing if there are events to explain how to play. The Special Features section was created with the idea that a user may be especially proud of something they were able to make a character do and would want to share it. Other users might look at the special features and want to learn those, because they may have been the most challenging to create. An Acknowledgements section was also added, as the reuse system may cause kids to feel like others are stealing their work. However, if there is an "Acknowledgements" section on the share dialog, they may be more likely to thank those whose works they have used.
After a paper prototype was created, I began to code the button and dialog box into Looking Glass. At the beginning, this involved a lot of time spent tracing through Java classes to determine what a piece of code does and where it comes from, since there are other buttons with dialog boxes within Looking Glass that I was able to learn from and explore. A better understanding of eclipse's debugger definitely helped me do this more efficiently. Since I have not worked on a project this big, or one involving a user interface before, the were many things to learn from the code that already exists for Looking Glass.
The overall task was to create the dialog box so that the information received from the text fields could be used in the website to share the user's work with others. There were other components of the dialog box that were also important, though. For example, the OK button needs to be disabled if a user has not entered their username, password, and a title. This involved adding event listeners, which was something I have not worked with before. Once I got them working, though, it was simple to only allow a certain number of characters in the text fields, and only allow a certain type of file for the photo upload.
Another challenging aspect was adding the instruction text field only if events exist in the project, such as "move camera with mouse" or another event that happens with a mouse click or button press.
This is the working model of the Share dialog box. Though significant thought went into choosing the fields, I think that some areas, like the tags, groups and notes would need further study based on usage on the website. For example, if there were something that a lot of users were writing about in the notes, that could become it's own text field, or if there were fields that few users filled in, those could be removed in order to shorten the dialog box. I added the photo upload option, even though each story has a default screen shot, in case users wanted to use a different photo to represent their project. However, this may require some monitoring of photo submissions and also may lead to uploads of photos that are not related to the project and do not help other users to get an idea of what the story or game is about.
For my project, I would like to work on the community within looking glass, focusing on adapting the current Layout of the IDE in order to facilitate easy to find and clear logging in/out, as well as the ability to share a world, get help on a world and find inspiration. Within this, I am most interested in focusing on the help feature and reworking the IDE in order to fit accommodate these features. These are the ideas Alexis and I came up with for the interface and my ideas on the help feature:
The two main changes to the layout would be adding a login/log out button at the top right of each screen and adding a Community Panel. Once a user is logged into the system, they can share, ask questions and get inspiration from the community or "Tea Party" panel, on the right side. This panel can be hidden if the user does not want to use it, or popped out if they choose to share, get help or get inspiration. The Tea party panel has 3 tabs, one for of these purposes. The dialog box from the share button would then be moved from the file menu to the community panel. Having these three community features in one place makes sense to me, since they would be easy to find and use, but also possible to ignore if a user does not need them at that point and wants to focus on their own project.
I think it is important for a user to be able to get help within looking glass. There are four different cases when a user would turn to the help feature within looking glass: 1. They need help and would like to submit their unfinished world to other users along with a question. 2. A user feels confident in their abilities and would like to assist another user, so they go there to find users that need help. 3. Advice for their problem has been given and they want to see the advice and world in order to get a tutorial of how to do it. 4. A user does not want to submit their world to other users, but wants to check to see if anyone else has ever had their problem and received a solution.
1. The Advice Asker: When a user wants to submit their work for advice, they need to be able to select the lines that they want help with, so that the user giving help can quickly find the problem area. They also should be able to input text describing what they want those lines of code to do. 2. The Advice Giver: The user who chooses to give advice picks that option from the menu and then is given several problems users have in areas that they have already mastered. The problems that do not currently have "accepted answers" are given priority in these views. If the user does not want to or know how to fix these problems, they can click a button to view different problems. The advice giver then chooses one to help with, at which point they can open the file and view the question. The world shows which lines the Asker has selected. The giver can then play with the world to get it to do what the Asker requested, as well as write a written response to answer any of the Asker's questions. When they have completed it, submitting will send the edited world as well as the response back to the Asker. The Giver could receive participation credit for helping another user, if the Asker deems that the advice was helpful. 3. The Advice Viewer: When advice for a problem is received, the advice section will blink, or somehow else alert the user that their question has been answered. The user can then open the hopefully fixed world and view the advice given. The user would also be able to view a tutorial then for the working world. After viewing it, the user can select whether or not the solution answered their question. If it did, the question will be removed from the open questions that people can solve, and moved to the solved problems section, which would show up in searches. Furthermore, it could suggest acknowledging the Advice Giver as someone who helped make the world a success. If it is not solved, its priority remains the same as an unsolved problem. 4. The Advice Searcher: This user does not want advice from other users, but would like to see if the solution is already in the database. They search for key words and are presented with similar problems that have already been solved, of which they can view the problem description, the solution text and the solution video.
These features need to be created in Looking Glass, but there are also a lot of connections that need to be made with the website and the databases used for the online Looking Glass community. Some of this also depends on the Meta work, as problems should only be suggested to Advice Givers that have more knowledge and experience, as deemed by the skills they have already learned.
After presenting our proposals, we began the task of prototyping our ideas, both using paper and Inkscape. Alexis and I are working collaboratively on the Looking Glass interface, attempting to figure out the best way to add the community into the application.
After much thought, we thought of two possible ways to add in the share, help and inspire functions.
One of these ways was to add a panel on the right side that could be hidden if desired. It would have drawers that a user could open to see the different sections next to what they are working on coding. When they are done using it, they can hide it. A second way to implement this would be to add all of the features to the top menu bar. Share already exists in this form in the "File" menu, but we could add a community menu that includes sharing and inspiration. In this model, obtaining help would be a part of the help menu, in order to make it clear where to find it. We see pros and cons to both of the models. For the panel, it is definitely much more prominent than the menus. A user would see it immediately when they start the program and might be more likely to use it, because they are more aware of it. Furthermore, there are some parts where it would be useful to have it open at the same time the user is also viewing their code, which this makes possible. However, when it is open, on a very small screen, it makes it look very crowded. A new user might be overwhelmed by all of the different things on the screen. If these functions were in menus instead, they would be out of the way. A user could choose to open them if they want to, and then close them when they are done. However, a user who does not know they are there or is not looking might never find them. Users might not expect the help menu to have the function that allows them to actually ask another user for help; other help functions are often less helpful, so users do not actually go to that menu for help.
Another issue we need to address with these added features is where and when the user needs to, or can, log in. Having to log in separately for each of the features does not make sense, so we were thinking that having a log in page when the program is opened makes more sense. However, if they choose to not log in at that time, they also need the option of logging in later. Also, if they do not have a username/password, they should have the option of registering as a user in order to use the options.
We are now working on thinking of use cases in order to determine the best way to add the community to Looking Glass. Hopefully use cases will make it clear which of the prototypes is best!
After about a week of various forms of prototyping and many discussions about both the interface and its interactions with the website, Alexis and I are now delving into the java code to start the beginnings of our project.
Though we oscillated between the pop up windows and the side menu for much of the discussions, our ideas on where and how to log in were really the deciding factor. Rather than having the program ask or advise a user to log in at every stage of the process, we decided on two main log in areas: when the user first opens the program and when they want to use the community panel. We thought that it would be useful to have it at the beginning so a user could be logged in and then automatically have all of their information show up. Alternatively, if they decide to not log in at that point, then they would realize when they attempt to see their scrapbook or help responses, that they cannot do so until they log in. If each of the functions were in their own separate pop out windows, you would need to have the option of logging in at any of those points, which we thought would get annoying for a user.
Once we made these decisions, we were able to move into the beginnings of coding. My task was to create the side panel and make it snap in and out by clicking a button (pictures to come..). I then started to look at how the other menus in Looking Glass work and how to integrate them into the community panel. Though the class for the split pane in Looking Glass works, the buttons to minimize or maximize it are very small and at the top. I would like to change this to make the buttons bigger and in a more clear location. Then, the menus can begin to be filled in, after our designs are confirmed, of course.
Brainstorming and thinking of new ideas are often thought of as simple and maybe even easy, but I definitely find this part of the process challenging. It's like writing an essay and then trying to edit it- I've always found this kind of difficult because I originally wrote those words, so why would I want to change them later? Though I hate that this always pops into my head, I always remember how much my tenth grade
English teacher said that "the more you revise, your grades will rise." In that competitive English class, grades were the focus, but in reality, I do believe that revising helps you to think more about original ideas, refine them, and eventually end up with the highest quality writing, idea, prototype or product. Similarly, my first computer science professor freshman year couldn't stop talking about how you should be thinking about what you're going to code twice as long as you're actually coding (and before you start coding, of course), or else you'll often be coding and debugging and re-doing things for much longer.
Obviously many smart people have taught me that brainstorming, revising and thinking are important prerequisites to great works, but I don't think that makes it any easier of a process. Alexis and I have worked through several different models of how the community could be integrated into the IDE: buttons in the top menu that create pop-up windows, an icon in the scene editor that pops out a menu, and a side panel that can pop in and out. At the end of last week, we had also struggled with where the log in feature should appear. We came to the conclusion that the user should not need to log in at every step of the way. In order to accomplish this, all of the community features need to be consolidated into one area that requires the user to log in. This seemed to point to the side panel.
Originally, we had not included the side panel in the mode where the user is watching their video. I realized that this is a problem, since this is the place where the user would originally discover that they need help. I also wasn't sure how to encourage help users to choose the lines they need help with. If it is an option, in many cases, the user probably wouldn't select the lines, since it is an extra step, or they might just not realize that they should or how to do so. I then began to think about the fact that a user who would be giving help (answering a submitted question) would not go to the "help" section, as in most cases, only someone who needs help would click on a help button. This resulted in some conflicts in my design, since I had included all of the help features in one area.
These issues with having all of the help features in the side panel forced me to think if there is a better way of doing it. I started to think if selecting the lines in either the run mode or the scene editor could be a way of asking for help. For example, a user plays their movie by clicking run. As it's playing, they realize something doesn't work right and they don't know how to fix it. If they could just select the lines right there with the mouse and then click on a help button that pops up, it would be more immediate than going to a help menu, finding what you want, writing your problem and then having to select the lines that were the problem. By that time, who even remembers which ones they were? More users might actually attach the correct lines if that is the first step in the process, perhaps.
In this model, searching for help can be found in the top menu bar, as this could possibly be the most natural place for someone to search for help. I figured having an ask for help feature in that help menu as well, meaning that you could either initiate the "ask for help" feature either in the scene editor/run mode or by clicking on it from the menu makes sense.
Coming back to the problem of what to do with what I previously called "give help," I stared to try to think of use cases where a user in looking glass would want to use this feature or where they might find it and choose to use it. I had a really hard time with this, since, in theory, a user would normally open the program to play with it if they are a beginner, or with a specific purpose of making a movie or game if they are a more experienced user. In either case, they are thinking about their own work, not really thinking about helping others. It seems like users would more commonly use this function from the website, rather than the IDE. On the website, users are thinking about interacting with the community, so they are more likely to see the help section and go there to answer questions that they know the answer to. Furthermore, their would be more space for browsing, so they could view more questions at the same time and choose the ones they know how to help with.
And the brainstorming continues
On the east coast, St. Louis isn't really considered the top summer destination. As everyone figured out their summer plans, many Tufts students decided to stay in the area, go home, or go to France, while I figured out my flight and housing in St. Louis. I didn't really know anything about the city before I came here, and though I wish I had brought a car, I have really enjoyed my time here so far! Exploring a new city is always fun, and St. Louis really makes it affordable, since so many of the events and "tourist attraction" sort of places are free or very cheap.
One weekend, we visited the Gateway Arch, which is right on the bank of the Mississippi River. You can travel up the arch for a small fee and look out over the landscape from 633 feet in the air. I visited the St. Louis zoo, which is in Forest Park right next to the university (along with an art museum and a history museum) and has a huge variety of animals. St. Louis also has runs free showings of a Shakespeare play in the park every summer. This year it was a 50s version of Taming of the Shrew, which I ended up seeing and enjoying twice! One of these times, we went with our whole lab and all brought food for a great picnic before the show. I also went floating, or canoeing, down the Current river a few hours southwest of St. Louis. Though we had to wake up before sunrise for the drive, it was definitely worth it! This past weekend was split between Marine Week and the Pride Festival, both of which were big events in St. Louis and a lot of fun. I've also been playing ultimate frisbee weekly as a part of the St. Louis Ultimate Summer league, so I definitely haven't been bored this summer, neither in nor outside the lab!
Though I spent time brainstorming new ideas of how to approach "help" in looking glass, I did not arrive at many new conclusions. However, I did think the process was very helpful in thinking of different cases and possibilities. One main idea that did result from brainstorming was the idea that the help should be available while the video is being played. This is one of the crucial times when a user plays the video and the result is not what they expected and would want to ask for help. I also spent time prototyping the selection feature, so that users can select lines of code and be prompted to ask for help for them.
Jumping off of these ideas, I have begun to program the community panel, adding the text boxes and buttons to ask for help, search for help and view help responses. I am now confident that these options should be available alongside of the code a user is working on, so that they can select the lines they want help with and ask the question as they are looking at it. Though I now have the interface of this process working, little more could be done with it until I was able to connect it to the database in order to actually submit questions and search for help questions. For the weeks leading up to this point, the database was mostly a hypothetical thing, like an oracle of sorts, that can magically be asked or told anything and would work. However, with the progress being made in both the IDE and the website, the time where we would actually require the database to move forward was quickly approaching. Though the database had been in early design stages, we really needed to meet as a whole group in order to ensure that it fulfills the needs of everyone working on the community features (all of the REUs, basically).
At the same time, we also needed a way to logically connect the IDE to the database. In order to protect this process from the problems caused by new versions of the database and old versions of the IDE, we decided to create an API to make this communication smooth and robust. Though we were able to get information from the database to the IDE, going the other direction is more complicated on the rails side. Since I have been able to get it working in Java going in both directions, Alexis and I will be able to continue with our work, pulling from a stand-in database until we determine the best way to create the API in rails. Though it would be even better to have it all finished so we could actually communicate directly with the website database right away, at least we can move forward with our work for now (and I know a lot more about APIs than I did before)!
As the week of 100-degree temperatures begins, I also realized that I only have a few more weeks to finish up my work in looking glass, which is both scary and sad (though I'm not quite sure I will ever miss this combination of heat and humidity..).
During the past week, I began to work through the prototypes of the help section and really begin to make them function in Looking Glass itself. It really is a fun process to see prototypes come to life. I'm really hoping we will also be able to see how the prototypes function in user testing (maybe in August..). However, I'm also not sure how that would even work, since I don't think a brand-new user of Looking Glass would be invested enough to seek out serious help. I imagine the help tool being used by more mid-level users who have goals and are seeking to accomplish a specific task, which is hard to user-test with kids who most likely have never seen Looking Glass before.
After accomplishing some of the implementation of the prototype, I started working on how to allow users to actually select the lines of code they want help with. This is challenging both technically, in accomplishing this within the constraints of the Looking Glass software, as well as in theory, as there are still questions as to whether the feature would actually be used, and how. It is definitely a challenging endeavor on both accounts, but I really feel like I am making progress in understanding how the code works and how to accomplish what I want to do.
In other news, though I may never completely enjoy this climate, I have definitely adapted to some degree, or at least enough to go horseback riding at noon during a heat wave and have a great time. And, even if getting up early isn't always the greatest, it allows us to walk the mile to work in a slightly lower temperature, so it's definitely worth it.
Well, we aren't actually finishing up quite yet, but it already feels like we're short on time with a lot left to do.
Over the last week, I spent a lot of time with our Abstract Syntax Tree. It holds the lines of code that make up a world, or the animated movie created in Looking Glass. In order to allow users to select the lines of code they want help with, I had to delve into this tree in order to find all of the lines between the beginning and ending points and select them. This was not an easy task. There are block statements and user-created methods. Beyond that, there was the problem of maintaining the selection when a world is saved so that a user opening it to give advice can see and change the selection. Another necessary functionality was that users should only be allowed to select a begin point and an end point, so that the lines in the middle will be highlighted. None of these tasks turned out to be trivial, but in the end, line selection by right clicking on two lines as the beginning and end works!
The remaining missing link in the Looking Glass Community is the connection between the IDE and the website. The plan is for this to be done using an API, which we have yet to create, but Alexis and I are definitely eager to get started on it so we can change the IDE-website connection from hypothetical to real!
Friday is the Research Symposium for all REU students in the CS department for the summer, at which I will be giving a talk, with the title of this blog post. Beginning to prepare for the talk, as well as beginning to write the paper for DREU has really brought my work this summer into focus.
The Problem:
Going back to my proposal from the beginning of the summer, I realized I never really did flesh out the problem that I am working to solve. I wrote one sentence describing my purpose for the summer:
"I think it is important for a user to be able to get help within looking glass."
Not the most well thought out statement, to say the least. Greater thought about the overarching goals of Looking Glass made me realize how important a help system truly is in this context. Looking Glass, though used in schools and camps, is designed to be able to be used by an unexperienced and independent learner, often without the support networks that classrooms provide. In this context, in order to keep users engaged beyond the roadblocks they hit when they can't figure something out, it is especially crucial to have a help system that gives users effective and useful help.
The (Possible) Solution:
A community-based help system integrated into the programming environment. In lieu of a help forum where users must go to a website and can only ask textual questions and receive textual responses, this system exists in the environment where the user determines that they have a problem. Along with a description of their question, users can select the lines of code that they would like assistance with. When another user looks at the question to answer it, they can open the project, see the highlighted lines, change the lines to do the correct operation, and then send the code back the the user who requested help. The hope is that users requesting help would receive better information in order to move beyond sticking points and continue to use Looking Glass in order to further their programming learning.
Stay tuned for my presentation and paper...
Friday of last week was the REU symposium, at which Mark and I both spoke about our summer research and many students presented posters at the poster session. After working on my talk for most of the week and presenting it three different times to the lab, I definitely felt much better about it than when I started, but that didn't stop me from being nervous anyway!
Since it was my last weekend in St. Louis, it was a busy one, doing those last couple of things that shouldn't be missed: the City Museum, the Soulard Farmer's Market, and the Missouri Botanic Gardens. The weather has finally mellowed out a little bit, making walking around outside slightly more enjoyable than the past few weeks. The city museum, which is basically a huge jungle gym big enough for adults, was definitely my favorite thing that I've done in St. Louis and the botanic gardens were beautiful!
With the talk out of the way, I began to focus this week on building the API and connecting it with the online community and the Looking Glass program. It's really exciting for me to see the project come together- I can now type in a question in the ask for help section and it is sent to the database, where it is available as a question that needs to be answered. Having Looking Glass communicate with the database through the API such that community exists both in Looking Glass and online really makes it feel like we accomplished something significant this summer (even if Looking Glass and the website may still be a ways off from being released..). It has also been interesting working on the API, since I knew essentially nothing about how APIs worked before this and now have a much better understanding of how they work and all of the different pieces necessary to build one.
Halfway through my last week here, I've begun to look back on the summer and realize all of the things I've accomplished in the lab, as well as all of the fun things I've done away from the computer. I have definitely learned a lot, and really enjoyed working in the Looking Glass lab this summer!
Week 6: July 5-11
Week 7: July 12- 18
Week 8: July 19- 25
Week 9: July 29- August 1
Week 10: August 2- 9