Group Number: 20

Members:

Brian conducted one interview on his own and partnered for another interview and helped write the paragraphs on the interviews.

Matt conducted one interview on his own and partnered for another interview and helped write the paragraphs on the interviews.

Josh answered the 11 task analysis questions and helped Ed write the three storyboards and answer the interface design questions.

Ed helped Josh answer the 11 task analysis questions and wrote the three storyboards and answered the interface design questions.

Problem and Solution Overview
Currently, there is very little teaching of computer science fundamentals taught in middle school and high schools. Often, schools are prevented from teaching CS because they have insufficient computer resources to provide each student with a computing environment. Even in college, some students have difficulty learning the basic concepts such as binary number representation, memory, and recursion. The barrier of entry to learning CS is just too high. We are hoping to create an interactive method for teaching the fundamentals of computer science that does not rely on coding software on a computer. We wish to extend the idea of whiteboard programming. Using computer vision and a projector, we want to let users place “blocks” of code on the board and our tool will return visual feedback. Our solution could provide a low cost and interactive interface that could revolution technology teaching to the masses.

Description of Users Observed
Our target user group is divided into two main groups: teachers using our tool for pedagogy and students learning from our tool. We decided to select three users across both of these groups to get the most balanced perspective.

• The first user that we observed created and teaches an introductory CS course targeted at students with almost no technical background (often students from humanities departments). We think that he was a good choice for a user group not only because he has had years of teaching experience, but also because he is often recognized by his students as being an extremely effective and engaging educator. He is extremely interested in CS education although his background and interest tend to be focused on a slightly older age group than we are targeting.
• The second user that we interviewed was a student who took the above course. He had no technical background for the course and had a heavily humanities background. We thought he was a good user to interview because we were able to talk to him about the frustrations and confusions of learning the most simple CS. Also, we were able to compare his interview with the above interview readily.
• Our final interviewee was a member of the school board of a large suburban district near Los Angeles. He is been extremely interested and involved in education reform. We thought he would provide an interesting insight into the backend of education. He helped us to understand how teachers might adopt and use this technology from an institutional standpoint.

CI Interview Description
Our first interview was conducted in the office of the user. We started out by explaining a little about who we were and what the goals of our project was. We then asked him to walk us through a couple of his extremely early lessons to help us get a picture of what current teaching practices are. Our second interview was conducted in a classroom with a student who had taken the aforementioned introductory computer science course. The student is concentrating in a nontechnical field but took the computer science course to fill in a distribution requirement and learn some fundamental computer concepts. We asked the student to walk through some of his previous code in the course, explaining what he did in the assignment. Our final interview took place in a common space. This interview was tricky to take the perspective of contextual interview. As we will discuss later, professional development for teachers is extremely individual and therefore hard to observe. We therefore made sure to talk about specifics from a more distant perspective.

Our first user, the professor, provided us with an outline of the first few weeks of lectures, and discussed how he explains various concepts ranging from binary to memory to logical loops. Our second user, the student, talked briefly about what he liked and disliked about the introductory computer science class he took. In particular, he liked learning about internet security issues as well as computer coding. However, the coding portion of the class was the most difficult for this student to learn. As part of the interview, I asked the student to go through some of his code from the computer science class that he took. When going through the HTML code that he written, he noted in many places where he had to fix syntactical errors. Most of his errors in this particular program came from omitting the ‘/’ character from the end tags. Similarly, his JavaScript errors were almost entirely syntactical, usual because of a missing or extra ‘}’ character. Both the professor and the student agreed that binary was a very hard concept to teach/learn. In particular, the student suggested that most students struggle with the concept of how many decimal numbers can be represented by n bits. Both also agreed that a very difficult concept in computer science is how all computers are actually equivalent, and how languages can all do the same computation. The professor also mentioned that most students have an incredibly difficult time understanding the abstractions of the computer process. In particular, the student had trouble understanding compiling, assembling, and linking because the concepts were too abstract. However, the professor and student disagreed on some issues. Firstly, the professor believed that students struggled most on the idea of memory and more specifically the actual holding of memory. While the student admitted that memory was difficult, he believed that more students had trouble with binary representations of numbers. The student also emphasized that he was most frustrated by the syntax problems that he encountered while coding.

After having looked into a teaching lesson itself, we wanted to take a step back and gain more perspective on what it’s like to be a teacher. This is where we turn to our last interview. Our final interviewee, as a member of a school board, has a big picture knowledge of what fundamentally it is like to learn how to teach. The main takeaway we got from the interview is that current pedagogical education is extremely individual. He walked us through all of the professional development activities that a teacher does in a given year (including professional development conferences and school events). They were very few of them (~5 days per year) and individually focused. Teachers make their own lesson plans and learn new technological tools on their own. He talked us through the process of integrating iPads into his district and how poorly they are used by many teachers. This individuality contradicts our first interview slightly. Our first user actually published the notes of his class in a book so other teachers could use them to shape their lessons. I would explain that difference as being the difference between K-12 and college education. Ultimately, I think that for the context of our project, we have to understand that K-12 teachers wouldn’t have much support in learning how to use our tool. It must be self-contained, self-teaching, and extremely foolproof if we hope to gain traction with this audience.

Task Analysis Questions
1. Who is going to use the system?
Our target audience is the typical classroom. We envision the product being used with about 20 students and a single teacher. The students don’t need to have any background in CS or experience coding.

