Assignment 2

Observations

I observed COS 333 and ECO 332 about five minutes before class started. In both
classes, my professors showed up early (earlier than I show up, presumably to
set up projectors, etc). In COS 333, Prof. Kernighan always arrives early and p
lays music. In both classes, ith less than a third of the class arrived, almost
no one talks to each other; rather, most people are on facebook/reddit/various
social media, checking email, doing homework, or texting. As more people arrived, some
students began to strike up conversation. It seems to be a fairly even
split between students doing work and entertaining themselves; however, there
were surprisingly few people talking with each other, especially among the earlier
students. These are large classes, and students tend to just interact with
those they already know.

  • Student 1 arrived early to ECO 332, generally arrives early to all classes. She finds someone she knows to talk with.
  • Student 2 arrived right before class started, checked email, and continued to check email through class. She usually checks email and/or facebook if she arrives early.
  • Student 3 arrived a bit late to class, due to having to walk across campus from a previous class.

Ideas

1. A shared music playlist that anyone in the class can add to.
2. Class-wide chatroom
3. Simple quiz questions to refresh students’ memories before class starts.
4. Course-relevant news (which both students and teachers can add to) with comments and ‘like’ capability
5. Q&A (about anything) with professor
6. Random seat assignments, get to know your new neighbors.
7. Site for collaborative doodling
8. Stalker app — provides facial recognition (to names) for students and teachers.
9. Location and time-specific weather (is it raining outsides? snowing?) with finer granularity than city, morning/afternoon/evening.
10. Course-related question/answer (anyone can ask, anyone can answer)
11. Selection of interesting current research in the subject area.
12. Group poll for planning meals/study breaks/etc (similar to generalized doodle pool)

Prototypes

I chose to prototype 1 and 4: 1 since I’ve been in a couple classes where the professor sets up early and plays music until class is to begin, and it’s had a good response; 4 since the content is course-relevant and interesting.

1: shared playlist

4: aggregation of course-relevant news, papers

User Testing

Testing with idea 1:

Insight

Overall, the interface was fairly intuitive — once they knew what the goal of the application was. It’s not entirely clear from the mock up that the application is for playing songs (as opposed to buying them, for example), or that it is a shared playlist. The immediate reaction seems to be to try to interact with the currently playing song or the songs in the playlist (as those take up the majority of the space of the app), which I hadn’t planned for. Once they got to the ‘add’ button, though, searching for a new song and adding it to the playlist seemed to be straightforward. There were concerns raised that given at most a 10 minute wait, such an application wouldn’t scale for classes with a large number of students, since the playlist could dwarf the wait time. I then suggested voting on the songs to order the playlist (which I hadn’t thought of previously), which was received favorably as a potential solution. Users liked the idea, were generally able to navigate through though the purpose of the application should be more clear, and provided some valuable insights to improve the application.

Friend Map App

Erica Portnoy (eportnoy) Assignment 2

1. A description of how you conducted your observation (who, where, when). Notes and insights from observations / contextual interviews.
I conducted my observations between 11:50am and 12pm in and near Frist 302, and between 1:20pm and 1:30pm on Monday, February 18 in Aaron Burr Hall. I observed students staying after lecture to ask the professor questions about logistics and content. Preceptors for a class were discussing ideas that they had during the lecture to bring up during this week’s precept. Community auditors left the lecture hall slowly, discussing plans for lunch and where they were parked. The professor mentioned that he had to go back to his office for a lunch meeting. One student without a class immediately after stayed in the lecture hall, checking his email. He mentioned that he was in fact finished with classes for the day. Outside of Frist, two students when questioned responded that they were not in fact heading to the same place, but had just come from the same class and were walking together for social purposes. Various students walking alone mentioned that they were currently desiring food or planning the rest of their day. One student was checking her email on a public computer. Many students waited on a long line to acquire coffee. Professors co-teaching a class arrived at the classroom early to prepare for the class. One student who had arrived early was doing reading for a class later in the week. Another student was sending emails. One student was eating food. One student observed me doing these observations, for her class in human-computer interface technology. Another student was actively concentrating on twiddling his thumbs. One student arrived out of breath while running into the classroom late.

2. Full list of ideas you brainstormed. Express your ideas as “headlines,” explaining the main concept in less than one line. For this brainstorm, you can work with as many people as you want (inside or outside the class). So their contribution is acknowledged, list their names. You have to complete the remaining steps individually.
Some ideas were inspired by conversations with Dillon Reisman, Valya Barboy, and Bonnie Eisenman.

  1. Healthy snack food stations or food trucks or other easily available food, with locations shown on a map
  2. Nearest free food plotted on a map
  3. After class finishes, automatically open a videoconference into the classroom accessible by students in the class, so that students who must rush off to their next class can still ask the professor questions
  4. A system that rearranges room locations after the enrollment period has ended, to decrease the time it takes to walk from one class to the next
  5. App that calculates and displays optimal route from class to class.
  6. A waterproof alarm or clock for inside the shower, so that you will not be late to class because you could not check the time
  7. An application that uses your friends’ schedules (available on ICE) to show you a map of their current and next locations, so you can meet up with them to walk from class to class
  8. App for coordinating meals with friends
  9. Collaborative music-playing devices embedded in seats in a lecture, with the center seats having a higher volume effect to encourage people to move into the middle
  10. For those professors who still require paper versions of assignments, place a printer inside every room and have an app to print to a certain room
  11. Allow students to print to printers without releasing the papers in person so they can pick it up while running past
  12. Lighted book gloves for reading on the long trek to the E-quad for a night lab.
  13. Electronic maps by the entrance to a building marking which stalls are in use in which bathrooms
  14. Social puppy locating app; tap to inform others of puppies around campus, look at a map to locate them while rushing to class
  15. An app that makes the phone make a sound in a phone call at a certain time so you know to end a phone call immediately (helpful for parent conversations)
  16. Collaborative playlists playing inside of lecture halls
  17. App that senses proximity to objects like a car’s backup sensor for when you’re reading while walking
  18. App that looks at distance to dining hall and crowded level based on prox swipes

3. One sentence each explaining why you chose the two ideas you did for prototyping.
3. I chose the professor videoconference based on observations of people annoyed that they couldn’t ask the professor something, based on observations of a lack of consistent ability to talk to the professor after class, and because it is screen-based and implementable.
7. I chose the friend schedule map app because it is feasible, useful, and based on the social interactions I observed and received interview information for students walking from class to class.

4. Photos & descriptions of your prototypes
This is the prototype for the professor videoconference. It is similar to a skype system, except that users’ classes are automatically added on the backend to allow them to enter a class’ video discussion. The user has a login screen, a class list screen, and taps a class’ name to enter the class’ video chat. If it is not available, the class will be dimmed out on the class list screen.

Class choice and video display screens.

This is the friend schedule map app. A user logs in and is shown a home screen. From this home screen, the user can logout or move to the map or add friend screens. On the add friend screen, the user can choose whether or not to show a friend on the map. Also, they can search for people by name or netid to add friends. On the map screen, the user is shown a color-coded list of friends.

Original prototype of the friend schedule map app.

Final prototype of the friend schedule map app.

5. Photos & descriptions and detailed notes from user testing

User 1: Valya Barboy
touched map on the x → created popup screen
“so they’re moving from here to here is what’s happening”
“it’s an app that lets you see where your friends are and where they’re going so if you want to meet up with them for a reason or something you can find them.”
“I’m assuming it’s bidirectional.”

Valya touches the gold x, a user action that I had not anticipated…

…so I improvised further information that appears in a modal dialog.

User 2: Silken Jones
both users tapped the gold x, then knew to touch outside to get rid of the modal dialogue
touch entire name to remove or add check
“tells you where your friends are going according to their schedule”
“you can add friends if you want.”
“almost expected a dashed line to show up between the from and to.”

Silken searched for and added a friend.

Silken adds her friend.

User 3: Mireille

“this is an app on a phone” “ohhh, ok!”
“is that like telling me like where they are?”
“so this is the only person that isn’t added, so I’ll add them – cool!”
I should have an are you sure you want to log out
“I don’t understand what it means by from and to”
<drew dotted lines connecting from and to>
seem to need to touch the x to figure it out
told her we’re in between classes
“how do they know?”
<added from ICE to add friends screen>
gasp of oh!!
“if you want to accidentally run into someone on the way to class, this is the app to do it with.”
“or if you wanted to avoid someone on the way to class.”

6. List of insights from testing

  • It is not immediately clear to users where the data is coming from. Indicating “from ICE” on the “Add friends” screen seemed to help people understand. An “about” or “how does this work” page might also be useful.
  • I should probably also add a popup to confirm logging out of the system.
  • I would definitely need to try out even more variations of the map screen, to indicate what I mean by “from” and “to.” I tried out connecting the from and to markers with a dotted line, but other variations may work even better.
  • When a person tapped one of the dots and was given more information about a friend (a feature that was added on the fly based on observed user interactions), they seemed to immediately understand what the dots meant.

