User-interface (navigation and search placement)

[b16r05]

The top panel has Kiwix version #, Home, Configure and About links, and to the right, a vast blank space exists which could house Search AND Navigation buttons found elsewhere.

Consider placing search (Search box and Scope along with Random Article button) on the top right to free up screen real estate. Also, consider placing bottom navigation panel buttons (home, left, right and up) in the middle of the top panel.

Further, Navigation could be the first [left] item, followed by Search in the center and lastly, kiwik info+config on the right as that is usually changed/checked every now and then. Being able to move the three sets of items [left, center, right] by users would be nice.

Top Panel example: HOME LEFT RIGHT UP.................................. SEARCH RANDOM..................................KIWIX HOME CONFIG ABOUT

[Jaifroid]

I've only just seen this @b16r05 . I'd be interested in your view on the alternative arrangement we have in Kiwix JS Windows, which looks like this:

On very narrow displays, the Search field become extremely small (but is still functional, because it opens to a wider field when typing in it):

This suggests to me that it's unlikely we could fit more buttons on this row without using the hamburger solution that Kiwix JS uses for narrow displays. The hamburger makes navigation very cumbersome, as it adds a significant number of extra taps just to change a setting.

[b16r05]

It has been a while and I am embarrassed to say that I have forgotten how to open a sample zim page in kiwix-Firefox addon :-( However, I managed to review the pictures of kiwix 2.0 addon from the addons page (https://addons.mozilla.org/en-US/firefox/addon/kiwix-offline/#&gid=1&pid=3) and it has all come back to me :-)

Yes, what you have from Kiwix Windows interface looks good. However, I don't see navigation buttons, I think this is part of the application menu itself. What takes up one line space in Kiwix Windows takes up three line spaces in kiwix 2.0 (addon) minus the navigation. You could consider using a similar menu with BACK, FRONT and UP navigation buttons placed between the HOME (kiwix logo) and SEARCH box...

[Jaifroid]

Oh, sorry, navigation is on the bottom (that shot only focused on the top). Even so, the Kiwix icon is "Home", which is back to the opening page of the ZIM, but the forward and back buttons are on the bottom toolbar, as it's easier to reach it. Screenshot below.

[b16r05]

Finally, got the Kiwix extension running in Firefox. Yes, I know about the navigation at the bottom. My opinion is that along with changes on top (to make the bar concise), the navigation could work better on top as well -- everything in one place. However, I tested the current setup and it is good as well. I just wanted to share my suggestion -- that's all!

[mossroy]

Thanks for the suggestions. I agree that the current layout is not optimal. There had been some discussions about this in #293, and kiwix-js-windows already implements a better layout, IMHO. But we need to keep in mind that the layout needs to adapt both to very small screens (on smartphones) and very large screens (on computers) I'd be happy to backport in kiwix-js the layout of kiwix-js-windows, through a PR (including the zoom feature, but maybe not the Table of Contents for now, which would need more discussions)

[b16r05]

I agree... having a sort of unified (similar) interface (an identity) would be good.

I have been using Firefox add-on called Stylus for a while to enhance Wikipedia. I was using Wikipedia Dark Material Design style, but I felt wanting after seeing WikiWand, however, I will never touch it with a 10 foot pole : )

Wikipedia Clean Dark style is the closest in terms of design to Wikiwand... looks stunningly, beautiful. There are CSS files and licenses are under Creative Commons - Public Domain.

With that said, I have not used Kiwix in a while... desktop version, Firefox addon or on Android.

References

1. WikiWand: https://www.wikiwand.com/en/Fish
2. Wikipedia Clean Dark: https://userstyles.org/styles/154881/wikipedia-clean-dark
3. Wikipedia Dark Material Design: https://userstyles.org/styles/122072/wikipedia-dark-material-design

To do list for Wikipedia Clean Dark:

• Move Contents to the left
• Move Languages to the right
• Add ability to toggle (static/dynamic) Content

[kazerthekeen]

A group of us at a University are looking at moving the search and shuffle button into the top bar which will also collapse into the hamburger bar on smaller screens. We believe the static search bar is unnecessary and takes up space that could be used for other content. The result should look something like this if we were to get approved for such a change (created from fiddling with HTML for a couple minutes): This doesn’t solve the larger issue of uniform styling, as mentioned in a couple other issues, but I believe that is a different issue. This should make it a bit more user friendly for desktop and hopefully mobile users as well.

[Jaifroid]

@kazerthekeen While your suggested layout would make more space for the article content, I'm not convinced it would be good UX on mobile, because Search is the most used interface and collapsing it would add extra tapping and make the experience more cumbersome. What we are looking to port to Kiwix JS is the interface used in Kiwix JS Windows, which looks like this, and which works on mobile without collapsing the Search bar:

The only thing we're currently missing to make this change is time to work on it! You can test the Kiwix JS Windows interface by visiting the online implementation of it here. If you want to help implement that interface here (NB we are using Bootstrap 4 here, whereas Kiwix JS Windows still uses Bootstrap 3, so quite a lot of code would need to change), then a PR would be welcome.

We could take a look at an interim PR that moves the search bar into the top toolbar, but without collapsing Search on mobile, but I think that implies replacing the text with icons. Whatever solution we have, it should be a good experience on both Desktop and Mobile.

[kelson42]

I really share the opinion that the top bar should be collabsable on small screens. We have done this on kiwix serve http://library.kiwix.org/wikipedia_fa_medicine_nopic_2019-10/A/%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%AF%DB%8C%D8%A7:%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%B1%D9%88%DA%98%D9%87_%D9%BE%D8%B2%D8%B4%DA%A9%DB%8C/%DA%A9%D8%AA%D8%A7%D8%A8%DA%86%D9%87_%D8%A2%D8%B2%D8%A7%D8%AF_%D9%BE%D8%B2%D8%B4%DA%A9%DB%8C. What dou you think about it?

[Jaifroid]

@kelson42 Our top bar already collapses on small screens. If I've understood correctly, the issue is whether the Search bar should also collapse, and that doesn't seem to happen on the implementation you linked. We aim to have some sort of collapse also for a more compact interface (like Kiwix JS Windows) for ultra-small screens, but IMHO the search bar should at all times be available without further clicks (which the Kiwix Serve implementation seems to achieve).

[kazerthekeen]

Sorry for the delay, I believe porting the interface should be manageable. It should be a fun project for us and we are looking forward to it.

[Jaifroid]

@kazerthekeen That sounds good! Might I suggest you do it in stages, with a few smaller PRs rather than one large PR? This way we're more likely to catch issues like incompatibility with very small screens, etc., before they become blockers.

It might be worth planning the stages. Something like this comes to mind:

• PR 1: Change text to icons in top bar and move random icon
• PR 2: Move search bar to top menu
• PR3: Re-engineer the collapsing, with proposals for a hamburger menu and, if necessary, a kebab menu
• PR4: Implement option to hide bars

But please also read carefully the discussion in #523 [Rework User Interface like Kiwix JS Windows] because there are some ideas there about colours, mutating icons, the repeated Home button, the option to hide top and bottom bars after x seconds of inactivity, and display them again if the user scrolls or clicks/taps somewhere in the text.

I personally believe the bottom bar and its functionality (forward, backwards, home, jump to top of page, possibly ToC) should be kept because of the need to support one-handed use of the app (and bottom bars are much easier to access one-handed than top bars on large phones), but perhaps the option could be provided to hide it if the user has no use for it, in which case the functionality should be in the hamburger menu.