overview
dashboard
deliverables
project
bibliography
resources
x360 schedule
private
 
 PROJECT  

 

project deliverables table

MARK WEIGHTS: The following table shows deliverables, i.e. documents that you hand in. Mark weights for team deliverables are not listed here; instead see the last page of the full project assignment for a breakdown. This is because the project marking scheme does not align in all cases to deliverables; there are several elements that are assessed holistically end of term. These include the project content, management (as observed by instructor), as well as the presentatation itself.

Element Submission Description Type Weight
project ads post ads on 543 twiki - project overview (in class)   See
assignments page

project teams

post teams on 543 twiki (proj teams)

Post should include
- names of team members
- name for your team
- (if possible) 1-sentence most-likely topic description.

Team

unmarked

proposal

handin title:
projProp

1-pg project proposal, pdf format. Not marked; this is an internal planning document to be developed in consultation with instructor.
See details in project assignment.

Team

5% of team
project mark

personal blogs

post blog link on 543 twiki
(proj blogs)

Iteration 1

Individual

10% of individual
proj blog mark

personal blogs

post blog link on 543 twiki
(proj blogs)

Iteration 2

Individual

45% of individual
proj blog mark

personal blogs

post blog link on 543 twiki
(proj blogs)

Iteration 3

Individual

45% of individual
proj blog mark

final presentation slides

handin title:
projPres

PDF of final presentation slides, submitted 2 hrs in advance of final presentation.

Team

included in team project mark

final report

handin title: projReport

PDF of final report and any appendices. Videos supplied by link included in report appendices (fully typed out; clickable if possible).

Team

included in team project mark

 

project overview: sketching a design language

The 543 project is defined and carried out by a team (2015W2: ~3 members each) formed around a shared exploratory objective.

What: While there is not really a "typical" 543 project, this is a design course, specifically for computationally enabled physical media. All projects will involve a significant degree of prototyping, and most commonly the exploration is to find a way to effectively communicate something in this medium, and to gain experience in current relevant tools and practices (a rapidly moving target).

How: The project is based on Arduino-powered "physical sketching:" a rapid iterative cycle in design explorations. You'll warm up with some early individual labs, then transition to a group project.

Range: The specific focus of sketching may vary considerably by project. Some will choose to explore physical form and movement as a means of communication. Others may consider tactile display, e.g. vibration patterns.

Design Evaluation: Formal evaluation processes are taught elsewhere in our curriculum (including CPSC 344, 444 and 554). In 543, a project which carries out a full three design/prototyping iterations will not have time to conduct a careful user study, and this is not a requirement; instead, we'll use lightweight mechanisms such as peer design reviews.

If your team is highly interested in doing a formal (hypothesis driven) user study or experiment, has the appropriate preparation, and can make the case that this is a logical next step for a concept you care about and it can fit into the structure of the course, please discuss with me and possibly we can make it fit. Your proposal will still need to have a significant component of prototyping effort, with at least one design iteration; but conceivably these could surround a usability study.

Properties of a good "typical" project:

  • Interesting exploratory objective
  • requires imaginative and appropriate prototyping
  • iteration
  • progress or insights relating to exploratory objective (which could shift)
  • resourcefulness in face of adversity (never fear, you will have an opportunity to exercise this).
  • good (appropriate and effective) documentation

Teamwork: Your team can be a loose or tight organizational unit, as you prefer, but you should share an objective and find an effective way to collaborate. You choose how your team works together. For example, individuals or pairs can try a shared objective independently; or divide the job and take different pieces.

Components / stages:

  1. Project ads (individual, ~ week 3): ideas which teams can form around
  2. Proposal (group, ~week 4): 1 page. Guiding objective, motivation, appropriateness to haptic sketching approach.
  3. Three haptic-sketching iterations (group/individual)
  4. Blog documentation (individual; throughout)
  5. Final report (group, end of term)
  6. Public presentation (exam period)

