This page is designed to help you know what we look for when we are testing a module for usability as well as functionality.

• When clicking on the module in one of the module lists, the configuration window should open up right away. Do all of your startup in a background thread.
• Your module should never cause a crash in the application
• Blatant spelling mistakes
• Save is disabled when not all of the settings are specified.

*Consistency between module names and other terminology in the event/reaction lists, configuration windows and display panel
*Clear and concise error messages printed to Mayhem’s error log when a user tries to do something that is not allowed (i.e. turning on a connection that uses a module that requires an internet connection when no internet connection is present) or when something has gone awry (i.e. a connection that opens a program from a specific location is turned on or triggered and notices that said program cannot be found this message should be printed to the error log)
*Configuration windows should not be able to pass the edge of a user’s screen
*Appropriate, reliable and timely response times for all modules
*Settings and connection state for all modules should be saved when Mayhem is closed and reopened
*Module descriptions should be descriptive and user-friendly (contain as little jargon as possible)
*Module titles and descriptions should remain consistent with pre-existing Mayhem module formats and tense
*If module is configurable, make sure that every option in the configuration window is clearly labeled and explained (if necessary)
*Do not allow for contradiction or confusion in configuration windows (i.e. do not use checkboxes where radio buttons would be more appropriate to allow for only one option to be selected)