Project 1 - iLarm Clock

For the assignments in this class you can choose the user interface toolkit that you wish to use. Good options are Swing for Java, fltk for C or C++, wxWidgets for c++ or Python, and flash. The limitation is that we need to be able to check your program on the CS department linux machines on the second floor of SEL.

Project 1 will give you a chance to program a small interface and get used to the UI toolkit of your choice before we proceed onto the main project in the course: Project 2.

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. We will be using computer software to compare people's programs and it is very good at finding similar programs.

Any code, images, icons, or other elements borrowed from others must be fully cited in the work and in the README file.

Now onto the project itself.

For the first assignment you are going to design the interface for a modern alarm clock with a variety of features.

The hardware is an LCD touch screen on a small stand - 2" by 3" screen - 320 x 480 pixels - colour. You can choose whether your clock is portrait or landscape.

The clock has a usb cable so you can take it to a computer and move 128MB of mp3 files onto it to act as music for the alarm(s.) It will have five mp3s permanently stored inside it as the default alarm choices in case the user doesn't have any other mp3s.

The clock has power cable so it is normally plugged into the wall but it also has a small built in battery so it can stay on for an hour or two if the power fails and it can stay on while transferring mp3s.

The clock has some kind of built in radio/wirelss/cell connection so every 30 minutes it can receive regular updates including:

Since it is possible the user is living in a place where there is limited connectivity to the outside world, the clock should allow the user to manually set the current time.

The clock's primary purpose is to tell the user what the current time is, but it should also allow the user to quickly see data about the current conditions so he/she knows how to dress.

The clock should allow the user to easily set one or more alarms, each of which can have its own mp3 song/sound. The user should easily be able to see that the alarm has been set. Once an alarm goes off the user should be able to hit a snooze button for a few more minutes of sleep.

The clock should:

The user should be able to:

Implementing Project 1

You will simulate this application in software in a 320 x 480 window with a mouse-click being used to simulate a finger press. Think about how much space a finger takes up when pressing a button.

In terms of getting access to weather data there are a few ways to do this. In the real world the interface would be created at the same time as the weather server is implemented so there would need to be a way to simulate that weather server. One way is to grab the data off of real weather web pages and parse it to get what you need. Another way is to write a server application where you can set these values manually and then your iClock interface talks to this server regularly. A third way is to add a debug interface into the iClock interface itself that lets you set/change these values to see how the iClock reacts.

Playing mp3s may also cause an issue, so you might need to substitute sound file types for testing.

You need to think about what the most important features are of this device. Which features will be used every day, and which will be used less often. What needs to be most visible. It is important to note that this system is designed to be used by 'normal people' so there is a need to balance more powerful features with the desire to keep from confusing the user. The first thing you should do are a bunch of drawings to try and lay out this data and the controls in a useful way. You might want to do some of these drawings life-size and mount them on cardboard to test them out yourself.

Turning in Project 1

The project is due at the beginning of class on 2/12/08

Make sure your project works on the linux machines in the CS lab, the windows lab, or the mac lab on the 2nd floor of SEL by the vending machines. Be sure that your application compiles and runs in one of those three rooms, or that we can run it from a web browser running in one of those rooms. If there are any external libraries you should be sure to include them.

Be sure to have an html README file that explains what your program does, and what it does not do so that while grading we know what to expect. This file should also specifically state how to compile and run your code. You should include images of all of the various screens in their proper screen size. Pick one image that you think best represents your application and place that at the top of the readme file. We will use this image on the class web pages to help show the variety of designs created.

We will be using the traditional CS turnin system. Projects are due by the beginning of class on the due-date so please be sure you have your program turned in before then. For more information on turnin you can do 'man turnin' on any of the CS machines, but basically if you have a directory called 422 containing your project you would go to the directory level above 422 and type:

turnin -c cs422 -p project1 422

where the -c tells which course and -p tells which project. Turnin definitely works from but doesn't seem to work from bert at this point.

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/12 and 2/14, after the project has been turned in, we will have some group discussions and presentations about the solutions to Project 1.

On Tuesday 2/12 the class will break into 8 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 README file 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.

Before Thursday's class 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 Andy before class begins on Thursday.

On Thursday 2/14 each of the 8 groups will give a 8 minute 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.

Very likely later on in the term the class will break into different groups and revise the revised designs again.

Here are the designs that were turned in on 2/12

Here are the websites showing the group work done in class on 2/12 to compare their current designs and create an improved design.

Bhat - Sidea - Mihali - Urso
Basic - Hillyer - Gorczowski - Mostafa
Brown - Ogar - Tata - Valencia
Chau - Tom - Shakhnazaryan - Demeter
Iyer - Jain - Kapadia - Miryala - Nuvvula - Ritter
Bak - Ziec - Balawender -  Cheung - Mroczka
Serrano, Franco, Gupta, Patel, Mykietka

Here are the websites showing the group work done in class on 3/20 with new groupings to compare their current designs and create an improved design.

Serrano, Cheung, Brown, Gorczowski
Valencia, Tom, Hillyer, Ziec
Mykietka, Tata, Chau, Kapadia, Balawender
Jain, (Bhat), Gupta, Bak
Contreras, Demeter, Mroczka, Nuvvula, Patel
Mostafa, Shakhnazaryan, Iyer, Franco

last updated 4/3/08