Assignment 2

Part 1: Observing

In order to conduct my inquiry into the behavior of students before class, I performed a mix of passive observation – i.e., simply watching students before class, and noting the actions they performed and their apparent motivations – and active contextual inquiry; that is, interviewing students to try to get a sense for what it would be like to be in their shoes. By watching first, I was able to get a general sense for the general kinds of activities students seemed to perform most often. I then conducted three focused interviews, informed by the task-oriented knowledge I’d gained.

1. Interview: I conducted my first interview with a student whom I had observed playing a game on her iPhone. Talking to her, I learned that she was playing the popular game Temple Run, saying that she found it so addictive that she found herself playing it whenever she had a short break or waiting period conducive to playing a phone game. She told me that she had arrived early to ensure that she got a good seat for the lecture, but that otherwise she had no reason to be in the classroom before the start of lecture, and felt that she had nothing better to do than to play Temple Run. I let her get back to her game, and observed that she was quite disengaged from the activity going on around her (other students coming in, etc.)

Design Opportunity: Many, if not most, students, seek out entertainment while waiting before class. Often they do this in a solitary, non-academically-inclined way: playing videogames, browsing their favorite subreddits and microblogs, etc. Perhaps there’s a way to entertain students while bringing them back to the classroom, engaging them with each other and with the academic content of the course? It seems like a shame that the students – all of whom are bright and have a common knowledge of and interest in the course – don’t collaborate in a meaningful way to entertain themselves during this time. Entertainment value is key, though: students would resent being required to participate in an activity before class; and a boring, voluntary activity could never compete with Temple Run.

2. Interview:  I had observed my second “victim” reading what looked like a pdf of something on his MacBook. I asked him about the reading – it turned out it was course-reading for a completely unrelated class – and he mentioned that he often tries to read between classes, particularly when he gets behind on his work. However, whenever he tries to read before lectures he is much less productive than he could otherwise be, because the environment is so distracting. This, he mentioned, is a source of frustration for him; he wishes everyone would just be quiet, though he knows that’s not realistic.

Design Opportunity: Some students want to use the lecture hall as a space to study before class starts. However, with people coming, going, and talking amongst themselves, the lecture hall at this time is a busy, loud, distracting environment that is not conducive to productivity. Similar to interview 1, I wondered if the students could in some way be brought together to engage in something academic. Perhaps students would be willing to cooperate in some kind of collective studying or problem-solving process? This could turn the lecture hall from a studying-hostile to a studying-friendly environment, and might – again – help reinforce students’ understanding of the material. I asked the subject about this, and he stressed the importance of it being voluntary: students are busy enough just getting between classes, and would resent the extra burden.

3. Interview: My third and final subject appeared to be carrying out a rather extended conversation with a friend over text-messages. This conversation lasted for several minutes; for this reason, it seemed to me to be a distinct kind of activity from the aimless browsing or e-mail checking a student like Subject 1 might do instead of playing a game. This was, more than anything, a social interaction. When I spoke with him, he mentioned that he and his friend were continuing a conversation they’d had before. He said that it’s hard to resist the urge to continue these kinds of digital social interactions, even during class, though (as he acknowledged) this is rude toward the professor. For him, the urge was more about having a conversation – being continuously socially engaged – than about the particular person he was conversing with; he mentioned that he might have started a text-message-based conversation with a different friend if he weren’t already in one.

Design Opportunity: The students that do reach out and communicate with others, ironically, often do so in a way that isolates them from the others in the room, and from the in-person social opportunities present during the time before the start of lecture. Perhaps there is a way to harness this social drive – the urge for a conversation and real-time communication – in an academically productive way, that does not interfere with the room as a place to study as well.

From these three interviews, the problem (or, at least, potential problem) of isolation appeared to be a trend. Students appeared to value pursuing solitary activities – gaming, reading, or texting, in these cases – to engaging with others in the room. This seems like a waste; the group setting provides many untapped opportunities for fruitful (and, in some cases, academically valuable) interactions.


Part 2: Brainstorming

For this part, I collaborated with Clay Whetung ’13, Peter Grabowski ’13, and Andrew Callahan ’13. We came up with the following ideas:

  1. Interactive quiz show on lecture material beforehand, just for fun.
  2. Correct answers win prizes?
  3. Correct answers load funny pictures/memes/pictures of cute animals
  4. Soothing and/or energetic audio-video patterns to get you in the mood for lecture
  5. Survey about what you want to see in the lecture (or future lectures)
  6. Slideshow of interesting topics in news or inspirational videos
  7. Guided meditation
  8. Organized, guided back massages
  9. Summary of previous course content
  10. Physical art supplies, so the class can create a communal piece of art
  11. Digital doodle-board (similarly, to create a communal piece of art)
  12. Digital collaborative music that’s easy to make – like this.
  13. Parallelizable puzzles/challenges/problems for people to solve together
  14. Collaborative game for all to play
  15. Anonymously ask and vote on questions for the lecturer to answer
  16. Aggregate websites that people are looking at and show popular articles
  17. 10 minute lesson series (potentially related to course material, or not at all).

Part 3: Selecting my favorites

First, I chose Idea 14, above (course-related games students can play while they wait), since it can potentially satisfy the needs of Subject 1 (a well-designed game could provide an engaging, challenging distraction for those who want it) and Subject 2 (since the game could tie into the course material.)

Second, I picked Idea 15 – (a way for students to submit questions) because it seemed like a powerful, real-time way for students to communicate about and collaborate around the course material, making it potentially appealing to socially-oriented students such as Subject 3 and more academically-focused students like Subject 2.


4. Rapid Prototyping

1. GameClicker! (Idea 14)

Inspired by the iClickers given to students in some introductory science labs, I decided to give each user of the system a clicker-like device, but one optimized for gaming. It also has small seven-segment LED screens for displaying your score, as well as the entire class’s score for cooperative games. The buttons on the device are labeled “A”, “B”, “C”, and “D”, making the device usable as a convenient replacement for a traditional clicker as well (i.e., students submitting answers to multiple-choice questions on the board).

In addition to the clicker-controller, I also prototyped out an example game. It is a cooperative game that can be played by the entire class, using their clicker joysticks. The goal is to guide the person on the screen to the correct answer to the multiple-choice question shown, while avoiding enemies. The character moves according to the average of all the players’ inputs, making it a truly collaborative activity (and, to an extent, an exercise in group problem-solving!)

Here are some photos of this prototype (I used 3×5 index cards):

Allows students to play games and answer questions using a joystick and buttons. Roughly actual size; real device could probably be a bit smaller.

Allows students to play games and answer questions using a joystick and buttons. Roughly actual size; real device could probably be a bit smaller.

A game where the class works together to guide the character (smiley face) away from the bad guys (frowny faces) and towards the correct answer (n log(n)). Not actual size! This would be projected on the board for all students to see.

A game where the class works together to guide the character (smiley face) away from the bad guys (frowny faces) and towards the correct answer (n log(n)).
Not actual size! This would be projected on the board for all students to see.


2. Live Class Forum (Idea 15)

This product consists of two main parts – again, one that goes in the user’s hand (in this case, a smartphone app), and another that is projected onto the board. Live Class Forum enables a group of people gathered in a space to ask and answer questions in real time, with an emphasis on the in-person aspects of the situation. Used in a lecture hall before the start of lecture, it allows students to submit questions for everyone to view. Students can attempt to answer each other’s questions, as well as vote (up or down) on those that they think are the most interesting or important.

The professor also has access to this discussion, and can participate either by answering students’ questions directly within the system, or by designating some questions as “Professor’s Picks” that will be answered at the start of lecture. Having real-time access to the students’ inquiries can help professors tailor their classes toward what material the students are most interested in, and what material is most in need of review or re-explanation.

Here are some pictures of this prototype (again, I used 3×5 index cards):

(1) Main Screen
The screen that shows up when users first open the app – and also the screen that gets projected onto the board for everyone to see. Students using devices can scroll to see the questions others have asked, and the top reply for each question. The screen also shows each question’s upvotes and downvotes.
Clicking on a “+” or “-” upvotes or downvotes, respectively, the question or reply they are next to. Clicking on a question will focus the question (screen 2). Clicking a “reply” link will take the user to the compose-reply screen (screen 3). Finally, clicking “new question” will take the user to the compose-question screen (screen 4).

(2) Focusing on a Question
Students can scroll to see all the replies for their chosen question (not just the top one reply, as on the main screen). They can up-vote or down-vote the question and each of its replies, as well as writing a reply of their own by clicking a reply link (which will bring them to screen 3). Clicking the “All ?s” link returns the user to the main screen (screen 1).

 

(3) Compose a Reply On this screen, students can use an on-screen keyboard (not shown) to enter a reply to the question shown above. They can choose to post or post anonymously, which will add their reply to the thread with or without their name attached, and bring them back to the screen "focusing" on their original question (screen 2). Clicking "To Thread" at the top will also return to this "focus" screen, but without making a post. Clicking "All ?s" at the top returns users to screen 1.

(3) Compose a Reply
On this screen, students can use an on-screen keyboard (not shown) to enter a reply to the question shown above. They can choose to post or post anonymously, which will add their reply to the thread with or without their name attached, and bring them back to the screen “focusing” on their original question (screen 2). Clicking “To Thread” at the top will also return to this “focus” screen, but without making a post.
Clicking “All ?s” at the top returns users to screen 1.

Students on this page can enter a new question (using an onscreen keyboard, not shown). The page displays the user’s name. The user can click on “Post”, or “Post Anonymously”, to submit the question and return to the main screen (1). Users can also return to the main screen (without submitting) by clicking “All ?s” at the top.


5. Rapid Feedback

To get feedback, I chose to use the Live Class Forum because, of the two, it seemed like the better-defined idea, as well as the idea more easily captured by paper prototypes and Wizard-of-Oz style simulation.

1. Bonnie Eisenman ’14

This was my first test, so it was a little rough around the edges. Bonnie’s main suggestion for improvement was to make better use of the mobile UI libraries and “look-and-feel” that Android, iOS, and similar provide (for instance, overlays that slide on top of the main window for the compose screens), because this would make the application look more polished and behave in a way mobile users expect. She also pointed out that the main screen was somewhat cluttered, and that it wasn’t especially clear which regions were clickable (for instance, tapping on a question in the main screen takes you to a different screen; tapping on a question on the “focused question” screen does nothing).

Some photos:

Testing with BO

Testing “Create a Reply” with Bonnie

Testing

Testing the main screen -> create a reply workflow with Bonnie

2. Max Botstein ’14

Max had no issues with the interface itself – other than that it was a bit tight and cluttered, but not much more so than most mobile UIs that only have a small screen to work with. However, he pointed out that the question-and-answer format that this product sets up – in which the questions are factual in nature and have a clear “best” answer – tends to work better in “hard” scientific or quantitative classes than in the humanities or social sciences. As a history major, Max couldn’t picture any of the professors in his department using this product, though he does think it could work better in a department like COS. Like Bonnie and Valya, he was somewhat caught off guard by the lack of clear instructions, but figured out the gist of things pretty quickly.

Some photos:

Testing the reply screen with Max

 

Testing the focus screen -> reply workflow with Max

3. Valya Barboy ’15

Valya’s main comment was that the main screen was too confusing, and needed to be simplified – perhaps by removing or hiding the reply, up-vote, and down-vote buttons on the main screen, and leaving them on only the “focused” screen. She also was not convinced that students would use the product even if the UI were improved – she said that it seemed too unnatural and inorganic, and that inertia would draw students to doing whatever they normally do between classes, because there are seldom questions to be asked that are so compelling students will break out of their usual routines to write or vote on them.

Some photos:

Testing the “all threads” button from the “focused” screen with Valya

Wizard-of-Oz simulations can be challenging! Here I'm fumbling with the cards while testing on Valya

Wizard-of-Oz simulations can be challenging! Here I’m fumbling with the cards while testing on Valya

 


6. Insights/Conclusion

  • Even when you think you understand the potential user, you probably still don’t, especially if you’ve spent only a comparatively small amount of time getting to know them. I thought I was designing a product that would appeal to students interested in deepening their knowledge of the course material, but in the the appeal was not as strongly compelling as I had thought it would be.
  • When designing for a device or UI form factor that already exists (e.g., desktop, mobile, facebook app, …), be aware of the UI conventions that exist and follow them. A source of confusion for the users I tested on was the fact that my product differed from how typical mobile applications work, in terms of transitions between screens, title bars, and text inputs.
  • Make extra sure you’re not making implicit assumptions about your user. Two of the lectures I went to to observe (as well as most of the lectures I attend in my day-to-day life) were COS lectures; as a result, my thinking about what a typical Princeton lecture looks like was excessively influenced by what a typical Princeton COS lecture looks like. This caused me to make unconscious assumptions about who I was designing for, and I ended up designing a product that might not find many uses outside of COS classrooms.
  • It’s impossible to avoid having a learning curve for your product, but it’s important to understand why the curve exists in your particular case. Simply giving my prototype to the users to experiment with without any explanation was immensely helpful – it was a form of brutal honesty that revealed many of the un-intuitive features of my UI, such as the clutter on the main screen making it difficult to navigate, and the ambiguity in the presentation of question-and-response threads (such as only the top answer for each question being presented on the main page.)

In conclusion, if I were to continue to iterate on and revise this product, I would first reduce the clutter on the main screen; in particular, I would remove the reply and upvote/downvote buttons, keeping them only on the “focused on a thread” screen. I would also retool this thread-focus screen, to make it more clear exactly how it fits into the main screen’s big-picture view of the questions (perhaps by using overlays or other fancy mobile UI elements). I might also consider more fundamental redesigns of the product’s functionality and interface – after all, this is still the early stage of the design process where many different ideas can be explored without too much cost.

This was definitely a humbling experience. I knew that getting UIs right was difficult, but I wasn’t expecting to my interface to have so many flaws, in spite of the fact that I tried to take my users’ specific needs and situation into account. This assignment really demonstrated to me the importance of prototyping, testing, iterating, and failing fast in UI design.

HCI A2

OBSERVATIONS

I conducted two sets of observations. The first was a preliminary test, to see how the prototypes would work and practice my observation/testing techniques. The test was conducted at Terrace in the evening with Olivia, a senior EEB major. I believed a senior would be most likely to understand the potential value of the system, after many years of classes. EEB was a good major to test with, as there’s a range of question types, from memorization based to conceptual and mathematical. Finally, I chose Terrace because it provided a more casual environment, allowing us to take the time we needed (especially for me to practice my technique) without any rush.

Here are the observations I made, along with direct quotes from Olivia:

DIRECT QUOTES

  • “I thought the interface was intuitive”
  • “Why does it have to be on a phone instead of a computer? why not make it either or, like you can access blackboard either on a computer or a phone?”
  • “Maybe you could link it with blackboard and have it send you an email update of how many points you have (3-4x/semester)”
  • “Make rewards more frequent — maybe once before midterm, once before final”
  • Can you have an interface where you can participate in it, but you won’t be scored for class. Can you save the questions for later, to help you study?
  • “I like the projector idea, more engaging”
  • “What about kids who don’t bring laptops or phones to class?”
  • “Strive to answer a certain number of questions, then base reward on percent correct with minimum number to answer in the first place. This would equalize it if people can’t make every class”
  • “Offer students a chance to opt-in/opt-out at beginning a year. Some people might not be able to show up on time (class right before is far away). “
  • “I like that it’s not extra credit for the class — more fair. $10 to Starbucks is good — everyone likes Starbucks”
  • “I like phone/laptop interface — a dedicated device would get stolen too fast”
Olivia uses one of the projector cards as a phone. Next time, I should make it more clear

Olivia uses one of the projector cards as a phone. Next time, I should make it more clear

Olivia is engaging with the  asked question

Olivia is engaging with the asked question

OBSERVATIONS:

  • Immediately knew how to interact with phone/touch based interface. Big, easy to read buttons were good
  • Could accurately guess what each button would do on the screen. Having only few buttons made things simple
  • Tried to hold the “projector” cards as if they were a phone — next time, make it more clear that projector cards are up on the screen
  • Seemed to appreciate the idea, and recognize the potential for making better use of the time between classes

The second set of observations was with a group of Freshman before a NEU 259 lecture (11 am) in Robertson Auditorium. I tried to find a group with a wide variety of intended majors, including EEB, COS, and ENG, to see how the system would be perceived by people with different academic interests. I was glad to also be able to find another EEB major, to be able to compare their responses with Olivia’s. I met with Katie, Allister, and Amanda. The practice observation session paid off, as I was able to move through the real observation quickly, making the best use of the limited amount of time between classes. Again, I recorded direct quotes as well as my own observations

DIRECT QUOTES

  • “I liked the idea of it being a question that I might be able to get a better question to in lecture”
  • “Only having 15 seconds might make me more stressed than it would be helpful”
  • “I’m ambivalent about being compared to other people in the class — that could make me feel really stupid, or that other people are really smart, or that I’m ahead of other people because they haven’t been playing — I just don’t know”
  • “I don’t like it as a mandatory thing that I have to do”
  • “I suppose it’s alright that it’s competitive, because it might be a good metric of how I’m doing in the class”
  • “Definitely have score anonymous”
  • “What about extra credit — but some people can’t be here early, so maybe not?”
  • “Ten seconds is too little time”

OBSERVATIONS

  • Was visibly stressed when she couldn’t figure out the question in 10 seconds (even though the clock wasn’t actually counting down)
  • Younger students were more focused on their score being anonymous and whether they might get class credit. Older student (Olivia) was more focused on sharing feedback with professor, to get more out of lecture
  • Seemed to be still rooted in high school class mentality — asked why didn’t we just ask the professor, instead of designing a big interface for it.
  • Enjoyed the competitive nature of it — had “mock” competition of how quickly they could respond. Perhaps it could be good to play up the fun/competitive side of it?
