Inquisit 3 wishlist


Author
Message
Blackadder
Blackadder
Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)
Group: Forum Members
Posts: 280, Visits: 147

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


  <text illshowanything>
  /item = ("<%values.sometext%>")
  </text>


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:


  <picture illshowanything>

  /item = ("<%values.somepic%>")

  </picture>


(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 3.0.5.0. Its disregard for line endings when copy-pasting drives me nuts.



Dave
Dave
Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)Supreme Being (968K reputation)
Group: Administrators
Posts: 11K, Visits: 74K

First, I'd like to second all of Malte's well thought out suggestions -- many of these are also on my list (I really have one) plus a lot more.



(3) 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


  <text illshowanything>
  /item = ("<%values.sometext%>")
  </text>


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:


  <picture illshowanything>

  /item = ("<%values.somepic%>")

  </picture>



However, this should already be possible. Indeed (as you noted), to get this to work you have to make sure that the picture files get preloaded (or parsed) at the very beginning of the experiment. To that end, I usually stuff all these pictures into an <item> element:


<item picstopassaround>
/ 1 = "apicture.jpg"
/ 2 = "anotherpicture.jpg"
/ 3 = "yetanotherpicture.jpg"
[...]
</item>


Note that you do *not* need an actual <picture> element that would reference the above <item> element (via '/ items = picstopassaround'). The picture files contained in the item element will be parsed and thus will be adressable by their names (e.g. "apicture.jpg") and can be handled just like text strings via


<picture illshowanything>
/ items = ("<%values.somepic%>")
[...]
</picture>


or similar techniques.


~Dave


Blackadder
Blackadder
Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)
Group: Forum Members
Posts: 280, Visits: 147

I created a new thread for this. See here: http://www.millisecond.com/forums/Topic3960.aspx


Blackadder
Blackadder
Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)
Group: Forum Members
Posts: 280, Visits: 147

(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.



Malte.


seandr
seandr
Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)
Group: Administrators
Posts: 1.3K, Visits: 1.1K

Hi Malte,


Thanks much for the feature suggestions. Here are some comments:


1) Without doubt, this feature would simplify programming for a lot of Inquisit scripts, and I've gotten a lot of requests for this (including a coupe from Dave, as I recall). It's on top of the list for Inquisit 4. At a minimum, this will be supported via expressions (e.g., trial.example.stimulusframes.3 = picture.mask;). Possibly this could be added to the the /stimulusframes command itself, although that might make the syntax of that command too complicated or lead to some ambiguities.


2) I agree, also a good feature to have, and also on the list.


3) As Dave pointed out, the only trick is to make sure you have an <item> set defined for all of the pictures so that Inquisit preloads them. Having done that, you can assign the items to any given <picture> element. I've thought about adding the ability to load picture files on demand, but that could introduce timing delays into an experiment, and cause situations where the experiment fails at run time (as opposed to compile time) because it can't find a picture file.


4) The only reason this hasn't been done is that Inquisit uses DirectDraw, the 2D graphics API, which does not have support for alpha-blending. Moving to Direct3D is a possibility, but unfortunately, Direct3D doesn't play well with the standard Windows APIs for presenting text, video, buttons, textboxes, etc. In any case, I agree this would be a good thing, and it's on the list.


5) Yes, this makes perfect sense.


6) Great suggestion, and you are probably right about being able to purchase such an editor.


7) Great idea, I've often wished I had a "fast" monkey. I will also consider enabling saving monkey data (both fast and slow) in evaluation mode. This definitely seems reasonable. I have a number of other ideas for making the monkey smarter as well.


8) Shouldn't be hard to add. Of course, this is going to "recalibrate" the relationship between the mouse on the pad and the cursor on the screen, but I'll assume that's acceptable.





Tags
seandr
seandr
Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)
Group: Administrators
Posts: 1.3K, Visits: 1.1K

BTW - while we're on the subject, here are a few other expression enhancements I'm planning to add:


1) Increment operators (e.g., values.duration += 200; values.trialcount++; values.remainingtrials--; values.score *= 10)


2) Methods on objects (e.g., counter.targets.additem("foo"); )


3) Expressions in list attributes (e.g., /trials = [1-10 = noreplace(counter.group1picker, counter.group2picker, values.distractortrial)] ). This allows higher order randomization, such as randomly selecting from sets that randomly select trials, stimuli, or blocks.


4) if->else if->else if->else if->else


