Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

Carsten Haitzler (The Rasterman) raster at rasterman.com
Sat Oct 31 01:49:00 CET 2009


On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber
<matthias.huber at wollishausen.de> said:

> Laszlo KREKACS schrieb:
> >> To not confuse with window changing, I would suggest the following
> >> scenario:
> >> 1. double click for launching an app
> >>
> >>
> >> why double click ? for me, i am using double click for a menu and a single
> >> click for starting the app.
> >>     
> >
> > Because when sliding, you can have accidental clicks. I know it from
> > the hard way.
> > (I came up a nice usability workaround in paroli exactly for this
> > issue. It works good.)
> >   
> yes i know this also from paroli. but it is solvable i think.
> 
> openbox has a tunable parameter for distinguish between slide and click.
> in my oppinion, this is highly usable.
> 
> i personally find a single click more elegant and usable than double click.

the problem is not differentiating between slide and click - e and elementary
have this too. it's that if you drag horizontally for example, your actual
events often look something like:

+----+ +--+ +--+   +-----+ +    +-+    + +------+ + +   +   +---+

if you dont press firmly with a sharp point (stylus, fingernail etc.). you can
go to every app and start trying to add filtering to close such gaps, but now
you duplicate that code everywhere. IMHO tslib/x should filter it so the input
to clients is the "intended input" by the user. also you will have unintended
clicks (drawing press/release over time):

+ +-----+ +-+

you pressed just once - or you think you did. but you actually had a press, a
release, and a press , release etc. again because your pressure went above,
below and above the "pressure level" needed to register a click.

imho there should be some filtering on the input events that patches these
gaps. and that filtering should go in x or tslib. capacitivie screens are much
more sensitive and have a different problem - but their events are filtered too
as you dont get a point - you get an area that is pressed, so they have a
hysterisis on how big the area has to be first to start a press registering and
then it has to get much smaller that this area to stop. eg:

press start @ 8x8 pixels, press stop at 3x3 pixels. as long as your press area,
once registered, is >3x3 pixels, it will continue to be "pressed" until it gets
below.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com




More information about the community mailing list