From what I can tell, the two biggest aggravators are the Chrome url bar and tab bar. There are ways for the user to fix that, but OGS can do stuff too:
Allow scrolling in landscape, resize board appropriately (maybe… we might need a css wizard)
Looking more closely, I gather “mobile landscape” is what you get when you turn your phone around to landscape, and for some reason the break-point make it lay out in the way that’s intended for desktops?
It’s as if there should be a minimum height for the landscape layout, so on teeny screens it never landscapes like that?
(And we’re all in raging agreement that this will be improved with the move-controls moved into the right column)
Yeah, I just turn my phone 90 degrees. Seems like it could be useful in some cases if the board weren’t tiny.
I assumed this was intentionally laid out for mobile - it has the hamburger menu and so on - but maybe we just have different breakpoints for different layout features applying on top of each other, and people get various unforeseen combinations?
“Mobile landscape” = landscape. We don’t try to detect the device. If the window is wider than high, you get the landscape layout, otherwise you get the portrait layout.
The difference is basically that mobile devices have a much higher pixel density, so everything defined in pixels scales down, but everything that is text, or depending on text size does scale much less.
Btw: You can change the text size in your browser’s settings, if you want the layout to break.
Right - that’s what I was also clarifying in my previous post. My undedrstanding is that Feijoa had concluded it was special for mobile because of the hamburger.
That’s not actually the case.
The relationship between width and height is not at the breakpoint is not constant, as you can see if you play around with the screen size in the brower debug tools.
connection indicator is a cool feature, so I had to turn on “Experimental”. Board became smaller.
For those who understand OGS code: I guess easy fix is possible:
there should be function that detects that board is already maximum possible size for current window or not if board is not max, just do not even start try to increase width of chat
bug where there are some users with standard width of chat when wider chat is possible
is better than bug where there are some users with wider chat when bigger board is possible
For what it’s worth, I think the OGS interface would look so much better if it switched into a 3-column format.
Earlier this summer I ended up playing a league game that ended up accumulating a lot of viewers and a lot of chat, and the tiny size of the chat window made it really really hard and annoying to view more than a few lines at the time. This was also particularly true after the game was over, which is when the AI analysis appears to take even more space, and even more messages become visible. I had not found this experimental setting back then, so maybe I would have used it. The problem is slightly addressed by this new experimental wide format, since the wider column would allow the chat messages to require fewer newlines, but I think it’s still not quite ideal.
There is so much space that could be used in a 3-column format, which is what motivated me to make my own CSS modifications to the game pages; see below, how easy it becomes to read the chat and how many messages it contains. Imagine trying to scroll through multiple such columns, but only being able to see 2-3 messages at a time… There’s only so much simple CSS changes can do, so it’s still far from ideal, but it’s such a big improvement imho.
I like the idea of a 3 column view, but I’d prefer the board to be in the center. (Like it is in the post you linked)
Also, three columns would exacerbate @square.defender 's bug, so someone looking to implement this would need to make sure the columns still stack on screens that are landscape, but not very wide.