Step 2 of this process asks whether the user wants to code at selected nodes or all nodes.  If selected nodes are desired, this is the place to clarify just which nodes should be coded to.  Or, a user may choose to have all nodes coded to.  

The other question in this step is to decide how much coding the user would like NVivo to create.  This is a relative measure, and it may help to conduct some initial autocoding-by-pattern runs in order to get a sense of what level of machine-based coding is optimal.  If the slider is set too high towards “More,” there may be irrelevant data coded to particular nodes, which means a user will have a lot of work cleaning up after the computer.  If the slider setting is set too low (towards “Less”), then the computer may miss some relevant information that should have been coded but was not.  This latter scenario means that the user may have to go back through the nodes and sources to ensure that nothing critical was missed.  

Once the selections are made, click “Next.”  

NVivo checks the existing coding patterns.  It will report back whether it has sufficient information to go on.  (It may be good to capture the report in a screenshot in order to have a sense about how to understand and possibly qualify the resulting coding afterwards.)  

Once the necessary decisions have been made, click “Finish”.  

What results is a focus on the main selected nodes, with overlaps of coded information presented in a table.  The darker the color of the cell, the more freshly coded data there is (represented by the number in the cell).  

In this scenario, all the coding by “NV” was automatically accepted into the existing nodes.  (Later, a user could conduct a Coding Comparison Query in order to see where the machine and the human differed, if both coded to everything…or if both coded to at least a discrete part of the project.)  

As noted earlier, it is assumed that there will be human oversight and analysis of the coding achieved by machine. It will be important to omit the code which is not appropriate to a particular node.  It is simple enough to highlight the coding and delete on a case-by-case basis.   

So when would machine-coding based on human patterning be possibly helpful.  After all, most research fields require “close readings” of texts by in-field experts.  There may be contexts in which there are “big data” sets that may not be humanly readable given the volume.  Web-scale contents from social media platforms could be one example of such a large set.  In such cases, "distant reading" by machine counts and machine text summarizations may be desirable.  (Franco Moretti of Stanford University coined the term "distant reading."  This term refers to the uses of computational methods to consume texts and resultant data visualizations--graphs, maps, networks, trees, and other representations--to represent textual contents.  This approach does not preclude human "close reading" except in cases when such consumption is not possible.  This latter case of non-consumptive reading is one in which machine algorithms may be used to explore and probe copyrighted textual contents which are not made available for direct human reading.)  Machine coding could be used to analyze sentiment…with a training set by human coders to indicate which type of emotions or attitudes fit into which categories (and at what strength or “direction”).  

Others have suggested that this pattern-based coding tool could be used to differentiate between particular speakers or interview subjects based on unique “tells.”  (In this case, all known speakers have their works set up in respective nodes. These are human-coded.  Then, unknown transcripts may be introduced…and machine-coded.  Those nodes that share high similarity may be probed further for potential likeness.  (Theoretically, coder “hands” or “fists” could be remembered by the machine and applied to new data.)  

QSR International highlights some contexts when it may not be advisable to use this human-based patterned autocoding.  Nodes that are coded based on sentiment should not be autocoded because NVivo does not apparently capture sentiment--in the sense of word choices, direction of sentiment, degree or strength of sentiment.  (There are text analysis tools that achieve this, but generally, such tools require a fair amount of setup and adjustment, and also reliance on various training text sets that indicate sentiment.)  Likewise, nodes that deal with "attitudes, tones, or emotions" should not be included in pattern-based autocoding.  Any  nodes that involve interpretation of the data (such as through a close reading) will not do well.  And finally, if coding is based on speaker captured on either audio files or videos, researchers should do the coding; they should not hand this over to the machine.  

What NVivo captures in the patterned autocoding includes coding of certain disambiguated term-based phenomena, with words that are original or in original order.  NVivo captures words and their synonyms well.  The clearer the coding, the easier it is for machine emulation.  It may be helpful to think of NVivo as more of a generalist tool without the tailored nuances of pre-set text analysis "thesauruses" and sophisticated stopwords lists.  Computers may be trained to handle nuances well, but it's questionable how much training may be done within a dataset for accurate patterned autocoding.  (Researchers would do well to code the work sufficiently and then run the autocoding feature on a test version of the project to see what the outcomes are...and then to review the outcomes.  It is important to keep a version of the project "pristine" and separate from any patterned autocoding in case the results are not what the researcher or research team wanted.  There is value in reading through the "NV" coding to get a sense of how the computer was emulating the human coding.)  

For more information on autocoding by pattern, visit the QSR site.  It would help immensely for QSR International to share more information about the various algorithms running for "autocoding by existing pattern".  An analogical feature in SPSS is its post hoc "Automatic Data Preparation" report which lists step-by-step all the machine processes that went on under the covers for its Automatic Linear Modeling" (inferential analysis based on data and one output variable).  That step-by-step approach in describing what the machine did does a lot to disambiguate algorithmic processes and makes that research much more transparent and reportable.