2015S, Group project 3/4 PD DI Dr. Andreas Riener Due: Friday, June 5, 2015, 10 AM. Last name: Tutor: AR. First name: Group: 1

Transcription

1 Exercise Principles of Interaction, Institute for Pervasive Computing 2015S, Group project 3/4 PD DI Dr. Andreas Riener Due: Friday, June 5, 2015, 10 AM Last name: Tutor: AR First name: Group: 1 Student ID: SKZ: Points (max. 24) Project Overview This term you will undertake a group project (3-4 people) to evaluate a computing-related task/problem, to develop interface design alternatives for the task/problem, to implement a prototype of your design, and to evaluate your design. This project should provide you with hands-on experience with the tasks that interaction/interface designers face every day. We have tried to select a topic for the project that is a problem that matters to some real-life people. To provide some unity and shared understanding across the project teams, there is an overall theme for all projects: CHANGING MY LIFE (subtopics: Bodily sensing, Awareness and control, Health in everyday life, Quantified self, Rehabilitation, Exergaming, Personal fitness coach, Fitness tracking for skill development). The aim or expectation of the project is to finally show a significant difference (e. g., behavior change, change in weight, more calories burned in exercises, etc.) before/after or with/without using your device/application. Think broadly about the theme and the spot that interests you (your group) most it is your problem space for the semester long team project! Each project group will be graded as a team, that is, each person receives the same grade. I will contingently poll team members, however, to make sure that all members are contributing. Lack of participation in-class may precipitate an individual reduction of grade. Within the team, you must negotiate on how much and what each person will contribute. Think carefully about your team members: Where do people live and what hours do they work? Where will you meet? What skills do the different individuals bring to the group (computing, programming, design, evaluation, statistics, etc.)? It would be encouraged to form a heterogeneous team full of individuals with varying skills. The project will include the following phases: P1: Brainstorming and Ideation (Literature review, problem definition, basic concept development (photo traces, video)) P2: Evaluation (Focus group/questionnaire, final concept with time plan) P3: Prototyping/Mockup (Low- or high fidelity, Balsamiq, Wizard of Oz, etc.) P4: Analysis and Interpretation (User study, results presentation, final paper) In further project phases, you will work more on your concept, but don t limit your creativity by thinking (now) about possibilities for implementation. It is completely fine to have parts in your concept that cannot easily be implemented. (In a later stage you will build a prototype and conduct a user study.) Changing my Life: Developing a Novel Concept How well do you know yourself? Page 1 of 8

2 Does exercise lower your heart rate? Does being productive makes you happy? Does a long commute reduces your sleep quality? Does controlled food intake change your weight? Does longer sleeping enhance your grades? etc. Usually we learn about studies related to these questions from the news, e. g. [1] or from other people. These studies are always done on a sample population, usually through randomized controlled experiments. But as every person has different responses and sensitivities, these studies show only that there is some change for some people (but never allow for generalization for all people on earth). In the group project, you (your group) will develop a concept for a device/application to measure dependent variables (which are, of course, also person-dependent) and to put it in relation with independent variable(s). Depending on your solution, you will finally conduct an experiment with one or more users, to see how your concept changes the behavior of subjects by making frequent measurements. Ideally, you find volunteers to take part in the study, and to not test it on one of your group members (as they are biased and, thus, will most likely react as expected...). P3: Prototyping/Mockup points This project phase consists of three steps 1) implementation of the prototype, 2) usability specification and evaluation plan, and 3) technical documentation. Part of this is process (i. e., you learning some prototyping tools and techniques) and part is product (i. e., you actually completing something that can be evaluated). We want to see how you made decisions between your design sketches and your actual prototype... One comment to the timing: In project phase 2(c) it is stated: Develop a time plan based on which you plan to implement your application (final deadline end of June 2015, final report/paper due July-August 2015). For project phase 3 as well as 4 I would like to change this and move the deadlines forward to motivate completion of the project within the summer term (i. e., by June 30, 2015). If your plan as documented in project phase 2 (c) and agreed within your group is to complete later (e. g., July-August) this is still fine. However, in this case, please see your instructor and discuss about deadlines (in particular for project phase 3). (a) 12 points Prototyping In project phase 3 (i. e., prototyping and mockup) you will now take the design that you sketched and planned in project phase 2 and actually implement a detailed prototype of your interface/device/application this part of the project is thus directly based on the previous stage P2! Make use of the results of your survey (questionnaire) and describe/build your prototype on top of your final concept from the project stage 2, task (c) Final concept development. Report any last-minute deviations, e. g., due to unavailability of hardware, etc. Page 2 of 8

