eye tracking reading study

Michiel Spape Michiel.Spape at nottingham.ac.uk
Wed Jun 29 16:49:12 UTC 2011


Hi Alon & List,
Turns out I later decided to do no online eye-tracking at all, but in an old version, I still have the following bit of code:
---------
Set theGazeData = CTobiiEyeTrackerResponseData( TobiiEyeTracker.History(TobiiEyeTracker.History.Count)	)
If Not theGazeData Is Nothing Then
	CurEye.x = theGazeData.CursorX
	CurEye.y = theGazeData.CursorY
	if c.GetAttrib("ShowEye") = "Yes" then donow = TekenCirkel (CurEye.X, CurEye.Y, c.GetAttrib ("BallSize")/2, "green")
	Set theGazeData = Nothing
End If
----------

Which, if you have been through the Tobii code, you might notice is roughly based on the capture AOI code of an example of theirs. If you, or anyone else, goes through my code (I don't know whether the list now accepts attachments or not), notice how *AWFUL* my own code tends to be :). Embarrassing!
 
Anyway, it does the trick. In 1g, attached, it takes the last bit of (i.e. TobiiEyeTracker.History(TobiiEyeTracker.History.Count)), which contains CursorX and CursorY. If you want to drive a participant absolutely mad, do what I do above and show a little dot at the position of the (captured) fixation-position. It's always a bit off, so you will follow it and thus drive it away - a bit like having a speckle of dust in your eye. Re: attached files, notice 1g is the older version, 1i is the later one; and they probably only work if you have the Tobii installed, and have a similar system as ours. 

As to your questions:

"Is there an advantage of using solution two (fix.position) over
solution one? Using the fix.position, you would still end up doing the
calculations as in the first solution. Also, I didn't know you could
call the fixation position within an InLine, that's helpful -- is it
just "fix.position"? If you have that script, I would greatly
appreciate it."

Sadly, it's a bit more difficult than Fix.Position - as above. But it can be done. The advantage, for instance, is that you could calculate the centre of words and figure out the distance between word-centre and gaze-position, which should be more accurate than using square AOIs. It's also plain cool, because it allows you to debug like my version above, using a dot on the screen :) It is, all in all, pretty good to figure out once, even if you later decide to abandon it.

" Are you saying to have the words displayed successively, so say, the
first two words of the sentence on one state, then the next two on the
second state, etc.? How would the states advance? (I've never used
more than the default state, so forgive my ignorance). Do you have an
example of this?"

No, I meant, if you have 3 conditions (for 1,2 or 3 words), then show one state depending on the condition. Or am I missing something and you want to use successive presentation of words? 
Anyway, I gather that a lot of people plainly do not see that slides can have states, in fact, I never did anything with them either until some point. It can, however, provide a lot of clarity, as it can keep your experiment relatively free from code. So, make three states with names OneWord, TwoWords, ThreeWords (this can be changed in the properties panel, for instance - not very clearly visible). In the slide's (i.e. not in the state's) property, set ActiveState to "[HowManyWords]" and in the list, have an attribute of HowManyWords, with again, the three names of states. 

Hope that helps!
Best,
Mich

Michiel Spapé
Research Fellow
Perception & Action group
University of Nottingham
School of Psychology
www.cognitology.eu


-----Original Message-----
From: e-prime at googlegroups.com [mailto:e-prime at googlegroups.com] On Behalf Of Alon Hafri
Sent: 29 June 2011 15:47
To: E-Prime
Subject: Re: eye tracking reading study

Hi Mich,

Thanks for your solutions! I'll respond to yours in order, below your
text:

On Jun 29, 5:10 am, Michiel Spape <Michiel.Sp... at nottingham.ac.uk>
wrote:
> Hi,
> Here's my take:
> - given that E-Prime uses, I think, a font with constant letter symbol size (I forgot the official name, but the point is that an I takes as much space as a W - as in the font you're probably reading this), it is not that difficult to line them up, as you say. Say, one letter is 12 pixels (you can test that by trial and error), then the word WORDS is 60 pixels. If I want to have two AOIs for the words TWO WORDS, then, as per your second possible way to do this, I'd just show that as one slideText on the slide and make two AOIs. Given that our screen is 640x480 by default (or whatever you have), the we print the TWO WORDS as one slideText in the centre. TWO WORDS is 60 + 48 (TWO plus space makes 4x12=48 pixels) = 108 pixels and should therefore be positioned LEFT at 266 to RIGHT at 374* (LEFT: 320 (screen width centre) - 54 (i.e. 108 / 2) = 266 and RIGHT: 320 + 54 = 374). Thus, your left AIO, if you align it left, can be placed at 266, and should be 36 pixels (since the space shouldn't be included). The AIO right should be aligned right, and can be placed at 374.
> Depending on your knowledge of E-Prime (and you'd need some to get Tobii to work properly in E-Prime), that shouldn't be too hard to programme, but let me know if you need help.
>

This would definitely work (the font is called Courier New). But I do
see your point below about wanting the AOIs to be a bit larger so
things are accurately detected, and it may be hard to do that with a
lot of words on screen.

> - You could also do away with all the AOIs as programmed by the Tobii team and just look at the fixation position on the fly - that is, just take the fix.position, calculate distance to each word and figure out which is the likely candidate. I have some script for that, if you're interested.
>

Is there an advantage of using solution two (fix.position) over
solution one? Using the fix.position, you would still end up doing the
calculations as in the first solution. Also, I didn't know you could
call the fixation position within an InLine, that's helpful -- is it
just "fix.position"? If you have that script, I would greatly
appreciate it.

> - Alternatively, have you thought about just NOT lining up the words? That is, if you have a slide with 3 states, state 1 with one word, 2 with two words, 3 with three words, and put words on slide 2, for instance, at 35% and 65%, then this will be a LOT easier. I can see the point that it doesn't look right, but I think there's plenty that can be said for this experimentally:
> 1. you probably want to control for word length anyway
> 2. you probably want to control for saccade length anyway
> 3. Accurate as Tobii *can* be, I've often found I wanted my AOIs quite a bit larger so that things are accurately detected.
>

Are you saying to have the words displayed successively, so say, the
first two words of the sentence on one state, then the next two on the
second state, etc.? How would the states advance? (I've never used
more than the default state, so forgive my ignorance). Do you have an
example of this?

> - Finally, I've later come to realise it is a lot easier to just don't do much with Tobii in E-Prime and analyse the "gazedata" separately (in matlab). That is, it's pretty easy to find out later on what word people were fixating (at least, roughly), given that you at least save their positions on the screen.
>

Yes this I've done before (even for E-Prime experiments, when the AOIs
were adjusted after running subjects) -- could work well. Again thanks
for your help.

> Best,
> Mich
>
> * obviously, this would make the region one pixel too large, but I'm not compensating for that to simplify matters.
>
> Michiel Spapé
> Research Fellow
> Perception & Action group
> University of Nottingham
> School of Psychologywww.cognitology.eu
>
> -----Original Message-----
> From: e-prime at googlegroups.com [mailto:e-prime at googlegroups.com] On Behalf Of Alon Hafri
> Sent: 28 June 2011 21:47
> To: E-Prime
> Subject: eye tracking reading study
>
> Hi, wondering if someone in the group can help me out.
>
> I am creating an E-Prime experiment using the E-Prime Extensions for
> Tobii. For each trial, the participant will read a sentence, and I
> would like to record reading times for each window of size 1 to 3
> words.
>
> I have experience with using list attributes to set Slide Image
> position (and therefore AOI position) at runtime, as well as with
> using transparent Slide Images overtop of larger images to act as
> AOIs, but I've never done a reading study before. Since the words will
> vary in length for each trial, but will need to be evenly spaced (and
> on multiple lines conceivably), it would be great if position for
> every window would not have to be specified but could be determined by
> a script.
>
> I can think of a few solutions, but perhaps someone has an easier one?
> 1) create a Slide Text object for each word (or window), and so they
> could act as their own AOIs.
> Drawbacks: You would have to specify locations for each one, and it
> could be tricky lining them up appropriately so words are evenly
> spaced.
>
> 2) Have one Slide Text object for the whole sentence and have
> transparent AOIs overtop as the AOIs.
> Drawbacks: You would still have to specify locations for each, but the
> text would be in one object so would appear normal.
>
> 3) Suggestions?
>
> Thanks!
> Alon
>
> --
> You received this message because you are subscribed to the Google Groups "E-Prime" group.
> To post to this group, send email to e-prime at googlegroups.com.
> To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/e-prime?hl=en.
>
> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system:
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Collision 1i.es
Type: application/octet-stream
Size: 248790 bytes
Desc: Collision 1i.es
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20110629/78521ea2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Collision 1g.es
Type: application/octet-stream
Size: 239056 bytes
Desc: Collision 1g.es
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20110629/78521ea2/attachment-0001.obj>


More information about the Eprime mailing list