Trail Making Test with Windows Tablet?

Back

Trail Making Test with Windows Tablet?

Author	Message
drtb	drtb posted 8 Years Ago Topic Details Share Topic
Group: Forum Members Posts: 16, Visits: 37	Hello, We're having a bit of an issue still with the Trail Making Test (TMT) when running on a Windows Tablet. Specifically, we've had some "wonkiness" when asking participants to draw using their finger/stylus - the traced line will dart around, not trace at times, not register taps/touches when participants clearly meant to go over the appropriate number/letter, etc. Enlarging the test area and running it in "portrait" mode helps to some extent, but not enough to where we're extremely confident in the error counts we're getting (i.e., false errors). One thing that seems odd is that we noticed the inputdevice attribute is defaulted to mouse, which seems to make sense - we never seem to be getting these errors on a desktop platform. My question is - if we set the inputdevice or validresponse to "touch" somehow, would that fix some of this wonkiness? I can't help but feel that part of the problem is that the tablet thinks the participant is tracing using a mouse and this is causing some idiosyncrasies in the tracing (and therefore, registering which numbers/letters are hit). Thoughts? Thanks, -`-Tim
	Reply Like 21
Dave	Dave posted 8 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 105K	+x drtb - Wednesday, June 7, 2017 Hello, We're having a bit of an issue still with the Trail Making Test (TMT) when running on a Windows Tablet. Specifically, we've had some "wonkiness" when asking participants to draw using their finger/stylus - the traced line will dart around, not trace at times, not register taps/touches when participants clearly meant to go over the appropriate number/letter, etc. Enlarging the test area and running it in "portrait" mode helps to some extent, but not enough to where we're extremely confident in the error counts we're getting (i.e., false errors). One thing that seems odd is that we noticed the inputdevice attribute is defaulted to mouse, which seems to make sense - we never seem to be getting these errors on a desktop platform. My question is - if we set the inputdevice or validresponse to "touch" somehow, would that fix some of this wonkiness? I can't help but feel that part of the problem is that the tablet thinks the participant is tracing using a mouse and this is causing some idiosyncrasies in the tracing (and therefore, registering which numbers/letters are hit). Thoughts? Thanks, -`-Tim I don't think that changing /inputdevice to touchscreen will necessarily improve matters, but that should not keep you from giving it a try nonetheless. More likely, the difference you're seeing is simply due to that fact that different input modalities -- on a hardware-level -- have different properties and measurement error associated with them. I.e. some touch screens will be much less sensitive and sample at a lower rate than a typical mouse.
	Reply Like 23
drtb	drtb posted 8 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 16, Visits: 37	+x Dave - Wednesday, June 7, 2017 +x drtb - Wednesday, June 7, 2017 Hello, We're having a bit of an issue still with the Trail Making Test (TMT) when running on a Windows Tablet. Specifically, we've had some "wonkiness" when asking participants to draw using their finger/stylus - the traced line will dart around, not trace at times, not register taps/touches when participants clearly meant to go over the appropriate number/letter, etc. Enlarging the test area and running it in "portrait" mode helps to some extent, but not enough to where we're extremely confident in the error counts we're getting (i.e., false errors). One thing that seems odd is that we noticed the inputdevice attribute is defaulted to mouse, which seems to make sense - we never seem to be getting these errors on a desktop platform. My question is - if we set the inputdevice or validresponse to "touch" somehow, would that fix some of this wonkiness? I can't help but feel that part of the problem is that the tablet thinks the participant is tracing using a mouse and this is causing some idiosyncrasies in the tracing (and therefore, registering which numbers/letters are hit). Thoughts? Thanks, -`-Tim I don't think that changing /inputdevice to touchscreen will necessarily improve matters, but that should not keep you from giving it a try nonetheless. More likely, the difference you're seeing is simply due to that fact that different input modalities -- on a hardware-level -- have different properties and measurement error associated with them. I.e. some touch screens will be much less sensitive and sample at a lower rate than a typical mouse. No worries, that's about what I had figured. Any way to make the circles a little bit bigger on the screen - and therefore, more forgiving for registering "hits" on a touch screen? Tried enlarging the photos themselves but that didn't do much in terms of seeing them enlarged during the test itself.
	Reply Like 28
Dave	Dave posted 8 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 105K	+x drtb - Friday, June 9, 2017 +x Dave - Wednesday, June 7, 2017 +x drtb - Wednesday, June 7, 2017 Hello, We're having a bit of an issue still with the Trail Making Test (TMT) when running on a Windows Tablet. Specifically, we've had some "wonkiness" when asking participants to draw using their finger/stylus - the traced line will dart around, not trace at times, not register taps/touches when participants clearly meant to go over the appropriate number/letter, etc. Enlarging the test area and running it in "portrait" mode helps to some extent, but not enough to where we're extremely confident in the error counts we're getting (i.e., false errors). One thing that seems odd is that we noticed the inputdevice attribute is defaulted to mouse, which seems to make sense - we never seem to be getting these errors on a desktop platform. My question is - if we set the inputdevice or validresponse to "touch" somehow, would that fix some of this wonkiness? I can't help but feel that part of the problem is that the tablet thinks the participant is tracing using a mouse and this is causing some idiosyncrasies in the tracing (and therefore, registering which numbers/letters are hit). Thoughts? Thanks, -`-Tim I don't think that changing /inputdevice to touchscreen will necessarily improve matters, but that should not keep you from giving it a try nonetheless. More likely, the difference you're seeing is simply due to that fact that different input modalities -- on a hardware-level -- have different properties and measurement error associated with them. I.e. some touch screens will be much less sensitive and sample at a lower rate than a typical mouse. No worries, that's about what I had figured. Any way to make the circles a little bit bigger on the screen - and therefore, more forgiving for registering "hits" on a touch screen? Tried enlarging the photos themselves but that didn't do much in terms of seeing them enlarged during the test itself. You need to change the /size of the various <picture> elements throughout the script. I.e., taking the 1st script -- samplea.iqx -- as example, change <picture SA1pic> / items = ("1.jpg") / size = (5%, 5%) / position = (53%, 20%) / erase = false </picture> to, say, <picture SA1pic> / items = ("1.jpg") / size = (8%, 8%) / position = (53%, 20%) / erase = false </picture> and so forth.
	Reply Like 17