3 You can use any prototyping tools that you would like to assist this process (e. g., Programming language tools (Visual Basic, Flash/Director), Software prototyping (Balsamiq), Paper prototype (paper, plastic, Stencils, etc.), Prototyping hardware (Phidgets, Arduino, Raspberry Pi, etc.), Smartphone apps, etc.). The point is that you choose a method, or combination of methods, that allows you to create a prototype at a level that can provide the expected user experience and that could actually be evaluated. Depending on the aspect of your system/device/app you want to evaluate, either a horizontal prototype, vertical prototype, or combination of both might be suited best (motivate and document in your report below!). This may include parts that work using a Wizard of Oz simulation (see lecture material or [1], [2]; remember, the Wizard of Oz technique enables unimplemented technology to be evaluated by using a human to simulate the response of a system). Document the created prototype, (the prototyping process,) and provide the source code of all parts implemented. Draw a figure that depicts the system architecture, or if applicable provide the schematic of the implemented prototype. (This might be an extension/refinement of the basic system architecture drawn in P2.) For the physical design, provide photos, screen grabs or video or something to show that you actually did it, and that document the system and its basic functionality. If these are large or numerous, upload them to a web site and reference them in the document. Note that this is a prototype, still, and not a final application or tool or device. You do not need to implement *** all *** of the functionality. Only enough to get the idea, and enough that you could have users perform representative benchmark tasks with the mockup/prototype... What to hand in? No extra report to be handed in for this part of P3. The points indicated before should go into the technical documentation/report (into sections III, IV; see Figure 1 below). For more details on the technical report/documentation see (c) below. Provide all additional material (scans, photos, system architecture, etc.) as raw files. Further readings [1] Jonathan Lazar, Jinjuan Heidi Feng, Harry Hochheiser, Research Methods in Human-Computer Interaction, Chapter 10: Usability Testing (pp ), 1st edition, 2010, pp [2] Kaj Maäkelä, Esa-Pekka Salonen, Markku Turunen, Jaakko Hakulinen, and Roope Raisam, Conducting a Wizard of Oz Experiment on a Ubiquitous Computing System Doorman, Ubicomp 2001, pp. 8, (PDF provided as supplemental material). (b) 6 points Usability specification and evaluation plan Additionally, you must provide a set of initial usability specifications (see [1], [2] for details) for your system and a plan for an evaluation of it. To develop usability specifications, consider the objectives of your design. For example, if you are working on a new concept for data input on a mobile, you might specify a maximum number of errors that you expect to occur or a maximum time you allow for input a certain amount of text (for reference, see the lecture example keyboard or T9 in the development Page 3 of 8

4 part, taught May 22, 2015). Basically, you should list a set of quantitative/qualitative criteria by which your interface can be evaluated (see the example in Table 1 below; details in [2], [3]). Ask yourself: What kinds of benchmark tasks would you have users perform to help evaluate the interface? What kind of subjective questionnaire would you deploy to have a user critique the interface? Usability Measuring Value to be Current Target Observed attribute instrument measured level level result Initial add appoint- length of time to add 20 secs. (compe- 15 secs. performance ment task appt. on first trial titor system) Initial add appoint- numbers of 2 1 performance ment task errors Table 1: Usability specification table (after [2], [3]). You will need to actually carry out some of this evaluation in the final project phase 4, so you should do your best to set it up now (but you can change later if it appears that the methods described here are no longer feasible). The key at this stage is not to do some exhaustive description of a usability evaluation plan, but to motivate why the particular plan you propose is appropriate for this concrete interface/device/app. Include and describe some quantitative as well as qualitative criteria. Note that developing an initial evaluation plan is also a good way to figure out how much of the interface you actually need to develop/implement. You should be able to build and connect enough of the application functionality to be able to conduct an initial usability evaluation with the benchmark tasks as you are proposing here. Your write-up for this part should include a description of your system prototype. You can include screen dumps to help explain it and text to describe how a user would interact with it. Discuss the implementation challenges you faced. Were there aspects that you wanted to build but were unable to do so? The key component to include in your project report is a justification of why you settled on the design that you chose. What s special about this particular design with respect your problem? The report for this part also must include the usability specifications that you established and a description of the evaluation that you are planning. This need not be too detailed here as the actual evaluation will occur in phase 4. Note that you do not have to actually have someone evaluate it. If you choose to do so, that s also fine (pick a method that you find feasible and document any findings). But, as said, it is not required for project phase 3. What to hand in? No extra report to be handed in for this part of P3. The usability specification and evaluation plan is part of the technical documentation/report created in the last part of the actual project phase and should go into section V. You should include a usability specification table (similar to the example above) for quantitative criteria along with a textual discussion what, how and why you will evaluate your design/device/application. Have again a look on the questions indicated before and the usability specification table (Table 1). Don t forget to include some qualitative criteria (table or textual form) plus associated discussion. Provide additional materials (scans, photos, system architecture, etc.) if any as raw files. Page 4 of 8

