The goal of the afternoon lab sessions is to help you develop an advanced interactive system that applies the concepts you will learn in the morning lectures. You will be working in pairs and can choose the topic for your project, which we will validate. If there is an odd number of students, only one group of 3 people will be accepted.
We expect you to come up with an advanced architecture and an interaction design that solves the problem you want to tackle. We will also value the modularity, extensibility and legibility of your code and documentation.
Your TA will be present each week to help you with the design and the implementation. We suggest you to implement the project (or part of it) in Java, but if you want to use another language you should consult it with us first.
Form the groups. Brainstorm on the topic of your project (see examples below).
Refine and finalize the topic of your project. At the end of the session, each group should submit a document (max. 3p.) with:
- the title of the project
- description of the project
- why it complies with the topic of the course
- the main problems/challenges to solve to make it
- a brief technical description on how you will implement it (this can be revised during the development)
- overall architecture
- programming models/language(s)/toolkits
Session 3, 4, 5 & 6
Presentation and demonstration of the project (no slides, but prepare your 10-minute demo well).
Potential project ideas
- Review the HCI literature (e.g. UIST) for interesting interaction techniques. Propose one to implement.
- Create a drawing program that recognizes and “prettifies” drawn shapes (e.g. drawing a rough triangle becomes a triangle of the detected size and shape).
- Create a distributed system and architecture for collaborative work on a wall-sized display. An interactive and collaborative workspace is displayed on a wall (for example, with a video-projector). Users in the same room can interact with the content with their smartphone or tablet. This example can be addressed from multiple perspectives: focus on a generic architecture and flexibility so as to propose a toolkit/framework for implementing such distributed interactive systems (although the framework should propose some ready-to-use interaction technique and a proof-of-concept application); or focus on the interaction techniques (although the architecture should also be flexible).
- Create a visual programming environment for teaching/learning programming: inspired by, e.g., scratch (https://scratch.mit.edu/), squeak (http://www.squeakland.org/), etc.; or mix several interactive and visual programming paradigms (state-based, data-flow, programming by demonstration, etc.).
- Define the scope of your project before starting, discuss with your partner your programming experience before deciding on what you want to do exactly. If you have doubts about the difficulty of your choice, ask your TA for her opinion.
- You are encouraged to be creative and add extensions to your system, but do not forget you will have 6 weeks to complete it: If you get stuck, simplify.
- We do not expect impressive mechanisms (e.g. non-player characters with AI for a game) but a well-designed, robust interactive system.
- Bear in mind this is an HCI course and you are expected to carefully design the interaction and not only the technical aspect of the system.
- Structure your code well and comment it.
Your work will be evaluated based on the following criteria:
- Breadth and depth of the functionality. You are expected to implement the proposed functionality. To get a good grade you also have to come up with extensions and creative ideas. These features you add have to be well-thought and integrate well into the overall design of your project.
- Quality of the design and implementation: clean and usable user interface, appropriate use of UI design guidelines, fluid interaction, well-thought labels and messages.
- Quality of the code: well-structured code, separation between model, look-and-feel and interaction components, meaningful names for classes, variables and packages.
- Documentation: clarity about what has been implemented, clear instructions about how to run the application (e.g., README file), code documentation.
- Bonus points will be given for creative extensions depending on how creative/challenging they are.
Criteria 1 and 2 have a higher weight. However, a poorly documented submission risks to get evaluated more strictly, e.g., if we do not manage to run it. If you decide to code in a platform other than Java Swing/Java 2D/FX, it is fundamental that you provide clear instructions about how to use it. Also, make sure that your TA has the necessary hardware to test it!
Submit your work
On session 4 (Wed, October 3) you should be prepared to show the TA your progress (this is an official landmark that will give you a grade, so be there!). You will be asked to give a brief 10-minute demo of your project during the last Wednesday session. Do not prepare slides, just show a well-rehearsed demo of the application running.
Create an archive (zip or tar.gz) that includes:
- A short document (2-3 pages, preferably a pdf) with a brief description of your result: what functionalities you implemented, what simplifications you made (bullet points are ok) and how the application can be used.
- Your code: both the source code and an executable version (in java a .jar), or your Eclipse project. Add any necessary instructions for running your project.
- Your code documentation can be automatically generated (in Java using Javadoc) or just included in the source code.