Hello, I have tried your sidebar but I want to make changes.
I want to show only the categories on the left, so I want to use the categories to make the drop down menu.
And I want to write a text instead of icon .
The menu that opens is not closing when I click on the image (header)
A post was split to a new topic: Category list in the hamburger menu
I took up another weekend project to allow swipe gestures for mobile, building off of some previous swipe work that is already in core. I only target mobile views here, so neither large nor small desktop views change.
IMO gestures allow for Discourse to feel a lot more at home on mobile - this is the result:
Just an experimental prototype or is that going to make a release?
I guess the issue with āswipe from leftā is that is an iOS gesture in Safari for ābackā?
Itās not yet released - itās a coded proposal, but I wanted to collect some feedback first 
Great stuff Jeff! Iām such a fan of making web pages behave like native apps!
Iām not sure we could release something like thisā¦ as mentioned previously, this would interfere with the iOS swipe to go back/forward functionality, right? I think thatās a restriction we have to live with.
I was hoping that safari would honor css touch action properties so that we could define our own gestures. If not, consider me pretty disappointed in Safari.
It was a pretty nice --gesture-- at least.
As far as I know Apple has the browser gestures locked down entirely. There are some hacks out there, but theyāre pretty extreme (preventing all touch within 20px from either edge). Weāll have to continue pushing buttons the old fashioned way.
Iām fine with the button pushing, Iād expect that actually ā I use swipe back and forward from the sides a fair bit on my iPhone!
I love the full size menu on mobile, have wanted that for some time, kudos @featheredtoast 
Thanks for the feedback! Kinda bummed that iOS steals swipe gestures like this but I guess I get the appeal for that gesture on browsing at-large.
Iād really like to play around in this space and see if thereās a way to eek out progressive changes, where swipe-to-open could be disabled on iOS so the swipe back/forth could continue to just work without interruption there. (Note in the gif that good olā button pushing still works!) Will eventually like to test out different options here, but I unfortunately do not yet have an iOS device to test this out on just yet.
Well if you like slow mobile devices, Qualcomm and Android have got your back 
On Android, be careful that you donāt turn scrolling motions into menu opens. A drag at the edge of the screen @ a 320deg heading should be a scroll, not the menu.
(Googleās Blogger platform is terrible at this, because almost the entire screen is a place you can start a Previous/Next Article drag from. Which isnāt even something you want to do that often.)
Yeah, I hear you - itās definitely a priority to get those details right. Iām making sure that vertical scrolling is not being stolen, and that menu events only fire within a set px from the edges of the screen.
Actually, I think a percent might be fine here? Some devices have heavily beveled edges or have overstepping screen protectors, so itās hard to get all the way on the edge. As long as the angle is reasonably tight itāll be fine.
% might work. Iāll have to experiment and see what works best here. Regardless, I can declare that the center is definitely ignore zone central.
I also spent a bit of time trying to get direction right, and I am only determining movement in 4 directions (up/down/left/right). It also waits for a 5px move before making a decision about where the finger is going, because otherwise Iāve found it is just not accurate at all.
This came up here (FFed to 8:10):
I definitely donāt want swipe from the left being stolen on my iPhone. Glad theyāve got it locked down to going back one page.
But Iām looking forward to the full-size menus and being able to swipe to dismiss them.
I think the point is that they have it so locked down you canāt leverage that in a PWA even for the action it is intended for, e.g. to go back from Topic to Topic List. And that is NOT good. You then need an actual button, which is rubbish, given all you are trying to do is repeat the same action as the website has which would seem to be a perfectly reasonable expectation and a de facto standard. It works even in e.g. Whatsapp.
https://meta.discourse.org/t/progressive-web-application-pwa/79217/26?u=merefield
I must have misunderstood. I thought that if I saved the site to my home screen as an āappā then it worked?
Otherwise, it is a website in my mind, and must conform to website standards.
Not to say that this UX would be bad in an app, but imagine all the websites stealing the ābackā button and preventing you from going back to the website you were on prior to visiting the site. Thatās just basic dark UX behavior. Websites that prevent me from leaving the site via the back button need to be shot. Lol.
