Project 1 will give you a chance to
program a small interface and get used to html and JavaScript
before we break into groups and proceed onto Project 2.
In homework 1 you took a look at the
current variety of controls for a shower / bath. In this
assignment you are going to design and implement a more futuristic
interface to solve those needs. As we move towards homes that have
more computer controls (lighting, temperature, door locks,
doorbells, alarms, music, etc) at some point that kind of
technology will move into the bathroom.
While it is conceivable that you could
control your bath / shower from your phone or watch, we are going
to create a system where all the controls are external to the user
and placed on the wall, as they are now, just with much more
technology backup.
Based on your work on homework 1 and your in class discussions
with others about homework 1, you should have a pretty good idea
about the basic needs of this interface. The user wants to
quickly, easily, painlessly take a shower or bath at their
favorite temperature and shower head (spray) settings.
You should start by coming up with some sketches of what your
interface could look like. Try some of your ideas out in the
shower / bath. Get feedback from your friends.
Here are some additional requirements:
- assume that there is a bath mat on the bottom of the
shower / bath that is smart (like a wii balance board) so it
knows the weight of the person standing/sitting on it. This
could be useful to know when a person has stepped into the
shower or is sitting in the tub
- your interface should support people standing to take a
shower and sitting back in the tub for a bath - the range of
comfortable reach for controls is very different in those
two use cases
- any text or audio needs to 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, but
Swedish chef or Klingon are acceptable as the second
language, and there are automatic translators for those
available on line. If your shower / bath talks then it
should talk in at least two languages out of 10 selectable.
- if you chose to display any units (like temperature) then
they should be in C or F based on each user's preference
- remember that people who wear glasses don't wear them in
the shower so make sure your interface elements and icons
etc. are large enough, and make sure any buttons are large
enough to touch easily
- you should be able to store, update, and retrieve up to 5
preference settings
- you should support first time users, regular users, and
guests, so you will need to identify people or have people
identify themselves - while a video camera could be helpful
for user identification, it probably wouldn't be good for
sales, so no video cameras in the default system
- assume that the device knows the current temperature of
the water and how much water is in the tub (in case its near
overflowing, or the drain may be blocked)
Implementing that interface well gets you a C. To get an A or a
B you need to add at least five more additional functions and
create a really good user interface.
Some other things you could add (and feel free to add good ideas
of your won)
- safeguards for kids burning themselves in too hot water
- clock display (remember there are multiple 'common' ways
to show the time and date depending on where you are from)
- chime / announcement for when a bath is ready
- important news feed
- calendar reminders
- current weather and today's forecast
- ability to answer a call (assume integrated phone /
internet calling)
- something to record all those great ideas you get in the
shower
- backdrop imagery (tiles, country lake, the moon, etc)
- playing music
- several default sets of preferences for people to start
with
clearly you are not going to be turning physical water on and
off through your interface, though you should show whether
water is coming out of the shower head or faucet if the user
has told it to - e.g. you could change the color of the shower
head or spout in the interface, or have some cute animation of
water. You do NOT need to run a simulation in the background
for the amount and heat of water in the system, but your
interface should react to the user and change its state
appropriately as the user interacts with it.
you can use static mock-ups of the time, calendar, weather,
music data or use live data that you query. Either way the
display and interface should match the rest of your interface
and not look like it was cut and pasted out of some other
application.
Implementing Project 1
There are various libraries for drawing and interacting in modern
web pages. For this project we are going to use
fabric.js
-http://fabricjs.com. Fabric is a fairly simple way to draw on
an HTML5 canvas, but more importantly for this class it builds
interaction in, making it easier to re-position elements on
the fly while developing to quickly try out new ideas. It is
explicitly not a GUI builder. This is a shower, not a laptop,
so you should not be constrained by interface elements
designed for other platforms. The user
interface should be suitable for everyone, not just people who are
familiar with computers, or even tablets and their user
interfaces.
You may use other publicly available JavaScript libraries for any
specialized networking, sound, or data handling, but not for
interactive graphics. You can use applications like Photoshop or
illustrator to create images to use in your interface. If you have
questions about whether a particular tool is legal, ask first.
Here is some code to get
you started (and a version
scaled for the classroom wall)
The total screen size in the classroom is roughly 8196 x 2188
(which is almost the same aspect ratio as two HD monitors side
by side), but we will not be using the entire wall. For the
shower/bath itself you should assume the physical wall area you
are working on is 160 cm (5.25') for the length of the tub, and
75 cm (2.5') for the width of the tub, and the walls are 170 cm
(5.6') tall. We can pretty much do this life size in the
classroom with a canvas size of 3650 x 2000.
Each person will work individually on this project; this project
is NOT a team project.
It is expected that all of the code used in these programs will be
written by you. You can use code from the web as examples and a
guide to writing your code, but the code you turn in for the
project must be your own.
Any code, images, icons, or other elements borrowed from others
must be fully cited in your application itself and on your webpage
documentation.
I would advise that you look into getting a public webpage up
quickly either through UIC or google or a provider of your choice,
and start testing your interface on that website as well as
locally. The page must remain visible and accessible to everyone
in the class until the term ends.
Some other thoughts on JavaScript and HTML5:
- the console is your friend
- JavaScript does not have block level scope
- be careful what 'this' is at each line in your code
- be careful with == and ===
- jshint is your friend - http://www.jshint.com/about/ and
http://nodejs.org/download/
- classes can help integrate code from multiple people when
you get to project 2.
- browser caching makes it hard to tell if you are running the
latest version of your code especially from an external site.
You can run your browser with the local cache turned off.
Another solution is to run your own local web server via
Python Simple HTTPServer -
http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/
- when creating separate regions on a web page it can help to
initially give them each different background colours to see
how much space each region actually covers
- if you run a JavaScript blocker it may block parts of your
app from loading
- if you draw something and it doesn't appear it may be
outside the canvas or underneath something else. making
objects partially transparent helps with the latter.
Turning in Project 1
You should create a set of public web pages (available to anyone
for the duration of the course) that describe your work on the
project. This should include:
- 1 page containing your application
- 1 page with links to all the source code
- 1 page on how to use your application and the things you can
do with it.
- 1 page on why you think you have created a good interface.
- 1 page on your sketches
all of which should have
plenty of screenshots with
meaningful captions. Web pages like this can be very helpful later
on in helping you build up a portfolio of your work when you start
looking for a job so please put some effort into it.
You should also create a 2-3 minute YouTube video showing the use
of your application including narration with decent audio quality.
That video should be in a very obvious place on your main project
web page. The easiest way to do this is to use a screen-capture
tool while interacting with the application, though you will most
likely find its useful to do some editing afterwards to tighten
the video up. Its also a good idea to have a video like this
available as a backup during your presentation just in case of
gremlins. You can also shoot your video on the classroom wall if
you wish.
The web page including screen snapshots and video need to be done
by the deadline so be sure to leave enough time to get that work
done. Once you have your webpage done, send the URL to andy before
the deadline. I will respond to this email as your 'receipt'.
I will be linking your web page to the course notes so please send
me a nice representative jpg or png image of your application for
the web. This should be named
p1.<your_last_name>.<your_first_name>.jpg or
p1.<your_last_name>.<your_first_name>.png and be
roughly 1024 x 768 in size.
Presenting Project 1
An important part of creating user interfaces is getting feedback
and using it to improve your design. Given the class size, this
can be a bit of a challenge. On 2/9 and 2/11, after the project
has been turned in, we will have some group discussions and
presentations about the solutions to Project 1.
On Tuesday 2/9 the class will break into groups. Each group will
compare notes on their solutions to the problem and come to an
agreement on a single revised interface design, so bring printed
screenshots of your design to this class meeting (the web pages
you created to turn in the assignment should be able to do
double-duty here). This revised design does not have to be
implemented; it should be presented as a series of screen
snapshots / mockups for the major functions. It is expected that
this design will not be the same as any of the previous designs -
your goal is not to pick the best previous design - your goal is
to come up with a new best design that is better than any of the
previous ones.
Before Thursday's class on 2/11 each group should create a web
page with the team members' names, the screen snapshots for the
revised design, and a description of how the revised interface
will be used. The address of this page should be emailed to the TA
before class begins on Thursday.
On Thursday 2/11 each of the groups will give a presentation on
the revised interface that their group came up with, using their
web page, showing the snapshots and giving a brief description of
its functionality. The length of the presentation will be
determined once we know the number of groups, but most likely
around 5 minutes.
Very likely later on in the term the class will break into
different groups and revise these revised designs again, so keep
them around.