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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
