Krithin Sitaram (krithin@) – Krithin conversed with people in contextual interviews, and wrote about contextual interviews descriptions and task descriptions.
Amy Zhou (amyzhou@) – Amy drew a storyboard, conversed with people in contextual interviews, and wrote about user descriptions and task descriptions.
Daniel Chyan (dchyan@) – Daniel drew a storyboard, wrote about the interface design, observed interviewees during contextual interviews, and wrote about task descriptions.
Jonathan Neilan (jneilan@) – Jonathan took notes during contextual interviews, and took pictures of the design sketches.
Thomas Truongchau (ttruongc@) – Thomas drew a storyboard, wrote about task descriptions, and took pictures of all the storyboards.

Essentially, each person addressed different problems when they arose.

Problem and solution overview
Smartphone map apps are useful but very demanding of the user’s visual attention, and still require the user to be able to read a map. Our proposed solution is to outfit a belt that the user will wear with a number of buzzers; this will interact with a user’s smartphone to determine the user’s location and bearing and vibrate the appropriate motor to indicate the direction the user should walk.

Description of users you observed in the contextual inquiry
Our first target user group includes travelers in an unfamiliar area who want to travel hands-free. Our rationale behind choosing this user group is because they tend to have their hands full and need a solution that will help them quickly move from place to place without referring to a map or phone.
Our second target user group includes people searching in Firestone library. Actual tourists are hard to find this time of year, so we chose students attempting to locate things in Firestone as an approximation. They have the problem of making their way around an unfamiliar environment. This allowed us to gather insight into how they use the same tools that people use when navigating a larger scale unfamiliar environment, like a city.

Persons observed in contextual interviews
At the transit center:
1. Two female adults, probably in their mid-20s, who were very outgoing and excited about traveling. They were primarily occupied with getting where they were going, but also wanted to have fun along the way! They were good target users because they were new to the area, having just arrived from the airport, and also had a distinct destination they wanted to get to; they also did not want to expose electronics to the rain, so they fit in the category of travelers who would have liked to have hands-free navigation.
2. Two women, probably in their early 20s, weighed down by shopping bags and a small child. They were fairly familiar with transit in general, but not with this particular transit center. Their top priority was not getting lost. They were good observation candidates because they were in a hurry but were having trouble using existing tools — they were uncertain whether they were on the right bus, and waited for several minutes at the wrong bus stop.

At Firestone:
1. Female student searching for a book in the B level, then looking for the way back to her desk. She does not know Firestone well, and was using a map of the library on her laptop to get around.
2. Male student searching for his friend in the C level of Firestone. He knew the general layout of that part of the library, but did not know precisely where his friend would be. It seemed time was less of a priority for him than convenience, because he was content wandering around a relatively large area instead of texting his friend to get a more precise location (e.g. call number range of an adjacent stack) and using a map to figure out directions to that location.
3. The official bookfinder on the B-level of Firestone provided some information about the way people came to her when they needed help finding a book. Although she was not part of our user group herself (since she was trained in finding her way around the library) she was a useful source because she could draw on her experience on the job and tell us about the behaviors of many more people than we could practically interview.

CI Interview Descriptions
We carried out interviews in two different settings. Firstly, we observed people attempting to find their way around using public transit who were waiting at the Santa Clara Transit Center, while it was dark and raining, immediately after a bus had arrived from the airport, thus carrying many people who had just arrived in the area. Secondly, we observed people in Firestone library as they attempted to find books or meet people at specific locations in the library. In addition to direct observations, we also interviewed a student employed as a ‘bookfinder’ in the library to get a better sense of the users we expected would need help finding their way around. We approached people who were walking near the book stacks or disgorged from the elevator; asked them what they were looking for, and followed them to their destination. One person recorded observations by hand while another talked to the participant to elicit explanations of their search process.

One common problem people faced was that even with a map of the location they were uncertain about their exact position, and even more so about their orientation. This is understandable because it’s very easy to get turned around, especially when they are constantly looking from side to side. Recognizable landmarks can help people identify where they are on a map, but it is harder to figure out their orientation from that. Another problem is that people are often overconfident in their ability to navigate a new area. For instance, at the transit center, one informant was sitting at a bus stop for quite some time, apparently very confident that this was the correct bus stop, only to run across the parking lot several minutes later and breathlessly exclaim “We were waiting at the wrong bus stop too!” The first student we interviewed in Firestone also told us that she knew the way back to her desk well (even though she admitted to being “bad with directions”), but nevertheless had to keep looking around as she passed each row in order to find it.

One Firestone interviewee revealed another potential problem; he was looking for a friend in the library but only knew which floor and which quadrant of the library his friend was in, and planned to wander around till the friend was found. This indicates that another task here is the mapping between the user’s actual goals and a physical location on the map; we expect however that this should be easier for most users of our system, since for example the transit passengers and the students in search of books in the library had very precise physical locations they needed to go to. Even when users are following a list of directions, the map itself sometimes has insufficient resolution to guide the user. For instance, at the transit center, all the bus stops were collectively labeled as a single location by Google Maps, with no information given as to the precise locations of the bus stops within that transit center.

Answers to 11 Task Analysis Questions
1. Who is going to use system?
Specific target group:
People who are exploring a new location and don’t want to look like a tourist.
2. What tasks do they now perform?
Identify a physical destination (e.g. particular location in library) that they need to go to to accomplish their goal (e.g. get a certain book).
Harder to define for some goals (‘looking for a friend in the library’)
Determine their own present location and orientation
E.g. Transit passengers try using GPS; inside library people look at maps and landmarks.
Identify a route from their location to their destination, and move along it.
As they proceed along the route, check that they have not deviated from it.
e.g. the transit passengers
3. What tasks are desired?
Identify a physical destination that they need to get to.
Receive information about next leg of route
Reassure themselves that they are on the the right path
4. How are the tasks learned?
Users download a maps application or already have one and figure it out. They usually do not need to consult a manual or other people.
Boy Scouts orienteering merit badge
Trial and error #strug bus
Watching fellow travelers
5. Where are the tasks performed?
Choosing a destination can happen at the user’s home, or wherever is convenient, but the remainder of the tasks will happen while travelling along the designated route.

6. What’s the relationship between user & data?
Because each person has a unique path, data will need to cater to the user. Privacy concerns are limited, because other people will necessarily be able to see the next few steps of the path you take if they are physically in the same location. However, broadcasting the user’s complete itinerary would be undesirable.
7. What other tools does the user have?
Google maps
Other travelers, information desks, bus drivers, locals…
Physical maps
Signs
Compasses
8. How do users communicate with each other?
Verbally
Occasionally, text messaging
9. How often are the tasks performed?
When the user is in an unfamiliar city, which may happen as often as once every few weeks or as rarely as on the order of years, depending on the user, the user will need to get directions several times a day.
10. What are the time constraints on the tasks?
Users sometimes have only a few minutes to get to a location in order to catch a bus, train, or plane, or have to get to their destination within a few minutes.
11. What happens when things go wrong?
In the case of system failure, users will be able to use preexisting tools and ask other people for directions.

Description of Three Tasks
1. Identify a physical destination that they need to get to.

Currently, this task is relatively easy to perform. On the web, existing tools include applications like Google Maps or Bing Maps. Users generally input a target destination and rely on the calculated path in order to get directions. However, the task becomes moderately difficult when consulting directions on the go. Users inconvenience themselves when they need to take out their phone, refer to the map and directions, and then readjust their route accordingly.
Our proposed system would make the task easier and less annoying for users who are physically walking. After the user identifies a physical destination, the navigation belt will help guide the user towards the target. Our system eliminates the inconvenience of constantly referring to a map by giving users tactile directional directions. This is discrete and inconspicuous.

2. Receive information about immediate next steps

Determine in what direction the user should be walking. This can be moderately difficult using current systems, because orientation is sometimes difficult to establish at the start of the route, and the distance to the next turn is usually not intuitive. For example, users of current mapping systems may have to walk in a circle in order to figure out a frame of reference to determine the correct direction because a user must orient the mobile phone. With our proposed system, the direction will be immediately obvious, because the orientation of the belt remains stable. Our proposed system will make this task relatively easier.

