UI makeover

[rgaudin]

This is a meta-ticket archiving some notes related to an effort to redo/improve the nautilus UI.

Links

1. auteurs en herbe: PDF files
2. livres interactifs: ePub files
3. Expériences scientifiques (Bayard): Videos
4. Mes p'tites questions (Bayard): PDF+ePub combo
5. J'aime lire + Planète J'aime lire (Bayard): PDF+audio combo
6. Audiolivres de littérature: audio files including multipart audio

@siemsie will work on mocking a new UI up

Notes

• Internal search feature will be removed
• we'll have an HTML ZIM entry for each entry (fixes No URL to access directly a content #54 with clear URL, suggestion and full text search)
  • with the entry's details
  • download link
  • preview of content if possible (PDF, ePUB, video, audio, Images)
• home page will include (subject to first mockup feedback)
  • clickable title linking to details page
  • clickable download link
  • clickable open/play link
• Open/play link will enable autoplay (fixes Videos should be played in autoplay #24)
• autoplay is not a ZIM option anymore
• random is not a ZIM option anymore
• UI will allow shuffling entries in random order
• Logo won't be clickable anymore (dont repeat reader feature)
• Video covers will be displayed on details page. On home page TBD
• new ZIM option: folder-tree (fixes Allow for file arborescence #43)
  • UI displays files inside folders
  • disables the shuffle option for users

Screenshots (current)

[kelson42]

What is the status of this issue? I belive we teally need one at this stage.

I was assuming this was only UI revamping but I see important features appearing and disappearing.

I also see no mockup I can have a look and on which building an opinion.

[kelson42]

Internal search feature will be removed

I'm not sure to understand what it means, but if I get ot right I'm 100% against this.

In general I'm not confortable with non obvious AND non-argumented (written) moves.

[kelson42]

Logo won't be clickable anymore (dont repeat reader feature)

Which logo is meant? If this is the logo on the top left, then would be interest to understand the rationals behind this decision.

[rgaudin]

We've had this discussion several times and you keep coming back to it. It really sounds like you don't want it to happen and you're not satisfied with how it's being done. Maybe we should just close the issue and move on.

---

The process has already been explained. Has a U/I makeover, this starts with mockups that are discussed live (in calls you did not participate to) and changes/features debated with the designer, the user-representative and the developer. The latest iteration awaits @Popolechien's approval so there is no Accepted one to share on Github.

Should the mockup be posted on Github for others to comment on? That defeats the purpose of doing it live: otherwise it's re-doing the same discussions/arguments with multiple stakeholders.

Should it be entirely on Github and not live? All arguments would then be written but we've seen in the past that this makes decisions very difficult.

Should there be a post-discussion document that shows the mockups annotated with all decisions? Would be great!

Status: there is a mockup that I think is ready but @Popolechien was not present in last meeting and should give feedback on. Development has no started yet (unrelated to previous point)

[kelson42]

@rgaudin Whatever what is done: tracability, accountability, rationality and transparency is a wish. I understand that this is difficult to fullfill all of this all the time, but product or even UI design should not work differently. Even if decisin making is challenging, giving-up on all these principle is not the solution.

Fondamental points:

• product design != UI design, so if there is a discussion to have around a feature (or many features) GitHub issues are here for that
• UI design is not magic and does not escape any rationality
• there are tools to make mockups and discuss them. I see no reason to not post the link here
• whatever the topic, we need to have updates and vision about next steps

[rgaudin]

Note

This is all based on mockups (Desktop version).
The black bar on top of the mockup pages represents Kiwix reader features.

• Desktop: https://assets.adobe.com/id/urn:aaid:sc:EU:ab6351e1-cd6d-4779-b9c2-7666500840f6?view=published
• Mobile: https://assets.adobe.com/id/urn:aaid:sc:EU:04f30364-652e-4d11-b093-bc2652fc7f5c?view=published
• Tablet: https://assets.adobe.com/id/urn:aaid:sc:EU:99d66c1a-e2c5-4d98-9771-41fee116d78a?view=published

Warning

The mockups are hosted on Adobe Review

It means those can be updated
@siemsie please freeze those ones as v3
Only comment on Github and not via the Adobe's review feature

---

Previous UI was a Single Page App built using a small HTML shell and a piece of JS that reads the list of entries from a JSON file (into an in-browser DB) and displays it as a simple list (Icon/Title/Description/Authors). Clicking on the icon linked either to the file URL or a popup for a couple of mimetypes: audio and video.

The new approach is closer to a file browser albeit it is based on a two-step scenario (browsing and details page). It does support direct downloads though.

---

---

---

Cards vs Lists (browser)

• Better readability in a small card rather than wide block (like columns in newspapers)
• More flexible on various screen sizes
• Information is more accessible on small cards
• Easier to identify a card vs just text in a list of lines

Files tree (browser)

• Requested in Allow for file arborescence #43
• Offloads nautilus from UI complexity that some data bring: Creator takes care of organizing its content.
• Allows grouping files by whatever makes sense from the Creator's POV
• Not mandatory: can still be a bunch of files.
• Easier to navigate
• Similar to file systems

Individual Entry Page

Moving away from SPA means that:

• we can use the suggestion feature (previously missing)
• we can use the random feature (previously missing)
• we can use the full text search feature (previsously only a basic title/description search was provided)
• we can have permalinks to content that can be used as bookmarks or shared
• we wont suffer from kiwix-serve bug which does not reflect JS updated location
• Driven by No URL to access directly a content #54
• Supports Not clear solution to download/open in third part app a content (PDF, AVI, …) #69

The individual page displays the entry's metadata:

• File type (as an Icon)
• Title (might have been truncated in browser)
• Description (might have been truncated in browser)
• Authors (might have been truncated in browser)
• Direct open link
• Download link
• Preview for some file types

Direct open link

• Via Direct open link icon
• Opens the file URL in the browser
• Exact behavior depends on the file type and the browser's capabilities. PDFs, Images, Most videos and audios are expected to open directly and be fully usable.
• When not supported, would fallback (browser handles this) to a download.

Download link

• Via Download link icon
• Downloads the file directly (even if browser supports opening it)

Preview

Some file types can be previewed:

• Image is displayed
• Video can be played direcly
• Audio can be played directly
• PDF can be looked at via PDF.js
• EPub can be looked at via Epub.js

Important

It is a preview. It may not be comfortable for all use cases

• Preview size is fixed
• Preview canvas should be small enough that this page is not scrollable
• We want to avoid double-scroll that would happen on scrollable content (PDF, epub)
• Preview reader would provide ability to go fullscreen

Video and Audio autoplay

• Video and Audio are not autoplayed by the preview
• Arriving in the indiv page does not convey a strong intent to play the video:
  • can be from suggestion/random or search (where it's not mentioned that it's a video/audio)
  • browser does indicate filetype but no cover has been shown
• clicking on the preview/player is not considered to be an issue
• autoplay is very annoying if unexpected (or even if expected but not wanted)
• user can still use download button from browser for quick access
• user can use direct open link (in this indiv page) which generally has autoplay

Lack of preview

Other file types have no preview. Instead, a large box with the type's icon and filename is shown.
That whole box is clickable and serves as a direct-open link.

Entries are single-file

Consequence of the two previous point: with folder/subfolders it's easy to group files together should there be any need.
This removes the need (and burden) of displaying multiple entries together.

In previous UI we had for instance the case of an audio book that was split into chapters and we were displaying all on the same popup.

Breadcrumbs (browser, indiv-page)

Consequence of the file arborescence, we display where we are in the tree and allow jumping to any level easily (each level is clickable)

Folders are ZIM entries with URLs that can be shared as well.

No link on header logo (browser, indiv-page)

Header logo was clickable and linked to the home page (which is an SPA 🙄).
We removed the link as to not duplicate a Kiwix reader feature (all readers have a Home button)

No in-ZIM search anymore (browser)

Because it was an SPA and there could be an unlimited number of entries, previous UI had a search box which filtered (not live) the entries matching the title or description.

It has been removed as this feature (and sibling ones) are now offered by Kiwix reader natively. Search-related URLs will now be decent-looking as well.

File-type filters (browser)

Pursuing simplicity, ease of use and acknowledging that main use case is browsing (ie. discovering content), we have limited interactions to a File type filtering system. The is no sorting for instance.

It is understood that Kiwix search is good-enough to find a known entry and that Suggestion and Random are complementary features.

Navigating through the hierarchy is thus done by looking at the cards.

Excluding some entries by file type seems to provide a good ratio of usefulness over reduction.

The filters are on-by-default: all the file types are ticked. One can reduce the list of displayed cards by unticking some unwanted types.

A Select All button allows for quick back-to-all action.

The filtering is applied to what's on the screen:

• when entering a folder, the filter is reset
• it filters only what's visible: it doesn't tell me what's deep inside a folder

File size in card (browser)

• Allows making choices when looking for content.
• Basic, expected info should not be hidden from user

File download link in card (browser)

• When you know you want to download, you can without entering the indiv-page and going back
• Light blue (#e9f4fa) colored in mockup indicates the clickable-area (not visible)

Top part of card leads to individual page (browser)

• Fixes Only the logo clicking allows to open a content #70

Previous UI gave access to file/popup only via click on the Icon.
Access to indiv page is done by clicking on the card-wide top area of the card (from top to end of title)

Light Pink (#f8e7f1) colored in mockup indicates the clickable-area (not visible)

Moved “About content” page link

• Via info icon
• Was next to header logo (just right of it) and is now next to breadcrumbs (just left of it)

Removed pagination option

Pagination is rendered useless by the arborescence feature. Creator can now organize files (and its number per level) as sees fit.

Removed random option

Random was default and we had a no-random option that allowed one to keep the files in order. We used it on smaller sets.

With the arborescence feature empowering Creator, there is no point in having stuff random.

Removed show-descriptions option

This was only present to balance the lack of UI flexibility (looked weirder without)

Replaced Footer logo (secondary-logo) with Footer text

Barely used and brought confusion more than anything else.
Instead, a footer-text would be allowed. Sample use: Sponsored by X

Removed main-color option and computation

Header color was either settable by user, or automatically computed using the solarized version of the logo's main color.
Header color is now static.
We chose #FFFFFF in order to acomodate people with white-background logo which have not been adapted for transparency.

Removed secondary-color option and computation

Footer color was either settable or computed (solarized main color from the secondary logo).
Footer is now static without constraint: there's no logo in the footer anymore.

You'll notice footer is not in the mockups. It's missing but it expected to be a simple indication of the end of the content. Maybe a #e4e6e5 line with the new footer-text inside…