Usability Improvement Sugestions

[Asinin3]

While LRReader is in quite a early stage I have a ton (sorry) of ideas for things that could improve the overall user experience, and would like to hear your thoughts on these.

Keybind Suggestions

• [x] Middle-Clicking a gallery to open in a new tab, and Ctrl+W to close the current tab (unless it's bookmarked) just like most browsers.
• [x] Make back/forward mouse side-buttons act as a back/forward keybind for navigation.
• [x] Pressing the space-bar to scroll down by X% until it reaches the bottom of the image, once it does pressing it again will navigate to the next page. Another keybind from browsers that I miss.
• [x] Implement the ability to drag images around to scroll them.
• [x] Up/Down arrows should scroll an image rather than go to the next/previous image, that's what the left/right arrows are for.
• [ ] Scrolling up/down while zoomed in and shift is held down will go back to its normal forward/backwards page navigation functionality

My biggest pet-peeve with LRReader is not being able to drag images around to scroll them in all directions. This becomes a huge pain if you want to scroll vertically and horizontally at the same time. And the inconsistent scroll-wheel behavior scrolling the image when zoomed in, and navigating to the next/previous page when not zoomed only makes this feel more strange.

Reader Suggestions

• [x] Add a setting to fit images to the window's width (maybe this should be disabled when the "show two pages" setting is enabled?)
• [x] Add a setting to limit the amount an image would be scaled when fitting to the windows width e.g don't scale above image's native resolution, don't scale above 200%, 300%, 400% the image's resolution
• [x] Display a short zoomfactor % overlay when zooming in, allowing users to easily zoom by a specific value.
• [x] Remember manual zoomfactor across pages on the currently viewed gallery (or add an option/keybind/button to do this)

The zoom-factor options are currently quite hard to recommend using as whenever you view a landscape oriented gallery or a double-spread page you will often get vertical scroll-bars. Fitting images to the window's width would fix this, and limiting it to not zoom the images too much would help keep low resolution images from being zoomed in too much and looking horrible.

Another issue with the zoom-factor functionality is that for some galleries you may want to zoom in by a specific amount, but if you zoom in manually that zoom factor is lost when you navigate between pages. I really think there should be either a keybind, button... or setting to lock the zoom % in place between pages on the currently viewed gallery.

UI suggestions

• [x] Show a galleries tags when hovering over them
• [x] Add a bookmark gallery button in the right-click context menu on the archives page
• [x] Add a setting to allow the "continue where you left off" functionality to work on non-bookmarked galleries.
• [x] Add a setting to make opening a gallery navigate straight to the first image unless the "Continue where you left off" functionality is available. Alternatively change this to the default behavior.
• [x] Add a bookmark button next to the settings button or to the left of the archives tab which you can click for a drop-down of all currently bookmarked galleries to click on. This would free up valuable space needed for the tab bar and allow users to bookmark more galleries at once.

The biggest thing I miss from LRR's web-interface is the ability to see tags without having to first open a gallery. It becomes tedious if for instance you search for two tags then open a gallery only to find it has another tag you don't like, then having to go back to the Archives page. Similar to this, it feels strange that opening a gallery doesn't simply just open the image viewer, and instead you need to click on the first image or click on the "Continue where you left off" button. I guess this one is pretty subjective though.

The way bookmarks and continuing where you left off on a gallery works right now is also odd. You cannot bookmark a gallery from the archives page or while viewing an image so you have to go to the main gallery page, click bookmark then either go back to the archives page or click "continue where you left off". And you can only really bookmark a few galleries at once since they take-up valuable space in the tab bar, this wouldn't be as big of a problem if the "continue where you left off" functionality worked on non-bookmarked galleries. Adding a setting for that, and adding a bookmark button to the right-click context menu seems like a no-brainer.

Sorry for the huge list, the ideas kept coming, if you want I can split this into multiple issues.

[Guerra24]

Keybinds

Tab related keys are easy to do, shouldn't be a problem. I would want more detail for the back/forward navigation, what is the expected behavior.

Reader (including the keybind related ones)

This is a tricky one, uwp's native scrollviewer is kinda... 💩 Stuff like fit to height, width, zoom by %, etc... is missing. It just gets in the way, I'm waiting for WinUI 2.3 improved scrollviewer that (hopefully) includes a lot of this. But I'm going to see what can be improved with the current one. And if there is no way, roll my own custom control.

UI suggestions

This is a more how do you want tags to look question 😅 The continue where you left requires the gallery to be baked by a bookmarked archive object to keep track of the progress, will see what can be done.

I changed the bookmarks behavior, they are closable now and to group them there is a bookmarks tabs that shows a very compact item with the title and progress. There are two new settings to open the bookmarks tab and/or bookmarked archives on start.

The bookmark reminder only works with new archives, I can make a setting to trigger it always.

If I didn't comment on something is because adding it is easy and there are no issues.

If you want to try these changes check the actions continuous delivery artifacts for the package.

[Asinin3]

I would want more detail for the back/forward navigation, what is the expected behavior.

In most software such as file explorers, browsers, media players they simply act as a back and forward button navigating to the previous window/file/folder.

The bookmark tab does look a lot better than the current implementation that just takes up too much space, so good work there. I will edit the OP when it makes its way into the main releases. And fingers crossed for being able to dragscroll. If you don't want to implement any of the suggestions feel free to just cross it out in the OP.

[Guerra24]

Thoughts? I need to tweak tags size a bit, too big right now. Sort by namespace will implemented later.

[Asinin3]

Bookmark tab looks pretty nice now, good work. I guess the only real feedback I have is that the blur is excessive I think it would be better to be able to see the covers but that's just me. And i guess it could show the hover for tags overlay too, but that's not too important here unless you have tons of bookmarks.

The hover overlay for tags does get in the way though because it appears instantly and no matter where you put your mouse. I'd like to see a few tags appearing below/above the gallery image like LRR's web interface and you can mouse-over it to show the full amount of tags. And a short delay could be added to the hover to stop it appearing when scrolling through or moving your mouse around the UI.

Thanks for implementing all these changes though!

[Guerra24]

Sorry for the 3 months of inactivity but MS broke the designer in VS(crashes the entire editor) and I didn't have any other system which had the previous version so I was stuck with a broken VS until today when they finally released the fix.

App-related, the new scrollviewer got delayed so I decided to implement a custom control where I can implement exactly how it behaves. I'm going to be adding the different suggestions into it.

[jmhickman]

Glad to see you return!

Is there API support for being able to edit metadata from an external application like this? Just about the only reason I continue to use the browser is because when I'm done with a chapter, I remove an "unread" tag that I automatically apply to all chapters I upload.

Right now the app just opens the Edit control in the browser.

[Guerra24]

Sadly no, the API is only for reading purposes. I could hack into the edit page but that's only accessible if you log-in with the password. Also I could implement it in the repo but I don't know Perl so that's kinda improbable.

[jmhickman]

Aww, too bad. Worth asking though, thanks for the fast reply. :)

[Asinin3]

Adding read/unread seems more like a feature to request upstream

[Guerra24]

I think everything (with the exception of mouse side buttons) is implemented.

[Asinin3]

Yeah you've implemented nearly everything, feel free to close if you're not going to implement the others.

[Guerra24]

From the unchecked suggestions*, in order.

• Mouse back/forward navigation is going to be implemented next, though only for pages.
• Since I dropped the base zoom/factor and instead relay on the new zoom slider the scrolling up/down while zoomed in and shift does page navigation doesn't make much sense because there is no zoomed-in mode now.
• The scaling limit is already implemented just like you suggested.
• The new zoom control in the reader displays the current zoom value.

Said that, once mouse navigation is implemented I'm going to close this.

[Guerra24]

Everything is done, finally... just took 4 months. Thanks for all the suggestions! and for waiting, this has greatly improved the app 👍 If you have more, feel free create another issue.

I'm going to release the stable version once 0.6.9 is done so I can test it beforehand (just in case).