5) More events where logic can be inserted (e.g., element.onload , stimulus.onprepare, stimulus.onselect, counter.onselect)


6) possibly some simple loops, such as while (true) { } and do{} while(true), although not sure about this one yet


Anything else you'd like to see?


-Sean




Blackadder
Blackadder
Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)
Group: Forum Members
Posts: 280, Visits: 147

About the editor issue: I didn't mean to purchase such an editor (either by Millisecond or the user) but resort to the free alternatives out there. For example, Scintilla (http://www.scintilla.org/) is a free editor component, the license of which permits to even use it in commercial projects. My idea would be to provide the option of integrating certain editors into Inquisit and use them as an alternative to the built-in component.



My opinion about the expression enhancements:


1) Increment operators (e.g., values.duration += 200; values.trialcount++; values.remainingtrials--; values.score *= 10)


Very nice to have but not a must.



2) Methods on objects (e.g., counter.targets.additem("foo"); )


From a programmer's perspective: YES. From a user's perspective: You can do this already with getitem/insert/setitem. I would either opt to make everything strictly object oriented or leave things as they are.



3) Expressions in list attributes (e.g., /trials = [1-10 =
noreplace(counter.group1picker, counter.group2picker,
values.distractortrial)] ).


This is probably my number one if you would also consider to allow "/ items = someitem" in a counter. It would provide extreme flexibility when writing code. Make everything an object that can be passed around, so that texts, pictures, trials, blocks can all be loaded into counters. Of course, this would lead to a plethora of possible run-time errors.



4) if->else if->else if->else if->else


Nice to have, yet achievable by the current logic, although tedious.



5) More events where logic can be inserted (e.g., element.onload , stimulus.onprepare, stimulus.onselect, counter.onselect)


My number two on your list.



6) possibly some simple loops, such as while (true) { } and do{} while(true), although not sure about this one yet


I imagine a lot of tasks where loops as control structures would come in handy but all in all, to me the least important addition together with object methods, particularly with respect to the effort that would presumably go into this.



Thanks very much for replying,
Malte


Blackadder
Blackadder
Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)
Group: Forum Members
Posts: 280, Visits: 147

Two more wishes.



(9) Expressions in <%...%> context: Maybe this works already and only I did not get it right so far. 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 objects named so that you can have multiple <values> groups in a script. Would allow for cleaner, more structured code.



Oh, if I may say the following, despite it being contrary to my own set of desiderata. I am profoundly unsure how many Inquisit customers really take advantage of the expression syntax. There is a huge difference between "normal" script writing and expression based coding which can be summarized in a simple antithesis: "users vs. programmers". The vast majority of Inquisit users I met had never written a single line of source code in their entire lifes and probably never will. They are not familiar with concepts like variables, functions, events, control structures and so forth. Handing some of Dave's wonderfully crafted scripting examples to any of my fellow lab members and ask them to a) understand and b) modify them would yield a river of tears - and resignations. Hence, although I should like to see Inquisit become more of a full blown programming environment, I strongly doubt that this is what most users require.


Inquisit's pivotal feature is that setting up functional scripts can be learnt within a matter of hours. Before adding features in the expression department, I'd always ask myself whether a similar thing could be achieved within the conventional Inquisit framework of elements, properties and dependencies. It's not helpful to include more and more functionality for less and less people until you reach the point where the latter might wonder why not use Matlab instead.



And now, nerd mode on again: yes, I love those expressions and what you can accomplish with them!


Malte.


seandr
seandr
Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)Supreme Being (131K reputation)
Group: Administrators
Posts: 1.3K, Visits: 1.1K

Thanks for the pointer to scintilla. I will take a look, although I'm hoping to find one that has a Mac version as well. And free is great, but I haven't ruled out paying for a license if the quality is there. And, yes, this would replace the current editor component used by Inquisit. 


-Sean




Blackadder
Blackadder
Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)Supreme Being (23K reputation)
Group: Forum Members
Posts: 280, Visits: 147

Scintilla or at least parts of it are included in the wxWidgets library, so even without resting on GTK+, there is Mac compatibility. I may quote the Scintilla homepage: "The wxStyledTextCtrl editor component in the
wxWidgets cross platform toolkit is based on Scintilla."


And if you think about a licensing agreement with somebody, I'd vouch for UltraEdit. I love this editor and they are about to release a Mac version in the very near future.


Bye, Malte


GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Explore
Messages
Mentions
Search