[SDK] Tap to hide toolbar is inconsistent

The current header behaviour is described in the app design guidelines[1] (see "Overlay" section), and it's used also in the image viewer of gallery-app[2].

"The Header is made semi-transparent and the content sits beneath it. Developers can choose for it to be displayed constantly or hidden on timeout or tap."

We have chosen this behaviour since the default one seems not to fit perfectly with our navigation pattern (in a standard list view, the elements provided are somehow in a hierarchy - e.g. relevance, date, etc - so scrolling up the view is a less important action than scrolling down, but pages in a PDF documents has not that strong hierarchy).

I agree that this behaviour is a bit weird, since it's not much used in Ubuntu SDK apps, but, being "authorized" by the UI guidelines, IMHO this is not a real issue.

Anyway we're missing the "semi-transparent" part, and this may require to be fixed.

I've heard some different opinion on the implementation of the header, before choosing the current one, so I'm open to any further discussion on this.

-----
[1]: https://design.ubuntu.com/apps/building-blocks/header#display-options
[2]: line 166, http://bazaar.launchpad.net/~phablet-team/gallery-app/trunk/view/head:/rc/qml/MediaViewer/MediaViewer.qml

> The current header behaviour is described in the app design
> guidelines[1] (see "Overlay" section), and it's used also in the image
> viewer of gallery-app[2].

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.

> (in a standard list view, the
> elements provided are somehow in a hierarchy - e.g. relevance, date, etc
> - so scrolling up the view is a less important action than scrolling
> down, but pages in a PDF documents has not that strong hierarchy).

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.

> 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'm inclined to agree with Stefano. Viewing photos in gallery is often improved by using all available pixels to display the image. Browsing web pages frequently requires the use of toolbar, buttons & navigation.

The pdf / book reading experience is often one of total immersion for long periods. So I'd like the chrome to be out of the way as much as possible as much of the time, however I'm scrolling. The toolbar appearing and disappearing as I scroll up and down in a book would be a distraction in my opinion.

The linked document is not public.

I've (re-)requested the authorization to access the document.
Please confirm the request, or provide a public link for the UX resolution.

I've read the UX specifications.
The reference to the page '24' is wrong with the current revision of the document, since the "Header behaviour" section starts from page 27.

An header that is fixed and opaque can not be "transient", i.e. hidden on tap or timeout.

Some solution:
1) Use the default, "scrolling" behaviour
2) Keep the header fixed and opaque (that means that it will be always visible and never hidden)
3) Use a fixed, but semitransparent, header (in this case it can be hidden on tap)

I don't think 3) will be used, since it would be much harder to keep consistent when the app runs in "tablet/desktop mode" (width > units.gu(80)).

We will probably implement 1), with some exception when the app runs in "desktop mode" in some particular contexts (e.g. libreoffice viewer in presentation mode).
However having a no-fixed header may require some change in the current header configurations/states, therefore I'm marking this bug as 'confirmed', but not 'triaged'.

Fix committed into lp:ubuntu-docviewer-app at revision 210, scheduled for release in ubuntu-docviewer-app, milestone Unknown