Allow swiping the admin menu open and closed on touch devices

[ryan]

​https://make.wordpress.org/flow/2014/10/17/opening-and-closing-the-admin-menu-on-touch-devices-nexus-5-ipad-air-iphone-5-4-1-alpha-20141016/

Other mobile web interfaces with a side menu allow swiping the menu open and closed. We too should accommodate swiping.

[Denis-de-Bernardy]

If I may add another suggestion: Make #wpadminbar's position absolute rather than fixed. By default, it needlessly clutters precious screen real estate. (You can always tap the top of the screen to rapidly scroll and reach it.)

[ninnypants]

I've attached a rough first pass at this. It probably needs some cleanup and more testing, but I'm able to swipe to open/close in Safari on my iPhone 5s.

[helen]

Replying to Denis-de-Bernardy:

If I may add another suggestion: Make #wpadminbar's position absolute rather than fixed. By default, it needlessly clutters precious screen real estate. (You can always tap the top of the screen to rapidly scroll and reach it.)

That's already the case on small screens.

[ninnypants]

rtl support

[ninnypants]

Updated patch to add support for rtl menus.

[MikeHansenMe]

Tested this on my HTC Onc and Kindle Fire. Worked as expected on both.

[ryan]

With 31187.2.diff on an iPhone 6+, sometimes hamburger taps don't open/close the menu. Multiple taps are needed. Swiping isn't reliable. Often times, to get open/close swipes to work, the hamburger icon must be active (highlighted blue).

[ninnypants]

With 31187.3.diff some of the buggieness around tapping the hamburger, and swiping. Taps open and close consistently for me now, and it accounts for swiping open and tapping closed and vice versa.

[ryan]

Hamburger taps and swipe to close works reliably on an iPhone 6+ with 31187.3.diff. Swipe to open less so. I have to initiate the open swipe pretty close to the left edge and often trigger browser back history instead.

[ninnypants]

Replying to ryan:

Hamburger taps and swipe to close works reliably on an iPhone 6+ with 31187.3.diff. Swipe to open less so. I have to initiate the open swipe pretty close to the left edge and often trigger browser back history instead.

Is the main issue with swipe to open just reliably hitting the trigger area, within 20% of the screen width from the edge the menu is on?

Currently the the setup, for ltr, is if your swipe starts within the left 20% of the screen and moves 20% to the right the menu will open, and to close it just needs to start outside the menu, and move 20% to the left to close.

How would you like to see these interactions work, does the above sound like a good way of approaching it?

[ryan]

Replying to ninnypants:

Replying to ryan:

Hamburger taps and swipe to close works reliably on an iPhone 6+ with 31187.3.diff. Swipe to open less so. I have to initiate the open swipe pretty close to the left edge and often trigger browser back history instead.

Is the main issue with swipe to open just reliably hitting the trigger area, within 20% of the screen width from the edge the menu is on?

I think so. With G+ mobile web and any of the lefthand menu apps I have installed, I can swipe the menu open anywhere on the screen. I find that I've been using the righthand 20% of the screen to swipe open and closed.

[ninnypants]

Replying to ryan:

I think so. With G+ mobile web and any of the lefthand menu apps I have installed, I can swipe the menu open anywhere on the screen. I find that I've been using the righthand 20% of the screen to swipe open and closed.

Ok 31187.4.diff allows swiping from anywhere on screen, and avoids interfering with scrolling by not starting unless the first swipe is left/right and not triggering menu open unless the horizontal swipe is longer than any vertical swipe.

[ryan]

Swipe open, swipe closed, open, closed, open, closed. That feels pretty good.

[DrewAPicture]

@ryan: What's left here? More mobile or a11y testing?

[ryan]

Replying to DrewAPicture:

@ryan: What's left here? More mobile or a11y testing?

Code and accessibility review and more device testing. I'll try it on iPhone 5, Nexus 5, and iPad Air soon.

[ryan]

Looked good during a five minute test drive on a Nexus 5

[iseulde]

Taking a closer look at the patch. Not sure if that touchmove event is necessary? Can make the necessary calculations at the end.

I'd also like the menu to close if I tap on the content.

[iseulde]

I think this does the same thing.

[ryan]

I temporarily had problems with index.php on both iPhone 5 and 6+. The menu would swipe open and closed on every screen except index.php. Nexus 5 had no problems with index.php. I tried with and without the welcome panel up, and index.php still wouldn't slide on my iPhones. I gave up for a bit, came back, and the menu was sliding just fine on my iPhones. I currently have no problems. @iseulde could never reproduce. So, I'll write it off as multi-device testing dementia.

With the index.php glitch gone, the menu swipes open and closed with every attempt. Swipes were reliable across quick runs on Nexus 5, iPhone 5, and iPhone 6+.

I checked out the open/close action on plus.google.com. G+ has a softer open. We might want to do some fiddling, although I'm fine with landing what we have.

[iseulde]

Stick with one source of truth.

[ryan]

31187.2.patch works for me on iPhone 6+, iPhone 5, Nexus 5.

[iseulde]

Might be good to have swipe events such as the ones in jQuery mobile, but maybe that's material for another ticket.
Was discussing this a bit with @azaozz yesterday.

[DrewAPicture]

Tested this on an iPad2 and the experience wasn't too bad – actually pretty good, I could get used to using it like that.

Also tested it on my OnePlus One (chrome/Android) and it didn't work at all for me. Didn't even have a collapse-menu button. See opo_chrome_31187.png​

[DrewAPicture]

I think the OPO failure can be considered an edge case. Let's get this in for beta and see how it goes in wider-spread mobile testing.

[azaozz]

In 31720:

Allow swiping of the admin menu on touch devices.
Props iseulde, ninnypants. See #31187.

[azaozz]

May need some refinement, leaving open for now.

[helen]

This doesn't seem to work for me on a Nexus 7. It's also nearly undiscoverable without animating the menu in/out with the swipe and doesn't feel very polished.

[iseulde]

When I try to use this on an iPhone, half of the time it goes to the previous page. When there's a page further in the history it sometimes goes there if you swipe too close to the edge.

[iseulde]

I'm actually not sure if we should do this. Also tried plus.google.com again and it seems they removed it?

[ryan]

Replying to iseulde:

I'm actually not sure if we should do this. Also tried plus.google.com again and it seems they removed it?

Yes, recently removed for both iOS and Android. As much as I like an outlet for "app learned swipe to open" compulsion, I'm open to ending the experiment. Nav history swipes on iOS do complicate the interaction if you haven't learned that apps don't require swiping close to the edge to open the menu, you can swipe anywhere. I'll just have to get used to double tapping home on my iPhone 6+ to bring the menu button down, tapping the button to open the menu, and then double tapping home again to restore full view.

[helen]

Reverting and wontfixing, the iOS complication is a problem and it seems that other web apps are making pain point discoveries on our behalf.

[helen]

In 31910:

Admin menu: Revert [31720] for swipe open/closed.

This is problematic on any device that uses swipe for history navigation, particularly iOS. It's also quite unrefined from an interaction point of view and would not be material for this release either way.

see #31187.