See also Review stages
In general, we are ready to accept wide range of various applets. However there are several important topics to discuss that may help you and us to reach the optimal result.
The applet must illustrate encyclopedic topic. If the encyclopedic article is not yet present, the best is to start writing it as soon as you upload the code, maybe even before. Not all possible applets are encyclopedic enough:
The strong side of the applet in comparison to the image or even animation is its interactivity, ability to capture mouse and keyboard input and respond by showing different content. Do not leave this without attention. An applet that simply shows some graphics without interaction is worth less than its screen shot, because the screen shot that does the same can be displayed with less trouble. An applet that shows animation is already better as is may be much smaller than the animation file. Still, even the animation is not enough to disclose the full potential of interactivity.
You applet must be quick enough to be usable, do not stall and do not hang. If such things are happening, it will be accepted for the test runs but not for production pages, waiting until you or somebody else will fix the issues.
The reader must concentrate on topic and not how to run your software. This means, the applet should be usable without reading user manual. This is a challenging requirement that can be achieved by
There is no a strict rule against putting some advertisement or crediting links directly into the applet. However (unless somewhere in the help popup) they use valuable space and make your applet less impressive. You can always be credited in the applet project and home pages and applet source code (that is visible through review system). If this is not enough, we can credit you directly in the article (acknowledgements section), just write this requirement in the project page. We suggest to think maybe this is enough.
Embedding next to text requires applet to be smaller that the "full screen" version. Please think if your applet uses space efficiently enough. We needed to rewrite some otherwise good applets just because they were taking most of the screen.
An applet that just illustrates one focused topic is great. But in many cases also looks efficient to reuse the same applet for various related figures. For instance, the Conway's Game of Life applet can show arbitrary colony and is inserted multiple times into the same article - can also appear in other articles. Think, maybe your applet can be more powerful if you can customize it through parameters.
The parameter strings to configure the applet are often cryptic. Hence it may be a good idea to have some button that exposes the parameter string of the applet how it is currently tuned with user friendly controls. The built-in parameter alt supports alternative screen shots for differently configure applets (see How to insert applet referece on how the applet is embedded into page).
Either ASCII or UTF-8 encoding is required for all text files. If some other encoding is used, this may trigger alerts as the text text file may look for the builder as a binary file, and binary files are not allowed. Be sure you delete all .svn and .cvs files because we really do now want this stuff in public review.
If you have used different encoding and have access to Linux, you can use the iconv tool to fix your charset. To fix all files in release, you need the two bash scripts: 1. The converting script (must be named conv.sh):
iconv --from-code ISO88592 --to-code UTF-8 -o $1.conv $1 rm $1 mv $1.conv $1 echo "Converted $1"
2. The wrapper script that calls the former script (assumed to be in the same folder) for every .java file. The name of this script does not matter.
New articles (RSS)
find . -name "*.java" -exec sh ./conv.sh {} \;
If you have a good applet with this the only problem, we will help you to convert. Make backup of your code before converting.
Bringing your code from private kitchen to public conference may require to 'outfit' it, making easier readable for many people. Also, while our build system is quite flexible, it requires some simple rules to be followed. These topics are covered in the required archive structure article.
There are certain types of coding that are not welcome and are likely to cause rejection of the contribution:
When unsigned applets are strongly confined, signed applets have access to the web, local filesystem and hence if some malicious code gets in, they can do much more damage. Surely, if everything goes well they allow to identify the author still we think for the project like Ultrastudio.org it is safer to use unsigned applets. If you cannot get the unsigned applet working, please upload the source code and we will try to fix it together. No any applet on this site runs as a signed applet.
If your applet supports some parameters or otherwise has some features that are worth to be documented, please create the documentation in the applet Project page. A project groups all your releases so you will not need to rewrite documentation every time you upload a new version. Use the applet home page to describe things that may version specific.
If you contribute a version of the GPL licensed work where your are not the first owner, put the note on all changed files that you have changed them, and the date of the change, also stating briefly that has been modified. Both 2 and 3 versions of GPL require this. This is also why we put such marks on all files that we change, even when these changes look too minor to claim any serious ownership.