Increase usability on eInk devices

[Biont]

First, let me thank you for this wonderful app. It's easily my most-used app on my phone. I just got an eInk device and was hoping to be able to turn it into an actual digital newspaper with Nextcloud News.

Now don't get me wrong, the app is well-usage without major problems, but I figured that for a usage scenario that makes so much sense (even if it's admittedly a niche one that not many users will make use of), the experience could still be imrpoved with some tweaks that might(?) be simple to implement. Here's what I found:

• The contrast of the app header is a little low using the bright theme
• The side panel animates in an out which is undesirable on an eink device
• News items need to be scrolled via touch. I think some sort of pagination with arrow buttons or touch areas at the top/bottom would work a lot better here. They would only cause a single screen refresh
• Simliarly, you can only switch prev/next articles by swiping. Again, little arrow buttons or touch areas left/right would help greatly

How do you feel about adding some kind of "eink-mode" to the app?

[stefan-niedermann]

The contrast of the app header is a little low using the bright theme

Should be resolved with #943

The side panel animates in an out which is undesirable on an eink device

Android supports disabled animations natively, though i noticed, that this does not affect the sidebar (also not in any other app with a sidebar). Ideally the app can detect this global setting and disable the animation, but since no other app supports this, i personally consider this as a minor issue or at least something that should be reported and fixed upstream (AOSP?).

News items need to be scrolled via touch. I think some sort of pagination with arrow buttons or touch areas at the top/bottom would work a lot better here. They would only cause a single screen refresh

Can you provide a mock up of how you imagine this? If one can't detect an eInk display and only add buttons for this, i'd vote against this as it would clutter the UI unnecessarily for all other users.

Simliarly, you can only switch prev/next articles by swiping. Again, little arrow buttons or touch areas left/right would help greatly

The app already provides an option to switch to the next article via volume buttons additionally to swiping - this seems to be an appropriate workaround for this.

[stefan-niedermann]

@Biont since the first issue has been solved in the meantime i would like to hear more input, especially regarding the 3rd and 4th issue 🙂.

[Biont]

Hey sorry for not replying earlier. Thank your for your mindful reply and for your continued efforts - a large chunk of which landed on my devices via F-Droid today.

Shortly after creating the original issue, I started toying around in a forked repository and implemented a couple of things. I don't consider my changed PR-ready, but it was good enough to use on my personal reader for quite a while. But it helped me make up my mind about a few things and the way they can/cannot be implemented. (It seems though that I never committed my branch and the changes are all on my other computer, so I am going off the top of my head when talking about them)

Android supports disabled animations natively, though i noticed, that this does not affect the sidebar (also not in any other app with a sidebar). Ideally the app can detect this global setting and disable the animation, but since no other app supports this, i personally consider this as a minor issue or at least something that should be reported and fixed upstream (AOSP?).

Yes, this is minor. But as you said, it is not governed by Android's animation settings since it is indeed tweened "manually" by that particular view -which sucks. I was able to short-circtuit the behaviour, but it was easy to confuse the views by doing very very short swipes. Sometimes the drawer would get stuck - or it would behave as if it was opened despite being closed. I wouldn't suggest spending too much time here.

Can you provide a mock up of how you imagine this? If one can't detect an eInk display and only add buttons for this, i'd vote against this as it would clutter the UI unnecessarily for all other users.

In my fork, I think I added a "Swipe instead of scroll" toggle to the settings. Then I added a GestureListener to the adapter that intercepted all scroll events and programmatically scrolled the RecyclerView by ~70% when a swipe has been detected. I basically applied this wherever possible to make every navigation possible via swipes. This worked great for the news item list but caused some trouble in the detail view since the view layout is much more complex there I believe WebViews inside some other RecyclerView that can be scrolled horizontally. This made swipe detection quite a bit more error-prone and for some reason, my swipes would always result in a click event on the WebView which often led to accidental navigation. Also, "Mark entries read while scrolling" broke with this behaviour since the underlying logic really needs to be triggered as you scroll an item out of view. I tried for quite a while, but could not find a way to command that "everything between Y:110 and Y:180 needs to be marked as read now" without getting dirty with the ORM and finding a way to predict/fetch previous item IDs (which was beyond my understanding)

The app already provides an option to switch to the next article via volume buttons additionally to swiping - this seems to be an appropriate workaround for this.

My reader does not have volume buttons. It only has a power button. It offers software buttons via an overlay that I can use to scroll lists. This helps with the news item list, but switching articles is still impossible.