audiobooks: better UI design

[llemeurfr]

We should make the design better looking.

The best design I've seen recently is on the Jellybooks web app (a pure JS implementation), with a responsive design, a larger cover, clean SVG buttons and progress bar.

Another implementation by De Marque

Should we ask a frontend developer some help?

Original issue: #956

Related issues:
#955
#955
#942

Follow-up to PR #938

[danielweck]

Not that the minimum width of Thorium's window is quite wide, in fact is it impossible to reach portrait aspect ratio when resizing the window (i.e. no "mobile" style responsive design).

EDIT: well, I personally use an external display in vertical orientation, so strictly-speaking Thorium's window can in fact reach a portrait aspect ratio, but I meant that in practice, this is an unlikely occurrence :)

[danielweck]

To illustrate my comment above, here is Thorium's mininum window dimensions (I am not able to resize any smaller):

[danielweck]

...and, here is Thorium on my external vertical display :)

[danielweck]

...so, I am not convinced (yet) about the "responsive" argument in the case of Thorium (for the "mobile" / portrait layout), unless we drastically change how window dimensions are currently restricted / dictated by the publication info dialog, right-side slide-out menus, etc.

[danielweck]

This is Thorium in wide landscape mode ("fullscreen" on my HD laptop display):

In this case, we can definitely afford to increase the dimensions of the cover image, and placing the audio controls on the right side of the cover image (instead of below) may indeed be a improvement.

[danielweck]

As for the audio controls (buttons): I have my personal opinion about the "look and feel", but regardless of our convergence / divergence about how "nice" the UI is, we can definitely discuss how to improve the implementation, which right now is located in the navigator component, which does not benefit from Thorium's localized strings (accessibility labels, even if not displayed as text in the UI), and the configurable keyboard shortcuts to activate commands related to audiobook playback.

Therefore, in a future development iteration we will need to address this significant shortcoming by designing a UI paradigm (in Thorium) that overlaps with the central area where the navigator component normally renders its own content (but remember: actual audio playback is still handled by the navigator, therefore requiring the usual sandboxed webview runtime with hidden HTML5 audio element, event listeners, etc.).

[danielweck]

There was already an issue logged for this, so I am deleting is as duplicate:
#956

[danielweck]

Another thought: the r2-testapp-js "test app" will probably never implement its own audio controls UI (unnecessary development costs, just to test the navigator component). Therefore, r2-navigator-js will continue to provide its UI as a "sensible default", but will allow host apps (like Thorium) to deactivate the default UI. In concrete terms, the host app will register a set of event listeners in order to interact with the audio playback progress events (there are quite a few!), in order to trigger updates in its own UI (e.g. progress bar, play/pause state, etc.)

[danielweck]

The current "design" is built with basic CSS shapes, quite angular. Much like the BBC "Gel" icons: https://www.bbc.co.uk/gel/guidelines/iconography#audio-and-visual

Conversely, the Material Design "rounded" icons are softer and more elegant:
https://material.io/resources/icons/?style=round

(scroll down to find the play/pause/rewind/etc. icons)

[danielweck]

Updated r2-navigator-js player style (SVG icons), and added speed/rate control:

[danielweck]

Note that the screenshots above show the minimal reader window size (constrained width/height dimensions). Also note that the time indicators underneath the audio player's own timeline (left and right-aligned) show by default the current time and the total track time, respectively. However the labels are clickable and can toggle between remaining time (negative value) and percentage progression, respectively.

Also note that the bottom bar and its accompanying left/right arrow buttons (located on the right hand side) has not been tweaked for audiobooks yet (other than the "more information" popup which shows progress data). The bottom progress bar encompasses the entire publication reading order (i.e. multiple audio tracks), so it is not redundant per-se. However it looks redundant in the user interface, which is quite crowded. To be discussed further.

[danielweck]

bug triage: this clearly needs to be moved to a "discussion", this is not an actionable issue (plus, we decided that responsive design is not on the roadmap, due to Thorium's minimum window width)