Factorio Forums

Right click to open your blueprint book. Now, Shift + scroll up, and you will move down through your blueprints. Shift + scroll down, and you will move up through your blueprints. It's very counter-intuitive and it should be switched.

Turtle wrote: ↑

Wed Aug 28, 2019 6:44 pm

Right click to open your blueprint book. Now, Shift + scroll up, and you will move down through your blueprints. Shift + scroll down, and you will move up through your blueprints. It's very counter-intuitive and it should be switched.

Be aware that this is what "natural scrolling" is all about, and thanks to macOS making the switch, and Android/iOS, we have plenty of evidence that about half of people will find this is entirely natural and intuitive, and half will not.

There is no "natural" direction that people will expect that interaction to happen: some people think about scrolling moving the viewport over the underlying document, and some think about moving the document past the viewport.

In this case the behaviour scrolls the "document" -- the list of blueprints -- "up" in the sense that you moved the lower layer, the thing with all the blueprints, while keeping the viewport fixed in place.

slippycheeze wrote: ↑

Wed Aug 28, 2019 7:03 pm

Be aware that this is what "natural scrolling" is all about, and thanks to macOS making the switch, and Android/iOS, we have plenty of evidence that about half of people will find this is entirely natural and intuitive, and half will not.

There is no "natural" direction that people will expect that interaction to happen: some people think about scrolling moving the viewport over the underlying document, and some think about moving the document past the viewport.

In this case the behaviour scrolls the "document" -- the list of blueprints -- "up" in the sense that you moved the lower layer, the thing with all the blueprints, while keeping the viewport fixed in place.

If we were talking about viewing some content in a window, yes, you are correct; In THIS situation, we are selecting something, blueprints, using a mouse scroll wheel and not tapping on a multi-touch monitor.

Part of the confusion comes from the book being rows and not a pure vertical list. So there is no "natural" scroll direction to select "next in row" or "previous in row".

Rseding91 wrote: ↑

Wed Aug 28, 2019 10:46 pm

Part of the confusion comes from the book being rows and not a pure vertical list. So there is no "natural" scroll direction to select "next in row" or "previous in row".

That's where I strongly disagree, next in row is to the right and if it reaches the end of a row, it's to the bottom on the left on the next row. So moving "down" is the "natural" scroll direction.

Imaging this:
You are looking at youtube.com with a 5x6 grid of videos numbered 1 - 30 from left to right and top to bottom. So 1 is at the top left and 30 is at the bottom right. All you can do to navigate is up arrow or down arrow to select a video. You hit the up or down arrow key and the number 1 gets highlighted. In this case it's "natural" to assume that hitting the up arrow key is going to select video 2. So when I reach video 5, hitting up arrow is natural that it is going to select the video that is below due to the numbering sequence.

Now remove the numbering from the videos from the example above and just highlight the video frames or titles. The "natural" button to use to go to the next video is the down arrow.

This is about context and most common expectation; If I ask you to make a numbered list because we're making a list of the 10 most important items to bring camping, you will make a list from 1 - 10. If I read you a ranking or 10 tires, from worst to best, you will make a list from 10 - 1.

In THIS window, scrolling down the list should be shift + down scroll.

If this change is not going to be implemented, then I argue that scrolling down in this window should scroll the contents of this window down in order to keep it consistent - which is utterly ridiculous.

Just add an option to switch scroll direction and be done with this never ending debate.

I can't wrap my head around this "natural" scrolling. I learned computing in the last Millennia, back then I never heard of anyone that a page on screen should go up when scrolling down. For western users pressing right or down advances a list to the next element and left or up jumps back to the previous one, scrolling down means next and scrolling up previous. I doubt any of those natural scrolling supporters would fill spreadsheets from left to right and bottom to top.

Yes, when using touch input the direction changes since you physically move the page up to read what's below, but that doesn't mean mouse wheel inputs have to be reversed.

I don't get what Apple was thinking on this one - "natural" scrolling directions are clearly the opposite of each other between touchscreen and mouse wheel. (Not sure about trackpad ?)

Turtle wrote: ↑

Thu Aug 29, 2019 1:18 am

Rseding91 wrote: ↑

Wed Aug 28, 2019 10:46 pm

Part of the confusion comes from the book being rows and not a pure vertical list. So there is no "natural" scroll direction to select "next in row" or "previous in row".

That's where I strongly disagree, next in row is to the right and if it reaches the end of a row, it's to the bottom on the left on the next row. So moving "down" is the "natural" scroll direction.

Imaging this:
You are looking at youtube.com with a 5x6 grid of videos numbered 1 - 30 from left to right and top to bottom. So 1 is at the top left and 30 is at the bottom right. All you can do to navigate is up arrow or down arrow to select a video. You hit the up or down arrow key and the number 1 gets highlighted. In this case it's "natural" to assume that hitting the up arrow key is going to select video 2.

Are you sure this is true for folks who have a right-to-left writing direction? I'm sympathetic that it is "wrong" for you, but this is not nearly as universal as you seem to think.

Concretely, I think the current scroll is in the correct direction, but rebound the two rotate directions to the reverse of the default. Because that makes sense to me.

I guess so, but not so much for folks that go bottom-to-top, if any ?

Anyway, if it's a grid, up should go up, regardless of numbering.
(Tab/Shit+Tab might be a better example ?)

BlueTemplar wrote: ↑

Thu Aug 29, 2019 3:03 pm

I guess so, but not so much for folks that go bottom-to-top, if any ?
Anyway, if it's a grid, up should go up, regardless of numbering.
(Tab/Shit+Tab might be a better example ?)

It's been more years than my memory can handle since I worked on the table widgets in a GUI toolkit, but my vague recollection is that we had specific support for tab moving left in RTL language environments. I'm only, like, 60 percent confident about that, and have no recollection if it was the default or just an option. I mostly did the graphics and optimization, not the higher level design, on them anyway. By now I think I'm way off topic though, so I'm gonna leave it as-is.

While I hate options, Optera probably has it right: for scroll direction, nobody is ever going to agree with everybody, so a choice is the least worst option.

and to comments, even if you scroll through the blueprints with the book closed, there is still a "natural" order to them, or you wouldn't consider them backwards. since this is pretty much all about the fact that there is more than one definition of "natural" in that statement, it has the same deal as the scrolling window thing, etc, etc.

people are too complicated. whoever wrote the firmware for humans really did a hack job on it.

Calling black "white" does not make it white.

BlueTemplar wrote: ↑

Thu Aug 29, 2019 9:30 pm

Calling black "white" does not make it white.

"Steve Jobs enters the stage, wearing his trademark black sweater and says this is the new white."
People start calling black "new white".

Indeed !
I mean, "retina" was a bit annoying, and also how a lot of people seem to think that Apple invented smartphones.
But this is a new low...

Some also think Apple invented round corner and bitten apples