3. Reassure themselves that they are on the the right path

The user often wants to know whether they are still on the right track, or whether they missed a turn several blocks ago. The user attempts this task once in a while if they are confident, but if they are in a confusing area they might want this information very often or even continuously. Currently, checking whether the user is still on the right path is not very difficult but rather annoying, since it requires pulling out a map or phone every few minutes to gain very little information. With our proposed system, it would be extremely simple, because as long as the front panel is vibrating, the user knows that he or she is walking in the right direction.

Interface Design
The system provides users with the ability to orient themselves in a new environment and receive discreet directions through tactile feedback. A user can ask for directions and the system will vibrate in one of 8 directions to guide the user through a series of points towards a destination. Benefits of the system include discrete usage and providing an additional sense of direction beyond the current maps provided by Google and Microsoft. Reliance on a tactile system also reduces the demand on visual attention which allows users to focus more on his or her surroundings. The scope of functions will encompass orienting towards points of interest and providing directions to those points. No longer will users need to stare at a screen to find their way in unfamiliar locations or spin in a circle to find the correct orientation of directions.

Storyboard 1:

Design of NavBelt

Design of Mobile Application Interface

GROUP NUMBER: 25
GROUP NAME: Deep Thought
GROUP MEMBERS: Vivian Qu, Neil Chatterjee, Harvest Zhang, Alan Thorne

All four group members conducted contextual interviews. All four worked on answering task analysis questions and interface design together, organizing a meeting and collaborating on a google docs.

Harvest, Alan, and Vivian drew sketches and final storyboards for the 3 defined tasks. Neil and Vivian compiled the blog post information to publish on the website.

PROBLEM SOLUTION AND OVERVIEW:

VAHN (pronounce vain) is Microsoft Kinect project that allows on-the-fly, gesture-controlled, audio editing for musical performers and recorders. Skeleton data allows the manipulation of recording software that includes features such as overlaying audio, playback, EQ modulation, and editing. Suppose you want to know what your a cappella performance is going to sound like, or you’re creating a one man a cappella song — stand in one location, use gestures, sing, record and edit. Physically move to the next location (simulating multiple singers). Use gestures, sing, record, and edit. Move to another location, realize you don’t want a middle of a snippet, and use gestures to remove that snippet. Finish the third section, and finally overlay them together. VAHN provides a cheap solution for gesture-controlled audio recording and editing.

DESCRIPTION OF USERS YOU OBSERVED IN THE CONTEXTUAL INQUIRY:

Our target users are amateur musicians with high level of skill and therefore need more music recording functionality, but who may not have much technical ability, and may lack familiarity with or access to complicated audio recording systems. This is a reasonable target user group because we imagine our system being a lightweight, simple tool which lowers the barrier to creating and enjoying music.

Interviewees were students who are deeply involved with playing and creating music. The majority consisted of students in a cappella groups and a member of Princeton University Orchestra ( PUO). Priorities included arranging music, improving their music skills, and the ability to experiment. In terms of technical skills, one was tech-savvy singer, two non-technical singer, one non-technical instrumentalists — all agreed they wanted a simpler way to record music and disliked the complicated interfaces of usual digital audio workstations where users are often limited by the fact that they don’t even know many functionalities exist.

CI Interview Descriptions

When conducting our interviews we followed this process:

• We shared general idea of our project and asked why he would or wouldn’t use it.
• Asked what the users would like to see in an interface (ideas without prompting).
• Posed our ideas for interfaces to get their feedback, likes and dislikes.

We interviewed the users in their rooms or in public spaces such as coffee shops and dining halls. The process of recording music is generally isolated in a quiet spaces (usually with easy accessible software, such as those that come by default on computers), so the environment itself was not important for understanding the music-making and recording process.

Common suggestions included ease of operation, gesture control while recording, and a general expansion of features to incorporate as much functionality as possible as a recording studio. The “undo” functionality is very important for any music editing software, and needs to be intuitively integrated in the system. Editing should be able to happen in real time and be fine-tuned, so users can be precise how they edit the tracks and cut out segments on the fly. Overall, this should include all the features of high tech recording software, but maintains the simplicity of any kinect gesture software.

Suggestions from singers included the need for visual indication of loop position (like the start and finish of tracks), visual indications of beats/pulse, recommended auto-tune mode and various sound effects such as compressors and EQs. This product concept is extremely appealing to singers because other available software (Musescore, Sibelius, Finale, etc) all have electronically-generated MIDI files which doesn’t correspond to how parts will sound together in real life.

Feedback from a instrumentalist included the need to address handling of gestures — its weird to give gestures while playing an instrument. It would be useful to have different “modes” (switch from skeleton data input for kinect to depth perception data), allowing the musician to add notes. A timer countdown before recording starts would also be useful. Really like the concept of using spatial location to have different tracks.

Users also suggested that a video component would be valuable to the music-making process, especially if users could see multiple visual recordings at the same time.

ANSWERS TO 11 TASK ANALYSIS QUESTIONS:

1. What are unrealized design opportunities?

We would like people who can sing and play well (serious instrumentalists) to have an affordable pick-up-and-play recording and mixing system. Technology available is either too simplistic or too expensive and with complicated interfaces. Gesture-controls for the kinect are a new concept that can be integrated during performances or recordings. This allows people of all levels of technical skills to do a lot with the product without touching the computer.

2. What tasks do they now perform?

For music recording, our target user group uses freely available, bare-bones recording equipment instead of professional systems which are too expensive and complicated. For example, GarageBand is relatively easy to use, but still complicated for non-technical people and many often don’t recognize the power it has, and attribute undeserved limitations in sound quality because of lack of knowledge. Additionally, the editing and recording process takes many hours, at least 4 hours minimum to produce a do-it-yourself quality recording. Results are similarly for other digital audio workstations like ProTools, LogicPro, etc. Users may also use tools not intended for music recording (such as Photobooth on Mac computers) simply because they are easy and quick to use, though the quality is bad. There seems to exist a trade-off between time investment and quality with ease of use.

3. What tasks are desired?

Users would like to have a simple recording process that allows you to quickly and dynamically create music content alone or possibly collaboratively. This is allows them to improve their skills and quickly share the music, often useful in situations where others need to learn (such as new arrangements, where people would like to hear the balance of the overall blend). In particular, users want an easy interface allows musical people to take advantage of sound manipulation techniques and mixing/layering tracks without a technical tech background.

4. How are the tasks learned?

Trial-by-fire — trying to muddle through and figure out the functionalities. Our interviewees said they learned by asking people who already know how to do them, so they could never learn themselves how to make things work. There are no formal classes that they can take. Documentation online exists for these systems but they can sometimes be hard to understand — some say they don’t know where to start.

5. Where are the tasks performed?

Task performed in quiet environments (usually home, dorm room, practice room, recording spaces) and open areas. No influence of environment except for the impact on sound quality. It’s important to pay attention to how recording equipment is positioned. For example, a cappella groups sing in circular formations, which is hard to capture with a single one-directional mic, so a 360 degree mic is invaluable to capturing a recording that best matches a live performance. There is no effect due to bystanders, usually recording alone or with people who you are comfortable working with musically.

6. What’s the relationship between user & data?

Handling of data should be local, because recording music often results in catastrophic failure (the song sounds bad, the singer is off-key, etc) so you don’t want to broadcast bad recordings to others over the internet. The recordings should be private with the option to share with others. Not much of a privacy issue because the system is offline.

7. What other tools does the user have?

Laptop, home PC, cell phone, musical instruments, microphones, speakers. Microphones are extremely important to guarantee quality of sound, which might be useful to integrate into our system. There are mobile recording and mixing applications, but they are intended for casual interaction and have no ability to edit.

As mentioned before, currently available digital audio workspaces includes GarageBand, ProTools, LogicPro, and musicians even use PhotoBooth to record music.

8. How do users communicate with each other?

Not relevant for tasks related to music recording. Users often upload their recordings onto websites and youtube to share it with a larger audience.

9. How often are the tasks performed?

The tasks are performed whenever the urge to record and mix music occurs, which could be daily or once in long spans of time. Music recording is estimated to take a minimum of 4 hours, which become longer is significant editing time is taken into account. However, the time can be broken up into different chunks and worked on across an extended period of time. Therefore, it’s necessary to allow saving the workspace so users can later return to pick up where they left off.

10. What are the time constraints on the tasks?

No time constraints for the tasks, used whenever. If our device is used for live performance and collaborative music making, need minimal amounts of time to set up.

11. What happens when things go wrong?

Delete and start over again. Editing should be available on a very fine-grained scale and undos are very important.

DESCRIPTION OF 3 TASKS:

1. Single recording — If you wanted simple gesture based recording and editing, one voice role could easily be performed this way. This would involve the performer recording with the kinect. Afterwards or during recording, the performer could edit different sections using gestures. The performer would spend minimal time interfacing with the computer this way and more time focusing on the actual performance/recording.
2. A capella recording (“intro version”) — combining multiple tracks into one recording. This would be the “intro version” of recording because the performer would use default settings for everything (autotune on, equalizers set, beatbox helper).
3. Real-time mixing and recording — The performer could manipulate sound properties while recording, including dubstep, EQs, and other sound processing features. This would mean that the performer has full control over every aspect of recording, much like the functionalities available in complex recording systems but with an easier, simpler interface.

INTERFACE DESIGN:

Text Description: 

The device focuses on real-time recording music with smooth playback and simple, intuitive interface allowing for many different functionalities for sound manipulation. It will allow easier and more intuitive forms of recording compared to digital audio workstations, and a more quality alternative to rock band. Users can separately record multiple tracks and combine them into one recording, adjusting sound levels on each track individually. Can add filters and change other sound properties. Body gestures would facilitate the recording and editing process. The main innovation is using spatial location of the person’s body to detect which “part” they are recording (for a capella, would correspond to soprano, alto, tenor, and bass voice parts). This would be easier for the user to understand the multiple track layering since they have to physically move to start a new track.

STORYBOARDS:

SKETCHES:

Names & Contribution
Saswathi Natta — Organized Interview form & Questions. Did one interview
Brian Hwang – Writing
Andrew Boik – Did one Interview. Writing
Kevin Lee – Did one Interview, Finalized document [editing, combining interview descriptions, task analysis, user group narrowing]

Problem & Solution Overview
People cannot remotely explore a space in a natural way. When people watch feed from a web chat, they have no way to move the camera or change the angle, they only have the view that the “cameraman” decides to give them when recording.  They may send signals to the camera through keyboard controls or maybe have verbally command the cameraman to change the viewing angle; however, these are terrible interfaces for controlling the view from a remote camera. The goal of our project is thus to create an interface to make controlling remote viewing of an environment in the web chat setting more intuitive.  We aim to improve the situation by replacing mouse, keyboard, and awkward verbal commands to the cameraman with Kinect-based head tracking used to pan around the environment.  The image of the environment based on the change in head angle will then be displayed on a mobile display, which is always kept in front of the user.  This essentially gives a user control over the web camera’s viewing angle through simply moving his head.

Description of users you observed in the contextual inquiry.
Our target user group are students at Princeton that web chat with others on a routine basis.  We choose this target group as our project aims to make the web chat experience more interactive through providing intuitive controls for the web camera viewing angle; thus, students who routinely webchat are the ideal target users.

Person X

• Education: Masters Candidate at Princeton University
• Likes: Being able to web chat anywhere through mobile interface and easily movable camera.
• Dislikes: Web chatting with people that are off-screen.
• Priorities: No interruptions in the web chat, which might arise from poor connection quality or having to wait for a person to get in front of the camera.  Good video/audio quality.
• Why he is a good candidate: X is a foreign student from Taiwan.  He routinely web chats with his family who live in Taiwan.

Person Y

• Education: Undergraduate at Princeton University
• Likes: multitasking while Skyping
• Dislikes: bad connection quality
• Priorities: keeping in touch with parents
• Why he is a good candidate: Y is from California and communicates with her family regularly.

Person Z

• Education: Undergraduate at Princeton University studying Economics
• Likes: being able to see her dogs back in india.She wants to be able to talk to her whole family at once and watch her dogs run around.
• Dislikes: the connection issues on skype. Does not want camera to be able to rotate all the time for privacy issues
• Priorities: time management, keeping in touch with family.
• Why she is a good candidate: Z is from India and communicates with her family every 2 weeks via skype.

CI interview descriptions

We arranged to visit X’s office where he was going to web chat with his family for us to see.  He shares his office with 5 other people in a large room.  The office consists of six desks with computers and books on each.  He occupies one of the desks.  We arranged to visit person Y in her dorm room when she was going to communicate with his parents.  The interview was conducted in a standard issue dorm room where Y lives alone.  We interviewed Z in the student center, a public place, to talk both about how she webchats with her family but also about searching for friends remotely. Before each web chat contextual inquiry interview, we asked the participants some questions to gain some background context.  We learned that person X web chats with his family in Taiwan once a week. The web chats are just routine check ups between the family members that can last from 15 minutes, if not much has happened in the week, to an hour, if there is an important issue.  These web chats are usually on Friday nights or the weekend when he is least busy.  He always initiates the web chats because his family does not want to interrupt him. Person Y usually calls her parents who live in California  multiple times per week, with each session lasting from 20 minutes to an hour. Person Z webchats with her family from her dorm room, sitting at a desk. She talks to both her parents and her grandparents who live in the same house in addition to her dogs via skype. She expressed interest in being able to to talk to her family all at once with a rotating camera as well as being able to see her dogs as they run around with a rotating camera. Person Z also experienced the need to find a friend in a public location such as Frist and found that a being able to check remotely would be useful, though she felt that the camera might be an invasion of privacy if users did not want to be seen both in a home or in a public place.

After gaining context through questions, we then proceeded with the actual web chats.  X used Facetime on his iPhone to web chat with his family who were also using an iPhone. Y, on the other hand, used Skype on their laptops to web chat with their parents.  At the beginning of each web chat, we briefly introduced ourselves to the web chat partners and then allowed the web chat to flow naturally while observing as per the Master-Apprenticeship partnership model.  We briefly interrupted with questions every so often to learn more about habits and approaches to tasks.  We sometimes asked also asked questions to understand their likes/dislikes/priorities regarding the current web chat interface, the results of which are listed with the descriptions of the users.  We found that the theme of each web chat was largely just discussion of what recently happened.  Each interview also shared an interesting common theme where the participant would most of the time engage in a one on one conversation with one family member at a time.  We reason that this theme exists due to the limitations of the web camera technology.  The camera provides a fixed scope that is usually only enough to view one person through.  To engage in intimate conversation, both chat partners need to be looking directly at each other; thus, there is no room for natural, intimate conversation with more than one family member at a time.  To deal with this, our participants instead engage in intimate conversations with each family member individually.  Indeed, at one point Person X’s father was briefly off-screen while speaking to the Person X, creating a fairly awkward conversation situation.  Person X started off by speaking to his mother, then asked his mother to hand the iPhone to his father so he could speak with him.  Person Y similarly began speaking with her mother, and later the father swapped seats in front of the camera with the mother when it was his turn.  Thus, a common task that was observed across each interview was where the participant requested to speak with another member through verbal communication.  The task was then fully accomplished by the web chat partners on the other side complying with the request by ending the conversation and handing off the camera or swapping locations with another chat partner.  We reason this common task exists because there is no natural way for the participants to actually control the web camera viewing angle to focus on another person.  Instead they must break the conversation and verbally express a request to switch web chat partners.  This request can then only be completed through moving around of partners on the other side of the web chat due to the limitations of the web chat interface.

