Team Colonial Club Final Project – PostureParrot

Team Colonial Club, Group 7

David, John and Horia

Project Description

The Pos­turePar­rot helps users maintain good back posture while sitting at a desk with a computer.

Project Blog Posts



  1. 0:00 – 0:05
    1. User positions back into desired default posture and hits “Set Default Posture” on the GUI
  2. 0:00 – 0:20
    1. User deviates back from default posture and responds to the device’s audible feedback to correct his back posture.
  3. 0:20 – 0:35
    1. User adjusts the device’s “Wiggle Room” through the GUI.
  4. 0:35 – 0:50
    1. User tests the limits of back posture deviation that are allowed by the new “Wiggle Room” setting.  It is noticeably more lenient.
  5. 0:50 – 1:00
    1. User adjusts the device’s “Time Allowance” through the GUI.
  6. 1:00 – 1:11
    1. User tests tests the time it takes to receive feedback from the device with the new “Time Allowance” setting.  It takes slightly longer to receive feedback than before, meaning that short back posture deviations are tolerated more often.

Changes in Working Prototype

Bulleted list of changes that we have made since P6 and a brief explanation of why we made each change

  • We now play an audible confirmation when a new default back posture is set.  This is done through the Piezo sensor at a different pitch than the back posture deviation audible feedback pitch.

    • Through our obser­va­tional notes, we noticed that users were con­fused when asked to set the default back pos­ture. This could poten­tially because there was no con­fir­ma­tion when a user selected the but­ton to set their desired back pos­ture.

  • Wiggle Room and Time Allowance increment and decrement buttons are now working correctly. We also added color changes to the buttons for user-feedback.

    • Previously, val­ues for both wig­gle room and time allowance became dis­torted when the increment / decrement but­tons were quickly selected.

  • Added text snippets to explain wiggle room and time allowance.

    • Through our obser­va­tional notes, we learned that wig­gle room and time allowance were not intrin­si­cally intu­itive and require addi­tional expla­na­tion.

  • Refined default wiggle room and time allowance values.

    • We also found that our default value for wig­gle room was far too lenient.

  • Added multi-toned feedback based on the amount of deviation from the default back posture.  In other words, one tone will play from the device when you are close to the default back posture, but another will play while you are further.

    • We also dis­cov­ered that some­times it becomes dif­fi­cult find­ing your orig­i­nal pos­ture, espe­cially when the wig­gle room is rel­a­tively unfor­giv­ing.

Evolution of Project Goals

Overall, our goal has always been to help people maintain good back posture while they are seated.  However, the design of our product has evolved greatly since its early conceptualization.  Initially, we were really interested in having the system simultaneously evaluate and provide feedback for the three main regions of the back: top, middle and lower.  We wanted the system to give vibrational feedback to the area of the back that was causing bad back posture and we wanted our GUI to display their performance in each of these areas over time.

What we found was that these objectives added complexity to the physical product and the GUI.  In particular, they required that the device span the entire back, which would correspond with a complicated procedure for attaching a large wearable device and taking it off.  This could keep users from wanting to use the product in the first place.  We also found that users quickly responded to feedback from the device and positioned their back to the correct posture.  Given this, it didn’t make sense to display a visualization of the user’s back posture over time, since it would be very close to the correct posture as long as the user wore the device and responded to the feedback.  What we ended up with was a device that achieves our overall goal without adding unnecessary complexity, and a GUI that simply helps with usage of the device.

Critical Evaluation of Project

Our work suggests that, with further iteration, this system could be turned into a useful real-world system, especially given that back posture is such a relevant issue for today’s society.  Many people spend most of their day sitting at desks.  From our observations, we found that people who would start with good back posture did not stay that way for long.  When our test users attached the device, they were pleasantly surprised about how useful a simple reminder is for maintaining good back posture.

When we first described the concept to our test users, they often responded with “I would buy that!”  However, one of our most challenging tasks was to find an implementation that was very unobtrusive to the experience of sitting down and working at a desk.  The user was often distracted by complexity and device attachment issues.  Fortunately, we have gotten very close to making the system part of a seamless effort by the user to maintain good back posture.  Once the device is standalone, has vibrational motors and has a simple shoulder clip-on mechanism, the PostureParrot will be a useful real-world system.

Moving Forward

There is certainly room for improvement for the PostureParrot in terms of implementation.  In particular, we were limited by the Arduino’s size, a lack of vibrational motors and battery-power options.  It would have been ideal to drastically shrink the size and weight of the device through a specific system other than an Arduino.  The general-purpose Arduino forced the entire system to be much larger.  In addition to making the device very small and light for the user’s shoulder, the system could have been improved by providing vibrational rather than audible feedback through vibrational motors.  This would enable the user to use the device in libraries and other public areas.

To make the perfect system, we would also want to make the PostureParrot wireless.  Having a long USB cable extend from the user’s shoulder to a laptop is not only messy, but also limiting in that it requires that the user be near a computer.  A  better setup would be to have the PostureParrot communicate with a desktop or mobile application via wireless internet or bluetooth.  Any additional configuration could be done through the application.  The resulting stand-alone small and light device could be very appealing.  Other than these optimizations, it would be nice to come up with a solid adhesive solution for sticking the device to a user’s shoulder.