5 Note that a usability specification/evaluation plan as requested here is normally not (at least not in this form) part of a technical report/publication. Instead, it is implicitly contained in the evaluation/results/discussion sections. For your final report (phase 4) this means that you will have to remove or revise the information for section V. Further readings [1] Jonathan Lazar, Jinjuan Heidi Feng, Harry Hochheiser, Research Methods in Human-Computer Interaction, Chapter 10: Usability Testing (pp ), 1st edition, 2010, pp [2] H. Rex Hartson, Deborah Hix, Developing user interfaces: ensuring usability through product & process, Chapter 8: Usability Specifications (pp ), John Wiley & Sons, Inc. New York, NY, USA, ISBN: , (PDF provided as supplemental material). [3] John Whiteside, John Bennett, Karen Holtzblatt, Usability Engineering: Our Experience and Evolution, in: Handbook of Human Computer Interaction, M. Helander (Ed.). Elsevier Science Publishers B.V., New York (North-Holland), (PDF provided as supplemental material). (c) 6 points Technical documentation Write an initial version of the documentation to be handed in as final paper at the end of the semester. In the current stage, it will be more like a technical description of your system (with lot of gaps), but it will finally advance to a sort of scientific paper (more about that in project phase 4). The report/paper should include a description of the prototype (see (a) above) and the usability specification and evaluation plan (see (b) above), and surrounded by a technical documentation. Choose yourself which section (I to VI) is best suited for the particular points below. Write up a description of the process of transforming the sketches/design into a prototype. Focus on the decisions you made, why you made them, what criteria and principles you applied. For example, recall some of the many usability principles you have learned did you apply any explicitly and intentionally? Did you make some decisions in your design that you can look back on and retrospectively label as good or not so good, in consideration of the usability? Design limitations. If you had to trim down your design, and only implement part of it, why did you choose what you chose? How did you decide? What would you like to do, if you had more time or different skills? Were there constraints on your creativity or on the usability imposed by the prototyping environment (or of your level of experience with it)? Would these constraints be overcome in a real implementation of the system? How? Why? Documentation of the prototype or mockup. You can include screen dumps to help explain it and text to describe how a user would interact with it. Motivate the prototype and compare it to related work in this domain (depending on how much time you want to spend in this phase, you can hand-in a very coarse, preliminary version or a more detailed elaborated prefinal version as this will be required anyway in phase 4). Describe the basic concept/idea behind your solution/device/application and document the main points of the concrete implementation. The key component to include in your project report is a justification of why you settled on the design that you chose. What s special about this particular design with respect your problem? (A good place for this would be sections I or II). Page 5 of 8

6 Principles of Interaction , 2015S Project 3/4 Due: June 5th, 2015 (10:00 AM) Figure 1: Structure of the final paper (to be submitted with project phase 4). The structure should be already used to report about project phase 3 (...with most of the sections kept empty or preliminary (e. g,. I, II, V) for P3). Page 6 of 8

7 (Note: System evaluation, interpretation of results, and conclusion will be the last part of the project (P4).) Your paper should conform to the IEEE CS conference style template (same format we used for the previous assignments). Please make sure your that your final paper (to be submitted at the end of the semester) is between 6 and 8 pages in length. A sample outline for your paper is shown in Figure 1. What to hand in? For project phase 3, only a single report ( Technical documentation ) needs to be submitted see the item list above as well as the requirements in (a) and (b). Along with the report, submit additional material (photos, scans, screen dumps, architecture overview, source code, etc.) as requested in the different subtasks. Further readings [1] Georgios Varsamopoulos, How to Write a Technical Paper: Structure and Style of the Epitome of your Research, Department of Computer Science and Engineering, Arizona State University, USA, (PDF provided as supplemental material). [2] Aaron Hertzmann, Writing Research Papers, University of Toronto, Dynamic Graphics Project lab, pp. 32, (PDF provided as supplemental material). Homework Submission and Late Assignments All assignments have a deadline by which they should be turned in. All submissions must be made using our electronic assignment delivery system (see introductory slide set in the download area of the course) and by the due date. Late assignments and submissions by are not accepted! A complete hand-in for this assignment (project phase 3) has to include at least: A single report Technical documentation (Word or LaTeX+PDF; IEEE CS format) including all the parts requested in (a) to (c) of this assignment sheet plus additional material (photos, screen dumps, source code, architecture chart, etc.). There is no page limit for this report, however, be aware that the final report (to be submitted at the end of the semester), and which will be based on the actual version, has a mandatory pagination between 6 and 8 pages. Please adhere to the following formatting guidelines. 1. For each assignment (irrespective of the number of files to hand in), submit a single ZIP archive including separate documents as requested in the assignment specification above + additional files (source code, screenshots, figures, videos, etc.). Word or LaTeX+PDF, IEEE CS format, A4, double column. Header area including assignment name, task name, information about you. For group works, the name and details of all involved students should be provided in the document header. 2. It is mandatory to use the IEEE CS format (templates provided) 3. File names of submissions must follow the following structure: Page 7 of 8

8 For individual assignments Assignment number + Student ID + Program code + Lastname +.zip (separated by underscores), e. g., A1_ _938_Riener.zip For group assignments P (for project) + Phase number + Group ID + Chosen group name +.zip, e. g., P1_1_TheCrazyHorse.zip Group assignments should be submitted only once (i. e., one group member uploads the solution of the group)! Don t use special characters and Umlaute in the filename! Page 8 of 8