1 Tracking Student Participation in Large Classes User Testing Team Members: Danny Garfield Timothy Kou (Nai-Shu Kou) Emma Miller Erez Morag Michael Vo Sponsor: Stephen Arnold Computer Science 160, Fall 2005 University of California, Berkeley2 Table of Contents 1. Study Proposal ...........................................................................3 a. Objective ..........................................................................3 b. Description of System Being Tested................................3 c. Task Environment and Materials .....................................3 d. Methodology....................................................................4 e. Tasks ................................................................................5 f. Test Measures...................................................................5 2. Study Report...............................................................................6 a. Test #1..............................................................................6 b. Test #2..............................................................................7 3. Changes.......................................................................................8 a. After Test #1 ....................................................................8 b. After Test #2 ....................................................................9 4. Observations.............................................................................10 a. Test #1............................................................................10 b. Test #2............................................................................103 1. Study Proposal a) Objective Our primary goal in the usability study is to make sure that our program is easy to use. Specifically, our software should be extremely unintrusive, so as to make the grading of participants as easy as possible. The more concentration it takes to use our program, the more it hinders an instructor during class. Secondly, our program should be as close as possible to the natural process that involves a student raising his or her hand and being called on. Our program should encourage the choosing of people who volunteer less often. Otherwise, our program should allow the instructor to choose the students in whichever other way he desires. It should make the implicit process of choosing a sort order a little more explicit. b) Description of System Being Tested We will be testing the instructor’s side of our software and hardware. We are testing: the input screen, used to grade people in class; the results screen, which yields the final numbers outside of a classroom setting; and the graph screen, which displays results visually. Also, we will be testing the remote control function in conjunction with this software. The user for the part of the system we are testing is the instructor of any large class of students, for any subject. The students’ end of the system, at the moment, is just a single button; this side will not be tested in this phase of development. c) Task Environment and Materials We intend to perform our user testing in the privacy of the instructor’s office. We will be using a paper-based lo-fi prototype, and thus will not need to be using the instructor’s computer, or any of his or her own tools. The lo-fi prototype consists of a set of previously drawn screens and cut out buttons and labels. One member of our team will function as the computer and make the system “work”. The remote control will be implemented only as a picture of a remote control, a box with a single button. The instructor can simply tap this paper to “click” the button.4 d) Methodology To introduce our project, we will first go through the actual intentions of our system, the problems we intend to solve. Our goals are both: to provide a larger equity to the order in which students are picked and to make the actual tracking of participation points easier and take as little additional out-of-class time as possible. We will then describe exactly how one use of our system is intended to work. We will describe the process of the instructor clicking his button to flag the system for question responses, and how the students “raise their hands”. Then, we describe how the instructor should call on and grade a student. Finally, we describe the differences between a question response and a spontaneous volunteer. We do all of this without displaying any of our actual prototype or screens, just to describe the system’s somewhat original use. There will be no training before the actual testing on our software. If we explain the broader process we are trying to accomplish, there should be no actual software testing needed. We will be testing as if this is a user’s first use of a product, out of a box. This user would know only what the product is intended to do. One of our group members will be asking our user to perform a series of tasks. Another member will function as the computer, making our lo-fi prototype “work”. One more student will function as the “students” of the class. Because our system has somewhat a mind of its own, because of student input, this member will simulate student input. He will volunteer and respond to the instructor’s questions. The conclusion of our testing will be more of an open discussion. Here, we will be asking for clarification of any notes we have taken throughout the rest of the session. When we have clarified everything we need, we’ll conclude with a more open question. We will ask the instructor forthright if there’s anything they think might be changed or added to our system. We will conclude by thanking the instructor for their time, and assure them that their input was valuable. We will be sure to mention one specific thing we have gleaned from our interview, and mention that it will help. All information will be recorded free-form, on notebook paper. At the conclusion of the interview, our team will meet to coordinate our notes, and cement and ideas we’ve learned. We will synchronize our thinking, and make sure we all have similar interpretations of the things our user expressed.5 e) Tasks The tasks to be performed are as follows: Lines in parenthesis () will be spontaneous acts by students Lines in quotes “” are notes that the facilitator must express
View Full Document
Unlocking...