Bug 51241 - VIEWING/UI: Page-by-page navigation needs love
Summary: VIEWING/UI: Page-by-page navigation needs love
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-19 14:06 UTC by Adrian Custer
Modified: 2013-11-30 12:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Custer 2012-06-19 14:06:42 UTC
Page-by-page navigation needs attention to ensure a functional experience which exhibits a systematic logic no matter how the page-by-page change is done.

The current experience, on 3.5.4.2 and 3.4.x, does not work effectively. It only works consistently at just the right level of zoom and only works with the Navigation toolbar set to 'Page' and then clicking on the 'next' and 'previous' (which I use at the bottom of the vertical scrollbar).


There are three modes of input (of which I know) for page by page navigation:
  * key presses on the 'PgUp' or 'PgDn' keys,
  * mouse clicks on the Navigation toolbar/widget at base of vertical scrollbar,
  * mouse wheel incremental rolls, some integer number of which will result in 
    a full page move.
I would expect similar or identical behaviour with all three. Note that the latter case has been described in:
  https://bugs.freedesktop.org/show_bug.cgi?id=42794


Note that there are several different zoom cases to consider: 
  * UI zoomed to a fraction of a physical page,
  * UI zoomed to a full page,
  * UI zoomed to more than a full page.
Regardless of the state, the expectation is that the UI will skip ahead so that an integer number of inputs (key presses, mouse clicks, scroll wheel scrolls) will result in the UI being in the identical state to the initial view but one page further in the document. 


Currently, the Navigation toolbar/widget works but only if the entire top of the page is visible including the header (in my case always empty) and more but not quite the whole 'paper' page, I am not sure why. On a constrained desktop, say a laptop, it is helpful to be able to zoom into the page as much as possible (in my case at 100% I can get all the text without the headers and footers, plus the comments). However, if I do that, currently the page down navigation will skip to the next page but will move the page to show a lot of blank at the top of the page. The work around is to zoom out and expose a lot of blank area which wastes screen estate but enables skipping forwards and back without having the relative position of the page change at all.

Currently, the use of the 'PgUp' and 'PgDn' keys moves by some random amount, without hitting the same position on the neighbouring page after an integer number of clicks. Similarly, the scroll wheel (which for me is *not* set to go page by page) does not land on the same position after twenty two clicks.


Thanks for the great work on libreoffice!
  ~Adrian Custer

LibreOffice is the version provided on Debian Wheezy gnu/linux.
The machine is a thinkpad from summer 2004, an R51.
Comment 1 Hb 2013-02-25 08:28:08 UTC
(In reply to comment #0)
> The current experience, ... only works consistently at just the right 
> level of zoom and ...

True. 

> only works with the Navigation toolbar set to 'Page' and then clicking 
> on the 'next' and 'previous' (which I use at the bottom of the vertical 
> scrollbar).

Page wide steps sometimes fail when more than one page is displayed on the screen. This is another bug.

 
> There are three modes of input (of which I know) for page by page navigation:
>   * key presses on the 'PgUp' or 'PgDn' keys,

False, this mode should be for screen by screen navigation as usual.

>   * mouse clicks on the Navigation toolbar/widget at base of vertical
>     scrollbar,

True when the Navigation toolbar is set to "pages".

>   * mouse wheel incremental rolls, some integer number of which will 
>     result in a full page move.

Bug 42794 wants to change this.

> I would expect similar or identical behaviour with all three. 

No, page by page is different to screen by screen.

> Regardless of the state, the expectation is that the UI will skip ahead so
> that an integer number of inputs (key presses, mouse clicks, scroll wheel
> scrolls) will result in the UI being in the identical state to the initial
> view but one page further in the document. 

Yes, but this is another problem. This report mixes at least two issues in one bug. Also the operating system used effects the scrolling. 

I recommend to split it up to the individual problems, search bugzilla and post then new reports.
Comment 2 Joel Madero 2013-02-25 15:39:45 UTC
We don't update the version, ever, for these kinds of things. 

Leave a comment saying it's still an issue but please do not update version as it is used to see when the first request (or bug report) was made. 

Thank you
Comment 3 Jean-Baptiste Faure 2013-11-30 12:56:31 UTC
The status of this bug report is still UNCONFIRMED because it does not describe a clear scenario to reproduce the offending behavior(s). As it stands its description is unusable.

I will close this bug report as INVALID. If you are still convinced that, in the current active branches, there is something that goes wrong in this area, please file another bug report for each individual behavior with a scenario describing step by step how to reproduce it.

Another way, is to discuss this question on the UX-advise mailing-list.

Best regards. JBF