Amanda immediately understand how to interact with the device

Amanda immediately understand how to interact with the device

Amanda and Allister begin to become a little competitive

Amanda and Allister begin to become a little competitive

Katie is visibly stressed by the time limit

Katie is visibly stressed by the time limit

Katie immediately understands how to use the prototype

Katie immediately understands how to use the prototype

Katie considers the question

Katie considers the question

BRAINSTORMING — worked with Clay Whetung, Andrew Callahan, Mario Alvarez

  1. Soothing and/or energetic patterns to get you in the mood for lecture
  2. Collaborative game for all to play
  3. Survey about what you want to see in the lecture
  4. Slideshow of interesting topics in news or inspirational videos related to the topic of the class (presumably curated by the professor).
  5. Guided meditation to relax people before class
  6. Organized back massages. Odd rows give massages to even rows, then the reverse.
  7. Summary of previous content in lecture
  8. Physical art supplies, and the class together creates a communal piece of art
  9. Digital doodle-board — let people draw together
  10. Digital collaborative music – something like .http://www.earslap.com/projectslab/otomata
  11. Parallelizable puzzles/challenges/problems for people to solve together. Multiple choice or free-form, and people in class vote for answer. Precepts compete against each other
  12. Anonymously ask questions for the lecturer to answer, Piazza-style. Vote on questions you especially want answered
  13. Aggregate websites that people are looking at (voluntarily, of course). Like this, you can see what everyone’s looking at and potentially provoke discussion
  14. 10 minute lesson series (potentially related to course material, or not at all). Could be student taught or prof taught. Consider 10 minute html, 10 minute css, 10 minute knitting, etc
  15. Performance of lecture relevant material — consider a music course, where many students are in the orchestra. One (or more) of the students could play a piece before class that would then be discussed in lecture
  16. Interactive quiz show on lecture material beforehand. Correct answers win extra fun
    1. Correct answers win starbucks gift card
    2. Correct answers load kidbleach.com (cute pictures)

TOP TWO IDEAS

  1. Interactive quiz show on lecture material beforehand. Correct answers win extra fun
    1. Potentially win Starbucks gift card — good to solve sleep problem
    2. Potentially load kidbleach.com (cute animals) — who doesn’t love cats
    3. iPhone/laptop based — people are already engaging extensively with their iPhones/laptop
    4. Allows people to review their notes on previous lectures in a guided and fun fashion
    5. Gives feedback to professor on what needs to be covered
  2. Anonymously ask questions for the lecturer to answer, Piazza-style. Vote on questions you especially want answered
    1. Professors will like it — allows them to focus their lecture
    2. iPhone/laptop based — people are already engaging extensively with their iPhones/laptop
    3. Allows people to ask a question that comes up while they’re reviewing their notes

1 — This idea incentivizes people to come to class early, but doesn’t penalize those who can’t, and allows people to engage with their mobile devices while reviewing their notes in a fun way.

2 — This idea is less fun but still provides valuable feedback to the professor and allows people to use their laptops/mobile devices, which are likely already ready to go

PROTOTYPES

FIRST IDEA

Simple home screen. Users can pick to either ask a question or browse trending questions

Simple home screen. Users can pick to either ask a question or browse trending questions

On this screen, users can ask a question. Similar questions are displayed below (stack overflow style) to cut down on redundant questions

On this screen, users can ask a question. Similar questions are displayed below (stack overflow style) to cut down on redundant questions

The user's submission is acknowledged, and they're given the option of what to do next

The user’s submission is acknowledged, and they’re given the option of what to do next

Here, the user can browse existing questions and answers, as well as upvote or downvote them

Here, the user can browse existing questions and answers, as well as upvote or downvote them

The professor's customized display, which shows the top questions for the upcoming lecture

The professor’s customized display, which shows the top questions for the upcoming lecture

 

SECOND IDEA

Users can log in using their NetID

Users can log in using their NetID

Users see this image on both the projector and their phone in between rounds

Users see this image on both the projector and their phone in between rounds

The question is displayed on both the phone and the projector, with a real time count down clock

The question is displayed on both the phone and the projector, with a real time count down clock

After students submit an answer, they can see if they were correct, and have an opportunity to flag the question as "silly" or "confusing", for later followup with the professor

After students submit an answer, they can see if they were correct, and have an opportunity to flag the question as “silly” or “confusing”, for later followup with the professor

Users see this image on both the projector and their phone in between rounds

Users see this image on both the projector and their phone in between rounds

At the end of the semester, users can see how they did overall. The top score is announced, and wins a prize

At the end of the semester, users can see how they did overall. The top score is announced, and wins a prize

 

INSIGHTS

  • Users of all ages and majors seemed to like the mobile interface, and immediately understood how to use it. Olivia made the good point that many people don’t have smartphones, and a laptop based interface might also be appreciated
  • Competition is fun. People like to compete with each other, and enjoy it. This should be leveraged in future iterations
  • Privacy matters, even if situations where you think it shouldn’t. People were worried about other people seeing their score, and either being jealous of a high score, or thinking badly of them for a low score
  • Age matters, even on a small scale (4 years). Freshman were more worried about privacy and their score, while seniors were focused on how it could improve lecture quality. Freshmen tended to become more stressed about the time, while seniors didn’t care
  • Age can influence privacy concerns. The freshman I spoke with were significantly more focused on privacy concerns than the seniors.
  • Having a small number of big, clearly labelled buttons was very well received. No one had any trouble predicting what the buttons would do, or predicting how a given task would be accomplished. No screens were ambiguous

 

 

 

 

 

 

Assignment 2 – Prerna Ramachandra

To conduct my observations, I spent a lot of time between class observing what people did. Initially, I chose to observe and talk to people in the same classes as me but who I did not know very well – Byrd Pinkerton and Kirsten Parratt in ENG 339: Jane Austen in Context; Patience Haggin and Saahil Madge in HIS 310: Imagined Languages; Stephanie He and Sebastian Gold in COS 340: Reasoning About Computation.

I found that when people had time between class, they usually answered emails, checked the day’s lunch menu or read through the notes from the previous lecture for that class to refresh their memories.

I also interviewed acquaintances and friends to ask them what they did between classes – Izzy Kasdin, Alex Kasdin, Dillon Reisman, Erica Portnoy, Bonnie Eisenman, Mengyi Xu, Michelle Yakubisin, Ballard Metcalfe, James Bedell and Alexander Patton.

For people who were running between classes in 10 minutes, their biggest concern was being late and missing the beginning of lecture which sometimes lead them to miss important assignment information or even the base of the lecture which was hard to catch up on.

People also complained about not being able to find resources such as printers, water fountains, bathrooms, etc. in time when they had class in an unfamiliar building.

Many people merely spent time playing games on their computers or relaxing between class and said it would be fun to have more recreational games before class to rejuvenate.

I came up with the following list of ideas based on the observations I made and conversations I had.

List of Ideas

  1. Legos in the classroom – fun way to keep people engaged before class (add sensors to prevent students from taking them)
  2. Magazines and newspapers in or right outside the classrooms
  3. OnMyWay: Wirelessly transcribing the first 10 minutes of lecture to your phones so you don’t miss the beginning if you’re running late
  4. Outline Transmitter: Transmitting lecture outlines to the phones before class so students can skim through them
  5. Campus wide puzzle challenge: Form teams within your class to solve a semester-wide puzzle challenge in which clues are scattered around the classroom right before the class starts
  6. Video monitoring for students who have experiments running in the lab – video feed sent live to phones so they can keep track right until class begins
  7. FindIt: Compilation of locations of students necessities such as printers, water fountains, bathrooms and prox hotspots so students know where to look before class
  8. Email Filter: App which filters only the most important emails which must be answered urgently so students don’t have to sift through tons of emails finding the ones which must be answered before class
  9. Mood-based music filtering: App which selects the right music for you as you walk to class depending on your mood – happy, sad, want to workout/ race walk, etc.
  10. QuickSnack: Snack trucks or coffee bars right outside or near classroom for a quick hunger fix or coffee boost
  11. Audio feed summary of the previous lecture for the class you can listen to before the next one so it is fresh in your mind
  12. MoodCheck : App which posts your mood – happy, sad, stressed, etc. so your friends can see it; you can check friends’ moods and offer to chat, hang out, small gift to cheer them up if they’re sad
  13. LunchMenu: App which consolidates menus from various dining halls/ eating clubs for the day’s lunch so you can pick where to eat when walking from class to class
  14. Day Progress Report: List of tasks you need to finish for the day, and how you’re keeping up, i.e. personalized day tracker to check before class.
  15. Daily Calorie Intake: What did you eat (pick from d-hall menus), how many calories, track physical activity including walking, etc
  16. TechTracker: An app which lets students who are the first to enter the class send a complaint regarding technology in classrooms which does not function.
  17. Sustainability Check: An app which informs students of all the empty classrooms in which lights are on giving students near those classes to walk in and turn them off.
  18. Best Paths: An app which optimizes your path to class and gives you the best routes by foot and by bike (taking rain/ cold weather into account).

