Re: Enabling Touch Events everywhere

On Mon, Sep 8, 2014 at 8:03 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

> 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).
>

That all makes sense, and is probably more valuable overall than any of the
automatable approaches I was considering.

We're thinking of possibly using a site-hacks approach here.  We'd enable
the touch event API globally, but then have a blacklist of sites where it's
disabled globally on desktop (even when a touchscreen is present).  There
would be a switch to disable the blacklist for testing purposes, and noisy
console warnings about the fact that the blacklist is in effect.  We'd
likely also put a time limit (Eg. 1 year) on blacklist entries.  It's not
clear yet whether we can actually pull this off (today we don't have the
ability to enable/disable the touch event API on the fly), but it's the
main plausible path I see for getting where we want to be without a total
revolt.

> 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.
>

Ok, I'll try to make the time to do this sometime soon.  If we see the data
for the top 100 sites is useful, then I'll happily run it on the Alex top
1-million!