2. What tasks do they now perform?
Current CS education tends to be done with “whiteboard coding.” This is the practice of writing code on a whiteboard to demonstrate the features. Other practices commonly used is simple lecture style and for certain concepts, teachers use abstract drawings. For example, when students first learn about memory, it is often represented with a box to be filled with data. These abstractions of data are very important, as students can quickly get confused when exposed to the more complicated principles that lie under them.

3. What tasks are desired?
Typically, educators are looking for a tool to help boost the understanding of their students in a classroom setting. Having the ability to present basic concepts of CS to students in a way that is easy to visualize, grasp, understand, and interact with is very desirable. Additionally, having a teaching tool that students can use and get feedback from without need to have the teacher on hand to always give direct instructions is very useful as it allows students to continue to learn on their own and at their own pace.

4. How are the tasks learned?
Currently, teaching is an extremely self-taught process. Teachers individually come up with their own lesson plans. In our system, tasks could be learned through a simple tutorial lesson that would introduce the students to the basic operations and principles behind our system. Concepts would be introduced one at a time and the interactions between could be demonstrated as students make progress.

5. Where are the tasks performed?
Classrooms with a projector and whiteboard. Only a few computers for a lot of students. Our system could potentially operate on any smooth surface to which ID tags could be easily attached and moved around.

6. What’s the relationship between user & data?
Users could potentially have personal profiles that track their progress throughout the lessons. When using the system in a group setting, the system could controlled by the teacher to set up lessons and track the progress of the class as a whole.

7. What other tools does the user have?
Textbooks, the internet, Toy programming languages (e.g. Scratch)

8. How do users communicate with each other?
Teachers communicate with their students in a classroom setting. The Teachers can give their students guidance and instructions as they use the system, and the students can freely ask questions about the current lesson.

9. How often are the tasks performed?
Students would go through a lesson about 2-3 times a week. Multiple lessons could potentially be completed in one class session if they are short.

10. What are the time constraints on the tasks?
Class session usually last about an hour. This should be plenty of time to go through most lessons. However, more difficult and complex tasks may need to be broken up into multiple lessons spanning multiple days.

11. What happens when things go wrong?
Ideally, any errors encountered would be a result of improper set up by the user, not flaws in the code itself. If something does go wrong such as the project getting out of alignment in the whiteboard or the camera has trouble reading the ID tags, users could simply tell the system to recalibrate. All data and current lesson progress would be saved. Data should be saved periodically regardless to ensure that if the system fails completely, the users’ current progress is still preserved.

Description of Four Tasks
Tutorial – How to Teach a Lesson (Storyboard not included)
This purpose of this lesson would be to provided a ground work for the teacher and students to build and to teach them the basic principles of using our system. This lesson could include walk throughs of specific lessons they should be teaching. Highlighting blocks and stepping them through each part of the process. Currently, this is an individual learning task done by teachers. They read textbooks and compile a lesson plan. We would hope to significantly reduce the difficulty of this process.

Teaching Number Base (e.g. Decimal, Binary, Octal, Hex)
Our first two interviews both said that one of the hardest things for early tech students to learn is binary. This is something that is fundamental to CS but can be conceptually very challenging to students. We hope to help the students to better understand number base through visualization. We imagine they would place Binary/Octal/Hex/etc. tiles on the board. They would then see how different number systems represent numbers. This would be a moderately difficult task to perform with our system but one that is currently very hard.

Teach First Toy Program (I/O and intro looping)
Another suggested teaching example from our interviews was an extremely simple toy programing lesson. The lesson essentially works through each of the fundamental parts of a computer and provides a simplified example:

Read in a number from input and print (intro. to I/O)
Read in a number from input, do an operation, and print (intro. to processing)
Read in two numbers from input, print the product (intro. to memory)
Read in numbers from input until a 0 is given. Calculate the sum and print (intro. to loops)
We would create these programs with simple code put on the board and inputs placed on the board as well. This lesson (especially memory) is something that is currently difficult to teach and learn but we hope to reduce that difficulty.

Simplified Turtle Graphics
Our final lesson is the most complex. We want to create a tactile version of the Logo programming language library. Users could control the movement of a virtual turtle and see how his path changes as they change various part of code on the board. This would be a great way to introduce functions and show the execution of the program in a visual manner. It would use:

Create “Function” cards that would allow users to define custom operations
Only uses a basic set of commands, such as forward, turn, and pen color.
This language is well established a good way to teach new students about programming but the difficulty is it often requires a computer for each student. We plan to reduce that difficulty by adapting the program to our tool, requiring only one computer per classroom.

Interface Design
The user can teach and interact with a variety of lessons on computer science topics. By placing a “lesson” card on the board, the system reacts and projects the interface for that lesson. Then, the user can add physical cards to the board in the relevant areas (eg. Binary values, Code, Input, etc..) and the system will react by showing the execution and output of the program. Unlike any current solution, our system allows a teacher or professor to visually demonstrate to an entire class these computer science topics. The interactivity of our system allows the teacher to make quick, visual changes to the program or input to demonstrate how the output will change. We believe that this will be an engaging, fun, and flexible way to teach students important topics in CS.

Storyboards
Teaching Number Base

This slideshow requires JavaScript.

Teach First TOY Program (I/O and intro looping)

This slideshow requires JavaScript.

