Table of Contents

Description

There will be one project over the course of the semester. Projects will be conducted by teams of 4–5 students; you are responsible for forming your own teams. Use the #team_formation channel in Slack to help you form teams.

The goal of the project is to perform a piece of new, original research. This can be a study or an implementation.

Study projects

If you want to run a study, it should be on the scale of a CHI Note or Work-in-Progress. You can study something new or replicate a previous study; if you want replicate a study, you must provide good justification for why the prior study needs to be updated. For example, Oulasvirta’s Interaction in 4-Second Bursts study was conducted in the early days of smartphones and a number of things have changed since then that might influence the results of a new study (it’s up to you to figure out what’s changed!).

If your study will involve human participants (and if it doesn’t, you may be in the wrong class), you will need to submit an IRB application. This application requires that you completely think out all of the details of the study, including how you will recruit participants, what the study procedure will be, and whether and how you will compensate them. Talk to me soon so we can determine how best to proceed.

Some ideas for study projects (note that in most cases I have not checked to see whether these have been done already):

  • How do people in cold environments use their phones with gloves? Or, how is touchscreen accuracy affected by touchscreen-compatible gloves?
  • What are people’s long-term experiences with fitness trackers?
  • How do people use phone notifications? How do people use wearable notifications?
  • Replicate Oulasvirta et al.’s Interaction in 4-Second Bursts study
  • Replicate Vadas et al.’s Reading on the Go study
  • Replicate Ashbrook et al.’s Quickdraw study

Implementation projects

Another option is to create something—hardware, software, or a mixture. For this option, you can build on previous research work, but it’s not appropriate to re-implement something that’s been done already.