An interesting difference that we found across the interviews is that Person X largely told his father the same things that he told his mother regarding events that happened in the past week.  However, the subjects of the conversations between Person Y and her two parents differed.  We reason that this was observed because of differences in relationships with the participants and the other chat members.  Person Y feels uncomfortable discussing certain topics with her father while being able to discuss them with her mother and vice versa.  Person X, however, is equally comfortable about talking with his parents about all matters.  Person Y also multitasked by surfing the web while chatting with her parents while Person X did not.  This difference could have arised because of a difference in technological capabilities, as iPhone is a single-foreground-application device while laptops are not.  Person X, however, had a laptop in front of him but did not surf the web with it.  We reason that this is because Person X is more engaged in the web chat sessions partly because he web chats only once a week with his family while Person Y web chats multiple times a week. For person Z regarding webchat, she also talked to her parents one at a time and found that she could not communicate with her dogs at all because they would not stay in front of the camera for a very long time. Regarding finding friends in a public location, Person Z would text a friend to ask where they were before leaving her room to meet them. She would also just walk around the building until she found them, or just sit in one location and wait for the friend to find her. This took considerable time if the friend was late or texted that they were in one location but had moved. A simple application to survey a distant room would have helped with this coordination problem.

Answers to 11 task analysis questions
1. Who is going to use system?
Identity:
People who want to web chat or remotely work with others through similar means such as video conferencing will use our system.  People who want to search a distant location for a person through a web camera can also use the system.  Our user also needs to physically be able to hold the mobile viewing screen.
Background Skills:
Users will need to know how to use a computer enough to operate a web chat application, how to use a web camera, and how to intuitively turn their head to look in a different direction.

2. What tasks do they now perform?
Users currently control web chat camera viewing through:
-telling the cameraman, the guy on the other end of the web chat, to move the camera to change the view onto somewhere/someone else as with Person X.
-telling the guy on the other end of the web chat to swap seats with another guy as with Person Y.
-ask who is talking when there are off-screen speakers.

3. What tasks are desired?
Instead, we would like to provide a means of web chat control through:

• Controlling web chat camera to look for a speaker/person if he is not in view.
• Controlling web chat camera intuitively just by turning head instead of clicking arrows, pressing keys, or giving verbal commands.

4. How are the tasks learned?

Tasks of camera control are learned through observation, trial and error, verbal communication, and perhaps looking at documentation.

5. Where are the tasks performed?
At the houses/offices of two parties that are separated by a large distance.
Meetings where video conferencing is needed.

6. What’s the relationship between user & data?
User views data as video/audio information from web camera.

7. What other tools does the user have?
Smartphone, tablet, web camera, kinect, laptop, speakers, microphone.

8. How do users communicate with each other?
They use web chat over the internet through web cameras and laptops.

9. How often are the tasks performed?
-Video conferencing is weekly for industry teams.
-People missing their friends/family will web chat weekly.

10. What are the time constraints on the tasks?
A session of chat or a meeting generally will last for around one hour.

11. What happens when things go wrong?
Confusion ensues when speakers are out of view of web camera.  This often causes requests for the speaker to repeat what was just said and readjustment of camera angle or swapping of seats in front of the camera.  This is awkward and breaks the flow of the conversation.  Instead of facing this problem constantly, our interview participants have one on one individual conversations with their web chat partners.

Think about the tasks that users will perform with your system. Describe at least 3 tasks in moderate detail:
– task 1 : Web chat while breaking the restriction of having to sit in front of the computer

• – Allow users to walk around while their chat partner intuitively controls the camera view to keep them in view and continue the conversation
• -Eliminate problems of off-screen speakers.
• – current difficulty rating: difficult
• – difficulty rating with our system: easy

– task 2 : Be able to search a distant location for a person through a web camera.

• – Allow user to quickly scan a person’s room for the person.
• – Can also scan other locations for the person provided that a web camera is present.
• – current difficulty rating: difficult – impossible if you’re not actually there
• – difficult rating with our system: easy

– task 3 : Web chat with more than one person on the other side of the web camera.

• – Make web chat more than just a one on one experience. Support multiple chat partners through allowing the user to intuitively change camera view to switch between chat partners without breaking the flow of the conversation.
• – current difficulty rating: difficult
• – difficult rating with our system: moderate

Interface Design
Text Description:
With our system, users will be able to remotely control a camera using head motion which is observed by a Kinect and mapped to the camera to change the view in a corresponding direction. The user will keep a mobile screen in front of them so as to always view the video feed from the camera.  This provides a more natural method of control than other webcam systems and allows a greater amount of flexibility in camera angles, as well as an overall more enjoyable experience.  Our system thus offers the sole functionality of camera control through intuitive head movement.  Current systems either require using a physical device as a controller or awkward verbal commands to control a remote camera angle while our system allows users to simply turn their heads to the turn the camera, similar to how a person would turn their head in real life to view anything that is not in their vision. The system will essentially function like a movable window into a remote location.

Storyboards:

Task 1 – Able to move around while video chatting

Task 2: Searching for a friend in a public place

Task 3: Talking to multiple people at once

Sketches:

View user would have of the mobile screen and Kinect in the background to sense user rotation

Example of user using the mobile screen as a window into a remote location

Contributions:
Gene – writeup
Alice – interviewed physical trainer, runner, some writeup
Rodrigo – got fitted for shoes at a running store, editing
Phil – some writeup, storyboards, sketches, & interface design
All – interviewed running store employees, interviewed sports doctor

Problem and solution overview:

Runners frequently get injuries. Some of these injuries could be fixed or prevented by proper gait and form. The problem is how to test a persons running form and gait. Current tools for gait analysis do not provide a holistic picture of the user’s gait. Insole pressure sensors fail to account for other biomechanical factors, such as leg length differences and posture. We will build a system that integrates pressure sensors, gyros, accelerometers, and flex sensors to measure leg and foot position. By combining foot pressure and attitude information with joint positions of the lower body, our system will capture the necessary information as one package.

Description of users you observed:

Our target group is high-end amateur runners, and the support system of running store employees and physical trainers who cater to them. The popularity of upmarket running stores that employ video gait analysis show the size of the market and the desire for such systems.

User 1: Sports physician
This physician holds a biology degree, and has completed training in internal and sports medicine. She has worked as a consultant for the NCAA, and as a team physician for US National teams. Her priorities are a holistic view of sports health, minimizing injuries and their effects, and recommending appropriate strength training and/or orthotics. We chose a sports physician, because we believe that our system could be used by physicians trying to help runners with their injuries.

User 2: Avid amateur runner
This undergraduate student ran on his varsity team in high school, and continues to run 6 times a week. Injuries have kept him from running on a team in college. His priorities are staying healthy while running at a highly competitive level. We chose him because he belonged to our target group of people who are actually running and going to either have people use our technology for him or even potentially use it himself.

User 3: Running company manager
This person ran on a varsity college team, and continues to run avidly. He also manages a running company. His priorities are providing an enjoyable customer experience and selling shoes. He was a good candidate to interview because we think that a company like his might be interested in using our sensor system to help with picking out the correct shoes for clients.

User 4: Customer 1
This customer had plantar fasciitis, and needed a new pair of shoes. His priority was buying a pair of the same shoes he had.

User 5: Customer 2
This customer wanted to purchase orthotics for her shoes. Her priority was comfort.

CI interview descriptions:

When possible, we visited the interviewee in his or her usage environment. Both the sports physician and the running company manager emphasized the difficulty and importance of considering the whole picture when trying to improve running health. They consider foot positioning and pressure, joint position, body type and proportions, and stature, as well as type and environment of activity. We also repeatedly encountered the opinion that comfort promotes good health. The running company manager disagreed with a commonly advocated theory: that reducing cushioning causes improper gaits to become more painful. The manager advocated strength training as a means of improving gait, and argued for shoes that make the runner comfortable. The sports physician also strongly advocated for strength training.

Both the physician and the running company manager indicated that gait can be related to injuries. They both said that the first thing the look at is the person’s foot to get a sense of the structure of the foot itself. From there, the two diverge. The physician engages more with the person’s body. She checks for issues of flexibility, muscle imbalance and asymmetry. The running company manager was clearly aware that those were factors, but he chooses to ask clients to run on a treadmill, which he videotapes and then plays back in slow motion to see how the client is running. The avid runner said that he can tell a little bit about his pronation by looking at the bottom of his shoes. For the most part, he bases things more on how he feels than through quantifiable information. He has gone in for professional gait and form consultation before.

