CS 422: Project 2

Data gathering phase

In this phase you are going to try and better understand your own personal behavior in front of your bathroom window. Each member of your team should:

1 - take a photograph of your mirror
2 - measure how big your mirror is
3 - over several days, time how long you spend in front of the mirror in the morning, and in the bathroom in general in the morning. One way to do this is to use your smartphone. Start it audio recording when you do into the bathroom then say what you are doing when you switch from brushing your teeth to combing your hair to taking a shower to whatever. You can then listen at the recording later to work out and write down how much time you spend on different activities.

Create a public web page for your team where each member posts a photo of their mirror, measurements of how big the mirror is, and the timings. You will use these, along with the data from your teammates to inform your design. Before the data gathering due date you should send the address of this page to the TA and to Andy.

Sketch phase

In this phase you are going to think about the user interface to a bathroom mirror that has been combined with a display screen, speakers, and possibly microphones. Think of something like a large thin-border LCD TV with a half-silvered mirror in front of it so it continues to reflect the user's image while being able to simultaneously display computer generated graphics and act as a touch screen for interaction. Its main function is to still act like a mirror, but while you are in front of the mirror the mirror will give you additional information. For privacy reasons we will not include a camera. A microphone is not required but you may choose to add one.

Some of the general information that the mirror will provide are

personalized calendar events for today
personalized news feed items and social feed items
clock
local weather

The mirror should also provide health-related information such as

how long you slept last night, how much was light sleep vs deep sleep, and how your total hours sleep compares to the last week of data
your current weight (assuming you have a scale embedded in the floor in front of the mirror), and how it compares to the last week of data
how many steps you took yesterday, and how that compares to the last week of data

Some other things the system should do

work for regular users (full features) as well as visitors (limited set of features)
allow the user to customize the display - e.g. the widget sizes and locations
function in the day and night

Some other things the system could do

play music when you are brushing your teeth or in the shower - how do you control the playlist?
act as a light source (with different possible colours)

Some initial questions:

how long do you spend in front of the mirror in the morning and evening?
where do you display this information so it does not block the user's reflection?
does the mirror talk?
can you talk to it?
if you go to the bathroom in the middle of the night should the mirror act differently compared to the daytime?
how do you identify yourself to the mirror
if there are multiple people in the bathroom at the same time how does the system split up the display space?
how does the mirror add a profile for a new user, including their preferred language?
how does the mirror introduce itself when its first turned on?
how does the user connect the mirror to the local Wi-Fi?
what if there is a person the mirror doesn't recognize (a guest who isn't going to be here long) how should the mirror react?

Your interface should support multiple languages. It should allow the user to choose from at least 10 languages, but you only need to implement English and one other language. That second language could be a real language (see what languages your group members can write and speak) but Swedish chef or Klingon are acceptable as the second language if your team does not have a member that is fluent in another language, and there are automatic translators for those available on line. If your mirror talks then it should talk in at least two languages.

There will be several different ways to accomplish this, so one major feature of the sketch phase is to create and evaluate multiple designs. Each of the members of your group should design a version of the interface on their own independently and then bring these designs together in a meeting and create your final proposed design. All of the original designs should be significantly different from each other. If each design is done by a different person then that will probably happen naturally. Each design should be composed of sketches showing how a user would accomplish a certain task with text explaining what this screen shows. You should be drawing lots of quick sketches at first to get your ideas out, then a period of refinement. In the end I would expect there to be at least 20 final pages per design. I would prefer that the designs that you turn in are done on a computer, but if you draw _neatly_ with a ruler and print very cleanly then that is also acceptable. Anything that looks like it was hastily drawn and ripped out of a spiral notebook and scanned 5 minutes before class will not be accepted.

Here is a sample blank sketch showing before and after the user does some action. You can also use stick figures to represent where people are standing, what they are touching, etc. You can also zoom in for detailed views of parts of the interface.

sample sketch

