|
There are three interconnected learning outcomes and goals associated with this project; low-fidelity prototyping, working with potential users to develop a prototype (interactive in some meaningful way, though likely not completely interactive) of a system that has the potential to become a real release and to document and reflect on the process of doing this. We've talked about brainstorming and low-fidelity prototyping. We will be talking about user studies more as you are working on the project, and before you need to perform user studies. In a few weeks you will submit a paper prototype as well as some additional information about your application and its users. Towards the end of the semester, you will submit your final interactive prototype with a paper describing it and documenting the steps you took to get to it. Your team will also give a short in-class presentation about your prototype in the last week or two of the semester. As you are working on the prototype, you should add a new section to your journal Google Doc where you document your personal contributions and reflections on the process. In addition to providing me with a way to see everyone's contributions, this will likely prove useful when writing the team paper.
March 11th: Each team will have talked to others and fleshed out
their project option idea to have
(1) a list of representative task scenarios,
(2) some interface design implications of these, and
(3) a short "executive summary" of the project written to explain the idea
to a funding agent or campus administrator.
One member of the team should then e-mail this information to me
(at egolubUMD@gmail.com)
on behalf of the team. A single PDF is probably
easiest on my side of things, but if you'd like to do each of the three
bullet items as it's own PDF, that can work as well.
|
|
|
| At the end of the project I will be asking everyone to assess their contributions as well as the contributions of each team member so think about the contributions being made by others as the project unfolds. |
|
|
|
As you are working to prepare your in-class presentations, consider
the following as an example structuring of such a presentation.
Please practice your presentation to make sure it will fit into the
10-12 minute guideline (my suggestion is to aim for 10 minutes in
your practice runs).
|
|
|
|
As you are working to prepare your written report, make sure that the
written report contains everything that your in-class presentation
contains, along with a written version of the narrative of how your
project unfolded. In the written report it is fine to talk about
challenges encountered and how the team met them.
You will be able to provide more details here than
during the class presentation. The written report should also give a
summary of "highlights" of each team member's contributions.
An example structure could be a 5-8 page document including: |
|
|