To interview the sports physician (user 1), we visited her workplace. Unfortunately, due to patient privacy concerns, we were unable to observe her at work with a patient. Still, we asked her to go into detail about how she would work with a hypothetical patient in order to accomplish a successful contextual interview.

To interview the avid runner (user 2), we chose not to run along, because we did not think we could keep pace. If the runner slowed his pace to match ours, the situation would be artificial. However, we asked him to illustrate various elements of technique, and how he currently assesses his running style.

To interview the running company manager and customers 1 & 2 (users 3-5), we visited the running company. We observed the running company staff at work with customers. Also, Rodrigo got fitted for a pair of shoes, including slow motion video analysis on a treadmill.

Task Analysis questions:
1. Who is going to use the system?
We envision two main groups of users: relatively high-end runners (who do significant amounts of running regularly), and those who work to support them (running store employees, physical trainers, and sports doctors). Those in the second group will be utilizing the system for the benefit of the first group, but members of the first group who are especially concerned with their gait could also purchase and use their own unit.
2. What tasks do they now perform?
Currently, runners mainly analyze their gait and manner of running mostly when purchasing shoes or after injuries. As we learned from our interview with a frequent runner, he had his gait analyzed after being injured. In order to analyze gait in a running store, they currently use a slow-motion camera and muscle receptors. Also, the runner we spoke with mentioned that he occasionally pays attention to his form while running to make sure he is moving efficiently.
3. What tasks are desired?
One desired task is a way of analytically determining the mechanics of an individual’s gait and movement – either to fit orthotics or to adjust the runner’s technique. Additionally, it is desired for a runner to be able to determine (while running) how their form has changed with fatigue and environment (running differently on different surfaces, for example).
4. How are the tasks learned?
Runners often go to running stores or personal trainers to learn more about gait and proper running technique. Specialty running shoes are typically tested and viewed at running stores, where analysis of gait occurs. After injuries, athletic trainers and sports doctors also might assess one’s gait, having the user run on a treadmill in a training room to observe their form.
5. Where are the tasks performed?
The tasks are performed in three distinct areas: on a run (wherever the run is happening), in a running store, and in a training room or doctor’s office. The tasks performed in the first location tend to be less analytic and more subjective, while the other two locations tend to perform tasks with specialized observation of the runner.
6. What’s the relationship between user & data?
The running user has very little access to data – they are entirely dependent on their own perception of their form while running. This perception can be rather inaccurate, especially if the runner is fatigued. In a running store or training room, the runner’s support user (either a trainer, sport doctor, or store employee) is analyzing the data of the runner’s gait and technique, and then presenting it in a manageable format to the runner, possibly with a recommendation of shoe type or technique modifications.
7. What other tools does the user have?
The runner will often have an electronic device with them, such as an iPod or mobile phone, which may also have GPS capabilities. This presents a useful opportunity for live updates of gait and technique information. In a running store, there is likely to be a treadmill, video cameras, and a computer for accessing information. Thus, the type of tools available to the user is highly dependent on the setting.
8. How do users communicate with each other?
The runner communicates with other support users when buying shoes or after an injury, which are both times in which they feel there is potential for serious modifications to technique and gait. In these situations, they often try to offer information from their experiences running, and the areas where they feel pain or discomfort to the expert, who then gathers data from observation and makes a recommendation of a type of running shoe or a technique change.
9. How often are the tasks performed?
The task of observing one’s technique while running happens at irregular time intervals; according to the runner we spoke to, he thinks about it especially frequently when he becomes fatigued during a run. He runs 6 times a week, and would reevaluate his form several times on each run. Also from our discussions with him and the running store employee, we found that running shoes are typically replaced every 400 miles or so. If the shoe is working properly, the task of getting an expert opinion isn’t performed and a similar shoe is purchased. If the user has developed an injury or some discomfort, however, they then perform the task of consulting an expert.
10. What are the time constraints on the tasks?
While running, the user does not have much time or focus to devote to evaluating gait while still moving normally. Feedback on technique should be relatively immediate in this environment, since it is much less relevant to the user how they were running several minutes ago. Especially if the user begins to feel discomfort during the run, live feedback is needed. In the setting of a running store or training room, the time constraint is limited by the customer/user’s comfort. In the running store, the typical interactions we viewed were on the order of 20-30 minutes for purchasing new shoes and evaluating gait.
11. What happens when things go wrong?
If a runner isn’t sure about their technique, and think it might lead to an injury, they will usually stop running or at least shorten their run. In a running store, the employee mentioned that the ideal way to test a user would be to have them run for at least 30 minutes and then test them in a fatigued state. He said that viewing someone when they are fully rested (and aware that they are being observed) can be problematic and can sometimes lead to errors. The store had a 15 day trial policy for their shoes so that users could return if the analysis turned out to be incorrect.

Description of three tasks:

Task 1:
While running, assess gait and technique. Currently this is done by mentally taking check of body position. Thinking about one’s body is simple, but getting accurate results is very difficult. With our proposed system this will involve the initial setup of placing the sensor in your shoe and connecting any other necessary equipment, and selecting the settings that you wish to have during the run. Ideally once the person is on the run this task will involve no more than pushing a button on the watch/iphone to get feedback. We could either have the system provide automatic updates, alerting the runner while they are running that they are pronating or striking too hard on their heels, or it could be manual and the user could push a button to get feedback in their current gait.

Task 2:
After an injury, evaluate what elements of gait can be changed in order to prevent recurrence. Currently this is a very difficult task. An official gait analysis that is done by specialty places involves a lot of money, stop motion analysis, and electrical equipment. More frequently people figure out what is hurting, examine the person’s body type and peculiarities, and does a number of exercises to test flexibility and musculature, from that they can approximate what might be wrong with the current gait. Ideally with our system this would be a simple to moderate level of difficulty. There will still be a fair amount of sensors that will need to be attached to the person’s body and shoe, as well as some analysis of what the data is showing. Once set up, our system will display what is happening to the persons weight on their feet as they run as well as displaying other characteristics of the persons running technique. Ideally our display will be clear and intuitive enough that the analysis should not be too difficult.

Task 3:
When buying running shoes, determining what sort of shoe is most compatible with your running style. This is currently a moderate level task. This involves doing an initial examination of the person’s foot and leg structure, as well as measuring for size. After that it involves trying on a variety of shows and running with them on a treadmill. More shoes are tried until one both feels comfortable enough to the runner and the form looks decent when the person is videotaped running and is played back in slow motion. Our solution might be about the same level of difficulty, but will hopefully be more precise. Mutiple shoes will likely need to be tried on and the user will still need to run on a treadmill. Sensors will need to be attached as well but this will not be too difficult. The analysis will be far more precise than just viewing the person’s feet and will ideally lead to better fittings, and potentially allow for quicker selection of the correct shoe.

Description of User Interface:

We envision our system working on both desktop and mobile interfaces in order to properly serve all of the tasks we are considering, Individual runners would benefit most from a mobile interface which could be operated from a phone, since it would enable them to get live updates. This is a major departure from existing systems, which either require the user to be in a lab or do not provide feedback in real-time. For the users who will use it to support runners, however, we feel that a desktop interface would be useful, because it would be easy to navigate. These support users would require more information than a runner who is using the device for live feedback – medical diagnoses and shoe selection are more sensitive to information. For the live interface, the functions would be to track the distance and pace of the runner, while also giving them advice on form. While the first two functions are commonly available, the third is not currently offered to consumers. In the desktop interface, the doctor or store employee would be able to view animated pressure heat maps of the user’s feet, as well as gyroscopic information of how the foot is moving through the air. Current analysis by film accomplishes these tasks, but in a much less precise way. Furthermore, the user could take the device and go for a typical run on their usual surface, gaining more realistic data for the support user. The main improvement offered by the system would be the ability to gain precise data in a more realistic setting for the runner.

Storyboards

Sketches of the screen

Group # 21

Group Members & Contributions

