Switches around the world and broken metaphors [Was: Battery Monitor revamp]

Wed Jul 3 09:40:02 UTC 2013

Am Sonntag 26 Mai 2013, 18.07:14 schrieb Thomas Pfeiffer:

Morning

Added the below content to a new page about Repeated Discussions in Plasma:
http://community.kde.org/Plasma/RepeatedDiscussions/SwitchesVsCheckboxes

Hope that's ok.

Thx
Mario

> On Sunday 26 May 2013 00:05:56 Marco Martin wrote:
> > On Saturday 25 May 2013 14:32:29 Martin Graesslin wrote:
> > > > And this is clearly the case let's work around something we don't
> > > > want to
> > > > fix. Switches are a clear improvement over checkboxes depending on
> > > > the context even my 60yo mom got it much quickier than a checkbox
> > > > would be able
> > > > to on my plasmoids.
> > > 
> > > And I would completely fail to use the switch. I have huge problems
> > > understanding those switches and I have not seen any implementation of
> > > the switch where I got which one is on and which one is off.
> > 
> > that's for me as well.
> > I have to spend a second or more every time to figure/remember if the
> > "on" that is written on the switch (or being colored vs greyed, same
> > thing) means "it's on now" or "it's an action, so it's telling me it
> > becomes on if i click on it"
> 
> Well actually, there is an easy way to make it absolutely clear which is
> which, although it takes lots of horizontal space and probably looks very
> ugly if you have many switches in the same UI: Just add text labels on
> each side, _next to_ the button, not inside of it. E.g. "OFF" or "O" on
> the left side, "ON" or "I" on the right side. That makes things perfectly
> clear.
> So if ambiguity is the only reason against using switches on Desktop, we
> should use them. If you can make it clear on a touch screen, you can make
> it clear on a normal monitor. However, there may be more reasons than
> that.
> 
> Let us look at the issue more closely. First of all, switches are _not_
> merely the "touch version" of checkboxes. Some developers may use them
> that way, but they are not. They should be used for different purposes,
> and the GUI guidelines of systems that have both do make that clear
> (though interestingly, the decision criterion varies from platform to
> platform:
> 
> - The Android design guidelines make the following distinction: "Checkboxes
> allow the user to select multiple options from a set. Avoid using a single
> checkbox to turn an option off or on. Instead, use an on/off switch."[1]
> 
> - The guidelines for BB10 go in a similar direction[2]:
> "Use check boxes when users can select multiple items or options."
> "Use a toggle switch when users are choosing between two distinct options,
> such as Off and On. You can also use a toggle switch if you want to make a
> setting harder for users to change accidentally."
> 
> So according to the Android or Blackberry guidelines, the Battery Monitor
> should use a switch, whereas the Printer Manager should use checkboxes.
> 
> - The Meego UX guidelines[3] (yes, Meego is dead but that doesn't mean
> their guidelines are bad) say the following: "Toggle switches are best
> used in system or applications settings, and are best suited to toggle a
> setting or mode that affects the whole system. Good examples are switching
> networking or silent mode on or off." "A checkbox works in the same way as
> a toggle switch, but it is more suitable to use for smaller settings, like
> a preference in an application"
> 
> So these guidelines would speak for using a switch in the Battery Monitor
> as well. Regarding the Printer Manager, it would be a question of
> interpretation.
> 
> - The Windows Store apps guidelines[4] offer a distinction which I
> personally find the most logical: "Use a toggle switch for binary settings
> when changes become effective immediately after the user changes them."
> "Use a checkbox when the user has to perform extra steps for changes to be
> effective. For example, if the user must click a "submit" or "next" button
> to apply changes, use a check box."
> 
> The reason why I find this logical is that it relates to the real-world
> equivalent of checkboxes and switches. When I flick a switch, usually
> something happens immediately. On the other hand, checking a box on a
> paper form does not immediately change anything, it only has an effect
> after I _submitted_ the form somewhere. And this is similar in the digital
> world: Checkboxes first appeared on digital forms, where changes only went
> into effect after the form was submitted. Therefore if we only use
> checkboxes for changes without immediate effect, users can be sure that
> changing the state of a checkbox won't do any immediate harm.
> 
> According to these guidelines, both Battery Monitor and Printer Manager
> would use switches.
> 
> So conceptually there is indeed a difference between a checkbox and a
> switch. Now, with that said, comes the big "but":
> All of these guidelines are for touch-based OSes. Looking at the guidelines
> for mouse/keyboard systems from the same vendors reveals a different
> picture.
> 
> Neither the OS X Human Interface Guidelines[5], nor the GNOME Human
> Interface Guidelines[6] (Toggle Buttons are not the same as switches!),
> the Microsoft guidelines for desktop applications[7] or the ChomiumOS
> guidelines[8] contain any mention of switches. They all have only check
> boxes.
> 
> So why is that so, even though the criteria for using switches instead of
> checkboxes would apply in the desktop world as well? Unless someone here
> knows someone in the respective teams at these companies or digs up a blog
> post explaining the decision not to introduce switches in the desktop
> world, we can only speculate.
> One reason is surely that flicking a switch on a touch screen, though not
> "natural" at all because of the lack of haptical feedback, is much closer
> to reality than flicking a switch by clicking it with a mouse.
> Another reason is surely that accidentally clicking a checkbox with a mouse
> is much less likely than accidentally tapping it on a touch screen (which
> the BB10 guidelines mention as one argument for using a switch and which
> is also underlying the guideline from Microsoft).
> 
> Sure, Metro apps would display switches on the Desktop as well, and so does
> GNOME 3, but that's only because they're trying the "One size fits all"
> approach, which Plasma explicitly does _not_ adopt (and if we look at the
> "success" of Windows 8 so far, I think that's a good decision). In their
> guidelines specific for desktop applications, both do not mention switches.
> 
> > to me that slowing down is consistent, and that's what makes a broken
> > paradigm. maybe is not like that for everybody (it may indeed depend from
> > power switches in europe looking completely different).
> > but i would like to see a real user test statistic prior to reevaluating
> > them in any way.
> > 
> > on touch they became so universal that's probably fine (and interacting
> > with it with touch is a bit more natural)
> 
> I've read from a few users in the PA community on G+ that they don't
> understand the current switch in PA either and I think it could still be
> improved even for touch devices.
> 
> > on the desktop they should really never be there (btw, in 4.11 on the
> > desktop switch will look exactly like a checkbox)
> > 
> > and last, the use of one or another should not depend from the choice in
> > the application, we have too many inconsistencies already without
> > introducing new ones
> 
> So, to summarize: The industry has mostly adopted a distinction between
> checkboxes and switches in the mobile world, but sticks with checkboxes
> only in the desktop world and I see no compelling reason for being the
> only environment that has switches in desktop-only UIs.
> 
> And If a developer works around the standard to display switches in his or
> her desktop UI, that UI should not become part of Plasma Desktop, unless
> we agree that we want switches in general (for a reason yet to be brought
> forth).
> 
> I hope this input helps taking the whole discussion to a more factual
> level. Cheers,
> Thomas
> 
> 
> [1] http://developer.android.com/design/building-blocks/switches.html
> [2] http://developer.blackberry.com/devzone/design/bb10/components.html
> [3] https://meego.com/sites/all/files/users/admin/meego_touch_ui_v1.2.pdf
> [4] http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx
> [5]
> http://developer.apple.com/library/mac/#documentation/UserExperience/Concep
> tual/AppleHIGuidelines/Controls/Controls.html [6]
> https://developer.gnome.org/hig-book/stable/controls.html.en
> [7] http://msdn.microsoft.com/en-us/library/windows/desktop/aa511482.aspx
> [8] http://www.chromium.org/chromium-os/user-experience/ui-elements
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel