Once you become familiar with the basics of the Berkeley Studio, it is important to get a grip of the structure of decision trees. If you are not familiar with graphs, nodes and variables we advise you to take a look at the first steps in the Studio and the introduction to graphs and subgraphs.
Graphs, nodes and variables
Each model is composed of three main elements. Graphs contain nodes and connections between nodes, and each node in turn contains actions. While the actions (text, questions) in the end determine what your model will do, nodes and graphs will make up the structure of the model.
Each and every element in the Studio has its own name. This name is not only useful for creating the model, you can also use it to refer to the element. For example, if a user answered a question, you can show the answer to that question in a conclusion later on.
It is important to name all graphs, nodes and variables well. Consider the difference between
Both could refer to a phone number, but in the second case it is much more clear what the graph, node and variable are all about. Furthermore, by adding ‘g_’ to graphs you and other people can easily recognise them.
Structuring your models using subgraphs
In order to keep models maintainable and allow you and others to understand them, you should pay attention to the structure of your model. This is not that much of a problem if your model is small, but large ones tend to become very hard to understand. Consider a model with one hundred nodes. Not only do they not fit on a screen, it also becomes hard to track which node does what.
To prevent this, you should use subgraphs. Subgraphs are graphs within other graphs, usually created to do a specific thing. For example, say we need a model that asks personal information about you and (possibly) about your partner. You would need to create the questions for both you and your partner!
The solution is to create a subgraph that contains all questions regarding personal information. We will now give an example of using subgraphs.
Consider the case mentioned above: we need information about the user and possibly his or her partner. We need both basic information and contact information. Initially, one might come up with the following graph:
However, imagine what happens when we add more questions! Or what if we need to ask information about more people? We need to recreate the nodes basic_information and contact_information over and over again. Furthermore, if we add another set of questions we need to do it twice. This is where subgraphs come in:
This works as illustrated below: each time you use a callgraph action (
Actions > Call Graph), the Studio will run through that entire graph and only when it’s finished continue to the next node.
In order to create your own subgraphs, you will need to add your own graph first. This can be done with clicking via
Graph > New Graph. This will automatically create a call to the graph, which you can delete if unwanted. Put everything you want in your new graph, and add a Call Graph whenever you need it!
If you use subgraphs, you will probably need to access information the user entered in the graphs. Recall that you can refer to any variable with
graph.node.variable. The only problem here is that we use g_information multiple times! The Berkeley Studio uses numbers in order to address this problem. The first time a graph is called, it is labelled g_information, the second time g_information and so on. You can use this to refer to specific cases! In our example, g_information refers to the users information and g_information refers to his or her partner’s information.
Important: note that graphs start counting from zero! The first graph will always be g_graph, not g_graph.
Repeating a graph
You can of course use a graph for two people as demonstrated above, but it might also happen that you need to go through an (un)known amount of people. In that case, you will need a repetition of the graph. To do so, you can Repeat your Call Graph. For more information on repeating, see the introduction to repeating and further.