Inconsistent admin behaviour on devices with both mouse and touch

[Toutouwai]

It's quite common these days for devices to support both mouse and touch screen interaction. My 27" desktop has a touch screen, but I almost never use this - for me it's a mouse-driven device.

The PW admin seems to sniff out touch screens and change behaviour based on this:

• the useHoverActions config setting is ignored and page actions only display on click/touch
• the top level menu items (Pages, Setup, etc) cannot be navigated to by click (presumably so the dropdown menu can be displayed when "hover" isn't supported)

Interestingly, these behaviour changes occur in Chrome and IE for touch+mouse devices but not in Firefox.

When using a mouse on a touch-capable device these changes are unwanted. Maybe there is a way distinguish between touch-only devices and touch devices with a mouse attached? Or find different workarounds for hover on touch devices? I think default iOS behaviour is to trigger hover on the first touch if a CSS hover rule affects visibility, so maybe this could be leveraged instead.

[teppokoivula]

Maybe there is a way distinguish between touch-only devices and touch devices with a mouse attached?

Last time I dug into this issue it seemed that there really are no good options; the most reliable method seemed to be detecting the first movement of a mouse, which is a bit of a hack, and adds some overhead.

In case someone knows of a better method, that would be awesome. Currently the best option seems to be designing the UI so that this difference doesn't matter in the first place.

[mikerockett]

Conversation reference: #1386

[ryancramerdesign]

In case someone knows of a better method, that would be awesome. Currently the best option seems to be designing the UI so that this difference doesn't matter in the first place.

From what I understand, AdminThemeReno already accomplishes this. If there are no reliable ways to detect a touchscreen device that also has a mouse (?), then perhaps the best option is to make the Reno theme the default, since it would cover a broader range of input devices.

I feel like I have to do more mouse movement/clicking to get where I need to go in Reno, but I think that's because the default admin is originally designed for a mouse environment. Whereas Reno seems to be more portable in general, even if a little more work for those of us using mice.

the most reliable method seemed to be detecting the first movement of a mouse, which is a bit of a hack, and adds some overhead.

I don't think even this would be reliable because chances are the first mouse movement would occur after the JS initialization, after it's already initialized the environment for a touch device.

I'm going to keep an eye out for alternative ways to detect touch devices that also have a mouse though. Antti mentioned detecting screen resolution, which we can do, but not sure that's a reliable thing either.

[Renobird]

I feel like I have to do more mouse movement/clicking to get where I need to go in Reno, but I think that's because the default admin is originally designed for a mouse environment. Whereas Reno seems to be more portable in general, even if a little more work for those of us using mice.

As Teppo mentioned, there really aren't any solid solutions for this (last I checked), so for the Reno theme I stuck to click/touch for all the primary navigation items. When implementing click/touch vs hover, there is a trade-off between clicks (on non-touch devices) and overall usability across all input types.

[ryancramerdesign]

As Teppo mentioned, there really aren't any solid solutions for this (last I checked), so for the Reno theme I stuck to click/touch for all the primary navigation items. When implementing click/touch vs hover, there is a trade-off between clicks (on non-touch devices) and overall usability across all input types.

Yes, that's what I've gathered from reports about default admin with mouse-enabled touch screen devices over the last couple of weeks. It seems you were on to this before I even knew such devices existed! Given that there don't appear to be any reliable methods to detect such devices, and the Reno theme already supports them well, perhaps Reno theme should become the default (as mentioned above). That would ensure new users coming to PW on these mouse-bound touch-screens aren't immediately excluded.

How common are these devices? I'm guessing somewhat, since the issue is surfaced twice in the last week or so.

[Toutouwai]

Although the Reno theme is truly beautiful I personally wouldn't be in favour of it becoming the default theme (if that meant the current default theme was no longer available). Reasons being:

• I find it slower to move around in (like Ryan has noted, more mouse movement and clicking required - menus have to be manually closed, for instance).
• I think several of the click targets are too small. The lightning bolt icon needs to be used frequently and you have to be quite precise to click it. This is an issue for both developers (who have to do a lot of interaction with the PW admin) and editors (who may be relatively inexperienced computer users, or older users with less than perfect motor control).
• I don't think it's as intuitive as the current default theme for new users to understand. When using the menus (a big part of the admin) it isn't obvious that the little lightning bolt would have anything to do with the activation of sub-menus.
• Menu items with long names are cut off (text doesn't wrap inside menus).

the first mouse movement would occur after the JS initialization, after it's already initialized the environment for a touch device

What issues arise if the default admin theme is used on a touch device without any special initialisation? Are we certain the initialisation for touch devices is necessary?

[Renobird]

@ryancramerdesign

It seems you were on to this before I even knew such devices existed!

Haha, not at all. Don't give me too much (any) credit here. My decisions on how I implemented the menus in the Reno theme were based largely on my own preference of having primary navigation items open/close on click instead of hover. Coupled with the fact that I really couldn't come up with an alternative approach that didn't seem like a bear to troubleshoot and support.

With regards to making it the default, I'll follow your lead. I know there has been some chatter about making Reno the default theme, but I think there are just as many people (perhaps more) who prefer the current default. Toutouwai's comments are a perfect example.

@Toutouwai

I think several of the click targets are too small. The lightning bolt icon needs to be used frequently and you have to be quite precise to click it. This is an issue for both developers (who have to do a lot of interaction with the PW admin) and editors (who may be relatively inexperienced computer users, or older users with less than perfect motor control).

The bolt icons have a target that is pretty much the same height as the parent item, and a 17px padding on either side. I'm not sure I agree about that being too small, but I can explore some options for enlarging the target area. You may already be aware of this, but those bolt (quick link) icons show their menus on hover as well as click. Additionally you can access the full page (instead of the quick link menu) by clicking the nav item — the lightning bolts are just a way to access the sub items without an additional click and without having to go to the full page view.

Menu items with long names are cut off (text doesn't wrap inside menus).

On my to-do list for the next update.

Thanks for the feedback, I'm always looking for input on how to improve the Reno theme. My apologies for hijacking this conversation, but I felt the replies here were warranted.

[Toutouwai]

To quote myself... :-)

Are we certain the initialisation for touch devices is necessary?

I tested the two touch behaviours I mentioned in the first post after commenting out the relevant JS initialisations. In the case of the page actions I replaced the JS show/hide with a CSS hover rule. When testing on an iPad both elements behaved exactly as expected/desired. First touch shows the menu/page actions, second touch triggers the click behaviour.

I don't have an Android device to test on, but showing/hiding with CSS hover seems to work fine on iOS. If this approach works I think it's better than changing the admin behaviour based on touch detection.