Skip to content

(UX) progress bar(s) improvement #9979

Description

@mergen3107
  • KOReader version: 2022.11-62
  • Device: Onyx Boox Kon-Tiki 2 (Android)

Hi guys!
Following items are not issues, but suggestions on bottom and top progress bars' UX.
I am not insisting these to be fixed, but I think if they are fixed it will make KOReader a tad more polished ereader.

(Also, answering the question of me being so picky - yeah, congrats guys! That means KOReader works so good, that only those tiny details are only jumping into view :D )

☐ Item 1 (bottom progress bar): redraw box when margins are tight

bottom1_clock_redraw

When Auto refresh is on, the bottom progress bar redraws after each minute update.
I set the Font size to 12, Container height to 7 and Container bottom margin to 1.

Now, when it refreshes, the next total width of the whole progress bar string is different. This is because in this font characters 5 and 6 have slightly different widths. This consequently allows to see that there are remnants of previous string after redraw.

So maybe there should be a white box drawn first over the whole progress bar area before the new string is drawn for the refresh?

Temporarily, if I set the font size to 11 or lower, this "fixes" it, but the text is quite tiny.

✅ Item 2 (SOLVED in #9983) (bottom progress bar): redraw box when bottom menu is open

bottom2_bottom_menu

When Auto refresh is on, the bottom progress bar redraws after each minute update and even over the bottom menu.

In order to keep everything working as intended, here is my suggestion: make bottom menu aware of the bottom progress bar if it's used.

  1. I suppose a flag like " Auto refresh is on and bottom bar is active" should be passed to the bottom menu before the menu is drawn.
  2. Bottom menu then suppresses/suspends the progress bar refresh, and then triggers it after it is closed, if necessary, i.e. if the time has changed while the bottom menu was open.

☐ Item 3 (bottom progress bar): left/right alignment margins?

bottom3_alignment

In the settings of the bottom progress bar progress line, there is an option to light the text string to right/left/center. However, I don't understand where is the alignment beginning for the progress bar string. It doesn't seem to be affected by the setting and it doesn't align to either of book margins (currently 20 in the picture above) or the default margin (16). By trials, I found that the string and the progress line match when the both book margins are set to 10.

Can the progress bar string be aligned with the progress line?

✅ Item 4 (SOLVED in #9985) (top progress bar): bookmark sign in the corner: start after the top progress bar

top_bookmark icon draw location

Currently, the bookmark icon drawing area is not affected by the top progress bar.
Can this be adjusted?

☐ Item 5 (top progress bar): remove it completely?

I remember you guys complaining about the top progress bar being an utter rubbish when it comes to handle it overall.

So maybe with 1) making the bottom progress bar adjustable to be put on the top; and 2) adding the author's name (#7642), we can remove the legacy top progress bar completely? So that it will do the same job if needed, expect there won't be a second progress bar simultaneously.

This will unwind the haywire of the top progress bar from the bottom menu. Haywire, because the top progress bar is strictly related to the settings of the document layout, not reader settings. This is the legacy of crengine after all.

UX-wise, this change will make it much easier to set up and actually use the progress bar.

✅ Item 6 (SOLVED in NiLuJe@cc2b072) (bottom progress bar): does not refresh instantly after tap

In muPDF engine, tapping on the bottom progress bar does not show up instantly. However it works as intended.

For example, I have a progress bar which fits it all. Taping once causes it to disappear. Taping another time brings it back. It is fine in crengine, but in mupdf I tap it once, it slightly shifts (redraws?) but the action will be visible upon next page turn. Maybe it is because the zoom is set to Fit the page?

Metadata

Metadata

Assignees

No one assigned

    Labels

    UXsolvedThe issue is solved. Details are described in the issue.wontfixPR are welcomed

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions