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. www.bodymedia.com) 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:
- the sketch phase - due 2/27 at 9pm Chicago time
- a. final sketch - due 3/16 at 9pm Chicago time
- 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
- personalized calendar events for today
- personalized news feed items and social feed items
- clock
- weather
The mirror should also provide health-related information such as
- how long you slept last night and how much was deep / REM /
light sleep
- your current weight (assuming a scale on/in the floor) and
how it relates to your recent weight
- how many steps you took yesterday, and how that relates to
your recent totals
- how many calories you burned yesterday
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?
- have a camera to help detect skin cancer by taking photos at
regular intervals and comparing them - lots of privacy issues
here
- show you how many calories you ate yesterday (assuming you
have a way of tracking that) or even more detailed nutritional
information about what you have eaten recently
- show that it has recognized you and then welcomes you
- act as a light source
- allow the user to customize the display - e.g. the widget
sizes and locations
- and you are definitely encouraged to add ideas of your own
Some initial questions:
- how long do you spend in front of the mirror in the morning
and evening?
- does the mirror talk?
- if you go to the bathroom in the middle of the night what
should the mirror do?
- how does the mirror recognize you to show your data (camera
recognition? voice? touching an icon?)
- 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
- if the mirror needs to connect to the internet, how are
those settings set
- 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?
- would the mirror show you different things in the morning
and in the evening?
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:
- scans or screen snapshots of the 20+ pages (each) that
describe each of your group members' designs
- scans or screen snapshots of the 20+ pages that describe your
final proposed design
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:
- a downloadable version of the interface written in qml along
with any other necessary pieces of software (databases, etc)
- a web page describing the important features of your
application, who did what, and links to the source code and
other data files. 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 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
http://www.vischeck.com/vischeck/ 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
|
link
|
link
|
2 - Grenning - Cobb - Garay - Guerra
|
link
|
link
|
3 - H Wang - A Wang - Spaulding - Young
|
link
|
link
|
4 - Sarumi - Ahmed - Rodriguez - Hanson |
link
|
link
|
5 - Jovanovic - Bowling - Yin
|
link
|
link
|
6 - Chen - Snyder
|
link
|
link
|
7 - Szumilo - Thomiszer - Wrzesinski - Trakas |
link
|
link
|
last updated 4/16/12