• View
• History
• Print

Main / P1Final

Handing Stuff In

The project itself is due on Wednesday, March 11th. We'll have demos where you can show stuff off. (be sure to list your available times on the Wiki page Contrib.P1DemoTimesBlog).

There are three parts to "turning things in"

1. Your demo - we'll spend 15 minutes where you can show off what you've done to me.
2. Your code/artifacts - you'll turn in a zip file with what you've done. You should also put pictures into your writeup.
3. Your writeup - you'll write a document describing what you've done, how you've done it, what you've learned, and what you thought of the process. You can do this either on the Wiki, or in some more traditional "print" form (word, latex, ...) - in which case you should upload the pdf AND the source to the wiki and make sure I have a link. There's a "feedback" part of the writeup that you can either send me by email, or anonymously on paper.

The demo will be on the 11th, so you'll need to pretty much be done with the work itself. Everything else must be turned in on Friday, March 13th by 4pm.

A little more description:

• For the code/artifacts - include everything necessary to build your program, as well as example data, etc. Put it into a big zip file. Put it somewhere on AFS with public read access and send me email where I can grab it from.
• For the writeup - this documentation is a substantial part of the project. The main parts of the writeup will be evaluated as a document, but also its a major way that I have to assess your work. The expectation is a few pages of text (more on that in a bit): there's no length minimum or limit, but its best to say everything concisely rather than not saying enough or being too wordy.

Evaluation

When I assess your project (I hate having to give grades, but it has to be done), you'll be evaluated on:

1. Did you complete all the pieces along the way? This includes contributing to your blog and discussions, getting the proposal in, etc.
2. Did you achieve a good result?
3. Did you do good work along the way / learn from the process?
4. Did you write things up well?

There is no set balance to this: you can make up for doing poorly at one by doing better at another.

I mention this because it explains the writeup. For me to assess #3, I need to know what work you did (especially if you did a lot of work that doesn't show). Writing things up well, like really analyzing the technique you were experimenting with, is an opportunity to make up for not doing as well on other parts.

The Writeup

There is a more detailed suggestion of the writeup further on. But basically, I want you to document well what you did and how you did it.

As a kind of "add-on," I want your feedback on the project process. This is particularly important since I am planning the next project. I have some thoughts on things to do differently, but I don't want to change things that people like (or keep things that didn't work).

The feedback part should be separate from the rest. You can send it to me by email (preferred), or give it to me anonymously on paper (details below).

The form of the writeup is generally up to you. There are a few things that are specific requirements, but overall you can decide what you think is important to say, and how to say it.

Things you need to include (these are in the long-winded thing below):

• The separate feedback on the project.
• An explicit discussion of what you learned.
• A list of what you've read.
• Pictures. (this is a graphics class)
• What would you do with an extra 2 weeks

Some commentary on why I am asking you to these things

You might not care about this part. But I'm writing it to make sure that what I am asking you to do really is aligned with my pedagogical goals (yes, there really are pedagogical goals for this class)

Writing things up serves a number of purposes.

1. Its good practice at an important skill. Being able to document and explain things is a relevant skill - maybe as important in the long run as the technical ones.
2. Its a way to tell others what you've done. In particular, its a way that I know what you've done so I can try to evaluate it.
3. It forces you to explain what you've done, which is good for helping understand stuff (having to teach about something is a great way to learn it - something I'm confirming to myself this semester).
4. Reflection is a good way to make lessons sink in. Lots of stuff on teaching I've read/heard recommend making students reflect on projects as a way of making them learn more.
5. It can make some of the hidden lessons come out in your mind. For example, you (hopefully) learned a little bit about project planning - but the value (or lack thereof) these lessons might not come out unless you reflect.
6. It helps me understand the process we've gone through, so it can be better next time. Normally, this is a favor to future students. But for you, it can make the rest of the semester better.

Parts of the Writeup

There are 4 aspects here, not completely independent. And a fifth thrown in specially for you...

1. Description of the completed project.
2. Evaluation of what was done - the project results.
3. Description of the project process.
4. Self-Evaluation
5. Evaluation of the way the project was run

Basically, 1 and 2 is what did you make, and 3 and 4 is how did you make it. At a really terse level, you might answer them (for a hypothetical example - and these are short summaries of what you might really write):

1. I was going to make a program to animate a train going around a track, but what I ended up with is a blank screen.
2. After extensive testing, I am realizing that i must still have some bugs in my implementation. The problem might relate to the "on" button of the monitor. Had things worked, I believe that I should have seen ...
3. Over the past 6 weeks, I read about splines and lighting, typed a lot of C++ code, and puzzled over what the cable dangling out of the back of the monitor was for.
4. I think I put in a lot of effort, and learned a lot from reading. I've found out that coding blind is hard for me. I am quite disappointed that I didn't make more progress towards a functioning project. I learned a lot about splines.
5. I think the project was well structured. Next time, you might require students to work in the lab more since those machines don't seem to have the dark monitor problem.

The questions below are suggestions. You don't necessarily need to explicitly answer each one, however, it is meant to give you the kinds of things you should include in the writeup, and some things to think about to help you collect your thoughts about your project.

1. Description of what you've done

Note: this is "what did you do" in terms of what was the thing you created. "What did you do" in terms of the actually work in getting there goes later.

• Define what the problem you were solving was.
• What does the thing you created do?
• How does it do it?
• What can it do?

Be sure to describe how to actually use the programs you created, as well as just describe what they do.

Include lots of pictures. I like pictures.

• How does it do it?
• What methods have you embodied, what were your sources for these methods?

2. Evaluation of the "things"

• What are examples of what you've done with it?
• How good are these results? (how do you assess them)?
• How does the implementation perform?
• How have you tested it?
• How do you know whether its right?
• How do you distinguish between problems with your implementation and problems with the ideas?

Part of this phase of the evaluation should be a discussion of what things should have been. In addition to explaining what your program actually did, what would it have been able to do if you had gotten all the bugs out, had a more complete implementation.

3. Description of the process

Sometimes, a lot of hard work goes into something with little to show for it. To prevent that from happening here, this is your opportunity to describe all the hard work.

• What did you do over the past 5/6 weeks?
• Where did the time go?
• What were the stumbling blocks/issues that came up?
• What were the things that went well?

Note: if you've been keeping a good blog (for example Alex's or Jake's), that will satisfy those questions.

• What would you have done with an extra 2 weeks?

Had this been an 8 week project, rather than a 6 week one (or a 6 week project where you didn't have the planning phase), what could you have achieved?

• What did you read/refer to?

Include a reading list (all the things you've read/referred to). If you had been keeping your reading blog up to date, this will be easy. Be sure to include web pages and tutorials that you found useful. I am particularly interested in your assessment of which things you read were valuable.

4. Self-Evaluation

• How do you think you did?
• What went right?
• What went wrong?

Don't be afraid to be self-critical. If you say "I don't think I did too well" it won't affect how well I think you did. On the other hand, don't be too hard on yourself or self-delusional.

• Did you choose an appropriate topic?
• How much of the problems or successes came from poor choices of topics and/or

planning?

The upside of picking your own project is that (hopefully) you picked something that you were really interested in, and had a chance to learn about something you really wanted to learn about. And ideally, your interest in the topic can motivate you to work extra hard on it. But, one of the risks in a project where you choose the topic is that you pick a bad topic. One that's too hard. One that you lose interest in. One that requires some resource that you couldn't find. One that required too much engineering. One that required you to deal with some frustrating tangential issue....

• What did you learn?
  • technically? (e.g. about the graphics topics involved)
  • in terms of engineering? (e.g. programming, working with tools, ...)
  • in terms of doing projects in general?

Answering the What did you learn question is one of the most valuable things for you (since it can help the lessons really sink in), and for me (since ultimately, its what I care about). But its a hard one to answer, which is why I tried to give you the 3 sub-parts to help frame your thinking.

• If you had it to do all over again...
  • Would you have done the same topic?
  • How would you have changed the plan?
  • What would you definitely do again?
  • What would you have done differently?

This question is really just a way to ask some of the same things in other questions in a different way, that can aid reflection. Here's another one:

• If someone else were about to do the same project, what would you tell them?
• What did you wish someone told you while you were doing the project?

5. Evaluation of how the project was run

Note: you won't be graded on your answers to this part, but rather on just doing it.

This is basically your chance to evaluate me, and the project format I have set up. I really want your feedback so that the next project can be even better.

Note: If you prefer to do this anonymously, print out your text answer, put it in an envelope. Put that envelope in another envelope. Write your name on the outermost envelope and give it to me. (that might sound like a lot of effort, but the double envelope is necessary - i need the outermost one to know that you turned something in, and the inner one makes sure I can't connect your paper to your name).

Again, this is an "open essay" question, but here are a bunch of questions that might jog your thoughts.

• What was good about this project?
• What could we have done better?

Asked abstractly like that, it can be hard to answer. But you should be able to say:

• What was the best thing about this project?
• What was the worst thing about this project?

Selfishly, I would like to know what I can do to make the project a better experience for everyone:

• Were there things the instructor did that made the project better?
• Are there things the instructor could have done to make the project better?

The beginning of the project included time for looking around to choose topics and problems. I am really curious as to whether or not this was a good use of our time:

• Did you find the process of having to look around for topics a good way to learn about problems in graphics?
• Do you think that it was an effective way for you to pick problems to work on?

I made a point of having an explicit planning process. The goal was to force you to make the project concrete, and hopefully to make sure the project was something that could be achieved in the time you had. Also to give you some planning experience.

• Did you find the planning process useful?
• Should I have worked harder to force people to make concrete plans?
• Should I have forced people to look back at (or update) their plans?

Rather than having people do explicit status reports, we tried blogging and having the in-class "open lab." Some people have been already been very positive about the blogging.

• What is your opinion on the blogging? Are there ways we could have improved it? Would we have been better off with weekly status reports?
• Are there better ways to monitor progress?
• Would you have preferred to have gotten more feedback?

We tried some "cohort" exercises to make it more possible for you to help each other. These included the topic discussions on the wiki, the class meeting and the open lab for discussion.

• Did these community things help you? (if you worked on a unique project, then your answer might be a bit different). Which ones worked? Which ones didn't?

I would also be curious in feedback about other aspects of the class (readings, lectures, discussions, etc.). At this point, anything is up for grabs to be changed / improved / rethought.