Final Project Team Chewbacca

Group Number and Name
Group 14, Team Chewbacca

Eugene, Stephen, Jean, Karena

Our project is a sys­tem con­sist­ing of a bowl, dog col­lar, and mobile app that helps busy own­ers take care of their dog by col­lect­ing and ana­lyz­ing data about the dog’s diet and fit­ness, and option­ally send­ing the owner noti­fi­ca­tions when they should feed or exer­cise their dog.

P1: Group Brainstorming
P2: Contextual Inquiry and Task Analysis
P3: Low-Fidelity Prototype
P4: Usability Test with Lo-Fi Prototype
P5: Working Prototype
P6: Pilot Usability Study

Project Video


1. Added the “generate report” button to the top “action bar” of the application. This way, users can see the button much more easily. We found in our testing that this was a significant problem for users who were inexperienced with the hardware of the Samsung Galaxy S3, where the settings button appears on the top right in that position.

2. Changed the home screen panels to actual buttons that would automate a swipe motion instead of doing nothing upon clicking. This makes it all right if the user identifies one of the panels as a button instead of swiping, since both actions will lead to the same place.

3. Instead of automating the “Wizard of Oz” functionality by pressing the panels five times, we changed it to the settings menu

4. Redesigned collar for more compact design

Evolution of Goals/Design

Overall goal
When we began brainstorming the design of our system, we thought about making a convenient pet owner system that would integrate any feature related to owning a pet. This included adding features like  a GPS tracking device to detect the location of the dog, and a physical dog feeder that would release food at certain times in the day. As we began developing our project, we realized that we should make our app a lot more focused, and not just add any feature related to pet-owning. As we started performing contextual analysis and interviews with our users, busy dog owners, we realized maintaining the dog’s health should be our primary focus because they were too busy to keep track of their dog’s activity and health habits on a day-to-day basis-but also that they did not want to be overwhelmed with so much data. Therefore, our overall goal for the pet-owner system transformed from making pet-owning more convenient for the dog-owner, to allowing the user to maintain the dog’s health with three different tasks: tracking the dog’s diet pattern (how much it has eaten every day), tracking the dog’s activity level (how many steps it has taken every day), and being able to send the data to a veterinarian who can add further insight on the dog’s behavior.

Design changes to system
The design of our project also evolved considerably over the course of the semester.  In our initial sketches and prototypes, our mobile app functioned more as a data log than as a tool for data interpretation.  For example, in our paper prototype in P3, the homepage of our mobile app only included a “total health score” and the time the dog bowl was last filled.  It did not include suggestions about how to respond to or improve the health score, or provide feedback to the user about whether or not they should feed or walk their dog.  During our prototype testing in P4, this limitation of our system was brought to our attention by the feedback we received from users, as they expressed that they wanted direct, actionable feedback and recommendations from the mobile app.  Another major design change we made to our mobile app was to “hide” our more detailed data in separate pages that were linked from the main diet and activity pages, as prototype testers expressed being overwhelmed by the long-term data, and said that they would not access this data very often.  This also helped us to keep the most relevant information “above the fold” in keeping with Nielsen’s Heuristics (H8: Aesthetic and Minimalist Design).  Finally, we made changed the initial designs of both the dog bowl and collar by eliminating the time display panel on the dog bowl and the LEDs on both the bowl and collar.  We made this change because it did not communicate much information to the user, and we felt that this created a more minimalist design.

Critical Evaluation
As our system is currently implemented, there are several design obstacles that we need to address in order to turn this final prototype into a useful real-world system.  First, we need to fully integrate bluetooth into the functionality of our app, as we currently signal another application, Amarino, to run in the background and connect to bluetooth instead of handing this in the DogSmart application. We also must consider the scalability of this device to multiple users – our current system only accounts for one smartphone to control the device, but in the future we want users to access the data from their computers and also have other caretakers view and manage this data. We can also consider how we might adapt the device for other pets, such as cats, and what other constraints we might need to our app to make including other animals feasible.

However, we believe that these design changes are all feasible, and that with a reasonable amount of further iteration we could turn DogSmart into a real-world system.  At Communiversity, we spoke with a woman who runs a small dog-care business. We asked her a few questions, and gained some important pieces of information from her. Firstly, she commented that our system could be very useful for detecting sickness of dogs, since usually one can determine if a dog is sick by checking their health habits over an extended period of time. Additionally, she noted that this device could be very popular with dog owners, since they are often people who care very much about their dogs and are willing to purchase a variety of products to help their dog stay happy and healthy.

