RE: Enabling Touch Events everywhere

From: Rick Byers <rbyers@google.com>
> When doing this outreach it may help to say that Chrome plans to enable
> touch events all the time (tracked by http://crbug.com/392584), so this
> will likely break them on mouse-only machines before too much longer.  

This would be great info to be added to the outreach we're tracking at webcompat.com. It would probably be best though to come from the Chrome team. Could you add this info to the bugs I linked to?

> Also using Chrome with a mouse on a device with a touchscreen is increasingly
> becoming a "default configuration" for us.  When we get user complaints of
> such issues, the users generally have not noticed that they can work around
> the issue by using their touchscreen (a substantial minority of touchscreen
> laptop users almost never use their touchscreen in our experience).

Pointer Events then, perhaps? :-p

> Note that your bug reports say: "you typically should be able to see these
> issues in Chrome by enabling Touch Events in the developer tools".  That's
> technically 100% correct.  Due to technical limitations we can't completely
> enable the DOM0 touch event properties
> https://code.google.com/p/chromium/issues/detail?id=133915> dynamically
> through the devtools (although we play some tricks to help catch the common
> use cases).  The best way to test is to force the touch event API to be
> enabled with chrome://flags/#touch-events.

Good info.  Again, we should just tag-team this advice over on webcompat.

> Can you share a little about the methodology you used to find these, and
> how you classified "broken"?  The most obvious failure mode is when
> clicking things just doesn't work (often making the site unusable).  This
> used to be very common, but in our experience is much less common these
> days.  The more minor issues are things like non-essential hover menus
> which are disabled on touchscreen laptops but (arguably) a desirable UI for
> mouse users.

We originally wrote off the issue that touch can't use mouse hover menus as "non-essential on most sites."  Boy were we wrong and our users let us know it!  I think the same thing would happen if suddenly these types of seemingly minor things start to break for mouse. We can (and should), of course, take severity into account when prioritizing outreach.

To us, a site is broken when it doesn't behave in the way the developer intended. From the user's perspective, it's broken when functionality is removed from the site that was present there before the change to expose Touch Events. Even if there's an alternative way to complete the scenario (e.g. a non-essential hover menu is broken but you can access the same content in a different place), you've regressed the users' learned behavior and potentially altered things the developer cares about like how the site was promoting content to the user or metrics like # of clicks to complete the task. In the outreach bugs we filed, I would consider several  of these blockers to turning on TE (e.g. can't use prev/next buttons in the WebMD slideshow, can't see top stories in Huffington Post categories, etc.).  Further, this was a sample size of only 100. I expect there are far more impacted sites.

The methodology was basically:

1. Load a site with Touch Events disabled
2. Run some basic interactive scenarios in the page with a mouse (navigation, login, share, other common interactions)
3. Reload the site with Touch Events enabled
4. Run the same scenarios and see if they work as expected from step 2

We did this with an internal prototype of desktop IE with/without Touch Events. We validated our results using Chrome with touch events enabled/disabled (we used real touchscreens, not flags or dev tools emulation). 

> I've been planning on doing an automated test where I load up each of the
> top sites homepages and compare the number of mouse event handlers
> installed with and without touch event support being present.  I expect the
> sites whose handler counts differ will correlate well with those that are
> badly broken, but I'm not sure how reliable this will be in practice.
 > Thoughts?

I think that's certainly good additional info to have, especially if this could be done at a much larger scale than 100 sites.

Received on Tuesday, 9 September 2014 00:04:18 UTC