Rework the bottom bar

[mossroy]

This bottom bar has a few problems :

• It can hide some content at the end of an article. For example, we had to put a few carriage returns in the About section, just to allow clicking on the links at the bottom
• It needed some extra work in the automated UI tests for the same reason : sometimes you can not click on a link if it's hidden behind the bottom bar
• It should be hidden when the user is in the Configuration or About section (see Bottom bar should be not displayed in settings kiwix-js-pwa#43)
• The user can not click on the bottom right of the screen (for example on the scroll bar) : it clicks on the "go to top" button instead

[mossroy]

I'm starting to wonder if the solution would not be to completely remove this bottom bar.
There's no such thing in the Android application. They have found other solutions to provide the same features.
@kelson42 says that the dev version now has a bottom bar that disappears after a few seconds. We might try to align with the same ergonomic ideas (as long as they are compatible with a desktop version).
Is there a doc/wiki explaining the ergonomic strategy of this app?

[Jaifroid]

The scrolling viewport (iframe) gets sized to fill the entire screen space before the bottom bar is added in as an absolutely positioned fixed overlay, which inevitably hides some content beneath the bar. I've experimented with different ways of calculating the viewport size (but I was doing this early on, before I had a proper understanding of the layout) and didn't come up with a satisfactory solution other than adding padding to the HTML. Even if we reduce the viewport size, then the transparency effect of the bottom bar becomes useless, and it might as well just be a solid block (I think I encountered this when experimenting and it was visually less satisfying, in part because without the transparency there are no visual clues that there is further content to read).

Note that ergonomically, bottom bars are much easier to reach on mobile devices than top bars, as they can be controlled by the thumb without having to stretch, especially with large screen sizes which otherwise have to be operated with two hands. IMHO therefore the bottom bar should be the last thing to go and hiding it should be optional unless another completely satisfactory way of navigating one-handed can be found...

Having said that, hiding the bottom bar in the Config and About screens is a simple document.getElementById('footer').style.display = "none";, and can be added to the Config button and About button onclick routines. A very easy PR (implemented in kiwix/kiwix-js-pwa#43).

[practik]

I'm starting to wonder if the solution would not be to completely remove this bottom bar.

Having just installed Kiwix for Firefox I tend to agree. Instead of using the bottom bar's home, back and forward buttons, I can just click on the Home tab at the top of the browser window and use the browser's back and forward buttons or keyboard shortcuts. So the only thing in the bottom bar whose functionality is not duplicated elsewhere is the up arrow, and on a desktop browser, at least, that one's easy to live without.

(Kiwix 2.2.0 on Firefox 58.0.2 on macOS 10.12)

[Jaifroid]

@practik You're using Kiwix JS in a browser context, where functionality for forward and back navigation is indeed duplicated. However, Kiwix JS needs to work also in an app context, and there much of the duplication is stripped away. Mobile device back buttons can be programmed to navigate backwards, but more often than not they just exit the app by default, so a back button needs to be provided at least in app context, or some other way of going back in the history, and ideally without having to use two hands.

A swipe-from-the-left functionality could replace a back button, but the action tends to be less discoverable than a simple button.

[practik]

Ah, sorry, I thought Kiwix JS was only intended to be used as a browser extension. Thanks for the explanation.

[mossroy]

On some mobile applications, some options of this kind are put in a top bar. This top bar disappears when the user scrolls down, and re-appears when the user scrolls up.
I saw that on Android, with Tiny Tiny RSS, Amaze or VLC.

I find it convenient, as it does not reserve some space for the buttons, and it seems easy to discover.

But it might be not easy to implement for us if we want to have a smooth transition between a visible and a hidden bar.

[garuffalo]

I am no coder, just a user, but is there not some way to offer, in settings, the option to show or hide the bottom toolbar, in the same way that other applications allow to show or hide a status bar? The bottom toolbar annoys me for the same reasons posted above, since I am using it on a laptop web browser. I noticed that I could not click on the "next" button/arrow to go to the next page of TED videos, for example. Had to use the one on top.

[Jaifroid]

@garuffalo It's not hard to implement hiding of the bottom or top bars. The only difficulty is agreeing on a standard approach and how/when to make those bars re-appear when they're needed. One approach would be to fade out top and bottom bars (or a choice of either/both) after a two-second timeout (for example), and show them again as soon as the user starts to scroll. We do need to have back/forward buttons available on screen through some mechanism because apps don't have the respective browser buttons to do this. And IMHO they should be in the bottom bar to enable one-handed use in mobile contexts.

[Jaifroid]

I've added a very simple PR to hide the navigationButtons in the footer when the user goes to Config or About.

I think adding an option "Hide navigation buttons permanently" in Config needs a bit more thought, however, which is why I think it can't be done in this PR. I'm inclining towards making the option work on a timer after scroll stop, so that the buttons would be available for, say, two seconds after scroll. We should also have an option to hide the top bar, for users who prefer to use their phones one-handed. For the top bar, it can be made to re-appear temporarily on pressing the up arrow in the bottom bar.

[mossroy]

I like the idea of hiding the bars (top and/or bottom), and making them re-appear when the user scrolls.
I see many mobile apps that work like that (see my previous comment #337 (comment)), and find it's a good compromise.

[Jaifroid]

There are two approaches I've seen at work in different apps:

1. Like in Kiwix Android, the bars can disappear when scrolling down, and can be made to re-appear when scrolling up slightly.
2. In other apps, you sometimes see the bars appear when scrolling down or up, and disappear after a defined interval (1-2 seconds) on scroll stop.

Personally I think I prefer 1. It is what Kiwix Android uses, and also what I implemented in Kiwix JS PWA / UWP. Also, there is a slight coding disadvantage to 2: there is no actual "scrollStop" event in JS. It can be simulated, but the simulation involves a timeout testing the vertical displacement at regular intervals during a scroll event. It's not a big performance hog, but it's a bit more complex than simply showing toolbars on scroll up, and hiding them on scroll down.

[kelson42]

I am no coder, just a user, but is there not some way to offer, in settings, the option to show or hide the bottom toolbar, in the same way that other applications allow to show or hide a status bar?

Complementary to other comments, this seems a pretty legitim request for user on none mobile devices. Default value could be set based on screen resolution. Maybe this could be implemented first (because easy to do) and other problems reported in this ticket later.

[Jaifroid]

Agreed. I think the only question is if we rework this as part of the larger UI change in #523, or whether we add an option to hide the bottom bar in the current design. I'd favour having the bottom bar on by default, because I think for a new user opening the app for the first time it is reassuring to see controls. After the new user has used the app for a while, they may wish to hide the bottom bar, and can choose to do so in Configuration.

[mossroy]

I could be implemented apart from #523 if we wish.
I agree with you, and would also prefer to see it implemented the same as on Kiwix Android.
Having an option to completely hide the bottom bar would be a plus, but could even be a separate PR if we wish

[Jaifroid]

I think all the issues with the bottom bar are now (finally) addressed by #1142. Good to be able to close this issue open since 2018...