Author Archives: Dylan Bowman

P6 – Group 8 – Backend Cleaning Inspectors

Posted on by

Your group number and name.

Group 8 – Backend Cleaning Inspectors

 

First names of everyone in your group.

Dylan

Tae Jun

Green

Peter

 

A 1-sentence project summary.

Our project is to make a device to improve security and responsibility in the laun­dry room.

 

Introduction (5 points). 1 paragraph. Introduce the system being evaluated and state the purpose and rationale of the experiment.

We have built a laundry security system prototype that is intended to be used in Princeton University laundry rooms to help protect student’s personal clothing when it is left alone to be washed and/or dried.  The purpose of this experiment is to test out three tasks that will be performed by users of our system.  We wish to analyze and observe test participants attempting each task and to determine if there are any changes we need to make in the implementation of these three tasks.

 

Implementation and Improvements (5 points). Provide a link to your P5 submission. If you have changed your working prototype at all since submitting P5, supply a brief bulleted list of the changes made since P5. (It is not necessary to change your prototype from P5 before doing P6.) This section should be no more than 1 paragraph.

http://blogs.princeton.edu/humancomputerinterface/2013/04/22/group-8-backend-cleaning-inspectors-p5-working-prototype/

 

Method (10 points).

Participants: 1 paragraph. (Who they are, how they were selected.)

 

Participant 1)  21 year old Junior, Male, MAE major

 

Participant 2)  19 year old Freshman, Female, undecided

 

Participant 3)  19 year old Freshman, Male, undecided/Econ

 

See demographic questionnaire results below for more information.

 

We set up our study in a laundry room in Butler, and approached the first three people to enter the room.  They all agreed to do the study and both genders were represented.

Apparatus: 1 paragraph. (What equipment did you use, where did you conduct the

test.)

We used our model prototype to test the three tasks.  We do not need any wizard-of-oz techniques in our model prototype currently, so we were able to just use our prototype.  We tested it out in a public laundry room at Princeton University.

 

Tasks. ~1/2 page. Describe the tasks you have chosen to support in this working

prototype (3 short descriptions, 2–3 sentences each; should be one easy, one

medium, one hard). If you have not changed the tasks from P5, you can re-use your text from P5 here. Otherwise, if you have changed the tasks, explain how and why. In any case, explain why you have chosen these tasks.

1. Cur­rent User: Lock­ing the machine:

– The Current User inputs ID number into lock­ing unit key­pad. The product will then try and match his number to a netid in our system. If it finds a match, it will ask the user if this is their id. They can then answer yes or no and if yes, the machine locks. This netid is also the netid that will be sent emails if an alert is sent. This task would be medium in difficulty as the user has to ensure that he/she enters the right 9-digit number.

2. Next User: Send­ing mes­sage to cur­rent user that laun­dry is done and some­one is wait­ing to use the machine:

– When there are no machines open, the next user can press a but­ton to send an alert at any time dur­ing the cycle. When the but­ton is pressed, and the id of the next user is verified, an alert will be sent to the current user saying someone is waiting to use the machine. The difficulty of this task would be easy/medium, as the next user has to input his/her 9-digit ID number.

3. Cur­rent User: Unlock the machine:

– If the machine is cur­rently locked and the current user wishes to unlock the machine, the cur­rent user must input his princeton ID number. Once he has done this, the system then checks this id and tries to find a potential match to a net id. If it does, it will ask the user if this is his net id and on yes, it will unlock. This is a medium/hard task, as the user must input his number and confirm to unlock.

 

We chose these specific tasks, because these are the three main (and only) tasks our system is designed to execute (at least in this model…. in future models, additional features could be implemented).

 

Newly added to the machine was a grace period allowed after the first alert had been sent (if the alert button is pushed while the laundry is still running, aka during “laundry time”, then the alert is sent immediatly after “laundry time” is finished).  This specific feature did not have any impact on the above tasks; however we did explain the concept to them and observed their reactions to it.

Procedure. 1 paragraph. Describe how you conducted the study.

Once we found a willing participant, we obtained his consent using our consent script, and then proceeded to describe the basics of what our system was and how it works, leaving out any important instructions on how to perform the three tasks.  We also described the “think aloud” procedure following the protocol given at http://www.hu.mtu.edu/~njcarpen/hu3120/pdfs/thinkaloud.pdf.  We then watched and listened to the participant attempt the three tasks and observed any and all things that they said and did.  We then repeated this procedure for the other two participants.

 

Test Measures (5 points). Describe what you measured and why. Bullet points are

encouraged.

We measured the following:

  • task time – the time it took to complete each task, measured in seconds

  • self-reported satisfaction with each task

  • number of errors or mistakes

Results and Discussion (25 points). ~4 paragraphs. Provide results of your tests.

Describe what you learned from the user study. Document any changes that you plan to make in your prototype as a result of the study.

 

Times (seconds)

Task 1

1 – 20

2 – 54

3 – 27

 

Task 2

1 – 18

2 – 24

3 – 22

 

Task 3

1 – 16

2 – 14

3 – 32

 

Satisfaction (1-5)

Task 1

1 – 5

2 – 3

3 – 5

 

Task 2

1 – 5

2 – 5

3 – 5

 

Task 3

1 – 5

2 – 5

3 – 4

 

Number of errors (#)

Task 1

1 – 0

2 – 1

3 – 0

 

Task 2

1 – 0

2 – 0

3 – 0

 

Task 3

1 – 0

2 – 0

3 – 1

 

Overall, the results of our user study were encouraging.  The users generally had a good feel for what was required of them to accomplish the tasks set before them.  The first user was able to accomplish all tasks with no problems.  The second user had a bit of trouble with locking the machine, and the third user had a small problem with locking it again.

 

Problems

The second user had a problem with locking the machine.  She couldn’t figure out what the machine was asking for when it said “Enter ID: “.  At Princeton, every student is assigned a Princeton ID number when they enroll at the school.  However, this number is only used rarely, as most activities only require the student to swipe their prox.  This is probably the main reason behind the problem.  The third participant messed up when typing in his ID again to unlock the machine.  We judged this is as a rather inconsequential error, but noted that there may be easier ways to authenticate a user rather than have them type in a 9-digit number the user most likely does not have memorized each time they lock or unlock the machine.  Additionally, although not specifically part of any of the tasks, users one and three expressed a little bit of confusion when informed about the concept of the grace period.  Although inconsequential to the tasks they were asked to perform, it was still noted and taken into consideration.

 

Cool! Comments

All three users, when prompted for the second task, made some kind of remark about how they thought the ability to send an email to the “current user” of the machine was really cool.  We saw this as a very good sign for our product.

 

Although, we mostly received very positive reviews from each participant, there are some areas where the product could be improved for future usability tests.  First, we could arrange an easier way for user authentication.  Possibilities for this would include a prox swiper, a netid input (rather than Princeton ID), or other Princeton identification means.  Second, we could attempt to inform the user more about what is going on with the machine currently.  A couple of the users expressed confusion about the concepts of the grace period and alert sending when the laundry was not done.  This could be easily improved in future versions.

Appendices (5 points).

Provide all things you read or handed to the participant: consent form,

demographic questionnaire, demo script, post-task questionnaire and/or interview

script.

consent form,  demo script, demographic questionnaire

 

Also provide raw data (i.e., your merged critical incident logs, questionnaire

responses, etc.)

 

Demographic Questionnaire Responses:

Participant 1:

1.) Male

2.) 21

3.) single

4.) summer internship

5.) college junior

6.) MAE

7.) every 2 or 3 weeks

8.) the keypad on the princeton doors?

9.) Nope

 

Participant 2:

1.) Female

2.) 19

3.) single

4.) dining hall

5.) college freshman

6.) undecided

7.) every week

8.) No, I don’t think so?

9.) Yes, had my laundry taken out of dryer and put in washer, when some of the things shouldnt be washed.  It made me very mad.

 

Participant 3:

1.) Male

2.) 19

3.) single

4.) unemployed

5.) high school

6.) college freshman

7.) every two weeks on Sundays

8.) Princeton keypads?

9.) Not really.  Have had it taken out before, but I didn’t care too much.

 

***** Post-Demo Questionnaire

 

Based on the following scale from 1 to 5, please rate your agreement with the following questions:

0.) Strongly disagree

1.) Disagree

2.) Slightly Disagree

3.) Slightly Agree

4.) Agree

5.) Strongly Agree

 

1. I felt secure with my laundry using this device.

-Subject 1: 4

-Subject 2: 5

-Subject 3: 4

 

2. I felt less guilty pulling the laundry out of the machine after the grace period is expired.

-Subject 1: 5

-Subject 2: 5

-Subject 3: 5

 

3. I believe this device will increase efficiency in the laundry room.

-Subject 1: 4

-Subject 2: 3

-Subject 3: 5

 

4. I would be less irritated if my laundry was taken out after a warning and the grace period.

-Subject 1: 4

-Subject 2: 4

-Subject 3: 4

 

5. When mass-produced, we expect this device to take $30/device to manufacture. I believe this is a reasonable investment by the university.

-Subject 1: 5

-Subject 2: 4

-Subject 3: 5

 

6. I would definitely use this device in my daily laundry interactions.

-Subject 1: 5

-Subject 2: 5

-Subject 3: 4

 

7. It was easy to (secure the laundry machine) using the device (Task I/II/III)

-Subject 1: 5/5/5

-Subject 2: 5/5/5

-Subject 3: 5/4/5

8. The time it takes to perform the task I/II/III is reasonable

-Subject 1: 5/5/5

-Subject 2: 5/5/5

-Subject 3: 5/5/5

 

1. How long do you think the Grace Period should be?

-Subject 1: 10 minutes

-Subject 2: 5 minutes

-Subject 3: 7 minutes

 

Group 8 – Backend Cleaning Inspectors – P5: Working Prototype

Posted on by

Your group number and name
Group 8 – Backend Cleaning Inspectors

First names of everyone in your group
Dylan
Green
Tae Jun
Keunwoo Peter

1-sentence project summary. 1 paragraph describing the tasks you have chosen to support in this working prototype (3 short descriptions, 2–3 sentences each; should be one easy, one medium, one hard).
Our project is to make a device that could help with laun­dry room security.

Tasks supported in this prototype
1. Cur­rent User: Lock­ing the machine:

– The Current User inputs ID number into lock­ing unit key­pad. The product will then try and match his number to a netid in our system. If it finds a match, it will ask the user if this is their id. They can then answer yes or no and if yes, the machine locks. This netid is also the netid that will be sent emails if an alert is sent. This task would be medium in difficulty as the user has to ensure that he/she enters the right 9-digit number.

2. Next User: Send­ing mes­sage to cur­rent user that laun­dry is done and some­one is wait­ing to use the machine:

– When there are no machines open, the next user can press a but­ton to send an alert at any time dur­ing the cycle. When the but­ton is pressed, an alert will be sent to the current user saying someone is waiting to use the machine. The difficulty of this task would be easy. It is lit­er­ally as easy as press­ing a button.

3. Cur­rent User: Unlock the machine:

– If the machine is cur­rently locked and the current user wishes to unlock the machine, the cur­rent user must input his princeton ID number. Once he has done this, the system then checks this id and tries to find a potential match to a net id. If it does, it will ask the user if this is his net id and on yes, it will unlock. This is a medium/hard task, as the user must input his number and confirm to unlock.

1 short paragraph discussing how your choice of tasks has changed from P3 and P4, if at all, as well as the rationale for changing or not changing the set of tasks from your earlier work.
The only change to our task was that instead of unlocking automatically when the cycle and following grace period ended, our system will unlock only when a new user alerts the owner of the locked machine (followed by a subsequent, shorter grace period).

2–3 paragraphs discussing your revised interface design
Describe changes you made to the design as a result of P4, and your rationale
behind these changes (refer to photos, your P4 blog post, etc. where appropriate)
We decided to only make one significant change to our system. Before, we planned to have our system automatically unlock after the grace period (the 10 minute-ish period after the laundry finished) was finished. However, we decided that there is no reason to unlock the machine if no one is waiting to use it. That would be unnecessarily risky. Thus, we decided to start the grace period only after an alert has been sent to the current user.

Provide updated storyboards of your 3 tasks
first task

second task

third task

