Touch Gestures

[zoomiti]

I love the whole yarr experience even on mobile but I feel myself wanting to interact with it in a way it doesn't support yet.

I want to implement 3 touch gestures I feel like it could use but I want to know if there is any interest in it.

The three gestures are:

• Swipe down on an open post to close it
• Swipe left on an open post to go to the next post
• Swipe right on an open post to go to the previous post

In essence I just want to add the some of the same functionality granted by keyboard shortcuts on desktop.

[nkanaev]

Hi @zoomiti,

I like the idea, but I need to clarify a few points:

• Are there benefits of introducing swipe vs. relying solely on touch (the latter implying using buttons for navigation)?
• If we agree on swipes, can they be implemented without frameworks?

[zoomiti]

Hi @nkanaev,

• I think on a phone it is just slightly more convenient to slide on the RSS post body over having to reach buttons. I think it also has the benefit of not adding extra "chrome" as I've seen you mention it before. We're talking about a touch device meaning the size is directly proportional to how easy it is to click but we also don't want to lose screen space for the post. Plus to reiterate, it accommodates holding your phone with either hand so that you don't have to worry about your thumb reaching the x, prev, or next buttons.
• Theoretically yes. I was already planning on using a pure JS solution modeled around this implementation

[nkanaev]

By extra "chrome" I was referring only to the bottom bar, the navigation buttons (at the top) are ok imo. And I have concerns about the "swipe up to close" - it clashes with content scrolling, creating "longcut" for content-rich articles. But all in all, I like the idea and I'm happy to include the feature.

It's very likely that I'll rewrite the article navigation API in the near future. You can use helperFunctions.navigateToItem from key.js in the meantime.

[zoomiti]

There's no reason I couldn't add the buttons too. It's mostly a convenience feature that circumvents making the buttons more easily reachable.

Also swipe down would only happen when you start swiping the top bar. That way there's no conflict between the scroll bar in the content and the close action. Sort of like how the control center used to work on IOS or an inverse (swipe up instead of down) of the notification panel on either mobile platform.

[nkanaev]

AFAIK "swipe the top bar to close" is not an established UX to justify including it into the app. Besides, if a finger can reach the top bar it surely could reach the X button (with a right hand finger at least).

On second thought:

• the swiping behaviour is always accompanied with visual cues, either by icon indicator appearing during the movement or the content shifting/being moved.
• the travel distance must be significant enough not to cause accidental swipes to cause undesirable behaviour.

If the considerations are too much effort to implement, maybe good old buttons could be sufficient.

[zoomiti]

The considerations are more than reasonable. I was planning on implementing them regardless since yes, you need some visual feedback to know its happening and it can't be too sensitive.

• The implementation I linked in a previous comment uses CSS to shift the content according to the swipe which would probably be the easiest visual feedback to implement.

  • To avoid false positives of movement, there could also be minimum distance of travel before the swipe moves the content so if you're scrolling and aren't 100% vertical with your scrolling, content doesn't "jitter" as you scroll

• I plan on having the travel distance be a minimum of 50% of the horizontal screen space but I'll tweak it after implementation and proper testing.

I think two of the most prominent examples of swiping a bar up or down to close are the notification centers on IOS and Android. Admittedly they're inverted but gist is that from a UX perspective the notification centers act like curtains or projector screen. You pull the bottom of them down to open them and then push them back up to close them.

Here's actually an example of a projector screen you have to pull down to close.

[nkanaev]

I like the notification bar & projection screen analogy, though I disagree that it's applicable in yarr. Notifications are OS-level interfaces, and swiping is a reveal/hide action.

Article section in feed readers is more akin to the content areas in mobile web browsers. It's meant to consume content. Swiping down the top bar of a web browser acts as a minimize/show-all action, in Android Google Chrome at least.

"Swipe-down top bar to close" sounds too alien, in my experience. There's "swipe down the whole content to close" widely used in image viewers, but it's not applicable for text content, as it interferes with select/copy functionality.