Application design: Style guide

Applications module

1. Introduction

This style guide serves as a guideline for designing intuitive and uniform Intrexx applications, providing support during the development of new applications and optimizing existing applications. The aim of this style guide is to guarantee a distinctive and consistent design, and a high level of usability.

1.1. Design fundamentals

Intuitive design requires the needs and user requirements of the end users to be defined. User-friendliness, and the acceptance resulting from it, can only be achieved when applications line up with the requirements and expectations of the end users and when a simplification of work procedures is the goal.

1.2. General principles of design

When planning an application, the principles of the dialog design ( EN ISO 9241 Section 11) are to be regarded.

1.3. Presentation of information / Page design

When presenting information, the following criteria are to be regarded:

2. Application structure

When developing applications, you shouldn't just concentrate on the mere visual appearance. Overall, you should pay attention that the three "pillars" content, design and structure, which are required for a good result, remain strictly separated from one another and that emphasis is equally placed on all three points. With regard to the structure, attention should be paid to reaching a uniformity and consistency within an application.



The sitemap shown above shows the structure of a correctly built application made with Intrexx. The starting point of this application structure is the overview page (A1). From here, various interaction options are made available to the user so that they can complete tasks quickly. In the following, these are referred to as
The interaction elements and their triggered actions should be the same throughout an application. For example, the action "Add data" should always be performed by a button and a text link should always redirect to details page. The interaction elements must be in the context of the information to be changed.

By clicking on the "Add data" button (A1), an edit form (E1 / E1.2) will open as a tooltip in the middle of the page. In this form, empty edit fields are displayed. For a large amount of data, an edit page can also be opened in the main window.

If the "Edit data" pencil icon (A1) is clicked on, an edit form (E1) is shown in this case as well, however the fields are populated.

Therefore, it's the same form for adding and editing data, this saves time during the development phase of the creation. In practice, a user can find their bearings in the application more quickly and the usability is increased due to the consistent structure and the uniform appearance.

Starting from the overview page (A1), a detailed view page (A2) can be reached from the provided View data text link. The details page (A2) can, depending on what's needed, contain the options "Add data", "Edit data" or "View data".

On the detailed view page (A2), users are shown information that's already been created. This data can, once again if required, be modified. If this is the case, an "Edit" button can be used to open the same edit form (E1) with populated fields; this the same form reached via the pencil icon on the overview page (A1).

For all subpages, the same structure and approach as described above is to be regarded.

2.1. Application menu structure




The application menu subdivides the most important pages of an application and provides the user with quick access to the respective pages by directly linking the individual menu points. A selected and active menu point should visually stand out from the other menu points. This can be achieved both by using a completely different color (for a:hover and a:active) as well as by using an additional bar underneath the currently selected menu point.

An application menu should be shown above the content area and left-aligned. It shouldn't contain more than 7 +/-2 menu points to ensure clarity.

Application menus should correspond with a logical and in particular, a consistent sequence.

As an example, ordering the points based on how often they are used can be very helpful so that users have immediate access to the information that they are more likely to need.

In our example, only the content that is definitely relevant to the user and that is very likely to be accessed is shown under the menu point "Projects". The point "All projects" contains all of the created projects. This menu point is seen as the second most important and is therefore placed second. The menu points "Administration" and "Search" are positioned last because these are accessed least.

If multiple applications in a portal contain the same menu points, these should all correspond to a consistent order, for example in our case, the menu point "Search" is always positioned last. The similar structure makes it easier for users to find their bearings regardless of which application they're using.

3. Overview page

3.1. Possible structure of an overview page (A1)




With regards to information, there are different needs and amounts for an application page. Because of this, the structure can vary based on content's criteria.

Every application page should have a page title (Heading, Text_H1, distinct and clear name) which ideally matches the selected menu point of the application. Furthermore, the first letter of the page title should be left-aligned with the application menu.

The content area covers the entire width available, if a navigation or filter area isn't required.

If an additional filter/navigation area should be provided, this should be positioned to the left of the content area. Individual filtering options are arranged vertically one beneath the other in order to provide the content area with enough space. Please also bear in mind that the content area should be clearly separated from the filter/navigation area (min. 5px).

3.2. Possible design of an overview page

3.2.1. Application page with a free layout table (A1)




Presenting content in a free layout table is a good idea if data should be presented in a visually appealing manner. A background image draws interest to the content and thus increases the "joy of use".

If tables can be subdivided into categories (in two columns here), there should be a gap (min. 5px) between the tables to create a visual separation. Additionally, each table group should have an appropriate table title (Text_H2). In our example "Public projects" and "My projects", these titles should be left-aligned above the table and unify all of the table content assigned underneath it.

3.2.2. Application page with a view table




If a filter/navigation area isn't used, the content area of an application is stretched to take up the entire area of the application area. Each table should have a clear table title that is left-aligned and positioned above the table.



If tables can be divided into different categories, each table group should be given a container that fully encloses it. A gap of 15px should be made between the table groups. If users should be provided with the ability to add new data to a table, a corresponding button should be positioned above the table and right-aligned.

The appearance of an application page with a filter/navigation area could look like this:



In this case, each table column ought to have a suitable heading and if possible, consist of one apt word. In general, columns should be ordered based on their priority (from left to right with the most important columns first).

Tables enable you to get a quick summary of large volumes of data. Therefore, the aim when designing tables is to provide the user with optimal access to the information needed or wanted.

The following alternatives can be used for viewing or editing a data record. Which variant should be used generally depends on the context within the application. The choice of the target destination (view page or edit page) is also dependent on the context and must be determined on a case to case basis.

View data record (View page A1)




If the primary goal of a table is for displaying data, the title in the first column should be a link that directs to a view page (the magnifying glass symbol is redundant in this case). However, opening a view page from within the table only makes sense if additional data, which isn't shown in the table, is displayed.

View data record (Embedded tooltip A2)




Another available option is to allow a view table's data records to be shown as an embedded tooltip.

The advantage of this is that the user doesn't need to leave the application page and the data can be viewed conveniently within a table or container. Here, the opened data should be indented and a "Close" function should also be provided.

Edit data record




If the primary function of a view table is to enable data to be edited, the title in the first column should be a link that directs to an edit page with populated fields. This means that the pencil symbol at the end of a row can be omitted.

View and edit data record – strict separation




If the primary goal of a view table is for displaying data, the name in the first column (usually the title) should be a link that directs to the corresponding view page. Furthermore, a pencil symbol is provided at the end of each row; this links to the corresponding edit page.

The distance within a row between the "View" and "Edit" actions should prevent the users from clicking incorrectly.

3.3. Summary of the overview page (A1)

Possible structure

Application page with a free layout table

Application page with a view table

4. Details page

4.1. Possible structure of a details page (A2)




A details page can be divided into two areas, depending on your requirements. The upper content area is for general information and the lower details area provides additional information. Because a details page usually displays a large amount of data, it shouldn't be opened as a tooltip but rather in the main window.

4.2. Possible design of a details page (A2, General information)




General information, in this example the most important project data, should be shown as the main information on a details page; this provides the users with a brief rundown of the most important details. To make the presentation visually appealing, the area for the general information could be depicted using two columns, according to your requirements. One area could, for example, show a video or image and the area next to it could display the general information. Here, the general information should correspond to same order that it was entered in. Furthermore, users should be provided with an option to edit this data. For this purpose, a corresponding button is positioned beneath the data (Edit). Above the data isn't an option as this area is reserved for the "Add data" text button – if it's required. Likewise, an edit icon should not be used because this could be overlooked amongst the large amount of data.

The details area, which could appear beneath the general information, contains additional information. This information can be opened directly on the details page as an embedded tooltip. This allows the content to be collated under a tab menu. From the tab menu, the user can jump to the specific content needed. Using the embedded tooltip function prevents overly long pages and the need for scrolling.



The order of the tab menu should be grouped and arranged based on the importance. The most used tab is on the left. As with all navigation elements, the tab menu comes first in the details area and is left-aligned.

The page title (Text_H1) of the details area comes from the currently selected tab. The label of the tab and the left-aligned page title beneath it should coincide.

If filter/navigation options aren't provided, the detailed information should stretch to the maximum available width. If a filter/navigation area is also provided, this should be positioned to the left of the detailed information. Here, keep in mind that the detailed information and filter/navigation area should be clearly separated from one another.

4.3. Summary of the details page (A2)

Possible structure

Possible design of the details page

5. Page design: Edit and view pages

5.1. Edit pages

5.1.1. Open edit pages in a tooltip




This edit page (E2) is opened as a tooltip in the middle of the layout with the displayed page title (Text_H1). Optionally, an edit page can also be opened modally. A Close symbol is shown at the top right. If possible, an edit page should contain no more than seven edit fields. However, as always, the context that the corresponding page is used in should be regarded. The target group should also be regarded here. Normally, one edit form should be enough to record all of the required data. To support navigation within a form via the Tab key, it's essential that the edit fields are arranged logically.

5.1.2. Edit pages as a multi-page wizard (E1 – E2)






Instead of trying to pack a large amount of edit elements into one overly long form, it's recommended that you create a multi-page wizard which is operated by the Next button (E1, E1.2). Every edit page (E1 and E1.2) is opened as a tooltip in the middle of the layout with the displayed page title (Text_H1). A "Close" symbol is shown at the top right.

Wizards should only be implemented in situations where the content of each edit page can be divided meaningfully (grouping).

As always, the context that the corresponding page is used in should be regarded. This also makes it possible to place more than seven elements in a form without it feeling overloaded.

It's a good idea to provide the user with information regarding the progress within the multi-step process on each page of the multi-page wizard. This means the user knows precisely where here they are and how many steps are left (e.g. Step 3 of 5). By meaningfully dividing the form into multiple steps, it's kept manageable which in turn allows the usability to be increased notably.

5.1.3. Open edit pages in the main window




As a third option, edit pages can also be opened in the main window. This could be useful in a situation where the large number of edit fields would take up too much space in a tooltip.

5.2. View pages