• Shubhro Saha — Blog Post, Interviews
• Andrew Cheong — Blog Post, Interviews
• Miles Yucht — Blog Post
• David Dohan — Blog Post

Problem & Solution Overview

The problem we aim to solve is that of computer user authentication: verifying credentials when logging into a database, a web application, or a touch-screen cash register, for example. The prevailing solution has been to prompt users for a username/password combination. But such a solution, while dominant, is limited to keyboard-based human-machine interaction. As interfaces gradually migrate to touch-screen and voice-based interactions, the keyboard is becoming less important as an input device. From an accessibility point of view, some individuals find learning to type on a keyboard extremely difficult. Security-wise, passwords can be cracked by brute force input methods. Our solution is to authenticate by means of a combination of hand gestures performed in a “black box”, detected by LEAP motion. This solution is more difficult to hack by algorithmic methods because it requires a human hand, and is more natural and potentially a faster method of authenticating than typing into a keyboard.

Description of Contextual Inquiry Users

Our target user group would be composed of individuals are are required to sign in and out of accounts on a regular basis. Usually, signing in and out requires the user to type in their username or swipe a card to verify their id and then they follow that up with typing in a password or a providing a user PIN number. The student uses her laptop for many different reasons such as academic studies or social purposes. Being at a university, the student tends to carry her laptop around in public. While she expressed irritability for complex passwords for internet accounts that she visits less frequently,  she appears to be content with her current passwords. She expressed concern for public acceptance of carrying a box for verification or to provide hand gestures at a computer. This provides insight into why HandShake might be appropriate for stationary computers. For a cashier, they use an id card to swipe into a cash register. Her primary concern was to ensure the security of the register and that only people allowed can access the register. She expressed concern about keeping track of her id card since it is so valuable for her work. HandShake removes the necessity of maintaining a physical key/card while ensuring the security by identifying one’s hand as well as the gestures.  Even from a librarian standpoint, who must access the library network frequently when checking in/out books as well as including new resources to the library, they must provide long passwords to authenticate themselves each time. Handshake helps remove the necessity to memorize long passwords and eases the tasks in hand for the librarian.

Contextual Inquiry Interview Descriptions

Procedure. In pairs, we scouted out interviewees in their “natural habitats”. Generally, we asked them all the following questions to understand their experiences and openness to the idea of alternative authentication schemes:

1. On a day-to-day basis, how often do you login into a computer system?
2. Do you find keyboards logins annoying?
3. Do you find it annoying that passwords require so many special characters?
4. Would you consider an alternative approach to logging in?
5. In the ideal world, how would YOU like to login to such a system
6. Would you appreciate coming up to the computer system and it logging in for you automatically?
7. Go into talking about our product being a derivative of that
8. Do you see problems in using our product?
9. Would you feel comfortable using the product?
10. Would you find a handshake easier to remember than a text password?

Common themes. Most of our interviewees found text passwords in the status quo to be frustrating when they require a set number of letters and symbols. They all value speed of authentication, and were all willing to consider alternative methods like HandShake. However, some common concerns included uniqueness of the handshakes generated.

Student: The most common purpose for the student to sign in or out of an account is when she uses her laptop and when signing into internet accounts such as Facebook. She estimates that she signs into her laptop approximately three times a day and signs into a total of three different internet accounts. When asked about current day username/password approach and the complexities of special characters, numbers, and cases, she did mention that it annoying especially when she signs up for accounts that she enters less frequently and often forgets the password. She also explained that she would be totally open and willing to try a simpler technique to signing into an account. When describing the hand gesture approach, she initially expressed concern about the unusualness to make gestures at one’s computer but was comforted that the individual would do these gestures inside a box thus providing more security as well as not being out of place. While transportability and use of HandShake while on the go proves to be a problem for a student, she believes that this could be very appropriate for stationary desktop accounts such as home computers.

Cashier : She has her own ID card that she can use to swipe into her cash register. She does it at least three times a day during her 8-hour daily shift. Her manager gave permissions for her to access that register and no other registers in Frist. She feels “50-50” about the responsibility of having to carry a card. While she understands the security protocol, she sometimes worries about losing it and being “written up” for a replacement. When asked about her openness to alternative authentication schemes, she gave a positive response. With regards to gesturing to a cash register to authenticate, she was OK with it as long as the hand could be recognized specifically. Specifically regarding the idea of HandShake, she liked the idea as long as the system identifies individuals reliably. Reliability seems to be a dominant theme. When asked about other concerns regarding HandShake, she stated she said she had none and that she would find hand gestures easier.

Librarian. We spoke to biological sciences librarian. She purchases science materials, speaks to students one-on-one and primarily to support research and learning. In this effort, she does find herself having to login to resources often, but anything that the library owns or the university subscribes to are automatically authenticated based on access through the Princeton University network. She finds it annoying to find passwords of a longer length, as they are harder to remember. She would definitely consider alternative methods of authentication. Anything not requiring numbers or symbols is great– she loves using a phrase in her textual passwords. When presented with the idea of HandShake, she was open to the idea, but had concerns about the uniqueness of passwords created. From her perspective, there’s “only so many gestures you can make”.

Answers to 11 Task Analysis Questions

1. Who is going to use system?

   • HandShake would be used by individuals who are required to sign in and out of accounts frequently such as librarians, cashiers, as well as student to access public computer accounts.

2. What tasks do they now perform?

   • Most if not all forms of signing and out require individuals to enter a username and password pair and the system would verify accordingly.

3. What tasks are desired?

   • We want to device an approach that allows users of this product to sign in and out with less time, less effort, and more security. After identifying that the user is the correct user (either through facial recognition or selecting an option) HandShake allows the user to present different hand gestures inside a blackbox as his/her password. This requires no typing of a password, clicking, just simple hand motions. Hand gestures are so primal and innate that humans had such gestures since way back when. This innate behavior may facilitate a common practice such as signing in and out of an account.

4. How are the tasks learned?

   • When HandShake is adopted, rather than simply presenting the username and password text file, they can be prompted to identify themselves by either selecting from a list of ids and prompted to insert their hand inside HandShake and provide the necessary gestures to verify themselves. A simple tutorial can be provided for first time users and the tutorial will no longer appear for users who are comfortable with the tasks.

5. Where are the tasks performed?

   • The tasks are performed in front of systems where authentication is required. This depends on the user, but for our focused cases: a librarian might authenticate at a computer to access a database, a cashier would authenticate at a register, and a student would authenticate at a computer cluster terminal.

6. What’s the relationship between user & data?

   • Anyone with potential access to the system should be able to submit a handshake (ie, they have a valid username). The username can be selected by tapping on-screen (works well for a list of recent users on the same computer) or facial recognition can identify the individual when he/she approaches HandShake, and issue a handshake prompt to authenticate.

   • The data the users access after authenticating is outside the scope of our problem. We’re concerned up to the point of successful authentication. Indeed, much of the data and privileges obtained after authentication may be sensitive and/or personal.

7. What other tools does the user have?

   • Users usually have cell phones and PCs. The PC is probably what is going to be authenticated into. The cell phone would be a useful tool in the handshake reset verification process (see below.)

8. How do users communicate with each other?

   • In the authentication process, users usually do not communicate with one another.

9. How often are the tasks performed?

   • Users might perform the same tasks multiple times a day, depending on how often he/she authenticates with the systems concerned. For example, a cashier needs to authenticate with his/her employee credentials every time he/she changes registers. On the other hand, a student logs into Facebook much less frequently because the system leaves the user authenticated for some period by default.

10. What are the time constraints on the tasks?

    • Usually, users are authenticating a system to obtain privileged access to data and actions. Authentication should take no more than 10 seconds– ideally, performing a handshake is faster than typing in a username and password

11. What happens when things go wrong?

    • If the user forgets his/her handshake, the system provides a means of “resetting” the handshake after authenticating a different way (Mother’s maiden name, text message confirmation, etc.)

    • If the correct handshake is performed, but the system does not recognize it, the user should reset their handshake to a clearer one.

Description of Three Tasks

The three tasks users might perform are the following (in ascending order of difficulty):