Source Code

Third-Party Code

Third-Party Code was not used in our project.

Demo Session Materials

P6 – PostureParrot

Group 7, Team Colonial

David, John, Horia

Project Summary

The Pos­turePar­rot helps users maintain good back posture while sitting.


The system that is being evaluated is the functional prototype of the PostureParrot and its accompanying GUI.  The purpose of this experiment is to determine whether our target audience will find the operation of the PostureParrot to be simple, intuitive and instructive.  It needs to be easy for users to wear the product and learn from its audible feedback and from the GUI’s visual feedback.

Implementation and Improvements

Link to P5:

Between P5 and P6, we have altered the list of tasks, now reintroducing a GUI that allows the user to set their default back posture, as well as alter the allowed wiggle room (degree that user can move without being notified) and time allowance (total time that user can deviate from default posture before being notified.) This GUI originally allowed the user to set the default back posture, as well as see changes in separate areas of the back over time; through our tests, we discovered that it was simpler, more refined, and more accessible to produce a compact device with a single component rather than a device that monitored multiple parts of the back. Overtime, we discovered that our fabric “reset” button embedded in the device was extremely unreliable, and, as a result, moved this functionality to our GUI.



To select our participants, we looked for Princeton students who studied while sitting.  To find these students, we went to an eating club library and asked sitting students if they would like to take part in our usability study.  Additionally, we asked them each a few questions to make sure that they were a part of our target user group.  For example, we asked them if they studied at desks a lot of the time or if they ever experienced back pain.


We performed the test at a table that was set up in an eating club.  We put a standard desk chair up against the table.  The only other equipment we used was our PostureParrot connected to a laptop.


(Easy) Set the default back posture of the PostureParrot.  This requires that you have already attached the device and opened the GUI.  The user should position himself so that he has good back posture   Then he should press the button on the GUI that says “Set Default Posture”.

(Medium) Deviate your back from the desired back posture and respond to the PostureParrot’s audible feedback.  After the user has set a default back posture,  the device will make a noise when the user deviates too far from it.  The user must correct their back posture back to the default to make the noise stop.

(Hard) Use the GUI to adjust the PostureParrot’s wiggle room and time allowance.  While the device is attached and the GUI is running, the user adjusts the values associated with wiggle room and time allowance and observes the effects.  The user should select a wiggle room and time allowance that they feel comfortable with.


For each participant, we first requested that they fill out the consent form, as well as their demographic data. We then gave them a quick demo, opening up the GUI and demonstrating how one attaches the device onto their shoulder. After beginning our video recording, we then asked the participant to sit before the laptop and attach the device themselves before proceeding to the three tasks. For each of these tasks, we explained to each participant what they were trying to achieve, and asked them to say aloud any concerns or observations as they arise (which we recorded by taking notes, in addition to any critical incidents that we see.) Once a task was complete, we paused to explain the goal of the next task. Once all three tasks were complete, we asked each participant to take a brief survey.

Test Measures

Our main goal for testing was to evaluate the level of difficulty associated with the different tasks.  In addition to making standard observations, we had the user fill out a questionnaire where they self-reported values pertaining to their satisfaction and level of difficulty with different aspects of the device.  The following were our questions:

  • Please rate the difficulty of task 1 (setting the default posture)
  • Please rate the difficulty of task 2 (deviating from default back posture)
  • Please rate the difficulty of finding a good “wiggle-room” value
  • Please rate the difficulty of finding a good “time-allowance” value
  • Please rate how intuitive the device was over-all
  • Please provide any additional comments / potential improvements

Results and Discussion

Through our observational notes, we noticed that users were confused when asked to set the default back posture. This could potentially because there was no confirmation when a user selected the button to set their desired back posture. To alleviate this, we plan on making the arduino beep in confirmation when a new default is set. We also discovered a bug that was present in our GUI; due to some odd communication between Processing and Arduino, values for both wiggle room and time allowance become distorted when the increment/decrement buttons were quickly selected. Fixing this problem will involve looking at the values that are being passed between the two programs, as well as how various delays (intentional delays, tone delays, etc) are affecting results.

Through our observational notes, we learned that wiggle room and time allowance were not intrinsically intuitive and require additional explanation. In future iterations, this may simply require a small text snippet in the GUI that briefly explains what each value represents. We also found that our default value for wiggle room was far too lenient; in our final iteration, we will have refined values so that the device responds appropriately to those using it, especially first-time users. We also discovered that sometimes it becomes difficult finding your original posture, especially when the wiggle room is relatively unforgiving. One potential way of addressing this in our next version is to have the tone respond according to your deviance from the base posture; for example, we could have it so it increases in frequency the farther you deviate. However, perhaps this functionality may be unnecessary, since users can always reset their desired back posture.

