Dear Inquisit Forum,

I am running a relatively simple task - which is also my first go at Inquisit programming.

The aim of the task is to present a series of images (in this case 240 foods) and for each image ask the same question with a likert scale, with each image being presented once and with the order selected at random.  I have coded this for 3 images, and it is very straight-forward (see my code for the block in question below).

My question is: is there an alternative to typing out every single picture filename under <item foods> in the code at the outset? This is both tedious and error prone, and seems to be an inefficient way to code.

All the images are named with numbers ("001.bmp", "002.bmp", "003.bmp" .... "240.bmp")

There are a number of ways I can think of doing this (from my experience with other testing programming)

1. To have the item list populated at runtime using a loop and adding a filename at each run through the loop, being limited by how many files to look for. 


2. To specify a folder from which to populate the item list. 


3. To evaluate an expression on each trial that determines the picture filename during runtime, for example using / item = ("<% counter.foods.currentvalue %>.bmp") and with a counter selecting a number from 1 to 240 at random on each trial.

I have explored all three - and think they are all impossible with Inquisit. Can anyone with more experience suggest what would be possible?  I am currently considering writing a piece of code elsewhere to make sure I write the list with no syntax errors!

If it is relevant, the task is going to be run using Inquisit Web 3.0.

Many thanks for you help, and if there is more information I can provide, please ask.

Suzanna

The code for the block of Likert trials I am using is pasted below (in this case with only 3 food images):

<block likerthealth>
/ preinstructions=(rate_health)
/ trials = [1-3 = Health]
</block>

<item foods>
/1 = "001.bmp"
/2 = "002.bmp"
/3 = "003.bmp"
</item>

<picture foodpicture>
/ size = (500, 500)
/ items = foods
/ position = (50, 50)
/ select = noreplace
</picture>

<text HealthQ>
/ items = ("How healthy is this food?")
/ position = (50,10)
</text>

<likert Health>
/ anchors = [1="very unhealthy"; 5="very healthy"]
/ stimulusframes = [1 = foodpicture, HealthQ]
/ mouse=false
/ numpoints=5
/ position= (50, 90)
</likert>

<instruct>
/nextkey=(" ")
/prevkey=("a")
/font = ("Arial", -16, 400, 0, 49)
</instruct>

<page rate_health>
Please can you rate how HEALTHY you think the follow foods are on a scale from 1 (very unhealthy) to 5 (very healthy).^^^^
</page>

When Inquisit parses a script it needs to be able to verify that any external files referenced in the script (here: picture files) exist.

Thus the list of pictures must be available at parsing time and indeed cannot be generated at runtime.

The best solution is to write a little script to generate the filenames in your preferred scripting language and paste the resulting list into Inquisit.

Regards,

~Dave

Dave,

Thanks for the speedy reply. I do understand your point about needing to check files at parsing, though I don't see that that fact prevents some other option being possible (during parsing to collect the filenames for all images within a pre-specified folder?).

There is something very neat about coding in Inquisit - it is a very elegant programming language in many ways.  But it does seem at odds with that elegance to ask people to write out long lists of filenames...

For the time being, it is back to perl coding to write this list then!

Many thanks

Suzanna

This would also be error prone (e.g. some picture files might be in the wrong folder; what about the order of elements which may be important in certain designs?) and additionally pulling files from subfolders is not possible in a web context.

There are other factors at play, too, mainly having to do with performance optimization. For example, Inquisit aims to minimize disk access at runtime and thus will try to stuff all pictures into the machines RAM at parsing time (which again requires files be known and verified to exist at parsing time).

While I understand and am sympathetic to your point about elegance, I personally find erring on the conservative side and ensuring (as much as possible) that the program will actually run (instead of failing midway due to e.g. missing files) preferable to the conceivable alternatives.

Best,

~Dave