Projects - ISU570 Human Computer Interaction

Professor Futrelle, CCIS, Northeastern University - Fall 2008

Version of October 8, 2008

Introduction

Your semester project is far and away the most important piece of work you will do in this course. Because of that, the specifications and requirements for the project are rather detailed. The primary organizing principle for your project is that it should, as much as possible, draw on all of the material in your textbook. The details are described below.

You can get started and be inspired by this list of abstracts of projects done by students in this course in previous semesters.

Project handin schedule

The minimums, for each version are approximately as follows. Each version of the project may include as much of the content of the earlier project versions as you need, perhaps edited and improved, based on the feedback you get, and newer ideas, as you develop them. The requirements for length and figures is significant, so start right away. Be on the lookout for good figures, make your own (camera or cell phone pics) or draw your own.

• Project P1 - Due Wednesday October 15th, by 11:59pm
  Version P1 is to be a short email, e.g., 100 words or so - more is OK.
  It should be sent to Professor Futrelle, futrelle@ccs.neu.edu,
  describing your first ideas about what your project might involve,
  or possibly two different topics, if you can't decide right away.
  You are welcome to make a major shift in your topic by the time you get to your Version P2 handin,
  as well as continuing to tweak your goals as the semester proceeds.
  The earlier you submit P1, the earlier you'll get useful feedback and guidance from me.
  

• Project P2 - Due Friday October 31st at the beginning of class.
  Total: Three pages of text, 1500 words, plus two figures and three references.


• Project P3 - Due Tuesday, November 25th at the beginning of class.
  Total: Five pages of text, 2500 words, plus four figures and five references.
  Includes one page devoted to redesign.


• Project P4 - The final version - Due Tuesday, December 9th at the beginning of class
  (last day of this class for the Fall semester).
  Total: Seven pages of text, 3500 words, plus six figures and seven references.
  Includes a page-and-a-half devoted to redesign.

Overview of your project structure and activities involved

This project has some resemblance to your first assignment, in which you analyze and evaluate some artifacts. But the project will go beyond that in all dimensions, including experimental design and data gathering and including your own ideas for redesign of the systems you study. A key component will be evaluation - it is easy enough to state your own personal evaluation of systems - it is quite another matter to discover how other people use and evaluate the systems you are focusing on. More than anything, you will need to do extensive and careful reading in your textbook to make sure that you have included as many important concepts and strategies in your project as is practical, within the time and effort you have to devote to it. There will be no further assignments in this course beyond your project. On the other hand, there will be some exams covering a variety of important topics from the textbook.

Your "experimental subjects"

You should do everything you can to enlist people to use the systems you are working with so you can observe them, ask questions, have them fill out user experience forms, etc. You may need to give them some little reward such as taking them to dinner or to a movie to show them your appreciation. You should not name your subjects, just age, gender, occupation (typically "student"), as well as some indication as to whether they are or are not familiar with the system(s) you're studying.

You must describe redesigns for systems you study!

Your project will also differ from your past work, because you will take a more active approach. When you carefully study any system, you'll find deficiencies or awkward, confusing, or annoying design. So an important part of your project, especially in the second and final versions, will be to suggest design improvements, and in addition, describe the types of experiments that could be done to compare the new design with the old - does it produce a more successful user experience?

How many words, pages, figures, and references you'll need

Each successive version will include improved versions of what you handed in previously, plus new material. For each version, state clearly how much is old and how much is new - how many more pages, how many more figures, how many more references. You may throw away or radically revise some older material too. That's often a smart approach. For example, you may find better references or figures and replace the old with the new as well as adding a few more. And remember your audience, the people you'll target your reports at - not Professor Futrelle, but other students who might or might not have taken ISU570 (the latter audience is the best bet). A smart move would be to have your reports read by someone else before you finish the final editing of each version, to see if it reads well and clearly.

Develop a user group for evaluation

In interaction design it is rarely enough for a single person to evaluate a system. It should not be difficult to include some friends as evaluators. If you use an online survey, you'll need to decide who to email to alert them to it. You can also ask your friends to email their friends. Survey Monkey allows up to 100 responses, which is quite enough for an evaluation in this course.

