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.