Skip to main content

Context

General​

Each Context should appear with a title and (if via a View in the "Detail" area of a MainView) a title plural. Technically, the title and the titlePlural are NOT set in the Context model, but in Entity model that is assigned to this Context. (A title set in the Context is only displayed in the menu editor of the Designer.)

You can use the example Contexts of the Customizing Manual as pattern. The Customizing Manual is available in the customer area of the ADITO web site.

Augment your Context with links to all Views, also of other Contexts, that might be helpful for the user. Your aim should be to minimize the steps that the user must take in order to reach the required information. Links can be implemented in various ways:

  • EntityField’s properties "linkedContext" and "linkedContextProcess": Display the EntityField’s value with a link leading to another Context:

    • The link opens the target Context’s MainView of the data set that has the original EntityField’s value as primary key (ID). Example: Person_entity.ORGANISATION_CONTACTID.linkedContextProcess (opens the OrganisationPreview_view of the contact person’s related company).

    • In the PreviewView, an additional "eye" icon is displayed beside the linked EntityField value. If you click on this icon, the present PreviewView is replaced by the PreviewView of the target Context, again showing the data set that has the original EntityField’s value as primary key (ID).

  • Actions: Simply include methods like openContext in the onActionProcess to enable the user to open other Views with related information. Example: Action "newTask" of Person_entity.

  • ViewTemplate property linkedColumns (available in some ViewTemplates, e.g., "Table"): All columns specified here will be displayed with a link to the Context’s MainView. This property must always be set.

Views​

FilterView​

Basic configuration of a FilterView:

  • Set the View properties

    • "filterable" to true

    • "layout" to GroupLayout

  • Make all reasonable EntityFields available as filter properties, by setting property "isFilterable" of the respective RecordFieldMappings to true.

  • Filter settings:

    • Filter values referring to boolean EntityFields must always be "YES" and "NO".

  • ViewTemplates: The GroupLayout should include the following ViewTemplate types:

    • minimum: "Table" - this type of ViewTemplate is applicable for almost all kinds of data

    • wherever possible: "TreeTable" - this enables a grouping of data, which is a significant benefit for the user. (To make this work, ensure that all respective EntityFields have their property "groupable" set to true.)

    • ViewTemplates of further types, suitable for the data to be displayed - e.g., "Timeline" or one of the "chart"-type ViewTemplates. Add ViewTemplates of all types that are actually an added value for the user in this Context.

      Each ViewTemplate placed in a GroupLayout should appear with a suitable text in the ViewTemplate selection button. In seldom cases, if the ViewTemplate’s type (which is automatically displayed) is not suitable, you can use the ViewTemplates property "title" for an individual text.

  • Actions:

    • Important, frequently used Actions should appear with specific buttons.

    • Further, more seldomly used Actions should be placed in the "3 dots" menu.

PreviewView​

Structure​

Set the View properties "layout" to HeaderFooterLayout. Each PreviewView

  • must have a ViewTemplate of type "Card" as header

    • max. 3 normal lines: titleField (mandatory), subtitleField, and descriptionField

    • max. 1 additional line for system output, such as error messages: informationField. Example: Duplicate note in cardViewTemplate (header) of PersonPreview_view (calculated EntityField "Information" was set in property "informationField")

    • iconField (optional). You have one of the following options:

      • If your data sets usually include an image (icon or picture), then reference the corresponding EntityField (usually named PICTURE). Example in xRM project: OrganisationPreview_view.

      • If you want initials (e.g. "JS" for contact person "John Smith") to be shown as a placeholder instead of a real icon, then reference the corresponding EntityField (usually named IMAGE) and set the corresponding valueProcess accordingly. Example in xRM project: SalesprojectPreview_view.

      • If no icon and no placeholder is to be shown, leave property iconField empty. The values of the other properties (titleField etc.) will then be displayed horizontally centered. Example in xRM project: DocumentTemplatePreview_view.

    • Actions: see chapter Order of Actions

  • ActionViewTemplate:

    • optional

    • to be placed directly under the cardViewTemplate

    • up to 6 Actions that are daily in use

  • FavoriteViewTemplate:

    • optional

    • to be placed directly under the cardViewTemplate/actionViewTemplate

    • named "Favorites"

    • automatically, it will show the drawer caption "Tags"

  • ScoreCard:

    • optional

    • if used, then always as footer

    • up to 3 EntityFields showing very important data of the dataset

Every further ViewTemplate is to be placed above the footer and should

  • comprise only EntityFields that are logically associated (except, if required, a ViewTemplate titled "Further information")

  • have a concise, self-explanatory headline (= property "drawerCaption").

  • have a unified layout: either vertical or horizontal

This will ensure a clear differentiation of data and thus enable the user to find all required information quickly and intuitively.

Order of Actions​

Via the Action button ("3 dots" button) of the cardViewTemplate, you can open a dropdown menu showing an arbitrary number of Actions.

These Actions must be in the following order:

  1. Actions with fixed positions:

    • "Observe data set" always at first position

    • "Open admin view" always at last position (see also chapter Admin view)

  2. Further Actions (in between the Actions with fixed positions) are to be grouped according to function, in the following order:

    • Create Actions (e.g., "New task", "New appointment", "New offer")

    • Linking Actions (e.g., "Add to serial letter")

    • Reading Actions (e.g., "Customer base sheet", "Show classification")

    • Executing Actions (e.g., "Test email", "Set finished")

  3. If an additional function group is to be added, its position must be determined according to priority.