Your sketches should also take into account the constraints the system needs to work under. It should use current-level technology, and be something that could replace a bathroom mirror in a regular person's house or apartment without major remodeling. The physical mirror size is 80" (203 cm) wide by 45" (114 cm) tall (which not coincidentally is the size of 4 displays on the classroom wall). You should assume the bottom of the mirror is 40" off the floor. Reachability is important. The maximum resolution of the display is 2732 x 1536 pixels (also not coincidentally the resolution of 4 tiles of the classroom wall). You can create your application for a lower resolution and them scale it up if you want. It should also take into account what you can code in processing. This is meant to be a design that you can implement.

You can assume the mirror does not fog up.

You should come up with a cool name for your device ... Myrror ... refleXion ...

It would also be a good idea to test your designs out on your friends, parents, or other novice computer users to see if it actually 'works.' Print out interface elements and tape them to your mirror in the morning. Where do they need to be and how big should they be? Ask your roommates or friends to try and use your taped on interface. Having first time users talk aloud about what they are thinking when confronted with your interface can be extremely helpful in giving your assumptions a reality check.

Once you have your separate designs you then need to come together as a group to create the sketches for the final design that you are going to implement.

In the sketch phase your group should create a well organized public web page that contains the following:

Important note: I will not be commenting on your sketches. I am not going to tell you what is good or bad about your design - that is where the value of having many voices on a team comes into play. Your grade will be based on the completeness of your information and the quality and variety of your designs.

This project has two critique phases. An important part of user interface design is getting feedback. Part of this feedback comes in the design phase where the members of your group critique each others design and then come up with a final proposed design to implement. Part comes from presenting your final design to the other groups. Each project team will give a short 10 minute presentation on their final proposed design, and the reasons why it looks the way it does, to the rest of the class, and then answer questions from the class for another 10 minutes. Each person in the group must speak for part of that time. Groups will be graded on the quality of the presentation and the quality of the Q/A session, so I highly recommend practicing the presentation several times. Really. Practice it. Several times. Really. And you should focus your talk only on the final proposed group design.

Members of the audience get points for asking good questions or making good comments about the interface presented. Each group can ask at most one question or comment per presentation, and at most two questions per day for credit. When asking a question or making a comment the group member should identify their group by name - this is like in a press conference when the reporter says what paper he/she works for.

Three groups will present each day for four days. The goal here, again, is to see different possible design alternatives and to get new ideas to improve your own design and implementation. As such the goal of the question and answer session is not to pick on people and rip their design apart, but rather to give constructive criticism on how to improve the design before people start implementation. The goal is for everyone to come up with a really good interface for the given problem.

by 3/17 at 9pm I would like each group to add another design to their web page. This is the design that you plan to implement - including revisions based on the comments from the class. This may be a minor revision to your final proposed design if it went over well in class and you didn't see features in other designs that you want to add, or it might be a major revision if the class presentations gave you a lot of new things to think about. You can not make any major changes to the design after this point. That is the design you will be implementing.

Implementation phase

As with Project 1 you will be designing and implementing this interface in Processing and Processing.js to run on the wall in the classroom.

You should be able to use touch on the wall itself and you can simulate a touch interface with a mouse, but remember that you don't have right click. If you want voice recognition you need to implement it yourself on top of an existing library that will work on the web through javascript. Undergraduate students can use placeholders for health related data feeds and news and weather feeds, and music tracks, but the kinds and amount of data shown must be realistic, the display of the data should be helpful, and the methods of user interaction need to be implemented to show how the user will manipulate these various kinds of information. The format of this presentation should match the rest of the interface - i.e. you need to create the presentation of that information not just cut and paste something from the internet. Graduate students need to load in data from external sources, preferably actual sites providing that data, but this can also be data files set up on personal servers.

General grade scale:
- implementing the interface for the general information and health information with a good interface gets a C
- adding other useful features like those in the 'other things' section with a good interface gets a B
- having an elegant design for those features, or a very good design with some other useful features gets an A