Some ideas for implementation projects:

  • App for eyes-free music composition while walking (optionally include a hardware controller)
  • Mobile RSVP (Rapid Serial Visual Presentation) on phone, watch, or HMD
  • Accessible eyes-free mobile keyboard with haptic or audio feedback
  • Build a wearable keyboard
  • Build and study peripheral notification
  • Implement a mobile programming environment
  • Address an issue from a prior study; for example, Naftali et al.’s (Accessibility in Context)[http://dl.acm.org/citation.cfm?doid=2661334.2661372], a study of accessibility challenges in the real world

Projects involving hardware

If you want to do a project involving hardware, I will purchase a small amount of hardware for each group, but there must be a clear justification for the need for it and the ability of the group to make use of it (e.g., I won’t buy you something just because it looks cool). I have some resources already available for loan: one Pebble smartwatch, one Samsung Galaxy Gear 1 smartwatch, five Google Glass units, and several Arduinos, including the Bluetooth Low Energy-based Light Blue Bean and the Particle Photon. I recommend the use of The Construct, the on-campus makerspace, which includes 3D printers, soldering facilities, and various other useful tools.

Deliverables

There are several items due at various points through the course; see the right sidebar for the dates. Each deliverable should be turned in via Direct Message to me on Slack. For all items, I expect high-quality writing: check your spelling, avoid passive voice, and proofread (note writing resources on the main page).

Note that I will only accept PDF format for documents!

Proposal

The project proposal should be a well-written document approximately two pages long, consisting of:

  • Project title
  • Group members and detailed roles (see the Advice section below)
  • Project idea, including motivation
  • Planned contributions
  • Plan of attack with weekly milestones (E.g., a rough plan of how you will accomplish the work)
  • Initial literature review (Has this been done before? What prior work is relevant?)
  • What hardware, software, or other resources you might need, and how you plan to get them
  • Success criteria (How will you know if you succeed? I will grade you partially on whether you met your own criteria.)

If you are having a hard time with your proposal, please come to my office hours, email me, or otherwise discuss it with me.

Updated proposal

Approximately 3–4 days after you turn in your proposal, I will give you feedback. You will update your proposal based on my feedback and turn in the new version.

Mid-project check-ins

At two roughly evenly-spaced intervals throughout the semester, you will turn in mid-project check-in documents. These documents are intended to serve several purposes: first, to give you some concrete deadlines to get work done by; second, to get you to self-assess your progress; and finally, to work towards the final paper deliverable.

As with the final deliverable, the check-in documents should be in the format of an ACM SIGCHI Extended Abstract, and roughly in the pattern of a research paper such as those we read in class. Your goal is to make progress towards the final paper; as such, each check-in should be a clearly-written draft paper with at least the following sections:

  • Introduction, including the project idea, motivation, planned contributions, etc…
  • Related work section with more fleshed-out relevant work
  • Outline of body with the approach you are taking
  • Current milestones with progress towards each
  • Remaining milestones with planned progress towards each
  • If changes are made to milestones, explanations of why

At both check-in dates, you will turn in this paper draft; additionally, at the second check-in, you will turn in a draft of your final video (see “Final deliverables” below). The video draft can include parts that don’t require a working prototype (if you are doing an implementation project) such as explanation of motivation, process involved, etc.

Final deliverables

All groups will turn in a final paper describing their project, as well as a short (three minutes or less) video describing the project. The paper must be in the format of an ACM SIGCHI Extended Abstract, and in the pattern of a research paper such as those we read in class. This latter part means that you should not include the milestones sections; the paper should essentially be a draft of something that could be submitted to a conference such as CHI or MobileHCI. The paper must be submitted via Slack, and the video may be submitted either via Slack or a link to a YouTube or Vimeo video.

Each team member must also individually turn in (via a Slack Post) a self evaluation: a short description of your individual contribution to the project, including:

  • What percentage of the work you personally did (0–100%)
  • A description of your own work products (several paragraphs)
  • A description of your collaboration with your team members (several paragraphs)
  • Anything you want me to know about team dynamics and collaboration with other team members, especially any other team members who did an especially good job at contributing

This description is your opportunity to claim credit for the things you worked the hardest on, and to help me judge how you personally contributed to your team’s success.

In addition, you should fill out a final peer evaluation report.

Final presentation

During finals week, each group will present their project to the class in an under-30-minute talk. For groups that implemented something, a demo is appropriate (although not required).

Grading

The project grade will be comprised of the following components:

  • Proposal (2.5%)
  • Updated proposal (2.5%)
  • Check in 1 (2.5%)
  • Check in 2 (2.5%)
  • Final deliverables (20%)
    • Final paper (15%)
    • Video (5%)
  • Team participation (10%)

Group evaluations

At each deliverable (proposal, check ins, final deliverables) you will use the peer evaluation functionality at http://peereval.rit.edu to evaluate your team members. This will allow me to keep track of how well the groups are working together.

Advice

Whether you are doing a study or an implementation, your goal is to focus—focus on what you want to show or find out and the set of work that will get you to that point. As you begin, you will have a difficult time focusing, but I expect you to gain focus quickly. Part of the way to get said focus is to read—read many, many research papers related to your project. Don’t just read the bare minimum required for the class, but look at lots! You don’t have to read everything in-depth, but cultivate an understanding of the area in which you want to do your project and find examples of what you think are successful projects. Those papers will help you understand what focus looks like for that kind of project.

Additionally, for whichever type of project you choose, ensure that your skillset matches the needs of the project. This is not the time to learn to program or to run a user study if you’ve never done those things. Your groups should be balanced so that your skills complement each other and let you complete the project. The detailed description of team member roles should reflect the needed and available skills; e.g., not just “Jane will do the programming and Fred will do the design”, but “Jane did machine learning in her internship with Google and will handle the gesture recognition component of the project while Fred’s experience in HCIN-730 will allow him to design an ethnographic study.”

Hardware

For hardware projects, there are many possible components and platforms to use. I recommend using something that is Arduino-based, as there is a lot of support online for this platform. In particular, the Light Blue Bean is a newer Arduino-compatible platform that supports Bluetooth Low Energy and has a built-in batter, making it nice for wearable projects. Good resources for hardware projects include SparkFun, Adafruit, and SeeedStudio, as well as the Arduino website and forums.

Software

For software projects, there are a number of ways to go. I personally am a big fan of Python, which can use Pygame for simple GUIs and Qt for more complex ones. On the Mac, both of these can be installed via Homebrew. Another option is Kivy, which is a cross-platform Python framework which will let you use Python to create both mobile and desktop apps.

Alternatively, using HTML and Javascript is a feasible approach. Cordova will let you translate applications written this way into mobile apps.

If you need an Apple developer account for this class, please let me know ASAP and I will help you.