Re: next steps for touch support in GTK+

[Tristan Van Berkom <tvb gnome org>]

Hi,
   I just went through a midnight read of this thread, might as well throw some
ideas relating to the several points which have (or have not) been made.

>From a touchscreen perspective, you want to avoid spin buttons at large
cost if not all cost.

>From my experience, in the context of a kiosk type machine (think touchscreen
jukebox or point of sales unit or such), first of all you want every
touchable area
to be *at least* as large as an index finger, even then some people with huge
fingers can and will be annoyed from using the interface.

If you have a 15" or 17" monitor & touchscreen to work with, as we did, then
you will probably permit yourself some spin buttons in the
operator/configuration
screens... you wont put very many in that screen... and the up and down arrows
will appear after the entry (not on top of each other but beside eachother, as
Emmanuele mentioned that takes too much height to be usable at all with touch).

However, even then with a 17" monitor we would never allow ourselves to place
these spin buttons in any "user" screens, the operator of the jukebox
has to spend
time configuring the thing, you dont want to annoy users with spin buttons.

On a tablet, if you really really cant avoid it, perhaps you can get away with
using a spin button. On a handset, I think you can just forget about it, or
limit yourself to having only one (or two ?) spin button visible at a
time (perhaps
inside a vertical scroll window, however sliders are usually better for this if
exact precision is not an issue).

Slider widgets need special care with touch as well, specifically you want
a huge knob, and you want the indication of "where you are" to be indicated
outside of the knob and not on top of the knob (perhaps the scale widget
is an index into the alphabet, or a numerical value, you want to see that
value "outside" the knob, not covered by your finger).

Secondly on slider widgets, you generally dont want this awkward "jumping" by
page size when the user touches the trough area.

The user's intention with a scale widget is to first "get the knob"
and then make
a modification to the scroll position (Up and Down buttons positioned above
and below the scale widget are helpful for fine grained modifications).

So the correct behaviour is to allow the finger to slide into the trough area
without modifying the scale value and allow the finger to "Enter" the knob
area... once the finger has entered the knob's area then the knob should
stick to the finger and move with it.
  a.) It should not "jump" unexpectedly towards your finger
  b.) It should not require that your finger cause the "button-press-event" to
       occur on the knob, it should instead be tollerant and allow the finger
       to slide into the knob area and control it.

The slider behaviour is also very critical when the slider is controlling
the master volume (of your home stereo system or whatever it is), of course
you dont want the volume to "jump" up just because you missed the knob
initially when trying to "catch" it).



On "bastardising" the toolkit to get touchscreen support in GTK+, I personally
never thought this was the point to touchscreen support in GTK+.

It will definitely be useful if for instance, GTK+ makes some things possible
on touchscreens which were not possible before, perhaps panning mode
in scrolled windows is a good example, at least some features in basic
widgets that you *need* in order to extend your UX to touchscreens.

One thing I'm most certainly convinced of is that applications (or their
user interfaces) will be written separately for touchscreen devices.
You wont be able to ship exactly the same code on a touchscreen
enabled device, set the gtk settings touchscreen mode = TRUE and
just hope for the best... that will never happen, or perhaps I'll just have
to see it to believe it.

So yes I think it's completely logical to build a widget kit on top of GTK+
which is particularly suitable for touchscreen environments, in any case
its what people will do (write custom widgets for touch in their own
applications).

I also believe that a GtkSwitch is programaticaly interchangable with a
GtkToggleButton, and it's a bit confusing too... when one changes a toggle
button to look "switchy" then one potentially needs to actually change code
(i.e. that vfunc which I was overriding in togglebutton no longer compiles
when I derive from switch ? ... I changed it for a switch and now
GTK_IS_TOGGLE_BUTTON() fails for a switch ? can I connect it
to that toggle action which I've been proxying my toggle buttons through
like before ?... definitely seems awkward).

Then again that's not really worth arguing, there wont be an api break till
GTK+4 anyway so...

