Three principles of tree construction in NVivo
Author of this page: Graham R. Gibbs
Affiliation: University of Huddersfield
Date written: 14th Nov. 2005
When creating and modifying you node tree there are a few principles that should guide your actions. Following them will ensure that your tree is tidy, meaningful, consistent, clear and efficient as a representation of your thinking about the data. The following three principles come from a paper by Richards and Richards, two of the authors of NVivo (Richards and Richards 1995). However, note, these are principles and not rules. The software does not require that you follow them, let alone require that you have a tree structure. But by following these principles you will create a node tree that works best for your analysis. The following examples use nodes created as part of a project on people looking for work in the UK.
Principle 1. The children of a node should be cases, in the same sense, of the parent.
An example of this principle can be seen in the children of the node ‘Job Search Strategy’ (the tree fragment in Figure 1.a.). The node ‘Routine’ does not seem to be a strategy or activity in the same sense as the others such as ‘Use of newspapers’ and ‘Word of mouth’. It is really a manner of searching. Any of the other children of the node 'Job Search Strategy' could be done (or not done) in that manner. So a new sibling of 'Job Search Strategy', 'Manner of Searching', should be created and 'Routine' moved to one of its children. The opposite manner of searching, namely haphazard, now seem a possibility so a new node for this, as a sibling of 'Routine' can be created, in the expectation that you might now find some accounts of searching for jobs that are haphazard. (See the tree fragment in Figure 1 b.)
Richards and Richards suggest that if this principle is followed, then the link between nodes up and down the tree should be clear from inspection. It will be kinds to instances, or things to parts, or concepts to examples, and so on.
Figure 1. Constructing a node tree from free nodes.
Principle 2. The description of a given node should apply to all the nodes in the sub-tree below it. The subnodes in a tree should not switch part-way down: that is they must remain generic with respect to the higher categories.
In many ways this restates principle 1 but in the other direction. The conception behind the parent node should apply to all its children. Consider the tree fragment, The nodes ‘Job Searching’, ‘Interviews’ and ‘Not actively searching’ are all topics that respondents offered excuse accounts for in the Job Search project. In addition, the node ‘Job Searching’ has three children, ‘Local’, ‘Regional’ and ‘National’. These code passages about how wide respondents’ search was cast. So these nodes relate to their parent as being examples of breadth or scope of the search and not of the account given. Now the relationships defining the tree switch part-way down. From ‘Excuse accounts’ to its children the relationship is ‘topics of…’, from ‘Job Searching’ to its children the relationship is ‘breadth of…’. This is a recipe for a large and sprawling tree that will tend to have more important nodes hidden away low down in the branches. You might even be tempted, with the tree as it is, to take the node ‘Job Searching’ that appears further down and merge it with the one under ‘Excuse accounts’. This might seem logical, but will only make matters worse. Moreover, it illustrates what is wrong. The nodes ‘Local’, ‘Regional’ and ‘National’ are not really related to ‘Excuse accounts’, they actually categorize different kinds of searching. The answer is not to merge the second ‘Job Searching’ with the first but rather attach the children of the first under a new child of the second – ‘Breadth’. This gives the tree fragment, Figure 2.b. In Figure 2.c. I have suggested some children for ‘Job Searching’ that do remain generic with respect to the root node. They are all types of account. I also took the opportunity to rename the parent node ‘Vacancy Searching’ to prevent confusion with what is now the much broader node ‘Job Searching’ further down the tree.
Figure 2. Tree fragment and improved version.
Principle 3. One topic or idea should occur only in one place in the node tree.
This is a very important principle as it helps eliminate ambiguities and duplication in the tree. If you follow Principles 1 and 2 you should already have eliminated most of these duplications. One example is in Figure 2.b where there was a danger of having two nodes with the same name. That is why I renamed the first ‘Job Searching’ node to ‘Vacancy Searching’. This recognised the different ideas behind the two nodes. The second, broader node is about all those things to do with looking for and getting work. The first (now ‘Vacancy Searching’) is only about the narrow activities of finding a job to apply for. So actually there weren’t two examples of the same topic or idea, just two ideas that initially shared the same name. The examples that offend Principle 3, however, are usually more obvious and more serious. For example, in the Job Search project, respondents were asked for their views about the services on offer to help them find work. Imagine that for each of these we coded how the service was evaluated, how often it was used and how respondents found out about it. This would produce a tree fragment like that in Figure 3 a.
Figure 3. Tree with repeated nodes and improved version.
However, now we have repeated nodes throughout the tree. This makes many things awkward. For instance if we want examine all the text coded at evaluation of services and perhaps compare this with the gender of the person talking we would have great difficulties. We would need manually to find every occurrence of the node ‘Evaluation’ wherever it occurred in the tree, gather all the text together and then make the comparison with gender. Following Principle 3 we should eliminate the repetition. Essentially the nodes ‘Evaluation’, ‘How often used’ and ‘How heard about’ could be moved to become children of the node ‘Work Finding Services’ and the services themselves gathered together as children of a new node ‘Service’. This would produce the tree fragment, Figure 3.b. Now all the discussion on evaluation etc. of the services would be coded at the same node, no matter which service was being referred to. The tree is smaller, avoids repetition and is more efficient. Of course, you might complain, now what if I only want to see the text where people are talking about, say, evaluation of Worklink? There is no longer a node for this. However, in NVivo it is a simple matter to inspect this text using an intersection node search. Whereas in the original tree we would have to search manually and ensure we have found all the nodes on ‘Evaluation’, in the revised tree no manual searching is required, the computer can do it for us. People get bored and can miss things, especially if they are biased by looking for positive cases. So re-arranging the nodes in this way, and using the search tool to look for specifics has important benefits for validity as it avoids the potential errors of a manual search through the node tree.
You might find it hard at first to keep to all three of these principles. Don’t worry about that. Not all researchers feel the need to follow these approaches and in the end you should do what you find useful and helpful in organizing your thinking about the data. As you get more familiar with your data, as you gradually hone your analysis and come to focus on some core ideas, and especially as you start to do certain kinds of searching, you will find that a well-organized node tree, following these principles is a good idea. Above all though, don’t let the difficulty of adhering to these principles stop you from trying to rearrange the node tree. Any attempt at reorganization is good as it will entail your thinking about your data and your coding. Your first attempts at creating a neat node tree will probably fail, but they will be necessary stages on route to a clear analysis of your project.
Richards, L. and Richards, T.J. (1995) Using Hierarchical Categories in Qualitative Data Analysis, in U. Kelle (ed.) Computer-Aided Qualitative Data Analysis. London: Sage.