The user interface plays an important role in making the user comfortable. To adjust it, you will need lots of modeling and little bit of coding here and there.

An online database comes with a default menu which allows access to the index from where the generic workflows start. Every online application, tailored to one user group, receives its own custom main menu which provides quick access to their pages and tasks. When customizing a main menu you create links and sub menus on the fly or reuse them, if they already exist.

The first entry of the main menu is also the start page of the store. When you are using static links for menu items, you may not use an absolute URL as a first entry, as this would redirect the user away from the store on entry. Topincs will simply ignore that menu item. In this case your start page will be the next valid entry. Revisit the menu factsheet and provide a URL within the store to fix that problem.

Users have a deeper relationship with their domain than view and edit. They want to do things:

• issues need to be resolved,
• invoices need to be mailed, and
• reports need to be released or delayed

To accommodate those needs Topincs introduces context menus. A context menu entry can either be a service connection or a dynamic link. The first one binds the topic in focus to an argument of a service. It is created by declaration. The latter needs a few lines of code to simply create a link within the web database and e.g. prefills a form with values derived from the context (time, date, user). Context menus are accessible on the page of a topic as well as on right-clicking links to the topic. Conditions may be specified under which entries of a context menu are inactive or hidden.

The label of a topic can be a computed value. It is recomputed on change, so that it is always correct. Label rules are created in the User interface Index linked in the Admin menu. They work on one or more topic types and use a tiny piece of PHP code to specify the computation of the label. The code is the body of a method of a transient domain class. So $this is a tobject and you can access the normal interface of its topic type. Sounds complicated? Watch the video and see how easy it is.

Label code for wish in the Santa Claus store

Another label rule example

Label rules can be varied depending on the perspective by scoping them with a role type and optionally a language. Usually some segments of the unscoped label rule needs to be left out since it is given in the context.

The order in which statements are presented in a topic or form page can be influenced by an occurrence of type Field order on the topic type. The field order can be edited on the page of the topic type. You need to take care to only add constraints that belong to the topic type or a super type thereof.

The sort order of instances can be controlled for the following aspects of the web database:

• Index: order of instances of a type (multiple domain sort criteria can be defined and selected)
• Factsheet: order of counter players within a paragraph.
• Form : order of options in select boxes (tied to order of previous point).
• Services: iteration over tobjects.

The predefined alphabetical sort order is case insensitive, so it does not matter whether the first letter is lower case or upper case. The sorted topic list appears natural to humans. Custom sort orders – on the other hand – use the result of a given computation rule for a case sensitive comparison. The programmer can simply make it case insensitve by lower casing the result in the computation rule.

By default counter players are displayed as a link with a label. In some cases it makes more sense to just display all the information on a counter player directly in the page. There is two settings to easily activate this behavior in form and factsheet: Displayed as data sheet and Displayed as row. The first one displays information vertically, the second one horizontally. Row display does works well for topic types with up to seven constraints.

If users should not see certain fields, either to simplify the user interface or for security reasons, there is generally three approaches:

• Fields can be securely hidden from one or more user groups by editing the respective statement constraint. One is for viewing in the fact sheet, the other is for editing in the form. With this approach the information is never transferred to the client.
• Use the Initially hidden on the statemnt constraint. This only applies to the form. It is useful, if a field might only be edited every now and then.
• In the form some fields might only be required depending on the input to other fields. Use Hide when valid and empty on the statement contraint in this case. The field will be displayed automatically when the compound constraint invalidates it. Invalid fields are always displayed.

You have seen multiple ways how to tailor the user interface to you needs, but this is just the tip of the iceberg. There is a many options for you left to explore. Try them out and see if it helps you. If not, simply revert the change.