Project 4: Lifelogging
The final project theme continues what we have been thinking about in P2 and P3 – Lifelogging: Mobile and Online Sensing for Public/Private Good. For the rest of the quarter you will iteratively design, prototype, and evaluate a new lifelogging service.
Several factors are important in thinking about your project:
- User-centered design. Your application should meet a real-world need identified through your observations and experience. You may wish to engage in additional interviews or observation to inform your project's development. Make sure your choice of target users is realistic for the course. Designing for astronauts sounds great, but it may be hard to evaluate to evaluate your designs if you don't work for NASA. Pick a problem and demographic that you might meaningfully engage (and possibly that you yourself belong to).
- Human context. We want this project to have a plausible story about the people who would use it, the benefit they would get from it, and the way it would fit into their lives. This includes testing your prototypes with users who are representative of your target audience.
- Mobile and/or online sensing. One goal of the project is to get you engaged with the possibilities and pitfalls that surround the incorporation of mobile and online sensing into our daily lives. As such, you must incorporate some sensing component into your project. This might include use of a device's on-board sensors, adding new peripheral sensors (e.g., air quality monitor), pulling data from online services, or having users self-report information (e.g., through user-initiated data entry, photography, audio recording, etc – though you might also consider having the device proactively request such information at appropriate times). A fun challenge to consider is how you might prototype some of these sensors to evaluate them prior to committing to a full-blown implementation.
- Functional implementation. As a computer science course, one goal of CS247 is to realize your design in a working system. The primary steps are paper prototyping, implementing an operational software prototype that illustrates and tests some aspect of the larger picture, user testing that prototype, and then refining that prototype into an improved, deployable system.
Activities and Deliverables
The final project is organized into iterative cycles, with feedback from testing in each. We will be talking about the processes in class. We will have a set of major milestones, roughly at one week intervals. We will also ask your team to send us a statement each week of what you completed in the past week and what you intend to achieve by the next week.
Tu 1/25 | Form project teams and choose your project problem area (not any intended design solutions!). Enter your team name and members using the provided web survey. We will be brainstorming concrete design ideas in class Tuesday. |
Th 1/27 | Be prepared to present your project idea and envisioned solutions for group critique and feedback. No PowerPoint allowed! Use physical props or posters to communicate your ideas. |
Tu 2/1 | Complete (and email to cs247@cs) a project plan: create a schedule mapping out your project goals for the rest of the quarter. Your schedule should include time for ideation (generating multiple design alternatives) and recruiting users for user studies, in addition to implementation milestones. Interview, and then user test, early and often! You should also consider how to support collaboration among team members – for example, use resources such as Google Code for version control, a team wiki, etc. We recommend that you put your project plan on a group wiki and then email us with a link to that page (and make sure we have read access!). |
Th 2/3 | Completion of paper prototype demonstrating your primary usage scenarios. We will perform low-fidelity user tests in studio. |
Th 2/10 | Make significant progress on your "alpha" prototype. Be sure to send in your project progress and goals for the coming week (email cs247@cs). |
Th 2/17 | Completion of a functional "alpha" prototype. Not all envisioned features need to be implemented, but your central usage scenario should be possible with the application. Next, refine your prototype further. You should be able to "eat your own dogfood" by using your application the next week. |
Th 2/24 | Completion of a functional "beta" prototype. Use insights gained from your own usage to iterate the design. By Feb 25, recruit representative users from outside the class to serve as trial users for your app; interview them after a week of usage to gain feedback on your design. |
Th 3/3 | Results from user testing due, including a prioritization of improvements to make in your next iteration. |
Th 3/10 | Completion of a "release candidate" prototype. Test run of your final project presentation (1 minute pitch + 5 minute demonstration). |
For more details about the final deliverables, please see this page.
Teams
P4 must be done in teams of 4 to 5 people. We will have an in-class exercise on Thursday Jan 20 to assist with team formation. Your team composition and problem area should be finalized by Tuesday Jan 25.
Grading
20% | Process - Are you following design processes that are appropriate for your application area? |
40% | Solution - Does your design work for your intended users? |
25% | Implementation - What is the quality of your implementation? Is it appropriately polished, robust, and reliable for your chosen problem? |
15% | Presentation - Are your final presentation and demonstration clear, engaging, and effective? |