From our questionnaire, we discovered that the first two tasks were relatively easy; this shows that although our interface was slightly surprising without a notification, it was still an easy task to accomplish. The last task – regarding the two variables – was generally more difficult; although this was most likely due to the distorted values, it would be useful to find out if there were additional reasons for why this task was unintuitive. For the additional comments part of the questionnaire, we received a comment about how the adhesive on the device made it difficult to keep it on the user’s shoulder.  Another comment that we received stated that it was possible to achieve the same “good posture” angle when slouching.  Although this is a valid point, the user did have to work to find this same angle and our adjustable wiggle room and time allowance should compensate for this.  To completely eliminate this issue we would need to keep track of lower back posture too, something that would require the device to be more cumbersome (what we moved away from after P5).

There were some limitations that we found while conducting our usability study.  Due to our small population size, it was difficult to get an accurate idea for what users thought were optimal wiggle room and time allowance values.  It would be interesting to track the final wiggle room and time allowance values settled upon by many different users.  Another limitation that we had in our sample population was that our test users all had very low back pain.  Each of our users were male as well, meaning that we were not able to distinguish differences in usage by gender.  After tracking each user’s major, we also thought that it would be interesting to see how people with different lifestyles (lifestyles associated with computer science majors, english, etc) would affect the product usage.  This would also require a larger population.


Consent and Demographic Form


Name: ________________________

Please rate the difficulty of task 1 (setting the default posture)
1 – difficult 2 3 4 5 6 7 – easy

Please rate the difficulty of task 2 (deviating from default back posture)
1 – difficult 2 3 4 5 6 7 – easy

Please rate the difficulty of finding a good “wiggle-room” value
1 – difficult 2 3 4 5 6 7 – easy

Please rate the difficulty of finding a good “time-allowance” value
1 – difficult 2 3 4 5 6 7 – easy

Please rate how intuitive the device was, over-all
1 – not intuitive 2 3 4 5 6 7 – very intuitive

Any additional comments / potential improvements:

Observational Notes & Questionnaire Responses

Max J.

Task #1

  • 7:06 Clicks default posture and laughs (potentially because nothing happened on either the interface or the device)

Task #2

  • 7:06 Laughs (potentially because he needs to bend his back to a great degree)

Task #3

  • 7:08 Moves GUI around screen
  • 7:08 Finds a bug: if user clicks buttons too quickly, values are corrupted
  • 7:08 Device falls off shoulder and needed to be placed on the shoulder again
  • 7:09 Experiments with wiggle room until a desirable value is found

Questionnaire Responses

  1. 7
  2. 7
  3. 3 (“buggy”)
  4. 3
  5. 7
  6. Additional Comments: Better tape [emphasis his]

Zhexiang W.

Task #1

  • 7:25 Confused by no confirmation after selecting default

Task #2

  • 7:26 Comments that the default wiggle room is extremely large
  • 7:27 Wonders if there is a time delay / if he should move slower while testing

Task #3

  • 7:27 Minimizes the range of wiggle room, is pleased with stricter values

Questionnaire Responses

  1. 6
  2. 6
  3. 2
  4. 5
  5. 6
  6. Additional Comments: None

Andy H.

Task #1

  • 7:45 Success!

Task #2

  • 7:45 Tries different ranges of motions: forward-back, left-right, diagonally

Task #3

  • 7:47 Has difficult time finding original position
  • 7:48 Tries device moving forward and backward, but not any other direction

Questionnaire Responses

  1. 6
  2. 5-6 (circled together)
  3. 5-6
  4. 5-6
  5. 4
  6. Additional Comments: Needs to keep track of lower back posture too – same “angle” can be achieved w/ both slouching and “good” posture

P5 – PostureParrot

Group 7, Team Colonial

David, John, Horia

Project Summary

The PostureParrot helps users maintain good back posture while sitting.

Working Prototype Tasks

Task 1 (Easy): Putting the posture parrot on

At this point, the PostureParrot is connected to a USB port for power.  The user puts the connected device onto the top of their shoulder of choice.  The device will stick due to its adhesive underside.

Task 2 (Medium): Setting the default posture

The user should position himself so that he has good back posture.  Then he should press the top of the device.  This will set the default back posture.

Task 3 (Hard): Adjusting back posture based on device feedback

After the user has set a default back posture, the device will make a noise when the user deviates too far from it.  The user must correct their back posture back to the default to make the noise stop.

Choice of Tasks 

The goals of these three tasks are the same as in P4.  However, there are a few differences in how a user must accomplish these goals.  For example, in task 1 the user must put the device on differently due to its new design.  In task 2, the user now sets the default back posture through the button that covers the entire top of the device, a simpler design that prevents the user from having to open an application.  In task 3, the user still reacts to the feedback given by the device, but this time it is done through the sound given off by the PostureParrot, not a vibration.  In general, our adjustment of tasks was driven by the simplification of our product, which eliminated the need for a desktop application.

Revised Interface Design

