How can you help?

Shodor > CSERD > Help > How can you help?

  • Ask and answer questions in the forum.
  • Review material in the catalog.
  • Add items to the catalog.
  • Submit modules to be included in CSERD's resources.
  • Submit in depth verification, validation, and accreditation reviews.

In addition to the prestige of having your materials featured in our site, we will track the participation of users. Reference desk participants will be scored on a point system (1 point for each forum post and 3 points for each catalog review or entry. Points for submitted modules that are accepted for publication will be higher, and determined on a per case basis). At 50, 100, and 250 points participants can be considered for promotion to bronze, silver, or gold status respectively. If your promotion is approved, we will send a letter to the administrator of your choice informing them of your academic contribution to CSERD.

I think I/my student could review some of the tools here, how would I/my student do that?

At CSERD, we strive to make sure to bring you educational materials that are reliable and usable. How do we do that? We get you to help us review the material in our catalog! We feature different levels of reviews, realizing that different users have different needs and experiences. Have specific technical information on how the materials run? Consider submitting a verification review. Are you a content specialist who has something to say about the correctness or incorrectness of the information presented? Consider submitting a validation review. Are you using the materials in the classroom and want to say something about their appropriateness for classroom use? Consider submitting an accreditation review. Just want to say a few words? We've got a forum for user feedback on catalog items too.

Review Types

There are two main types of reviews, free-form reviews, and structured reviews. Both types allow the user to state preferences, include mistakes or errors with the information, and include any likes or dislikes about the information and its format. The review types do have quite a few differences though.

1. Free Form User Comments.

These reviews are submitted and are posted in the forum. These reviews are in paragraph form and are usually opinions about the software, but can also include factual data about the usefulness and accuracy of the information.

2. VV&A Reviews

VV&A reviews, or verification, validation, and accreditation reviews, are a more structured way of reviewing the information on CSERD. This type of review proves most helpful when examining the "usability" of an item. Someone looking through can clearly see any errors, problems, drawbacks, or strong points of the material. The reason this can be done so clearly is the information input in these reviews is all formatted to allow for quick, efficient, and yet in-depth reviews.

2.1 Verification

Verification is the demonstration that the model is logically correct and follows from the physical and mathematical laws used. For a computer simulation, verification shows that the specifications are fulfilled and that the model will run on the computer system of the educator and student as specified. Scientists and technologists will be involved in the verification review process however even someone totally unfamiliar with the information the material covers can supply verification information. Verification includes things based on how the material displays, if at all. If on a computer with a certain browser and a certain platform a model cannot be displayed, a verification review along with a bug submission would help resolve the issue. Additionally, if the directions are not easy to follow or are ambiguous and confusing to follow, a verification review would be the best thing to submit. In some cases people that know nothing about the material are the best people to fill out verification reviews since scientists and technicians rarely need the directions to figure out how to use a tool.

2.2 Validation

Validation is the demonstration that the model correctly predicts the phenomena modeled. This ensures that the model is based on good scientific methods and principles. This type of review should be submitted by those who are very familiar with the science behind the material, since they will be asked on what scientific facts, theories, equations, or findings they are basing their observations.

2.3 Accreditation

Accreditation is the act of showing that the educational purpose of the model or simulation is achieved. This includes relating the object to the K-12 standards, identifying assessment criteria, and grade level. Educators will be involved in the review process. Who is the information useful for? What field of math, science, or technology would the material fall under? How should the information be used and applied to aid in learning? These, and other such questions are answered in the Accreditation portion of the review. Although reviewers choosing to submit an Accreditation review should be familiar with the material, it is more vital that they have experience in applying material in an educational setting so they know when information is useful and applicable, and when it is not.

That module creation thing sounds like something I/my student would like to do. What types of modules do you accept?

We are looking to partner with the academic community to find and publish educational modules related to computational science education in accordance with the CSERD module criteria.

CSERD Module Criteria

1. Types of modules currently accepted by CSERD

The types of modules currently accepted for proposal for submission into CSERD include activities, models, applications, algorithms, and architectures. By publishing your module on CSERD, CSERD agrees to distribute the module online and include the module on CD releases of the reference desk. You, the developer, agree to provide us with a copy of the module that meets the CSERD module criteria, allow CSERD to make that copy available for free educational use, and be responsive to feedback from users of your module and otherwise be responsible for maintaining the module. In addition, CSERD prefers that you make your source code available under a suitable public license.

1.1 Activities

Activities are inquiry-based lessons designed to introduce students to a concept in computational science or to allow students to use computational science to learn some fundamental concept in science, math, or technology. Activities should be divided into three parts, a self-study based lesson, a list of materials, and a lesson plan.

1.1.1 Lesson

Lessons should be designed such that they can either be an example for teachers, or a self-directed unit for students. Lessons should include any appropriate background to start the inquiry, and questions to guide the inquiry. Materials (worksheets, links to models or data, lab equipment) should not be included in the lesson.

1.1.2 Materials List

Any materials required for the inquiry should be listed here. Worksheets or data created by the module author for this lesson should be included as separate documents to be downloaded, and links should be provided here. Worksheets or data should be stored in the same directory as the activity, and should be accessed with relative links. A separate target window should be used for any items that will display in a browser window (e.g. pdf documents which will be viewed using a plug-in). Items not created by the author, or items that are in and of themselves separate modules, should be accessed by a link, and should open in a separate target window. Where appropriate, items that are not already CSERD modules should be added to the CSERD catalog of necessary, and links should point to the CSERD entry rather than to the actual page. For example, a lesson is created which uses the SIMBAD astronomical database. The author would ensure that the SIMBAD astronomical database was listed in the CSERD catalog, and then link to the entry page, as in the Photometry lesson activity.

1.1.3 Lesson Plan

Lesson plans should include where the lesson fits in typical pre-college and introductory undergraduate curricula, what misconceptions are being targeted by the lesson, what standards are met by the lesson, sample answers to inquiry questions, suggestions for alternate activities and further discussion, and references.

1.2 Models

Models are pieces of software used to answer a question in computational science. Included in this category are simulations that apply scientific laws to user input and determine change over time, calculators that provide a simple interface to solve some equation or formula, and viewers that allow for visualization of scientific concepts. All models should include the following items: Instructions, Software, and Theory.

1.2.1 Instructions

Clear instructions on how to use, and if required, download and install the software must be included in any model. If there are any hardware, software, or system configuration requirements, they should be specified. Download packages should be in as compact a format as possible (zipped folders or installers for application downloads, jar files for java applets).

1.2.2 Software

In order to ease redistribution of CSERD materials, CSERD requires a copy of the software that can be freely redistributed for academic purposes, preferably in an archived and compressed form. The Software page should include a link to download or display software. If more than one variant of the software exists, multiple links should be listed, with a description for each variant of the software. For example, the LunaSee model is a Java applet that visualizes the appearance of the moon based on the relative position of the earth, moon, and sun. The applet has a different appearance if you want to allow for the possibility of an eclipse. Each different option is included as a separate link on the software page, and each link brings up the applet in its own window with no extra toolbars or browser information. Class files are stored in the same directory as the model as a jar file.

1.2.3 Theory (Application, Algorithm, Architecture)

The theory section should cover the scientific or mathematical question being addressed (the application), the techniques used in the solution (the algorithm), and the hardware used to implement the solution (the architecture). If excellent descriptions of any of these pieces exist elsewhere on the web, the user is strongly encouraged to link to those descriptions rather than recreating content. If application-algorithm-architecture descriptions exist as CSERD modules, those modules should be used, and suggestions for any modifications required should be made to the author of that module and to CSERD. If modules do not currently exist on CSERD and if the content does not exist on the web of sufficient quality or permanence, then the author should submit modules where needed for the Application, Algorithm, and/or Architecture.

Application, algorithm, and architecture links should all specify a unique target window if the materials exist on the CSERD site. If the materials exist elsewhere, the materials should be added to the CSERD catalog if appropriate and the link should take the user to the catalog entry. If the materials exist elsewhere but are not appropriate for the CSERD catalog, then the target window should be different from that used for other application-algorithm-architecture links. Justification should be given for any links to items that the author does not feel are appropriate for the CSERD catalog. For example, the Space Ship Pilot model applies Newton's laws of motion to a vehicle in either space or on the water, uses an Euler's method integration to solve the laws of motion, and does so in a Java applet. Newton's laws of motion, Euler's method, and Java Applets are all added as separate application, algorithm, and architecture modules, respectively.

1.3 Applications

Applications are the question being asked. Application descriptions should address the fundamental science behind any model. Application descriptions should consist of a single HTML page.

1.4 Algorithms

Algorithms are the methods used in computational science. Algorithm descriptions should include enough detail to reproduce the technique. Algorithm descriptions should consist of a singe HTML page.

1.5 Architectures

Architectures are the tool used in calculation. Architecture descriptions should address key details that allow the user to understand why a particular architecture might be use as well as its strengths and weaknesses

2. Programming and Style guidelines

2.1 Audience

Modules should be written in proper English suitable for an undergraduate audience.

2.2 Mathematical Text

The content creator and editorial staff should decide on a formatting option for mathematical test, which balances the following three desired features:

  • Mathematical text should be easy to read
  • Mathematical text should appear the same on all browser/operating system combinations, regardless of font size
  • Users should be able to copy and paste mathematical text

Unfortunately, there is not currently a solution for displaying mathematical text in a web browser, which meets all of the above desired goals. For complicated graphics, two recommended options are LaTeX2HTML and MathML. For simpler graphics, using preformatted text with the <PRE> tag may be acceptable.

2.3 Programming Language

Module pages should be written in HTML with minimal formatting. Page look and feel will be handled by CSERD, and as such primary pages should be written in HTML text without any header information (text will be included in a larger page). Any secondary pages launched by a primary page (such as a single large graphic or a Java applet) should be formatted as simply as possible, with a white background. For links that pop up secondary windows, the secondary window should not display window or browser information.

Our goal is to make CSERD models available on as many platforms as possible. Therefore, the preferred form for software is Java 1.1 applets. (Note: this means Java 1.1 and below, not Java 1.1 and above. Using post-1.1 classes or methods (such as Swing) will prevent applets from being run by many Mac users and PC users.) Another reason to prefer Java is that it is widely spoken; if your model is coded in Java, many programmers will be able to modify or improve it.

However, other types of web-accessible software are acceptable, such as JavaScript, Shockwave/Flash, and CGI scripts. Programs the user must download to use may also be OK in some cases. If you would like to use some form other than a Java 1.1 applet, email the CSERD team to talk it over.

2.4 Programming Style

For software written in Java, we encourage you to look at Shodor's Coding Style Conventions, which are based on Sun's conventions for the Java language. Whether you follow our guidelines, someone else's, or your own, you should make an attempt to keep a consistent, clean style throughout your code.

3. User interface guidelines

Models should be intuitive to use, which means the user interface must be clean and easy to figure out. There is some advice about how to accomplish this in Shodor's User Interface Guidelines. We urge you to look over these guidelines and keep them in mind while writing your model.

Disclaimer: The Computational Science Education Reference Desk reserves the right to judge the quality and appropriateness of all submissions to CSERD's forum, catalog, or resource library.

©1994-2024 Shodor