Hacker News Reader

Comment by PMunch | Hacker News Reader

I wish more pages took the pointer and resolution media queries into account. So many times I open windows side-by-side on my desktop and end up with the menu collapsing into a hamburger menu which fills the entire screen when clicked. Many phones today have very high DPI and very low precision in touch, so it makes sense to have massive visual elements and buttons, but my desktop with the same size in pixels as my phone but a much lower DPI and much higher input precision doesn't really need them.

View on HN

This. Unfortunately today, the desktop is an afterthought and everything is designed for “mobile first”. I even see this in SaaS apps that should actually never be used on a phone. Or desktop OSes like windows and mac are increasingly using mobile paradigms on the desktop.

There is so much whitespace, huge fonts, huge buttons, hamburger popup menu everywhere (aaaargh!!)

Basically it boils down to the “information density” which is dumbed down to the lowest possible denominator.

There should be a measure for this and websites/apps should be rates based on that.

It sounds like you are talking about gmail web at md2 era. The giant sidebar item that can only literally show 6 item on a 1080 screen. The giant mail row that display only 10 or maybe 15 mail on whole screen. And new mail button on right bottom that requires you move your mouse across the whole screen to write a new mail.

It really makes me wonder 'wtf? Who designed that, did he actually try to use it by himself?'.

At least it seems they steps back a bit now. Also they moved the new mail button back to top left.

I'm actually not entirely sure what you're talking about.

I'm very familiar with websites switching to mobile layout with hamburger menu instead of a navigation bar, when you reduce the width of the browser window on your desktop. BUT I don't think I've ever come across a resolution change where the website elements (either hamburger menu or content) get massively larger.

Can you provide an example of one or two mainstream sites that change resolution like that?

The reason I'm confused is because in CSS everything is based on logical pixels, not actual device pixels. E.g. a "1 px" width will be 2 or 3 hardware pixels wide on an iPhone. Similarly "1 em" will be 16 hardware pixels on a standard resolution display, but 32 or 48 hardware pixels on a 2x or 3x display. So web designers don't have to do anything special to accomodate hi-DPI screens in the first place.

The resolution doesn't change, but a 64x64px icon button doesn't need to be that big on a desktop.

But this is my point, I haven't been seeing any 64x64 px (logical pixels) hamburger menu icons out in the wild. That would be too big for mobile as well.

The hamburger menu buttons all seem normally sized to me when I make a browser window narrow on my desktop.

Yes, if you are on a touch screen, you need 'normally sized' hamburger menus. When using a mouse, a 16x16px hamburger is plenty big enough.

I think you may have misunderstood my comment. I'm saying I am seeing normally sized hamburger menus on desktop. You're using an example of 64x64, I'm saying I don't see that.

Although 16x16 is a little on the small side even for desktop. The point isn't just to click it, but to have it be prominent enough to see and notice as a primary action. It's about visibility, not touch area.

For example, on the SquareSpace homepage (an example someone else brought up) it's 30x18. That seems like a nice size to me. It's two pixels taller than the 16 you suggest, but the extra width helps make it a little more prominent. Especially since the width isn't taking away from anything else.

It is 44x44 on my computer. Absolutely massive.

https://imgur.com/a/dL1Se2v

It can't be 44x44, it's not even square.

I can't tell what units you're measuring in, are you measuring hardware pixels on a hi-DPI screen? We're talking about logical pixels which is the only thing that makes sense to measure in and compare.

But comparing it with e.g. the refresh button on your browser, it's merely 17% taller than that, in your screenshot. So I literally don't know what "absolutely massive" you're talking about.

It seems perfectly fine to me. Maybe I'd make it a little narrower, but they probably wanted to balance the logo in the top left corner in terms of visual weight, so it makes sense.

The button is 44x44. The SVG is 30x18

If that's the clickable area, is someone complaining that's too large?

You've been able to select radio buttons by clicking on their text for decades now. On desktop. Often literally hundred of pixels wide.

Generous margins for clickable elements seems like a feature, not a problem. As long as they don't interfere with anything else (which they don't, here).

I happen to agree, just trying to point out the miscommunication

> Often literally hundred of pixels wide.

And 16 pixels tall...