Project iterations: With your team you will carry out three iterations whose start/end dates are indicated on the course calendar. As you approach each, you will set an objective for that iteration: what do you want to try/learn next --

  • expand your design space; or
  • evolve or refine one approach (each takes concept further, with more detail, functionality, etc.)
  • Evaluate some aspect of your design
  • or, both.

Each iteration will conclude with a class-wide demo / design critique session.

 

 




your project (and lab) blogs

[blog mark scheme] [structure suggestions] [contribution] [platforms]

In 543, you'll describe your labs and project iterations with individual project blogs, regardless of team effort. We do this because the things you're doing are best documented with multimedia (images, video), not just words; and it makes possible sharing of best practices and peer calibration. Individual blogs let the instructor see your own take on things.

What makes a good 543 blog post? Your lab and project blogs have some common and some different objectives. Your lab assignments are relatively structured, and will generally suggest the structure of your post. For your project, you have more discretion; below I suggest some ways you can do it.

For both, tell your story but keep the reader's needs in mind too, with respect to organization and degree of detail. Your job is to convey your goals, technical approach and findings, and lessons learned so the marker can understand what you attempted, how and what you leearned from it. Too little detail, and I'll miss things; too much, and I'll be overwhelmed and unable to extract what's important.

Sample Project Iteration Marking Scheme [pdf]

Read it before you start. It tells you what I think matters.

Approaches to Structuring Your Blog

If in doubt about how to approach this, you'll be well off using tried-and-true technical writing structure - and regardless, please check to make sure you've got all the elements below covered. You build sketches (and certainly iterations) in order to ask and answer a question. While the queston(s) may take many forms, this makes your sketch a small experiments. Talk about it that way. The standard experimental-writeup format is as follows. Depending on the current job, the length and importance of the sections may vary.

  • Motivation -- why do you care? [this may fall out obviously from previous steps, or from the assignment, but if not... state it.]
  • Question / Goals -- what are you trying to learn? What do you need to accomplish?
  • Approach -- how, generally, will you go about answering it? e.g., a variation on somethig yo've tried before; or a completely new direction? What wil be your source of information and answer - other people, or your own opinion about something you've built? Is this to explore a broad direction when you're really not sure fo best approach; or a small refinement?
  • Methods / Procedures -- In detail, what did you do?
  • Results / Discussion -- How did it go; what did you find / learn? Think about factual reporting (Results), versus interpretions (Discussion); try to be clear about which is which. OFTEN, at this point in a sketching process, you may dive right into another iteration. Your choice whether to have sequential procedure/results, or integrate these at iteration levels. What will be most clear and efficient?
  • Conclusions / Next Step: Return to your original question/goal. What is your progress towards that objective? Where does this leave you, and what will you do next?

Your Contribution

I ask (see marking scheme) for you to say something about your personal contribution to a group's work. This doesn't need to be heavy handed, but do include a brief reflective statement. If your group divided up some of the work, say at the top what the division was, including its extent. For components where you worked together, simply say that you worked together on it. I'll assume the effort put in by members was equal if someone doesn't say otherwise. If you feel you had a greater or smaller contribution in particular areas than your teammates (e.g. did less in one aspect but made up for it in other ways), fine to report this. You can also mention what you were able to peer-teach or peer-learn from your partners and other labmates.

Tips and Best Practices

  • Edit. Keep it succint, while providing sufficient detail.
  • Don't expect the reader to extract "themes" or messages - spell them out.
  • Tell reader what to get out of each section right at top
  • Err towads more diagrams, not fewer
  • Keep internal structure consistent when appropriate - e.g., if you try several things during an iteration, give each section subsections for goals, procedures, results, next step).
  • At end of each section, and particularly at end of blog, state again what the reader is supposed to get out of that section.

Blog Platforms

[Update from project intro slides, next course offering]

 

physical user interface design and evaluation 2015/16 W2 -- MacLean