Ashinch / ReadYou

An Android RSS reader presented in Material You style.
GNU General Public License v3.0
4.77k stars 187 forks source link

Swipe left and right to switch articles #144

Open Alphabet1226 opened 2 years ago

BundleOfJoysticks commented 1 year ago

This is the one feature I miss from inoreader. Thanks for considering it!

alfureu commented 1 year ago

Missing this feature badly too...

sbellon commented 1 year ago

Add me to the list.

alfureu commented 1 year ago

Would like to again endorse this function. The issue is that the app's usability for me is very limited without the swipe functionality. The current phones are rather big (e.g. Pixel 6 or Pixel 7 Pro) and reaching to the bottom of the screen for every article is really difficult without the risk of dropping the phone.

Please introduce this functionality ๐Ÿ™

JunkFood02 commented 7 months ago

Hello, I can understand the pain of using a phone with one hand, especially on a large screen. However, swiping left and right to switch between articles seems quite weird as a primary action. It could be triggered by accident when scrolling up and down to read a post. Instead of introducing a full screen gesture, we came up with the idea of using a FloatingActionButton at the BottomEnd of the screen for switching to the next article.

It looks like this:

Feel free to tell us your thoughts about this suggestion!

alfureu commented 7 months ago

Thanks for the feedback. I disagree, one of the best apps (not developed anymore) for RSS on Android was Press. One does not need to scroll through the whole text (my server collects full text for reading) to get to the next article, if - based on the title and 1st para - one does not want to read it. Also, swiping helps skim-reading many articles while waiting for bus, or commuting.

Again, especially on huge phones (which become a norm these days), swiping is essential imho. At least introduce this functionality as optional, not everyone needs to agree with me

JunkFood02 commented 7 months ago

huge phones (which become a norm these days), swiping is essential imho

Then how about making the button larger, or move it closer to your comfort zone? With a button placed at a fixed position, switching action should be more accessible and predictable than swiping across screens

sbellon commented 7 months ago

A larger button only covers more screen area. I have to agree with alfureu on this.

If you strongly object to swiping and want to add a floating button, then please do not make it large, and ensure that not only advancing to the next article, but also going back (by a long press perhaps?) is possible.

I still think, swiping would be the best choice (could be an option you can enable or not).

Lzmxya commented 7 months ago

I think adding FAB on the article screen is not a good idea, it will reduce the display space for the article and disrupt the reading experience. Referring to the Material Design guidelines, FAB should only be used to represent the screen's primary action. However, the most crucial action on the article screen is "reading the article!" Look at other web browsers, video players, or book readers, they don't have FAB on the main content.

Switching between previous or next articles by swiping left or right on the article screen is, in my opinion, a very intuitive design. In fact, that's what Gmail does, and it doesn't conflict with the system's back gesture:

Swiping in Gmail https://github.com/Ashinch/ReadYou/assets/5507263/3ad6c88c-05fb-4ce0-b1ff-adf29066b82f

Swiping gestures is also advantageous over the existing "v" button on the bottom toolbar. Here is a comparison of each option:

Swipe gestures FAB Bottom toolbar "v" button
Visual distraction None High Low
Go to next Yes Yes Yes
Go to previous Yes ? No
Chance of fat-fingers Low (If it has a suitable sensitivity thresholds) High (Considering the position of FAB) Middle
Back to the original article Yes (Could do better by temporarily remembering articles scroll position) ? No (Can only back to articles list)
Easy get started Middle (May need a tutorial) ? Middle (The icon may be misinterpreted as scrolling to the end of the article)
Conflicts with others Yes (Transition direction is different from the "v" button) ? Yes (Transition direction is different from the swipie gestures)

