Wims offers great freedom in the design of modules. In the simplest (but not very useful) case, if an ordinary html file, under the name main.phtml, is put into a directory, this directory will behave as a Wims module, and the html file will be sent to the user when this module is requested.
On the other hand, there is no limit to how a module can be complicated. main.phtml can call other files in the module; inline mathematical symbols and Wims commands can be inserted into these files; in order that the module be correctly indexed on the site, a file named INDEX should be created; auxiliary (static) graphics files can be included; variables which the user is allowed to define when requesting the module should be declared in var.def; etc.
The output of the module is defined by phtml files (phtml stands for `programmab le html'). The format of phtml is a proprietary extension to the html language, by allowing Wims commands and variable substitutions in the file.
In order to achieve maximal independence between Wims commands and html tags, the Wims command language is line-oriented. Wims only interprets lines whose first non-space character is the exclamation mark `!', considering the word following this `!' as a Wims command. All other lines are simply sent to the user, after eventual variable substituti ons. This allows Wims commands to take place anywhere in the html result: within html tags, html header fields, http references, javascript scripts, etc. As a result, the interaction between Wims commands and html tags is very flexible.
Of course, the result sent to the user is a pure html file, with all Wims-propri etary codes replaced by their outputs.
Although it is possible to put all the processing of user requests into a phtml file, it is recommended that computational codes be put into variable processing files which have a slightly different syntax. This syntax is more convenient for variable processing. Such a distinction between computation and output also helps multi-language support: when a module is translated to another language, only phtml files need to be translated.
There can be two variable processing files: var.init which is interpreted at the module's initialization, and var.proc which is interpreted at every user request. An arbitrary number of other variable processing files can be present, to be called by the above two.
The quality of the modules is of crucial importance to the system, as it is by this that ordinary users judge the quality of the system. User interface (the html page output) should be designed to achieve good compromise between simplicity, clarity and versatility. Due to the particularity of users through the Internet, simplicity is very important, and ideally the first page of the module should directly lead the user to the main functionality of the module, whether it is an exercise or a tool.
In order to reconcile beginners who just need the basic functionality and advanced users who want to make more complicated computations or more detailed setups, many Wims modules implement a dual-menu mechanism, allowing the user to switch between a simple menu and an expert menu.
Special pages such as introduction, about, help and hint can be included in the module.
Wims has a scoring system for exercise modules. The module can send a score to the scoring system by simply assigning a value to the variable module_score. This value should be a number between 0 and 10 (10 for full success). This score can be used by the structure of virtual classes (see Section 5) to monitor the progress of each student.
Inter-module communication is achieved by usual html links: any module can include a link pointing to another. This is particularly useful when solving an online exercise requires computatio ns which can be done by an online computational tool. In order that the exercise remains open when the tool is called, another browser window is opened to host the tool. A new session is also created for the latter.
This mechanism does not work perfectly, especially for unexperienced users. This is because the new browser window is often sized to exactly cover the original one, especially when the browser is in full-screen mode. And the user is often confused, thinking that the exercise is lost. An ideal solution seems not easy to find even with the use of javascript, because there is no way for the server to know what is the screen size of the browser.