Simplified Turtle Graphics

This slideshow requires JavaScript.

Sketch of the System

Group Name and Number: The Elite Four; Group 24

Names and Contributions: Clay Whetung, Jae Young Lee, Jeff Snyder, Michael Newman

Clay conducted one of the interviews and helped answer many of the questions, especially regarding contextual inquiry.
Jae conducted one of the interviews and helped answer many of the questions, especially regarding contextual inquiry.
Jeff conducted one of the interviews and helped answer many of the questions, especially regarding task analysis and interface design.
Michael drew up the storyboards and sketches and helped answer many of the questions, especially regarding task analysis and interface design.

Problem and Solution Overview

We are addressing the problem of people (especially students) leaving important items (e.g., keys, wallet, phone) behind when they leave their rooms/buildings. This can lead to various further problems, like being locked out, being unable to start one’s car, or being unable to send/receive texts or voice calls. Our proposed solution is a system that uses proximity sensors to detect when a user is attempting to leave a room without their keys/phone/wallet and alerts them (visually or audibly) before it’s too late. Our sensors can also help a user find missing items around the house or even out in the world. This addresses the problem by both preventing and dealing with the aftermath of user forgetfulness.

Description of Users Observed in Contextual Inquiry

Our target user group includes all people who leave important items behind. Specifically, we are focusing on rooms/buildings with self-locking doors, since the consequences of forgetting something are often more severe. A great example of this user group is college students. We also have easy access to these students and can make first-hand observations without much trouble. The first user we observed lives in a quad in Brown Hall. He is a junior in the COS department who describes himself as fairly organized. He spends a large amount of time in his room since it is one of his main places for studying and doing work. The second user we observed was a CBE senior living in a triple in 1903 Hall. He was generally organized, but his room had become quite messy in the past few weeks as his thesis workload increased. He often leaves his room to work, go to the gym, do laundry, and attend various extra-curriculars. He would like to be able to ensure that he is completely prepared when he leaves the room, with minimal effort on his part. The third user we interviewed lives in a quad in Little Hall. She is a senior in the PSY department and described herself as organized, though her room was somewhat messy. She would like a solution to help prevent expensive lock-outs.

Contextual Inquiry Interview Descriptions

We interviewed the three users in the environment that our system would be employed — their dorm rooms. Each of the three was observed leaving their rooms. We logged the habits that they had formed for preparing to leave their room. Afterwards we discussed with each participant their routine in detail and how they thought their current system could be improved. We also asked them what they were willing to sacrifice for an entirely new system and provided them with some of our initial ideas for our project in order to help focus and guide the discussion.

There were several common experiences that each user shared. They all commented on the habits that they used to ensure they were ready to leave their room. This universally involved checking pockets/bags for wallets, phones and keys. However, these systems fail catastrophically when key items are missing from the wallet, or items are mistaken for each other. For example, users would remove their prox from their wallets to do laundry or go to the gym, and when they forgot to place it back into their wallet they were locked out. Along with this, they would lock themselves out if they felt their phone in their bag, but mistook it for their wallet. These were by far the most common lockout cases. They also commonly propped their doors to prevent lockouts, but this could lead to fines by fire safety. Two of our users also expressed interest in a device that would help them find lost items. Such a device would preferably be stationary, such that it does not become lost as well. Interviewees also stated they they would only use a system that was easy to install and did not change the form factor of their necessities very much.

Interestingly, one of the users that we had interviewed had investigated permanent solutions to the door locking problem. They had set up a variety of systems in their room to allow access without their prox, so they could never be locked out. However, this was a massive security issue and they were fined multiple times for their efforts. One user was willing to go to great ends for this system, even briefly considering total room overhauls for an optimal system. However, they did express that such changes may be unfeasible.

Answers to Task Analysis Questions

1. Who is going to use the system?
We’re focusing the system on students, but it’s usable by pretty much anyone who lives in a house/dorm/apartment and owns keys, a phone, a wallet, a purse, or other important items.

2. What tasks do they now perform?
Currently, users are simply forced to remember everything they need to bring when they leave home. When they want to find missing items, they must perform either an inefficient sweep over their entire room(s) or a slightly better search of possibly incorrect “last seen” locations. Finding missing items outside of one’s home is pretty much a hopeless task.

3. What tasks are desired?
Ideally, users wouldn’t have to rack their brains for missing items every time they leave the home. Instead, they will be automatically reminded if they’re about to leave something behind. Searching for missing items, particularly in one’s own home, should be faster and easier than simply looking everywhere.

4. How are the tasks learned?
These tasks are mostly learned by habit; they are performed several times a day every day by users. Most users develop strategies for finding lost items early in life, though they may not confront the problem of remembering important items until they live on their own for the first time.

5. Where are the tasks performed?
A user will generally attempt to determine if he has all necessary items immediately before leaving their abode, usually when close to the exit. Searching for missing items can occur anywhere, both inside the home and out.

6. What’s the relationship between user & data?
We don’t collect personalized information about the data or create a centralized data store; therefore privacy concerns are minimal/nonexistent. The only data we collect is proximity data  (e.g., are the user’s keys nearby?), which doesn’t need to be stored.

7. What other tools does the user have?
The user’s memory is their primary tool, both for remembering not to leave things behind and for trying to find missing items. However, the memory is a fickle and unreliable tool. For finding one’s phone in particular, there do exist apps that use GPS or other mechanisms to track the missing phone. However, these tools may not work in all situations — for example, if the phone is powered off. For remembering items and being let back into a room after being locked out, a roommate might be a useful “tool.” Many users use hacked solutions — makeshift door stops, door mechanism modifications, or others — to prevent their doors from ever closing.

8. How do users communicate with each other?
When locked out, Princeton students will call Public Safety with their phone, if they have it. If phoneless, they will generally attempt to borrow a phone from a neighbor or kind stranger. Roommates who are locked out may contact each other via cell-phone or email to borrow each other’s proxes. If users realize they have forgotten other important devices while away from their rooms, they may contact their roommates or significant others and request that they meet up and bring the forgotten devices.

9. How often are the tasks performed?
Leaving a room is done multiple times per day. Finding missing items (hopefully) is done less frequently, depending on the forgetfulness of the user. On average, the users interviewed and our group members get locked out on the order of once every 2-3 months.

10. What are the time constraints on the tasks?
There isn’t really a “time constraint” on not forgetting to take one’s keys/wallet/phone out of the room, although usually this is a process that occurs within just a few seconds. On the other hand, finding lost items (especially for important things like phones) is a task that is best accomplished within a short time frame — such as a half-hour to a couple of hours. If a user ends up locked out, they may need access within a short time frame if they have left necessary items in their abode, such as completed assignments.

11. What happens when things go wrong?
At worst, a user will be locked out of their room (potentially wearing nothing but a towel) with no way to call someone else for help. Less drastic scenarios include simply being locked out, being unable to start a car, being unable to open a door or a bike lock, being unable to make calls or send texts, and/or being unable to purchase things. Some of these scenarios could be seriously problematic; others are merely annoying.

Description of Three Tasks

Task 1: Being reminded to take keys/phones/wallet along when leaving a room.
Our system will have a proximity sensor and be located (by default) near the door. When a user opens the door to leave their room, our system will flash red LEDs and play a warning melody if certain items (e.g., keys, phone) are not detected. If these items are present, the system will light up green (and may also play a happy tune).
Current difficulty: Easy
Proposed difficulty: Trivial

Task 2: Being able to use the proximity detector in one’s house to find missing items.
Though our system will typically be located near the door, users will also be able to carry it around (with some kind of battery pack) in order to detect important items in their home. Since the area being searched is relatively small and confined, it should be relatively easy to find objects simply using proximity sensing. The device will have an “item-detecting” mode that the user can activate, and it will light up green and beep more quickly as it gets nearer to the missing item(s).
Current difficulty: Moderate
Proposed difficulty: Easy

Task 3: Using the proximity sensors to find missing items out in the world.
This task is very similar to the previous task in that it involves detection of missing items; however, finding missing items outside of the home environment is far more difficult due to the increased size of the area being searched. For this, the user will need to have a general sense of where their item(s) might be; unlike in the previous task, a broad sweep over the entire searchable area will not be feasible. Battery life and detection range are also more of a consideration for this task; we may need to use sensing devices with a longer range than (for example) RFID tags.
Current difficulty: Hard
Proposed difficulty: Moderate

Interface Design

Our system consists of several parts: tags of various form factors that users can attach to important items and a door-frame mounted sensor to check for items when leaving the room that can also be detached and used as a handheld proximity sensor to locate lost items. The sensor will have a Li-On battery, rechargeable over USB, so it can be used as a portable device. We believe that for wallets, a credit-card form factor tag would be minimally intrusive, whereas for keys and cell phones, a small fob (about the size of a quarter) would be more appropriate. Each of these tags would contain a battery and an antenna. Our system alerts users when they attempt to leave their room or abode without every item they’ve tagged using our system by playing an alert noise and flashing red LEDs. When a user leaves the room with important items, the system plays a happy noise and flashes green LEDs. To add a new item to the set tracked by our system, the user presses a button on the door sensor and holds the new tag up to it until the sync completes. A user can also remove an item from this set by a similar process.  The visual and audible reminder provided by our system will help even users in an altered mental state remember their important items. The system can handle multiple users by maintaining separate device profiles for each inhabitant. It will alert a user leaving if it does not detect a complete set of devices. Users can separately add and remove devices. By removing the sensor from its door frame mount, the system will automatically switch to proximity sensing mode so that it can be used to locate missing objects — both in the user’s room and elsewhere. When no device tags are detected the system will flash red and beep slowly; as the user nears the missing item(s), the system will flash green and beep with increasing frequency. As far as we know, no other system grants this kind of functionality to a user — at best, there exist ways to find lost phones using GPS, but only when the phones are powered on. Our system is far more versatile than that, especially since it implements preventative as well as remedial solutions to the problem of forgetting important items.

Storyboards

Task 1: Being reminded to take keys/phones/wallet along when leaving a room.

A clueless user about to leave his room without his keys.

Our system notifies the user that he has forgotten his keys.

Task 2: Being able to use the proximity detector in one’s house to find missing items.

A sad user unable to find his keys.

Our system can be used as a proximity sensor to help locate the missing keys.

Task 3: Using the proximity sensors to find missing items out in the world.

A helpless user who has just realized that he lost his phone at the beach.

Our system can be used as a proximity detector anywhere to find the missing phone.

Design Sketches

A sketch of the proximity sensing device.

How different items would be tagged by the device.

