Q13: User-Testable Prototype

Table of Contents


Objectives

  • Continue working as a guild.
  • Develop a complete and playable scenario.
  • Make significant progress towards meeting the final requirements of the project.

Academic Honesty

Read the Scholastic Honesty Policy and Assignment Integrity policies of the syllabus. Here are some clarifications for this particular assignment:

  • You are expected to work with your guild to develop a complete and playable scenario.
  • Do not copy code from the Internet or other sources without attribution. You may use helper classes from other sources, such as the instructor or Internet, but must attribute the code to the originator. Copying code snippets from the instructor's lesson examples without attribution is allowed.
  • Within your guild, you are expected to help each other develop code, artwork, music and sound according to your abilities.
  • However, you must type all the code for your subsystem and not copy or modify it from another source. You may get help from your guild members if you get stuck. However, you must be able to explain and reproduce all code within your subsystem.
  • You may get help from people other than your guild members if your guild members cannot help you, but only if they do not show or tell you the code to type. Instead they should show you other examples that you can adapt to your code.
  • You may get help from people other than your guild members on non-code aspects of the project but must attribute their work.

If you get stuck, take a break and come back to it later, talk to the professor, or ask a guildmate for help. Remember, do not allow anyone to type Java code for you or show you Java code to copy. Instead the person helping you should show you techniques using other examples that you can adapt.

User Testable Prototype Specifications

At this point you and your guild should have a complete and playable scenario ready for user testing. Some final touches, like opening screens, may be absent, but the scenario should be complete and playable. Also, each guild member must have made significant progress towards meeting the requirements of their subsystems, including originality. We will use this prototype to provide feedback on the project from a user standpoint.

Note that solo subsystems must be incorporated into the guild scenario and all members of the guild must turn in the same user testable prototype.

Solo Requirements

  1. The central or most important classes of your subsystem must exist and function well in the scenario.
  2. Your subsystem must have one or more functional classes with at least one private instance variable and method besides act() that you coded (or more to meet originality requirements).
  3. At least one of your subsystem classes must contain a private static GreenfootImage array for caching of images to produce animations.
  4. The same class as solo specification 3 must contain a static method named initializeImages() that you coded to load images and to populate the GreenfootImage array.

    Document which files contain the initializeImages() method in the README.TXT file.

  5. At least one of your subsystem classes must directly play at least one sound.
  6. Every one of your classes must have a file comment block with your name in the @author field. If there is more than one author, list the primary author first followed by a comma. For example:
    /**
     * Superclass of projectiles.
     *
     * @author Ed Parrish, Emma Programmer
     * @version 1.0  11/07/2015
     */
    

    If you do not put your name on your work, you may receive no credit. Do NOT put your name on classes you did not write.

  7. Document the percentage completeness of the classes in your subsystem, and any others for which you are responsible, for inclusion in the README.TXT.

    For any class that is not complete, add a brief explanation of the status like:

    -Jane: the user-controlled character (80%)
    --Need to add throwing controls
    

Guild Requirements

  1. All guild member subsystems have been incorporated into the scenario.

    If a guild member's code is not available, make certain their name is still listed in the README.TXT file but with an N/A for project files.

  2. Scenario functions well as a whole without errors.
  3. Scenario has user interaction.
  4. Non-player characters are included in the scenario
  5. All classes have a file comment block with the @author field filled out.
  6. README.TXT file (Scenario Information) contains the Greenfoot supplied labels PROJECT TITLE, AUTHORS and USER INSTRUCTIONS with their associated information. As AUTHORS, put the guild name.
  7. README.TXT file lists the project subsystems, responsible guild member (first and last name) and the class files for which the guild member is primarily responsible, along with an estimate by the guild member of the percentage complete.
  8. Setting up at least three test stations for user testing of the scenario.
  9. Providing at least three copies of the printed instructions during user testing.

Here is an example of a full credit user testable prototype with classes implemented for all subsystems: platformer-upt.zip. Also, here is a link to the README.TXT with status. Class names may have changed from the proposal and not everything must be implemented. However, it is still a testable scenario showing good progress for all guild members.

During class when testing occurs, each guild will load their scenario onto several classroom computers. During class students from other guilds will read the written instructions for and try out other guild's scenarios. Your guild, as the developer, cannot tell the user what to do or make suggestions to the user. The user who is testing your scenario will fill out a User Test Report which evaluates your scenario and offers suggestions.

