Touchpanel I/O

I am amazed at how commonplace this is becoming -- and
how shortsighted the implementations!

Have YOU considered how a user CLEANS the panel?

If the device can be turned OFF, then they could
resort to that avenue to ensure cleaning actions
aren't interpreted as "commands".

But, if it *can't* be (or, if the user decides they
want to clean the panel NOW -- for whatever reason),
then you need a mechanism that disables input from
the panel WHILE it is being cleaned.

I use a countdown timer displaying the remaining
time (until re-enabled) and a message indicating that
the panel is inoperative for that duration.

I also make this relatively easy to invoke (NOT buried
in the 12th sublevel of a menu tree!) as, IME, it seems
to be something that users want to be able to do
without having to wonder where the control is located.
Or, having to resort to just wiping across the touch
surface and "canceling" any actions that happen to get
invoked.

On 1/23/2023 20:10, Don Y wrote:
> I am amazed at how commonplace this is becoming -- and
> how shortsighted the implementations!
> 
> Have YOU considered how a user CLEANS the panel?
> 
> If the device can be turned OFF, then they could
> resort to that avenue to ensure cleaning actions
> aren't interpreted as "commands".
> 
> But, if it *can't* be (or, if the user decides they
> want to clean the panel NOW -- for whatever reason),
> then you need a mechanism that disables input from
> the panel WHILE it is being cleaned.
> 
> I use a countdown timer displaying the remaining
> time (until re-enabled) and a message indicating that
> the panel is inoperative for that duration.
> 
> I also make this relatively easy to invoke (NOT buried
> in the 12th sublevel of a menu tree!) as, IME, it seems
> to be something that users want to be able to do
> without having to wonder where the control is located.
> Or, having to resort to just wiping across the touch
> surface and "canceling" any actions that happen to get
> invoked.
> 

On the phone it is not such a drama, switching it off via
the on/off button at the side is easy enough - unless of
course you forget to do it and still go on to wipe it,
we all have done this as well.
The worse one for me is the touchpad on the laptop, turning
it off is neither as fast nor as easy. And of course it is even
more frequently in need of being wiped - oily/sugary fingers
having touched it, crumbs etc.
How do you activate your timer? Not a bad idea at all.

On 1/23/2023 11:20 AM, Dimiter_Popoff wrote:
> On the phone it is not such a drama, switching it off via
> the on/off button at the side is easy enough - unless of
> course you forget to do it and still go on to wipe it,
> we all have done this as well.

Or, happen to be USING it at the time ("Excuse me; I have
to hang up so I can wipe the crud off my phone.  I'll call
you back in a minute...")

It seems almost instinctual that we see crud on a surface
and want to wipe it off - without thinking that there may
be "side effects" (that, as far as the device is concerned,
are PRIMARY effects!)

> The worse one for me is the touchpad on the laptop, turning
> it off is neither as fast nor as easy. And of course it is even
> more frequently in need of being wiped - oily/sugary fingers
> having touched it, crumbs etc.
> How do you activate your timer? Not a bad idea at all.

I have touchPADs in my current design that are worn
by the user.  It recognizes different "gestures" so
I allow the user to assign a particular gesture to the
"please-ignore-me-while-I-clean-things" action.

My touchPANELs tend to be more "point" driven (touch
here for this, there for that, etc.).  But, also recognize
gestures -- though don't rely on them as extensively,
for obvious purposes.  I prefer touching a corner and
HOLDING it (for a 3-count) to be easy to remember
without sacrificing any screen real-estate.  Of course,
a user could map a different icon/gesture to that action.

In each case, I've found it better to require confirmation
(timing out if none received) than to unilaterally act on
the "command".  (My thought is that a second confirmational
action is a small price to pay for this activity; much
better than an additional "menu level" -- that must be remembered!
Timeout if no confirmation in a small number of seconds)

Then, a prominent display (whatever modality is appropriate
for the user) so he knows what's happening.

The problem that I see with many products is they don't treat
the active regions analagously to physical keys.  Wiping across
them shouldn't be construed as *actuating* them.  I.e., the
OnLeave method shouldn't be the same as the OnRelease method;
if I release the "key" while I am not "on" it, then it should be
as if I never touched it.  With this simple change, you should
be able to wipe the entire surface as long as you don't release
pressure over an "active" area.

Another gripe is "icons" that appear active -- so you try to
touch them -- but aren't recognized at this point of the UX.
"Did I not touch it properly (no tactile feedback!)?  Is it
broken?  WHY DOESN'T IT WORK??!!!!!!"

IMO, any UI that hasn't been *modeled* as a state machine
(regardless of how it is implemented) will miss many use cases
and lead to a less than ideal UX.  E.g., new stove politely
displays a prompt telling you about the options that lie ahead
for you.  And, waits 5 seconds to let you read the message
before, automatically, overwriting it with the first option.

Yay!

But, once you've read this... once, twice, three hundred times...
you likely don't want to sit there staring at it for 5 seconds.
Yet, there is no way to proceed past it to the options as
it ignores all user input while that 5 second timeout runs.
That would be painfully obvious if modeled as a FSM!

The wrong sorts of people are designing these interfaces.

On Monday, January 23, 2023 at 1:10:28 PM UTC-5, Don Y wrote:
> I am amazed at how commonplace this is becoming -- and 
> how shortsighted the implementations! 
> 
> Have YOU considered how a user CLEANS the panel? 
> 
> If the device can be turned OFF, then they could 
> resort to that avenue to ensure cleaning actions 
> aren't interpreted as "commands". 
> 
> But, if it *can't* be (or, if the user decides they 
> want to clean the panel NOW -- for whatever reason), 
> then you need a mechanism that disables input from 
> the panel WHILE it is being cleaned. 

You mean like on my house thermostat, and in my car, etc?  So, what's the problem? 


> I use a countdown timer displaying the remaining 
> time (until re-enabled) and a message indicating that 
> the panel is inoperative for that duration. 
> 
> I also make this relatively easy to invoke (NOT buried 
> in the 12th sublevel of a menu tree!) as, IME, it seems 
> to be something that users want to be able to do 
> without having to wonder where the control is located. 
> Or, having to resort to just wiping across the touch 
> surface and "canceling" any actions that happen to get 
> invoked.

Or better, to just give them buttons.  You can add buttons on one, two or more sides of a screen, while labeling them on the screen.  That works very well on my devices, like oscilloscopes. 

Pretty much all menus are evil.  If you have a lot of leaf screens, you either have to make the menus deep, or wide.  My Tesla has only two levels of menus really.  The top level and the leaves.  I never know where controls are.  Which screen would you expect to find the button to view the manual (it's on the "service" screen I've eventually learned)?  How about the button to control the automatic windshield wiper mode?  I don't know either.  I leave it on manual and use the two speeds of intermittent they provide. 

-- 

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209