A6: Ready for testing - due Thursday, 11/10, 11:59pm

Brief

Crunch time! Your interactive webpage prototype needs to be ready for user testing by the end of this week.

Step 1: Complete Functionality

By the end of this week, your app should be completely finished and functional in terms of interactions (don't worry about finalizing visual layout and styles). If you're not on track to finishing, it's time to step up the pace.

Your app should now be able to save data inputted by the user in JavaScript variables within your Node.js server app, which serves as a fake-'database'. (This data will be persistent only until the Node server restarts, so there is no need to set up a real database.) Note that you can use a real database if you want, but it is not a requirement for this course.

Your app should also have a working account and login system if it requires user accounts (but it can be simple, so don't go overboard with complexity here since it's not the most interesting part of your app ... e.g., if you want to put fake usernames/passwords in your data.json file, that's fine).

Your app should have several pages where users can submit and view data (stored in JavaScript variables within Node.js or as JSON files such as data.json -- see Lab 5, or in a real database). Use the feedback you received in studio to help determine what changes or improvements to implement. Remember, we are not at the "making it pretty" phase yet, so don't spend time on aesthetics unless all other components are already complete. Your user testing results next week will be much less insightful if your interface is still half-finished and buggy. So focus on finishing the interactions.

If you are creating a mobile web app, now is also the time to make sure your app fits into a mobile form factor, use Google device mode to help with this , or test on your own mobile devices.

Step 2: Develop a Protocol

For A7, you will be testing your app with real users. In preparation for next week, you will develop a protocol for testing your app. You will be using this protocol to do user testing throughout next week.

Protocols, or "usability scripts," help keep tests consistent across testers and facilitators. It gives exact, step-by-step instructions on how to test a user, often down to the exact words that the facilitator will say. Write a user testing protocol that covers:

  • Preparation and setting up
  • Gaining informed consent using this form
  • Executing the test, identify who does what
  • Written instructions that you will read to the testers, and any other materials (e.g. questionnaires, interview questions) that will be used during the user testing session
  • How your observations will be recorded
  • Debriefing the tester and a team debrief

Your protocol should be ~1-2 pages.

Step 3: Update Development Plan

Follow the development plan you created last week, and update it as you go. Mark tasks that have been completed and add new ones if you need to. Make sure that your next week is planned out with goals and who is responsible for each task. Be sure to add tasks for future weeks as well.

Student Examples

Here are some examples of development plans. If you want, use File -> Make a copy... to copy over the formatting for each spreadsheet to form the basis for your own plan.

  • (1) is very stylized, dynamic, and mostly thorough,
  • (2) is fairly thorough, colorful, but is missing time estimates and has only one stretch goal listed,
  • (3) is a mediocre plan that's mostly thorough, where most tasks are broken down into less than 1 hour chunks,
  • (4) is very thorough, with time estimates and time costs, but some tasks could be more actionable,
  • (5) is a great video of the dynamic nature of implementation plans throughout the project.

GradeSource++: This example project from last year abstracts GradeSource for you and works with the data to show you where you are in a class.

Balancr: This app helps people balance their time between work and play. They have done a wonderful job making the app functional-- you can create a sign-up, add activities, and see it reflected on the pie chart.

For both examples above, the data that undergirds the functionality of the apps are pre-populated and updated from JSON. For instance, login information should be stored as JSON. You should have a pre-canned user that is persistent, and the ability for creating a new user whose credentials will be stored in JSON for the duration of the session. Look to Lab 6 for the necessary machinery to implement this.

Team Submission

For this assignment, ONE person will submit the assignment for their team, listing every team member's name and student ID number (PID) in the assignment submission.

Your write-up will contain the following in one single PDF:

  • The URL of the app prototype that you want us to see and grade. Note: the URL must work at least until your assignment is graded. If it doesn't work, you'll receive no credit. Very important: the contents of this URL should not change in the upcoming week while your TA is grading this assignment, or else that is a violation of the academic honesty policy; test your new changes at a different URL. Also, if you are doing a mobile app, let us know which mobile platform you have tested it for: Android, iOS or mobile emulator on Chrome or some other browser (Functionality, Data/Templates, Mobile Design)
  • The shared GitHub URL for your project, your JSON filename, and the filenames of webpages that use templates to render data from JSON. (Data & Templates)
  • The protocol to test users for A7 and the blank consent form you will be presenting to users. (Develop a protocol)
  • The PDF of your development plan that you submitted last week for A5. (Look up how to join multiple PDFs into one single PDF submission.) (A5 Development Plan)
  • The PDF of your updated development plan. (Look up how to join multiple PDFs into one single PDF submission.) (Updated Development Plan)

Note: since we may grade your assignment up to a few days after submission, per the honor code, we expect that the prototype URL show the state of your prototype at the time of submission. You will very likely be updating your prototype after submission, but please do so on a separate URL.

Submit your single formatted PDF in Gradescope.


Evaluation criteria & Grading rubric

The rubric below contains criteria that are worth one point each and will be graded independently and in a binary fashion.

  1. Prototype is at least somewhat functional in a non-trivial way.
  2. Prototype is fully functional.
  3. Prototype is free of major bugs and ready for user testing.
  4. While not fully polished, the overall look and feel is reflective of the final prototype.
  5. Prototype's interaction flow is easy to understand. First-time users can go from screen to screen and know what functions they can perform.
  6. All of your code is publicly viewable on GitHub.
  7. Your code uses templates to render data from a JSON file or (optionally) a database rather than copying & pasting hand-written hard-coded HTML into multiple files.
  8. Protocol gives step-by-step instructions on how to perform the user testing; it could be used by another person to reproduce the same user test.
  9. Protocol includes "scripts", which include the exact words that a facilitator would say to the participant, to ensure consistency across all tests.
  10. Protocol is well-designed. It is clear why specific steps are taken & the instructions and scripts do not bias/lead the user in one particular direction.
  11. Protocol plans to test a completed feature of the app that contributes meaningfully to the app's overall goal.
  12. Development plan is included as a PDF, is easy for your TA to read and understand, and has been updated to show progress and additional tasks in the new version compared to the previous week.
  13. Extra credit (up to 4 points) - In addition, your TA can give your team up to 4 extra credit points if your app is extraordinarily polished by this deadline, which provides an incentive to get work done early and to go above and beyond the basic requirements.

Due with assignment (no studio this week): Self Assessment

During studio, click here to self-assess your team's work as a collective unit.


Due with assignment (no studio this week): Teammate Assessment

During studio, click here to assess how each of your teammates contributed to this assignment.