The two ideas I chose to prototype are:

1. OnMyWay: Wirelessly transcribing the first 10 minutes of lecture to your phones so you don’t miss the beginning if you’re running late

I chose this idea because many students, especially freshmen engineers have back to back classes and invariably miss the first five or so minutes of lecture and find it hard to catch up. They also miss important homework information which professors talk about in the beginning of lecture. An app which relays this information to them while they are walking would be very useful with a simple UI.

2. FindIt: Compilation of locations of students necessities such as printers, water fountains, bathrooms and prox hotspots so students know where to look before class

I feel this is an important problem because students generally use time between classes for tasks such as filling their water bottles, printing things for class, going to the bathroom, etc. but don’t find the amenities required because of being in an unfamiliar building or part of the building. An app which helps them find these things is simple to design and very useful.

Prototypes

1. On My Way!

omw1

1. Opening screen which lets you select the class for which you are late

omw2

2. Second screen which displays the time and relays a message saying it is waiting for the class to begin before transcripting

omw3

3. Transcript of lecture begins when lecture starts, can be viewed while walking to class

omw4

4. Transcript stops 10 minutes after lecture begins – enough time to get to class

2. FindIt!

f1

1. Opening screen – option to select building manually or use GPS location

f2

Optional second screen (only if user chooses to select building manually) to choose from list of buildings

f3

3. Screen to choose item being searched for

f4

4. Screen specifying floor location of said item in the building

f5

5. Tap on each floor for further info about location or look in a nearby building

User Testing

I decided to user test the prototype for Find It!

I decided that students who test my prototype would not be Computer Science students and those interested in interface design since I believe they would not give me a completely accurate picture of the regular user. Emily Wibberley, Izzy Kasdin and Temple Douglas tested my prototype, and here are the pictures from user testing:

Emily Wibberley

IMG_1880

1. Decides she does not want to use the GPS

IMG_1881

2. Trying to figure out how the building selector works

IMG_1882

3. Selects the Friend Center!

IMG_1883

4. Looking for a water fountain

Izzy Kasdin

IMG_1884

1. Decides not to use the GPS

IMG_1885

2. In the Friend Center

IMG_1887

3. Looking for a water fountain

IMG_1888

4. Found the location! But…how to get more info?

Temple Douglas

IMG_1889

1. Decides to use the GPS

IMG_1890

2. App finds that she is in the Friend Center. Chooses to find a water fountain

IMG_1891

3. Gives the floor location…but how to get more info?

IMG_1893

4. Decides to find a fountain in a nearby building instead

Observations and Conclusions from User Testing

The initial screens seemed to be a simple enough interface for testers to figure out, especially when they manually selected the building. However, those who used a GPS locator said it would be nice to have a confirmation screen asking them if they were actually in the location it found out, which would be useful if they were outside or near a certain building.

I also observed that none of the users tried to find more information about the location after the floor locations had been displayed. They were tired of clicking through too many screens, and hence it taught me a lot about simplifying the interface so necessary information is quickly and clearly displayed. Thus, I feel having the detailed location displayed next to the floor location is a better interface than waiting for the users to tap on the floor locations for more info.

One of the users also said that having a ‘nearby buildings’ options might only be necessary if the required item is not available in the building the user is in, or is hard to find (eg. the bathrooms in McCosh are extremely hard to locate). This lessens the amount of text on the screen and prevents too much confusion.

Overall, I got positive feedback about the usefulness of the app, and users testing the prototype said they would definitely use it. The functionality is simple and some minor tweaks in UI will improve usability. I am happy with the reception of the app and gained some valuable insights from user testing.

 

Assignment 2

1. Observations.

I conducted observations on Tuesday in the CS building room 102 at 9:50 am, Friday in the Friend Center Lobby at 10:50 am, and Monday at 1:20pm in Frist.

At Tuesday in CS 102, I observed people in Programming Languages before class started. I spoke with others too to ask about what they were doing. My observations were:

  • Most people were quiet. On interview, the most likely reasons for this were because:
    • “It’s early.”
    • Students do not know each other, in part due to the gradt/undergrad split of the class.
  • Many students were on their laptops checking email, performing other small tasks, or looking at our electronic textbook.
  • Many students were either texting, sending email, or reading the news on their phones

At Friday in the Friend Center Lobby, I observed traffic as it passed through and interviewed people about what they were doing at that time. Popular activities included:

  • Standing and talking with friends
  • Printing documents in the Friend center library
  • Using the bathroom
  • Checking texts/emails on phone

I also spoke with students and found that most had checked their phone for email/text in the last 10 minutes.

At Monday in the Frist, I observed traffic and interviewed people about what they were doing. I also walked around the building to see observe different parts. Common activities included:

  • Getting late meal (long line)
  • Picking up a package from the package center (long line)
  • Checking mailbox or looking up mailbox combination on computer.
  • Staff was cleaning full garbage cans
  • Checking texts/emails on phone
  • Working at tables upstairs

The outside of Frist was also crowded with pedestrian traffic.

From interviewing people and observing these 3 situations, I think that my interface should probably focus on the student who is in a hurry to do something between class. It would likewise make sense for it to be a web, desktop, or mobile application, as most students use a computer or phone in the 10 minutes between class. Speaking to students, I found that many are “trying to get little things done,” or trying “not to be late for class.” Students felt like time between class was “short” so an application that helped people streamline their activities during this time would make sense.

2. Brainstormed Ideas:

  1. An attendance taking application using prox scanning to check students into a class before that class starts. Takes advantage of earliness so class time can be more productive.
  2. Flashcard application for teachers to learn students names.
  3. System of lights (turn signals, brakes, etc) for bikes to help bike users better communicate with pedestrians in crowded areas. Implement interface on handle bars of bike.
  4. Lights that notify people on bikes/skateboards when there are people around a blind corner (like near the pillars in front of Frist, or the corner of the Dinky waiting area building)
  5. Bike interface that lets you know how fast to go to get to class on time.
  6. Map services application mounted onto bike/skateboard to create a route to location that avoids stairs.
  7. Map services application to map routes like quickest, most scenic, least crowded, most squirrels, etc.. between buildings
  8. Touch screen interface in lobby of building for indoor map and room availability.
  9. Mobile application to quickly order “take out” from Frist or dining halls to save time if trying to grab food between class.
  10. Touch screen interface to quickly look up Frist mailbox lock combination.
  11. Mobile application to check printer status and release jobs from print queue remotely to save time printing before class.
  12. Resource finder application to find objects like printers, pencil sharpeners, staplers that actually work
  13. System for Frist late meal workers to montior traffic in order to have more checkout stations during peak hours (which often coincide with the 10 mins between classes)
  14. Trash can sensors for facilities workers to respond to full trash cans at peak times between classes.
  15. Course oriented chat interface to allow classmates ask other classmates course related questions (what’s today’s lecture about?, where did we leave off last time?…)
  16. Platform for “highlight video” of previous lecture.
  17. Web interface for instructors to post course-related articles or cool things to look at before class.
  18. Mobile based course related quiz game before class that gives you feedback on how well you know the material in that class relative to your classmates.
  19. Locations based interface to help introduce you to people in your lecture before with similar interests
  20. To-do list interface that automatically opens applications that are needed to complete tasks (ex. “email Joe” on todo list would automatically open a new gmail message w/ Joe as the recpient). Application would proceed down list sequentially.
  21. Applications that learns user’s computer behavior to suggest tasks.
  22. Mobile device plays music based on mood/weather
  23. Change music selections with interface on bike handle bars or by hitting a large button in your jacket.
  24. Application to allow for collaborative selecting of room temperature / lighting to be set before class starts.
  25. Application that generates ideas of things to do at night so students can make plans

Two Favorites:
Item 11, an application to check printer status and release items from print cluster remotely

Item 20, a to-do list that automatically opens applications that are needed to complete task.


3. Reasons for selecting each prototype:

-This is both a feasible and useful app that solves two persistent problems: Princeton students often are in a rush to print before class and printers are often unreliable.

– This app would be a straightforward way to help streamline the process of completing the “busy work” Princeton students often do between classes.

4. Photos and descriptions of prototypes:

Printer App

The Printer App allows students to remotely release print jobs when they are nearby a printer. This saves them time both finding a worker printer as well as printing their documents. This applications seems like it would be best implemented as a mobile app.

 The main page of the remote printing app has 4 buttons. A “My Queue” button to view all of the items currently in your print queue, a “Printer List” button to view all of the printers nearby, listed in order of closest to farthest, a “Check Map” button to view printers in a map view, and “Print!” button that will prompt you to select a document to print and a printer to print to.

