Module Requirements

Information on this page recaps the module process and elaborates on the requirements needed to advance a module from one version to the next, including an explanation of Project Links alpha and beta testing processes. (The Module Development Process page provides more background information for new developers.)

Overviewtop of page

In a nutshell, Project Links' module development process involves several dynamic stages, each including interaction and dialog with various people. These stages don't always follow the same order, and some steps may be completed simultaneously:

  1. Completion of the Module Design Questionnaire
  2. Completion of detailed Module Storyboards, and Applet Storyboards
  3. Review by the Technical Manager and Authors
  4. Alpha Testing in House
  5. Edits, changes and improvements
  6. Beta Testing in House
  7. Edits, changes and improvements
  8. Content Review
  9. Edits, changes and improvements
  10. User Interface and Educational Technology Review
  11. Edits, changes and improvements
  12. Student Usability Testing
  13. Edits, changes and improvements
  14. Pilot Testing in Classrooms
  15. Edits, changes and improvements
  16. Utilization in Multiple Classrooms and Sites
  17. Final edits as necessary

To help developers, testers and programmers keep track of all these stages, we have version numbers and guidelines that correspond to modules in varying stages of development (the stop light icons, also described on the Version Key page). The status of each module can be found on the Status Chart--clicking on the DONE under any of the testing columns will give a detailed status page for that module, including the date tested and the list of suggested changes from the reviewer(s).

The DONE classification will be upgraded to PASSED only when the changes have been incorporated to the satisfaction of the developers, the technical manager and reviewers. (i.e. just because a module has been tested and "DONE" it does not automatically get upgraded to the next version).

Version Definitions and Requirementstop of page


Version Definitions

Versions 0.0 to 0.4 consist of modules under development (in varying stages, obviously a 0.4 version will be farther along than a 0.0 one). The interface designer won't comment on them unless specifically asked to do so. However, questions about design implementation, organization and using the template are always welcome.

Version 0.6 = module is in current Links format (see template) and ready for internal alpha and beta testing. The interface designer will comment freely and often on these modules as suggestions are implemented and updates are made. Expect a lot of changes and dialog with the interface designer and technical manager at this stage.

Version 0.8 = module has passed the alpha and beta testing and is ready for external evaluation. The interface designer will review this module primarily for fine-tuned copy-editing purposes--checking spelling, grammar, looking for any broken links, etc. The external evaluators will evaluate content, educational technology and usability. Expect a lot of module tweaking and dialog with the technical manager and external reviewers at this stage.

Version 1.0 = module is released for public use. Changes, updates and improvements can still be made on Version 1.0 modules: think of them as a First Edition.

Version Requirements

To move from version 0.4 to 0.6 the module must:

  1. use the Links format.
  2. make logical use of the navigation: the side navigation frame represents content, and the top navigation represents functionality (content = ideas/major points of a lesson, functionality = interactivity and elaboration). Any questions about the differences should be asked to the interface designer or the technical manager asap!
  3. have content and links more or less complete (no "insert image here" type notes).

To move from version 0.6 to 0.8 the module must:

  1. incorporate the comments and suggestions from the alpha and beta testing to the satisfaction of the interface designer, technical manager, and the developers. This stage may take weeks or months, depending on the comments. Modules may be alpha and beta tested a number of times during this period. Again, any questions or concerns should be voiced to the interface designer and/or the technical manager asap!
  2. be blessed and proclaimed version 0.8 by the technical manager.

To move from version 0.8 to 1.0 the module must:

  1. incorporate changes suggested by the content, usability, and educational technology testing to the satisfaction of the technical manager and the developers.
  2. incorporate any changes suggested after final copy-editing to the satisfaction of the interface designer, technical manager, and the developers.
  3. be confirmed and elevated to version 1.0 by the technical manager (formal ceremony optional).

Alpha and Beta Testingtop of page

Alpha testing:

The interface designer will check modules on all platforms and browsers for broad editing, aesthetic and usability issues. Review includes checking for:

Beta testing:

The interface designer provides a fine-toothed copy-edit for: grammar, punctuation, misspellings, broken links, broken applets, etc. Beta testing also ensures that the design and usability look good and work smoothly--we want the outside evaluators to pay attention to the content and lessons, not get caught up in technological glitches.

home

Copyright © 1998 Rensselaer Polytechnic Institute. All Rights Reserved.

info@links.math.rpi.edu ... Last Updated: