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 start-up 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 (e.g. 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 (e.g. a connection that opens a program from a specific location is turned on or triggered and then notices that said program cannot be found [an error regarding that situation 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 responses for all modules
• Settings and connection state for all modules should be saved when Mayhem is closed and reopened
• Module descriptions should be as detailed and user-friendly as possible (contain little-to-no jargon)
• Module titles and descriptions should remain consistent with preexisting 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 (e.g. do not use checkboxes where radio buttons would be more appropriate for the module's functionality)