Current method for first two tasks: users currently authenticate by typing a username/password combination. The current difficulty level of this varies widely by individual and application device. For example, new computer users find difficulty typing into a keyboard, so authentication takes some time. On the other hand, most mobile phone users could probably relate to the annoying experience of authenticating into mobile apps and web sites with a tiny keyboard.

1. User Profile Selection / Handshake Authentication — In this scheme, most applicable to students at a university computer cluster, the user approaches the system and selects the user profile he/she wishes to authenticate into. This can happen in one of two different ways: (a) the profile is automatically detected by facial recognition, or (b) the profile is selected from a list of possible/recent users on the screen. Then, the user proceeds to perform his/her secret handshake sequence in a “black box” of sorts that contains a LEAP motion detector. If the handshake is correct, the system will login. Otherwise, the user will be given another try. We anticipate that performing a secret handshake will be easier and faster for users, especially for new computer users and individuals on mobile devices.

2. Card Swipe / Handshake Authentication — As an alternative to user profile selection from the screen, some contexts might find it appropriate to select user profiles by swiping an identification card. This is especially true and supermarkets and convenience stores where users already have such cards to perform common authentication tasks around the store. As a means of confirming the cardholder’s identity, the user can proceed to perform a secret handshake as described in Task #1 above. From the cashier’s perspective, we anticipate the authentication process will be faster with a handshake– time is of the essence when serving other customers in this context.

3. Handshake Reset — In this task, the user reset his/her secret handshake sequence for one of usually two reasons: (1) they forgot their previous handshake or (2) they seem to remember the handshake, but the system is not recognizing it correctly. For both of these cases, the user must proceed to reset the handshake by verifying their identity through other means. For example, the user might receive a text message containing a secret code they should type into the system. Or, the user will be asked for personal information previously set during the user creation process (mother’s maiden name). A combination of these secondary authentication schemes would be the best solution. Though seemingly cumbersome, we want this reset process to be as robust as possible. These procedures are something users are already familiar with from using other web applications.

Interface Design

Text Description of System Functionality
When the user uses the system, it will be able detect the identity of the user who approached the system by facial recognition. Then, it will confirm this identity by presenting the propose the identity, offering the user to change it, and asking the user to enter his/her handshake. If the handshake is correct, the system authenticates. Otherwise, the user can try another handshake for a limited number of times. This idea differs from existing systems because, for many people, a hand gesture can be easier to remember, and it’s also more secure than existing text passwords because it cannot be broken by brute-force algorithms. Other security systems have different modes of verification such as inserting a physical key, using biometrics, or providing a password of some sorts. By allowing a sequence of hand gestures, it combines the concept of a physical key as well as incorporating one’s biometrics. Physical keys are often difficult to manage because one must always carry it around, while it can be safely assumed that most people will have hands. Password have become difficult to manage with increasing safety precautions requiring more complex passwords with special characters, both cases, and numbers.

Three Storyboard for Our User Tasks

Sketches of System Itself

GROUP NUMBER: 12
GROUP NAME: Do you even lift?
GROUP MEMBERS:

All of us observed people in Dillion Gym. We worked collaboratively on a google doc as we sat together in the same room so we overlapped on basically every task.

Adam Suczewski: Final story board sketches, interface sketch descriptions, 3 task descriptions, interface text description, compiled blog…
Andrew Callahan: Drew final interface sketches, wrote problem overview, contextual inquiry, task analysis, rewrote many parts to improve coherence…
Matt Drabick: Drafted story boards and interface sketches, interviewed people in Dillion gym, task analysis questions, interview transcripts…
Peter Grabowski: Interviews in Dillion gym, task analysis questions, storyboard idea compilation…

PROBLEM AND SOLUTION OVERVIEW:

Many people lift weights to build fitness and good health. Some lifts are difficult to do correctly, and errors in form can make those lifts ineffective and dangerous. Some people are able to address this by lifting with an experienced partner or personal trainer, but many gym-goers do not have anyone knowledgeable to watch their form and suffer from errors as a result. We aim to solve this problem by having a computer with a kinect watch trainees as they perform lifts, and point out errors in form and potential fixes.

DESCRIPTION OF USERS YOU OBSERVED IN THE CONTEXTUAL INQUIRY:

Our target user group is the gym-goer with an interest in lifting or learning how to lift. This seems like a valid choice, as we envision our system serving as an instructional tool for lifters of all skill levels.

We started out our contextual inquiry by going to the weight room in Dillon Gym and watching students lift weights, paying attention to how they and their friends monitored their form. Most people were all at the gym for personal gains (i.e. they were not compelled to be there by a team). These personal gains varied among people but included goals like losing weight or building muscle mass. People ranged in apparent expertise from beginners to very advanced, and were in groups of 1-3 (i.e. some were alone). More details about users are given below in the CI Interview Descriptions.

CI INTERVIEW DESCRIPTIONS:

We conducted interviews with acquaintances that we encountered while lifting at Dillon Gym. We asked a short list of questions about their history in weightlifting, whether they went alone or in groups, and how they went about keeping their form correct. We found that people sometimes lifted on their own, or sometimes with friends. People find going with friends useful for motivation, for getting feedback on form, and for spotting in certain exercises. However, this comes with the downside of having to change weights more frequently and of finding a mutually agreeable time to meet.

People lifting with friends will sometimes get feedback on their form from the partner, depending on their relative expertise at the lift (as well as how vocal the partner is). This will usually come in the form of the friend giving cues in the middle of a set (“keep the back in!”) or more detailed feedback after the set is over, often with friend attempting to demonstrate with their body what the problem was and how it should look instead. Trainees lifting by themselves do not get this feedback, and self-report ignoring minor problems in form, and noticing more severe problems when they sense discomfort/pain.

The biggest difference we noticed was that people who lifted alone were much less likely to be concerned about form than those that went in groups. It might be that people lift in groups because they want to be careful about their form, and people who are less concerned just lift alone. It could also be that not having friends around nagging you about subtle problems leads people to just let subtle problems persist.

We also interviewed people in Dillon who do not lift but use the machines and cardio equipment. We were interested in asking these people why it is that they do not lift. We found that the main reasons were that they do not know how to lift, they are afraid of getting too big (particularly girls), or they found free weights intimidating. Most people said that they would lift if they had someone to teach them.

ANSWERS TO 11 TASK ANALYSIS QUESTIONS:

1. Who is going to use system?
People lifting weights will use the system. Lifters of all experience levels can use the system to provide cues and feedback while lifting, and people new to a specific lift could receive a full guided tutorial from the system on that lift. Lifters encountering the system will range from eagerly seeking and heeding the advice of the system to ignoring and even being annoyed by cues from the system (preferring their conception of how the lift should be executed). We need to strike a balance in presenting crucial information to lifters while noticing when they want the system to stay out of the way.

2. What tasks do they now perform?
Users can be split into two groups – those who lift alone and those who lift in pairs/groups or with a dedicated trainer. Users who are alone do not receive any feedback on their form, and will either ignore their form, or look at themselves in a mirror when available to check their form. Lifters in a group will sometimes receive cues from their friends when their form is flawed. However, having a partner is no guarantee of useful feedback – partners are observed and self-report sometimes being too inexperienced, distracted, or misinformed to help.

3. What tasks are desired?
We would like trainees to be able to confidently achieve good form and know when they’ve made mistakes, even if they’re lifting alone. We would also like these users to be able to track their performance over time in detail, including being able to watch video of them doing a set from any point in the past.

4. How are the tasks learned?
Currently, our potential user receives instructions from a knowledgeable trainer, who will demonstrate a lift and then provide feedback about how their form was. Personal trainers are often very expensive, so users sometimes have friends teach them lifts. The friends might not have perfect form or be very critical of the user, so bad habits can develop from the beginning. Our system display will provide instructions for the user. Users will follow the prompts from the system to select the exercise they want to perform. The system will give accurate feedback and keep track of it between sessions. Lifters often learn to keep track of lifts in a notebook or on a website from others.

5. Where are the tasks performed?
The lifts we are focusing on are usually performed in a school, team, or commercial gym. Lifts are performed in various dedicated stations in the gym, and are usually done with few interruptions. We could have a system at each station dedicated to the lift, or place one or more systems on a movable cart that the user could position. Lifts can also be done in the home, if the user has the right equipment. Our system will be an addition to their home gym set-up.

6. What’s the relationship between user & data?
The system will collect data from the user’s lifts, including their repetitions, weights, date and time of workout, as well as any flaws in the users form. The system (if the user elects to pay for an account) will upload it to a companion site, and provide a detailed record of their history and flaws, as well as allowing the user to watch a wireframe.
Privacy may be a user concern, although information about users weight-lifting habits is certainly less sensitive than their health (HIPAA) or education (FERPA) data. Of course, there are always exceptions (such as professional weightlifters, who may want to keep their training data private), but a simple username/password system with basic encryption should provide more than enough security for online access. A more basic approach might be to have users log into the kiosk by holding their gym card up to the camera (combined with face matching). Users can share their data with other users at their discretion.

7. What other tools does the user have?
Users currently have few options available to them for acquiring reliable, high quality feedback on their weightlifting form. Methods include watching themselves in a mirror (although the very process of twisting their head to watch may negatively affect form). Users can also ask peers for feedback, although as mentioned above, users may be hesitant to ask strangers for help. Finally users think about their own body mechanics, although this method is far from accurate. The user can also take notes about their lifts and keep track of that as well as their reps and weights. Several applications make that easy, such Fitocracy, which has additional space for the user to enter notes relevant to the workout, although Fitocracy does not monitor your form.

8. How do users communicate with each other?
Many users go alone, in which case it’s unlikely they communicate with anyone else. From time to time, one user may ask another to spot them during a set, but it’s very rare for one user to ask a stranger to provide feedback on their form. If users go with a partner, they’ll occasionally provide spoken feedback to one another, either during or after a set. However, this feedback is of unknown quality. Users may also engage with trainers, whom they pay to provide feedback. In this case, the trainer provides frequent spoken feedback of high quality after every set, but the service is very expensive.

9. How often are the tasks performed?
As often as the user goes to the gym to lift. This could be anywhere from once a week to every day. Our “Just Lift” mode addresses those users who are in a rush, and allows them to get and out of the gym quickly, while still identifying major flaws and providing feedback. Our “Teach Me” mode provides more feedback to those users who need it, whether they use the system more infrequently or have more time to spend at the gym. Users can switch between each mode seamlessly, allowing them to pick the one that best suits that day’s needs. Users might look back over old workouts every month or two months in order to decide how to adjust their workouts or to make a whole new workout plan. This process might take a 15 to 20 minutes or as much as a few hours depending on how focused the user is on lifts.

10. What are the time constraints on the tasks?
As long as the user wants to spend at the gym. There are no set time constraints across all users, but each individual user may have their own constraints depending on their schedule. An average session at the gym is about 90 minutes, although this could range anywhere from 30-120 minutes depending on the user. Frequent constraints seen among users are needing to get to work/class on time (if lifting beforehand), or not wanting to get home too late (if lifting in the evening). As a result, the same task could be hurried or possibly wait, depending on the individual users time frame. There’s no timing relationship between tasks — users pick one of the available tasks, and complete it in their preferred order.

11. What happens when things go wrong?
Serious injuries across the entire body are some of the more grave potential problems, but bad form can also lead to reduced performance in lift. The only backup system would be a spotter that can “rescue” the lifter if they cannot complete the lift by helping them drop the weight safely. This is especially important in a bench press, where user can stand above and take some of the weight off the lifter. In an squat, the lifter is more responsible for being able to drop the weight and step away if it is necessary.

DESCRIPTION OF 3 TASKS:

Our first task is to provide users feedback in their lifting form. We will do this by capturing their lifts with a kinect, processing the data associated with their movements, and outputting the result. We expect this to be moderately difficult, but we are confident that we will be able to figure the kinect out and build an accurate, useful device.

Our second task is to track users between sessions. The idea here is that users will be able to log in by holding their id card up to the kinect camera. The system will then associate that user’s data with that user so it can track lifting history. Users who log in will likewise be able to log in to a web interface at home and view their lifting data. We expect this to be challenging but believe that getting the core functionality down should not be a problem. It may be hard to develop our entire system and then build a web interface on top of it, but it should not be a problem to incorporate some sort user recognition/history into the system.

Our third task is to create a full guided tutorial for new lifters. Here, we plan to show the user pictures, videos, and text descriptions of the exercise We will then encourage the user to try the lift themselves while we monitor there movements with the kinect and provide realtime feedback. After implementing the first task, we don not forsee too much difficulty with this one. It seems to only involve creating instructional content as well as creating a user experience better suited to a first time lifter.

Details of the implementations of these 3 tasks are described below.  

INTERFACE DESIGN:

Text Description:

Our system is an implementation of the 3 tasks stated above. Using a touch screen display, users will choose to either get feedback on their lifts or learn how to lift. Likewise, they will choose whether or not we will keep their data for future access by choosing whether or not to log in. Once they have selected what they want to do, they will either perform their lifts, or follow our tutorial on how to lift. This is the core functionality and the scope of the system. The benefit of this system is that we intend for it give the kind of advice people typically get from a personal trainer. By providing users with this advice, we can help them maximize their health by maximizing their workouts and helping them avoid injuries associated with bad form. There do not seem to be an similar automated systems in existence. While our system may not initially have the credibility of a human trainer, it has the advantage that it is always available to an person using the piece of equipment it is integrated with, gives objective feedback, and tracks user progress.

Story Boards:

1) Monday? More Like Squat Day!
2) Squats! All Right!
3) ?How’d I Do?
4) Monitor: Good… but you look like you’re leaning back a bit
5) Ahhhh. Thanks.
6) I’ll nail it in the next set. (Next set starts in 1:29).

1) Bob Here!
2) Kinect: Woah! You’re leaning back!
3) Later… What did I do today? Oh yeah! I had sploppy curls.
4) Better do my stretches!
5)Kinect: Hey Bob! Watch out for lean back on those curls today! Bob: Gosh! Thanks!
6) Kinect: Great Bob!

1) I want to lift but I don’t know how 🙁
2) Monitor: Learn to Lift!
Guy: !?What could it be?!
3) Woah! It’s teaching me!
4)1 month later… I feel so fit! So healthy!

Sketches:

We envision our system consisting of a kinect, a computer for processing, and a touch screen display. Our touch screen display will be the only component with which users physically interact. If we do not have a touch screen computer for our prototype, we wil substitute an ordinary laptop computer.

This is our proposed startup page. From this page, users can select the exercise which they are about to perform. They also have the option to click the “What is This?” button which will give them information about the system.
After selecting an exercise, users can enter either “Quick Lift” mode or “Teach Me” mode. In “Quick Lift, “our system will watch users lift weights and then provide technical feedback about their form at the end of each set. In “Teach Me” mode, the system will give the user instructions on how to perform the lift the selected. This page of the display will also have a live camera to show users that the system is interactive.

In the top right corner of the display too, users can see that they have the option to log in. If they log in, we will track their progress so that they can view it in our web interface and so the system can remember their common mistakes for future workouts.
In “Quick Lift” mode, users have the option of receiving audio cues from our system (like “Good Job!” or “Keep your back straight!”). Users will then start performing the exercise (either receiving audio cues or not). Once they are finished with a set, we will show a screen like the one below. On the screen we will show users our analysis of each repetition in their previous set of exercises. We will highlight their worst mistakes and will allow them to see a video of themselves in action. This screen will also allow to see their result from previous sets. Likewise, if a user was logged in, this information would be saved so that they could later reference it on a web interface.

If a user selects “Teach Me”, they are taken to a screen like the one below. This screen gives a text description, photos, and a video of the exercise. After reading the page, the user can press the “Got it!” button. The system will then encourage the user to try the exercise themselves using the unweighted bar. After the user successfully performs the exercise a number of times, the system will prompt the user to try that exercise in “Quick Lift” mode.