{"id":347,"date":"2018-09-23T14:56:20","date_gmt":"2018-09-23T14:56:20","guid":{"rendered":"https:\/\/lab.florianschwarz.net\/PennController\/?post_type=yada_wiki&p=347"},"modified":"2018-11-12T21:28:23","modified_gmt":"2018-11-12T21:28:23","slug":"ontology","status":"publish","type":"yada_wiki","link":"https:\/\/lab.florianschwarz.net\/PennController\/wiki\/ontology\/","title":{"rendered":"Ontology"},"content":{"rendered":"

<\/menuToc>\n

Elements<\/h1>\n

The basic units of a PennController trial are elements<\/strong>: every command relates to an element.<\/p>\n

There are no clear-cut types<\/em> of elements: one element can have visual<\/strong> content (e.g., Text<\/a>, Image<\/a> elements) or audio<\/strong> content (e.g., Audio<\/a> elements), it can stand as an interface<\/strong> to collect responses (e.g., Key<\/a> elements). More often than not, an element shares several of those properties: for instance, Scale<\/a> elements both show buttons and collect scores, and VoiceRecorder<\/a> elements show buttons to record audio and play back the recordings to be collected.<\/p>\n

There are two ways to manipulate elements: either by creating a new element<\/strong>, or by referring back to an existing element<\/strong>. In this documentation, you will see scripts with blocks of lines separated by commas: the first lines of the blocks always start with new<\/code> or get<\/code>. All the lines below the first one that start with .<\/code> relate to the element in the first line. To give an illustration, consider the bit of script below: its first line creates an Audio<\/a> element, its second line starts playing it, and its third line tells the script to wait until the end of the playback before proceeding (more about this point later).<\/p>\n

[js try=”true”]newAudio(“myAudio”, “test.mp3”)
\n .play()
\n .wait()
\n[\/js]<\/p>\n

Commands<\/h1>\n

In the code above, play<\/code> and wait<\/code> are commands<\/strong> that relate to the newly created element named myAudio<\/em>. As just mentioned, commands start with .<\/code> and refer to an element (with Clear command<\/a> exceptions<\/a> as of PennConroller beta 0.2). The list of commands for a given element are specific to its category<\/strong>. For instance, there is no command wait<\/code> for Text<\/a> elements. There is a command wait<\/code> both for Audio<\/a> and for Key<\/a> elements, though its meaning is element-dependent: in the case of Audio elements it means “wait until the audio has ended<\/em>,” whereas in the case of Key elements it means “wait until the key has been pressed<\/em>.” That being said, you can find a list of commands shared by all elements on the page Standard Element Commands<\/a> (note that some of those commands simply have no effect on some elements—e.g., aesthetic commands have no effect on Key elements).<\/p>\n

Flow of evaluation and execution<\/h2>\n

To design your PennController<\/em> trials, you write scripts that consist of series of blocks<\/strong> of commands like the one given above as an illustration, separated by commas and contained within the parentheses of PennController( )<\/code>. When a trial is run, it starts by reading the very first commands of the very first block. Let us walk through a basic example:<\/p>\n

[js try=”true”]newButton(“myButton”, “Click”)
\n .print()
\n,
\nnewAudio(“myAudio”, “test.mp3”)
\n .play()
\n .wait()
\n .print()
\n,
\ngetButton(“myButton”)
\n .wait()
\n[\/js]<\/p>\n

The script starts by reading the first block, which itself starts with newButton(\"myButton\", \"Click\")<\/code>: the script creates a Button<\/a> element named myButton<\/em>, which will read Click<\/em> when displayed. This block will be about this Button element. Immediately after<\/em><\/strong> creating the element, the script reads what comes next, .print()<\/code>, and therefore adds the button to the screen. So far, the screen only contains a button that says Click<\/em>. Immediately after<\/em><\/strong> adding the button to the screen, the script encounters a comma, and it starts reading the second block. Note that the script keeps on reading: it does not wait for a click on the button, as it was not commanded to do so. It now reads newAudio(\"myAudio\", \"test.mp3\")<\/code> and therefore creates a new Audio element named myAudio<\/em>, using the file test.mp3<\/em>: this block will be about this Audio element. Immediately after<\/em><\/strong> creating the element, the script reads what comes next, .play()<\/code>, and therefore starts playing the audio. Immediately after<\/em><\/strong> starting<\/em> playing the audio, the script reads .wait()<\/code> and therefore knows that it has to wait until the audio has ended playing before continuing reading. While the audio is playing, the Click<\/em> button is still displayed on the screen, but clicks have no effect (this is just a button that says Click<\/em>, nothing more). Then, after the audio has ended playing<\/em><\/strong> (and regardless of whether the button was clicked), the script continues and reads .print()<\/code>, which means (in the context of an Audio element) it should add buttons to the page to provide control over the playback of the audio. So far, the script has already added a button to the page, so the controls appear below that button. Immediately after<\/em><\/strong> adding those controls, the script encounters a comma and starts reading the third block, which starts with getButton(\"myButton\")<\/code>: the third block will be about the Button element that was created in the first block. The script immediately<\/strong> reads .wait()<\/code> and therefore knows that is has to wait until the button is clicked. So far, the page displays a button that says Click<\/em>, above controls for the audio. Until the Click<\/em> button is clicked, the controls can be used to replay the audio, pause it, change its volume, …: the script is on hold<\/em> until the Click<\/em> button is clicked. Immediately after<\/em><\/strong> the Click<\/em> button is clicked, the script resumes and reaches the end: this is the end of the trial, the page is refreshed and the experiment proceeds to the next screen.<\/p>\n

PLEASE NOTE<\/strong> that this walk-through did not talk about lines<\/em> or about spaces<\/em>, for the simple reason that you could remove all<\/em> the linebreaks and all<\/em> the spaces<\/strong> from the script above and it would still work the same: it only cares about .<\/code> and ,<\/code> to determine what bits of text to evaluate (and, to some extent, (<\/code> and )<\/code>). The linebreaks and spaces are there for us humans: without them, the script becomes much less readable (to us). By convention, the scripts in this documentation follow spacing and linebreak conventions thought to make things clearer, but do not be surprised to find scripts that do not follow the same conventions, and feel free to adapt your scripts to your own style.<\/p>\n

Types of commands<\/h2>\n

Commands are divided in three types<\/strong>, and you will accordingly find them listed in types in this documentation.<\/p>\n

Actions<\/h3>\n

Action<\/strong> commands are usually active verbs, like play<\/code> or wait<\/code> above. Actions usually do<\/strong> at least one of three things: they add visual content to page (e.g., print<\/code>), they trigger an event (e.g., play<\/code>) or they pause the script (wait<\/code>). Other commands can have similar effects but are still better conceived of as settings<\/em> rather than actions (see below).<\/p>\n

Actions tend to be element-specific and to have element-depdendent meanings (though see Standard Element Commands<\/a>). They also tend to correspond to what you would intuitively use<\/strong> the elements for: print<\/code>ing some text, play<\/code>ing audios, start<\/code>ing a timer<\/a>…<\/p>\n

Settings<\/h3>\n

Setting<\/em> commands are always preceded with .settings<\/code>, even when they come after another setting<\/em> command in the block:<\/p>\n

[js try=”true”]newText(“myText”, “Hello world.”)
\n .settings.color(“green”)
\n .settings.bold()
\n .settings.italic()
\n .print()
\n[\/js]<\/p>\n

In the code above, you cannot<\/strong> replace .settings.bold()<\/code> with simply .bold()<\/code> or .settings.italic()<\/code> with simply .italic()<\/code> (even if you cleverly add spaces\/tabs to horizontally align them with .color()<\/code> in the second line—see PLEASE NOTE<\/em> at the end of the section Flow of evaluation and execution<\/em>).<\/p>\n

Settings are usually not<\/strong> active verbs and can be participles<\/strong>, adjectives<\/strong> or nouns<\/strong> (though there are some exceptions). They tend to affect attributes<\/em> or properties<\/em> of elements, such as aesthetics (as illustrated above) but they can also act on future behaviors<\/em> of the elements: for instance, using .settings.once()<\/code> on a Button element will tell it that it should become disabled after (if) it is clicked. Another way of thinking about this is in terms of what happens when<\/em>, or in terms of listening to events<\/em>.<\/p>\n

Even though settings tend to not have the punctuality of actions, they still are evaluated and executed in sequence (see the section Flow of evaluation and execution<\/em> above). In the code below, the text of the first button does not appear boldfaced until it is clicked, because wait<\/code> is executed before .settings.bold<\/code> is evaluated. By contrast, the text of the second button appears boldfaced from the moment it is displayed on, because it is evaluated and executed before print<\/code> gets evaluated.<\/p>\n

[js try=”true”]newButton(“first”, “Click me!”)
\n .print()
\n .wait()
\n .settings.bold()
\n,
\nnewButton(“second”, “Button 2”)
\n .settings.bold()
\n .print()
\n .wait()
\n[\/js]<\/p>\n

Tests<\/h3>\n

Test<\/em> commands are always preceded with .test<\/code> and are of a very different nature from actions<\/em> and settings<\/em>. They can mostly be used in two contexts: as a new block to define conditional branching<\/strong>, or within certain commands (such as wait<\/code>) to define conditions of success<\/strong>.<\/p>\n

You can always associate a block of command(s) to be evaluated and executed upon success<\/strong> of the test, and a block of command(s) to be evaluated and executed upon failure<\/strong> of the test.<\/p>\n

[js try=”true”]newAudio(“yarrel”, “test.mp3”)
\n .play()
\n .wait()
\n,
\nnewTextInput(“heard”, “”)
\n .settings.before( newText(“left”, “It said “) )
\n .print()
\n .wait()
\n,
\ngetTextInput(“heard”)
\n .test.text( “laurel” )
\n .success(
\n newText(“laurel”, “Yes, you are right, any other response would be wrong.”)
\n .print()
\n )
\n .failure(
\n newText(“yanny”, “You should pay more attention next time…”)
\n .print()
\n )
\n[\/js]<\/p>\n

This script plays the audio file test.mp3<\/em> and, after it is done playing it, invites the participant to enter what they heard. If what they have typed in the input box when they press enter\/return<\/em> is laurel<\/em>, what is inside the parentheses of success<\/code> is evaluated and executed: a text appears below the input box saying Yes, your are right, any other response would be wrong<\/em>. If the content of the input box is different from laurel<\/em>, what is inside the parentheses of failure<\/code> is evaluated and executed: a text appears below the input box saying You should pay more attention next time<\/em>.<\/p>\n

Note that tests do not pause the flow of evaluation and execution.<\/strong> That is, if you removed the wait<\/code> command from the second block above, the command .test.text<\/code> would then be evaluated and executed immediately after<\/strong> the input is added to the page, and therefore the content of success<\/code> would never be evaluated and executed, because the text of the input box is empty (and so, different from laurel<\/em>) when it is added to the page. Instead, the content of failure<\/code> would automatically be evaluated and executed.<\/p>\n

To know what happens when you use a test command within another command<\/strong>, read the documentation about that other command (only wait<\/code> commands accept tests as of PennController 1.1).<\/p>\n

testNot, and, or<\/h3>\n

Test commands in PennController are compositional to a certain extent. You can express the negation of any test by replacing test<\/code> by testNot<\/code>. The code below, where we replaced test<\/code> with testNot<\/code> and switched success<\/code> and failure<\/code>, has exactly the same effect as the code above:<\/p>\n

[js try=”true”]newAudio(“yarrel”, “test.mp3”)
\n .play()
\n .wait()
\n,
\nnewTextInput(“heard”, “”)
\n .settings.before( newText(“left”, “It said “) )
\n .print()
\n .wait()
\n,
\ngetTextInput(“heard”)
\n .testNot.text( “laurel” )
\n .success(
\n newText(“yanny”, “You should pay more attention next time…”)
\n .print()
\n )
\n .failure(
\n newText(“laurel”, “Yes, you are right, any other response would be wrong.”)
\n .print()
\n )
\n[\/js]<\/p>\n

Since PennController 1.1, you can test whether several tests are successful using the special keyword and<\/code>, for instance:<\/p>\n

[js try=”true”]newAudio(“yarrel”, “test.mp3”)
\n .play()
\n .wait()
\n,
\nnewTextInput(“heard”, “”)
\n .settings.before( newText(“left”, “It said “) )
\n .print()
\n .wait()
\n,
\ngetTextInput(“heard”)
\n .testNot.text( “laurel” )
\n .and( getTextInput(“heard”).testNot.text( “yanny” ) )
\n .success( \/\/ Success means “neither laurel nor yanny”
\n newText(“other”, “You follow the Middle Path.”)
\n .print()
\n )
\n .failure( \/\/ Failure means “either laurel or yanny”
\n newText(“laurelOrYanny”, “You come from a bimodal distribution.”)
\n .print()
\n )
\n[\/js]<\/p>\n

Besides and<\/code>, PennController 1.1 introduces the keyword or<\/code>. The code above can therefore be reformulated as:<\/p>\n

[js try=”true”]newAudio(“yarrel”, “test.mp3”)
\n .play()
\n .wait()
\n,
\nnewTextInput(“heard”, “”)
\n .settings.before( newText(“left”, “It said “) )
\n .print()
\n .wait()
\n,
\ngetTextInput(“heard”)
\n .test.text( “laurel” )
\n .or( getTextInput(“heard”).test.text( “yanny” ) )
\n .success( \/\/ Success means “either laurel or yanny”
\n newText(“laurelOrYanny”, “You come from a bimodal distribution.”)
\n .print()
\n )
\n .failure( \/\/ Failure means “neither laurel nor yanny”
\n newText(“other”, “You follow the Middle Path.”)
\n .print()
\n )
\n[\/js]<\/p>\n

Note that series of and<\/code> and or<\/code>‘s<\/strong> are evaluated linearly. As a result, a test of the form A and B or C and D<\/code> will be successful only if D<\/code> is successful, and either C<\/code> or A and B<\/code> is successful, i.e. ( (A and B) or C ) and D<\/code>. If you want to express (A and B) or (C and D)<\/code> you should call the last and<\/code> on C<\/code> itself:<\/p>\n

[js try=”true”]newAudio(“yarrel”, “test.mp3”)
\n .print()
\n,
\nnewTextInput(“heard”, “”)
\n .settings.before( newText(“left”, “It said “) )
\n .print()
\n .wait()
\n,
\ngetAudio(“yarrel”)
\n .test.hasPlayed()
\n .and( getTextInput(“heard”).testNot.text(“”) )
\n .or (
\n getAudio(“yarrel”)
\n .testNot.hasPlayed()
\n .and( getTextInput(“heard”).test.text(“”) )
\n )
\n .success( \/\/ (Played & input) or (neither played nor input)
\n newText(“consistent”, “You are a reasonable person.”)
\n .print()
\n )
\n .failure( \/\/ Played but no input, or input bot not played
\n newText(“inconsistent”, “You missed one step.”)
\n .print()
\n )
\n[\/js]<\/p>\n

The code above prints “You are a reasonable person.” after a press on return in the text input box in two conditions: audio has not been played back and the box is empty, or the audio has been played and the input box is not empty. In all other conditions, it prints “You missed one step.”<\/p>\n

Defaults<\/h1>\n

This page starts with a lie: some commands actually do not<\/em> relate to an<\/em> element. First, there are two special<\/a> cases<\/a>. But what is more, there are default<\/strong> commands. Say your trial contains lots of italic text lines: you need to create as many Text elements (though you may also consider using an Html<\/a> element). But it could quickly feel repetitive to call print<\/code> on every single Text element that you create. To spare you such unnecessary efforts, you can use defaults, like this:<\/p>\n

[js]defaultText
\n .settings.italic()
\n .print()
\n[\/js]<\/p>\n

Now whenever you add a line starting with newText<\/code> to your script, it is as if you actually added two lines right below it: a first line saying .settings.italic()<\/code> and a second line saying .print()<\/code>.<\/p>\n

As another illustration, note that this:<\/p>\n

[js try=”true”]defaultButton
\n .print()
\n .wait()
\n,
\nnewButton(“first”, “Button 1”)
\n .remove()
\n,
\nnewButton(“second”, “Button 2”)
\n[\/js]<\/p>\n

is equivalent to:<\/p>\n

[js try=”true”]newButton(“first”, “Button 1”)
\n .print()
\n .wait()
\n .remove()
\n,
\nnewButton(“second”, “Button 2”)
\n .print()
\n .wait()
\n[\/js]<\/p>\n

You use blocks starting with default<\/code> the same way that you would use blocks starting with new<\/code> or get<\/code>. Elements created before a default<\/code> is encountered are not affected by it (see the section Flow of evaluation and execution<\/em> above to understand why).<\/p><\/div>
\n

Index<\/h3>\n