Project Description
The idea of the project is to take the knowledge about visualization that you are gaining in the class and apply it to a real problem and real data. You are free to choose whatever application and data you like as long as the scope of the project is reasonable. I'm also providing you with a list of possible projects that you can pick from.
You will choose an application area and set of tasks and implement either a visualization technique or a system of your own. You may use any existing components or toolkits to help you build your system. The language and platform is also up to you.
Overview
Group Size: 2-3 students.
Expectations will be adjusted according to group size.
Important dates:
- Nov 02 - Project meeting due
- Nov 05 - M1: Project proposal due
- Nov 19 - M2: Ideation / Lo-Fi prototypes due
- Nov 23 - M2 presentations
- Dec 10 - M3: Hi-Fi prototype due
- Dec 14 - M3 presentations
- Jan 21 - M4: Final report due
- Jan 25+30 - M4 presentations
Project Types:
There are three types of possible projects: Technique projects, System projects, and evaluation projects. The three types of projects may be combined in some circumstances but please talk to us first.
-
Technique project: You will choose a visualization technique and a number of approaches and compare the advantages and disadvantages. You may use any existing components or toolkits to help you build your system. The language and platform is also up to you.
-
Design study project: The goal is to help solve a visualization problem for a particular application by creating a visualization system for the given problem. This could be a scientific task or a visualization of your favorite data set to gain insight.
-
Evaluation project: You will evaluate the effectiveness of a given visualization technique by running a study using a number of participants. There are four parts to these types of projects: selecting a techinque, desigining the study, running the study, and evaluating the results. While, this is not as programming-heavy as the other project types, designing and executing a study is not easy and there will be significant work.
Software:
You may choose the software that gets the job done best or that you are most comfortable with. A fantastic list of available software resources can be found on Tamara's page.
For a technique project I am expecting a significant programming effort on your part.
Submission:
This year we require that you submit each milestone as well as your
presentations to Moodle. There is a submission entry for each stage of the
project. Note that you as a group have a total of two grace days for the
various milestones but this does not include the presentations.
Marking
The project is worth 45% of your final grade.
Marking of the project will be broken down as follows:
20%:
M2: Lo-Fi prototypes
10% Content
10%: Written report
20%:
M3: Hi-Fi prototypes
10% Content
10%: Written report
5%:
M2 or M3 presentation
60%:
M4: Final
10%: Presentation
35%: Content
15%: Written report
Presentations will be graded based on:
- Content summary: 50%
- Synthesis / critique: 20%
- Presentation style: 15%
- Materials preparation: 15%
The content of your final report will be graded based on the completness and success of the followed guidelines given below. Finally, the written report will be graded based on:
- Synthesis / critique: 50%
- Writing style (typos, references, placement of figures, etc.): 25%
- Materials preparation: 25%
This is all summarized in the grading sheet
that we use.
Milestones
M1: Project proposal (due Nov 05)
The project proposal does not count for marks. It is the first iteration of your proposal and a chance to get feedback on your proposal before it is marked.
Meet with us in person after you prepare your summary. While it might be ok to sign off on your project after only one meeting, it might require several iterations. Hence, please do not wait until the last day for talking with us and brainstorming together. In past years the groups that met with us beforehand to discuss their project had a much easier time.
I'd also suggest to not worry about any software systems to use until you have a clear understanding what visualization problem you are trying to tackle. What are the requirements and what are the expected outcomes? What user interaction will be required? Only after you have a clear understanding of the visualization issues, only then go and figure out which tools might be best suited to help you accomplish these set goals. Sometimes no single tool will accomplish what you need and you either have to pipeline different tools together or write custom code to extend a particular tool.
Prepare a webpage with the following information then, sign up for the project using the google form:
- Names and email addresses of the members of your group
- A clear specification of whether you are approaching a technique, design study, or evaluation project.
- Description of the target application, dataset, users, and task(s).
- These descriptions should be detailed and specific. Give specific examples of user goals and the information & interactions the visualization tool must support in order to achieve those goals.
- Explain why these goals are hard to accomplish with existing standard tools.
- Brief description of your proposed solution. (At this stage just a short description and/or simple sketch is fine. You will develop this more for the proposal. However, a clear direction should be communicated.)
- A clear separation of tasks between the group members: you have to detail who did what for this milestone.
M2: Lo-Fi Prototyping (due Nov 19)
Expand and revise your Project proposal webpage. Include all of the information required for the proposal (you may update it or revise it) plus:
- Expand on your proposed visualization solution.
- Provide detailed illustrations of what the interface will look like and how the user will interact with it (e.g. a storyboard). You may either draw these by hand or use a mockup tool of your choice.
-
To help with coming up with novel designs,
in order to get full marks,
you need to provide at least 10 different possible single graphs that show different aspects of the data. In addition, you need to provide at least three different ways of combining different views into an interactive application (dashboard) and demonstrate what type of interactions are possible.
-
In order to ensure you are exploring the visualization design space, we
require you to, reason and design for at least 5 different vis
techniques. These methods can be in terms of vis encodings: aggregation
over all variables except for one, aggregation in general, tree-maps,
heat-maps, hierarchical exploration, correlation of two variables,
correlation over multiple var, filter, scented widgets, etc.; for
interactions: tooltip, zoom, table lens, focus-and-context (fisheye or
similar), small multiples, brushing & linking, etc.
-
You should
reason about the advantages and disadvantages of each of the different
views, dashboards, and interactions.
- Present a scenario of use, using sketches and text to demonstrate how the user accomplishes a specific task with your tool.
- The first step here is to make your tasks much more detailed and specific. Create a fictitious user and describe a specific problem they have.
- A scenario then spells out what a user would have to do and what he or she would see step-by-step in performing a task using a given system. The key distinction between a scenario and a task is that a scenario is design-specific, in that it shows how a task would be performed if you adopt a particular design, while the task itself is design-independent: it's something the user wants to do regardless of what design is chosen.
- Implementation details.
- Brief description of the language, platform, and any toolkit(s) you plan to use, and reasons for these choices. (you should have tried them out at this point)
- Milestones that break down the work into smaller parts.
- Include a description of each project milestone with start / end dates and who will be assigned to accomplish each milestone.
- These should be detailed enough that you know if the amount of work you are proposing is reasonable.
- A list of references (books, papers, software tools), that you draw upon.
- A clear separation of tasks between the group members: you have to detail who did what for this milestone.
M3: Hi-Fi prototype (due Dec 10)
Starting from your Lo-Fi prototypes, you need to incorporate the feedback from us, as well as feedback from friends and colleagues to converge to a single high-fidelity prototype that you know realize within the platform of your choice (Tableau, D3, VTK, etc.). The main idea is that you can load actual, real data and play with it and test how well you will be achieving your goals.
For this milestone you will need to:
- Provide a brief reminder of your problem
- Present images showing your current visualization design
- Demonstrate (i.e. run) your hi-fidelity prototype
- Iterate on the use cases from milestone M2
- Explain any changes to the original visualization design or work plan
- Detail current major challenges or problems
- A clear separation of tasks between the group members: you have to detail who did what for this milestone.
Your resulting prototype (and final version) must be a single integrated tool.
Furthermore, it must employ at least 4 of the following techniques we discussed
in the lecture:
- aggregation of variables
- tree-maps
- heat-maps
- hierarchical exploration
- correlation over multiple var
- filter
- scented widgets
- tooltips
- zoom
- table lens
- focus-and-context (fisheye or similar)
- small multiples
- brushing & linking
M4: Final Submission (due Jan 21)
It may seem that once your software prototype is done there is not much left
to do with the project. Not so! While you should spend time between M3 and M4
refining your software prototype based on feedback, the majority of your time
should be spent analyzing your approach on your data and illustrating the
pros and cons of your implementation. This typically requires a fair amount
of trial and error and writing it up well takes time so plan accordingly
Due date: Jan 21
Report format: PDF document
Software submission: zip file
Your final submission should be both a report detailing your complete
project as well as the software implementation of your project. Please combine
the PDF report and software together and submit them as a zip file to Moodle.
Your software submission should be runnable from the submission file. Please
include a readme file describing how to run your code. If the code does not
run when we grade it then it will count as 0.
The final report should be a stand-alone document describing your complete project. You should assume the reader has no prior knowledge of your project and has not read your proposal. Include the following information in your report:
- Motivation
- Background information about the problem, tasks, users, and data
- Related work
- Other visualization solutions to this problem or similar problems
- Any previous visualization ideas that you incorporated into your solution
- References to both academic and commercial tools used.
Approach
- Description of your visualization design
- Reasons for your design choices
Implementation
- Brief description of how the system was implemented (toolkits, languages, platforms)
- Any serious implementation challenges you encountered and how you handled them
Results
- Scenario(s) of use, including screen shots of the system being used
- Performance of the system
- Feedback from the evaluations about the design and functionality of your tool.
Discussion
- Strengths and weaknesses of your approach and implementation
- Lessons you learned
A clear separation of tasks between the group members: you have to detail who did what for this milestone.
References
Your report should include screen shots of your software that demonstrate how it functions. There is no specific page limit so take as much room as you need for images. As a general guideline, reports should be approximately 8-10 pages long. Some of the above sections will be much longer than others. (I would advocate to write your report using the latex templates used for the Vis conference.)
If you don't object to it, your report and software will be available for future classes to get an idea what range these projects have.
Presentations
A word on presentations in class. Here you have to give two presentations. Either you present M2 OR M3. In addition you will have to give a final presentation about M4.
Make sure your presentations are well thought through and structured, practiced, and on time; don't 'wing it'. Your presentation should be prepared in a presentation tool such as beamer, powerpoint, keynote, or similar. Other requirements include
- presentation length: 10 minutes; you will be penalized if you go over.
- the presentation is followed by 5 minutes of questions.
- your presentation should be available as a pdf file from your webpage appropriately linked either from M2 or M3 and M4. This needs to be online before you present.
- Due: day of presentation
Include some questions or discussion points in your presentation to help you obtain useful feedback from the class. Also, please be mindful of the presentation time and practice so that you stay in time.
A simple outline for your M2 or M3 presentation could be:
- intoduce users and tasks
- go over project prototypes
- where to go from there (milestones)
For your final presentation (of M4), interested people from outside the class will be invited so you should expect a few members of the audience who have never seen your project idea. Give a complete description of your project, including the problem, approach, results, and an analysis of the strengths and weaknesses. Focus more on the results and analysis since most of the audience will have seen your proposal and update. Demonstrate how your software works through screen shots or a live demo. (If you choose to do a live demo, make sure you have screen shots available as a back-up in case something goes wrong.) Leave a bit of time at the end for audience questions.
Also, please practice your presentation so that you stay in time.
Projects from other courses
Several visualization courses from other schools have past projects posted online. Viewing these previous projects may give you some ideas or help you determine what scope is reasonable. A fairly comprehensive list of other courses can be found at
Tamara's pages. What follows is a list of projects from the University of Vienna: