The main menu would be more accessible if it was invokable by swiping from the side of the page at any point in the article rather than only at the top centimeter of the article. Most pages are scrollable and the menu button is accessible for 99% of it.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T158314 [EPIC] Mobile site should support swipe user interactions | |||
| Invalid | None | T208155 Main menu should be swipeable |
Event Timeline
Comment Actions
@Niedzielski to clarify, you're talking about opening the menu?
Regarding iOS: on web browsers (Chrome, Safari, Firefox) swiping rightwards from the left-edge of the screen takes you to the previous page (i.e. it's a back button). This is also the behavior in many other apps.
Regarding Android: web browsers don't have the same swipe/back pattern. In apps the swipe to open menu drawer seems common, though I'm not finding any websites that support that behavior.
Two general notes:
- I think swipe to open/close actions on the menu would feel more natural once we did T206354.
- Perhaps we'd benefit from framing the issue more generally, e.g. make the main menu accessible from the middle of an article? In which case I'd say making the site header re-appear upon scrolling up (as in https://wicky.nillia.ms/headroom.js/) would be a better solution.
Comment Actions
Regarding iOS: on web browsers (Chrome, Safari, Firefox) swiping rightwards from the left-edge of the screen takes you to the previous page (i.e. it's a back button). This is also the behavior in many other apps.
@alexhollender, is this true when you swipe from the _edge_ of the device? I think if you swipe from the edge, the menu should be drawn out.
In which case I'd say making the site header re-appear upon scrolling up (as in https://wicky.nillia.ms/headroom.js/) would be a better solution.
If a sticky header menu is an option, you have my full support!
Comment Actions
@Niedzielski yes, all the way from the edge or slightly inside of it. So at least I don't think this makes sense on iOS :/
What if we merged this into T206354 and called out the swipe-to-open behavior as an open question (since the task already discusses swipe-to-close)? I realize we could theoretically do this separate from T206354 but I imagine that's unlikely.