Why are nested elements scrolled to the opposite direction?

Question

My question is about scrolling conventions, and spatial scroll conventions in general (even here it's only horizontal, but same applies for vertical scrolling).

Looking at the below mockup, why is it that the perceived expectation for clicking on the left << button is that the nested boxes inside the big container move right, and vice versa for the >> button on the right, I'd expect the nested elements to move left.

^{download bmml source – Wireframes created with Balsamiq Mockups}

This way of scrolling seems to be the default I have seen on many sliders, scrollers, carousels, etc. When I created a prototype where I tested a reversed sliding direction of the nested elements, it just didn't feel right.

What is this standard behaviour based on, and why does it feel counter-intuitive to move the nested elements in the direction of the arrows?

Does anyone have examples where the direction is in fact different to what I am describing here?

Answer 1

There is very simple logic behind it and that is difference of perspective. For example Make a frame of your fingers and like shown in the image below and turn your "frame" towards the right and see what happens.

• you move your frame right and your vision moves left.
• you move your frame left and your vision moves right.

Now you have to pic one of the two perspectives to explain who is going where. If you talk of your frame of fingers, then they are MOVING LEFT but if you are talking about the VISION then VISION IS MOVING RIGHT.

In computers, our screens are stationary and they do not move. That is why whenever we think of moving something, we imagine its the VISION that is moving instead of screen. Keep the same learning which you had above, this will explain that why >> actually means to move the VISION TOWARDS LEFT and << means move the VISION TOWARDS RIGHT.

Answer 2

The conceptual model isn't "left arrow moves the elements left"; it's "left arrow takes me to the element on the left".

With indirect manipulation like this, it's probably fair to assume that users are thinking in terms of the content they're consuming rather than the spatial projection of the UI.

Answer 3

The first thing which came to my mind after reading this question was "Theory of relativity". Lets me try to explain you in a more scientific manner:

Suppose, you wish to see content hiding behind the left edge of the frame. So you'll click the left button. Now, you should be moving towards left to unhide the content but you and the content slider frame are stationary. So, you should see the item inside the content slider frame moving right. The same thing you can visualize in the images below; when you see motion of one car from other car's rest frame.

Reference

Answer 4

What is this standard behaviour based on, and why does it feel counter-intuitive to move the nested elements in the direction of the arrows?

Arrows indicating the direction of the viewport/frame movement is simply the dominant convention since the Mac (actually Lisa) was developed. Apple established this and Microsoft followed suite, and after that it would be crazy for anyone go against that popular convention. But it wasn't always that way, here's some early GUI history about scrolling.

These are just conventions, there's nothing significantly better or more "natural" about focusing on the direction of movement of the viewport as opposed to direction of the movement of the contents. In fact Apple more or less reversed this emphasis (mouse-wheels and trackpads now move the contents, not the viewport) a couple years ago on its desktop software to be more aligned with iOS.

Answer 5

On a desktop environment, typically the usage of carousels have been as explained by you in your wireframe, i.e. clicking left arrow brings left elements in pushing right elements out and vice versa.

This is not just because of a dominant convention due to the fact that someone started this and everyone followed and nobody dares to challenge or change it now. Infact, Apple introduced this behavior and with the new OSX, they have themselves reversed the paradigm, so now scrolling left moves all content left and vice versa.

The earlier convention has another aspect to it which is related to attention and focus area of the user. This started mainly for a mouse based interaction, wherein user is pointing their mouse to particular locations of the screen to click and make the carousel move left or right. Cognitively, when he/she does that action, their attention, focus and vision too moves to a particular location of the screen, i.e. towards the left or right arrows/buttons. Given this and considering their peripheral vision, it made most sense to scroll the content right on pressing left and vice versa. When the user is clicking left button and content from left is pulled in thereby pushing existing content to right, it is easier for the user to look at the new element without moving their focus by simply using their peripheral vision, as opposed to moving the vision/focus to other extreme of the carousel. This especially played an important role when there is lot of content and user is continuously scrolling in a direction, i.e. lets say there are 10 elements in the carousel and the current position is such that 4th or later content is visible on the carousel with 3 or more hidden towards left. When user moves their vision to left arrow and starts scrolling, they could keep their focus on this area and using peripheral vision keep scrolling and scanning each of the appearing content to find the one they are looking for.

This paradigm changed drastically and reversed in case of touch based mobiles where user interaction were not pointer based but flick based. Since there was no pointer or button involved, there was no such requirement to consider moving the focus area to a particular location of screen to take the action to scroll. Rather user could flick left or right anywhere inside the carousel region to scroll. So instead of a particular left/right region the whole carousel became focus area. In this case, it seemed more natural to treat the carousel as a real world where if you move your vision towards left, you see what is on left and vice versa.

Apple introduced this paradigm shift with iOS and later continued it to OSX. It worked in OSX too with the introduction of multi-touch interactions on the trackpad such that user doesnt need to use a particular region of trackpad to scroll (like conventional PC based trackpads) but can use two fingers to scroll by flicking/moving two fingers together on any region of the trackpad.

If one will notice, even today in phones as well as desktop/laptops or tablets, both type of interaction paradigms are used. There are button based carousels to press left/right button/arrow/graphic on the edges of carousel to scroll and also implicit scrollbar based carousels where user scrolls by using horizontal scroll or trackpad or mouse-wheel. In the first case, no matter which platform it is used on, the behavior is same - clicking left pulls content from left in. Whereas in the second case, given the penetration of touch based devices in our lives, the 2nd paradigm is gaining prominence. This is exactly because of the vision/focus/attention context explained above.

Hope this clarifies the question.

Answer 6

I believe the issue is that you're incorrectly calling this "scrolling", whereas what it really is is "paginating".

This UI has its legacy in the old-school wizard approach where each screen had a "Next" and a "Previous" button. It's just that over time the words have been removed/replaced with arrows and designers have begun showing the next "page" alongside the previous one. The issue is exacerbated with the animations reinforcing that the pages are spatially arranged in a single horizontal row (as opposed to the old way of the whole page being instantly and unceremoniously replaced with the following one, with no sense of spatial arrangement at all).

If anything, pages used to be understood to be arranged in a stack like a notepad. Many apps used to actually use page curls in the corners to represent advancing pages!