Hacker News Reader

Comment by crazygringo | Hacker News Reader

Ugh. Can I just say that using the scroll wheel for anything but scrolling is one of my all-time UX pet peeves. Probably #1, in fact.

Above all, Google Maps repurposing it for zoom. Like, I'm scrolling down a webpage, there's an embedded Google Map, and suddenly it stops scrolling and starts zooming in by orders of magnitude and it's just a WTF moment... you're breaking the web. Nobody wants to zoom by orders of magnitude like that. Nobody asked you to stop scrolling the page. It's beyond useless.

Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.

View on HN

I'm so confused. I've never wanted the scroll wheel to do anything but zooming on Google Maps. It's not like there is anywhere to scroll to in the first place?

On Maps prime site it makes sense, embedded on other pages it makes less sense. But, the page other needs to add one line of config, or G needs to change defaults for embedded

But even when I'm on an embedded map it's super annoying to have to hold control... I pretty much never want to scroll if my mouse is hovering over the map. It's how it works in every application isn't it? Scrolling while hovering affects the object under the cursor, not the object with the focus. I feel like it might be better if the page has logic that checks "if you're already scrolling, then keep scrolling the same object instead of shifting focus to the embedded map"?

I have yet to encounter an embedded map that could not have better been

- a static image

- a table of addresses with an external map link

It's not just the idea of wheeling around in some 256x256 box added at the last minute to a Contact Us page, the entire concept of an embeddable map is shit

Their main purpose seems to be to add 1 second to page loads across the web, and feed more clickstream back to the mothership

The main exception to this I can think of right now is Flightaware, but even that does not require such detailed rendering

Maybe if you have a scroll wheel, but with a Magic Mouse you can swipe in all directions and you would want it to pan around the map, not zoom.

In my experience Google Maps fixed embedded maps about a year ago, it requires command-scroll to zoom and otherwise scrolls normally. I didn't realize that might be browser-specific, I'm using macos + safari.

Son of a gun. So for embedded maps, it only took them 13 years to fix, from 2005 to 2018. Better late than never, I suppose.

However, it still doesn't change the fact that, on my Mac, on Google Maps proper I want to use scroll wheel or two-finger swipe equivalent to pan/scroll up-down or side-to-side like virtually every other app does, instead of zooming like virtually no other app does.

I think this is unique to you. Click + drag to pan and scroll to zoom has been the way maps work for as long as I can remember.

Having the scroll wheel move in y with no scroll to move in x just seems...weird.

Ah, you should’ve seen what we had before Google Maps — https://images.app.goo.gl/JQ5xAhP8HpZjRNby7 The map was a static image, you had to click to change zoom levels and wait for the entire page to reload, or click to move in a cardinal direction and then agonizingly wait for the page to reload. The idea you could have infinite scrolling tiles of map with a simple way to map directions that auto-completed street names parsing from a plain English search — that was basically a revelation. :) Though MapQuest did give decent directions and a nice overview of where you were going.

Before that, you had to buy a book every year to keep in a glove compartment and look up street names in an alphabetical index, then go to a page number, look for a row and column and then plot a route by flipping between many pages or having traveled there before (aka getting lost) https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9

Also a Google Maps innovation—trying to accurately put street numbers on a map. You’d often know, in some books, where street numbers began and ended at intersections, but it was extra detail and was often left out or entirely wrong. Of course it’s still wrong today, but street view really changed all that.

Should clarify: I have used an atlas (in fact I had one in my car in 2018 when I sold it), but internet maps have always used that interface, though I do remember that mapquest interface and the similar interface on tribalwars.net before it updated to use js and click+drag map scrolling.

If you want some nostalgia, StreetMap is still just as it was in 2002 or whatever.

This alone convinced my father that it was worth having Internet access at home.

http://streetmap.co.uk/map.srf?x=531500&y=181500&z=120&sv=Lo...

> Having the scroll wheel move in y with no scroll to move in x just seems...weird.

Shift+scroll works as horizontal scroll in just about every place I've had reason to try it. (Outside of browsers, at least, though there I'm uncertain because everyone puts so much effort into eliminating any horizontal scroll)

Shift + scroll wheel scrolls horizontally in Firefox at least.

I think it's a configuration option when embedding the map, so it varies from site to site.

I believe you're correct, although I'm talking less about embedded maps, where I agree that having the map take over scrolling is aggravating, and more about the map interface in general.

