Switches vs Checkboxes in Xfce 4.14

[Landry Breuil]

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> wrote:
>> 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