The FirstSpirit concept

Extensive publications, for example, a company's website, involve a large amount of information, which has to be managed, updated, and published. FirstSpirit tries to make this as easy as possible by dividing the information into different “stores” (management areas) – while retaining the strict separation of layout, content, and structure. Depending on the role assigned to them in the project, the user should be able to keep an overview of the content and structure at all times.

Stores

Within SiteArchitect, different content (for example, images, files, structured data, layout, and navigation structure) is managed in separate areas (“stores”). This concept fulfills the paradigm of separation of the structure, content, and display of a website. The individual areas can be changed independently of each other and content can be reused at any time. This concept allows, for example, editors to make editorial changes easily, efficiently, and above all without any knowledge of HTML and XML.

SiteArchitect is divided into six stores each with different colors, which are strictly separated from each other but are functionally dependent. The colors of the stores indicate, among other things, the element type in which the data is saved and the store in which changes are currently being made. The color coding can be seen not only in the tree structure of a store, however, but in many other places in SiteArchitect too; for example, in the horizontal tool bar, in the tab navigation of the editing area, or on the tabs of the integrated preview.

• The Page Store contains all pages and their editorial content.
• The Data Store is used to create highly structured pages by managing the content using database mechanisms.
• The Media Store contains all media files used in the project. These do not necessarily have to be conventional image files. The Media Store also manages other types of files, for example, those which can be made available on a page for downloading (audio and video files, Flash animations, PDF documents, style sheets, etc.).
• The Site Store determines the navigation structure of the website.
• The Template Store includes all information concerning the layout and functions of the website. For detailed information about this store please see Template development (→FirstSpirit Online Documentation).
• The Global settings contain global user and project settings, global content (used multiple times), and definitions of URLs.

Permission assignment

In addition, FirstSpirit provides a clear system of permission assignment, as a large website can only be effectively managed if each individual employee has precisely defined tasks. Each website created and maintained with FirstSpirit is called a “project”. A roles concept defines task-related access to parts of the system and describes the allocation of a team's work within the project. The permissions can therefore be intuitively assigned in easily understood and clearly followed roles. A permissions concept is created for each role and is then assigned to the relevant group of employees. When a user logs in to FirstSpirit with their name and password they are only given access to the system corresponding to the permissions assigned to them by virtue of their role. For example, an administrator is given all permissions for access to system settings, the chief editor access to the structure of the website, and the editor is, for example, only given access to a special subarea for maintaining the website (see Permission assignment in SiteArchitect).

FirstSpirit differentiates between permissions valid for a user of FirstSpirit, for example, for an editor (editorial permissions), and permissions defined for a visitor to the site generated with FirstSpirit (user permissions).

• Editorial permissions: These are the permissions valid for a user of FirstSpirit.
• Workflow permissions: These are a special type of editorial permission that only relate to the workflows within a project.
• User permissions: These are permissions valid for the “visitor” to the website generated with FirstSpirit. User permissions are always linked with the personalization system used.

Use of multiple languages

FirstSpirit consistently supports the concept of multilingualism which runs through all aspects of FirstSpirit.

1. SiteArchitect language setting (“locale”):This setting is defined using the combobox of the FirstSpirit start page and affects the language of both the start page and the language of all FirstSpirit applications (including SiteArchitect) started from the start page. In SiteArchitect, the locale language determines the labeling of the menu bar, the dialogs, and all content which has not been deposited in the project in language-dependent form by the editor or template developer. You can currently choose from Dutch, English, French, German, Italian, Russian, and Spanish.
2. Editing languages: These are defined for a project by the project administrator and can then be set using the “View – Preferred display language” menu. The editing languages affect language-dependent content which has been defined by the template developer, e.g., within the page or section templates. The relevant language-dependent labels are displayed to the editor in language-dependent form, for example, in the form area (labeling of the input fields, tool tips, elements of a combobox, etc.).
3. Project languages (content languages): The third setting option concerns the project languages, i.e., the languages defined by the project administrator for the inclusion of language-dependent editorial content. The editorial content can be entered in SiteArchitect using the language tabs of the Page, Media, and Data Store.           
   A generated website can be multilingual, i.e., the form area contains different input fields per project language (per tab), for example, for texts and media, the content of which is to be displayed depending on the chosen language (“language-dependent”).          
   However, it is also possible to define “language-independent” input fields. In this case the content is entered once only but is available in all project languages. This time-saving, language-independent definition of content is useful, for example, for the display of images (without text) or for numerical details (e.g., product descriptions, dimensions).                                         
   Apart from simple editorial content, structured content from a database can also be integrated. The concept of multilingualism is taken into account in this case too.

In addition, FirstSpirit offers support for automated translation processes, for example:

• XML export/import (e.g., for Trados).
• Possibility of incremental translation using the “Page not yet completely translated” function (see page Settings at page level).
• The option of a fallback, i.e., configurable, automatic language replacement. If the content of a page is not available in a certain language, the content can be displayed in another language instead, for example, the project master language.

For multi-language concept in FirstSpirit see Languages in FirstSpirit (→FirstSpirit Online Documentation).

Parallel access in multi-user environments

FirstSpirit was conceived for use in multi-user environments. This means that, in particular, the editorial maintenance of the content can be carried out within a project in parallel by a large number of employees. Due to the close teamwork involved it is necessary to ensure that no conflicts occur during shared access to individual objects.

FirstSpirit differentiates between actions which may run on an object in parallel and actions during which access to an object has to be protected for the period of editing to prevent conflicts.

In FirstSpirit the following actions can be carried out in parallel for an object:

• Create: Create new objects in the project.
• Delete: Delete existing objects from the project.
• Copy: Copy existing objects to another position within the project.
• Move: Move existing objects to another position within the project.

The following actions may not be carried out in parallel:

• Change: Change the content of an object, for example, a page of the Page Store.
• Release: Parallel access also has to be prevented when an object is released, as the release ensures that only one precisely defined and checked status of an object is released.

The “edit mode” system implemented in FirstSpirit is used to prevent the possibility of parallel editing. If a user chooses an object to be edited (e.g., a page of the Page Store on which content changes are to be made), they must block this object from access by other users for the duration of their work. Content changes to an object are only possible if the object is in edit mode. This ensures that several users do not work on an object simultaneously, which would cause inconsistent data to be produced. This also achieves a high degree of security and simultaneously creates the chance to work in parallel with a correspondingly high edit speed in multi-user environments.

Versioning, historization, and archiving

The versioning, historization, and archiving of all information is very important in enterprise content management. The primary objective is to achieve the most continuous traceability possible of all changes, as well as access to “system statuses from the past”.

Versioning: Each time an object is changed by an editor, for example, a medium, FirstSpirit creates a new version of this object. Thus, an object has a version history on the basis of which it is possible to trace which changes were made by which persons over time. Apart from these simple changes, versioning in FirstSpirit also takes into account complex structures which can exist between the objects of a project. In FirstSpirit, for example, pages are compiled from individual sections and are combined in the Site Store to form a navigation. The versioning of the basic objects and the structural aspects gives a completely versioned description of the overall system status, which enables changes to be traced.

Historization: Historization in FirstSpirit builds on this completely versioned description and is used to reinstate a system status from the past. Historization can be used, for example, to generate the status of a website as of 01.01.2012 by (temporarily) setting the current live project to the status of 01.01.2012 and then carrying out a generation. Historization generates a temporary status only and allows read access only.

Archiving: Archiving is used for the long-term, secure, and unadulterable storage of data. Within the scope of enterprise content management systems, archiving is frequently focused on collating content into self-contained units and subsequently transferring them to a long-term storage medium.