Provide sketches for still-unimplemented portions of the system, and any other
sketches that are helpful in communicating changes to your design and/or
scenarios

3–4 paragraphs providing an overview and discussion of your new prototype

Discuss the implemented functionality, with references to images and/or video in the next section
 Our product implements each of the three tasks described above. In addition to the procedures mentioned above for taks one and two, our product also gracefully handles backspacing, clearing, and various other errors, such as entering the wrong id or an id not yet in our database system. As for the matching of the numbers to ids, currently we have just hardcoded a few pairs into our system. Were we to make our product for real, we would have to get a list from the school and integrate it with our product. This is unnecessary for our product at this stage however.

Describe what functionality from the proposed complete system you decided to leave out of this prototype, and why
 As of right now, we have not implemented the grace period system yet. It is intended to be a system where an alert can be sent, once the machine is finished running. When someone presses the alert button, our product sends an email to the current user of the machine telling them that someone is waiting to use the machine, and that the machine will be unlocked after a certain period of grace time has passed. We haven’t decided how long this grace period will be yet, but we think something like 5 or 10 minutes should suffice. The alert button can also be pressed before the laundry is done (before 35 minutes have passed), but the alert is still only sent once the laundry is done. The reason we have not fully implemented this grace period functionality yet, is because we had trouble with the code for implementing a third party timer class. We plan to have this functionality up and running in a week or so. We do however have the “send alert” functionality already running. When the button is pushed an email will be sent to the current user alerting them that someone wishes to use their machine. We just haven’t implemented the grace period timing yet.

iii. Describe any wizard-of-oz techniques that are required to make your prototype work

No wizard of oz techniques are required to make our prototype work.

In the above sections, be sure to provide your rationale for choosing what
functionality to implement, what to wizard-of-oz, and what to ignore.
The only thing we havent implemented yet is the timing mechanism for the grace period interval. This is due to unfamiliarity using third party library to implement the timing code.

Document any code you used that was not written by your team (e.g., obtained
from an online tutorial, third-party library, etc.). If you did not use code from other
sources, say so.
The additional libraries we use are: Keypad, LiquidCrystal, Servo, SimpleTimer, and WiFly Shield.

Video and/or images documenting your current prototype

keypad

wifly shield and lcd

inside of lock mechanism

whole set up

lcd screen

lock mechanism

Videos:

Group 8 – Lab 3

Posted on by

Group 8: The Backend Cleaning Inspectors

Dylan Bowman – dbowman

Peter Yu – keunwooy

Green Choi – ghchoi

Tae Jun Ham – tae

 

Description:

We built a miniature toy that moves around using two Servo motors, which act as legs for the toy.  The toy is controlled using a light sensor and potentiometer.  The potentiometer controls the direction of the toy (either left, right, or straight), and the light sensor tells the toy when to move.  When the light sensor is covered up (dark), the toy will move in whatever direction the potentiometer has set it, and when it’s uncovered (light) it stops moving.  We built this, because it’s a fun little toy that takes advantage of Servo motors as well as sensors that we’ve learned to implement.  The toy was a success in that we could control its movements and make it turn directions, but the Servo motors were not the most reliable source of propulsion in that they occasionally fell off, or the movement was not exactly ideal.

List of Brainstorming Ideas:

  1. RC Boat with DC motor propellor and Servo motor for steering
  2. Two servo motors, one on each side, in replication of Walker from Star Wars, or little bug toy
  3. Two wheel based mini cars (rubber around DC motors)
  4. Moving sprinkler – tied to a DC motor which pulls it forward, while Servo motor allows the sprinkler to spread water around
  5. Balloon powered car – Servo motor acts as rudder to steer air coming out of balloon on back of car
  6. Blimp with oscillating Servo motor powered wings that keep it afloat and steer it
  7. 4 DC wheel robot with an oscillating Servo motor arm that regularly pushes against a flex sensor which initiates the DC wheels to move
  8. Helicopter with a DC motor helicopter blade on top
  9. Sailboat with flex sensors that read where the wind is blowing from and turns the sail to best catch the wind
  10. Line tracer, car that traces a line on the floor to target point
  11. Wave generator, put a DC motor with a blade attached under the water which initiates waves which will push an object on the surface towards a point
  12. Paper airplane that can stay in the air forever (or a long time) by using force sensors to adjust flaps on the plane to stay in the air