View pages should correspond to the same logical structure of their respective edit page. The same, or a similar, arrangement of the elements in the edit or view page helps the user to find their bearings more easily and quickly within the form, regardless of whether it's they're adding, editing or viewing data.

5.3. Summary of page design

Open edit pages in a tooltip (E2)

Edit pages as a multi-page wizard (E1-E2)

Open edit pages in the main window

View pages

6. Form design

Forms consist of: Forms should be designed ergonomically for a high level of usability. Minimizing vertical lines and grouping related edit elements are important design criteria. Furthermore, a form should contain as little design elements as possible in order to optimally support the users in their work. Edit fields should correspond with a logical order to support navigation via the Tab key. Anything that doesn't support a user in filling in the form will distract them and should therefore be removed.

In existing applications, all forms should be checked for redundant edit fields. If you have very complicated forms, it's possible that you have edit fields that no longer have a function or are never filled in by users. These ought to be identified and then removed in order to make work easier and speed up processing times.

6.1. Minimizing vertical lines

In forms, the number of vertical lines should be kept as low as possible so that the eye isn't overwhelmed and to keep the form well-balanced.

Wrong




The figure to the above depicts a badly designed form that feels very chaotic due to the large number of vertical lines.

Right




This edit form has the same edit fields but feels clearer and more balanced because the vertical lines have been minimized.

6.2. Positioning labels

Labels should be consistently positioned throughout the whole application so that the flow of reading isn't disturbed.

Labels should always begin with a capital letter and have a clear meaning (using the language of the company, not a whole sentence). Additionally, the labels shouldn't end with a colon.

The label's positioning has an effect on the form's usability, whereby we can only speak of recommendations in this case.

Labels above edit fields




Labels should be left-aligned and positioned above the edit fields. This facilitates legibility and makes the connection between the field labels and edit fields obvious. By arranging the elements vertically, a natural flow of reading from top to bottom, or left to right, is supported. Labels can also have different lengths here without painting a chaotic picture.

Mandatory fields




In general, mandatory fields should be easy to recognize from the moment the user first looks at the form. We recommend specifying a color for mandatory fields. Specifying this color makes it less likely that mandatory fields aren't missed by mistake, speeds up processing times and increases user-friendliness. To further improve the visibility of mandatory fields, you could, for example, insert a star after the label.

6.3. Grouping elements




Dividing a form into meaningful groupings helps the users to find their bearings in the form more quickly. In doing so, more comprehensive edit forms can be consolidated into logical units. Here, blocks of edit fields, drop-down lists or lists are formed and distinguished with an optical separation (10px) between the groupings. We recommend using a distance of 5px between the vertically arranged edit fields. Furthermore, groups should be provided with a heading (Text_H2) so that their affiliation is immediately recognizable. However, if a form only contains a few fields (7 +/- 2), it doesn't make a lot of sense to group the fields.


Drop-down elements within an edit page should, provided it makes sense, be provided with a button (plus icon) for adding a new entry. This would be useful if you want the user to be able to supplement the list. Alternatively, you could use a text button "Add data".

6.5. Checkboxes

Checkboxes are used for selecting alternatives that don't cancel one another out. Here, the label should always be positioned to the right of the box.



If they are vertically arranged, the boxes and labels should be left-aligned one underneath the other.



If they are horizontally arranged, boxes and labels should be position at the same height.

6.6. Form navigation






An application's content is linked together via text links. Text links support the navigation within an application and should therefore be indicated clearly. Without having to think about it, a user should know what they can click on and what they can't. We recommend using a color that corresponds with the design of the application or portal, the overall picture will appear more coherent as a result of this. Text links should stand out clearly from the text body. If the user hovers over the link, we recommend that the text link changes color (dark green in our example) in order to provide the user with visual feedback.

6.6.2. Buttons

Buttons are implemented as function elements. Clicking on a button always triggers an immediate action, for example saving a form. Buttons shouldn't be used to navigate to other pages. Text links are better suited for this purpose. Exception: The buttons "Back" and "Next" can be using for navigating within a wizard. In this case, the buttons are arranged as follows:





With buttons, a distinction is made between primary and secondary buttons. The primary buttons are used for the main action (e.g. save) and should stand out visually from the secondary buttons (e.g. cancel and delete).

6.6.3. "Add data" button






The "Add data" button should be positioned above the content area. If the content area has a grouping, the "Add data" button should be provided at the top right above the grouping. By using a color to make the button stand out, you can guarantee that the action cannot be overlooked.

6.6.4. Buttons within a form




Normally, edit pages for adding new data contain precisely two buttons: "Save" and "Cancel".



Pages used for editing existing data contain three buttons: "Save", "Cancel" and "Delete". The "Save" and "Cancel" buttons should always be available at the bottom right at the end of the form. By arranging the buttons "Save – Cancel", you support the user's natural reading behavior from left to right.

The "Delete" button, which is additionally provided by pages used for editing data, should always be positioned at the bottom left at the end of the form. The spatial separation of the crucial "Delete" button from the main button ("Save") should prevent accidental deletion of the entries. Furthermore, the primary button is highlighted with a different color.

7. More information

Create and edit applications
Application elements
Practical examples: Responsive design