As a result of P4, we made several changes to how the device is worn. We originally constructed a device that traveled the length of the spine and registered whether or not the user changed his or her posture through a change in flexible, resistive fabrics. One problem with this original design is that it could not accommodate users with extremely small or large back sizes, which we discovered during our paper prototype phase. Additionally, we found that our resistive fabrics were insufficient for creating our device, so we were left in a position that required us to entirely rethink our approach to the problem. Our revised, alternative solution uses an accelerometer to detect changes in posture, and rather than notifying users with a vibrating motor, we decided to notify them auditorily through a piezo buzzer, which requires significantly less weight. This device is placed on the user’s shoulder, rather than the user’s back, and thus accommodates for a wider range of user body types.

Another alteration we made for our revised interface was to remove the data visualization GUI that displayed back posture deviance over time. Through our user tests, we found that plotting the deviance in posture over time and differentiating areas of the back were not contributing a great deal of useful information, and that the benefits of having the device beep was sufficient for notifying the user of poor posture. Through this simplification process, we lost a way for the user to set their default back posture; to account for this, we embedded a reset button in the device itself that provided the same functionality. Overall, these various changes allowed for a more simplified device that could accommodate a wider breadth of users.

IMG_20130422_222927.149 IMG_20130422_222950.566 IMG_20130422_223009.010 IMG_20130422_223026.616

Overview and Discussion

The implemented functionality is displayed in Video #1 below.  The user can attach the device to a shoulder of their choice, press the top of the device to set a default posture and then reap the benefits of automatic feedback during back posture deviations.  The user can always set a new default back posture by pressing the top of the device.  In Image #1 you can see the accelerometer and piezo sensor, providing posture input and sound output respectively.  In Image #4 you can see the final prototype, complete with colorful tape.  A “user” wears the PostureParrot of their choice in Image #5.

In order to make our prototype work, we needed to attach tape to the bottom of the device so that it would stick to the user’s shoulder.  Hopefully, this can be replaced with a more permanent solution in the future.  Additionally, we would like to make the PostureParrot a wireless product.  Currently, our battery options would more than double the weight of the device.  We’re going to have to do more research to find a good solution for power if we want to get rid of the need for a USB cable.

To connect the analog textile press button, we modeled some of our code off of a tutorial from, where we purchased the button.  The code is posted below.

int softPot = 0; // this line selects the input pin a0 for the sensor
int ledPin = 13; // this line selects the pin 13 for the LED output
int tempPot = 0; // variable to store the value coming from the sensor

