The purpose of this project is to give you hands-on experience designing and developing an information visualization. You will work with a team to identify a data source that is worthwhile, determine a set of important questions, and design a strategy for exploring that data through an appropriate set of representation and interaction techniques.
Presentation: Monday, May 31 in class
Pitch blurb: Tuesday, May 30 by 11:59pm
You will briefly pitch your project idea(s) to the whole class. You should have a data set picked out that is available online and ready to download immediately. For your presentation, you'll have just 2 minutes each and no slides - like the proverbial elevator pitch. Just quickly tell the class what data set you are interested in, why you think it is interesting, and what you have in mind for a visualization project. These pitches will give you (and me) situational awareness of what other people are thinking of working on. You might find project partners, either because you find somebody else interested in what you care about, or you're more intrigued by a new idea than your previous plan.
A short description of your pitch (1-2 sentences max) is due on Tuesday, May 30 by 11:59pm as a submission to Github.[Back to Top]
Due: Friday, June 9 by 5pm
Weight: 20% of Project Grade
You're submitting a statement of intent, not a specification - it's natural that your plans will change somewhat as you refine your ideas. The key is to find some domain and task(s) that both interests you and presents an opportunity for infovis. That is, there is some task where a human needs to understand the structure of a large dataset. You're definitely welcome to link the infovis project to another class or research project. You may also build on existing software, but your project should include some implementation work of your own. This project should be completed in d3. Think of this as working through the 'what' and 'why' questions of our three part analysis. The 'what' comes later.
Statement format: your writeup should be 2 pages and follow this outline:
Project Title and Team
Domain and Data
User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: "As a
<type of user>, I want
<some goal>so that
One statement per project team is due as a push (not just a commit) to github. Submissions should be single-spaced and use no larger than 11pt font (1.5 spacing between paragraphs is fine). Submissions should be in pdf form.
1: Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.