The Main Page

Three landing pages that follow the main page

From the main page, the buttons for “My Queue”, “Printer List,” and “Check Map” correspond to one of the three drawings in the column on the right. From the “My Queue” page, users can select documents to print from their queue and delete documents from their queue. From either the list or map view of the printers, users can select which printers they want to print from. After the user selects a document in the “My Queue” page, the user is directed to the “Select Printer” page. After the user selects a printer from the “Printer List” or “Map” pages, the user is directed to the “Select Document” page.

A dialogue appears if the user clicks on a printer in the map

If a user clicks on a printer in the map, the user is prompted to print from that printer.

 

A user can select documents or printers from these menus.

Below are the two menus from which the users can select a printer or a document. The user reaches these pages after selecting “Print!” on the home page or by landing here after viewing the “My Queue,” “Printer List,” or “Map” page and selecting the options described above.

The success menu.

A display appears to notify the user that their document is successfully printing.


The user has various ways of getting from the main page to the “Printing” page depending on how they interact with the intermediate menus.

A overview of the application

To-Do List App

The main feature of the To-Do list app is that helps students quickly navigate through the tasks that they typically complete between classes. When students add a task to the to-do list, in addition to the title, they must also give the name of the application needed to complete that task. For example, sending an email might use Mail or Thunderbird, while editing a document might use Microsoft Word. After selecting an application, the user must select the file or url of the resource they wish to modify. For example, if the task involved editing a document in Microsoft Word, he would enter the file path of the document. After creating a to-do list, the user presses “Start!” When the user presses start, the program traverses their todo list, automatically opening the necesarry resources. The todo list application maintains a small dialogue box in the corner of the user’s screen so that the user can move between tasks and can navigate back to the main page.

The main page of the todo list app consists of a list of the users tasks, with the options to add an entry or to start their to do list.

The main page

When users click the “New Entry” button, the are prompted with a form with which they fill in information about their task. The information requested is the title of the task, the application need to complete the task, and the file or url where the task can be accessed. Ideally the file/url entry section would be updated once the application section is filled in so the to-do list knows which resource it needs.

A form to create a new task

To choose an application, the user selects from a drop down menu. To choose a file/url, the user either enters a url directly or can browse their file system to find the correct address.

A drop down menu appears to allow the user to select an application.
A file system browser allows the user to select a file.

From the main menu, the user also has the option to edit an entry in the to do list. Likewise, certain local applications, like Mail, may not need a file/url inorder to start up.

This menu allows a user to edit an entry in the task list

Tasks Read: “Email Joe,” “Check Bank Account,” “Fill Out Survey,” “Proof Read HW”

When the user presses start, the correct application programs start. For example, the first drawing shows a new email window so the user can email Joe. The to-do list displays a small dialog box in the corner of the screen to remind the user that it is running and to allow the user to move to the next item in the list. Pressing the “next” button, for example, could automatically open Microsoft Word with the user’s homework so that they can edit it.

A view of the todo list application while the user is completing tasks.

5. Photos, descriptions, and detailed notes from user testing:

Test Structure: The structure of the test was that I presented the paper prototype to users telling them to interact with the paper as if it were a computer application. I tried to let them interact with it on their own at first, but offered help if help was needed. I started by giving them a card with a blank todo list queue. They then had to add tasks to the todo list and click “Start!” once tasks were added. I say they “had” to do this because this is really the only useful way to use the application.

1) Test 1

-Sarah clicking the “Application” button in the “New Entry” form.
-One common mistake was clicking “Start!” When the todo list was empty

For my first test, I demoed the application to Sarah. During her demo, the first thing she did was hit the “Start!” button. I then told her the the “Start!” button does nothing because there is nothing in her todo list queue. She then clicked the “New Entry” button. This brought up the new entry form. She then entered the title of the task, the application, and file path. After entering tasks, she was directed back to the todo list queue. She then clicked the “Start!” button. She was slightly confused when the email interface popped up, but she completed her first task, and clicked the “next” button. The second task then appeared and she clicked the “next” button. The simulation ended.

2) Test 2

-Mike attempting to start the to do list by clicking an individual task

For my second test, I demoed the application to Mike. Like Sarah, the first thing he did was hit the “Start!” button. I also told him that the “Start!” button does nothing because there is nothing in his todo list queue. After questioning the purpose of the application, he then clicked the “New Entry” button. This brought up the new entry form. He entered the title of the task and then entered the application. He asked about the “File/Url” field, for he was a bit confused as to why he would need to enter this information for a todo list.  He then entered the file path. After adding tasks to his queue, he was directed to the todo list queue. Instead of clicking “Start!” though, he clicked on an individual task, in an attempt to complete that task. Clicking an individual task, however,  does nothing. He then clicked the “Start!” button. His first task appeared, he completed the task, and he clicked the “next” button. The second task then appeared, he completed the task and he clicked the “next” button. The simulation ended.

At the end of the demo when I spoke with Mike he said he didn’t think he would personally use this application. He said he would “just do the task” rather than take time to add it to a list of small things to do later.

Test 3)

Kyle looking over the main page of the todo list app

For my third test, I demoed the application to Kyle. Like Mike and Sarah, the first thing he did was hit the “Start!” button. I also told him that the “Start!” button does nothing because there is nothing in his todo list queue. He then clicked the “New Entry” button which brought up the new entry form. He entered the title of the task, the application, and file path/URL. Like Mike, he also asked why the File/URL is needed. After adding tasks to his queue, he was directed to the todo list queue. He then clicked the “Start!” button. Like Sarah, he wasn’t exactly sure why the email interface appeared but after some direction, he completed the task. He, however, but did not immediately find the “next” button. I pointed out the “next” button and he clicked it. The second task then appeared, he completed the task and he clicked the “next” button. The simulation ended.

6. List of insights from testing.

  1. All 3 test users clicked the “Start!” button while the queue was empty
    1. My first thought to solve this problem is to eliminate the “Start!” button from the main page when the todo list is empty. I think this could work, although it’s possible that the word “Start!” could be confusing even when there are items in the list.
    2. A second solution would be to change the word “Start!” to “Execute To Do List”, or “Do!” or something more descriptive and straightforward than “Start!”.
  2. Users questioned why a file or url was necessary for a todo list
    1. To solve this problem I think it would be helpful the user to have more background information on the application. The user is supposed to go into this kind of test blind, so it might be helpful to add a more descriptive welcome page to the application to introduce its basic concept.
  3. Users were surprised when the page changed from the todo list queue to email when they pressed “Start!”
    1. Once again, I think it would be helpful for users to have more background of the purpose of the application. One idea would be to change the page sequence and make a “loading screen” appear when the user presses “Start!” that says something like “Now starting your todo list…opening HW.doc with Microsoft Word…”
    2. I think changing the word “Start!” to something more descriptive would be helpful to with problem as well.
  4. Users had trouble finding the “next” button or needed me to point out the small todo list dialogue box in the corner.
    1. I think I could make the dialogue box more prominent so that users are aware of its presence and can use the “next” button to go to the next task.
    2. After the user clicks “Start!” and the proposed loading screen appears, I could have the message in the loading screen make note of the fact that a dialogue box will appear.
  5. One user clicked on an individual task in order to attempt to complete that task
    1. I think that I should make clicking individual tasks have some functionality. I think it makes sense that users should be able to sort tasks in the todo list by dragging them.
  6. Users questioned the purpose of the application
    1. Though the application was somewhat confusing on it’s own, when I described the application to users myself, they saw its use. I think I should find a way to work my description of the app into the interface itself. Maybe some progress bar or instruction set like “Add Entries -> Sort Entries -> Execute List!” on the main page would be helpful.
    2. I think the fact that the application was made of paper was unusual for my users. I think this may have made the app seem more strange.

In all, I think my app was successful in that users were able to navigate through it reasonably quickly and understood its purpose with a little help from me. The biggest problem though is that it leaves much for explanation. I think the main goal of the revisions above are mainly to make the application and interface explain itself more clearly through better wording, button options, and page sequences.

Assignment 2 (Michael Newman)

Name: Michael Newman (menewman@)

My observations:
Every Tuesday and Thursday, I have two consecutive classes in the same room (Aaron Burr 219), as well as two consecutive classes in the CS Building (105 and 104). Consequently, I was able to observe the behavior of students/faculty between classes for the full 10-minute changing period twice a day on Tues/Thurs for the last couple of weeks. I observed that my peers tend to spend the extra time going to the water fountain and/or the bathroom, pulling out preparatory materials for class (laptops, books, printed notes, notebooks), conversing with the professor (particularly after class, not before), conversing with each other (occasionally, but not always, about course-related material), and using their phones – to text, call, browse the web, play games, or listen to music. Depending on the time of day (and the location), students may acquire/consume food or beverages – for example, I’ve seen COS students run to the tea room for coffee or to the vending machines for soda/snacks. This seems more likely to happen in the afternoon than in the morning. Professors, on the other hand, are less likely to spend the time socializing; in general they seem to roll into class with just enough time to set up their slides/projector and begin the lecture. After lecture, they tend to converse with students, pack up, and disappear. In general, both students and professors seem to spend the in-between time performing some combination of social interaction (in-person or via phone), personal refreshment (e.g., eating, going to the bathroom), and/or preparation for the class – not including, of course, travel time between classes.