The folder on your desktop is roughly the same size.

Sorry if I was unclear. I didn't mean that the resolution changed, but rather that pages should take into account how big elements will actually appear in the real world. Typically if I open a website and half-and-half my browser with a terminal the website goes into mobile-mode. The page however is about three times wider than my phone screen, and the hamburger menu is more than twice the size of my mouse cursor. Just because I don't have the page open full-screen any longer doesn't mean that I suddenly can't click the same size buttons or read the same size font, so there's no point in making everything big and clunky.

I know the official line is that "media types have proven insufficient as a way of discriminating between devices with different styling needs." But as far as I can tell most people really do just want to know if the visitor is viewing on a monitor or a phone. Trying to back that out through media features like viewport resolution and pointer types has been a big mess. I don't think the plan to replace media types with media features is wrong, but so far we haven't been given the right features to do what we want.

When I visit my bank, with my browser taking up half my 1080p desktop display, it tells me to use the app instead.

This is an interesting observation. Do you have some examples of this?

> Do you have some examples of this?

Sorry if it sounds rude, but have you used the web on the desktop in the past 10 years? Anything under 1000px-wide windows and sometimes 1200px-wide ones gets you the “mobile menu” on most websites. It’s a consequence of Bootstrap and other fixed-breakpoint frameworks. Overflow menus like what you see on GitHub repositories are the minority.

Screenshots: https://cloudflare-ipfs.com/ipfs/QmUL69cYwCs2sWV7eHqtt14BEcn...

Those are great examples, thank you for spending the time to make them.

react.dev

And for an example that does it better, legacy.reactjs.org :)

When I saw it I wondered how they managed to drop the ball so hard and how much they paid for it. All they needed is to expand and slightly restructure the docs, but apparently someone sold them a complete redesign that just made the whole docs way less usable (a11y aside, can't speak for that).

It doesn't work like that. Web browsers do not count actual pixels when rendering. They adjust high density pixels to the equivalent real life size of low density pixels.

The OP is talking about things like media queries that only look at screen width and imply other things like input method from that.

IIRC SquareSpace does exactly what they're saying: on desktop sites will have a horizontal list of links but on mobile it's a hamburger icon that takes over the entire viewport when clicked. Functionality exists to target pointer type and things like that in media queries, it's just very rarely used.

Ohhh, I had no idea! Thank you.

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...

    coarse - The primary input mechanism includes a pointing device of limited accuracy
    such as a finger on a touchscreen.

    fine - The primary input mechanism includes an accurate pointing device, such as a mouse.

This solves everything! What I really want is having more padding on mobile, that's it. I prefer things to be compact otherwise, and it seemed hard to square that circle... with the pointer media query it's so trivial.

Gotta love how every time you don't watch CSS like a hawk, it spawns 500 new features. Thanks again.

I'm actually surprised this isn't a selector in tailwind css.

That is one of the issues trying to re-implement every css property:value pair with a class name inherent in Tailwind.

But that's what you want, no? I just visited SquareSpace and their homepage seems to work as I'd want. When my viewport is narrow enough that there isn't space for the horizontal navbar at the top, it switches to hamburger menu.

Surely this is better than cutting off the navbar and half the page content in the middle vertically, and requiring the user to scroll horizontally?

The hamburger menu could just be a vertical drop down stack rather than something that takes over the entire screen.

The point is that the viewport-covering menu is huge because it’s designed to accommodate touch (i.e. imprecise) interaction. It could be much smaller when the user is using a mouse. But you rarely see such accommodation being made. The assumption is low width = mobile = touch.

I still don't get it.

The actual menu items you select are 20 px font size in the hamburger menu, and 18 px font size from the navbar menu. That's just 11% larger. Nothing about that is "huge".

The hamburger menu taking over the whole (narrow) screen doesn't bother me at all. If I'm using the menu, it's not like I need to be looking at the rest of the screen.

And it just feels silly to create a third design. We already have navbar for widescreen and hamburger menu for narrow screen. Now you want a third version -- a hamburger menu that is pop-up rather than fullscreen -- for narrow desktop usage? I sure wouldn't want to do all that extra work.

Reply on news.ycombinator.com