The door-mounted user interface.

The portable user interface.

Team 13 – CAKE

Connie (task description, interface design, blog post), Angela (task analysis, interface design), Kiran (contextual inquiries, interface design), Edward (contextual inquiries, task description)
(in general, we collaborated on everything, with one person in charge of directing each major component)

Problem/Solution

3d modeling is often a highly unintuitive task because of the disparity between the 3d work space and the 2d interface used to access and manipulate it. Currently, 3d modeling is typically done on a 2d display, with a mouse that works on a 2d plane. This combination of two 2d interfaces to interact with a 3d one (with the help of keyboard shortcuts and application tools) is hard to learn and unintuitive to work with. A 3d, gesture-based interface for 3d modeling combines virtual space and physical space in a way that is much more natural and intuitive to view and interact with. Such a system would have less of a learning curve and facilitate more efficient interactions in 3d modeling.

Contextual Inquiry

Users

Our target user group is limited to individuals who regularly interact with 3d data and representations, and who seek to manipulate it in some way that depends on visual feedback. These are the people who would find the most practical use out of our system, and who would benefit most in their workflow.

Our first user was a professor in Computer Graphics. He has been doing 3D graphics for many years and has some experience with many different programs and interfaces for manipulating 3D data. However, he stated that he didn’t personally do heavy 3D tasks anymore (at least with the interface he showed us); however, he often shows new students how to use these interfaces. He likes exploring applications of 3D graphics to the humanities, such as developing systems for archaeological reconstruction. He does not focus much on interfaces, as he believes that a good spatial sense is more useful than an accessible interface (though for the applications that he develops, he is happy to alter the interface based on user feedback).

Our second user was a graduate student in Computer Graphics who has been at Princeton for several years. He has experience in 3D modelling using Maya, and his primary research project related to with designing interfaces for viewing and labelling 3D data. Because of his research and undergraduate background, he had a lot of background in basic 3D viewing manipulations and was very adept at getting the views he wanted. His priority for his interfaces was making them accessible to other, inexperienced users; this was because his research is supposed to be used for labelling objects in point clouds (which could be outsourced). In terms of likes and dislikes, he stated that he did not really get into modelling because it required too much refinement time and effort.

Our third interviewee was an undergraduate computer science student from another university. He has experience in modelling and animation in Maya, and did so as a hobby several years ago. He has taken courses in graphics and game design, and has a lot of gaming experience. However, his experience with Maya was entirely self-taught, and he acknowledged that his workflows were probably very unlike those of expert users. Because of this, his priorities were not speed or accuracy of tasks, but being able to create interesting effects and results. He was happiest when experimenting with the sophisticated, “expert” features.

Interviews

We observed our first two CI subjects in their offices, with their own computers, monitors, mice, and keyboards. They were usually alone and focused on their task while using their systems. The last user did his modelling in his home or dorm room, generally alone or working with friends. We asked our subjects to show us the programs that they used to do 3D manipulation/modelling, and perform some of the tasks that they normally would. Following the master-apprentice model, we then asked them to go over the tasks again, and explain what they were doing as if they were training us to perform the same things. After this, we tried to delve a bit deeper into some of the manipulations that they seemed to take for granted (such as using the mouse to rotate and zoom) and have them try to break down how they did it, and why they might have glossed over it. Finally, we had a general discussion about their impressions about 3D manipulation in general, especially focusing on other interfaces they had used in the past and the benefits/downsides compared to their current programs.

The most common universal task was viewing the 3D models from different perspectives – each user was constantly rotating the view of the data (much less frequently panning or dollying). Another fairly common task was selecting something in the 3D space (whether a surface, a point, or a model). After selection, the two common themes were some sort of spatial manipulation of the selected object (like moving or rotating it), or non-spatial property editing of the selected object (like setting a label or changing a color). It seems that the constant rotation was helpful for maintaining a spatial sense of the object as truly 3D data, since without the movement it could simply look like a 2D picture of it (this is especially true because you can translate or zoom a single 2D image without gaining any more 3D information, whereas rotation is a uniquely 3D operation).

Essentially all of the operations we observed being performed fell into the categories mentioned above.

Our first user’s program was used for aligning several 3D scans to form a single 3D model; his operations involved viewing several unaligned scans, selecting a single one, and moving/rotating it until it was approximately aligned with another model. We noted that he could not simultaneously change views and move the scans, so he often had to switch back and forth between changing views and manipulating the object.

Our second interviewee showed us his research interface for labeling point cloud data. The point cloud data labeling application was really primarily about viewing manipulations: the program showed the user a region of a point cloud, and the user would indicate whether it was a car, streetlight, tree, etc. The user only really had to rotate/pan/zoom a little bit if necessary to see different views of the object under consideration, and sometimes select pre-segmented regions of the point cloud.

The Maya workflow was far more complex. For example, the skinning process consisted of creating a skeleton (with joints and bones), associating points on the model surface with sections of the skeleton, and then moving the joints. The first part was very imprecise, since it involved repeatedly creating joints at specific locations in space. After creating a joint, the user had to carefully drag it into the desired position (using the top, side, and front views). The user thought this was rather tedious, although the multiple views made it easy to be very precise. He did not go into much detail about the skinning process, using a smart skinning tool instead of “painting skinning weights” on the surface (which basically looked like spray-painting the surface with the mouse). Finally, joint manipulation just involved a small sphere around the joint that had to be rotated using the mouse. He also described how the advanced features generally worked (but didn’t actually show them) and described them as generally involving selecting a point and dragging it elsewhere, or setting properties of the selected object.

Task Analysis

1. Who is going to use the system?
   Our system can be used in 3D Modelling: Game asset designers, film animators/special effects people, architectural designers, manufacturing, etc. More generally, we can use our system for basic 3D Manipulation and viewing – Graphics research, medical data examination (e.g. MRI scans), biology (examining protein/molecular models), etc. People in these fields generally are college educated (since the application fields are in research, industrial design or media), and because of the nature of the jobs they will probably have experience with software involving 3D manipulation already. They certainly must have the spatial reasoning abilities to even conceptualize the tasks, let alone perform them. It may be common for users to have more artistic/design background in non-research application contexts. We imagine that there is no ideal age for our system; because of the scope of the tasks we expect that the typical user will be teenaged or older. Additionally, our system requires two functioning eyes for the coupling of input-output spaces to be meaningful.
2. What tasks do they now perform?
   In 3D modeling, they take 3D scans of models and put them together to form coherent 3D models of the scanned object. They also interact with 3D data in other ways (maps, point cloud data representations of real life settings), create and edit 3D objects (models for feature films and games: characters, playing fields), define interactions between 3D objects (through physics engines, for example, define actions that happen when collisions occur), and navigate through 3D point-clouds (that act as maps, of, say a living room: see floored.com).
3. What tasks are desired?
   On a high level, the desired tasks are the same as the tasks they now perform; however, performing some of these tasks can be slow or unintuitive, especially for those who are not heavy users. In particular, manipulation of perspective is integral to all of the tasks mentioned above, and manipulating 3D space with 2D controls is not intuitive and often difficult to learn so that operations run smoothly.
4. How are the tasks learned?
   Our first interviewee highlighted the difference between understanding an interface (getting it) and being good at using it intuitively (grokking it). The first of these involves learning how things work: right click and drag to translate, click and drag to rotate, t for translation tool, etc. These facts are learned through courses, online training and tutorials, and mentorship. The second part can only be done through lots of practice and actual usage to achieve familiarity with the 3D manipulations. Our first interviewee noted that, after learning gaining the spatial intuition for one type of interface, other such tasks and interfaces often become much easier to grok.
5. Where are the tasks performed?
   Tasks are performed on a computer, typically in offices, as they are often a part of the user’s job. Animators generally work in very low lighting, to simulate a cinematic environment. People are free to stop by to ask questions, converse, etc. — which interrupts the task at hand, but does not actively harm it, just as with other computer-based tasks. Also some people might design at home for learning, or personal app or game development.
6. What’s the relationship between user & data?
   The user wants to manipulate the data (view, edit, and create it). Currently, most 3D data is commercial, and the user is handling the data in the interests of a company (e.g. animated models for films), or for research purposes with permission given by a company (e.g. Google Streetview data). Some of it can be personally acquired, e.g. with kinect. Some users create the data: for example, designing game objects in video games, or 3D artwork for films.
7. What other tools does the user have?
   Manipulation of 3D data requires tools with computing ability — with a computer, there are other interfaces, such as through the command line, to select and move objects (specifying exact locations). With animation, animators can use stop-motion animation, moving actual objects incrementally between individually photographed frames. In general, a good, high-resolution display is a must. Most users do their input via mouse and keyboard. There are some experimental interfaces that use specialized devices such as trackballs, 3D joysticks, and in-air pens. Many modellers also use physical models or proxies to approximate their design, e.g. animators might have clay models and architects might have small-scale paper designs.
8. How do users communicate with each other?
   Users communicate with each other both online and in person (depending on how busy they are, how close they are located) for help and advice; they also report to managers with progress on their tasks. (for instance there are developer communities for specific brands of technology http://forum.unity3d.com/forum.php?s=23162f8f60e0b03682623bf37fd27a46 for example ).
   In general, modelling has not been a heavily collaborative task. 3D modellers might have to discuss with concept artists on how to bring their ideas into the computer. Different animators might be working on different effects on the same scene in parallel, such as texturing and animating, or postprocessing effects.
9. How often are the tasks performed?
   Animators undertake 3D manipulation jobs daily — for almost the entire day (and during this time, continually manipulating view and selecting objects to create and edit the 3D data). Researchers, on average, tend to perform the tasks less frequently. The professor we interviewed rarely manipulates the 3D data himself (except for demos); the graduate student still interacts with the data daily, as his research project is to design an interface that involves 3D interaction. In terms of individual tasks, the functions that are performed most frequently are by far changing the perspective. This happens essentially continuously during the course of the 3D manipulation session, almost such that it doesn’t feel like a separate task. Next most common is selecting points or regions, as these are necessary for most actual manipulation operations.
10. What are the time constraints on the tasks?
    As changing perspective is such a common task, required for most operations, it is a task which users will not want to spend much time on (given that their goals are larger-scale operations). For operations which they are aware require a significant amount of time (e.g. physical simulations, rendering), they are willing to wait, but would certainly prefer them to be faster — they are also more willing to wait for something like a fluid simulation if they are aware of what the end result will generally be like (which is another problem).
11. What happens when things go wrong?
    Errors in modelling can generally be undone, as the major software keeps track of change history for each individual operation. Practical difficulties may arise in amount of computer resources required to create a model of high resolution.

Task Descriptions

1. (Easy) Perspective Manipulation
   This task classically involves rotating, panning, and zooming the user’s view of the scene to achieve a desired perspective or to view a specific part of the scene/model. Perspective manipulation is a fundamental, frequent task for every user we observed. It seems to serve the dual purpose of preserving the user’s mental model of the 3D object, as well as presenting a view of the scene where they can see/manipulate all the points necessary to complete their more complex tasks.
   Currently, this task has a large learning curve, but once people are used to it, it becomes easy and natural; the only hurdle is that with current interfaces, it is not possible to change this while performing another mouse-based task. With our proposed interface, we first propose to separate the two purposes of preserving spatial sense and presenting manipulable views. With a stereoscopic, co-located display, we make preserving spatial sense almost a non-issue with no learning curve, especially with head-tracking. We also believe that using a gestural, high degree-of-freedom input method can allow for more intuitive camera control, equating to an easier learning curve. We also note that using gestural inputs will allow users to perform perspective manipulation simultaneously with other operations, which to us is more in line with how the users conceive of this (as a non-task, rather than a separate task).
2. (Medium) Model Creation
   This task is to create a 3D mesh of some desired appearance. Depending on the geometry of the desired model, it can be created by starting off by combining and editing some simple geometry (spheres, ellipsoids, rectangular prisms), or modelled off of a reference image, from which an outline of the model can be drawn, extruded, and refined to create a model. The task involves object (vertex, edge, face) selection, creation, and movement (using perspective manipulation to navigate to the location of the point of interest), and typically involves many iterations to achieve the desired look or structure.
   Game designers and movie animators perform this task very often, and a current flaw of the system is that the creation of a 3D shape happens in a 2D environment. We anticipate that creating a 3D model in 3D space will be much more intuitive.
3. (Hard) 3D Painting
   Color and texture on 3D models gives a sense of added style and presence. Many artists use existing images to texture a model, e.g. an image of metal for the armor of a model of a medieval knight, as it is relatively easy and efficient. However, when existing images do not suffice for texturing an object, an artist can paint the desired texture onto the object. Such 3D painting is a very specialized skill, as painting onto a 3D object from a 2D plane is very different from traditional 2D painting (many artists who are skilled in 2D painting are not in 3D painting, and vice versa) and can be unintuitive. Major platforms for 3D painting project a 2D image onto the object, which can cause unexpected distortions for those unfamiliar with the sense of operation. In our interface, we intend for users to be able to paint onto an object in 3D space with their fingers.

Interface Design

Functionality

We intend to include functionality for most basic types of object manipulation (rotation, translation, scale), which will be mapped to specific gestures, typically with both hands and arms. We also want to allow for more precise manipulation such as selection/distortion and 3d painting, which involve gestures using specific fingers in more precise movements. To add control and selection capabilities, we hope to incorporate a tablet or keyboard, perhaps to change interaction modes or select properties such as colors and objects. Together, these will encompass a considerable portion of the functionality that basic 2d interfaces provide currently, while making the interaction more intuitive because it is happening in 3d space.

Storyboards

Easy task: Perspective Manipulation

Medium task: Model Creation

Hard Task: 3D Painting

System Sketches

Top: Front view of the system, including all component devices. Middle: Tablet (or keyboard) for additional selection and control, like mode or color change. Bottom: Side view of system, showing the devices and basic form of interaction.

Top: basic ways for the user to interact with the system using hand gestures. Bottom: More precise gestures and interactions that require greater accuracy. (Not shown: control mechanisms such as a tablet or keyboard to switch between them, or provide extra choices for functionality)

Group Name: VARPEX

Group Members and Contributions: Abbi Ward, Dillon Reisman, Prerna Ramachandra, Sam Payne

Dillon recorded participant answers and wrote up information about our participants/people we observed and their responses and gathered test subjects.
Sam provided the music and music equipment, recorded the answers to the task analysis questions and gathered test subjects.
Abbi drew some of the sketches and wrote up information about the contextual interviews.
Prerna drew the storyboards, gathered some of the test subjects and helped with conducting interviews and compiled the blog post.

Group Number: 9

Problem and Solution Overview

We are addressing the problem that the concert experience can only be replicated by expensive, non-portable hardware. Further, these systems cause noise pollution in tight-living quarters. We will create an article of clothing worn on the torso that will use vibrating motors to generate stimulus similar to that created by loud bass – that is, a vibrating sensation on the skin. Our solution is portable, relatively inexpensive, and avoids the noise pollution problem.

Description of Users Observed in Contextual Enquiry

The target group of users we observed were students aged 18-22. They all have enjoyed listening to music at eating clubs on weekends or going to the occasional concert. They do these things, however, for a variety of different reasons. Some go to clubs for the social aspect of it (their friends are there, their friends are performing, etc.). Most, however, find the act of listening to the music enjoyable in its own right. The observed users enjoy many forms of music, and for most that includes some form of electronic music, though they had varying opinions on the quality of dubstep specifically. It helps that what is played in clubs is mostly of this type, as opposed to rock or other genres.

Contextual Inquiry Interview Descriptions

We invited six individuals to Sam Payne’s room on a Saturday afternoon. Sam has a good quality subwoofer which we used to experiment with different bass frequencies. We invited individual participants to the room at different times. We introduced ourselves and described the class and the purpose of the questions we were going to ask. For each participant, we walked through a series of questions about their music-listening habits and tried to get a feel for how, when, and why these students are listening to music. We then played a series of frequencies for them (from 110 Hz down to 50Hz) while they stood next to the subwoofer. We asked them to describe the sensation and where they felt it. We then put a foam chair near the subwoofer and had them listen to the tones again. We asked them to describe the sensations again, where they felt it, and how they liked it.

As participants answered our questions, we recorded their answers in this form, which gives a basic outline of the sorts of questions we asked.

Most of our users primarily listen to music in their dorms with laptop speakers. If they go outside, they’ll typically use headphones. These headphones are generally low-quality earbuds rather than slightly higher quality over-the-ear headphones. Many students will listen to music on speakers in whatever lab they’re working in. The participants we interviewed enjoyed a variety of genres, from dubstep and electronica to pop and opera. Even if the participants did not report that electronica or dubstep was very high on their list of favorable genres, they often at the very least appreciated it for its diverse and interesting sound and the “intense” sensation they often got from it.

Users felt the vibrations in very different locations. Some of this difference may have been due to different body types. The tall, thin men we interviewed felt vibrations very strongly in the top of their chest but other participants did not feel these vibrations as strongly. Another area where sensations were strongly felt was in the mid-back, along the spine. Users enjoyed the chair, as opposed to just feeling the vibrations in the air. The chair produces a more intense diffusion of vibration. People likened this feeling to a massage of the back and legs. This suggests that users enjoy the intensity of response and the similarity to the raw air experience may not be as important.

Answers to Task Analysis Questions

1. Who is going to use system?
This system would be for people ages 16-34 who enjoy concerts. They enjoy concerts because of the sensation derived from loud music, and would like to have this same sensation when they listen to music at home.

2. What tasks do they now perform?
They go to concerts when they can, and they play loud music in their home (if they can). Some individuals, such as college students living in dormitories, must listen to music through headphones due to noise pollution.

3. What tasks are desired?
Users would like the concert experience on-the-go and without disturbing their neighbors.

4. How are the tasks learned?
Users already know how to use their headphones and feel music. Our system would be an extension of simply plugging in your headphones.

5. Where are the tasks performed?
People feel music at concerts, parties and in dorms/apartments, if they have good speakers. People listen to music everywhere.

6. What’s the relationship between user & data?
Feeling music is a subjective experience, so our data is the reported experience of users. There may be some loss of data if users cannot describe or are not aware of factors that affect their experience.

7. What other tools does the user have?
Depending on the situation, the user may have headphones or speakers and subwoofers. They also have music-playing devices, such as iPods, computers. This equipment varies in expense.

8. How do users communicate with each other?
At concerts, people communicate through gesture and yelling.

9. How often are the tasks performed?
How often tasks are performed varies between individuals because it depends on the type of equipment they have. Those without subwoofers only feel music at concerts so they may feel music a few times per year. Those with subwoofers may feel music on a daily basis.

10. What are the time constraints on the tasks?
At a concert, the time of the concert constrains when users can listen and feel music. For those with good speakers and subwoofers, the constraint may be the time it takes for your neighbors to call public safety.

11. What happens when things go wrong?
If the concert is cancelled, the police are called, or your speaker breaks, you don’t listen and feel your music.

Descriptions of the Three Tasks

1. Many times, people want to listen to music at a loud volume in their room while     roommate is studying, or without disturbing their neighbors. Many students will listen to music on headphones. However, the physical sensation of listening to music is lost while listening on headphones. This product would allow people to feel that sensation without disturbing those around them. The task of listening to music loudly in your room is easier than the other tasks, but it becomes more difficult as you take into consideration the possibility of disturbing your neighbors.

• Users working outside of their rooms often listen to music while working. The portability of this device allows users to feel music while studying without disturbing those around them.

2. Many students listen to music while walking to class. This of course is done on headphones since speakers are not portable. However, again, the physical sensations of listening to music are lost while listening on headphones. The portability of this product would allow students to listen and feel their music in any setting, and on the go. The task of listening to loud music while moving is difficult, and is even more difficult when you take into consideration the possibility of disturbing other persons.

3. While at concerts, many people enjoy the feeling of music, and some songs are even written to promote these sensations. While producing music, artists could use this product to feel their music and gauge how their music will feel in a concert setting. Attending concerts is difficult due to availability and cost.

Storyboards

Storyboard 1 

Listening to music while walking to class and getting the live music experience

Storyboard 2

Listening to music in the library or lab while doing work

Getting the live music experience while doing work!

Storyboard 3

Listening to music in your room, and getting the live music experience without disturbing your roommate

 Design Sketches

Overview of the jacket, fit and spot to place iPod

Front and back of jacket, and sketch of the motors

Parts of the body affected by the jacket

Interface Design Description

Since our system will be wearable, it will grant the user a lot of freedom over where and when they can ‘feel’ their music. Ideally it will also look inconspicuous in its function; a user should be comfortable simply wearing it as a jacket or other article of clothing. It will still enable the user to simply listen to music should they wish, as they did before, but with the added ability to activate the more immersive ‘feeling’ system through vibrating motors. Currently this ability is not offered by any product on the market- headphones do not offer users the concert-going experience of ‘feeling music’.