Specific points to pay attention to in each version of your project

The following are my notes based on studying project handins in earlier versions of this course. I hope you find them helpful.

1. Title your handins, including "Version xx", whatever is applicable.


2. Organize your paper logically and visually, with sections, section titles, bulleted or numbered lists where useful, etc. Avoid a relaxed and conversational style whenever the issues at hand in more concise writing.


3. Consider using tables in your general introductions and discussions and in presenting raw data and the analyzed data. As just one example, a table could describe your subjects - age, experience, duration of observation.


4. Don't get embroiled in trying to automate much of anything. Wizard of Oz experiments are usually fine, e.g., for testing a messaging system.


5. Don't put references in footnotes. That's common in the humanities, but quite uncommon in scitech fields.


6. When using URLs as references always include additional material such as title, date, author, website name, etc.


7. If you're having your subjects compare a number of systems or artifacts, randomize the order for each new subject to avoid sequential biases.


8. Mixing a number of different objects (systems or artifacts) of study and users with varying experience with the objects can lead to such varied data that it's hard to analyze. Better: Choose one object with varied users or multiple objects with only experienced users or only users who have never used the object before.


9. Use the appropriate technical concepts and terminology and refer to the relevant chapters, sections, or pages of our textbook.


10. You should include references to the HCI literature, discussing the relevance of each reference in a minimum of two sentences each. If you have three or so such references, they should be good enough to deserve a short paragraph for each.


11. Avoid hype about your objects of study. Keep your study objective. You can give an analytic analysis, but the primary evaluative judgments should come from your subjects not you. You can evaluate the results. You can include your opinions, but make it clear that that's exactly what they are.


12. As a corollary, doing your own evaluation of a product you dearly love would be a big mistake. In such a case it would be more revealing to find someone who does not like the product, or strongly prefers another. Then you might be able to learn about the flaws that some perceive.


13. Don't do your final experiments with subjects without first laying out an experimental design, data analysis plans, etc. Your approach and results should be more than anecdotal.


14. A project paper that describes an object in extensive detail, but omits much discussion of your HCI investigation plans is missing too many important things.
    
    

More points to pay attention to

1. Organize your paper logically and visually, with sections, section titles, bulleted or numbered lists where useful, etc. Avoid a relaxed and conversational style whenever the issues at hand in more concise writing.


2. Consider using tables in your general introductions and discussions and in presenting raw data and the analyzed data. As just one example, a table could describe your subjects - age, experience, duration of observation.


3. Don't get embroiled in trying to automate much of anything. Wizard of Oz experiments are usually fine, e.g., for testing a messaging system.


4. Don't put references in footnotes. That's common in the humanities, but quite uncommon in scitech fields.


5. When using URLs as references always include additional material such as title, date, author, website name, etc.


6. If you're having your subjects compare a number of systems or artifacts, randomize the order for each new subject to avoid sequential biases.


7. Mixing a number of different objects (systems or artifacts) of study and users with varying experience with the objects can lead to such varied data that it's hard to analyze. Better: Choose one object with varied users or multiple objects with only experienced users or only users who have never used the object before.


8. Use the appropriate technical concepts and terminology and refer to the relevant chapters, sections, or pages of our textbook.


9. You should include references to the HCI literature, discussing the relevance of each reference in a minimum of two sentences each. If you have three or so such references, they should be good enough to deserve a short paragraph for each.


10. Avoid hype about your objects of study. Keep your study objective. You can give an analytic analysis, but the primary evaluative judgments should come from your subjects not you. You can evaluate the results. You can include your opinions, but make it clear that that's exactly what they are.


11. As a corollary, doing your own evaluation of a product you dearly love would be a big mistake. In such a case it would be more revealing to find someone who does not like the product, or strongly prefers another. Then you might be able to learn about the flaws that some perceive.


12. Don't do your final experiments with subjects without first laying out an experimental design, data analysis plans, etc. Your approach and results should be more than anecdotal.


13. A project paper that describes an object in extensive detail, but omits much discussion of your HCI investigation plans is missing too many important things.

The breadth and depth of what you will study in your project

Most importantly, here is an extensive list of abstracts of projects done in this course one year ago. And here are some additional examples:

• If you study remote controls, you would need to study at least six different ones, from TV/DVD controls, to game controllers, and even a swipe card.


• If you study a system like the Charlie Card system, you would have to track down and discuss other fare and ticket purchasing systems, such as airlines, Amtrak, and include accessibility provisions. Many major cities, including Boston, New York, Washington, Chicago, San Francisco, and London, have such systems. So part of the task would be to find out as much as you could about them, even emailing for info or having a friend who lives in one of the other cities help you out.


• For online stores, you'd need to compare different sites, as well as meta-sites (that compare prices from many stores), and auction systems. You could focus on a genre, such as building supplies or books, or compare distinct genres and how the approaches differ.


• For human-like agents online, you'd need to find and interact with a number of different ones


• For software systems, such as a drawing system, you would need to compare at least three quite different ones, with special attention to ones that are focused on drawing specific types of things, such as architectural plans, UML diagrams, and network and organization charts.


• For PDAs such as MP3 players, you would need to find people that own and use a variety of them. Devices such as Blackberries are a related category.


• A hybrid system is a self-bagging system such as the ones available at Home Depot and other stores. But you'd need to study more than just one.


• The list goes on and on ....

The literature describing your topic

In virtually every case, there will be literature describing the background, history, and current status of the systems you are studying. Some of it will from the HCI research literature. You'll need to track it down and discuss it. In addition, many systems have user guides and built-in-help that you'll need to discuss. You may need to have a system in front of you and write down what it looks like or explains. For a system such as self-bagging there is always an attendant nearby to help with difficult or confusing aspects of the system, ditto the Charlie Card (at least for now).

The material in the textbook that can be discussed in your project

In the list below, I list every chapter, with a brief note about how it could contribute to your project.

• Chapter 1: The design must create a successful user experience.


• Chapter 2: You need to describe the underlying design space and how it is conceptualized.


• Chapter 3: How do people see, think, remember, learn, and act when working with an interactive system?


• Chapter 4: Many systems today have a social basis, not just a single, independent user. The systems you study will probably have components of this - even if it's just the Charlie Card attendant, or other users who make suggestions, point out things, or describe problems and solutions in discussions you might have with them.


• Chapter 5: Emotions are crucial in interactive systems. You don't "like" or "dislike" a system on purely logical grounds.


• Chapter 6: Interfaces in computers, PDAs, remotes, and much more are the all-important "face" they present to the user.


• Chapter 7: You will need to gather data for your evaluations, so pay careful attention to this chapter.


• Chapter 8: Once your data is gathered, you'll need to analyze it and present your results and the conclusions you draw from it.


• Chapter 9: This describes the process of design, something you are required to do in your project - typically a redesign of something. Often some modest changes are enough.


• Chapter 10: When you design, you have to have some ideas about what the system is supposed to accomplish, and what the user would like to see.


• Chapter 11: You should consider prototyping your redesigns, at least in drawings and descriptions, since you're typically not building real things. (You're welcome to hand in a 3D model in Lego, clay, cardboard, or whatever ;-)


• Chapter 12: Evaluation is key. Without it, you just don't know whether a system has succeeded in its purpose. (In research proposals we submit, e.g., to the National Science Foundation, if there is no proper section on the evaluation of results, chances are you will not be funded.)


• Chapter 13: DECIDE is a framework to guide evaluation. DECIDE is an acronym for six steps in one standard approach to evaluation.


• Chapter 14: Usability and field studies are an important part of many Interaction Design projects. For example, you could hang out near a Charlie Card station or Home Depot self-bagging checkout location and observe how people do and don't succeed in using the system comfortably. Talk to the attendants about what the problems they've observed that users have most often.

Return to ISU570 Fall 2008 homepage. or RPF's Teaching Gateway or homepage