It would be nice to get the top, new, and top components in the top menu and the hamburger menu in the left. For example reddit is new
@Johani great work…are you planning to create a theme for this or it will be part of the core ?
Very nice, would love to see this as a theme !!
I created another theme based on the customized one listed in the original post:
It is more generic, and supports i18n locales, but it still needs some cleaning and improvements though.
You might like to have a first look:
(The screenshot presents how it works with the official Material Design Theme)
Well…It is possible to implement it by reopen some widget and rewrite the hamburger menu in a theme with a script block of type “text/discourse-plugin”, but it may result in a large amount of unused code rendered to the user.
I agree that it is better to include the design into the core.
The simplest way is to reattach the menu button (
#toggle-hamburger-menu) in the front of
header. Nevertheless, a clear DOM structure of the menu itself should be better.
Actually, I’ve developed a theme for my own website for a few months.
Warning: The theme above contains a lot of non-internationalized, hard-coded string, and many dirty hacks / improper coding practices. (It supports only
That looks nice!
I think it’s definitely worth considering something like this for core… one thing I’m not convinced on is having the hamburger icon on the top left. I don’t have a particularly large phone, and it’s impossible for me to reach that top left corner with one hand (the top right is pretty far away too, but it’s at least possible). Swiping helps, but we’ve also got the native browser gestures to compete with.
Also for what it’s worth, it’s starting to feel like more apps are beginning to move away from the top-left hamburger menu on mobile in favor of the bottom bar. (For example: Google’s new News app and the latest Netflix redesign have their primary navigation links in the bottom tab bar.) Bottom tab nav is a whole different conversation (and we’ve got a nice plugin already!).
One of the trickier things in the hamburger menu is how we handle categories. I think the flat list is starting to be a bit limiting for sites with long category lists, and it’s not particularly well suited for subcategories. Should we limit to popular categories (globally popular, then personally popular?) and rely on the full category page for the list of everything?
Improving the category list in the hamburger menu
I have a long history of burying the lead and otherwise conflating multiple independent ideas in this topic
Can by and large be kept completely separate from this:
There’s really 3 separate UX discussions to be had here:
Figuring out how to do a full-height, slide-out hamburger menu, which turned out to be more difficult than expected the last time we tried it: Full height, slide out hamburger menu
Is the hamburger menu due for a redesign? My personal opinion is a resounding YES.
Where should this menu be clickable and come sliding in from? That is highly subjective and ideally it’s the sort of thing that could be easily tweaked in a theme component anyway. The discussion comes down to what should be the default. Considering we already have a long-standing default in the top-right, I suggest we table this discussion indefinitely and in the meantime users like @misaka4e21 can enlighten us with theme experimentation.
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)
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.)