I just realized that the wishlist I once compiled for Inquisit 2 (http://www.millisecond.com/forums/Topic1118.aspx) has been covered nearly in its entirety by the new features Sean Draine and his team weaved into Inquisit 3 since then. That's why, at first, I wish to say many, many thanks from a grateful user! This is truly great customer support from a truly great team.
But as software can never satisfy men, I felt now would be a good time to put up a new wishlist from observations I made and issues I stumbled upon while working with Inquisit. I tried to incorporate mostly those nitpicks that at least one other user brought up in the discussions on this forum. So here we go.
(1) Allow <values> as trial timings: The timing/frame specification is one of the roughest edges about Inquisit I am aware of. Variable or adaptive presentation times are impossible to implement with the current logic and above all, changes to the timing of a certain stimulus within a trial event train require to change all subsequent timings accordingly.
(2) Evaluate a <picture> element every time it is used: Many research paradigms involve presenting some target stimulus among a number of distractor elements. These distractor elements are often visually different (e.g., letters in different orientations) but belong to the same conceptual class and thus lend themselves to be defined within the same <item>. It would be intuitive to only declare a single stimulus element for such an item and reuse that multiple times within the same trial. Inquisit precludes such efficient coding since it will evaluate the same stimulus only once at the beginning of a trial and then show exactly this instance on every occasion it is used within that trial.
(3) *SOLVED (http://www.millisecond.com/community/forums/t/1292.aspx)* Make <picture> elements objects that can be passed around: This is a minor one, agreed, but most probably something you will bump into when exploiting the more sophisticated aspects of expression based programming in Inquisit. Many of Dave's examples for efficient coding involve the use of <text> stimuli and the ability to assign a string to the item property of a text stimulus during runtime. This allows for something like
/item = ("<%values.sometext%>")
where you'll only need a few text items in your whole script to display even large numbers of different text stimuli. A similar thing cannot be done for pictures due to the preloading of the associated files. It would nonetheless be a most convenient feature if Inquisit made something like this possible:
/item = ("<%values.somepic%>")
(4) Preserve transparency given in picture files: I never understood why Inquisit, despite its DirectX roots, even ignores the transparency setting of GIF files and instead only provides the ability to set one fixed color transparent manually. Full alpha channel transparency would open Inquisit to a whole new universe of experiments particularly in the vision sciences. Keep in mind, however, that enabling alpha channel transparency would inevitably create the need for PNG support.
(5) Include subject id in data file name: This is self-explanatory. Putting the subject number/id into the data file name when separatefiles=true enables quick selection of files belonging to one subject.
(6) Enhance editor: How about code-folding, syntax highlighting, delimiter matching, an improved search-and-replace dialog with RegEx capabilities, selection search and proper notification about replacement results? There are highly sophisticated free editors on the market which can do all this and much more, why not enable their integration with the Inquisit IDE?
(7) Have a none-visual monkey that executes an experiment as fast as possible (ignoring the trial timings): And at best one who writes out data even after the trial period has expired. I explained that in more detail here, but to put it short, such a monkey would be a blessing to those of us who cannot afford Inquisit licenses for every notebook which scripts are developed on. My ususal routine when compiling a new experiment is to first code the script to the best of my abilities, then let the monkey do a test run, set up analysis and testing routines for the written data, and finally conduct the experiment myself to get a feeling for the possible caveats plus having some real-life data upon which timings can be evaluated. The monkey part is essential since it will reveal any programming flaws, faulty stimulus assignments, improper condition balancing and so forth. Unfortunately, our lab is pretty busy most of the day so computer time is a valued resource. A none-visual monkey that executes the experiment in silence as fast as possible and keeps writing out data would shorten the development process significantly.
I can see that Sean rather have me buy a license for my development notebook but why not offer something like a 20$ development license that writes out data only when in monkey mode. I'd buy one.
(8) Setting mouse cursor coordinates: In many paradigms,
particularly when eyetracking is involved, it is of high importance
where a subject fixates when a stimulus is presented. Not being able to
control where the mouse cursor is positioned if the task involves mouse
movements poses a significant problem.
(9) Expressions in <%...%> context: It would be great if
you could write, for example:
/ items = ("<%concat(capitalize(values.sometext),values.someothertext)%>"
(10) Multiple <values> objects: Why not make <values>
into named objects so that you can have multiple value groups in a
script. Would allow for cleaner, more structured code.
The list will be updated with suggestions appearing in later posts.
Kind regards, Malte
p.s.: Ah, and please fix the editor before launching 184.108.40.206. Its disregard for line endings when copy-pasting drives me nuts.