What not to do: don't come up with an idea that's just about building some application, like an email reader or a web browser, unless you're using that application to demonstrate an interesting, creative, and substantial, contribution to user interface software--new interaction techniques, interfaces, toolkit capabilities, and so forth. Remember, this class is about creating compelling user interactions, not just app building.
Projects must be done in teams of two, and must be on a topic approved by the instructor. Depending on whether we have an even or odd number of people, we may have a single team of 1 or 3 at the instructor's discretion. It is possible that more than one team works on a related project topic. However, those teams must work separately on their projects. You are responsible for finding team mates. If you're looking for a partner, using the discussion forums on T-Square may be a good way to match people and project ideas into teams. Please note that I expect all teams to behave professionally with each other, and to share in the obligations of the project equally. See the section on Teamwork Expectations at the end of this document for more details. In situations where work is not shared equitably, overall project grades for individual team members may be adjusted to reflect this.
Start right now: You should begin immediately looking for a project partner and discussing possible project ideas. I suggest reading carefully through this entire document so that you understand the requirements and grading criteria for all parts of the assignment before deciding on a project topic.
It should go without saying, but proper citations and adhering to the Georgia Tech honor code are essential with this assignment. Bulk copying from a published research paper, website, etc., is unacceptable, whether cited or not. Properly citing others' work and acknowledging external references is required in all cases.The breakdown of deliverables and grading for the project is given below.
Please see the online class schedule for due dates.
Your team should begin brainstorming on possible project ideas early in the semester. Feel free to look at the project ideas linked off of this page, but you do not need to limit yourselves to these ideas. You should look ahead in the class topics and readings, as well as browse relevant conference proceedings (conferences like CHI, UIST, and Ubicomp are particularly good places to look for inspiration). Other classes you're currently taking, or have taken, might also provide inspiration (example: if you're taking the grad networking class, perhaps some interesting interaction techniques designed to afford better network management).
By this milestone, you must deliver a preliminary writeup that describes the project you're planning to do. This is a preliminary proposal, because the instructor and TA may give comments or feedback about how to modify your project. For example, we may suggest changes in direction to ensure that your project aligns better with the learning goals of the class, or may suggest increasing or decreasing the complexity of the project. Proposals that are out-of-scope for the class, or that represent an insufficient amount of work, will be disallowed.
The deliverable for this phase of the project is a two-page proposal in PDF format, which outlines the motivation for the project (why it is a good idea, ideally grounded in what you've learned from the lectures, readings, or outside materials), and details on what exactly your project will do (a description of the system, or interaction technique, or whatever, as well as some details of how you think you'll implement it). You can feel free to include a few citations if they help you motivate or describe your project, but these aren't required. Images or figures may be useful in helping you communicate what exactly your proposed system will do.
This deliverable should be submitted on T-Square, by only one of the team members. Be sure to give your project a title and list the names of all partners on the team in your submission. This submission will not be graded, it's just to give an early opportunity for you to get feedback on your project idea.
In this milestone you'll submit your final project proposal. This written document should incorporate any feedback provided by the instructor or TA on the preliminary proposal, and should be a polished and detailed description of your motivation as well as what exactly you will deliver at the end of the semester.
In essence, this deliverable should look much like the first half of a conference paper: it should introduce your idea, provide the motivation and setup for your system, discussion of related work, and overview of what you plan to build. Illustrations may be helpful if you're proposing some GUI-based interaction technique or other visual system.
As before, you'll lay out the motivation for your work--why it's a good idea. For this deliverable, however, your project idea should be fully grounded in the relevant literature from the UI Software community. This literature is expected to come from major scientific sources, including peer-reviewed conferences such as UIST, CHI, Ubicomp, Multimedia, CSCW, or others, and journals such as ACM TOCHI, IEEE Pervasive Computing, and the HCI Journal. The Georgia Tech library website allows you access to all of these for free; sites such as Google Scholar and CiteSeer are also helpful. I would expect most submissions to have 15-25 citations.
In a few well-justified cases, authoritative web sites and non-research articles may be accepted, but the large majority of your bibliography must be academic research publications. Remember: a good related work section isn't just a list of papers. You can use it to motivate your project by using the papers to explain what the current state of the art is, and where the gaps are.
Your deliverable for this phase of the project is a 4-page (max) proposal in PDF format that includes the items listed above, in standard ACM format. For details, please check here for the formatting instructions used by UIST (ignore the specification of 10-page papers, and you do not need to include the copyright information). Again, only one team member should submit this in T-Square, but be sure you have both partners' names on the submission.
This submission will count for 20 points in the project grade. Grading will be based on the following criteria:
For this milestone you'll submit the following deliverables:
Please submit all of these as a single ZIP file via T-Square. Only one person should submit the file, but be sure to include both team members' names.
The implementation portion of the project will count for 30 points in the overall project grade. This is the milestone in which we evaluate what your project actually does:
In some cases, we may award bonus points for extreme novelty or extra "polish" (such as great graphical design, or implementation of extra features that, while not contributing to the UI portion of the work, make it more useful or finished).
During the last class meetings, students will be responsible for a presentation on their project. This will include a demonstration of your work as well as an overview of your motivation and implementation.
If you rely on special equipment that can't be transported to class, please bring a video and slides; if you have special logistics considerations you may schedule time for a private demo with permission of the instructor.
Note that it is your responsibility to understand what equipment is available in the classroom and come prepared! For example, most classrooms have only VGA connectors for the projectors, not HDMI. Be sure to bring your laptop power adapter.
Given that our presentation schedule is very tight, here will be a substantial penalty on the grade for this milestone if we have to reschedule due to lack of preparedness.
The presentation will count for 20 points in the overall project grade.In this milestone we are only grading for the quality of the presentation itself, not the overall quality of your system. Presentations will be graded on the following basis:
The final project milestone is to do a complete writeup of your project that is in the form and style of a conference research paper. This will be an 8 page (max) paper in standard ACM format, as in Milestone 1. If you wish, you can "reuse" your material from Milestone 1 in this deliverable, as appropriate (be sure to update it if your motivation, references, or other material have changed, and of course the deliverable should describe what you have done as opposed to what you plan to do). This deliverable should be submitted as a PDF document on T-Square by one of the project members; be sure to list both members' names.
Look at some of the assigned readings from the class, or proceedings of conferences such as UIST, Ubicomp, CHI, and CSCW to see the form and style of these papers. The typical paper will have an introduction section that motivates the work, a discussion of related work, a system description (including implementation details as necessary), sometimes an evaluation, discussion section, conclusions or future work, and references. Many of these sections will be new for this deliverable. The actual sections that you might have can vary, of course, but should be plausible as a research conference paper. I suggest looking for papers that are on topics that are at least superficially similar to your project and using them as templates.
The Author's Guides for various conferences provide details on how to write an effective research paper. As an example you can check out the Review Criteria for the UIST conference. This document details the set of criteria for how the reviewers (in our case, the instructor and any TAs) will evaluate your paper.
For a project of the appropriate scope, I would expect the final writeup will likely take the entire 8 pages to provide sufficient detail, coverage of related work, and so forth.
This portion of the submission is worth 30 points. The grading criteria are as follows:
It should go without saying that in a team project, I expect everyone to contribute equally. This doesn't mean that everyone has to do the same job: some may take on more responsibility for the writing, others for the coding, and so forth. But it does mean that I expect each teammate to exhibit an appropriate level of professionalism, responsiveness to their teammates, and overall sharing of the obligations of the project.
The first step toward a successful project is setting expectations appropriately. Talk to your partner early about workload and division of responsibilities. If you will be out attending a conference, let your partner know beforehand so that he or she can plan appropriately.
If you feel that a member of your project team isn't carrying his or her weight, then the first step is to speak to that person directly. I strongly prefer to rely on teammates working through these problems themselves. However, if you feel that you've exhausted these options, please make an appointment for your team to speak to me directly.
At the end of the semester, each person will complete a short "teammate assessment" form, detailing what specifically you did, what specifically your teammate(s) did, and how you feel the workload was distributed. In certain rare cases, where a strong inequity in workload or quality of work exists, overall project grades for the teammates involved in the project may be adjusted plus or minus up to 5 points to account for this discrepancy. In general, I do not anticipate (nor look forward to) having to do this for anyone, so please ensure that you're carrying your weight on the project.
Back to CS 4470/6456 Home Page