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.felt...@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 <y...@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 > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list