No, I too want to use the trackpad to pan the map. Not least because my initial muscle memory is always "swipe to scroll" followed by "FECK GOOGLE" when it doesn't work and then switching to click-drag mode.

> Having the scroll wheel move in y with no scroll to move in x just seems...weird.

Scroll wheels are still a thing in 2019 ? I can scroll in any direction using either the trackpad or a Magic Mouse in pretty much every app and website except Google Maps.

I think the counter-argument is you can drag-and-drop to pan the map (a Google Maps innovation) and so scroll-wheel was used with a mouse to zoom in (a “wow” feature from back then). But this is all very 2005, mouse-centric. It makes more sense when you consider Google Maps went full screen in a redesign — which lets them behave more like a game or interactive experience than a webpage. I remember mapping scroll wheel to switch weapons in more than one game—scrolling in games isn’t something you expect to do with a scroll wheel. That said I get frustrated easily on mobile when I zoom in or out in a map and I don’t mean to. It’d be nice to have a little “Undo” button/bar appear for 10 sec just to make life a bit easier.

Actually 2016: https://cloud.google.com/blog/products/maps-platform/smart-s...

I actually only really hate this because now it requires two active hands to control the map element. I'm sure google already did consider this when they decided to change the functionality

Do you have a suggested alternative? Personally I love scroll to zoom on maps, find it a really natural action.

In many other apps (e.g., web browsers, Office apps) Control+Wheel is used for zoom. Any modifier key with the wheel would be fine.

What would the wheel do otherwise? I don't want the scroll wheel to pan vertically. I guess doing nothing is acceptable, but I honestly zoom enough that I actually prefer the one handed action on my computer. I probably would just go back to double clicking if scrolling to zoom required a modifier, and that's worse UX because there's all sorts of stuff I could accidentally click on when double clicking to zoom.

If they do choose to go with a modifier, I hope it's not control, because I hate accidentally zooming the page with the browser's zoom since it breaks nearly every page out there.

But this would compete with the browser zoom

Ugh, terrible UX. No, makes no sense. Users expect to use maps with scroll to zoom.

If you are going to have a Google Map on a contact us page it is better to not bother.

A static map may be underwhelming for the tech people but it is better. No need to load the Google plugin so +3s page load, so better search. Plus, if someone wants the map the link around the image can take them to Google Maps and they can then type in directions, see your reviews and bring actual business your way.

Cutting down the bloat helps, sometimes simpler is better.

At the moment I have a project where I am trimming the maps out of the footer of the home page.

The static maps I am putting in place have been saved with srcset images so the pin is in the middle with mobile and off to one side with desktop. mod_pagespeed does the image resizing so that the images a customer sees are always bandwidth friendly. Why have 3s of download (or more) when you can have a 12k image come down the same http2 connection?

>Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.

Maybe you have a small imagination? :)

I use the scroll-to-change-number-input feature quite a lot, for one. Since you have your mouse already in hand, it's faster and more comfortable than switching to keyboard/numpad for quick adjustments or inputting small values; and definitely better than clicking the tiny arrow (does anybody use these anymore?) 32 times or clicking and holding.

I completely disagree. When I see embedded Google Map I always try to zoom it by scrolling, but then get frustrated when it scrolls the page instead and I'm supposed to press control for zooming.

Unfortunately that's pretty much the only way not to confuse the majority of your users. It depends a bit on your target audience of course.

At work we have a lot of embedded Google Maps and any content below the map was rarely viewed. Once we disabled auto focus, we saw more and people scrolling to content below the embedded map. Suggesting that people got confused by it and simply left the page. For us, it was the right thing to do.

When scroll-wheeling through a KDE/Qt scrollable form, if your mouse cursor happens to land on top of a slider/numeric/dropdown widget, the form will stop scrolling and all scroll inputs will instead scroll the widget.

I reported this at https://bugs.kde.org/show_bug.cgi?id=399324, and several Reddit posts have complained about the same thing.

This issue may also apply to GTK.

Scroll wheel is used to zoom in a number of applications, and I find it to be very useful.

I'll admit, I prefer something like CTRL+<scroll> or something to trigger it as an alternative behavior, but that's a minor qualm, really.

Ah, yes, I had to spend an afternoon disabling that in 2011.

Reply on news.ycombinator.com