Brainstormed ideas:
1. Online/mobile app that lets students anonymously rate the lecture they just attended, and/or provide direct feedback to the professor.
2. Mobile app that lets you know if your friends are planning to skip class; you can either coordinate so that someone always goes, or skip class if they are also skipping.
3. Mobile app that finds location on campus using GPS/Wifi, directs to nearest bathroom/food/water.
4. Mobile app that calculates distance to next class and estimates how long it will take you to get there.
5. Web app that lets you anonymously chat with those in the same lecture as you; you can ask questions and get immediate feedback without feeling embarrassed or put on the spot.
6. Kinect-based “stretching station” where students who have been sitting down too long can work out their stiffness with the help of a stretching game/program.
7. Mobile/web app where professor can upload class notes and student can send them all to All_Clusters with a single click (also provides printer location information).
8. Web app where students can anonymously gossip about their classmates (sorted by class, lecture time for convenience) and read gossip about themselvers.
9. Mobile app that uses current location data and time/location of next class to determine if it’s feasible to go get coffee before the next class starts.
10. Mobile app that plays soothing instrumental music and shows calming visuals (e.g., ocean waves) to help students relax between classes.
11. Web/mobile app that lets professors know what equipment/connections they should be prepared for in a given lecture hall (e.g., VGA adaptor only, HDMI connection, etc.)
12. Web/mobile app that provides a calendar of assignment due dates and exams; students can check to see if they have something to turn in for their next class.
13. Web/mobile app where professors can upload short outlines/background info on the upcoming lecture, which students can check on their phones before class.
14. “Assassins” mobile app: participating students can receive the names of targets to “assassinate” (with water pistols) between classes, and the last student still “alive” receives a prize.
15. Web/mobile app where student can log how much time they’ve spent outside each day; app reminds them to go outside between classes so they can get some sunlight and vitamin D.

The ideas I chose to prototype:
Online/mobile app that lets students anonymously rate the lecture they just attended, and/or provide direct feedback to the professor.
I like this one because it lets the student ask questions or suggest improvements while the lecture is still fresh in his/her mind; the professor can then respond to issues s/he otherwise might not even have known about.

Mobile app that finds location on campus using GPS/Wifi, directs to nearest bathroom/food/water.
This is useful because students often use their short breaks relieving/refreshing themselves, but they have only 10 minutes to walk to their next class, acquire/consume a snack, and/or use the bathroom – and in a strange building, students might have a hard time finding vending machines or a bathroom.

Prototype 1: Anonymous Lecture Feedback

Home page. User can either browse others' reviews or submit a review.

Home page. User can either browse others’ reviews or submit a review.

The user can use this form to submit a review for a lecture.

The user can use this form to submit a review for a lecture.

User gets this screen after submitting a review. It links back to the home page.

User gets this screen after submitting a review. It links back to the home page.

The user searches for reviews by department, course number, and section.

The user searches for reviews by department, course number, and section.

After the user chooses a course and section, s/he can browse the reviews from most to least recent.

After the user chooses a course and section, s/he can browse the reviews from most to least recent.

Prototype 2: Refreshment Buddy

Home screen. User must first acquire location, then look for food/water/bathrooms.

Home screen. User must first acquire location, then look for food/water/bathrooms.

If user tries to find food/water/bathroom without first acquiring location. they get this message.

If user tries to find food/water/bathroom without first acquiring location. they get this message.

The user gets this screen once the app has found their location.

The user gets this screen once the app has found their location.

The app shows nearby places to get food when the user clicks "find food."

The app shows nearby places to get food when the user clicks “find food.”

The app shows nearby water fountains when the user clicks "find water."

The app shows nearby water fountains when the user clicks “find water.”

The app shows nearby bathrooms when the user clicks "find bathrooms."

The app shows nearby bathrooms when the user clicks “find bathrooms.”

Map view shows the user's location and the location of nearby food/water/bathrooms.

Map view shows the user’s location and the location of nearby food/water/bathrooms.

User Testing:
I chose to test my second prototype, “Refreshment Buddy,” with the help of three fellow students: Katie, Charles, and Osei. During this process, they interacted with my paper “screens” as if they were using a mobile device; when they clicked a button, I would give them the appropriate piece of paper to account for that action. They provided feedback, both directly and indirectly (through observation); the insights thus derived are listed in the section below.

Katie and Charles both clicked through pretty much every screen of the prototype (Acquire Location -> Find Food -> See Map -> Back -> Back -> Find Water -> See Map -> Back -> Back -> Find Bathrooms _> See Map -> Back -> Back). Osei, on the other hand, went through the process of finding food but stopped there, without looking for water/bathrooms. I provided the next screen for them after each “click” and let them know when they were trying to click something that wasn’t clickable, but otherwise I provided no prompting or instructions. All of them seemed confused by the purpose of the “Acquire Location” button, and Charles and Osei expressed an interest in having additional information about the food locations.

Katie clicks "acquire location."

Katie clicks “acquire location.”

Osei attempts to find food without acquiring his location first.

Osei attempts to find food without acquiring his location first.

When Charles clicks "see on campus map," I switch to the map screen.

When Charles clicks “see on campus map,” I switch to the map screen.

My hastily scrawled notes from user testing.

My hastily scrawled notes from user testing.

Insights from testing:
Katie
-It’s not immediately obvious what the app means by “acquire location.” What location? Should be more specific.
-It would be preferable to show one’s location on the map after acquiring it, and then just have nearby food/water/bathroom icons pop up on the map.
-The prototype doesn’t provide a way to change or re-acquire one’s location; having a constantly updated map display would solve that problem.

Charles
-It might be better to have more specific food locations, or to provide extra information about food (e.g., show only nearby free food).
-Liked the water fountain-finding functionality.
-Like Katie, wasn’t immediately sure what the location in “acquire location” meant. Should clarify the meaning.

Osei
-Wasn’t sure which elements of the app were clickable (e.g., tried to click on “Frist Gallery” under “Find Food” but could not).
-Would like extra details, such as information about the food available (menus? vending machine items?) at each location.
-Since I force him to click “Acquire Location” first anyway, I might as well just auto-acquire the location, or not show the links for finding food/water/bathrooms until after location has been acquired.

Nightlight/Wake-up-Alarm Combo, by the Elite Four (Lab 1)

