This article will explain the concept and practicalities of working with ‘typicals’.
The typicals feature allows you to easily manage the requirements of objects that frequently reoccur in the Spaces & locations tree of your project. Think of patient rooms in hospitals, classrooms in schools, or segments in road or tunnel projects.
Check out the video below to get an overall impression of this feature, or scroll down to read about all the details.
The concept
In large projects, your spaces & locations tree is likely to contain lots of reoccurring objects, which more or less all need to have the same requirements.
To manage the requirements of such objects, you can define what-we-call typicals. Typicals are spaces (in case of buildings), outdoor spaces, or segments (in case of infrastructure projects) that you can predefine and then use as standardized ‘building blocks’ for the spatial breakdown of your project.
The spaces or segments that you create on the basis of a typical are called instances. Instances automatically get the same requirements as the typical from which they are derived.
To give an example: say that you are working on an office project and you have created a typical called Meeting room, which should be at least 16 square metres in size. You can use this typical to create various meeting rooms in your project decomposition (Meeting room 1, Meeting room 2, etc.) as instances of this typical. These instances will then automatically get the same size requirement.
Also, later changes to a typical will automatically apply to all of its instances. So, if the earlier mentioned size of 16 sqm is changed into 17 sqm, that change will automatically be applied to all the instances as well.
In database lingo, this mechanism is called inheritance.
It is important to know that BriefBuilder’s inheritance mechanism isn’t rigid. You can still make changes to the requirements of an instance, but these are then marked as a deviation from the typical.
To use the same example again: if one of the meeting room instances needs to be slightly bigger than the others, say 18 sqm, you can easily make that change. The only thing that happens is that the changed requirement gets a small marker (a blue dot) that indicates that it is deviating from the typical’s original requirement—which is crucial information for the design team.
Also important to know is that such deviations will be excluded from the inheritance mechanism, based on the assumption that you are making a deliberate deviation, and that you don’t want that deviation to disappear once the typical is updated.
Please note: you can only define typicals for the following object types:
Spaces
Outdoor spaces
Segments
All three object types feature in the Spaces & locations tree. They are also the object types that typically (no pun intended) carry the most requirements, which makes them the prime candidates for this functionality.
Also note that the following non-requirement information is not part of the inheritance mechanism:
– Comments
– Labels
– Verification data
– Analysis data
– RFCs (requests for change)
Another critical exception concerns adjacency relations. We have excluded these from the inheritance routine because these relations, almost by definition, only make sense in an actual project decomposition where you can point to specific spatial objects.
Activating the typicals module
Before explaining the typicals feature in detail, you should know how to activate this module. This is done via the settings in the navigation menu.
1. Go to Navigation menu > Settings > Project model > Modules.
2. Find the Typical objects module under Spaces & locations and activate it by means of the ‘toggle’.
Note: by default, the typicals module is activated when you create a new project model. But typicals aren’t always relevant, so this is also the place where you can easily deactivate the module.
More info about BriefBuilder’s modules can be found here.
Creating typicals
To create a typical, do the following:
1. Go to the Spaces & locations tree (the only tree for which you can define typical objects).
2. There, you will see two starting points: Typical objects and Project objects. As the name already suggests, you have to go to the Typical objects part.
Note: the difference between the typical objects and the project objects part of the tree is quite crucial.
Typical objects: this is where you define a list of the typicals for your project; the standard building blocks, so to speak, that do not yet have an exact quantity or location.
Project objects: this is where you make the actual decomposition of your project, indicating how many spaces or segments you need and where they need to be placed.
3. In the typicals part of the tree, you can create typical objects in the same way as you create objects elsewhere in the model: by using the button.
As explained earlier, you can create spaces, outdoor spaces, and segments as typicals. You can use folders to organize these objects in a neat list.
TIP: When defining typicals, limit yourself to those kinds of objects that are truly repetitive in your project decomposition—say, objects that are used more than four times—otherwise, you are overloading your project with requirements.
Creating instances from typicals
As explained earlier, an instance (e.g., Meeting room 1) is an object that is derived from a typical (e.g., Standard meeting room), which then automatically inherits the requirements from that typical.
There are two ways to create instances from typicals:
(1) Dragging in the tree
When you have created a typical, you can simply ‘drag’ that typical down to the project part of the tree to create an instance of it.
1. Click on the typical that you want to use (or an entire folder with typicals).
2. Hold down your mouse button and drag the typical to the project objects part of tree.
3. Release your mouse button when the typical is in the position where you want it to be.
(2) Selecting ‘create from typical’ when creating a new object
You can also create instances when creating objects in your project decomposition. In that case, you have to do the following:
1. Click on the button in the project part of the tree.
2. Select Create from typical.
3. Select one or more typicals and click on Add.
Note: you can create multiple instances at the same time! Do not forget, however, to add quantities when you are done.
Typical indicators
When creating an instance, you will notice that, in the tree, you will get a green-coloured typical indicator behind the object’s name. This indicator shows the name of the typical to which it is connected.
Important to note: the typical indicators look quite similar to object labels, but those are blue instead of green.
Connecting existing objects to typicals
If you have an existing space or segment in your project decomposition and wish to connect that object to a typical, you can do so on the object’s detail view.
1. Go the object’s detail view and the table Instance of.
2. Click on the icon.
3. Select the typical that you want to connect the spatial object to and click on confirm.
Please note: when performing this action, the original requirements (= the requirements the object had before connecting to the typical) will not be overwritten—you’ll keep them.
The only thing that happens with those requirements is that they will be marked with a blue dot, as deviations, when they differ from the selected typical’s requirements (see also here).
TIP: Getting dizzy of all those labels and indicators? In that case, click on the Hide typical indicators & label button at the top of the tree.
Instance detail view: green, blue and grey dots
As explained earlier, when an object is an instance of a typical, it inherits the requirements from that typical. So, lots of the requirements will be the same, but it is also possible to make changes to those requirements or to add new requirements. These are deviations from the typical.
For the design/delivery team, it will be crucial to know in which way a space or segment is different from its typical. Therefore, we have devised the following color coding scheme:
- A green dot: a requirement that is fully in line with the typical
- A blue dot: a requirement that deviates from the typical
- A grey dot: a requirement that is not tracked for deviations from the typical
Good to know: you can click on the green and blue dots to compare the requirement of the instance object with the one of the typical.
Green dots: in line with typical
Requirements that are exactly the same as those from the typical, are marked with a green dot.
Important to know: these requirements will automatically be kept ‘in sync’ with the typical’s requirements. So, if a requirement is modified at a typical level, that modification will also be made at all of its instances.
Blue dots: deviation from typical
If inherited requirements have been changed at an instance level, they get a blue dot to indicate that this concerns a deviation from the typical.
Important to know: if you make a change to an inherited requirement, that particular requirement will no longer be kept ‘in sync’ with the typical’s requirement. This is based on the assumption that you have made a deliberate choice to deviate from the typical for that particular requirement.
Note: on the detail view, the content of the changed requirements information (e.g., the value or note) will be shown in blue, so that you can easily spot that there is a difference with the typical.
In case you are deleting a relation that is inherited from the typical, this relation will be shown as strike-through, accompanied by a blue dot.
Greys dots: not tracked for deviations from the typical
Grey dots indicate information that is not be part of the tracking mechanism for deviations from the typical.
This usually concerns the objects’ classification or quantity. Also, adjacency relations aren’t tracked for deviations as these can relations can only be created at instance level.
Good to know: for standard properties and classifications/numberings, you can decide yourself whether these should be tracked for deviations or not. See the next section.
Deviation tracking settings
For standard properties and for classifications/numberings, you can decide whether these should be checked for deviations from the typical or not.
For standard properties
Standard properties are by default all set as to be checked for deviations.
There is, however, one exception and that is the property quantity. This is because typicals usually don’t have quantities while their instances do (e.g., a particular number of meeting rooms for a particular department), and you probably don’t want that difference to cause a space or segment to be marked as a genuine deviation.
But this is something that you can easily regulate yourself:
1. Go to Settings > Requirements > Standard properties.
2. Select the appropriate object type (space, outdoor space or segment).
3. Use the check boxes in the column Track deviations to determine whether a property should be checked for deviations or not.
For classifications/numberings
In contrast to standard properties (see above), classifications/numberings are by default all set as not to be checked for deviations.
This is because you probably don’t want a meeting room to be marked as deviating from its typical just because it has a different room number. You can change this in the Settings menu if you wish (check the box ‘Trace deviations’).
1. Go to Settings > Requirements > Classifications/numbering.
2. Select the appropriate tree (Spaces & locations).
3. And then use the check boxes in the column Track deviations to determine whether a classification/numbering property should be checked for deviations or not.
Upgrading project objects to typicals
It is possible that you have created a neat project space or segment that you would like to ‘upgrade’ to a typical. This is something that you can easily do by dragging & dropping that object in the tree.
There are two possibilities:
Create typical on the basis of a project object
This is the option where you create a typical on the basis of project object without removing or deleting the original project object.
This is relevant when you are working on your project decomposition while thinking: this is a very neat space or segment, and I am probably going to need more of those in the rest of my decomposition, so let’s make it a typical of it.
1. Click on the project object that you want to upgrade.
2. Hold down your mouse button and drag the object up to the typicals part of tree.
3. Release your mouse button when the object is in the position where you want it to be.
Note: as you will see, the original project object will stay were it is and it will be linked automatically to the typical that you have just created from it (which you can notice by the fact that it will then have a green ‘typical indicator’ behind its name). See also the image directly below.
Turn a project object into a typical
It is also possible to move a project object to the typicals part of the tree without keeping the original project object.
In that case, you must combine your ‘drag & drop’ action (as described above) with pressing the Shift-button.
Please note: if a project object is transformed into a typical, it will lose its adjacency relations! This is because we do not facilitate adjacency relations between typicals and project objects.
Disconnecting objects from a typical
Sometimes, an instance object has so many deviations from the related typical that it no longer makes sense for it to be an instance of that typical. In that case, you will want to disconnect that spatial object from its typical. This is how you can do that:
1. Go to the table Instance of on the instance object’s detail view.
2. Click on the icon.
3. Click on confirm.
Note: you can also do this from the typical’s detail view. In that case, you have to go to the table Instances and disconnect from there.
Deleting typicals
Typicals can be deleted via the action menu in tree, just like with all other objects. But typicals can only be deleted if they don’t have any instances.
So, before you can delete a typical, you have disconnect it from any spaces or segments in the list of project objects.