API TUTOR

Sameer Bajaj:Paper prototype for navigation in API Tutor and setting up modules. Daniel Brenners: Paper prototype for the interactive API page and reflections on the prototyping process. Dina Bseiso: I’m responsible for the storyboards drawn and elaborated on below, as well as the Landing

Page prototype. Jordan Kellerstrass: Paper prototype for playground module

Brainstorming Session. Date: Thursday, October 8th 2015 Duration: Two hours Attendance: Entire group Personas

Jo

Jo is a 12­year­old boy in middle­school, and his access to technology is moderate. He has a smart­phone, and shares a home computer. His parents disallow Facebook usage. He doesn’t have any coding experience; however, he loves videogames and aspires to be a videogame designer when he grows up, as well as a DJ due to his love for music. Jo is a quick learner, and is considerably tech­savvy, resolving issues with technology at home when they arise. Jo is more interested in experimenting and challenging possibilities than the look or design of experiences and products. With regard to school performance, Jo gets good grades and is a slow reader. He is not actively dedicated to activism, but cares deeply about animals. This care may be influenced by his pet golden retriever, Rufus.

Brittany

Brittany is a 16­year­old highschooler, very prominent on social media sites due to her high­access to technology via her iPhone and personal laptop. At a younger age, she used to be an avid videogamer; however, due to her recent involvement in the mock­trial team, badminton team, summer­internships (and general school attendance when it isn’t summer), videogaming has fallen to the wayside. She is also involved in theater productions, as well as recreational photography, owning a DSLR camera of her own. Brittany considers herself to be an activist in civil rights, attending events when she can with her camera, and maintaining her blog through tumblr; despite this exposure to customizable HTML/CSS layouts, she is not much of a coder. And while she likes pretty things, she would sacrifice beauty for conveying the truth. Brittany comes from an immigrant family, but she was born in the United States herself. She gets decent grades, is a fast reader, and loves pop music.

Chris

Chris is a 17­year­old senior in high school living in the suburbs, ambivalent about furthering his education. He thinks school is a waste of time, yet despite this he achieves high marks in math. He prefers to spend time on his own projects, such as building videogames inspired by games he has played and enjoyed (or hated). Some of these games he has posted online for purchase, hoping that these steps will assist him in becoming the next Zuckerberg. Although he has this high goal, he has low self­esteem, and his social net is small, composed of but a couple close friends he has known since elementary school. Chris also has little patience, and this manifests in his introversion. While recognizing that social activism issues are important, he isn’t particularly concerned with social activism personally unless there is a monetary gain.

Storyboards of Tasks Our System will Support

Jo has yet to learn how to keep a tidy workspace, both on­ and offline. Being newly introduced to the world of programming, he has yet to experience the woes of a cluttered and disorganized workspace. His curiosity of API Tutor compels him to give it a try, and to his surprise a new window pops up once he clicks on a module, acquainting him with a tidy workspace consistent across all API Tutor modules. The hope of this walkthrough is to instill good work­space practices that will carry on beyond the use of API Tutor.

Brittany is a busy girl. In addition to her classes, she’s involved in maintaining a civil rights blog for the school’s journalism program. The program believes the blog may benefit by having on its page tweets from various civil rights activists. Brittany has no idea how to go about doing this. In running a search in how she may be able to pull data and various stats associated with a Twitter account, she stumbles across API Tutor’s Twitter module, which introduces her to what the Twitter API can do.

Chris and his friends like to experiment with code, and the potential of coding knowledge, to do cool things. One day, one of Chris’s friends proposes that they attempt to join the capabilities of multiple APIs together, quickly and easily. They have a working knowledge of APIs, and believe that they can surely combine them, but to do so quickly is in question. Chris navigates to API Tutor to see if there exists a module that may recommend a method to combine multiple APIs in a way that makes sense, and quickly. He discovers the API Playground, which allows him to do just that, exposing to him the code that he can use as his skeleton to accomplish their next experiment. He’s excited about the prospect of posting their results to his blog, as posting cool projects may earn him more fame in his ultimate goal of becoming the next Zuckerberg.

Low­Fidelity Prototypes

Navigation and module setup in API Tutor

Playground Module

Reflection on Prototyping In starting to prototype, there was a vague idea of the information architecture and general layout of the application. This made it easy to shape the outline of the basic prototypes. We were able to quickly come up with some ideas of how the larger parts of the page would fit together or were in relationship to each other. Some of this was informed from our contextual inquiry, such as the “left/right” distinction of code and output. Other pages, such as the landing page, were drawn from websites that we felt were organized well and could present the information we were trying to convey in a clear and concise way. In general, it was fun to finally see our research materialize in an actual “thing” that could eventually be our working application. One of the difficult aspects of the prototyping was that it forced us to think about the smaller interactions that the user would use to navigate through the application. When thinking globally, it was easier to separate modules spatially on the page, but when it came down to thinking of how users would interact within these modules, it was more difficult to discern. For instance, would we use a familiar horizontally arranged tab­like interface or vertically expanding sections in the code module? Which one conveyed a sense of temporal progression through each step? It is difficult to know for certain without delivering the prototype to our target user group. The most difficult part of the prototyping was deciding how the users would input the code. While some of the previous examples were partly aesthetic in nature, this particular interaction is core to how users learn with our application. An interface that required users to drag and drop pre­coded blocks might be more engaging, but would lack some of the intellectual rigor required to learn the material. By typing the code from scratch, users may learn the material much better, but only if it was done in such a way as to not be intimidating. It’s not necessary to figure out exactly how this will be done, but prototyping forced us to think critically and early about this interaction that is central to the success of the product.