Switches vs Checkboxes in Xfce 4.14

[Steve Dodier-Lazaro]

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>
> 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
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>



-- 
Steve Dodier-Lazaro
PhD Student
University College London
Free Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160506/85c365ac/attachment.html>