Computer-assisted behavioral observation systems

With the advent of hand held computer devices, behavioral observation coding evolved from checklists, clipboards and stopwatches to slick GUIs with real-time data storage. Used by ethologists in the field, educators in the classroom, and behavioral scientists across diverse environments including hospitals, homes, and playgrounds these contemporary codings systems have the ability to cover more behaviors with greater specificity and higher reliability [1].

Existing coding systems are either one of two types: open-source or proprietary. Within each type, the scope of the program ranges from a specific topic area addressing a narrow research question to a more general omnibus system, built to cover a wide range of behavioral areas. Proprietary systems tend to be well designed, more often general in their scope, and often expensive. For example, the Noldus Observer XT [2] is typically used to observe human interaction across disparate settings, ranging from parent-child interaction [3] to patient-doctor conferences [4].

Conversely, there are ample, typically open-source, one-off computer programs that address a narrow band of research objectives focusing on specific populations. These are well suited for pilot studies, limited budget projects, or niche research situations. Because of their limited focus, these programs tend to be simple, built with accessible code, and have minimal bloat, either in the code or user interface (UI). pyObs is in this latter genre – built to capture time-stamped behavior, affect, and physical movement in preschool children, this software was a critical component in a multi-year NSF funded project, entitled Peers Across Landscapes (PALs), that sought to describe the genesis of friendships in 3–5 year olds (Li & Griffin, 2013; Torrens & Griffin, 2012).

Structure

pyObs captures naturally-occurring free-play interactions among preschool children [6]. Over the 3 years of the PALs study, from piloting to implementation, the emphasis was on coder accuracy, error-less data entry, and speed. A large team of undergraduates using tablet PCs collected the data; to reduce the likelihood entry mistakes, we focused on making the flow of the Graphical User Interface (GUI) intuitive. Likewise, data entry had to be simple with robust error checking methods.

During the PALs study, assessing interrater reliability commenced from the initial piloting until data collection ended, 2.5 years and 178,565 observations later; Kappa scores ranged from .70 to .99 for all coding structures. Details of the behavioral coding associated with the PALs study are elsewhere [7, 8]. The general scheme was as follows, while watching a randomly chosen child for 10 s, the observer coded the child’s behavior in a naturalistic setting, recording both social and geographic information. Specifically, a coder recorded whether the child was alone, with a teacher, playing with other children, or passively engaged in group behavior through parallel play – children are playing in proximity to each other, but not with each other.

After determining the appropriate code, observers next recorded the associated affect: positive, negative, or neutral while in the presence of social peers – those involved in direct interaction, or area peers – those in the physical vicinity but not interacting with the target child. The specificity of the data, along with its breath, enabled us to analyze how activity type and physical location commingled to influence micro-social processes among preschool children. See Figure 1 for a schematic of this procedure.

Data Flow

As shown in Figure 1, pyObs has 5 primary components relating to the target child: Behavior, Task, Peers, Affect, and Physical Location. Within pyObs’ architecture, assuming the selected child is present and available, relevant interconnected menu boxes require completion before submission for data storage. Figure 2 illustrates the GUI data entry flow. Elaboration of the study and the coding procedure is available elsewhere [7, 8].

GUI

Using pyObs requires minimal computer programing skills. As shown in Figure 3, data gets entered via drop down menus or check boxes. pyObs populates the selection options using either external or internal lists, depending on researcher preference. Output goes to the local directory unless directed elsewhere via an external configuration file. Data are saved as simple ascii text in csv format; in turn, these output are easily converted to a pandas DataFrame, a SQL database or a spreadsheet for subsequent manipulation and statistical analysis.

Depending on specific operating platform requirements, it may be necessary to make minor adjustments (e.g., directory dependences, color schemes) but the code should transfer without modification. Python programing etiquette encourages small modules, each reflecting a different function; conversely, pyObs is a single module. Because the PALs project required frequent updating across hand-held devices (e.g., Windows based tablets with a digitizer pen), to minimize the likelihood of introducing errors, we decided in the development phase that a large single module was preferable to multiple smaller modules. Although not ideal from the perspective of a programmer, this strategy ensures rapid and error free updating across machines. pyObs’ GUI uses wxPython [9], a wrapper for the cross-platform GUI API wxWidgets, written in C++. Coders used the digitizer pen to move through the appropriate sequence of drop down menus and check boxes (see Figure 3). Instead of a digitizer pen, current technology allows data entry using a touchscreen.

Variants

As pyObs evolved, novel research opportunities arose, resulting in two variants that capture selected micro-features of social interaction among children. Building a typical variant of pyObs, such as those described below, requires modifying small sections of original code. Because pyObs was built as an omnibus behavioral observation coding system, with its myriad components, changes made to the pyObs code usually are done by either removing or commenting out irrelevant functions and, if needed, modifying the appropriate GUI boxes locations and titles. This takes minimal time and programmer experience.

Additionally, depending on the researcher’s preference, populating the choices shown in the GUI are done using either an internal list or an external text configuration file. Although in pyObs the child’s range of activities are hard coded in the python module it is sometimes easier to use an external file. For example, the following function, taken from the VisualAttention variant described below, uses the activityList.txt file. Contained within the file is a list showing the range of possible child activities (e.g., nap, playgroup). To modify the range, the researcher simply alters the list.

def   GetActivityList (self):
      activityList = []
      f = open (‘activityList.txt’)
      line = f.readline ()
      while (len (line)>0):
          line = line.strip ().split (‘,’)
          if len (line) == 1:
              activityList.append (“)
          else:
              activityList.append (line[1])
          line = f.readline ()
      f.close ()
      return activityList

Archive

Name: Zenodo

Persistent identifier:https://doi.org/10.5281/zenodo.804072

Licence: MIT

Publisher: William Griffin

Version published: 2.2.1

Date published: 07/06/17

Code repository

Name: Github

Persistent identifier:https://github.com/billgriffin/pyObs

Licence: MIT

Date published: 07/06/17