Ok long night... food for though... lets sleep on it guys ;-)

Cheers,
            -Tristan


On Sat, Aug 4, 2012 at 8:15 PM, Simon Feltman <s feltman gmail com> wrote:
> Toggle buttons and the switch widget both suffer usability problems for me.
> The visual look of a button represents an action to be performed in my mind,
> perhaps why it was referred to it as a soft-action? So when a button is
> stateful it can create ambiguity depending on the text of the button. The
> old, "Does it perform the action shown on the label or does the label
> reflect the current state?" This causes dissonance in my mind which can
> hopefully be resolved by the widget having another visual indication of the
> state (the depressed look). A typical example of this failure is with Glades
> usage of toggle buttons on a selected widgets properties (don't mean to
> offend anyone here, just stating my experience!). This is further confused
> by the text changing when you press the button to Yes or No.
>
> Moving on to the switch widget, I think it mostly suffers the same issues
> I've described. Does the text on the switch widget represent the current
> state or the action of setting the state to on or off. Again the visual
> indication barely saves me here (having it highlighted to blue). Given this,
> the visual indication aside from the text is what I use to determine the
> state of either a toggle or switch. This makes me think the text on the
> widget only confuses things and the widget could simply be a checkbox which
> would resolve all visual ambiguity. However, I do see value in what is
> described in the UX guidelines regarding the switch widget and associating
> it with things that take time (not just a simple checkbox state). The
> guidelines also don't describe explicit styling of the switch which is my
> problem with it. I think the visual ambiguity could easily be fixed by
> showing both available states, looks like it is already being discussed
> here: https://bugzilla.gnome.org/show_bug.cgi?id=644658
>
> -Simon
>
> On Sat, Aug 4, 2012 at 8:47 AM, David Nečas <yeti physics muni cz> wrote:
>>
>> On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote:
>> > one implies a "soft" action (GtkToggleButton), whereas the other
>> > implies something similar of a hardware switch (GtkSwitch).
>>
>> As every user knows, widgets relay wishes to magic pixies.  I wonder if
>> that is soft or hard action, maybe it depends on how hard you need to
>> beat the pixies to do what you want.
>>
>> Do you actually expect different kinds of on/off controls to be mixed
>> wildly because each was selected based on how soft is the action it
>> implies?
>>
>> > they both
>> > have their use cases which are not interchangeable:
>> >
>> > https://live.gnome.org/GnomeOS/UX/Guidelines/SwitchWidget
>> >
>> > the page above should become part of the new Human Interface
>> > guidelines/design patterns. not every application should use switches,
>> > nor existing applications should be mindlessly migrated to moving from
>> > toggle and/or check buttons to switches.
>>
>> All cases listed there as good use cases of GtkSwitch would be – for me
>> – improved by using a plain toggle button.
>>
>> It would take less horizontal space, it would be less wordy, it would
>> not leave me wondering whether it shows ON when it is on or whether I
>> should move it to ON if I want it ON (yes, I still do not remember it),
>> it would not look trendy, and it would not have translation issues.  In
>> fact, even the ‘wrong’ checkbuttons would represent an improvement for
>> me.
>>
>> I would also say the widgets are completely interchangeable, but forced
>> to interpret the statement ‘their use cases are not interchangeable'
>> somehow I would have to conclude that GtkSwitch has no meaningful use
>> case at all.  Could the page be improved to include this?  In my opinion
>> it could lead to a considerable simplification of the guidelines.
>>
>> > the short takeaway is that the switch should be used in specific
>> > cases, and that the way its been defined as a widget does not allow
>> > inheritance from GtkToggleButton or GtkButton (no label, no children,
>> > styling of trough and handle).
>>
>> I am sorry but, again, this is just a recapitulation of the status quo.
>> Stating it a hundered times does not make problems vanish magically even
>> if you beat the pixies really hard with a switch.
>>
>> Yeti
>>
>> _______________________________________________
>> gtk-devel-list mailing list
>> gtk-devel-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>