Before you start building directly in ISO2HANDLE, we always recommend first thinking about what you exactly want to build and how it should relate to each other. It is worthwhile to draw this out, because it makes it visual and you will start seeing many things you had not thought about before.
To do this properly, we have created a kind of “standard” that fits very well with the possibilities in ISO2HANDLE. In this article we try to explain this standard.
There are many UML tools that you can use for this, such as Microsoft Visio, but we generally use Draw.io. This free tool offers many possibilities and is ideal to draw what you want to create.
When you start Draw.io, you can indicate whether you want to create a new drawing or adjust an existing one. You can decide where to save it and finally choose a template.
We usually use the third option under the heading “Flowcharts”.
We choose this option because the template already provides a very usable setup. This setup looks like this.
These components contain a title field and rows, and they can be linked to each other. This is quite representative of the basic setup in ISO2HANDLE.
The next thing we usually do is create two tabs. One for the manual and one for the forms.
We usually represent manuals as a tree structure made up of chapters. The advantage of these components is that when you hover over them, a green circle appears. From that moment, you can click and drag to connect components with arrows. For example, you can create the following structure.
This is a fairly simple tree structure of our manual. You can make this as large or as small as you want.
You can indicate that a page is enterable by making the title field bold.
The next step is to make your manual modular. This can be done in two ways, by using labels or by creating multiple manuals that work together. Both methods are explained below.
You can represent this by selecting a component and assigning it a color on the right side.
In this situation, several things happen.
More information about this, including the pros and cons, can be found in the related This article.
Once the tree structure has been outlined, it is time to focus on the forms.
We draw these in the second tab and start with a single component. This component already contains several rows by default, and these rows can represent elements.
For example, you can draw a very simple complaint form.
The next step is reusing forms and their data in other forms.
This can be done by drawing lines in the same way:
Here you can see that the department element in the complaint form offers the options that are defined in the department form. This is useful because it creates one central list of departments that can be used as input for many other forms. In this case, the “Departments” form functions as a list input. It is therefore logical to create this form as a table form.
We represent this by coloring the component green. A standard form is shown in blue.
It is important to understand that the rows in the forms represent elements, not the data within those elements. If you want to represent data as well, this is usually done as follows.
In this way, you can draw an entire landscape of forms. In many cases, you will also need a user selector.
We show this as a yellow component because it is always present and is not truly a form.
It can also be useful to make certain fields conditional. For example, a question is only asked when it relates to a specific image field. This can be represented as follows.
In this example, we indicate that when the department is “ICT”, the question “Is … correct” should be asked.
In the same way, it is possible through data transfer to include information from an underlying form in the form being filled in.
This is useful for building further logic or for using a form as a Configuration form:
Forms can contain various types of complex logic. For example, data transfer can be used to retrieve data from an underlying form. This is indicated with red lines.
Values can also be taken from another field using a trigger. This type of trigger is indicated with green lines.
Finally, fields can be used to filter other fields. This is indicated with blue lines.
For example, you can create the following drawing.
In this drawing, an accommodation type is defined first. This accommodation can have a heater and, if so, it has a heater type. Next, an accommodation can be added, where the accommodation type is selected.
As soon as this is done, several values are filled in automatically, such as whether the accommodation has a heater and which heater type applies. These are two hidden fields.
Next, the user can choose a heater type, but the correct heater type is already filled in by default.
Finally, the heater type field filters the options in the heater field.
It is also useful to include automations in the overall overview, so it is clear when notifications are sent and why. This is usually represented with a red diamond.
For long forms, it is also possible to use element groups. These can be visualized by giving the rows a distinct color. The specific color does not matter in this context.
This is, in short, how our authors draw their systems before they start building. If you have questions, suggestions or ideas, you can leave a comment below.