Comment 3 for bug 1453403

> The guidelines don't specify when to use each. But, I assume tapping is
> appropriate when there is no scrollable content. The gallery displays an
> image which is not something that is scrolled through as you view the
> image.

I had to check the logs of the docviewer meetings, since I was missing some information.
The header behaviour has been discussed with the Ubuntu UX Team, and its current design has been approved by them.

Also, I was wrong on the header transparency, since it isn't related to the "tap-to-toggle-visibility" pattern.
At the moment the design guidelines fails a bit in describing the overlay header, but they will be updated in future.

About gallery-app, the image viewer actually can be scrolled (horizontally) to switch to prev/next image, and the currently displayed image can be zoomed (which is the reason of that header behaviour).

> The hierarchy you mention sounds to me like linearity. You scroll to view
> something in a linear way. Reading a book is a linear process, the
> hierarchy is page numbers/content. In fact, I would argue that scrolling
> through a PDF is exactly the same as scrolling through an article in the
> web browser, which slides the header out when you scroll down the page,
> therefore I would use this behaviour to be consistent with the rest of the
> platform.

Not at all. Probably I didn't explain well what I meant, but, I feel it would be better to provide an example, comparing the behaviour with the Contacts app:
If I want to search a contact which name starts with 'G', I may want the header to disappear completely since I want to see the highest number of contacts possible in the page.
If I need to scroll up, that's because I need to move the view by a little "step", since I may have missed the first 'G' contact with the first scrolling. This last scroll is somehow less disruptive than the first one, and does not require the full height of the page.

With PDFs, things are a little different.
A page can be zoomed, and content may be arranged in columns (this is very common with magazines).
In this case the page numbers does not provide an univocal navigation pattern (since it may be broken by columns), and scrolling up or down is rather the same action. In both cases an user may want to use the full height of the screen.
Since we have to support a wide range of different PDF layouts, I feel this is the best behaviour for this purpose.

As for web browser, there are two difference IMHO:
1) Web pages should be (always, as Google would like to force) optimized for mobile devices. That implies that a web page content should be shown on one column that fills the width of the screen (without any possibility to zoom).
2) Web pages provides a lot of links, that conflict with a "tap-to-toggle" behaviour.

Since the current header behaviour has been approved by the design team, I don't believe it's not consistent.
As I said, it's rather weird/not common, and I feel this issue is about the difficulty in discovering the behaviour of the header, rather than its implementation.

I'd suggest to add an overlay on the first launch of the app, as camera-app does for its photo roll, when a new picture is added.
I'll discuss about this in the next docviewer meeting, next Thursday, asking for a solution to the design team.