Notice that missing class for the user testing will result in a low score on this assignment. User testing is a major part of the grade for this assignment.

User Testable Prototype Extra Credit

The following are worth extra credit points:

  1. Implement a scrolling world for the scenario as described in the lesson and show it in-class during user testing. This is a guild extra credit and applies to all guild members equally. (2 points)

Grading Criteria

The instructor will evaluate your assignment using the following criteria. Each criteria represents a specific achievement of your assignment and has a scoring guide. The scoring guide explains the possible scores you can receive.

Some scoring guides have a list of indicators. These indicators are a sign of meeting, or a symptom of not meeting, the specific criterion. Note that a single indicator may not always be reliable or appropriate in a given context. However, as a group, they show the condition of meeting the criterion.

For information on grading policies, including interpretation of scores, see the syllabus page.

Solo Requirement Checks

  • 8: Assigned subsystem(s) looks complete and functions without error during user testing.
  • -2: None of your subsystem classes are instantiated in the scenario.
  • -2: One or more of the central or most important classes of your subsystem are missing or does not function without error during testing.
  • -2: One or more of the central or most important classes of your subsystem does not function well or causes an exception.
  • -2: Missing a private instance variable and method besides act() within your subsystem that your wrote.
  • -2: Missing a private static GreenfootImage array for caching of images to produce animations.
  • -2: Missing a static method to load images named initializeImages() that you coded.
  • -1: No subsystem class plays a sound.
  • -2: No subsystem class has a file comment block with your name in the @author field.
  • -1: Some subsystem classes does not have a file comment block with your name in the @author field.
  • -1: README.TXT file does not document the percentage completeness of one or more of the classes in your subsystem as well as a brief comment on the status for those that are not 100% complete.

Guild Requirement Checks

  • 4: Scenario looks fairly complete and functions without error during user testing.
  • -2: Non-player characters are NOT included in the scenario
  • -1: One or more classes does not contain a file comment block filed out in the specified format and with a name in the @author field.
  • -2: README.TXT file does not list the project subsystem name, responsible guild member (first and last names), and class files for one or more guild members.
  • -1: README.TXT file missing an estimate by a guild member of the percentage complete.
  • -1: README.TXT file (Scenario Information) does not contain the labels PROJECT TITLE, AUTHORS and USER INSTRUCTIONS with their associated information.
  • -4: Did not particiate with your guild.

Setup and Instructions (Guild)

  • 4: Three user test stations setup, each with a copy of complete, clearly-worded and printed (not hand-written) instructions provided on paper.
  • -4: No user test stations setup during allotted time.
  • -3: No test instructions provided either on paper or screen.
  • -2: Not all user test stations were setup during allotted time.
  • -2: Instructions were not provided on paper.
  • -1: Instructions displayed were hand-written rather than printed.
  • -1: Instructions were not clearly worded.
  • -1: Only one copy of the instructions was provided.
  • -4: Did not attend with your guild.

User Test Report (Guild)

  • 4: A student not in your guild completes a User Test Report for your project.
  • 0: No User Test Report completed for your project or did not participate with your guild.

Maximum Score: 20, plus extra credit

How to Submit

Submit means that you are presenting your work for consideration and grading. Follow these instructions carefully and exactly to turn in your quest (assignment) and maximize your XP:

  1. Choose one person in your guild as the "leader" who will submit the final project from which everyone is graded.
  2. The leader ensures that all the parts are combined correctly, zips the folder and submits the project.

    Do NOT submit solo versions of the project as the last submission will be counted as the final version for the entire guild. Submit only the latest version of the project--NOT old versions.

  3. As a guild or guild leader, submit the project following these steps:
    1. Create a folder named "project" (no extra characters) and place your User Testable Prototype into this folder.
    2. Outside of a folder, include your instructions document in plain text (.txt), Word (.doc) or open standards (.docx) format.

      In addition, bring three paper copies (as a guild) of the project instructions to class for your three guild prototype stations.

    3. Create a zip file containing the project and instructions file, and submit the zip file to the Q13: User-Testable Prototype slot of Canvas.

Please do not put any spaces or special characters like #, : or $ in zip file or folder names. Your assignment must work as submitted. Remember to test and double check your files before submitting them. If you make a mistake, you can resubmit up to the deadline but must resubmit all your assignment files.

Home | Canvas | Schedule | Syllabus | Room Policies
Help | FAQ's | HowTo's | Links
Last Updated: May 14 2017 @02:15:24