Mouse-wheel scroll interaction for navigating through pages

Question

The application is a windows8 desktop app (runs in fullscreen resolution, always). The app is a comic viewer. Each page is a scanned image, the height is variable, but it almost always overflows the viewport (or at-least that's the assumption)

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

This is where I'd like a second opinion -

to avoid having a slider or pagination UI I'm using or thinking about using a convention like place your pointer on the next or previous button or the whole button area and wheel-up or wheel-down to cycle through pages. Remember the image overflows the viewport, so the user might be wheeling-up or down to scroll the height of the image. so while wheeling up or down, if the mouse pointer is on the image, the app will scroll the height of the image and if the mouse pointer is on the left/right area, then and only then it will cycle through the pages

Do you recommend it? If yes - how can it be made better. If no, why?

Answer 1

I like the idea to keep the user's finger on the wheel for two different things to scroll. I was wondering whether I would need to move the mouse from one side of the comic to the other to go into the other direction - then I wondered about whether "wheel-forward" will do the same when on the previous and on the next page buttons?

Can "wheel-forward" go to the next page, regardless whether the mouse is over the next or previous page button? "wheel-backward" would go to the previous page in both cases.

This leads me to think about whether you need next page and previous page buttons? Two buttons times two wheel directions give us these issues: 4 ways to interact, but only two directions to go...

Answer 2

A very similar behaviour happens on other systems, for instance, in Linux (most windows managers and aps), the mouse wheel will scroll whatever the pointer is on top of, so for a Linux user, that would something expected.

In Windows, that is not what usually happen, so the user expects to move the active area, or the are/application/document he has activated by a click, which takes us to your question, if you can make clear which area is active, the user will recognize the patter quickly and if it's not familiar with it, most probably will adapt soon.

Also, you should provide some explanation of the behaviour somewhere, so the user can look for it; but no hidden in the help section of the app, but in a place like a status bar, a temporary popup, etc.

Also, according to the wireframe that you are showing us, the inteface will have two more arrows for the chapters, you have to extend the page behaviour to the chapter controls, otherwise, the interface is not coherent with itself. You can add limitations, like you can scroll to change the chapter if you are not at the beginning or end of the actual chapter and show a message to the user if he tries. This last mechanic can also be tweaked by allowing to click the arrows to change regardless of the page on screen.

In any case, it's important that you provide information to the user and keep the interface and controls constant, otherwise, they will seem random and unexpected.