To the left of the "3 dots" button, up to 2 Actions can be set via the properties "favoriteAction1/2". These should be Actions that are frequently used. They appear as little square buttons. It is mandatory to set an icon and a tooltip for these Actions.

Admin view​

Via the Action button ("3 dots" button) of the cardViewTemplate, an Action named "openAdminView" (title: "Open admin view") should be available, as last (lowermost) customizable Action. If you execute it, the DefaultAdminView_view must be opened in place of the PreviewView, showing

  • the internal name of the Entity (as given in the Designer)

  • the selected data set’s ID

  • if applicable:

    • date of creation and last edit of the data set

    • name of the user who created and last edited the data set

    • the IDs of related data sets

You may use, e.g., the Action "openAdminView" of Organisation_entity as a pattern in order to learn how to implement it in the PreviewView of a new Context.

EditView​

  • Do not include ID fields, not even readonly, as their values are auto-generated by ADITO as random hexadecimal GUIDs, which are of no added value for the user to see in this place.

  • Include calculated EntityFields only if this is really an added value for the user. In these cases, make sure you configure them readonly. Example: EntityField "age" is calculated immediately after the user has set the EntityField "DATEOFBIRTH".

  • Avoid buttons, except toggle buttons for setting boolean values.

  • Unified/coherent naming of placeholder texts (e.g. "From - To" or "Start - End", but not mixed).

MainView​

The MainView should have a MasterDetailLayout,

  • with the PreviewView referenced as "master" and

  • with at least one tab in the tab register of the "Detail" area (= at least one additional View referenced)

Tab order​

Tabs shown in the MainView of more than one Context must be placed in the same order in all Contexts - e.g., tab "LOGS" always at rightmost position. This recognition factor will increase the usability significantly: If the user has learned to use the MainView of one Context, he will understand the MainViews of all other Contexts even quicker.

These a the guiding principles for the tab order:

  1. The order of the tabs is determined by the tabs' relevance from the master data set’s point of view.

  2. If in doubt about the relevance of a specific tab, its position is to be chosen according to the position it has in the tab order of other MainViews containing this tab.

  3. For the following tabs, the ADITO Design Guideline includes a fixed definition of relative positions within the tab register of all Contexts (with "relative" meaning that further tabs can be inserted between these tabs; in these cases, individual decisions are to be made).

    • Activities

    • 360 Degree

    • Tasks, Appointments/Tasks

    • Attributes

    • Documents

    • Duplicates (if present, always at second to last position)

    • Logs (always at last position)

Tabs with multiple Views​

If a tab in the "Detail" area contains multiple (sub-) Views, each of these must have a caption, in order to assign its content to a specific topic. Set the caption text in the (sub-) Views' property "layoutCaption" (only available, if layout "DrawerLayout" has been selected).

If, in turn, a View consists of multiple ViewTemplates, each of them should also have a headline (= property "drawerCaption").

Actions​

General​

Avoid too many Actions in one ViewTemplate. Instead,

  • group Actions according to principles that the user can understand intuitively.

  • sort out Actions that are not really necessary.

Icon​

Each Action must always have an icon (property "iconId"). This helps the user to understand the function of the Action intuitively. (Note that this is obligatory, even if the icon is currently not shown in the client, because there may be design updates in the future, which might require an icon.)

Title​

Actions need a short, concise title. The "title" property may exceptionally be left empty if the icon itself is self-explanatory or the same icon appears in the Client very often.

The title’s text must be formulated in infinitive ("Write E-Mail", "Copy ticket", etc.).

Tooltip​

As the title of an Action is not always displayed (e.g., if the Action is assigned as "favoriteAction" of a cardViewTemplate), we also recommend to define a tooltip for each Action - at least for those that are in need of explanation. Tooltips should always provide an added value (e.g., explain the keyboard shortcut for this Action), not just repeat the title.

Serial Actions​

Serial Actions are Actions that are not restricted to one single data sets, but can be applied also to multiple data sets. These Actions usually appear (as buttons or in ActionGroups) on top of ViewTemplates that are capable of showing multiple data sets - such es Tables, TreeTables, Trees, etc.

When configuring Serial Actions, make sure that their scope is explicit and unmistakable: They must only be enabled (state = ENABLED or AUTO), if at least one data set has been marked. If nothing is marked, all Serial Actions of this ViewTemplate must be disabled ("non-clickable"). Never implement a logic that supposes "nothing marked means everything marked"; serial Actions must never be applied to all data sets (or another non-explicit bulk of data sets), if the client user has not marked them.

Technically, you should

  • use the "EntityRecordsRecipe" approach (see Customizing Manual), because then a "select all" checkbox will appear in the ViewTemplate, which enables the client user to select, if required, all data sets with one single mouse click.

  • set the Action’s property "selectionType" appropriately (for its value options, see its property description).

Diagrams​

A diagram (i.e., a "chart"-type ViewTemplate, like "DynamicMultiDataChart") must be configured in a way that all parts of their content can be interpreted easily. This requires all respective properties to be set accordingly, in order to make both the complete diagram and all of its details (axes, columns, bars, etc.) being marked correctly (with titles, lables, tooltips, etc.), avoiding any risk of misunderstanding.