I believe excellent design should be intuitive, user-friendly, and universally applicable. If a design can fit in with the habits of most users, I think there's no need to "provide options" for that feature (that's why we rarely see options like "Enable pull-to-refresh?"). After all, too many options can be overwhelming and confusing, and simplify the complex is the better way to go. (Imagine if all the options from chrome://flags were added to chrome://settings ๐Ÿคฏ)

Ashinch commented 7 months ago

Next, weโ€™ll preview the effects of #468 or #481 in the nightly version to assess its impact on the current code logic.

JunkFood02 commented 7 months ago

Lmao I can literally feel your hate on an FAB just like my hate on the horizontal swipe gestures. Though I've already got another design in my mind(will post in next reply), I'll still try to defend the idea of this big dumb button. Just a disclaimer: view are my own

An FAB will reduce the display space for the article and disrupt the reading experience.

Chance of fat-fingers (FAB): High (Considering the position of FAB)

According to my initial design, the fab will disappear (or collapse) along with the toolbar (just like the twitter app). I don't think the "reading experience" could be ruined by an invisible button, especially when you're really "reading" an article instead of taking a glance at the title and quickly swipe it away.

In fact, that's what Gmail does, and it doesn't conflict with the system's back gesture

Sorry but I've never noticed that exists in Gmail ๐Ÿ˜‚, not a fan of it. I can even notice that many parts of it are simply against the material guidelines, like the navigation bar with only two items.

Though I didn't mention the part of back gesture, it could be an issue.

Switching between previous or next articles by swiping left or right on the article screen is, in my opinion, a very intuitive design

Visual distraction(Swipe gestures): None

Doubt it. Swiping horizontally to switch between articles is very counter-intuitive.

According to the material design guidelines (and my own feelings!), the lateral pattern is used for navigating between peer content at the same level of hierarchy, like swiping between tabs of a content library.

Think about the design of a photo gallery, switching between articles seems to fit this criterion just like switching between pictures. However, I'll expect switching between limited tabs or groups when displaying a vertical scrollable content. It's weird, but I feel overwhelmed when I find it possible to reveal more contents with two gestures perpendicular to each other.

Users like me may be more famillar with the pattern of "scrolling down to load more". For instance, pulling down to load component, or the endless feed in twitter or any other social media. I know this might sound like a SNS addict... And yes, it's addictive, because it's more intuitive for users than scrolling horizontally for a new content.

JunkFood02 commented 7 months ago

And, here's my implementation of Pull up and down to switch articles ๐Ÿ˜‰

https://github.com/Ashinch/ReadYou/assets/69683722/bb84d216-f90a-404b-9438-86a25e4b8fef
alfureu commented 7 months ago

And, here's my implementation of Pull up and down to switch articles ๐Ÿ˜‰

2024-02-05.15.46.41.mp4

Well, this looks very effective but impractical. Why should I swipe through a looooooong article from the New York Times, if I -know-, based on the title and 1st para that I do not want to read it?

In the other competing design, I can just swipe, and that's it.

JunkFood02 commented 7 months ago

Why should I swipe through a looooooong article from the New York Times, if I -know-, based on the title and 1st para that I do not want to read it?

We've got a better solution for this ๐Ÿ˜‰

Lzmxya commented 7 months ago

First of all, I don't hate FAB, but FAB should appear where it should.

According to my initial design, the fab will disappear (or collapse) along with the toolbar (just like the twitter app)

Even so, swiping is still the least visually disruptive implementation. And, when you do want to switch between articles, you have to slide out the FAB (if it is collapsed) and aim and tap it. In contrast, the trigger area for gestures is the whole screen! Therefore, I think the swipe gestures is more efficient than FAB. (If we use the analogy of a car center console, FAB is like a touch screen, and swiping is like knobs. It's hard and dangerous to drive and operate the touch screen at the same time.)

Speaking of Twitter, we can see that it only uses FAB on the home screen (and it's for creating new posts, which I rarely do, but in all fairness, it's a very important action), but once you tap into someone's post, there's no FAB.

Doubt it. Swiping horizontally to switch between articles is very counter-intuitive.

If you consider Read You as a magazine, then the articles list would be the table of contents of that magazine. Typically, the items in the table of contents are vertically arranged, while articles are presented one page after another. As you flip through, you either go from left to right or from right to left, meaning your page-turning direction is horizontal.

Moreover, as @alfureu said, horizontal swiping has a significant advantage: once you find yourself bored with the current article, you can easily flip to another page (which is something I often do when reading printed magazines). However, vertical gestures force you to scroll through the entire article (imagine if it's as long as this comment you're reading ๐Ÿ˜‚), which can be quite inconvenient.

We've got a better solution for this ๐Ÿ˜‰

Do you mean the "v" button? Or some other newly introduced gesture? If it's the "v" button, I think it's a bit redundant to have multiple entries for a same function; if it's a new gesture, I hope it's easy to learn and easy to use.

According to the material design guidelines (and my own feelings!), the lateral pattern is used for navigating between peer content at the same level of hierarchy, like swiping between tabs of a content library.

The guideline use the word "like", so that means including but not limited to. Swiping between articles is, of course, a same level of hierarchy navigating.

Finally, I have found that a number of apps use vertical overscrolling to close the full-screen dialog. Here are some examples:

Feedly https://github.com/Ashinch/ReadYou/assets/5507263/f6fa4070-bb6d-4a62-a607-12aa8d9f8370
Google Calendar https://github.com/Ashinch/ReadYou/assets/5507263/c26f53e7-1b76-4c71-972e-3a14f4098abd
Telegram https://github.com/Ashinch/ReadYou/assets/5507263/e2edf1d3-8219-47f2-8f86-62c59b3fd3a0

Considering that this is a commonly used gesture, I think Read You could possibly adopt this on both the ReadingPage and the ReaderImagePage. This will be useful especially when you keep scrolling down and finally finish reading and want to go back to the articles list, you only need to scroll down one more time. And it even works perfectly with the container transform suggested by Material Design (see below), that's neat!

Expand list item to a fullscreen view https://github.com/Ashinch/ReadYou/assets/5507263/165e5baa-2a6a-4d34-b816-3cddc09e491f

And, here's my implementation of Pull up and down to switch articles ๐Ÿ˜‰

Anyway, this demo looks excellent, well done!

shuvashish76 commented 7 months ago

Hello coming from #602. I'll re-explain the problem again: With current implementation it's difficult to switch previous article if you're in mid+ part of an long article. I don't have any problem switching next article as we've a button for it in the Toolbar. (turned off "Auto hide toolbars")

If we use up/down instead of left/right can we at least add both options in the toolbar? Something like this๐Ÿ‘‡๐Ÿฟ ReadYou_Toolbar

I'd like to add here that I'm a Tablet user and my experience with up/down switching is not good.

The current phones are rather big (e.g. Pixel 6 or Pixel 7 Pro) and reaching to the bottom of the screen for every article is really difficult without the risk of dropping the phone.

Completely agree with @alfureu but IMO here at least < > in "Toolbar" is the best option for us if devs decide to go with up/down swipe.

BundleOfJoysticks commented 7 months ago

@JunkFood02 thanks for putting a lot of thought into this. I don't entirely understand the reasons to reject left/right swipe as unintuitive.

Up/down to switch articles (vertical nav) doesn't fit the browsing model of forward/back (horizontal nav) of most navigation UI between like items that I can think of ("previous/next" track in music player, product on ecommerce, page in eBook or PDF reader, book in eBook reader, etc).

Pull up or down is harder to discover and error prone, as you have to give it just the right amount of force and hold time to distinguish from the scroll gesture. In general I personally disable gesture navigation on all my Android devices and all browsers on all platforms, and use three-button nav, so I didn't even know pull-up was a thing until this conversation :rofl: Mentally, up/down means paging through within a thing, and left/right means paging through between like things.

A left-right arrow in the toolbar like @shuvashish76 proposed would achieve the same mental model as left-right swipe and could work well without taking up new visual space. A FAB requires two taps to go left/right (open FAB then tap left/right) vs just one with arrows in the navigation bar.

I'd display them farther apart than @shuvashish76 has them, and maybe have an option to display the pair together on the left, center, or right side of the navigation bar to support left and right one-handed use, in addition to either end.

โฎ๏ธ ๐Ÿ’ฟ โœด ๐ŸŽง ๐Ÿ“„ โญ๏ธ

โฎ๏ธ โญ๏ธ ๐Ÿ’ฟ โœด ๐ŸŽง ๐Ÿ“„

๐Ÿ’ฟ โœด ๐ŸŽง ๐Ÿ“„ โฎ๏ธ โญ๏ธ

shuvashish76 commented 7 months ago

โฎ๏ธ ๐Ÿ’ฟ โœด ๐ŸŽง ๐Ÿ“„ โญ๏ธ

This is bad if you use the device on one hand since you've to reach opposite ends to go previous/next articles. Maybe instead of pre-fixed positions, option to drag & sort each button according to user choice in settings would be perfect.

Emporea commented 4 months ago

I look forward to this improvement as well. I would like to add that nextcloud news (the reader I used before) had left/right scrolling and it felt really intuitive and it was so so useful! With Read You it is not even possible to go back one article.

https://github.com/nextcloud/news-android

teilzeitutopist commented 1 month ago

Okay, I can see the issue has been controversially discussed. But I wanna give my two cents: Just tried out Read You yesterday for the first time and love the design, speed and approach (really a LOT!) . But I also directly tried to swipe left and right for switching between articles in reading mode, as it feels natural to me from so many apps like Newspaper apps, my previous feed readers (inoreader, newsblur) or even gallery apps for photos. I was surprised to not find the option to activate that in the settings. So I came here to check, if it has been discussed.

For me, all articles in a folder of subscribed feeds are in my mind on the same hierarchy - as are photos in an album, where I would never swipe down to see the next photo.

In reading mode I wanna go through all articles in my own speed, sometimes slow, reading everything, sometimes reading some paragraphs and deciding to skip the rest, often just scanning the title or a few sentences. Ultimately my feed reader is an aggregator of several sources that first and foremost saves time. That efficiency I am missing as of now in Read You. If I only had sources I really cared for almost all articles completely, the current behaviour would be fine. But for me it's just the opposite. A lot of switching to the next article without reading a lot of the article is mostly inconvenient: The "v" is only really usable in two hand usage on my phone and even then it's super small and I have to be super precise. To make it worse the bottom bar with the "v" is disappearing after beginning to scroll per default (okay I changed that).

All in all: I want to be another clear advocate for introducing swiping horizontally as a feature. It's clearly not counter-intuitive for me and I suppose a lot of other folks.