In addition to  the readings and assignments, each student in the class will do a group project this semester.  The specifics of the project topic are up to each student, within the following constraints.

  1. Each project must involve a virtual environment, not just technology that might be applicable to a VE.  So, if you want to focus on some technology, or business concept, or interaction metaphor, you must ground in it an actual VE.
  2. Each project must relate to at least one of the major topics on the syllabus.
  3. Each project must be justified.  There are many inappropriate or poor uses of VE’s that have been proposed (or implemented over the years), and I’m not interested in having students add to that tally.  If I think your project or VE idea is not well formed, we will talk about it and either you will convince me otherwise, or you will modify your initial idea to make it “better.”  That is the point of the proposal.
  4. Each team member must have a well defined contribution suitable for a graduate computer science class.  Nobody gets to “create media and documentation” or otherwise act in a support role.

Given that, you are relatively free to define a project that interests your group, or otherwise aligns with your interests.  Feel free to send the instructor ideas in email, for early feedback, or come chat during office hours.

If you have a project idea that may not meet these constraints talk to the professor about it.

Each project group will have a category on the blog, and will post their project description, summary of their reports, and final results (for specifics, see below:  only a subset of your deliverables needs to be posted on the blog).

The major steps in the project are as follows.

Individual Pitch

(Feb 11th, in class)

Each student will have 1 minute to pitch an idea. We will collect them as we go along, and then spend the remainder of the class session discussing them;   what’s good, what’s bad, what other ideas they inspire, what ideas overlap, etc.  The goal is to generate ideas.

The idea you pitch does not have to satisfy all of the constraints above:  you should aim to pitch an idea that could really be the focus of a project, but do suggest “obvious” or generic ideas, or ones that are obviously out of scope or scale for the class.  For example, “I want to build a vision-based real-time tracking system similar to Vuforia” or “I’d like to create a 3D virtual world for business collaboration” are both inappropriate (the former is “just” a technology, the later is both too generic and too big to be done in a class).

Deliverable: Send 1 or 2 powerpoint slides to the professor by 8am Monday Feb 11th, so they can be assembled into a single slide deck by class time.

Blog: Nothing needs to be posted on the blog for the pitch.

Grade: 5% of project grade

Project Proposal

(Feb 20th, due before class)

Each group will submit a short project proposal before class on Feb 20th.  The proposal should succinctly address the following points:

  1. List group members.  Outline what part of the project each member will be responsible for
  2. Describe the  project plan, addressing the constraints listed above
  3. Outline the project schedule (week by week plans, and goals for each deadline defined below).  Note that each of the 3 deadlines should have a tangible milestone and deliverable.
  4. List the equipment and software to be used, and plans for acquiring it (if appropriate)
  5. List the risks for the project;  what might go wrong, and what your plans are in the event there are unexpected problems
  6. Include an annotated bibliography of related projects or papers.  (By annotated, I mean include a sentence or two about each project or paper, saying how it relates to what you are thinking about)

Deliverable: You should be able to do this in 2-4 pages.  Please be succinct.  The goal is for the professor to give you rapid feedback on the project plan, especially if there needs to be a change.

You will receive feedback, and need to submit an updated proposal based on the feedback, iterating as long as required to achieve a project proposal that both you and the professor agree on.

Blog: Once you have a finalized proposal, you will post a summary of it (description, goals) on the blog.

Grade: 15% of the project grade

Progress Reports (2)

(March 11th and April 1st)

The proposal should detail your targets for the progress reports due on March 11th and April 1st.  Your target should include more than a document:  it should include a tangible milestone that can be demonstrated somehow.  It is up to you to select the most appropriate way to demonstrate your progress (combination of written report, videos, screen shots, and working prototypes), define these in the proposal document, and meet those deadlines.

It is also your responsibility to alert the professor as soon as possible if you believe you will not meet your deadlines.  Telling the professor a day or two before the report deadlines that you will not meet your goals is NOT ACCEPTABLE.  You should know at least a week in advance how things are going, and propose an alternative schedule for the remainder of the project;  leaving things to the last minute and hoping for the best is a risk, as not meeting the goals without advance notice will negatively affect your grade.

At the very least, each project report should reflect on the project plan document, commenting on how the goals were met, and updating the rest of the schedule (if needed). Individual contributions should be summarized, etc.  The reports do not need to be long, but should be comprehensive with respect to the original project proposal (and be written assuming the project proposal document).

Deliverable: Report document, and any media or demos in digital/executable format.

Blog: A summary of progress, along with links to any media or executable demos.  For example, if you use Argon, include a link to the channel

Grade: 20% of the project grade for each of the two reports

In Class Presentation

(April 22nd and 24th)

Each group will do an in-class presentation that summarizes their final results.  Use your time as well as you can:  you will be graded on the quality of the presentation!  Create (and practice) a polished presentation, and create videos of the final project.  Carefully consider if you should do a live demo;  you will be graded on effective use of your time, and if you spend a lot of time fiddling with technology or if your demo requires a lot of time to “get to the point”, a video might be a better option.

Every group is expected to have a video of their project.

Deliverable: everything you use in your presentation;  slides, media, etc.  If you use a web service like youtube or google docs, convert the content to a form you can submit (do NOT submit URLs).

Blog: you do not need to submit anything to the blog for your presentation

Grade: 15% of the project grade

Final Report and Demonstration

The final report should be formatted in ACM/IEEE conference paper format, and be 8-10 pages long.  You should structure and write the report as a standalone document that does not assume the reader has read any previous documentation on your project, describing the project goals/motivations, structure, evaluation and so forth.   You should use the document space to report what you believe is the most important aspect of the project.

Deliverable: project report, all media and demonstrations.

Blog: a final post summarizing your project. This could include the report, if you like, or not.  It should include enough media and text so that anyone reading it knows what you did.

Grade: 25% of the project grade