Hacker News Reader

Comment by jakelazaroff | Hacker News Reader

> The most striking example is when a horizontal menu bar is converted to a vertical menu bar: all the user's spatial memory of the menu bar's links flies out the window! That option that you thought were there? It's actually here!

What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.

Furthermore, vertical menus are far more common on mobile phones (not just on websites — apps too). Finding a way to shoehorn a horizontal navigation layout into a tiny screen is more likely to mess with a user’s spatial memory rather than respect it.

View on HN

Exactly this. You can either having pages that scroll horizontally or content that reflows. There is really no other option available when dealing with a layout that can be arbitrarily resized (edited to add: there are a couple other options such as scaling down all individual UI elements, or simply removing some elements but those aren't really viable solutions in most contexts).

Since we have collectively decided that horizontal scrolling is unacceptable in almost all web contexts, that leaves reflowing content when the window gets smaller.

I understand the complaint and I sometimes have a similar frustrations. But, what other options are there that don't introduce horizontal scrolling?

Not all reflowing is created equal. Say you knew for certainty your users were only on desktop. In that case you may still want responsive design but it will likely be a different responsiveness than what we get with the cliff dive to "the mobile site". Reflowing can be done gently and granularly at the exact maximum points needed with minimum changes - rather than the stark nuking to a completely different site at 700px.

Sure, but even if 100% of your users will be on a desktop site, you still need to deal with a browser window that has resized down to 300px.

At _some_ point, you will have to have a significant transition if you have an website that is mostly optimized for a desktop, full window experience.

I agree that many sites overdo the transition, but there are some things that really do warrant a phase-change at some point.

> Sure, but even if 100% of your users will be on a desktop site, you still need to deal with a browser window that has resized down to 300px.

In that case I would prefer the scroll bar over implementing a whole separate layout just for the 0.1% who resized their window to 300px for a moment.

> But, what other options are there that don't introduce horizontal scrolling?

- Wrapping the menu to a second line

- Moving menu items that don't fit to an overflow menu

Both of these would preserve spatial memory for all of the earlier menu items.

I think the issue is that many sites use screen size (e.g. max-width, max-height) as a proxy for things like "is this a touchscreen device", instead of using the media queries designed for that, e.g. (pointer: course) and (hover: none).

I understand _why_ things are done that way; it's far easier to design and test for three or four different screen sizes than it is to design for dozens of different combinations of screen size, pointer types, and screen orientations. Still, I get why some people might be frustrated about UI density _decreasing_ to accommodate a touchscreen when they reduce the size of their browser window on desktop.

> What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.

Before the author went off on a questionable advisement about javascript device detection he made a very good point: People should be using relative sizing for layouts so they scale.

Agreed, but I think the answer is still more nuanced than that. For example, even though touchscreen devices tend to have smaller screens, they need larger click targets; your finger is much less precise than a mouse cursor.

That's what zoom is for.

I don't want to zoom just to hit a tiny button. The design should accommodate my client. Zooming is an escape hatch in case it doesn't.

I don't want to have giant buttons just because some people don't want to zoom. Zooming is a feature to allow me to use my device the way I want.

Ideally, both users get their way. The web developer should be able to just say "button" and have the browser decide how big it should be, based on the user's preference and what is appropriate for the platform.

This isn't really an answer, you are basically throwing out usability for an appreciable fractions of users & devices.

> What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.

First and foremost I absolutely expect the page to not move things!

If I resized my window and things don't fit any more... then a scrollbar is exactly what I want.

Well, the context of the question, I think, is what you do when the "content" in question is navigation elements. I expect the page not to move things, either, but I also don't expect to have to scroll to access basic navigation -- and if you just let those elements wrap on a small display, well, we're back to the page moving things.

In general I'm (ahem) on the same page with you, but there are times when you have to decide on the least worst option.

If you have a site that needs navigation elements then you don't have a site. You have an app. You should build an app instead.

When I scroll on a site I expect all of the site to move. That includes and headers or footers or sidebars.

> If you have a site that needs navigation elements then you don't have a site. You have an app. You should build an app instead.

I have a web site that has multiple sections in it, and some of those sections have articles or stories in them, and some of those stories have chapters. I have breadcrumb navigation for it. That is a navigation element. I am not building an app. There are also web sites that have menus in them, because they have different sections and they choose to let you navigate between those sections using tabs or buttons or left-hand navigation columns or whatever. Those web sites are, nonetheless, still web sites.

> When I scroll on a site I expect all of the site to move. That includes and headers or footers or sidebars.

And when I view a site on my phone, I would prefer not to have to scroll left and right to access navigational elements. Because there will probably be navigation elements. Because web sites have those. :)

> I have a web site that has multiple sections in it

Cool. Scroll up to change sections.

> and some of those sections have articles or stories in them

That's pretty spiffy.

> and some of those stories have chapters. I have breadcrumb navigation for it.

When I read an ebook, I scroll down. When I scroll down I expect the navigation elements to move with (and disappear from) the screen.

If you want to repeat your navigation elements at the bottom of the page, that'd be a nice compromise. But please do not keep navigation elements on screen.

> There are also web sites that have menus in them

Menus are not discoverable in websites. Most websites implementations of menus is god-awful. It's absolutely _not_ intuitive, ever, that hovering a mouse should open a menu. And if you click a menu, should that navigate to a new page like clicking on anything else? Or should clicking suddenly _not_ navigate to a new page but instead do something different? How do you tell the difference?

Answer: you don't. The site shouldn't use menus. Use hyperlinks.

> because they have different sections and they choose to let you navigate between those sections using tabs or buttons or left-hand navigation columns or whatever. Those web sites are, nonetheless, still web sites.

And they're trashy websites that should be apps instead.

I mean, okay. I never said "keep navigation elements on screen"; I said web sites need navigation elements. As for "menus aren't discoverable in web sites," well, again: I mean, okay. They've been around in web sites for about two decades and maybe they've made you mad for about two decades, but I am going to go out on a limb and say that a lot of folks, when confronted with a list of items across the top of a web site that read like Categories of Things much the same as the menus that they have been using in GUIs in many many many other places, can intuit what's going on.

Maybe we're talking past each other. It feels to me like you're imagining the way these things that can be designed that you find absolutely the most annoying and deciding that's what I'm describing, and that you also have super strong opinions.

Also, thanks for suggesting the documentation web sites that I work on that have left-hand navigation columns are "trashy web sites" because I need to include tables of contents that are always visible, but I respectfully decline your demand to turn them into apps, because that's stupid.

I feel like this should be a browser option more than a design consideration.

How am I meant to tell if you are using a fullscreen mobile browser vs a resized desktop window?

> How am I meant to tell if you are using a fullscreen mobile browser vs a resized desktop window?

You aren't. Why should you assume that a mobile browser window is any different than a desktop window?

I have an Android tablet with a 13" 4K screen and a stylus. A full screen window on there is huge and you don't need a huge button.

I don't want huge buttons on my tiny iPod screen either.

> You aren't. Why should you assume that a mobile browser window is any different than a desktop window?

Because it quite obviously is. It would be absolutely bananas if the default view for the New York Times’ homepage was a super zoomed-out full width desktop site like it was in the original iPhone demo.

Reply on news.ycombinator.com