Skip to content

Commit

Permalink
Decrease touch-delay limits
Browse files Browse the repository at this point in the history
I have been testing around in some modes and only now really realized that a 'Release' event is not a ShortTouch.

Which is okay that we do it like this. We basically get three modes out of a button: Tap, ShortPress, LongPress.

But when playing around, it felt very sluggish. I thought the ShortPress mode was broken because it felt like a LongPress. :P
I researched online on UX studies and what kind of reaction people expect from Touch-UIs. Usually, a touch->interaction latency should be below 300ms. This is the Tap -> Response delay and not necessarily a good value for 'ShortPress' above them. But it gives a lower bound. I went with 500ms which does feel like a nice balance between 'I can always tap when I want and don't do accidental ShortPress' vs 'I want to do ShortPress and it does not feel so sluggish.'

Try it out. And let's discuss! :-)
  • Loading branch information
TokenRat committed Sep 4, 2024
1 parent e5adcf6 commit 57d48ff
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions lib/EFTouch/EFTouch.h
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,8 @@
#define EFTOUCH_PIN_TOUCH_NOSE 1

#define EFTOUCH_CALIBRATE_NUM_SAMPLES 10
#define EFTOUCH_SHORTPRESS_DURATION_MS 1000
#define EFTOUCH_LONGPRESS_DURATION_MS 2500
#define EFTOUCH_SHORTPRESS_DURATION_MS 500
#define EFTOUCH_LONGPRESS_DURATION_MS 2000

/**
* @brief Driver for touch sensors
Expand Down

0 comments on commit 57d48ff

Please sign in to comment.