Photos of Design Sketches:

Video of Our Final System:

List of Parts:

– Two servo motors

– photo cell

– potentiometer

– Capacitor (optional)

– Resistor

Instructions:

Connect the light sensor with the resistor and complete the circuit into an analog pin (0 in our case). Connect the potentiometer to an analog pin (1 in our case). Connect the servo motors to two different digital pins (5 and 9 in our case). Here you can use a capacitor (see http://learn.adafruit.com/downloads/pdf/adafruit-arduino-lesson-14-servo-motors.pdf) to power the servos more reliably. We did use a capacitor, but it’s not strictly necessary. Use the attached code.

Source Code:

#include 

int lightPin = 0;
int knobPin = 1;
int servoPinL = 5;
int servoPinR = 9;
Servo servoL;
Servo servoR;
int l;
int r;
void setup()
{
 servoL.attach(servoPinL);
 servoR.attach(servoPinR);
 Serial.begin(9600);
}

void loop()
{
 int reading = analogRead(lightPin);     // 0 to 1023
 int leftOrRight = analogRead(knobPin);
 if (leftOrRight  200) {
     servoL.write(0);
     servoR.write(90);
   }
   else {
     servoL.write(0);
     servoR.write(0);
   }
 } else if (leftOrRight  200) {
     servoL.write(0);
     servoR.write(90);
   }
   else {
     servoL.write(90);
     servoR.write(0);
   }
 } else {
   // go right
   if (reading > 200) {
     servoL.write(0);
     servoR.write(0);
   }
   else {
     servoL.write(90);
     servoR.write(0);
   }
 }

}

MTA website Heuristic Evaluatio

Posted on by

Names:

  • Dylan Bowman (dbowman)
  • Kiran Vodrahalli (knv)
  • Andrew Boik (aboik)
  • Avneesh Sarwate (asarwate)
  • Kuni Nagakura (nagakura)

Discussion:

  • We encountered several severe problems in our evaluation.  First, the home page is pretty cluttered with links and images that are not all entirely relevant.  This belongs to H8, as it is a aesthetic issue.  Another major problem was that there was no real help for using the website.  There was a section of FAQ’s but it was basically a list of question and answer pairs on what to do in specific real world situations riding MTA transportation. There was no real help beyond this. This belongs to H10.  One last severe problem was that there were multiple links labelled “schedule” on the home page that did not necessarily lead to the same information.  This is highly confusing.  This belongs to H4.  These could pretty easily be fixed by removing unnecessary interfaces on the home page, adding help documentation, and making the links more descriptive in what they access.
  • Problems that have to do with Help and Documentation (H10) were made more obvious having seen Nielsen’s Heuristics. As experienced users of basic websites, we don’t really require any documentation on how to actually use the website efficiently, however this is actually necessary for users with less experience on the internet.
  • One heurisitic we would propose to be added would be some kind of metric to determine how appropriate an interface is for a desired action or information.  For our system, some of the schedule links simply gave us a static table of times for all weeks and weekends that is extremely cluttered and difficult to read.  Another heuristic we want to propose would be the accuracy or correctness of the actual information.  In our situation, the pdf timetables for each transit line is not accurate–the table doesn’t account for local delays, etc.
  • Possible discussion/test questions: Matching a heuristic to a problem. Prioritizing different heuristic violations and justifying why you chose to focus on this problem and not another

Links:

Dylan – https://www.dropbox.com/s/34yylen10hgotsk/A3.pdf

Kuni – http://dl.dropbox.com/u/62526404/Heuristic%20Evaluation.pdf

Kirin – https://dl-web.dropbox.com/get/MTA_HeuristicEvaluation_cos436.pdf?w=AAB5dUrwPdc3JlGrq5JXS_dnEXtLfnQ8sq37-Pc8d_csIQ

Andrew – https://docs.google.com/file/d/0B9Qj9O_Quv4pempKRzlWLWZBa28/edit?usp=sharing

Avneesh – https://dl.dropbox.com/u/30768213/MTA_Review_Avneesh.pdf