Re: Enabling Touch Events everywhere

By the way, have you looked at all for websites that are similarly "broken"
when navigator.maxTouchPoints > 0?  We've seen a few of these, most
recently http://www.shape5.com/demo/design_control/?view=featured (see
http://crbug.com/409383).

Disabling hover menus when maxTouchPoints > 0 is a very similar problem to
disabling them for ('ontouchstart' in window), but there's no obvious way
to help these sites other than evangelism.  I certainly wouldn't consider
disabling our support for maxTouchPoints as a result ;-)

Perhaps the underlying issue is the same - they want an alternate UI
treatment when tapped than when a mouse is used.  Again I think something
like MouseEvent.derivedFromTouchEvent would make this much simpler for them
(or maybe in this case they really do want MouseEvent.pointerType).  I'd
love any input you have over on that thread
<http://lists.w3.org/Archives/Public/public-touchevents/2014Sep/0000.html>.

Rick


On Tue, Sep 9, 2014 at 3:12 PM, Rick Byers <rbyers@google.com> wrote:

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