The process of creating and testing low- and high-fidelity prototypes has taught us a lot about both dog care and the technology requirements of this application space.  For example, by interviewing dog-owners through contextual inquiry and prototype testing we learned that dog care is mostly completed by habit and routine, so any application or system being implemented in this space must integrate seamlessly into the user’s everyday life, running in the background and enhancing their normal routine without being an intrusive presence.  Thus, this application space is an appropriate environment for ubiquitous computing systems, and throughout the development process for DogSmart we have worked to fit our system to this model of computing.  In addition, the process of developing our system taught us about how to integrate several different hardware/software systems together; this included using bluetooth communication to connect data from Arduino hardware/software to an Android app. During this process, we also realized the limitations of using Bluetooth and the complications that arise from these limitations. The Bluetooth device only has a limited range, meaning the data can only be transferred when the Bluetooth device is in the vicinity of the Android app. This meant we had to either ensure the dog was always in the range of the Android app, or configure a database in the Arduino software so the data stored in the Arduino could be transferred to the Android app.

Moving Forward
If we had more time, we would definitely focus on giving our mobile app the capacity to handle memory. Our app is currently only running in real-time, and outputs are based on sensor data that occurs during an event in real-time. If we were to incorporate a database into our mobile app, we would have the option of using the EEPROM database in Arduino or the SQLITE software in Android. We would also focus on incorporating real-world data about dog health into the program. This would mean identifying important measures of dog health including the recommended level of exercise for different dogs, and the corresponding amount of food they should eat based on their exercise level. If this data did not exist, we would likely have to talk to veterinarians or experts in animal health who could give reasonable answers. This data would allow us to give more accurate feedback to the user about their dog’s overall health, and to give more accurate recommendations. Alternatively, we could also establish a “baseline testing” period of using the system, where the device would collect data about the dog’s movement and eating levels, and then incorporate this into a baseline measurement. When the dog deviates from this baseline, the device could report it as non-healthy behavior.

More specifically, we would need to change all the features of our app for which we are currently using “Wizard-of-Oz” techniques. This includes having actual graphs for activity level and amounts of food that correspond to data that has actually been collected over time. This also means having the color changes corresponding to how urgent the situation is; how dire the situation is based on data collected over time (the last time the dog was fed and the dog’s activity level). We would also like to have a valid way of assessing the dog’s health and calculating the health score. This is related to having real-world data stored in our app or a “baseline” data set,, as mentioned above. In the future, we would like our generate report to compile a nicely formatted pdf of the data collected over time, and be able to e-mail the pdf to the veterinarian. Currently, it does not have the data, and therefore, we could not actually implement this feature. We would also like to be able to send reminder notifications to the user, telling them that their dog needs to be fed. This could be done either as a text message, or an Android reminder message. Finally, we would like the app to be customized to different types of dogs.. We would like the user to be able to enter the type of dog they have, and have the threshold for steps, and the recommended food and activity levels calibrated accordingly. Finally, we would like to make the picture on the home screen of the app customizable. This means enabling the user to upload a picture of their own dog. If we were to test users in the future, we would like to test several types of dogs with our app to see how it responds to different dogs. Furthermore, we would get feedback from users on how they might actually use the long term data, and from testing, identify how we would like to display the data collected. Lastly, we would likely talk to dog experts who could possibly help with the back-end analysis of data, and identify what features are useful for a veterinarian versus which features are not as useful. 

Source Code

Third Party Code

MeetAndroid.h library
helps establish the bluetooth connection between the Arduino and the Android

Time.h library
allows us to get the current time reading for the dog bowl updates

Amarino libraries
code that allows Android to establish bluetooth connection with the Arduino

part of the Amarino library that graphs real-time data collected via Bluetooth

a library that is used by the Sensor Graph code in the Amarino library

Date Format Library
a library that allows the date printed on the screen to be formatted

Date library
allows the date to be read in as an object, and then manipulated easily

Tutorial for Sensor Graph

Tutorial for Android Begin­ners

Presentation Information

Click to access Poster.pdf


Lab 3, Group 14 (Team Chewbacca) – Catapult

i. Karena

ii. Group 14

iii. Short Description

We built a catapult that detects when something is nearby. Upon sensing something, the catapult will launch a small object in the direction of where the thing was sensed. We wanted to make something that reacted to a proximity sensor mounted on a rotating arm, and we thought a catapult was a fun and creative way to have a system that reacted to a nearby object. An inspiration for our project was defense mechanisms, that may be employed in preventing unwanted people or objects from nearing a certain range. Our original plan was to make a robot that moved in the direction of an object that it detected, but after multiple iterations, we could not get the robot to move forward effectively.  The forward motion was not effective because the motors weren’t powerful enough, and the servos would resume to their original position after moving, which canceled the forward motion. In the end, we ultimately decided to launch something at the target instead of moving towards it. With additional motors or materials, we might have been able to achieve our original idea. We thought we were successful in creating a robot that moved in reaction to its surroundings. The catapult accurately launched an object at considerable speed towards the target, and the proximity sensor responded immediately to targets it touched. One improvement we would have liked to make to our project would be to make our proximity sensor more powerful.  Because we didn’t have a 10 MegaOhm resistor, the catapult would only detect an object that was touching the proximity sensor. We would be able to improve our catapult if we had access to this resistor.

