FossifyOrg / Phone

A handy phone call manager with phonebook, number blocking and multi-SIM support

Home Page:https://www.fossify.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Swipe up/down to answer/deny incoming full screen calls

s0lid5n4ke opened this issue · comments

Checklist

  • I made sure that there are no existing issues - open or closed - to which I could contribute my information.
  • I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
  • I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
  • I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
  • This issue contains only one feature request.
  • I have read and understood the contribution guidelines.
  • I optionally donated to support the Fossify mission.

Feature description

  • Swipe up/down feature to awnser/deny incoming full screen calls like in the original android dialer app (com.android.dialer, V. 23.0) or its adaptive Version the Google phone app.

Why do you want this feature?

  • More convenient/modernized processing of incoming calls.
  • Improved user experience.

Additional information

No response

I like how it's now with horizontal swipe. I don't know why vertical would be more convenient and how it would improve user experience.

I think it comes down to personal preference.
Maybe it can be added as an optional setting (opt-in)?

I don't like the idea of vertical gestures either but I'll think about making it optional.

In Google Phone, once you open the incoming call window, it is impossible to close it with the go-to-home-screen gesture (which is now used for answering the call).

I like how it's now with horizontal swipe. I don't know why vertical would be more convenient and how it would improve user experience.

Because vertical gestures better follow the anatomy of your hand and fingers. :) It's more ergonomic in both one-hand grip and two-hand grip.

Also, with horisontal swipe the thumb may block the sight of the icons on the sides, which when a user is running to reach the phone in time could unecessarily halt their reaction-time.


The most natural and ergonomic swipe direction for everyone is vertical. Or to be precise, in a curved arc.

(The thumb rotates like a "clock arrow". When holding a phone, the natural resting position of the thumb is at ~45° upwards to the side from the pivot point (center of rotation) of which is near the bottom corner of the screen (depending on the vertical position of the phone in your hand)).


Ergo, OP has a point.

The optimal design would be a "touch drag handle" at the thumb's natural resting point.

This point is the same for both left-handed (LH) and right-handed (RH) people. To further make it "dominant handedness" agnostic, the "destination trigger" should allow for a curved swipe movement.

Vertical gesture design also makes it "handedness agnostic" due to neither up or down favoring anyones dominant hand.


Here's how I'd prefer it to operate:
Imagine an H laying on it's side. The two longest lines in the H are now horisontal and represent each "destination point" where you would let go of the "drag indicator" to confirm the action of either "pick up" (up) or "decline" (down).

The center of the middle line (now vertical) in the H connecting the two longer lines represents the "drag handle" which is now conveniently located at the thumb tip's natural resting point.

When someone calls, you would put your finger at this drag handle and drag it either up or down. The drag handle would surround the tip of your finger as a fading gradient and would gradually turn green og red depending on the vertical travel distance.

The drag handle may move horisontally as well, but it's the vertical distance that confirms the action.

At a certain vertical distance, the grab handle could snap to the top of the "sideways H-shape trigger area". Along with a haptic feedback to indicate this (kind of like Pixel phone's great back gesture haptic and visual cues).

I also have some neat animation ideas in my head. Maybe some day I can animate something (my life is kind of crazy now, so not for a while).

I might draw a mock-up of what is currently animating in my head.

In Google Phone, once you open the incoming call window, it is impossible to close it with the go-to-home-screen gesture (which is now used for answering the call).

This is not the fault of the vertical gesture, but rather the implmentation of it and lack of UX considerations.

I will reference my previous message above and would appreciate if you read it. :)

The solution is very simply to use the resting point of the thumb's tip as the starting point for the gesture.

Since this point is located relatively far from the bottom where the home gesture originates from, this should never create a conflict.

Coincidentally, the tips natural resting point is exactly where fingerprint sensors are located. Which, in fact, is no coincident at all.

A second advantage of my proposed gesture design (in case of a bug like on of which is currently open in this repo) would be that since the gesture origin or starting point (grab handle) is located where the fingerprint sensor is, this could not lead to accidentally accepting or denying a call (due to said bug or muscle memory). Because when you unlock, you firmly seat the finger tip at this position.


So all that would be required would be for the app to ignore swipe gestures unless you grab the touch handle.

This should trigger a slight haptic feedback as well to inform the user that you actually hot the grab handle trigger area. There should be a second haptic feedback when the drag handle snaps to either vertical pole (destination) and a haptic feedback for unselecting (unsnapping) so that you can confidently change your mind.

There should not be a haptic feedback when the app performs the inputed action (accept/deny), both because it could be mistaken as unsnapping to neutral position (starting point) and also because the screen UI transitioning from the action being performed is more than sufficient (imo). And it doesn't bombard the user with more than the intuitively useful and necessary "informative signals".