Today I went to the house of a cousin who has a Windows touchscreen desktop computer. I needed to test the color game because the technical person behind the observatory exhibition was having problems with touch events on this set-up.

My 10 year old nephew was with me and I asked him to play the game on his Android phone. He gave up after a couple of stages, “Why did you make the game so difficult to play?” was his praise to me. I told him it worked better on desktop, I just had to fix the game to load it up on the desktop touchscreen.

And this we did. Sure enough: a larger screen helps immensely and he had a good time playing, but this gave me the insight that a simple mobile adaptation is not enough, I will need to adapt the interface for thumb ergonomics.

Using my nephew as a subject also helped me discover a bug: if you tap the Windows touchscreen with two fingers, it will display the context menu. My nephew was very frustrated because he had selected a perfect match, and dismissing the context menu changed the selected color which gave him a bad score. He threw his hands up in the air in frustration, but I excitedly told him he had discovered something very valuable and promptly fixed it.

Regarding touch behavior, I was expecting a difficult if not impossible fix—if your browser app exhibits different behavior per platform (it worked correctly on my Mac and iPhone), it usually traces up to the way the OS implements the feature in question.

My problem turned out to be code I had copied from StackOverflow nine years ago. It looks something like this:

document.ontouchmove = fn

Which, despite its terseness, does not look correct to my javascript intuition, but I can’t say for sure. This did work on MacOS and iOS. It could have been fixed with either of these:

document.documentElement.ontouchmove = fn document.body.ontouchmove = fn

But I chose the less terse…

document.body.addEventListener("touchmove", fn)

Because that’s how I expect events to be attached in my current coding habits.