[Feature Request] Advanced tools for reading and library management

[Hadilan18]

I'd like to suggest some comprehensive, logical enhancements to the UX/UI of OpenComic. With the right implementation, these changes will deliver the best reading experience that any digital comic/manga/novel reader app can offer.

---

1. Toggle option to hide scrollbar

• The problem: The default scrollbar, though small, still occupies display area and can be considered visual noise that more or less compromises the immersion in the artwork.
• The suggestion: To make reading in maximized window/fullscreen truly free of any distraction, I suggest making an "Invisible Overlay Scrollbar" that stays hidden even when scrolling or moving the cursor around.
• How it works (When toggled ON):
  • The scrollbar is hidden completely, giving the user 100% of the display area for the comic content. It will not show up automatically when scrolling.
  • It only appears as a thin overlay when users hover or flick the cursor to the absolute right edge, with a clear intention to check progress or drag the scroll thumb.
  • Once the cursor leaves the edge, it smoothly fades out.
• Why a toggle is needed: Because it might not benefit users who read text-heavy light novels, or those who have a habit of glancing at the progress bar constantly and might feel disoriented without it.

---

2. Read or Unread, that's the whole point.

• The problem: The current logic of "reaching the last page = 100% fully read" is fundamentally flawed. If a user quickly scrolls to the last page just to check file integrity, preview the ending, or accidentally opens the wrong chapter, the app automatically marks it as read. This "guesswork" makes it very difficult for related features to function properly—such as the fading of completed chapters or a potential "Show only unread" toggle.

• The flaws of alternative solutions:

  • The 80/20 scroll rule: Marking a file as read when the scroll position passes 80-90% and stays there for 3-5 seconds fails for speed-readers, and any timed duration is highly subjective.
  • Header menu trigger: Using the "Next Chapter" button in the header menu as a trigger also fails. If a user reading Chapter 1 wants to skip to Chapter 3, clicking the next chapter button in the header would instantly mark Chapters 1 and 2 as fully read, even if they never saw a single page of Chapter 2.

• The solution: Create a large bottom navigation component (around 50px in height) placed right under the last page/paragraph of the chapter, and lock the "Fully Read" condition strictly to this component's actions (via mouse click or assigned hotkeys).

  • This component should be treated as a standard Page Element with its width matching the Comic Container. It should appear, disappear, or be cut off seamlessly in accordance with the user's scrolling speed, just like standard webpage text.

• Why it works:

  • For sneak-peeks or accidental clicks: If a user fast-scrolls to the last page and exits, the app will correctly keep its status as Unread.
  • For normal reading flows: Triggering these buttons provides an undeniable confirmation of the user's intent to finish the chapter and move on. Whether a chapter is marked as read depends entirely on explicit user action.

• Handling Series vs. One-shots:
  What if a user reaches the final chapter in a folder, or finishes a standalone book with no next file to proceed to, but still wants to mark it as read?I suggest dividing this bottom bar into 3 unequal areas: [Return to Folder] on the left, [Finish Reading] in the middle, and [Keep Reading] on the right. This layout covers almost all edge cases, even for folders mixing mini-series and unrelated one-shots:

  • Case 1: For Series (Chapters are in order): The user triggers the [Keep Reading] action to formally mark the current chapter as read and transition to the next file alphabetically.
  • Case 2: For Standalone One-shots (Next book is unrelated): The user triggers the [Finish Reading] action. The app marks the current book as read and navigates back to the folder view. This allows users to complete a book and browse for another in the same tab, without having to right-click to mark it as read manually.

---

3. Managing Library with Dynamic "NEW" Badges

• The problem: Users currently have no way of knowing which series have newly added chapters without manually opening each folder to check.
• The solution: Implement a dynamic notification badge system tied to an Electron file watcher that detects changes in the master directory. The "NEW" badge on individual files will automatically vanish only when those files are opened.

Inside the folder, individual files will have a simple "NEW" text/badge. Outside on the folder thumbnails, the badges will change dynamically based on 4 states:

• State 1 (Newly Added Content): The user adds 5 new chapters to Folder A. Before opening the folder, the directory thumbnail displays an urgent RED badge: 🔴 5 NEW, signaling fresh, unseen content.
• State 2 (Acknowledged Content): The user opens Folder A to see what's new but exits without opening/reading any chapter. Inside the folder, all 5 files still retain their "NEW" badges because none were opened. However, when returning outside, the folder badge changes to a neutral BLUE color: 🔵 5, signaling that there is no more unseen/unacknowledged content, but the folder still contains 5 chapters with active "NEW" badges.
• State 3 (Reading Progress): The user fully reads 1 new chapter and proceeds to the next, leaving 3 untouched. Thanks to the "faded on completed" or "show only unread" toggle, the fully read chapter either fades or disappears, while the 3 untouched files keep their "NEW" badges. Outside Folder A, the number on the blue badge automatically decreases to 🔵 3 accordingly.
• State 4 (Overlapping Content): The user adds 2 more chapters to Folder A (which still has 3 chapters in the blue badge state). Outside Folder A, the badge instantly reverts to RED and displays: 🔴 3 + 2 NEW, telling the user they have 3 previously seen but unopened chapters, and 2 brand new ones. Once they open Folder A and return, it goes back to 🔵 5 (merging the counts). When all 5 chapters are opened, the badge removes itself completely.

📂 How this works on Multi-Level Folders
Let's suppose the library is categorized into a 3-level directory tree: MANGA (Root) ➔ ACTION & ROMANCE (Genre) ➔ SERIES (Comic Title)

