I second this dropdown proposal for desktop (although that is not what the original question is about). I also like that it would create space to have a permanent search box in the nav bar.
4 Likes
This would be great. I only really go to the OGS site to search for a player.
3 Likes
I know it sounds good at first, but generally is nowadays a bad idea. As the âsameâ website gets accessed via a range of devices (often by the same owner) you really want the site to look as identical as possible every time.
Dropdowns wonât work on tablets, yet the resolution is same as desktop, suddenly the search bar is gone and eveything is somewhere else? etc. Having a menu and then drowpdown sub-menus? Sounds unintuitive and scary for newcomers⌠It becomes a nightmare for both the developer and the users very soon⌠I donât think it is a way to go and having to navigate dropdowns kind of defeats the purposes of easy-access links at the top anyway.
In such a scenario it would make more sense to just leave most of the options in the menu and just have play / chat / search, or something like that, but not sure if thatâs what we want.
1 Like
Hi Adam,
Can you explain your viewpoint a little more? Iâve used drop-downs on tablets to great success. Hereâs an example of one I hand-coded years ago that still does just fine. Theyâve been working on mobile since the early days of smart phones (though not without a little bit of growing pain in the first year or so).
While rearranging anything in an interface may feel sudden if not expected, there are good ways to clue users in to show them where things have moved to. Thereâs no reason anything needs to feel âsuddenâ. If anything, I think newcomers would be the least affected, as they wouldnât have prior expectations about where things should be.
Most developers Iâve encountered that do any front-end work have no problems with drop-downs. Users have seen drop-downs as a common pattern since the advent of windowed OSâs.
A second click to browse to a link does increase the overhead for navigation, but I tend to believe itâs still preferable to truncating the list of options for users on smaller screens, which is whatâs happening now because we have too many options in the bar. A drop-down categorization system aims to better utilize the space so we donât hit this cropping issue.
Iâd love to learn more about your viewpoint, though. Itâs one Iâm not familiar with. Can you explain for me?
4 Likes
I really like the proposed idea except it doesnât really go together with the rest of the site. It just looks really modern compared to the rest of the site. For example, when I go to press a tourney or group on the side, it has the link underline, which would feel weird if we had the highlighted navbar together with this.
Overall, I feel like it would be really cool to implement this. Maybe as a future idea, have the tournament list and group list have the same highlighted function?
1 Like
As a laptop user I voted for no navbar at all. I donât like the navbar stealing vertical space from the board on small widescreen monitors (mobile horizontal orientation, laptops etc). The current layout already looks bad enough and going into zenmode manually every game you play/spectate is extra hassle, which makes me want to just open Cgoban, or any other client which is able to utilize the monitor properly for the go board.
We have to remember OGS is being used by web browsers which usually have navbars their own and a regular user doesnât necessarily go into fullscreenmode only for this web site. So vertical space that is left to the go board can be scarce.
3 Likes
I can try, sure 
The original propsal was âdropdown for desktopâ, which my reservation is hopefully obvious, the website would look and work differently on different devices, which is not good for intuitive navigation
Well, it does not work for me, sorry. Might be my browser only, but I doubt it. Clicking the dropdown reveals the menu, yes, but immediately also loads another sub-page which hides the menu when loaded. I donât think thatâs the intended behavior. There is simply no âhoverâ on touch devices - thatâs the problem.
You can have dropdowns react to clicking, which would work the same across devices, but itâs clunky on mobile (and does not fit if there is more items in the menu), can be a bit unintuitive on desktop and kind of defeats the purpose altogether of easy to access links if it requires two clicks and navigating a list. We already have all of those in the menu, so whatâs the point, that would just be redundant. (And they can also be annoying on touch as they are hard to get rid of - you need to click elsewhere + other potential issuesâŚ)
Having both a classic menu AND dropdowns, is also not very clean and intuitive solution.
I might have missed something no doubt, but I simply do not see a solution with dropdowns that would fulfill the purpose of the quick links and work across all devices. Hope it makes more sense now
1 Like
If consisteny between touch and mouse is a strong requirement, you could achieve that by not using the hover event to expand the dropdown, so the dropdown would only expand when you click/tap it. This is exactly like how main menus tend to work on desktop (windows) applications. It looks like the hamburger menu is already working like that (expanding on click).
2 Likes
Thanks for clarifying!
I wasnât aware this suggestion was just for desktop. Reading it over again I still donât see where that was clarified, but it does make sense that that distinction could clear up some misunderstanding. Generally speaking I prefer a web interface that is handled the same on desktop as it is on tablet/mobile (assuming thereâs space), since desktop users almost never use screens as small as mobile, and only rarely use screens as small as tablets.
I just did some tests on my menu, and indeed it looks like Android regressed on this. Thanks for the heads-up! It used to handle just fine, and it looks like they changed the default behavior. Iâll need to revisit that. I wonder why Google thought nerfing a very standard (by now) behavior was a good idea. 
I do believe there are better solutions than a drop-downâbut I still think a drop-down is better than having a list of links that disappear without explanation when the screen narrows. Ultimately, I think we probably have a better option than to try to make the top bar an extensible menu system, but thatâll take more exploration.
1 Like
It might have also been me imagining stuff that is not there 
always a real option 
Ah the suspense! Donât want to pressure you into sharing more until you are ready/have tested, but obviously I (we) would be very interested
2 Likes
Could you have it so that when the window reaches a certain width the buttons on the Nav bar get removed and replaced by the Hamburger menu icon on the left? Thatâs how it works on Lichess.
Desktop: you also have more knowledge of the history of this discussion prior to this thread, so I expect you have more complete context!
Ahha! The âbetter optionâ statement isnât to say Iâve solved this already, but more to agree that the drop-down is not the best. Iâm sure we can figure something out, though. The tough bit is that even the best solution involves changing expected behavior, so whatever we find will probably hurt at least a little.
The code to do this definitely exists, and the pattern is a common one in cross-platform apps. So in short: yes, we could. The question is more one of usability heuristics, which I think we need to deep-dive before making any huge changes. Thankfully this thread is only about making the bar 1em taller. 
Good thought! Itâs an idea worth exploring, for sure.