Switches vs Checkboxes in Xfce 4.14
landry.breuil at gmail.com
Sat May 14 16:27:12 CEST 2016
For all the panel plugins that are ported now (datetime, systemload,
netload, smartbookmark, fsguard, diskperf, wavelan, mpc...), they're
ported to Gtk3 in their master branch on the main repo.
On Fri, May 6, 2016 at 9:57 AM, Steve Dodier-Lazaro <sidnioulz at gmail.com> wrote:
> Hapy to do that if I actually knew where the GTK+3 branches for each project
> are :-)
> On 6 May 2016 at 08:13, Landry Breuil <landry.breuil at gmail.com> wrote:
>> Less talk, more patches... there's no point discussing this without
>> actual *examples* of Xfce dialogs with switches/checkboxes.
>> On Tue, May 3, 2016 at 4:25 PM, Steve Dodier-Lazaro <sidnioulz at gmail.com>
>> >> Hi Steve,
>> >> are the sentences "I propose we stick with that interpretation and keep
>> >> checkboxes everywhere in the settings UIs." and "The Accessibility
>> >> settings dialog is a good example of where we might want switches."
>> >> contradictory? Anyway, could you elaborate why you think that Switches
>> >> are a good alternative in the accessibility dialog? Is there a benefit
>> >> (UI/UX-wise) in using them?
>> > There, I tried to be concise in the conclusion and removed too many
>> > sentences.
>> > I prefer we stick to the Google Material interpretation: all forms with
>> > multiple settings use checkboxes exclusively. Switches are used to turn
>> > on
>> > or off a service / feature which is a permanent component of its own
>> > (e.g.
>> > the a11y services, the power manager, the compositor). In Xfce these are
>> > often at the top of a settings UI and enable/disable the entire UI's
>> > content.
>> > We absolutely don't need to adopt switches. We're fine as we are.
>> > Adopting
>> > them could help users differentiate the important components (those who
>> > have
>> > a significant impact on their experience) from the behavioural details
>> > and
>> > could help provide a clearer visual hierarchy (where we used
>> > GtkAlignments
>> > and widget sensitivity so far). So there is a small benefit.
>> > Now onto the drawbacks. As pointed out by Matthew, GTK+ 3 is designed
>> > exclusively with touch devices in mind. Ultimately, the experience of
>> > the
>> > switches would depend on the themes used by users and on the quality of
>> > the
>> > keyboard interaction.
>> > Regarding themes: We should provide state information by making sure
>> > that we
>> > only use switches in UIs where the current state is unambiguous, and we
>> > should require friend/official themes to not display state labels like
>> > ON/OFF or I/O to avoid state-action ambiguity. Rather, they should go
>> > for a
>> > design similar to Material where the state label is not confused for the
>> > outcome of taking an action. We should also ensure that the colour code
>> > used
>> > to indicate state in the switch does not have another meaning in our UIs
>> > (I
>> > think we're clear on that so far in Xfce). Xfce users tend to use Numix,
>> > Arc-Dark, Greybird and a few other themes, so if we can agree on graphic
>> > design guidelines among those themes I would be keen to use a few
>> > switches.
>> > Regarding keyboard interaction: it is not thought through, as pointed
>> > out by
>> > Matthew. Yes, left/right is the immediate action that comes to mind and
>> > sadly it does not work. We would need to get the GTK+ devs to agree with
>> > us
>> > and change the switch before we go into production with it. This is not
>> > very
>> > likely to happen. I'll go and test the waters in #gtk+ right now.
>> > Best,
>> > --
>> > Steve Dodier-Lazaro
>> > PhD Student
>> > University College London
>> > Free Software Developer
>> > _______________________________________________
>> > Xfce4-dev mailing list
>> > Xfce4-dev at xfce.org
>> > https://mail.xfce.org/mailman/listinfo/xfce4-dev
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org
> Steve Dodier-Lazaro
> PhD Student
> University College London
> Free Software Developer
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
More information about the Xfce4-dev