Creating Template Blueprint (draw.io)

Creating Template Blueprint (draw.io)

Intro

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.

The tool

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.

http://draw.io/

The start

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.




Drawing your manuals (documentation)

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.


Page enterable or not

You can indicate that a page is enterable by making the title field bold.

Making your manual modular

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.

1: Through preferences and company preferences, you can go to label management. Here you can create as many labels as you want and use them to label your chapters. This can be useful, for example, to give chapters that are always present such as H1 and H2 the label “General”, and to give chapters that belong to a specific module a different label. Once your manual is imported into the customer environment, you can switch all chapters with a specific label on or off.

You can represent this by selecting a component and assigning it a color on the right side.


2: Another way to make your manual modular is by letting manuals work together. By editing a chapter, you can indicate that it shares its answer with another chapter. For example, you can synchronize clause 4.1 from ISO 9001 with clause 4.1 from ISO 14001. This can be represented as follows.



In this situation, several things happen.

  1. As shown, two manuals are created. You can create as many as you want, and the answers entered in one chapter can be synchronized with another chapter.
  2. This synchronization is generally indicated with a blue line. The color of the line can be adjusted on the right side when the line is selected.
  3. In addition, the line has an arrow on both ends. This can also be adjusted on the right side when the line is selected.

More information about this, including the pros and cons, can be found in the related This article.

Drawing your forms (registrations)

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.

Hidden fields

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:


Complex logic

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.

Notifications

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.


Field groups

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.


Conclusion

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.


    • Related Articles

    • How do you integrate your management system in logical order?

      Into We are often asked what things need to be arranged before I can use the system as an organization. There is no single answer to this. Many factors determine the steps and therefore the lead time of an implementation. Of course, we can show a ...
    • Platform construction

      Intro ISO2HANDLE can be compared to a box with LEGO bricks. With these bricks, you can build almost anything. But how do you get from the box with all the bricks to the image on the box? Users generally start from the other side, namely from the ...