Group Name: The Elite Four (# 24)

Members:
Clay Whetung (cwhetung@)
Jae Young Lee (jyltwo@)
Jeff Snyder (jasnyder@)
Michael Newman (menewman@)

What we built:
We chose to build a nightlight combined with a wake-up alarm. Our nightlight features not one, not two, not three, not four, not five, but SIX — yes, SIX! — LEDs that turn on when a photosensor detects a decreased amount of ambient light. Not only that, but we also included a buzzer that plays a friendly tune whenever our system detects that ambient light levels have increased again. The purpose of this system is twofold: First, by providing light when its surroundings are dark, it reassures and comforts those who are afraid of the dark. Second, it audibly announces the return of light to those who might have closed their eyes or otherwise lost sensory input (e.g., the sleeping or suddenly blind). Our system is a smashing success, as it correctly lights up in the dark and plays a tune, as specified. We particularly liked the reassuring charm of the system’s adorable lights and catchy jingle. A possible improvement would be implementing a continuous alarm that the user can turn off (for example, by turning a potentiometer) — more like a typical alarm clock. We could even include a snooze button.

Design sketches:

IMAG0130

Arduino Orchestra Instrument: Pitch is controlled with soft pot, and volume is controlled with FSR.

IMAG0132

Etch-a-Sketch: Potentiometers control the x and y coordinates of the “pen,” and a drawing is rendered onscreen using Processing.

IMAG0135

Nightlight/Alarm Clock: LEDs turn on when the light dims, and buzzer goes off when light is restored.

Storyboard:
IMAG0133

IMAG0134

Photos of our system:

The entire system

The entire system

Arduino's connections

Arduino’s connections

Big breadboard connections

Big breadboard connections

Little breadboard

Little breadboard

LEDs during the day

LEDs during the day

LEDs when ambient light levels decrease

LEDs when ambient light levels decrease

Video of our system in action:

Ingredients:
– 6 LEDS (3 yel­low, 3 red)
– 1 speaker
– 1 photoresis­tor
– 1 Arduino
– jumper wires
– 2 bread­boards
– 6 330-ohm resis­tors
– 1 10k-ohm resis­tor
– 1 lap­top with usb cable

Recipe:

Circuit diagram

Circuit diagram

1. Set up the LEDs in a line on a bread­board next to the photoresistor. Place the speaker across the cen­ter divider of the other bread­board. You may find it help­ful to con­nect ground and +5V to the power rails of the bread­board for the fol­low­ing steps.

2. Make the fol­low­ing con­nec­tions:
– Con­nect the anodes of the 6 leds to pins 0-5 of the arduino.
– Con­nect the cath­ode of each LED to ground via a 330 ohm resis­tor.
– Con­nect one pin of the speaker to pin 8 and the other to ground via a 330 ohm resis­tor.
– Con­nect one side of the photoresistor to a +5V pin.
– Con­nect the other side both to A0 and to ground via a 10 kilo-ohm resistor.

3. Check the val­ues out­put by the photoresistor using the ser­ial mon­i­tor and the Serial.println() func­tion. In the code, change the PHOTO_MAX and PHOTO_MIN val­ues as appropriate.

4. Enjoy the comfort and security of living with the sweet alarm nightlight.

Source Code:

/* 
  Authors: jasnyder, cwhetung, menewman, jyltwo
  Date: 2/25/2013
  COS 436 Lab L1: The Nightlight Alarm

  The nightlight alarm: lights turn on when it's dark, and when it
  gets bright again, the lights turn off and an alarm goes off to 
  wake you up!
*/

#include "pitches.h"

const int FALSE = 0;
const int TRUE = 1;

//  Input / Output Constants
const int PHOTO_MIN = 100;  // set me as appropriate!
const int PHOTO_MAX = 1023;  // set me as appropriate!
const int DARKNESS = 500;  // set me as appropriate!
const int LIGHT = 700;  // set me as appropriate!

//  Musical Constants
const int NOTE_DELAY = 300; // (ms)
const int NOTE_DUR = 250;

//  Pin Connection Constants
const int photo = A0;
const int red1 = 5;
const int red2 = 3;
const int red3 = 1;
const int yellow1 = 4;
const int yellow2 = 2;
const int yellow3 = 0;
const int speaker = 8;

//  Variables
boolean islight = false;
int photovalue = 0;  //  value returned by photo sensor

//  Set internal pull-ups for output on LED pins
void setup()
{
  pinMode(red1, OUTPUT);
  pinMode(red2, OUTPUT);
  pinMode(red3, OUTPUT);
  pinMode(yellow1, OUTPUT);
  pinMode(yellow2, OUTPUT);
  pinMode(yellow3, OUTPUT);
}

void loop() {
  //  Grab the light value
  photovalue = analogRead(photo);

  // If it has recently become dark, turn on nightlight
  if (photovalue < DARKNESS && islight) {     
    digitalWrite(0, HIGH);     
    digitalWrite(1, HIGH);     
    digitalWrite(2, HIGH);     
    digitalWrite(3, HIGH);     
    digitalWrite(4, HIGH);     
    digitalWrite(5, HIGH);     
    islight = false;   
  }      
  // If it has recently become light, turn off nightlight and play alarm   
  else if (photovalue > LIGHT && !islight) {
    digitalWrite(0, LOW);
    digitalWrite(1, LOW);
    digitalWrite(2, LOW);
    digitalWrite(3, LOW);
    digitalWrite(4, LOW);
    digitalWrite(5, LOW);
    playAMerryWakingUpSong();
    islight = true;
  }
}

//  Play a classic little ditty!
void playAMerryWakingUpSong() {
  tone(speaker, NOTE_C5, NOTE_DUR);
  delay(NOTE_DELAY);
  tone(speaker, NOTE_C5, NOTE_DUR);
  delay(NOTE_DELAY);
  tone(speaker, NOTE_AS4, NOTE_DUR);
  delay(NOTE_DELAY);
  tone(speaker, NOTE_C5, NOTE_DUR*.75);
  delay(NOTE_DELAY*2);
  tone(speaker, NOTE_G4, NOTE_DUR*1.5);
  delay(NOTE_DELAY*2);
  tone(speaker, NOTE_G4, NOTE_DUR);
  delay(NOTE_DELAY); 
  tone(speaker, NOTE_C5, NOTE_DUR);
  delay(NOTE_DELAY); 
  tone(speaker, NOTE_F5, NOTE_DUR);
  delay(NOTE_DELAY); 
  tone(speaker, NOTE_E5, NOTE_DUR);
  delay(NOTE_DELAY); 
  tone(speaker, NOTE_C5, NOTE_DUR);
  delay(NOTE_DELAY); 
}

L1: Electronic Anti-Intoxication (or Overflow Detecting) Cup

Group 15: Prakhar Agarwal (pagarwal@), Colleen Carroll (cecarrol@), Gabriel Chen (gcthree@)

Description:
We chose to build a pressure sensitive cup because it was the most widely useful of all of our ideas, and we could imagine using it in everyday life for a number of different applications. The cup uses a force sensor to detect the amount of liquid in the cup and colored lights to indicate to the user how much they have filled/emptied the cup. The idea was originally inspired as an easy way to track your drinking on a night out. The best part of our design is that it requires almost no new interactions for the users to learn. You can fill or drink from the cup like you would with any other cup and the color scheme of the lights follows standard green/yellow/red signaling for go/slow/stop. In our video, we show the application of this to building an light-signaling overflow detector and our storyboard shows another application of this sort of technology to staying safe on a night out. As we have the cup now, it is easy to pour into, but hard to pour out of (because it is hooked up to the Arduino), which complicates certain use cases. With more time, we would make it more mobile, and we would also like to create a way for it to keep track of when the cup is filled/emptied multiple times.

Photos of Sketches:

Air Bass Sketch

Air Bass Sketch

Fat Belt Sketch

Fat Belt Sketch

Overflow Cup Sketch

Overflow Cup Sketch

Storyboard:

sb1sb2sb3sb4

Live in Action:

Photo of the full setup

Photo of the full setup

Photo showing the outer cup with sensor and LEDs

Photo showing the outer cup with sensor and LEDs

 

Photo showing the bottom of the inner cup with a piece of styrofoam used apply pressure directly to the pressure sensor

Photo showing the bottom of the inner cup with a piece of styrofoam used apply pressure directly to the pressure sensor

Materials:

  • 2 plastic cups
  • FSR
  • 3 LEDs (green, yellow, red)
  • small piece of Styrofoam or cardboard
  • alligator clips
  • electrical tape
  • Knife
  • Arduino
  • USB cable
  • Breadboard

Instructions:

  1. Start by cutting one cup to about half of its original height. This will make it easier to attach the electronic components to the bottom.
  2. Pierce a slit in the bottom of the cup. Put the FSR through the slit so that the round sensor is centered inside the cup and the long end is sticking outside.
  3. Next, pierce three sets of 2 small holes in the bottom of the cup. You stick one LED in each of these sets so that the light is on the inside of the cup and the wires are sticking out.
  4. Fit the uncut cup inside the cut one. Notice the size of the gap between the bottom of the inside cup and the bottom of the outside cup.
  5. Cut a piece of Styrofoam or cardboard to the shape and size of the head of the FSR and then tape it over the FSR. This will serve as padding between the top cup and bottom cup so that the top cup will put pressure directly on the FSR, through the padding, as it is filled with water. (Note: Ensure that the padding is taller than the LEDs.)
  6. Set up the circuit as shown in the schematic so that each of the lights is connected independently to a digital input on the Arduino.
  7. Test the FSR. Note the reading when the cup is empty, half way full, full, and about to overflow.
  8. Write your program so that: If you are sensing an overflowing cup, the yellow lights up at half way, green at full, and red at overflowing. If you are sensing a draining cup, green lights up at full, yellow at halfway, and red at empty.

Code:

const int ledYellow = 2;
const int ledRed = 4;
const int ledGreen = 7;
int fsrPin = 0; // the FSR and 10K pulldown are connected to a0
int fsrReading; // the analog reading from the FSR resistor divider

void setup(void) {

// We'll send debugging information via the Serial monitor
Serial.begin(9600);

pinMode(ledRed, OUTPUT);
pinMode(ledYellow, OUTPUT);
pinMode(ledGreen, OUTPUT);

}

void loop(void) {

fsrReading = analogRead(fsrPin);

if (fsrReading < 500) {
digitalWrite(ledRed, LOW);
digitalWrite(ledGreen, LOW);
digitalWrite(ledYellow, LOW);
}

if (fsrReading > 500 && fsrReading <= 600) {
digitalWrite(ledRed, LOW);
digitalWrite(ledGreen, LOW);
digitalWrite(ledYellow, HIGH);
}

if (fsrReading > 600 && fsrReading <= 680) {
digitalWrite(ledRed, LOW);
digitalWrite(ledGreen, HIGH);
digitalWrite(ledYellow, LOW);
}

if (fsrReading > 680) {
digitalWrite(ledRed, HIGH);
digitalWrite(ledGreen, LOW);
digitalWrite(ledYellow, LOW);
}

Serial.print("Analog reading = ");
Serial.println(fsrReading); // the raw analog reading
delay(100);
}