OLAT has a fully compatible SCORM 1.2 runtime environement. Due to some SCORM concepts it differs a lot from the IMS content packaging viewser also integrated in OLAT. Each content object (Sharable Content Object [SCO]) communicates with OLAT over a separate channel with backend while the user is browsing the content. The API each SCO is looking for consits out of 5 javascript functions that need to be present in the SCO content.To communicate with the backend we relay on the not yet so commonly used XMLHttpRequest javascript object. It allows us to do asynchronous SCORM API call without the need for an Java Applet or other plugin technolgies.

The SCORM backend consits of three parts. First part is a standard OLAT controller which listens to the SCORM API calls and passes them further to the SCORM backend. The controller delivers also the content which is displayed in an IFrame. The API calls are passed to the API Adapter which is used in other projects as well (Ilias and ATutor).

All folders accessible through the GUI within OLAT are managed by the FolderRunController. The actual file operations are further wrapped by a Virtual Filesystem (VFS). See the section on the section called “Virtual Filesystem (VFS)” VFS for further details. Folders can have security restrictions such as read/write restrictions and quotas. All this is implemented through the functionality provided by the VFS abstraction layer.

All of a user's folder are exported via WebDAV through a single unique mountpoint at webdav://your.server.com/olat/webdav/. The user authenticates via an OLAT authentication provider (see section on authentication) and is presented its personal briefcase, and any coursefolders/groupfolders/sharedfolders she might have access to.

After log in the home site is activated. However, it is also possible to directly jump into a course, forum in a group etc. When creating new sites or dynamic tabs this is handled via ControllerFactory.createLaunchController(). When the site or dynamic tab already exists the activation is done through the Activateable interface that must be implemented by such sites.

OLAT should be easy to use without the need to read help. However, the functionality of OLAT is so big and some of it is quite complex that it is not possible to make everything self explanatory. The context sensitive help is used wherever some help might be needed. The context sensitive help is appears with a small symbol. By clicking the symbol a pop up window opens containing the help.

The context sensitive help is placed in the html files using the velocity helper rendering method velocityRenderDecorator.help(). The context sensitive help is written using the translation tool explained in Customizing.

The comprehensive help in OLAT is accessed via the top navigation tools. The help opens in a new window and is organized as a regular OLAT course. This is very handy since the help has also a forum. Make sure you register to this forum notifications!

The OLAT help course is imported when starting OLAT. Modify the lines in the module CourseModule in the WEB-INF/olat_config.xml file if you want to have your own help course used instead of the default one.

Some GUI elements in OLAT offer configuration / personalization options. These options usually have a very local scope and do not influence the whole system. In contrary the users settings that can be changed in the home site (see the section called “Settings”) have a global scope and affect OLAT as a whole for this user.

Every user has one object GuiPreferences that can be retrieved from the users user session ureq.getUserSession().getGuiPreferences(). The GuiPreferences object offers then methods to get and set values for this user.

The users list in the group management for example features much more data than is shown in the default view. However, presenting all data would make the table very large and would force you to scroll vertically. In this table a small icon right on top of the table lets you customize this tables view. Some other tables also use this feature, e.g. the listing of learning resources has an additional date field that is not visible in the default view.

Another place where the GUI perferences are used are the menu and toolbox state. Menus and toolboxes can be put into a dynamic / hidden state. This state information is stored in the GUI prefereces.

Another example is the home site portal configuration. The users personal settings are also stored in the GUI preferences.