• Scenario 1:
  • Current State: The SERIES folder inside ACTION contains 3 blue files (seen, unopened). ROMANCE has no active badges.
  • How it looks: Outside ACTION shows 🔵 3. Outside MANGA still shows 🔵 3, reflecting all changes in the deeper levels and signaling 3 unopened chapters remaining in the root directory.
• Scenario 2:
  • Current State: The user adds 2 new files to SERIES (ACTION) and 2 new files to SERIES (ROMANCE). (Previously, ACTION had 3 blue chapters; ROMANCE had 0).
  • How it looks:
    • ACTION Folder: Displays 🔴 3 + 2 NEW (3 backlog + 2 fresh files).
    • ROMANCE Folder: Displays 🔴 2 NEW (0 backlog + 2 fresh chapters).
    • MANGA Folder (Root): Combines data to display 🔴 3 + 4 NEW (3 blue files from ACTION + 4 fresh chapters from the entire directory tree).
  • The Dynamic Update Flow: When the user sees 🔴 3 + 4 NEW outside MANGA and begins browsing, the badge system updates dynamically step-by-step:
    • Step 1 (The user opens ONLY ROMANCE and returns): Inside ROMANCE, the 2 new chapters are acknowledged, converting its badge to 🔵 2. Outside, MANGA updates to 🔴 5 + 2 NEW—as the remaining unseen count is now 2 (from ACTION), while 2 files from ROMANCE join the 3 previous blue chapters to make it 5.
    • Step 2 (The user enters ACTION and returns): The last 2 newly added files from ACTION are acknowledged and turn blue. Inside ACTION, the badge updates to 🔵 5. With no more unseen chapters, MANGA changes to 🔵 7 (5 from ACTION and 2 from ROMANCE), signaling the total unopened chapters left in the library.

🛠️ Bulk Actions to Clear "NEW" Badges
While the "NEW" badge system works well by design, there are edge cases—such as importing a 100-chapter series where half were already read elsewhere, renaming folders, migrating files, or setting up the master folder for the very first time—where keeping thousands of active flags defeats the purpose of tracking fresh content.

To resolve this, we need cleanup tools on micro and macro levels:

• At the Individual File Level (Micro): Implement hotkey selections (Ctrl + Click for individual files, or Shift + Click to select a range) combined with checkboxes. Users can then right-click and choose "Remove NEW badge" for the selected files. This allows users to easily clear the 50 chapters read elsewhere while keeping the badges on the remaining 50. This approach avoids the complex code required for Windows Explorer-style drag box selection, making it lightweight and easy to implement in Electron.
• At the Sub-folder Level (Medium): Allow users to right-click a folder thumbnail to open a context menu and choose "Remove NEW badges for this folder". This perfectly resolves issues caused by file migrations or folder renames.
• At the App Level (Macro): Add a "Clear all NEW flags" button located deep within the Global Settings, accompanied by a yellow warning text. This provides a clean slate for initial application setups and massive library imports.

---

4. Bookmarks and Multi-Tab Session: The Perfect Duo

• The concept: Integrate customizable bookmarks and the table of contents into the left sidebar using a Dual-Tab Layout (separating Page Preview and Bookmarks).

To put it simply, here is how the interaction between controlled automation (without autosave) and explicit user intent (the BOOKMARK list) works seamlessly to cover every reading behavior:

• Want to binge the next chapter or pick other books? Scroll to the bottom and click the next or finish button to mark it as read and clean up the library along the way.
• Want to stop mid-way and resume tomorrow? Just leave that tab open, close the app, and let the automatic session restore handle the rest.
• Want to save an impressive artwork or a critical story detail with your own notes forever? Bookmark it and rename it right on the left sidebar.
• Opened a wrong chapter, checking file integrity, or just skimming without wanting to save anything? Click the 'Return to Folder'/'Back' button or simply close that tab.

🛑 Making the "Continue Reading" Bar and Progress Bars Obsolete

The combination of these features in action makes the traditional "Continue Reading" bar obsolete. It eliminates database waste caused by automatically storing the last accessed page of every single file—including completed, skimmed, or deleted ones.

There is also no more need for progress indicators on book covers, such as progress bars, percentages, or Current/Total Pages counters. These metrics are often misleading because they confuse casual skimming with actual reading.

Currently, to prevent skimming from ruining library tracking, users are forced to manually scroll or use hotkeys to reset every single skimmed chapter back to the very first page. This manual process easily leads to mistakes. Finding out later that a chapter thought to be "fully read" was actually just skimmed can cause frustration, making users worry that more books across the entire library are falsely marked as read.

With the timely implementation of these new features, PAGE COUNT (for Comics) and WORD COUNT (for Light Novels) should be the only reliable metadata displayed on book covers. They are 100% honest, regardless of whether the user skims, reads deeply, enlarges the view, or reduces font sizes.

---

Closing note

The major pain points of the old features are clear as day. Yes, removing them now might confuse users at first since they've been accustomed to them for some time, especially the continue reading bar which has probably been around since the early days of OpenComic.

However, instead of forcing users through frustrating workarounds, I'm sure they would find the synergy between the new features logical, as seen in how the 'Return to Folder' and 'Next Chapter' buttons at the bottom serve not only as alternatives but also cater to existing habits like skimming and sneak peeks.

This is why having a clear design in mind from the start would make room for future upgrades much easier, and keeping a clear goal of serving 'reading' as the one and only core value prevents the need to strip away irrelevant features later on—only after they contradict code, cause bugs, or make the app slower.

I think OpenComic still has plenty of room for development and a long road ahead to truly become the ultimate reader app. But I hope you feel motivated to continue thinking about how far this project has come and that there is still much to do. The potential is there.