WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#31187 closed task (blessed) (wontfix)

Allow swiping the admin menu open and closed on touch devices

Reported by: ryan Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Administration Keywords: make-flow
Focuses: ui Cc:

Description

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.

Attachments (7)

31187.diff (3.1 KB) - added by ninnypants 3 years ago.
31187.2.diff (3.8 KB) - added by ninnypants 3 years ago.
rtl support
31187.3.diff (4.3 KB) - added by ninnypants 3 years ago.
31187.4.diff (4.0 KB) - added by ninnypants 3 years ago.
31187.patch (1.6 KB) - added by iseulde 3 years ago.
31187.2.patch (1.9 KB) - added by iseulde 3 years ago.
opo_chrome_31187.png (134.3 KB) - added by DrewAPicture 3 years ago.

Download all attachments as: .zip

Change History (52)

This ticket was mentioned in Slack in #core by boren. View the logs.


3 years ago

#2 @obenland
3 years ago

  • Keywords 4.2-fun added

#3 @obenland
3 years ago

  • Milestone changed from Awaiting Review to 4.2

#4 follow-up: @Denis-de-Bernardy
3 years ago

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

#5 @SergeyBiryukov
3 years ago

  • Component changed from Menus to Administration

@ninnypants
3 years ago

#6 @ninnypants
3 years ago

  • Keywords has-patch added

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.

This ticket was mentioned in Slack in #core by ninnypants. View the logs.


3 years ago

#8 in reply to: ↑ 4 @helen
3 years ago

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
3 years ago

rtl support

#9 @ninnypants
3 years ago

Updated patch to add support for rtl menus.

#10 @MikeHansenMe
3 years ago

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

#11 @ryan
3 years ago

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
3 years ago

#12 @ninnypants
3 years ago

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.

#13 follow-up: @ryan
3 years ago

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.

#14 in reply to: ↑ 13 ; follow-up: @ninnypants
3 years ago

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?

#15 in reply to: ↑ 14 ; follow-up: @ryan
3 years ago

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.

Last edited 3 years ago by ryan (previous) (diff)

@ninnypants
3 years ago

#16 in reply to: ↑ 15 @ninnypants
3 years ago

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.

#17 @ryan
3 years ago

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

#18 follow-up: @DrewAPicture
3 years ago

  • Priority changed from normal to high

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

#19 in reply to: ↑ 18 @ryan
3 years ago

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.

This ticket was mentioned in Slack in #core-flow by boren. View the logs.


3 years ago

#21 @ryan
3 years ago

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

#22 @iseulde
3 years ago

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
3 years ago

#23 @iseulde
3 years ago

I think this does the same thing.

This ticket was mentioned in Slack in #core by iseulde. View the logs.


3 years ago

#25 @ryan
3 years ago

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
3 years ago

#26 @iseulde
3 years ago

Stick with one source of truth.

#27 @ryan
3 years ago

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

#28 @iseulde
3 years ago

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.

#29 @DrewAPicture
3 years ago

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

Last edited 3 years ago by DrewAPicture (previous) (diff)

This ticket was mentioned in Slack in #core by drew. View the logs.


3 years ago

#31 @DrewAPicture
3 years ago

  • Keywords commit added
  • Priority changed from high to normal
  • Type changed from defect (bug) to enhancement

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.

This ticket was mentioned in Slack in #core by boren. View the logs.


3 years ago

#33 @azaozz
3 years ago

In 31720:

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

#34 @azaozz
3 years ago

May need some refinement, leaving open for now.

This ticket was mentioned in Slack in #core by drew. View the logs.


3 years ago

#36 @DrewAPicture
3 years ago

  • Type changed from enhancement to task (blessed)

This ticket was mentioned in Slack in #core by drew. View the logs.


3 years ago

#38 @ocean90
3 years ago

  • Keywords 4.2-fun has-patch commit removed

#39 @helen
3 years ago

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.

#40 @iseulde
3 years ago

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.

#41 follow-up: @iseulde
3 years ago

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

#42 in reply to: ↑ 41 @ryan
3 years ago

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.

This ticket was mentioned in Slack in #core by drew. View the logs.


3 years ago

#44 @helen
3 years ago

  • Milestone 4.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

#45 @helen
3 years ago

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.

Note: See TracTickets for help on using tickets.