[webapp-container] New top header takes too much space

The real issue is with most webapps passing the --enable-back-forward and/or --enable-addressbar command line switches to the container. Most webapps probably don’t need that any longer, but for backward compatibility I kept the mapping of those switches to showing the chrome.

Note that the new chrome is not intended to behave like the old one: either it’s shown, and then it autohide upon scrolling, or it’s hidden, and it nevers appears (the latter is the default, and probably what most webapps want).

There can’t be a swipe to reveal/hide gesture for the new chrome, as it would conflict with interaction with the indicators. The new chrome has the same behaviour as the new header component from the SDK, its visibility is tied to the contents of the page, not triggered by explicit manual interaction.

Also note that with the new container, even when there’s no chrome at all, there will always be a thin progress bar shown at the top while loading, which gives some feedback to the user that something is happening (IIRC the --enable-addressbar switch was initially introduced to work around the lack of an external progress indicator, since the progress bar used to be embedded inside the address bar).

So I think the fix is to assess for each webapp whether they really need the legacy command line switches, and remove them accordingly.

Very annoying issue indeed, especially with google maps

I second Olivier's comments.

Also, HTML 5 apps should have their own navigation/action bar

Le 07/08/2014 02:29, Florian Boucault a écrit :
> Very annoying issue indeed, especially with google maps
Facebook, Twitter and Gmail have now been updated to remove all chrome,
including the top-header. Google Maps is next.

David

Awesome, thanks David!

Facebook and G+ are nearly impossible to navigate without a back button. We should consider putting those back for those apps.
Also consider adding back the auto hide of the toolbar so it would both autohide and hide when scrolling

+1
The absence of the back button forces the user to scroll up to the top, go
back to the news feed top, and scroll down to the last read item.
Gmail, Twitter are ok without header.

On Fri, Aug 15, 2014 at 6:53 PM, Bill Filler <email address hidden>
wrote:

> Facebook and G+ are nearly impossible to navigate without a back button.
> We should consider putting those back for those apps.
> Also consider adding back the auto hide of the toolbar so it would both
> autohide and hide when scrolling
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352338
>
> Title:
> [webapp-container] New top header takes too much space
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-ux/+bug/1352338/+subscriptions
>

As discussed on IRc, one thing could be to have a delayed auto-hide header when reaching the top for these, I guess that the header behavior can be tweaked for that. It would possibly maximize the amount of real estate when hidden while still being avail for back/fw browsing,

Before implementing anything, please validate the proposed solution with the design team (Giorgio).

Hi,

@Bill, David thank you for pointing these examples out. I agree HTML 5 apps
may occasionally need back button functionality

I also agree with Alex that the optional header could be either fixed or
hide-out on scroll. That's what we specified.
https://docs.google.com/a/canonical.com/presentation/d/1IpCWtWuGPES5llwmoscawhn2IG4fxOggMO8F_RM_zms/edit#slide=id.g180624b4a_014

It should behave similarly as the current Browser top bar.
https://docs.google.com/a/canonical.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit#slide=id.g2c4a617df_1_0

On Mon, Aug 18, 2014 at 9:38 AM, Olivier Tilloy <
<email address hidden>> wrote:

> Before implementing anything, please validate the proposed solution with
> the design team (Giorgio).
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1352338
>
> Title:
> [webapp-container] New top header takes too much space
>
> Status in Ubuntu UX bugs:
> Won't Fix
> Status in Web Browser App:
> Triaged
>
> Bug description:
> The new top-header takes too much space by default. It doesn't hide
> until a long page is scrolled.
>
> Suggestion: auto-hiding, like the previous bottom bar, would probably
> make that less of an issue.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-ux/+bug/1352338/+subscriptions
>

Should update the implementation based on Giorgio's latest remarks. Marking the bug for fixing at the next iteration

+1 I will have a patch to auto-hide again.

On Wed, Nov 5, 2014 at 3:36 PM, Giorgio Venturi <
<email address hidden>> wrote:

> ** Description changed:
>
> The new top-header takes too much space by default. It doesn't hide
> until a long page is scrolled.
>
> Suggestion: auto-hiding, like the previous bottom bar, would probably
> make that less of an issue.
> +
> + ** UX Solution **
> + HTML 5 apps
> + may occasionally need back button functionality
> +
> + I also agree with Alex that the optional header could be either fixed or
> + hide-out on scroll. That's what we specified.
> +
> https://docs.google.com/a/canonical.com/presentation/d/1IpCWtWuGPES5llwmoscawhn2IG4fxOggMO8F_RM_zms/edit#slide=id.g180624b4a_014
> +
> + It should behave similarly as the current Browser top bar.
> +
> https://docs.google.com/a/canonical.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit#slide=id.g2c4a617df_1_0
>
> ** Changed in: ubuntu-ux
> Status: Won't Fix => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352338
>
> Title:
> [webapp-container] New top header takes too much space
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-ux/+bug/1352338/+subscriptions
>