void setup() {
  // this line declares the ledPin as an OUTPUT:
  pinMode(ledPin, OUTPUT); 

void loop() {
  // read the value from the soft potentiometer
  tempPot = analogRead(softPot);   
  // it turns the LED on
  digitalWrite(ledPin, HIGH); 
  // stop the program for  milliseconds:
  // turn the LED off:       
  digitalWrite(ledPin, LOW);  
  // stop the program for for  milliseconds:


Video and Images

Video #1 (A video of a user completing all three tasks.  Listen carefully for PostureParrot feedback.)


Image #1

photo 1

Underlying circuitry, including an arduino, accelerometer, piezo sensor, textile analog pressure sensor and wiring.

Image #2

photo 2

Circuitry enclosed by elastic wrap and textile sensor.

Image #3

photo 3

Device wrapped in colorful electric tape.

Image #4

photo 4

PostureParrot on the left shoulder of a “user”.

P4 – BackTracker

Group #7: Colonial Club

David, John and Horia

Project Summary

We are making a system that helps users to maintain good posture while sitting.

Test Method

Obtaining informed consent

We obtained informed consent by providing a form for our test-users to form.  Here is the link:

Selecting participants

Participants were selected based on how we felt they would fit with the target-user group.  If we saw the person as someone who did not sit at a desk for extended hours, then we wouldn’t use them as a test user.  The people we picked were generally people who were known to sit at desks for extended hours and enjoy using technology to improve their lives.

Testing Environment

Our testing environment was set up essentially the same as described in P3.  We had a desk with a computer and a desk chair with good back support.  The paper prototype of the desktop application was placed on the screen.  The paper prototype of the back device was placed on the user’s back.

Testing Procedure 

  1. John greeted the test user and gained informed consent.
  2. David generally described the system and its purpose.
  3. David read the script to the demo while John acted out the demo.
  4. David read the task scripts while John gave functionality to the paper prototypes.
  5. John thanked the participant
  6. The group discussed the notes taken about the participant’s actions

Demo Script:

We are eval­u­at­ing a sys­tem that makes users aware of bad pos­ture dur­ing extended hours of sitting.  We want our sys­tem to quickly alert peo­ple in the event that they have bad back pos­ture so that they can avoid its asso­ci­ated neg­a­tive long term effects.

Here is a short example of our prototype in use.  The user first puts the prototype onto their back, taking note of the labeled top and bottom sections.  The user then opens up the desktop application that interacts with the prototype.  This application dis­plays rel­e­vant back pos­ture infor­ma­tion and sta­tis­tics to the user.


Task #1 Script

For the first task, you will be setting the desired back posture through the desktop application that you hope to maintain.  This should be a healthy back posture.

Task #2 Script

For this task, you will deviate your back posture from your desired back posture.  You will then respond to the feedback generated by the prototype to correct your back posture.

Task #3 Script

For this last task, you will look at how your back posture changed over time. Additionally, view how your posture has changed for each of the three specific regions of your back.

photo 1

photo 2

photo 3


We found that our users were generally well-capable of performing the first two tasks. However, one subject was confused when asked to set the default back posture, and was unsure whether to complete this task through the GUI or the device itself. In regards to the second task, all three subjects readjusted their posture back to its original position in response to the vibration feedback provided.

Our third task produced a great deal of critical problems, many of which were common throughout all three test trials. All three subjects felt that the graph needed information, including the units for time and posture deviance. They also found it difficult to differentiate between graphs and often missed the legend in the top left until the end of the experiment. One subject proposed using a diagram of the spine to display problematic areas when appropriate (i.e. glow red in areas where the user has poor posture.) Another user swiped their finger across the graph to see if any information would result; additionally, they tried right-clicking to bring up a menu / additional choices.

Discussion of Results

In future iterations, it may be beneficial to include more beginning-phase orientation, including explicit on-screen step-by-step instructions that guide the user through the putting on the device and setting the default posture. Having a diagram of the back can help easily demonstrate both the site and degree of poor posture, either in real time or as the user is scrubbing over the data with their cursor. Additionally, we learned that our graphs must become more readable, and could benefit from explicit units and differentiable, potentially color-coordinated, plots corresponding to each region of the back.

Subsequent Testing

Although our low-fidelity prototype made transparent several areas of improvement, we feel as though these issues are not pressing enough to justify an additional round of low-fidelity prototyping. These adjustments are relatively minor and are so easily implementable in code that an additional low-fidelity prototype may be redundant. Additionally, after considering the our timeline for both constructing and debugging the high-fidelity prototype, we unanimously agree that it should be our priority to begin this development as soon as possible, so that we may quickly test its usability.

L3 – Team Colonial Club

Team Colonial Club, Group #7

David Lackey
John O’Neill
Horia Radoi


This robot tries to simulate walking using two servomotors attached to opposing sides of the body. It is using friction to thrust itself forward. .

This robot is a precursor to the infamous ATAT, present in the (good) episodes of the Star Wars saga. As opposed to the robot that helped conquer Hoth, our model uses only two legs, on opposing sides, and upon careful calibration, the device can walk. Since our project was struggling with this last step, we decided to add a flag on top of it and call it a marvel of Empire Engineering.

List of Brainstorming Ideas

  1. oscillating helicopter
  2. creature that moves until it finds a sunspot / light
  3. boat that submerges itself when it hears a sound
  4. tank creature (multiple motors within on tread)
  5. worm
  6. creature that travels by rapid, random vibrations
  7. hovercraft
  8. robot that quickly rotates a flag
  9. swimmer
  10. walks around while spinning a disco ball
  11. robot that goes slower in the cold
  12. samurai robot that twirls a staff (we could have two battle)
  13. tug of war robots, each moving away from one another

Photos of Design Sketches

photo 1 photo 2

Final System Media    




The creature, complete with flag

Video of Moving Robot Carrying Flag
Moves from point A to point B, ever so slowly…

List of Parts

  1. 1 arduino + jumper wires + usb connection/power
  2. 2 servo motors (for legs)
  3. 1 AC motor
  4. Electrical tape (to attach pieces together)
  5. Transistor
  6. Diode
  7. Capacitor
  8. 330 ohm resistor
  9. Arduino
  10. Custom flag to represent your team

Recreation Instructions

After acquiring the appropriate materials, wire the DC motor to digital pin 8 as well as two Servo motors to pin 9 (so that they move in conjunction with one another.) Next, tape together the two Servo motors as demonstrated in the video, then orient the DC motor with the pin facing upward and tape it to the two Servo motors (making sure to include your own personalized flag to the top of the DC motor.) Once these all of these components are assembled, upload the attached code and watch your creature strut its stuff!

Source Code


int servoPin = 9;
int motorPin = 8; 

Servo servo;  

int angle = 0;   // servo position in degrees 

void setup() 
  pinMode(motorPin, OUTPUT);

void loop() 
  // scan from 0 to 180 degrees
  for(angle = 0; angle  0; angle--)    
    analogWrite(motorPin, 250);   


Group 7 Members

David Lackey

Conducted an hour and a half of observations.  Led the blogging / project managed.

John O’Neill

Conducted an hour of observations and thirty minutes of interviews.  Led user-casing / user tasking.

Horia Radoi

Conducted 40 minutes of observations and interviews and was the primary story-boarder.


The problem that we are addressing is bad sitting posture with students who are working at desks.  Our proposed solution is a wearable posture detector in the form of an under armor shirt.  This solution addresses the problem because we can gather all of the necessary information about the user’s back posture and alert them through the device that they’re wearing.  It can be easily embedded in the user experience without taking too much away from the task at hand.

Description of Observations

Our target user group includes people who study at desks and who are concerned with their sitting posture.  Additionally, these people need to be comfortable with the idea of technology helping their well-being.  We could have focused on posture in other realms, such as weight-lifting, etc, but we wanted to focus on an application of posture where many people spend a great deal of time.  Also, back problems associated with sedentary life styles is quite common.

See Appendix for thorough collection of observations.

User 1

User number 1 is a female undergraduate who has a history of back-related problems and has to spend a majority of their day in front of a laptop. They often enjoy using their computer for non-work activities, including watching videos, but dislike how using a laptop often requires you to look down / crane your neck. One of their greatest priorities is being able to focus in on their laptop work for hours at a time. They are a great candidate, given their applicability to our target user group (undergraduates who work at desks,) their history of dealing with back issues, and their laptop-heavy workflow.

User 2

We were unable to conduct an interview with user 2, but, based on the hour and fifteen minutes that we observed her for, we were able to extract a lot of important information about long-term seating habits for a relevant target user.

She was studying scientific books in the Friend Engineering Center Library, meaning that it is very likely that she is some sort of engineering student.

User 3

Our third user does not study in libraries that often.  She does, however, study in a chair at a desk in her room.  Without the scrutiny of others, it’s harder for her to force herself to not slouch.  Her priorities include making her room a productive, but healthy place to study.  She likes to study in her room more than the library.


To observe people, we would sit towards the edges of large seating areas in libraries.  This allowed us to pinpoint students who seemed to be a part of the target user group.  We identified these students by their noticeably bad seating posture.

Each of our users were clearly dealing with discomfort from long periods of sitting.  To deal with it, they would often stretch their backs, change to another position, or rub their necks.  See the Appendix A for the minute by minute observations of user 2.  Many of the observed mannerisms (such as those discussed in the above paragraph) were present in our observations of other users as well.

We found user 3’s note about the scrutiny of others to be very interesting.  Being scrutinized by others actually has an impact on your posture.  Being able to impose this scrutiny artificially through the device could prove to be beneficial.

A unique thing about user 1 is that she had back problems earlier in life, so back posture is especially important.

In terms of workflow, users 1 and 2 both appreciated long periods of time to focus on work.  User 3, however, approached work with a more off and on approach.  User 3 said that this made it a little easier to maintain proper back posture, since it was for shorter periods of time.

Task Analysis

  1. Who is going to use the system?

Undergraduate students who are concerned with their back posture while working and wish to improve it through the use of technology. Can be adapted to fit general people who are concerned about their posture while doing office work, or people who need a specific form for an athletic activity.

  1. What tasks do they now perform?

Working at desks with improper back, neck, and wrist posture, often for extended periods of time (over 15 minutes in a single posture). This causes problems in the long run. A specific target group would be young adults, who are at the end of their growth period, and for whom a poor posture can have long-lasting health effects.

  1. What tasks are desired?

To maintain proper posture while working at a desk.

  1. How are the tasks learned?

An extremely basic, printed walkthrough will accompany the hardware. This manual will explain how a user sets a “default” / “base” posture, and what will happen when one deviates from the base posture. At the same time, a doctor can set up a desired position during a consultation, and the user will have the choice to move between his personal mode or the doctor suggestion.

  1. Where are the tasks performed?

Wherever a student is working at a desk (the library, their room, etc.) or doing an activity that would put the back in a non-ideal position.

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

The user can interact with the data and set up an ideal back position, can switch between two modes (one of which is considered to be a physician’s recommendation). The analysis and alerting will be done automatically.

  1. What other tools does the user have?

None. He will interact with the computer through SET and CHANGE buttons, and will need to wear the hardware in order for it to function.

  1. How do users communicate with each other?

They don’t. This is an individual product. Different modes can be loaded using the USB cable.

  1. How often are the tasks performed?

It is recommended for users to wear the device every time their back will be in the same position for a long period of time (ie. while working, doing homework, working out etc.)

  1. What are the time constraints on the tasks?

There will be no time constraints except for the battery life of the device.

  1. What happens when things go wrong?

If things go wrong, the system may be encouraging bad back habits, which is counterproductive.

Description of Three Tasks

Task #1: Set up a desired back position.
The user must designate the “default” or “base” posture that will function as the user’s desired posture. This can be done by the user (or, for use cases outside of those we are studying, by a medical professional.) The user chooses a good posture and presses a button on the device to set the base;
the system will memorize this ideal position in order to record how far away the user deviates from it.

Difficulty Analysis

Finding a desirable posture requires no hardware or software – just an acute attention to how your body is feeling when undergoing certain postures. This means that our task is easy when performed using pre-existing tools and applications. Under a system, however, a “desired back position” has a specific definition and requires calibration, thus the level of difficulty is moderate.

Task #2: Alert user if back position / posture deviates too far from desired posture. Small motors in the system (ideally along the back / along the area of bad posture) will vibrate to notify the user that they have bad posture. We need to test whether we notify the user after a certain threshold of deviance (slouches too much,) if an improper posture is held for too long a duration (slouching for too long,) or some combination of the two.

Difficulty Analysis

One can currently ask another person to monitor their own posture, but this requires an additional person who is watching at all times, making this difficulty-level moderate. However, the device alerts the user automatically / without volition of the user, making this task difficulty easy.

Task #3: Monitor how their posture changes. User can optionally plug the wearable device into the laptop, which will record the readings of the resistors. We can use this data to show the users – in a nice, visual format – how often and how much they deviated from their ideal posture.

Difficulty Analysis

There may be some medical device that quantifies / provides feedback on a patient’s posture, but we are unaware of such things. This high barrier is why we are monitor this task as difficult. However, with this device, the user only needs to plug in the device, which is why we label this task as moderate.

Interface Design


The system is a wearable device that helps users maintain good posture. It monitors the user’s back posture and alerts them when it deviates from a desirable position, and can optionally provide the user with data on when and by how much they deviate from their desired posture. In form, the device is similar to underarmor; this is because the slim fit allows the sensor to more accurately monitor changes in the user’s posture. If the user has a chance to plug the device into a laptop, a program can extract readings from the device, allow the user to view changes in their posture over time. Ideally, such a system would encourage healthier habits in regards to posture. To our knowledge, there is currently no wearable system is dynamically monitors and provides feedback for bad posture.


Colonial (8)  Colonial (6) Colonial (5) Colonial (4) Colonial (3)

System Sketches

Colonial (2) Colonial (1)

Appendix A – Minute by Minute Observations of User 2

  • Where: Friend Library 2nd Floor
  • When: 12:00 PM on 3/8/12
  • Girl in green jacket sits and gets comfortable
    • Puts jacket around chair
    • Has a small world coffee
  • First sits on edge of her seat and uses smartphone
  • Stands up and starts to pull items out of backpack
    • Pulls out Windows computer
  • Sits back down and rolls back sleeves
    • Ties back hair
    • Cleans glasses
  • Looks out the window
  • Immediate posture
    • Edge of seat
    • One foot on ground
    • Kind of hunched over computer
  • Gets up and takes a photo of the snow with smartphone through window
  • Sits back down
    • Feet all over the place
    • Upper body pretty steady
      • Both elbows out resting on the table
      • Head forward over keyboard
      • Shoulders close together
  • After 5 mins, sits up tall briefly
    • Adjusts hair and maintains position for a few seconds
  • Returns to a position with a lesser posture
    • Head is more forward and lower
    • More slumped over computer in general
  • Slowly gravitates to original position over the course of several minutes
  • When: 12:15 PM
  • Legs reach a somewhat consistent form of being crossed
  • Head gets lower again
  • When: 12:21
  • Rubs neck with left hand
  • Rolls up sleeves and returns to work
  • Reaches the new posture
    • Elbows still resting on table
    • Left hand on neck
    • Right hand using computer
  • Puts on big green jacket
  • Goes to original posture
  • When: 12:40
  • Hunched more forward
  • Hunches over her phone every once in a while to send a text
  • When: 12:45
  • Leans more on right side
  • Sits up tall and puts elbows close together as a stretch
  • Almost back to original posture, elbows slightly more in
  • Elbows out again, more slump
  • Leans way forward with arms on lap and stays with this new posture
  • Leans back in chair after brief back twist stretch
  • Leans forward again
  • Gets up and throws coffee away
  • When: 12:50
  • Arms on lap, hunched forward
  • leaning forward on right arm
  • Sits tall and scoots chair forward so that her back is flush to the back of the chair and she’s close to desk
    • Arms on lap
  • When: 1:00
    • Left elbow on chair’s left arm
    • Leans
  • When: 1:10
  • Shift from elbow to elbow on chair’s arms
  • Looks uncomfortable
  • When 1:15
  • Stretches back backwards over chair
  • Leans forwards again with arms on lap

Seat Shame


I conducted my observations from the perspective of a student who arrived to class on time.  To get a full picture of what happened in the minutes before class, I sat to the back of lecture halls and observed the teacher, waiting students, and late students.

I noticed that the teacher spent the time before class standing around unproductively waiting for the class to fill.  Perhaps they want to appear available in case students have questions before lecture.  However, it seems as though they are just waiting awkwardly to start the lecture after the class has been filled with an arbitrary threshold of students.

Some of my favorite observations were about students who showed up just before class started or slightly later.  These students would have to climb over students to get to an open seat.  This was disruptive and a hassle for the seated and on-time students, the teacher and the late students.

Brainstorming Ideas

  1. A device that counts the number of heads and moving bodies in the classroom and alerts the teacher when the capacity has reached a threshold so that he or she can start the lecture.
  2. An LED meter on each seat aisle that displays how many seats are available in each aisle.
  3. An auditorium structure that adds seats to the side of previous seats as seats get filled. This ensures that there are no gaps in seats and people climbing over as class starts.
  4. A display on the screen that visually maps the seats to a virtual seating chart.  If students are using chairs inefficiently they show up as red on the screen (prompts them to move to a place where students won’t have to climb over them later).
  5. Don’t allow seats to fold down until middle seats in aisles are taken.
  6. People swipe their prox on their seat when they get to their seat. Ensures attendance and quick arrival since the teacher can track perpetually late students.
  7. People touch their prox to their seat once they sit and, along with the above point, their face goes on the screen if he or she is seated efficiently (people will have to climb over).
  8. Proxes unlock seats (they unfold).  Can only unlock seats with seats with green lights (start from middle of aisles for efficiency).
  9. Seats use weight sensors to detect if someone is sitting in them (user experience doesn’t change).  This can give the teacher knowledge about class capacity.
  10. Visual display on the projected screen with class student count over capacity and a visual proximity to the needed threshold to start class.  Students will be able to identify the people come in last and it will encourage students to be there on time.
  11. Seats vibrate for a few seconds when a student sits inefficiently (people will have to climb over them).
  12. Combination of ideas: camera mounted on podium that tracks which seats are taken. Minimal installation, can still display students who are sitting inefficiently.

Chosen Ideas

Brainstorming Idea 1

The confusion and awkwardness surrounding the idea of when to start class could be relieved, which may allow classes to start earlier.

Brainstorming Idea 12

This would incentivize people to sit more efficiently so that the lecturer and students wouldn’t be disrupted.


Brainstorming Idea 1

photo 3


Podium camera tracks student count (number of heads) and moving bodies to determine when class is ready to start.

Brainstorming Idea 12

photo 1

Initial screen that shows classroom seating.  Gives inefficient seaters notice before shaming them.

photo 2


Close up on student sitting inefficiently.

photo 4


Super close up of student sitting inefficiently.

In the Field

I ended up using the screens I developed for Brainstorming Idea 12, calling the prototype Seat Shame

The idea of being shamed resonates with people.  All three users quickly picked up the Seat Shame picture frame and put their face in the middle.

photo 2-1

photo 1-1

What ended up not being so clear was that there was a transition from each screen to the next.  After having a user sit in an aisle seat I would flash the screen that said “Move or be shamed”.  People understood from the diagram of the lecture hall and the statement that they needed to move.  However, people didn’t understand where they needed to move in order to not be shamed.  They would often just move one seat over, which would have resulted in another shame warning.


The product needs to display a clearer shame warning.  I think it would be useful for the projected screen to say something like the following: “Student sitting here, you have 15 seconds before you will be shamed.”  Additionally, there may need to be more explanation about what shaming is before it happens.  I’m not sure if this is more of an explanation that should be expressed by the lecturer or by the product.

There also needs to be some visual cue for users to go to the open middle seats in a row.  Perhaps these seats could be colored green on the screen, while aisle seats could be colored red.

Team Colonial – L1

Team Colonial

Group Members: David Lackey, John O’Neill, Horia Radoi

Group Number: 7

Short Description

We built a physical interface (with potentiometers) to change the RGB values of a window filled with a single solid color.  RGB values can be tricky to understand.  Providing physical knobs to adjust them with immediate visual feedback allows the user to better grasp the concept of RGB values.  We feel that our project was successful and we really liked how Processing allowed us to give such quick feedback.  One of the main drawbacks of our project is that a user can only accurately control 2 potentiometers at a time, making it really difficult to affect all three RGB values simultaneously.


RGB Interface

photo 1

This sketch involves our physical interface for adjusting the RGB values of a solid color, displayed via laptop.

Cup Temperature Indicator

photo 2

This sketch involves an LED setup mounted on the side of a cup.  A thermistor hangs just barely into the cup through a small hole in the lid.  The information from the temperature sensor is passed to the Arduino, which then powers certain LEDs based on the temperature of the inside of the cup.


photo 3

This sketch involves a Photo Sensor attached to a window to get information about the lighting outside of the user’s room.  If the light outside reaches a certain threshold (daylight), a buzzer connected to the Arduino will go off, waking the user.



System in Action


Parts Used

  • Arduino, wires, USB cord, breadboard
  • 3 Rotary Potentiometers

Creation Instructions

  1. Add three rotary potentiometers to a breadboard
  2. Add power to the rotary potentiometers, connect them to ground, and connect each one to a separate analog input
  3. Read potentiometer values and convert them to RGB values
  4. Use Processing to display a window filled with a solid color

Source Code


/* RGBKnobs */

// pins for knobs
int rPin = 0;     
int gPin = 1;
int bPin = 2;

// the analog reading from the knobs
int rReading; 
int gReading;
int bReading;

double knobMax = 1023.0;

void setup(void) {

  // We'll send debugging information via the Serial monitor


void loop(void) {

  rReading = 255 - (255 * (analogRead(rPin) / knobMax));  
  gReading = 255 - (255 * (analogRead(gPin) / knobMax));
  bReading = 255 - (255 * (analogRead(bPin) / knobMax));



/* RGB Knobs, created by Lab Group 7 (jconeill, dlackey, hradoi) */

 import processing.serial.*;
 Serial port;
 // rgb values
 int[] vals = {0,0,0};

 void setup() {
   size(555, 555);

   println("Available serial ports:");

   port = new Serial(this, Serial.list()[4], 9600);  

 void draw() {
   background(vals[0], vals[1], vals[2]);

 void serialEvent(Serial port) {
   String in = port.readStringUntil('\n');
   in = trim(in);

   if (in != null)
     vals = int(split(in, ","));