iv. Brainstorm
– smart window-blind motor (more light lowers blind using motor, less light raises blind using motor)
– flying robot that increases the motor speed depending on it’s proximity from the ground
– catapult; propels an object at different speeds
– tilt the arduino controller to move the robot
– a segway (with a servomotor fowards/backwards movement controller)
– mono-segway (hard)
– impulses depending on acceleration from accelerometer
–  temperature-sensing fan
– linear sensor with FSR – fsr controls speed, linear controls turning
– line follower/wall avoider
– moves towards light in its field of vision (servomotor wiggles the light sensor from side to side to get the max light reading)
– disk-shooting robot
– sweeping robot – spins around and pushes dirt around
– a top robot – spins around and balances itself
– a two stage system – first catapults itself using a heavy weight controlled by a servo (wires detach from the force), and then moves around
– a paddling robot for land and water
– kicking robot using proximity
– a monocycle – aka hamster bot
– hopping robot
– throw out a bunch of stuff on the robot to push it backways
– advances the lead on a mechanical pencil to push it forward
– inchworm robot (servos)
– underwater propeller
– a rocking robot
– hovercraft – propeller downwards, then another propeler sideways

v. photos of design sketches

20130331_180930 20130331_192759 20130331_192811



vi. video of final system

vii. list of parts

  • two servomotors
  • proximity sensor (using tin foil)
  • arduino uno
  • breadboards
  • a lot of tape
  • wires
  • some cardboard
  • straw
  • foil


Attach two servo motors to the arduino, and attach these to the straw by attaching one servo to the straw, and the second servo is attached to the first servo. The first servo acts as the “turning servo” which will turn the straw around to look for an object within its proximity, and the second servo  acts as the “shooting servo” to fire the catapult when something is detected.

ix. source code

Adafruit Arduino – Lesson 14. Sweep
#include <CapacitiveSensorDue.h>
#include <Servo.h>
int servoPin = 8;
int servoPin2 = 7;
Servo servo;
Servo servo2;
int angle = 0;   // servo position in degrees
int motorPin = 3;
CapacitiveSensorDue cs_4_2 = CapacitiveSensorDue(4,2); // 10M resistor between pins 4 & 2, pin 2 is sensor pin, add a wire and or foil if desired
void setup()
  pinMode(motorPin, OUTPUT);
int readCapacitor() {
  long start = millis();
  long total1 =;
  Serial.print(millis() – start); // check on performance in milliseconds
  Serial.print(“\t”); // tab character for debug windown spacing
  Serial.println(total1); // print sensor output 1
  return total1;
int threshold = 100;
void moveforwards () {
     // scan from 0 to 180 degrees
   int maxangle = 0, maxvalue = 0;
  // now scan back from 180 to 0 degrees
    maxangle = 0, maxvalue = 0;
  for(angle = 180; angle > 0; angle–)
void loop()
  // scan from 0 to 180 degrees
  int maxangle = 0, maxvalue = 0;
  for(angle = 60; angle < 180; angle++)
    if (angle % 1 == 0) {
      int proximity = readCapacitor();
      if (proximity > threshold) {
  // now scan back from 180 to 0 degrees
  maxangle = 0, maxvalue = 0;
  for(angle = 180; angle > 60; angle–)
    if (angle % 1 == 0) {
      int proximity = readCapacitor();
      if (proximity > threshold) {



A3 – TransLoc App

Stephen Cognetta
Jean Choi
Karena Cai

1. Most Severe problems with the app/site?
a. Error Prevention
When clicking too many lines/routes, the app will freeze and subsequently crash. This happened for over 10 lines. This is clearly within heuristic 5 – this error could have been prevented by the app. A suggestion for fixing this problem would be either to alert the user if they have picked too many lines, or to allow the app to accept a greater number of lines without crashing. This would therefore prevent users from picking too many bus lines than they should.
b. Consistency and Standards (H4)
The symbols are not very intuitive and do not allow the user to understand what functionalities correspond to the symbols. For instance, the magnifying glass shows the user the stops as opposed to some button that says: show stops. Also, the less than and greater than sign <> takes you back to your previous screen (after you have altered the map in some way). The user has no idea of the button’s functionality until he/she clicks on the button. There are also many useful functionalities of the app, but the features are not well documented and do not abide by standards of most interfaces, and thus can easily go unnoticed and unused. A solution to this problem might be introducing some legend or using short words and phrases that allow the user to have a better understanding of the functionalities of different buttons. These changes would introduce a standard for the application, and thus, fall under the consistency and standards heuristic. 

2. The biggest issue was the consistency and standards. Oftentimes throughout using the app, there would be an inconsistency with the use of symbols and characters. This problem is elaborated on above, in section 1b, and we probably would not have paid such close attention to this if we hadn’t kept the Nielsen standards in mind. One additional error that we would not have found otherwise would be the error that we found – that when adding too many lines, the app crashed. We wouldn’t have known to add so many lines if it weren’t for the heuristic of error prevention. Keeping this heuristic in mind, we tried to generate errors throughout our use of the app, and uncovered this important flaw.

Furthermore, we all knew in a broad sense why the app was pretty faulty, but Nielsen’s heuristics gave us a means to evaluate the website and pinpoint exactly what regions the app was lacking in. For instance, we all knew the app was pretty hard to use, but by looking through Nielsen’s heuristics, we could determine the reason why it was hard to use. Therefore, Nielsen’s heuristics gave us a criteria we could use to evaluate the app.


3. a. How accessible is an application to different people– are certain demographics excluded from the functionality of the app? (no wifi, no bluetooth, etc.)
b. How accessible is an application to people with limitations – such as color-blindness, deaf people, etc.

4. Useful Class Discussion Questions
– What are different methods you can use to improve violations of Nielsen’s heuristics?
– What are the particular problems associated with different platforms in meeting Nielsen’s heuristics? (i.e. mobile, computer, etc.)
– In which cases can the heuristics be violated? Perhaps there are situations where implementing the heuristics prove to be unnecessary/incorrect?
Exam questions:
– Given a particular interface, name five or more different issues with the Neilsen heuristics for the given interface.
– Rank the severity of several given heuristic violations

– Karena Cai:
– Jean Choi:
– Stephen Cognetta:


P2 – Group 14 (Chewbacca)

Lab 14

Stephen: wrote up the descriptions of the interviewed users and most of the contextual inquiry sections were planned here. Helped conduct interviews.
Karena: drew the 3 different story boards, helped with the task analysis questions, worked on writing up the interface design questions
Jean: helped conduct interviews, contextual inquiry writeups, also wrote up the tasks for the users
Eugene: drew the pictures and answered the task analysis questions, helped conduct the interviews

Problem and solution overview
We are addressing the problem of taking care of a dog, which involves tasks that are often shared between multiple people, completed/monitored by routine and memory, and sometimes entrusted to others when owners leave their dogs for extended periods of time.  These tasks, the most important of which are feeding, exercising, and monitoring a dog’s location, are currently done through imprecise measures, cannot be monitored over long periods of time, and are periodically forgotten.  We propose a system that involves a device that can be attached to a dog’s food and water bowl and a separate device that can be put on its collar, which detects the dog’s food and water intake, how much exercise or activity it has gotten, and its location, and aggregates this data for viewing on a mobile device.  The devices alert the owner when the dog has not been fed according to schedule and, tracks whether the dog has gotten enough activity over time, and shows its location, so owners can check up on it when they are not home.

Description of users you observed in the contextual inquiry

Our target user group is dog-owners who are concerned about their dogs health and who must spend time away from their household due to business, vacation, etc. They might share responsibility for the dog with others, and when they leave their house they must leave their dog alone in their house with either a neighbor or a paid caretaker to watch after the dog.We chose this target group because they would benefit the most from our idea, and have a currently strong need that must be resolved. Our first interviewee was a high-school student who owns a beagle. She shares the responsibilities for the dog with her sister, and says she forgets to feed her dog about every two weeks. When she travels with her family, they usually ask her neighbor. Our second user is a graduate student who lives on campus with his dog.  He is its primary caretaker, but he has to leave it inside while he teaches classes and does work in the lab.  He says his lab schedule is often unpredictable and runs over time, so he cannot follow a regular routine and is concerned his dog doesn’t get enough activity. Our last interviewee was a stay-at-home mother whose kids have all moved out of the house. She owns a dog (and two cats) and is its primary caretaker. She usually completes all of the tasks involved in taking care of her dog right before and right after work.  She is very routine-driven and rarely forgets to take care of her dog, but she becomes extremely stressed when she is away from home because she worries if it is ok.  This makes it hard for her to visit her kids or go on vacation for extended periods of time.

CI interview descriptions

We conducted several interviews, in a variety of different locations. Our general approach was twofold: we observed and eventually approached dog-owners while they walked around campus with their dog, and we asked owners who were at home with their dog. Our approach was to observe the owners as they went by with their dogs on campus, and take notes of our observations. We asked some preliminary questions to people we knew who have dogs at home, and then asked if we could talk to the primary caretakers in their family.  The graduate student who we interviewed was someone that we had observed walking their dog around our dorm room, and who we approached and asked questions.

All of our users definitely cared deeply about their dog’s well being and felt that their dog was important to them in their life. All of users were also busy and reported forgotting to feed their dog at least periodically. The high-schooler we interviewed was unique in that she was the only person who shared responsibility for her dog. She also mentioned that her dog often has other medical needs that need to be done on a recurring schedule, which suggested additional functionality for our interface, such as another button that would allow for checking up on personalized activities like giving medicine.  The graduate student we interviewed was unique because he had a more unpredictable schedule than the other users, and had the most trouble following a routine, and would probably benefit the most from a mobile device. The stay-at-home mom we interviewed was unique in that she didn’t really have many issues with feeding or exercising with her dog. She was also unique in how anxious she said she got when she was away from her dog.  She said that this is actually a constraint for how long she can leave the house, so this feedback would allow her to feel more relaxed during holidays/on vacations. It makes sense that all of the owners we interviewed cared about their dog and were interested in improving their dog’s lifestyle for the better. However, it is clear that different lifestyles/ages (students or working adults) lead to different issues in taking care of a pet.

Answers to 11 task analysis questions
1. Who is going to use the system?
Our target user group – dog-owners who have a vested interest in the well-being of their dog yet are too busy to sufficiently do so.

2. What tasks do they now perform?
Our current target user group feeds the dog, gives the dog water, walks the dog, and must make sure the dog stays within the appropriate boundaries (by putting up fences, etc.). If the dog owner must leave for vacation, they must make arrangements with someone for their dog to be taken care of while they are gone.

3. What tasks are desired?
One desired task is to set reminders for the user to feed the dog, or allow multiple people to feed a dog with little overlap. Another task would be to check up on the dog to know if they are getting sufficient exercise and staying healthy, relative to what they are eating. Also, it would be helpful to easily transition between users, so that if a user is going away for vacation, their dogsitter can easily know when to feed the dog, while the user can know if their dog is being taken care of appropriately.

4. How are the tasks learned?
The tasks are very visual, and therefore, easy to learn. The system is automated and serves as a friendly reminder to perform tasks. As soon as the user becomes familiar with how the reminders/updates about his/her dog work, he/she will learn how to respond to them, and therefore, learn the tasks.

5. Where are the tasks performed?
The tasks are mainly performed within the household – feeding the dog, giving the dog water, or walking outside around the house. The task of checking up on your dog while away from the household is done in any location.

6. What’s the relationship between the user and data?
The user will receive data about their dog (charts about fitness level and dietary intake), and the location of their dog through a mobile app connected to the bowl-collar system. The user can also receive alerts if any of these levels are outside a reasonable range. Given certain data, the user may change their behavior (giving less food, exercising more, etc.)

7. What other tools does the user have?
Users will also most likely have mobile phones that they can use in conjunction with this system. They will probably also have calendars, either electronic or not, that will be used to schedule important events for their dog. We can facilitate interaction amongst these devices by having the mobile phone, email, etc. all connecting to this app.

8. How do users communicate with each other?
The users of the system communicate implicitly with one another. For instance, the job of feeding the dog becomes a shared task under this system; if one person forgets, all the owners of the dog will get notified about the dog being hungry, and they can respond to this reminder. Thus, the responsibility of feeding the dog becomes a shared responsibility.

9. How often are the tasks performed?
Two of the tasks are performed on a daily basis. The activity monitor that senses the motion of the dog, and how active it has been, occurs in real-time. Meanwhile, the food reminders occur whenever the user has forgotten to feed the dog; this will vary from user-to-user. Finally, the task that serves to ensure the user that the dog has gotten fed when the owner is away, will be performed when the user has left for an extended period of time; this also varies depending on the user. The GPS tracking system will be used as frequently as the dog escapes from the backyard.

10. What are the time constraints on the tasks?
The time constraints on the tasks are not extremely relevant. As long as the reminder that the dog has not been fed is sent in a timely fashion (within 1 hour), the system should be useful to the user. When the user is getting updates (while on vacation) about the well-being of his/her dog, timing might be a little more relevant. Still, the data can be sent with a 1-2 hour grace period.

11. What happens when things go wrong?
When things go wrong–perhaps the weighing system is not calibrated well enough and the food is constantly setting alerts or maybe the activity monitor is not outputting the relevant data– the user will get unreliable data that could harm the pet, or rather, simply annoy the user.. Also, if the collar were to be removed by accident, it may omit important data to the user (the user wouldn’t be able to locate where the dog is, etc.)

Description of three tasks

Task 1: Checking who last fed the dog and when, and deciding when/whether to feed their dog.

Currently, this task is done mainly through routine and memory.  Dog owners typically have some kind of system set up with family members/apartment-mates, etc, where they split up responsibility for feeding their dog.  They have a routine for how much, how many times a day, and at what times they feed their dog, and they remember to do this task by habit (maybe feeding their dog when they eat). An owner might feed their dog twice a day in the same amount (a measuring cup), once in the morning and once in the evening. If multiple people share responsibility for feeding the dog, they might communicate orally or by texting, etc, to ask each other whether they have fed the dog.  This task is currently not very difficult, as it becomes habitual over time, but coordinating with multiple family members may pose intermittent problems, and most users report periodically forgetting to feed their dog.  Using our proposed system, coordinating this task with multiple people would be much easier, as the user would only need to check the dog bowl to see whether it is necessary to feed their pet.  In addition, the number of times the user forgets to feed their dog would be reduced, as the system would ping their mobile device when the usual feeding schedule has not been followed.

Task 2: Checking and regulating the activity of your dog

Currently, dog-owners check and regulate their dog’s activity through routine, memory, and some measure of guesswork.  This is a moderately difficult task.  Owners usually have a routine of how many times per day or week they take their dog on a walk, and they might adjust this according to their schedule (taking a shorter route when they are busier, etc). If they leave their dog outside for extended periods of time, they might guess how much activity they have gotten and use this time in lieu of other forms of activity such as walking.  In addition, activity is monitored and adjusted using relatively recent remembered “data”, such as whether the dog got less activity on a certain day or week (it is harder to remember long-term activity levels and trends).  This might lead a pet to get less activity than needed over an extended period of time and lead to weight gain, etc.  Using our proposed system, checking and regulating a dog’s activity would be much easier, as owners would not have to be reliant on memory.  They would not have to guess how much activity a dog gets when it is left alone outside, and thus would have a more accurate holistic view of their activity.  In addition, users could easily access long-term data about their dog’s activity level, and therefore see trends from over a period of several weeks or months and adjust their schedule accordingly to avoid giving their pet excessive/insufficient exercise.

Task 3: Taking care of your dog when you are away from home for extended periods of time.

Currently, users deal with this problem using a variety of methods.  Typically, they leave their dog in the care of someone they know, usually a neighbor, friend, or family member.  They might give their dogsitter a key to their house so that they can go in every day to feed/walk/check up on their dog, or they might have the dogsitter take the dog to their own home to take care of it.  They usually leave written or oral instructions about how much/how often to feed their dog, how often to let it out, and how much/how often to exercise it.  These dogsitters might have varying experience taking care of pets/dogs, and the owner might check up on the status of their dog by calling or texting the dogsitter periodically.  Overall, this is currently a difficult and stressful task, as many owners worry whether their dog is being taken care of correctly, and they might not know how responsible or trustworthy their dogsitter is.  Using our proposed system, this task would become much easier for both the owner and whoever has responsibility of the dog while the owner is away.  Owners would be able to check the status of their dog remotely, and easily see whether their pet has eaten, been let outside, and walked.  In addition, even dogsitters with very little experience taking care of dogs would find it easier to complete this task, as they would easily be able to see when the dog has not been fed enough, and when they are deviating from its usual schedule.  With mobile pings, they would also be notified when they forget to feed the dog, which might be helpful because it is not part of their regular schedule and is thus not habitual.

Interface Design
1. Text description of the functionality of system

The pet-care system has several functions. It is a system with three main components: a dog water and food bowl with weight sensors and an LED system, a motion-detecting sensor on the collar of the dog which includes a GPS tracking system, and an interface that allows the users to get data and reminders from the system. The weight sensor tracks how much the dog has been fed, and the user will get notified when the user has forgotten to feed the dog, or when their dog has not been eating. The user can also use the system to monitor how often the dog has been exercising, and give a ratio of food that is proportional to the dog’s exercise. When an owner leaves his or her dog in the care of a neighbor or a friend, the system allows the user to get updates about the dog’s activities. The GPS system attached to the collar of the dog will notify the user of the dog’s location. The system that ensures that the dog is cared in all respects, and ensures the safety, health, and attention that a dog needs from its owner. The current device that resembles this system is called Tagg. Tagg, however, features the GPS tracking system and does not have the additional functionality of ensuring that the user’s dog is fed and getting sufficient exercise. Furthermore, our system is fully automated through the bowl and collar devices. This allows the system to cause little interference in the pet-owner’s life, and makes it easy to use.

2. 3 StoryBoards

20130312_223752 20130312_223738 20130312_223802


3. A few sketches of the system itself


A schematic of the actual device, showing the weight-sensing bowl and the text display. It also shows the components: switch button, text display, accelerometer, microprocessor, battery, magnetic charging point, and a bluetooth receiver.



Shows a potential interface for the mobile app that would come associated with the device. The functionality is shown above.


Assignment 2 Karena Cai

Student 1: Curious Student

After my Fluid Dynamics class was let out, this one particular student seemed to debate whether or not to approach the professor about questions he had about the course material. He was extremely rushed and kept glancing at the clock. In the end, he decided to quickly ask the professor one question, and then hurriedly left the classroom. When I later interviewed this student, he said that he frequently felt rushed to get to the next class, but always wanted to clarify concepts that were confusing to him and his friends. An application that allowed students to easily convey their confusion would be helpful in this situation so that the professor could address the topic in the next class.

Student 2: the Precept-Preparing Student

I also started to notice how students who had a humanities precept following the lecture would frantically finish the rest of their reading, and try to jot down some notes about the things they would say during precept. An app that either combined their lecture notes and reading notes so they could easily flip through material in one location would be useful. In this situation, an app that also helped summarize the reading (via a website like Sparknotes) would also be especially useful given the time limitations.

Student 3: the student confused by a PSET problem

When I got a seat my Engineering Dynamics class early, I noticed that most students would communicate to each other by yelling across the classroom. In their discussions with each other, they would often be talking about specific questions on the problem set, and making plans for working on them later. During these discussions, however, the professor would cut them off as he/she began lecturing. Since most students had a class following the lecture, they wouldn’t be able to finish their conversations unless via text later. It would be useful if there was an app that facilitated some type of mobile conversation between all the students in the classroom. This would also allow the professor an easier time to begin class without having to quiet everyone down.

Student 4: The Student Engrossed in her Phone

I observed that the most common things students did between classes were: e-mail checking, browsing through blogs, and occupying their time with a game on their phone. Other than chatting about the latest pset problem, there was little interaction between the students. Most of the time was spent as alone time. I think an app that cultivated some discussion between students, or acted as some type of convenient way to meet new people would be useful to facilitate conversation and make the waiting time a time to allow people to communicate face-to-face. Furthermore, when people walk from class-to-class will often-times walk with the same people, or nobody at all.

What I gathered from interviews with fellow classmates (Rishita Patlolla, Richard Cheng, and April Liang):

– Students wanted more time to approach professor and ask some clarifying questions
– Access to food on the way to classes would be extremely useful
– The walk is sometimes impossible to make in the given time
– There isn’t enough time to make lunch plans so students normally end up eating with the same people
– Printing is very difficult between classes
– Planning what to say in precept normally occurs during this time
– The time in between classes is generally hurried and slightly stressful

Brainstorming ideas (collaborated with Jean Choi)

  1. Seat-finder for the late student: helps a student who has walked into the classroom a few minutes late, find a good seat without interrupting the lecture
  2. Optimized route finder for the biker: calculates the best path for a student on a bike to take to get to his/her next path (based on congestion of people, traffic, weather, etc.
  3. Printing cluster optimizer: helps student find the most convenient and least congested printer in between classes
  4. Mindful meditation application: allows student to practice a few minutes of mindful meditation in between classes to relieve stress
  5. Social app: helps students find walking buddies, coordinate lunch and meet new people 
  6. Trivia game for class materials: review the material that was just taught during lecture
  7. Reminder app: helps student remember which classes to go to and what meetings they have for the rest of the day
  8. Precept discussion preparation app: pulls up all lecture and reading notes pertaining to the discussion that student is preparing for
  9. Device that syncs students mobiles who are currently in the classroom so that they can communicate about concepts or problems they are confused about and find a time to work on the problem sets together
  10. Exercising application: app that records how many calories being burnt during the trek across campus in-between classes
  11. Professor-alert: allows professor to immediately gain the attention of all the students and notify them that he/she is starting lecture; prevents class from ending later
  12. Blogging integrator: coalesces the most popular or funniest posts from every blogging website so student doesn’t have to scroll through the unfunny post
  13. A things-to-do app that can be imported to different devices (phone, computer, etc.)
  14. Coffee stands that allow students access to coffee between classes
  15. Application that allows students to access transcribed lecture notes so that the late student can know what he/she missed
  16. Fun brain game app: helps quickly stimulate thinking so student is more likely to pay attention during class
  17. Music-syncing device: if you want to walk with someone and listen to music, the app lets you and your walking buddy share the same music without sharing headphone2 Favorite ideas (1-sentence explanation for each of why you chose that idea)

Two Favorite Ideas

  1. Social app: helps students find walking buddies, coordinate lunch and meet new people
  • I chose this idea because a lot of people were complaining about not being able to socialize and meet new people after sophomore year, but this app helps optimize the waiting time between classes by allowing them to easily coordinate walking and lunch buddies who share the same interests (or at least the same paths to class)

2. Device that syncs students mobiles who are currently in the classroom so that they can communicate about concepts or problems they are confused about and find a time to work on the problem sets together

  •  I chose this idea because a lot of the time students are trying to coordinate working on problem sets before and after class begins, and students could more effectively and more discretely communicate by using this type of communication which involves the syncing of mobile devices.


Left: The app cover; Middle: Where the user logs into the ICE network so that the app can access the user's schedule information; Right: Additional information the user should enter for optimal search results

Left: The app cover; Middle: Where the user logs into the ICE network so that the app can access the user’s schedule information; Right: Additional information the user should enter for optimal search results

Left: message indicating that the text message was sent successfully; Middle: settings page that user can alter; Right: privacy settings that user can change to make app access less or more of the information they inputted

Left: message indicating that the text message was sent successfully; Middle: settings page that user can alter; Right: privacy settings that user can change to make app access less or more of the information they inputted

Left: screen allows user to choose a friend that they want to meet up with; Middle: default text message that is sent if user does not customize the screen; Right: option for user to customize the text message they send to friend/new person

Left: screen allows user to choose a friend that they want to meet up with; Middle: default text message that is sent if user does not customize the screen; Right: option for user to customize the text message they send to friend/new person

Left: user has the choice of what type of buddy he/she wants for the day; Middle: user has the choice of either meeting new people or meeting with their friends; Right: page that indicates what app is doing after the data has been inputted

Left: user has the choice of what type of buddy he/she wants for the day; Middle: user has the choice of either meeting new people or meeting with their friends; Right: page that indicates what app is doing after the data has been inputted

Left: screen that pops up as the device is syncing all user inputted information; Middle: screen that indicates that all the information has been saved successfully; Right: the home screen for the app with the main features

Left: screen that pops up as the device is syncing all user inputted information; Middle: screen that indicates that all the information has been saved successfully; Right: the home screen for the app with the main features


Rishita begins using my social app prototype!

Rishita begins using my social app prototype; she doesn’t immediately know what to do with the title page

Jean wants a lunch buddy so she selects that option

Jean wants a lunch buddy so she selects that option but does not find the appropriate default text message afterwards

Yolanda wants to meet new people so she selects the find new friends button

Yolanda wants to meet new people so she selects the find new friends button; the page is a little wordy so she spends some time on the page

Second Prototype

Left: the title page of the app; Middle: user must log into Blackboard so app has user's class information; Right: main features included in the app

Left: the title page of the app; Middle: user must log into Blackboard so app has user’s class information; Right: main features included in the app

Left: the screen that allows the user to look through the past conversations; Middle: allows user to engage in live conversation with other students in the classroom; Right: interaction screen that pops up as soon as class is scheduled to start

Left: the screen that allows the user to look through the past conversations; Middle: allows user to engage in live conversation with other students in the classroom; Right: interaction screen that pops up as soon as class is scheduled to start

Left: asks user to put in the days and hours that the user is most available to work on problem sets; Middle: app lists all the different students that have similar preferences; Right: using information from Blackboard, the app relays some of the student's relevant contact information

Left: asks user to put in the days and hours that the user is most available to work on problem sets; Middle: app lists all the different students that have similar preferences; Right: using information from Blackboard, the app relays some of the student’s relevant contact information


I chose to test my buddy system social app with three different users. Every user testing offered some new insight into how I could change the interface for the app. When Rishita tested the application, she would struggle whenever she decided that she wanted to return to the home page and edit the information that she already entered. I realized the importance of making each stage of the app connect to the rest of the screens; this type of setup would allow for a lot more flexibility in accessing old information. Finally, she would often select options that I realized did not need additional pages in the application and in some cases, I had redundant pages (like asking the user their mode of transportation twice). I realized the importance of having relevant information and avoiding redundancy. When Jean tested my interface, she was sitting down to test my prototype. I noticed that the app was actually pretty time consuming, and the process itself took around 1-2 minutes. With respect to the waiting time (10 minutes), 1-2 minutes was actually already pretty time-consuming. This made me wonder whether it was really necessary to add the features where the app would tell the user when something was successfully completed. Again, the idea of redundant information came up. Finally, when Yolanda tested the app, I realized the importance of order. For instance, the text message should be customizable as opposed to set as a default message. This made me start realizing that the order of succession of screens should be very rational and easy to intuitively follow. What I took away from the experience, is that watching users interface with the prototype was extremely useful in understanding the flaws of the app; it also helped me better understand what types of interfaces are more intuitive. If I were going to actually develop an app, I would definitely engage in this prototyping process first.