Project 2 - Mirror in the Bathroom

People now have access to a rapidly growing number of data sources from the web/cloud which are getting augmented with personal sensors (e.g. which now commonly talk to mobile phones or web pages. We are going to look at designing an interface to make this kind of data and more available on your bathroom mirror, which could act as a large display surface that we commonly use each day.

My expectation here is not that you will produce something that looks as good as a professional graphic designer, but that you will apply the basic rules of visual design to design an effective interface to communicate with the user.

This project has two phases each with their own due date:
  1. the sketch phase - due 2/27 at 9pm Chicago time
    1. a. final sketch - due 3/16 at 9pm Chicago time
  2. the implementation phase - due 4/16 at 9pm Chicago time

You will be working in groups. Due to the class size, the group size will be 3 or 4 people, which will give us 7 or 8 groups. You will need to choose your team, and email me the member names by 2/9. I will randomly assign the remaining students to teams before the next class. If you only have a partial team (2 people, 3 people) that's OK, I can randomly assign people to fill in, or mix and match partial teams.

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 cameras and 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. 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.

Some of the general information that the mirror will provide are
The mirror should also provide health-related information such as

Some other things the system could do

Some initial questions:

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.

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 / apartment without major remodeling. The physical mirror size is 4 feet wide by 3 feet tall. The maximum resolution of the display is 1280 x 720 pixels. You can assume the mirror does not fog up.

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

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.

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. Time how long you spend in the bathroom. 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.

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 15 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 15 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 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.

Two 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/16 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

Touch interfaces need to be implemented. If you want to use camera recognition then you can assume you have a camera that can recognize someone with training (but you need write the interface to 'train' the recognition). If you want voice recognition you need to implement it yourself on top of an existing library. You 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.

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 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.

In this phase you should add to your web page:

Any code, images, or other elements borrowed from others 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 connect a laptop from the team to the wall and show your interface in roughly life-size. While our touch-screen wall won't let you directly interact with your application you will be able to give a pretty realistic demonstration of how it would work.

You should also take advantage of sites such as to make sure that your interface will work for colour blind people.

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.

The Teams:
1 - Morris  - Prentice - Ramir
2 - Grenning - Cobb - Garay - Guerra
3 - H Wang - A Wang - Spaulding - Young
4 - Sarumi - Ahmed - Rodriguez - Hanson link
5 - Jovanovic - Bowling - Yin
6 - Chen - Snyder
7 - Szumilo - Thomiszer - Wrzesinski - Trakas link

last updated 4/16/12