Capturing reaction times using Javascript, accurac

Question

I'm building a dot probe task (people have to react quickly to a dot after an image disappears) and we need to measure reaction times and show stimuli for pre-defined intervals for usage in an online therapy study.

We already decided on Javascript and we're willing to impose some constraints on users, i.e. ruling out IE etc. We can't ban Windows completely though.

I read John Resig's post on the topic and according to this we'll have to ban every browser on Windows except Firefox and Chrome.

In addition this answer advises using console.time(); as best-practice for FF and Chrome.

I have some follow-up questions, considering that Resig's post is 4 years old now and that the question above is about measuring function execution time (that means the execution of code skewing the timer is good, not bad as in our case) and not about a reaction time study.

The following similar question just asked for the "best web language" and only received the blanket recommendation to use JS (which is what a couple of published studies have done, but they don't publish technical details).

1. Can we somehow use the better accuracy of console.time() where available? I think not, because it only returns to the console, i.e. it can't be captured in a variable.
2. Have there been any significant changes to timing accuracy in the last 4 years? I'm comfortable banning IE for many reasons, but maybe things have changed for Safari and Opera on Windows?
3. Should I use a second method that ties into the execution process to get another set of times for comparison / cross-validation?

Answer 1

There was a good article recently about this topic from Stian Reimers & Neil Stewart.

Presentation and response timing accuracy in Adobe Flash and HTML5/JavaScript Web experiments http://www.ncbi.nlm.nih.gov/pubmed/24903687

Answer 2

ObDisclaimer - I used to write software just like like this for a University research department.

You can use performance.now() (or performance.webkitNow(), depending on browser version) to get a more accurate timestamp than Date.now(). See here for more information.

One issue to take into account however is screen refresh. Assuming a 60 Hz refresh rate, there can be a 16 ms variance in when the image actually appears on screen, depending on:

1. whether the software is synched to the screen refresh rate (not possible in JS, AFAIK), and
2. where the image and dot probe are relative to the top of the screen - pixels drawn at the top of the screen are drawn before those below them.

You should also consider effects caused by things like keyboard scanning intervals. On one project the researcher found significant groupings around periods that were (from memory, this is 20 years ago) a multiple of 30ms or so, which appeared to be due to how frequently the keyboard was being scanned for key presses on the Psion PDA being used for the tests.

In this case I solved the problem by building a hardware "button box" using a PIC microcontroller which could send a serial byte at 9600 bps with no scanning latency, and <2ms to get the key press from the box to the PDA.

I was considering writing a paper about the issues around screen refresh. Then I got a real job ;-) I don't know if anyone else ever studied it.