Your sketches from the first phase should allow you to divide up the work in the implementation phase, but I highly advise that the entire group hold regular meetings in the classroom to look at the current state of the entire integrated interface. Trying to put components together at the last minute is a really bad idea; they rarely mesh programatically or visually. Come in during office hours and test on the actual wall. Regularly.

Note that any necessary setup screens must also be implemented - i.e. if you want to connect your mirror to WiFi or a cell network or some health data account or your google account then you must provide the user interface for the user to do that.

You should also implement a tutorial to introduce a new user to their new mirror that shows them how to use all these features. This tutorial would probably be a really good thing to use for your final presentation. This tutorial must be interactive and can not be a video. It can also function as a nice automated way to test the basic features of your app to make sure you don't accidentally break something when integrating code, adding new features, fixing things.

Here is a page on testing Project 2 on the classroom wall - www.evl.uic.edu/aej/422/testingP2.pdf

In this phase you should add to your web page:

a version of the interface that runs from a webpage in the current version of Chrome
a link to all of the source code and required files
a web page describing the important features of your application and how to use it, who did what, and links to any other libraries, media, or tools you made use of. The web pages should include a series of screen shots, highlighting all of the features of your interface, with descriptive text, and a 2-3 minute YouTube video with narration showing your interface in action.

Any code, images, or other elements borrowed from other legal sources must be cited clearly in the interface itself and in the documentation.

As with the sketch phase, this phase will also have a public critique of your completed project with the same rules as the sketch phase. We will use the classroom wall to show your interface life-size through a modern chrome / electron browser.

You should also take advantage of sites such as http://www.vischeck.com/vischeck/ to make sure that your interface will work for colour blind people.

I will be linking your web page to the course notes so please send andy a nice representative jpg or png image of your application for the web. This should be named p2.<someone_in_your_groups_last_name>.jpg or p2.<someone_in_your_groups_last_name>..png and be roughly 1920 x 1600 in size.

During the project presentation days each of the groups will present their solution for 10 minutes. We will then have 10 minutes for questions and comments from the audience.

By the end of the first week the project is out your group should set up a public web page, then email the location to andy, where each member posts weekly progress reports on what they have done that week. This shows how the various tasks were broken up, and who was getting things done. At the end of the project each project team member will give a rating for your co-workers which will be taken into account at grading time, and the weekly progress reports are good evidence for those ratings.

When the project is done, each person in the group should also send Andy a private email with no one else CC'd ranking your coworkers and yourself on the project on a scale from 1 (low) to 5 (high) in terms of how good a coworker they were on the project. If you never want to work with them again, give them a 1. If this person would be a first choice for a partner on a future project then give them a 5. If they did what was expected but nothing particularly good or bad then give them a 3. By default your score should be 3 unless you have a particular reason to increase or decrease the number. Please confine your responses to 1, 2, 3, 4, 5 and no 1/3ds or .5s please.

The Teams:

#	Members	Link	Image
1	Omar, Talab Rajaram, Sriram Abraham, Jacob Davis, Brandon	link
2	Dao, Tran Nedumgottil, Anthony Auza, Jamie Rehal, Kirkpal	link
3	Cervantes, Andy Tsvetanov, Jordan Strahilov, Borislav McClory, Michael	app link
4	Patel, Zalak Patel, Henvy Patel, Janki Patel, Jay	link
5	Hayden, Sarah Leancu, Dennis Poulos, George Wong, Tony	link
6	Machin, Yordan Mirza, Lubna Tang, Kevin Mohammad, Ibrahiem	link
7	Elsalaymeh, Daia Azhari , Dania Tsao, Kevin Tisdale-Dollah, Nathaniel	link
8	Lulaj, Grieldo Leonova, Vitaliya Zikaria, Mariam Naik, Ashwini	link app video
9	Jeon, Jae Lee, Kristine Reid, Margaret Irizarry , Michael	link
10	Tam, Patrick Ludkowski, Louis Padilla, Roldan Molina, Kevin	link code video
11	Lee, Jason Lobanwala, Shanil Ruan, Weiheng	app link
12	Mei, Jian Muminov, Sherzod Procopio, Joseph	link