-
-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swipe left and right to switch articles #144
Comments
This is the one feature I miss from inoreader. Thanks for considering it! |
Missing this feature badly too... |
Add me to the list. |
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 🙏 |
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 It looks like this: Feel free to tell us your thoughts about this suggestion! |
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 |
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 |
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). |
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 Gmailgmail-swiping.mp4Swiping gestures is also advantageous over the existing "v" button on the bottom toolbar. Here is a comparison of each option:
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 🤯) |
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
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.
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.
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. |
And, here's my implementation of 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. |
We've got a better solution for this 😉 |
First of all, I don't hate FAB, but FAB should appear where it should.
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.
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.
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.
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: Feedlyoverscroll-feedly.mp4Google Calendaroverscroll-google-calendar.mp4Telegramoverscroll-telegram.mp4Considering that this is a commonly used gesture, I think Read You could possibly adopt this on both the Expand list item to a fullscreen viewcontainer-transform-list.mp4
Anyway, this demo looks excellent, well done! |
Hello coming from #602. If we use up/down instead of left/right can we at least add both options in the toolbar? I'd like to add here that I'm a Tablet user and my experience with up/down switching is not good.
Completely agree with @alfureu but IMO here at least |
@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 🤣 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.
|
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. |
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. |
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. 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. |
No description provided.
The text was updated successfully, but these errors were encountered: