Due: before class on April 7, 2014
- 1 Overview
- 2 Interface Redesign
- 3 Prototyping
- 4 Deliverables
- 5 Report
- 6 Grading
- 7 Presentation (25 pts)
- 8 Submission
In this assignment you will build a working prototype of your interface. You will first revise your user interface ideas based on the evaluation of your low-fidelity prototype from the previous assignment. You will then build an interactive prototype of your revised design using the Android SDK and run it on a real device.
Use the results of your low-fi prototype tests to design a revised user interface. Develop new and/or revised scenarios for your tasks by storyboarding your ideas. The tasks that most of you used in the low-fi assignment should be sufficient for this. However you should update or replace simple or partial tasks that did not adequately cover your proposed functionality. Make sure to revise all of your tasks based on the feedback from your users. If you are making significant changes to your tasks, make an appointment with us to present your new tasks, design ideas, and storyboards for discussion.
Your prototype should implement the three scenarios that you developed for your tasks. The design of the prototype should now start to account for the characteristics of the Android platform (design for the phone's screen resolution, adopt Google's interface guidelines, etc.)
You should implement enough functionality so that a user could adequately evaluate your application. While the underlying functionality does not have to be fully implemented, enough parts should work so that you can ask users to tell you whether or not the application is understandable and usable. For example, an application requiring voice recognition could instead use a wizard-of-oz interface in which a human-operator could manually do the recognition behind the scenes (Note however that wizard-of-oz control often requires special code to be written and that you should avoid hardcoded functionality).
You have a short period of time to complete this prototype, so you should focus on showing only what is essential and try to avoid writing code where it is not necessary. For example, you may wish to skip implementing features such as configuration screens in favor of features that are more central to the user experience. You will likely have to make some difficult choices! Make sure you talk with us if you have any questions about how much of your project you should implement.
Note: You should not consider this interactive prototype to be your final implementation. You will be evaluating this prototype in the next assignment and we expect that you will continue revising the implementation through the remainder of the class.
- Prototype: You must record a video of your prototype and run through all of the features your group has implemented. Since you will have real devices to develop on, think about whether you want to record video of the simulator or a real device. You must also upload operating instructions, including any limitations in the implementation. This information must be posted on the wiki before class on April 7th.
- Report: You must post a copy of the report on the wiki before class on April 7th. You must also submit one copy of a printed report (about 4 pages of text) in class.
- Presentation: On April 7th or 9th your team will present your project to the class, including a demo of your prototype. Presentations will be short and sweet -- 4 minutes per team. Presentation dates have been assigned randomly and can be found at the bottom of this page - contact us ASAP if you have any issues with presenting on the day you've been assigned. Telling the story of your project in 5 minutes is hard -- practice in advance! At most two people from your group should actively speak during the presentation (there just isn't enough time for everyone to speak). Each group's project will then be discussed/critiqued for an additional 5 minutes. Make any slides you use available for download on the wiki as either a PowerPoint or PDF file or a link to an online version such as SlideShare or Google Docs. You will run your presentation from our laptop, not your own machine, to minimize switching time. We strongly recommend that you use Google Docs for your presentation.
- Note: ALL groups must submit their report and prototype before class on April 7th regardless of when they present (you can wait to post your presentation until the day you present). We'll also be asking each of you to evaluate other teams on the days you aren't presenting - your feedback will help them improve their projects and will affect your participation grade, so you are expected to attend class on both days.
The report should follow this outline with separate sections for the top-level items.
- Each team member’s name and role in this assignment
- Problem and solution overview (1 paragraph)
- Tasks (3 short descriptions 2-3 sentences each)
- 3 representative tasks to test your interface (easy, medium, hard)
- Revised interface design (1 page plus screenshots or scripts)
- Changes as a result of low-fi testing and rationale behind the changes (refer to screenshots or scripts).
- Sketches or scripts for unimplemented portions of the interface
- Storyboards of tasks (annotated screenshots or scripts)
- Prototype overview (2 pages)
- Overview of the implemented UI (reference figures or scripts from next section)
- What was left out and why
- Any wizard of oz techniques that are required to make it work
- Documentation of any code not written by the team (libraries used, etc.) - This section may be left out if not applicable
- Prototype screenshots or scripts (as many as needed)
The report and prototype will be graded together, and the presentation will be graded separately. Here is the grading for the report and prototype (60 pts total):
Design (20 Points)
- Tasks (3 pts)
- Do the tasks cover the interesting features of the project?
- Do the tasks have an appropriate difficulty/complexity specified?
- Do the tasks altogether form a compelling story for the project?
- Changes (5 pts)
- Were appropriate changes made to address the important problems discovered?
- Are these changes well illustrated with screenshots or scripts?
- Transition from low-fi to interactive prototype (12 pts)
- Were the limitations of the low-fi addressed?
- Were appropriate constraints from the mobile device considered?
- Were any non-standard interactions described and justified?
Prototype (20 pts)
- Is the prototype accessible and working?
- Can users complete the three tasks with the prototype?
- Were appropriate tradeoffs made between functionality and completeness?
- Are the limitations and tradeoffs described and justified in the report?
Report (20 pts)
- Does the report cover all the topics in the outline?
- Does the organization follow the outline?
- Are sub-sections used for easy scanning of important parts?
- Screenshots and Storyboards or Scripts
- Are important figures referenced and placed inline with the text?
- Are they clearly annotated (i.e. with explanatory captions)?
Presentation (25 pts)
The presentation grading will be broken into two components: a grade for the design of the presentation itself and grade for the information conveyed in the presentation. The grades for each of these components are explained in more detail below. Other students in the class will be grading you and a large part of this presentation score will be determined by them.
Design of Presentation (15 pts)
- Suggested Organization
- Overall problem
- Representative tasks
- Overall UI idea including design changes from the previous iteration, rationale behind changes
- Use slides. Ensure that the presentation shows appropriate preparation, and that visual aids are effective, properly prepared, and properly employed. Try to replace text with images wherever possible. Make sure text is not too small.
- Cover the required scope within the 4 minute time period. Practice and time your presentation.
- Ensure the presenters make eye contact with the audience and speak with adequate volume.
- Team Work
- The most common mistake in CS160 presentations is trying to demo while speaking. One person in ten can do this effectively. Most lose the audience. Even with one person speaking and another one demoing, live demos often go wrong. We suggest you use pre-recorded video instead.
- At most 2 people from your group should speak during the presentation. There isn't enough time to switch between all group members. However all group members should be prepared to answer questions.
Information in Presentation (10 pts)
- Representative Tasks
- Did they provide coverage of the functionality?
- Were the tasks too easy or too hard?
- User Interface
- Was the interface novel and creative?
- Was it appropriate for the supported tasks?
- Does it follow from the task analysis, low-fi prototype, and other sound reasoning?
- Presentation of Functionality
- Was enough functionality presented to illustrate the representative tasks?
- Was enough presented to give a flavor of the interface?
Presentation Dates and Order
- Bearly a Group
- Laser Cats
- Fantastic Four
- Knock Knock
- Pesto Pasta
- Jalapeño Jaguars
- Ninja Narwhals
- Deans of Design
- Survey Parrot
- Tech Transformers
- Gnarly Gnomes
- Rad-ish Undergrads
- Melodious Minds
Giving Presentation Feedback
During each of the two days you are not presenting, you will be assigned to help grade one of the other groups that is. This is an opportunity for you to think critically about the design process and provide valuable feedback to the other students in the class, so take it seriously.
After we have determined the presentation dates for each team, we will post a list indicating which teams you'll be responsible for grading. On the day of the presentations we'll provide you with printouts with which to score other students and give feedback both on their project and on their presentation. The grades you give other groups will be kept anonymous, but your written feedback will be returned to the group.
This will be an individual assignment and will count towards your participation grade for the course. You are expected to come to lecture on both days!
To upload images to the wiki, first create a link for the image of the form [[Image:image_name.jpg]] (replacing image_name.jpg with a unique image name for use by the server). This will create a link you can follow that will then allow you to upload the image. Alternatively, you can use the "Upload file" link in the toolbox to upload the image first, and then subsequently create a link to it on your wiki page.
Hand in Printout in Class
Print your assignment and hand it in at the beginning of class on April 7th.
Add Link to Your Group's Page
Edit your group's page to add a link to a new wiki page for this assignment. The wiki syntax should look like this:
Again replace ExampleGroup with your group's name. Look at Group:ExampleGroup for an example. Then click on the link and enter the information about your assignment. Be sure to clearly address everything mentioned in the writing guidelines above.
Add Link to Your Finished Assignment
One you are finished editing the page, add a link to it here with your group name as the title link. The wiki syntax will look like this: *[[LoFi-Group:ExampleGroup|Group:ExampleGroup]]. Hit the edit button for this section to see how I created the link for the ExampleGroup.
This link and all of the necessary content should be on the wiki before class on April 7th.