Switch and Checkbox items

[Daniel Nicoletti]

2012/12/13 Aaron J. Seigo <aseigo at kde.org>

> On Thursday, December 13, 2012 14:00:51 Daniel Nicoletti wrote:
> > I really don't think one replaces the other. I have switches and
> checkboxes,
> > on my Android phone and I clearly sees that depending on the context it
> > fits better.
>
> yes, on touch (such as Android type use cases) we'll be keeping both. the
> question is about desktop.
>
Tho, I'm not in favor of one UI fit's them all, I think switches on the
other hand
can make "reading" an UI easier.


>
> > For example, in print manager I used a switch on each printer,
> > since it's a device and I find more natural to turn it on/off.
>
> do you have any user testing or external research that supports this?
>
I normally keep an eye on my friends/family using the desktop to see how
they can interact with it, but nothing scientific.


>
> i wonder how well people can accurately determine if something is a
> hardware
> device or not (networking is probably a minefield) and if there is benefit
> to
> introducing additional metaphores on the already complex desktop.
>
I think it's not a new metaphore, people are already used to switches on
real life, and even on smart phones.


> personally, i really don't want to see Switches start appearing in random
> places on the desktop UI (consistency) and there are so many use cases to
> cover to know if they can be properly integrated or not. the *last* thing
> we
> need is something like "use Switches for hardware devices .. except if
> <some
> UI limitation>" leading to a mix of switches and checkboxes for the same
> kind
> of functionality.
>
Agreed, though I think it's impossible to try to hold HIG to be missused,
if we start looking at System Settings, without one switch it's quite a mess
of different UI styles... (one thing I hope to be able to help address in
future).


>
> > I don't think droping one in favour the other is the way to go. Good
> > and easy to read guidelines are.
>
> can you address the Cons i raised about this approach, namely:
>
> * Much more work for developers (one UI for touch, one for desktop, all
> because of Switch vs Checkbox)
>
> *  if we change our mind in the future, all that work needs to be re-done
>
> * relies on people caring about and implementing HIG-compliant UIs (this is
> the big problem IMHO)

Agreed, but I think it's much better to provide good guidelines than
dropping
a functionality. So:
* for instance those who like switches will just copy the QML
file and ship with their own plasmoids ( I think this is the biggest
problem )
* if people ship switches we loose bug fixes
* Most checkboxes need a good expanation text, where if you show
[||||    ] Wifi
People just recgnize it's for turning the Wifi on/off vs
[ X ] Enable Wifi
On the other hand when you have long lists of options
switches are really hard to read.

We could even do some research showing users
screenshots of both, and create such document.

Best,

-- 
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121213/b3dfff67/attachment.html>