I have spent the last two weeks working to make print-manager experience in 4.11 the best I could. And this post should be about it. Sadly it’s not.
Whenever I write free software I write because I want to, because I have the need and since I don’t paid to do this I spend the time I can. Besides the selfishness I value user feedback a lot, Apper is an example of user feed back, not perfect yet but lots of things there changed because of this, yet sometimes one has to take a final word.
There has been some noise over the last years about “not invented here”, forks and diversity. People blame the Linux ecosystem of having no direction, no focus and hence failing on the Desktop. But they forget to remember that even Countries with much more control were divided because people are different. Heck yes everyone is different so there is no way of pleasing everyone, and this is what I like in Linux.
I’d rather be using OSX if it wasn’t for that, really OSX has awesome applications, iPhoto, Mail, Finder… and now I even have a MacBook, I could instead be build OSX apps and making money! Why don’t I use it?
Because I can’t change it. No matter how good it is for lots of people, it’s not good for me at several points. And heck our Desktop if much far from what I wanted a Desktop to be but still I can help changing this and have lots of fun.
So why am I sad? Simply because I’ll need to fork a component which I was actually willing to improve, and no it’s not because my improvements were rejected or ignored, but because some people don’t like Switches. Yes, you don’t like it either? Fine, but take a look on what has just happened:
Now think for a moment what is that checkbox trying to tell you
- Cable connected [Check]
- Output enabled [Check]
What about these?
Easy, that’s the list of printers I want to go shopping 🙂
No I’m not questioning if you like switches better that checkboxes, I’m fine if you do, I’m questioning the API that was changed post freeze, without being listed on the feature plan and that has just given me more work to do.
A checkbox must have a description text unless it’s a list of things, even then it is bound to some action normally described with a text or an icon. So even if I was ok with the change I’d need fixing this at soft freeze.
Yes I could instead just fork the component and don’t waste time writing a blog post. But as mailing list didn’t work out (I raised my points on three different threads and suddenly it got commited) I’d like to hear what users of printer-manager or kscreen or any application using Switches think about.
Granted I’ll keep the switches there, hopefully I’ll manage to find time to write a better one as I agree with the fact that this one is indeed confusing. But not because it’s confusing that we should replace instead of fixing.
And let me apologize for making this public, but we ain’t an evil company that must hide into mailing lists. I believe users should be able to give feedback even it goes to /dev/null.
This is my personal opinion.
and that being said I must say I’m very sad, really.
UPDATE: I have changed this text a lot trying to make it not sound like a personal critique or FUD. But then I didn’t notice I removed the last sentence which was the actual reason of this post. I did notice some users a bit confusing about what was the conclusion but only now I see the text got lost (as you can notice on the text above I did mention feedback but what feedback?)…
So the question was “How do you feel with these screenshots, do you think if a plasmoid is written for Plasma Active where switches are allowed, they can run as checkboxes on the Desktop (with no change)?”
In other words “Does my plasmoid on the Desktop looks fine now? So that I don’t have to actually create an specific version of it for the Desktop.”
IMO taking the decision apart which is not what I planned to change (as I know it wouldn’t just because of blog) I think simply replacing a switch with a checkbox without any change is not sufficient for the applications. All the work I do on System Settings module use QWidgets and though I love switches and feel that there are at least two modules that I maintain that could have them they don’t have switches. The reason is simple, there is not QSwitch or KSwitch, they never existed so I never intended to write one as I’d simply look different, once Plasma started shipping one on their API I was very happy and when programming with QWidgets I envy the Plasma for having it….
Dantti's Blog 
Was this decesion made by a vote? From the Printer Plasmoid, it looks like the problem was already solved. The disabled printers are greyed out. Perhaps you guys can emulate Android’s behavior where the switches will have the word “On” or “Off” depending on their state:
http://developer.android.com/design/building-blocks/switches.html
In my opinion, having text on switches can be rather problematic. You either always have to use “On”/”Off”, which has 2 issues: It’s not always the most suitable word, sometimes yes/no or enable/disable might fit better, though you could dismiss this as a violation of the switch semantics. More importantly, it’s always English text – and not everyone is speaking English, so even words as simple as On/Off might be confusing.
Alternatively, you make the text on the switch customizable, or at least translatable. Then you have to take care that the switch scales to different word lengths, which (IMHO) makes finding a good design rather hard.
Agreed, but since you don’t put text on switches and then they suddenly show up as checkboxes people are more confused than before.
About the On/Off issue well, where I live (where english is not our language) I see on/off on devices everywhere. But I’m more in favor of I/O for on and off like this: http://s582.photobucket.com/user/netbookc/media/XB1/XperiaSICSFirmware_12.png.html
I agree fully that the change from switches to check boxes in these two cases is a poor choice. The switches can be improved instead.
There is no need to use the words on and off or anything that needs translation. There are standardised symbols for power switches, even distingushing between a button that switches the power on and off and a button that swithces between active mode and sleep mode. Look at http://en.wikipedia.org/wiki/Power_symbol
I thought about using those, but since there’s no real poweroff or standby I don’t think the fit, a Switch can be a clear toggle for enabling disabling devices without the need of text.
Even better! I can’t believe I didn’t think of that since I just finished a digital signals class.
I absolutely utterly _love_ switches, which I personally consider a much better choice compared to check boxes, both aesthetically as well as functionally! I also feel sad about the respective decision 😦
And I absolutely _hate_ switches. THere you have it ^^ Checkboxes are much easier to interpret. Switches force me to toggle them to know which state they’re in because they are themed – people use different themes and color themes you know.
Hi, how can I make KDE switch automatically to external LCD monitor when plugged on my notebook plugging VGA cable? I want single output (not dual)
This is really not the right place for this, but doesn’t that mean if you accidentally unplug the VGA cable, you’ll be left with no output?
well he probably would have his screen jump back to his notebook, when that happens…
Well, that doesn’t answer your question, but the reason why that is not the default is that the most common use of notebooks’ VGA outputs is to hook them up to a projector, in which case you definitely want both the projector and the notebook to show the same thing.
Have you made some kind of data analysis for saying that?
Where I work (and in my past workplace) VGA output is used to connect a supplementary monitor, not for projector…
I was always finding the switches very confusing(especially on mobiles devices), but checkboxes are so ugly, like something coming from windows 95 (though switches are also not that good). So in this case I’d better have switches.
Then one should make checkboxes look nicer.
I think every tiny changes should be fully documented with a reason it was done. User’s should be informed of everything. The HCI knowledge of KDE should be “open” too.
Thanks for your post.
BTW, i prefer checkboxes ;D
You make it sound like it was decided on a whim: regardless if it is good or not, you have to admit that the issue *was* discussed in the plasma-devel ML. And it was not just the “plasma developers” to support the change, but also other workspace devs as well.
FWIW, I found those switches in print-manager to be fairly out of place.
My point is not about them being good or not, my point is about breaking applications using them. I’m ok with people thinking differently.
Introducing widgets designed for touchscreens (they should be flicked with a finger) to desktop components in the first place is the breaking part. That’s why Gnome 3 looks so cluttered in some windows despite only a handful of options available.
I don’t think a switch is more designed for touch screen as a button is for a desktop, every component resemble something in the real world. Look at sliders, you have to drag them to move the same way you need to do for a switch. But anyways that’s your opinion and I’m I just don’t like forcing a “solution”.
Frankly, I think that if that forced solution were switches, you’d like that very much.
No, I wouldn’t see my last comment.
Hi,
I think it’s more about coherency in the shell. Checkboxes or switches, but not both in the same shell.
To me they cover different use cases. And there is no coherency if you break applications.
I agree with the different use cases argument:
Checkboxes for enabling options.
Switches for turning things on/off.
Screens are really turned off (at least set in standby mode), so a switch is appropriate. Of course a switch could be something different from a slider, it could be a button that used 3D effects to show it was pressed, but I think a flick-switch like you have used makes it easier to see if it is on or off. Just add the standardised symbols and you’ve got a good representation of the real thing.
The printers are not turned off or set in standby mode I suspect. That use case is slightly different, as the printer queue is only set on hold/paused. Perhaps using pause abd play symbols would be appropriate? The flick-switch could still be applied.
A two-state check-box and a two-state flick-switch has the same functionality, but to represent switches the check-box should be displayed as a button using symbols, and the mentioned power symbols and the pause/play symbols are standardised and understood all around the globe. No point in reinventing *that* wheel.
I’m confused as to whether you personally approve of the change to checkboxes or not 🙂 its not clear from your psot.
Myself – I’m conflicted on it. I liked the look of the switches – they are sexy, but I also find them confusing as to their intent and state, when ever I encounter them in new apps its rare for their function to be clear without activating them. In that regard checkboxes are much more straight forward.
Agree there appears to have been little consultation. Misssed the discussion altogether.
I don’t approve since I use them, and like them. I agree the ones we have are a bit confusing (the one on my Xperia phone is just perfect imo), that’s why I was suggesting that their usage should have guidelines and the component it self could have some improvement.
Hi,
As a simple user of printer-manager, on a desktop, I really don’t see the point on using switches insead of checkboxes. I find the checkboxes more elegant and intuitive, and the switches are rough, and confusing. In real life, you see checkboxes on every questionnaire at school, on the tax return, etc. You don’t see switches at all.
Maybe it’s just resistance to change, maybe it’s bad ergonomists…
In real live you see switches to turn on/off your printer. Which is why I think they are perfect for hardware enable/disable.
But this is not a real life printer switch.
Devs use those switches because Apple introduced them in iOS. And when in 2 weeks the new versions of iOS and OSX will be introduced – the first versions Jon Ive as design lead supervises.
Jon Ive dislikes “realistic” looks and the new versions will throw many “realistic” looks out of the window.
That’s actually predates Apple use, but it was not common, I disklike realistic too, but denying the metaphor is like saying throw everything away, be it a folder, a button, a switch, a checkbox basically every thing with an icon tries to resemble real world.
Well, in my case, it’s not a very good example : I got this printer:
As you can see, the button to turn on/off is closer to a checkbox than a switch 🙂
Anyway your point on saying switches cannot always replace checkboxes seems right to me.
Great, you know what my printer power looks quite a lot that one, so if instead of a checkbox I have a circle button with glow inside them when it’s enabled with that I inside the O you can totally switch my switchers 🙂
Do those software switches physically turn off the printers? If not, your metaphor is misused.
I don’t deny that switch widgets predate iOS. I wrote that many other projects only started to use them after Apple introduced them to iOS. Older versions of Android don’t have switches. Gnome 2.x doesn’t have switches, and early Plasma versions didn’t have switches (and Plasma only gained them for Plasma Active which targets the same device formfactor as iOS).
Once Apple under design lead Jon Ive throws skeuomorphism out of the window, all others will follow once again – obviously with the usual 5 years delay.
The entire idea that software widgets have to resemble physical objects, is so 1980s anyway. People are so used to GUIs these days, the entire argument for skeuomorphism is gone.
Why would a hardware switch be a good metaphor here? You can’t turn on the printer with it. So why should it look like you could?
Personally I’m often confused by those switches. It’s often not easy to understand what they actually do or what their state is. Or even how you use them. Do you have to click and drag the switch? Real switches cannot be clicked and dragged. They really make no sense with a mouse.
Disabling a printer from receiving jobs and actually turning it off has the same effect.
A wifi switch has to be slided by my finger just like a volume slider.
I guess I’ll just reassign all kscreen reports about the button being ugly in 4.11 to whomever changed it.
I’d also like to hear from Plasma devs what they think is a suitable replacement for the switchbox that has no text label yet is clear enough what it does. This checkbox is totally /not/ a suitable replacement (for KScreen case).
Funny enough looking at both print-manager and kscreen IMO kscreen is the one that got worse, you can somehow assume that checkbox is to enable/disable the printer but on the monitors output you simply have no clue at all.
What about a checkbox with ki18n(“Enabled”) as the text? Don’t worry about string freezes, I’m fairly sure “Enabled” is already covered by kdelibs translations and so will get picked up from there anyway.
Personally I do not like the switches. I do not have a touch screen and that is what they were obviously made for and I do not think they belong on a desktop. I wanted to file a bug report about them, suggesting to change that. But I did not, since I couldn’t suggest an alternative. These checkboxes obviously aren’t. There must be something else, but I do not have a clue.
IMO you don’t need a touch screen to have a switch, you have a TV with buttons then buttons on UI, you have toys with switches, even laptops with wifi switches so switches on the UI. My support them is mostly for hardware.
Personally, I prefer checkboxes. When I see the switch, I am never sure whether it is currently enabled or disabled – only once I saw both states and notice that enabled has this blueish background, I know what position corresponds to that. The fact that the switch is on the left, doesn’t tell me it’s disabled. Furthermore, each time I see such a switch, I have the feeling of using a UI designed for touchscreens, it looks out-of-place when using mouse and keyboard. It even looks as if I have to drag’n’drop that switch to toggle it – I assume that’s not the case and you can click it, but still just from the look, it looks like it needs dragging.
It’s very similar to how I dislike this scrollboxes-bounce-beyond-the-end effect on my desktop machine. It just looks very out of place, I expect one “scroll tick” to move the list by a certain amount of pixels/display space (this can me done animated, as in smooth scrolling, if needs be), not to have some kinematic effect as if I physically dragged something around and this something was fixed with springs.
This general development makes me a bit worried. We have some really well established metaphors on the Desktop, how to handle some common UI options so people don’t need to think about how the program will react. The first touch devices tried to use the same metaphors and failed utterly. Some years ago, it was finally understood that these metaphors do not work when using touch interfaces. Now however, people try to push the the touch metaphors to the keyboard-and-mouse interface, which I think is just as wrong as the other direction. Microsoft just failed utterly with Windows 8 and trying to force mouse-people to use gestures designed for touchscreens. Plasma moves to the touchscreen (great), but instead of specialising components for both UI paradigms, the desktop is changed. How long will it take people to understand that we simply have to keep two different sets of metaphors here?
Just my .02€.
lol at the .02€.
How do you feel about sliders? They are exactly like Switches, you don’t know when it’s min or max, and you have to drag them, you also have to drag scrolbars, the fact that you can’t drag a Plasma Switch shows only one thing, it needs fixing. It must support that the same way a Slider does. And the state should have text to help on the on/off, especially for disabled people.
On the other hand, where Microsoft failed Apple didn’t OSX has lot’s of gestures but they didn’t force the use of those with a mouse, instead they created a touchpad (Trackpad) where you can do lot’s of cool gestures, and people really like it, then microsoft which doesn’t build hardware (ok they do but not most of the PCs in the world) expect it’s users to do gestures with a mouse…
In the end I think everyone is right, switches have it’s problems, just like checkboxes have without text, or a slider without text, and so on…
Switches don’t work for colorblind people, checkboxes do.
They do once they have text, which is what is currently broken with the plasma one.
Then don’t insist on using broken widgets.
I hate sliders, but in most cases it is obvious what min and max is, because they are labled. And you know that right / up means more. On / off for a switch is less obvious.
There’s no max/min label on KMix or any oxygen QWidget slider. So why does one older component can be ambiguous and a new one can’t?
neither is user-friendly without a minimal label/text.
I remember this plasma-devel threead dated back dec 2012 worth reading
http://mail.kde.org/pipermail/plasma-devel/2012-December/022955.html
cheers, thanks for your much appreciated work!
Yes, if you follow that thread it was the first one I jumped in. Till then it was no decision made.
1) KScreen should not be using Plasma Components inside a widget anyway
(it’s both inconsistent AND you’ll screw the colours up)
2) You should not have been using Switches for status feedback, when they are synonymous with a checkbox i.e allowing the user to switch between two states.
That’s the sort of inconsistency this change is designed to avoid. To stop people accidentally misusing a widget.
1. Because you can’t talk and convince a developer then let’s break his work?
2. It’s not status feedback, you can actually disable the printer there.
To stop people misusing a widget the only right way is to create proper documentation. Still that’s you personal opinion which I respect but I and others think differently.
I haven’t used your printer applet, (I have a fair excuse, I don’t own a printer)
I had misunderstood your text to assume you meant you were using them as status labels which checkbox doesn’t cover. My bad.
FWIW, here’s an archaic bug on the matter:
https://bugs.kde.org/show_bug.cgi?id=302067
Not sure why the bug hasn’t changed since it was patched….
No matter how old is that bug. The API shouldn’t change without proper notice. Actually the second comment is what should have happened (even if I don’t agree with the removal) but didn’t. Should I just fork all components I’m going to use to be future proof?
And if we follow that bug then let’s remove Toolbuttons (same functionality as a push button), then remove a combobox (same functionality of a small list view), then remove radio buttons because they cover the functionality a combobox had….
I think switches look slightly nicer, but checkboxes are more functional. (with switches, I sometimes have trouble quickly recognizing if they are enabled or not.) In the end, I’m fine with both. In any case: Thank you for your good work. Please keep up your good spirit and do not fret too much about such small issues.
No disrespect but you have a history of starting to develop an application and then dropping it in an unfinished state because you found something interesting. See Apper for example: development practically stalled (every half year a rather minor release so far) whereas Muon 2.0 gained plugable back-ends in the mean time and these days has a more polished UI.
My personal, humble opinion is that I’d rather see more concentrated development on on or two components (because you do awesome work!) instead of you working on yet another project because of cosmetics like switches.
If you like switches so much, why don’t you just modify the Qt widget theme and make every checkbox look like a switch?
I’m not working on yet another, I’m the main developer of print-manager, it’s 3 years old now. And yes I like to code different stuff.
Do you know why Apper has stalled? Because we are working underground to improve PackageKit/aptcc so that it can actually become a software center, now PackageKit is fixed (thanks to Matthias) now I need to make aptcc use it’s features but that’s not entirely easy as forking and doing IPC right is not very simple.
An no, I don’t like Switches that much, in fact I’d be upset if someone did that, look at Apper plasmoid there’s not a single switch because they don’t belong there. Checkboxes are much better in that case. And yes I miss a QWidget switch I can only envy GNOME right now…
You state in your blog post that you “need” to fork a component. From the context it seems that now a KScreen fork is under your umbrella as well.
And if you work on PackageKit code: Great! Provide a PackageKit back-end for Moun 2.0 and let Blue Systems handle the front-end.
But you don’t do that and now you “need” to fork a component because of stupid switches.
I’m very sorry to be that blunt but that is NIH syndrome in action.
No, KScreen is not under my umbrella.
Yes, I’m the author of the aptcc backend and I have introduced a bunch of features to PackageKit core.
And no, I won’t write a backend for Muon 2, there is packagekit-qt lib which I maintain that as well, and I’m totally open if they want to use it, but they decided they wanted to do what I was doing (instead of giving a hand) and I’m fine but I’ll keep my code and improve it when I can.
NIH would be if I had to create a replacement for the current switch to fix it’s non existent issues. I’m not going to create a new thing, just copy the current and disable one and maybe improve it.
What exactly is the component you “need to fork” then?
And btw, your attitude towards Muon is exactly NIH. If the rest of the KDE community had the same, KHTML would still be used everywhere. Luckily most other KDE contributors do not insist on “I was first, so everybody has to support my project, no matter if other projects overtake mine or not”.
It’s Muon’s attitude towards Apper which was the NIH. Apper was there first.
And it would be a GOOD thing if KDE were still using KHTML throughout. Instead, we now carry 2 forks of the same code for the same purpose in KDE (and distributions as a whole can have up to 6, counting also kdelibs3 KHTML, webkitgtk, Chromium and qt5-qtwebkit; and will there also be a KHTML in KF5? That’ll make 7).
And last I checked, Muon didn’t work with RPMs at all, so it’s no option for Fedora anyway.
Kevin, please read again. I wrote explicitly that though Moun came later, it now surpassed Apper. Yes, the Muon devs could have and should have improved Apper instead but now it’s too late. Muon is here and it is better than Apper.
I also wrote that Muon 2.0 has plugable back-ends. Porting Apper’s PackageKit code to Muon is very possible and that way would have the added benefit that Blue Systems would still improve the UI side. RPM-based distributions would get Muon updates for free while Daniel is busy getting distracted by yet another project (print manager, alternative NetworkManager widget, colord, and now switches).
Sorry, you fail to see why I wrote Apper.
Apper does work on a wide range of distros, how can you claim Muon is better?
Plugable backends? I can do it too. But no, I won’t because I have something much cooler in mind.
Is it better, every release I test it and it’s search is a joke.
Do you know why you find it better? Because you use kubuntu and you don’t know Cannonical’s Software Center data is not usable out of it, and you don’t know distros will hate to rely on a service from Cannonical.
You mentioned in one of your previous comment replies that switches and checkboxes have different use cases. I would like to know more about that, as I think they handle exactly the _same_ use case.
The use case is to let the user input and change a 1/0 state of a content, whereas 1 means enabled and 0 means disabled. Further, it lets the user _read_ the status from the switch/checkbox.
In my opinion, the checkboxes fulfill this need better than switches. Why? Because they are very easy to handle (click on them) and they are very easy to read (the hook means 1 aka enabled).
The switches have two problems: first, as mentioned somewhere higher up already, the switches are not unambiguous clear about the state 1/0. Said that, the user would have to find out which colour refers to which state. I’d bet that every user without that knowledge would turn a switch on and off in the first place to see, to which color the states 1/0 belong. And I’d bet the same user with the same knowledge wouldn’t have to do this with checkboxes.
Apart from that, the switch introduces something, which is completely irrelevant to its function: a direction. A switch could possibly be used for switching states different from 1/0, but in this case, the respective sides would have to bear a description. For the normal 1/0 case, the direction just introduces additional confusion aka which direction belongs to which function and – more importantly – why? The last question will _never_ be answered. This is actually not acceptable.
As a last point against switches I’d like to point to their bigger size. They look cluttered and somehow ‘overdone’. But this is just a question of design. However, as mentioned higher up already, the actual handling of checkboxes (clicking, tapping) is much clearer than switches (clicking, dragging, tapping, sliding).
And the argument that switches are more ‘realistic’ is wrong. It might have been true in the eighties, but nowadays buttons behave like checkboxes: you press them and the show you their state either via their height (high button: off, low button: on) or via an implemented LED (LED on: on, LED off: off).
Therefore, IMHO, checkboxes are always preferable if comes to a simple 1/0 decision even on touch devices. They wouldn’t necessarily need to be designed like the classic checkbox, but could rather by a hybrid of a checkbox and a switch. Imagine a switch-like rectangle, being ‘popped out’ and greyed-out in the off-state and ‘popped in’ and blueish in the activated state. That would be my favorite.
I totally agree Swithes are not easy to understand at first instance, now there’s also color blind people that probably don’t see the difference, so my point is, it’s is broken. can we fix it?
Yes, good switches use text, I/O is my preferable, also all switches I have used so far turn on on the right, so, it’s all about learning. Then the current plasma switch can’t be dragged, plus another thing that need fix.
About the use case, yes both code wise do the same, enable/disable. Visually wise too but with one difference, you know what a switch will do without text (no it Must have text for the state). So in the end the wider widget actually saves a LOT of space because it’s inherent to the contend he is in.
To understand better, my support for switches is only for hardware things, be it a monitor output, a printer, wifi and so on. So whenever you see it on that context you know without any further text that it’s about enabling/disabling the given hardware, and you can flood the ui with checkboxes to reject print jobs, make it the default printer, share it. But the switch has the context meaning of real world hardware. This is what happens on my phone, and I totally support this.
Even with text, switches can be hard to understand. For example, a switch with “On” or “Off” as text doesn’t indicate if the current item *is* “On” or if clicking it would turn it “On”.
Of course, some label like “Enabled” or “Disabled” is better: but can such a long text fit inside the widget ?
If you have text on both sides, you know it. Also there is the glow to help you.
And yes, Enabled or disabled are much wider than the complaints that switches are wider. And I not even comparing to other languages… 🙂
Bringing this to your blog instead of discussing it with the people involved .. what is that? It’s the same thing that people who gossip do: they have a problem with someone or something and instead of having the decency to discuss it with the person(s) involved, they talk about them to other people who aren’t at all involved. This lets them get away with all sorts of nonesense and untruthful statements because, hey, how can anyone know except those actually involved? You KNEW this was the wrong way to go about it, otherwise you wouldn’t have felt like you had to address it your blog entry. Suggesting that discussing things on an open mailing list is “hiding” and that it makes one an “evil company” is vile and cowardly rubbish. In a word: shameful.
So .. switches and checkboxes. I hope you are aware of how long we have said that switches do not belong on the desktop. They are great for touch where they overcome real world input device challenges. On the desktop, they introduce an inconsistency. They are also a new bit of design language that many people on the desktop simply do not get. We know this because we have *tested* this. Enough people find them confusing and unclear that we decided to stick with the well known and well understood checkboxes.
I have been telling people for probably a year now that switches on the desktop are not supported. So what do some people do? Ignore that and use them anyways because they think, personally, that switches are awesome. Here’s a lesson for you: ignore at your own peril.
As for the kscreen configuration, I’ve done user testing with that dialog. Have any of the developers involved done that? Nope. At least not last time I asked them, and several of the things I found in doing so were revelations, such as:
* rotation was completely non-intuitive due to rotating the whole thing including the widgets
* the icon for resolutions is not clear enough and the popup currently shown does not get much approval
but here’s the kicker:
* the switch was unclear.
When I would ask them to turn a screen off, the common response was hesitation and then when there was nothing else there, try the switch. Some thought it didn’t work because little changed (I ended up trying greying out the whole screen which worked better, unfortunately it also greys out the controls .. which was not so good as then it was not obvious you can turn it back on.)
KScreen is going in the right direction, but it needs some serious usability work before it’s completely there. (Even then, it’s still a lot better than what was there before .. though I’m still missing a way to set screens as clones of each other ..)
As for printers, it is a perfect example of why switches are evil on the desktop. The float off to the right hand side and it is anything but perfectly clear which switch is for which printer .. one’s eyes end up flicking back and forth trying to ensure you’ve got the right thing. Yet switches, by their very visual design, encourage this *exact* layout. On touch, this is less of an issue for 2 reasons:
* the screen is usually smaller
* you are using your finger .. which means you can visually track your finger across to the switch which is a completely normal and natural human activity (so one we’re actually GOOD at)
Really, I have been trying to talk to you in the plasma mailing list, I did that on the first email where you wanted feedback but you never said you were going to push the button and replace it.
No matter how wide you circles are http://api.kde.org/4.x-api/plasma-qml-apidocs/Switch.html doesn’t tell a word about deprecation on a Desktop, so instead of saying I’m the gossip girl you should rethink your means to spread the word, if I knew this at least a release cycle before I wouldn’t do this post. I’d just go and do what I think is right.
And again I’m not upset about someone forcing a change that some people (even if we are the minority) disagree, I’m upset about the lack of communication, what about you doing a blog post saying in 4.9 that in 4.11 you are going to do that? Give time for develops to adjust their user interface.
I really think you never used my plasmoid, first double line items are quite enough to assure one doesn’t need to look at the left to be sure it’s disabling the right printer, then if that wasn’t enough, on mouse over there is a selection.
You know why your tests have failed? Because the component is bad, I doesn’t allow one to drag and it doesn’t have text to help with the difference, Gnome, android and pretty much all others have text.
“you never said you were going to push the button and replace it.”
I’ve actually been saying that was likely to happen since the first release with the switch element.
“No matter how wide you circles are http://api.kde.org/4.x-api/plasma-qml-apidocs/Switch.html doesn’t tell a word about deprecation on a Desktop”
You’re right, it doesn’t say anything there. Mostly because you should not assume anything about the look of the widget. You can use switches, and on desktop they may not look how they do on touch. This is not unique to this widget.
“Give time for develops to adjust their user interface.”
You have until 4.11 .. you can also bring this concern to the mailing list or other appropriate venue.
“I really think you never used my plasmoid”
Ah, cognitive dissonance. Yes, I’ve used the plasmoid. I’m not saying “it isn’t clear when the widget is way off to the right” because I haven’t used it (do you truthfully think I’m that ignorant? Interesting ..) but because it’s basic usability: context matters, and context is often dictated by layout.
You brought up the gnome control panels, and they are imho horrible with the text all off to the left and the switches all off to the right (exactlys as in the org.kde.print-manager applet). I wonder who has done real world user testing of that decision, because it flies completely against what we know about associating controls with content from the last 2 decades of usability. Can people use it? Sure. Is it better? Highly doubtful.
“You know why your tests have failed? Because the component is bad, I doesn’t allow one to drag and it doesn’t have text to help with the difference, Gnome, android and pretty much all others have text.”
Lack of dragging (which should be added, indeed) had no affect on the tests. Why you bring that up, I have no idea.
With text we basically have a checkbox except one that doesn’t match the visual language of the rest of the desktop. Due to this, while a checkbox takes ~zero thinking for people using a desktop interface, a switch causes pauses, text or no. So what are the amazing benefits of a switch to justify that?
I’d be really happy to see both dragging and textual cues added to the switch component as that would make it better for where the switch UI makes sense.
Anyways, if you want to discuss this further, come to the mailing list where this discussion belongs. I won’t engage in this discussion here any further.
“You’re right, it doesn’t say anything there. Mostly because you should not assume anything about the look of the widget. You can use switches, and on desktop they may not look how they do on touch. This is not unique to this widget.”
Should I really program blindly now? So I add a Switch which always looked like a switch, I test it to make sure it works ok, then out of the blue it becomes a checkbox.
The biggest issue here is that if I had to use a checkbox, I’d have put some text. KScreen would have done that too, and yes I know there is a text property, but nobody uses that with a Switch.
“With text we basically have a checkbox except one that doesn’t match the visual language of the rest of the desktop. Due to this, while a checkbox takes ~zero thinking for people using a desktop interface, a switch causes pauses, text or no. So what are the amazing benefits of a switch to justify that?”
The cause is there because there is a learning curve, you don’t notice this anymore because you infer people already know the current widgets so let’s stuck in the 80’s where they first show up and haven’t evolved ever since. And yes I have my old mom to say this, no matter how obvious is a button or a gui window to me for her it’s taking some time. As of today I just lot at switches and I know right is on and the delay I had isn’t there anymore.
“Anyways, if you want to discuss this further, come to the mailing list where this discussion belongs. I won’t engage in this discussion here any further.”
See this thread http://mail.kde.org/pipermail/plasma-devel/2012-December/022955.html just follow to the end and see no final word, then another thread started and simply ended without big explanation. I’m sorry but I fail to see mailing list as the only right place for development discussions (especially when they involve user interactions) you can go to a plasma meeting or sth and there’s nothing on the mailing list saying some decision has been made (but the people on the event had come to an agreement).
Mailing list are as public as this blog and my intention here was just to get user feedback to see if people (namely users) can come with better arguing than I. And yes there are nearly zero users following a development mailing list and I quite happy with the excellent feedback I received.
Switches are not only evil on the desktop, they are evil everywhere.
Android 2.3 has lots of problems but bad usability of checkboxes in 2.3’s preferences is not one of them.
Switches serve exactly the same use case as checkboxes but switches not only look inconsistent, they also use more space.
Even worse: From a skeuomorphic POV they are an anachronism. Almost no modern gadget uses slidable switches. My Super Nintendo is probably the newest piece of hardware that has such a switch and that thing is from 1992 or so. All other devices have either pushable switch buttons or rocker switches.
I agree. We have checkboxes as a well-established UI paradigm, introducing a different control to do the same thing only produces inconsistencies.
I despise skeuomorphism as a design paradigm in UI’s, its terrible for usability. Physical interfaces do not translate well to digitial ones. The outstanding example being analog volume knobs. Great to twiddle with your fingers, useless to try and rotate with your mouse.
They don’t use more space. The word “Enable ” takes much more space than that.
“My Super Nintendo is probably the newest piece of hardware that has such a switch and that thing is from 1992 or so. All other devices have either pushable switch buttons or rocker switches.”
I had a quite new laptop with that switch to turn wifi on and off. And they only disappeared because it’s cheaper to do it with a keyboard.
I didn’t knew this change would have caused so much discussion
(for which i’m not completely sure planetkde is the proper place for)
Anyways, one thing i note about the arguments in favor of the sliders, is that they ignore any “historical memory”. If both checkboxes and sliders would have been invented today without any kind of previous experience, perhaps they would indeed present similar problems.
the checkbox is a piece of design language that has been around for decades in computer ui (and in fact way before then, and the fact that always was purely graphical instead of being a “real object” makes it even more powerful) and has a well acquired meaning for any two stare representation, being selected/unselected, yes/no, enabled/disabled, true/false…
checked is always “the current state is yes”, unchecked is always “the current state is no”
now, i find myself, and i find also in many comments here that a slider is more confusing, or at least less efficient in identifying at a glance if it’s saying “the current state is yes” (no, even labels can’t help, I would still wonder for ~0.5 seconds if the meaning is as in a button, ie the label is what happens when it’s clicked upon)
now, I’m not completely against changing old, acquired element, but real statistical data is needed about improving performance
“Anyways, one thing i note about the arguments in favor of the sliders, is that they ignore any “historical memory”. If both checkboxes and sliders would have been invented today without any kind of previous experience, perhaps they would indeed present similar problems.”
That’s a great point, people learned to use their computer, and some did it trough pain (those that hate computers), now when you give them a new UI the hate is almost natural, and I don’t deny the recognition time, which can be improved and once people are used it goes away. But I’m favor for them because I feel there are some benefits for those. One of them being the UI easier to ready when you have several checkboxes and only one switch in the case of a printer description, it’s fast to know which component you need to disable the printer. No matter if you are going to take a little more time in the beginning to know to which side you find the most important option faster.
Of course that’s how I feel.
And that’s classic example of KDE’s lack of product management. Every developer thinks he knows best, while UI design should be guided by bigger plan. Switches are not the same as checkboxes, and I’m not sure if any works here.
Every developer will always thinks he knows best till convinced the opposite, but that takes time and doesn’t always work. The same apply for lots other things in life, as long as we are not robots thinking inside a closed box I think we can work around issues the best way we can.
That’s one nice answer 🙂 You’re right. But again we should have design/UI team.
I’d like checkboxes better in my desktop, but only if text is at the right of them, just like any other App out there. Please, consider the view of uninterested users who prefer consistency over looks.
From one users POV:
I find the switches in the display configuration better, but over all, that UI is awful (wish I had useful improvements I could suggest as I agree its much better then the old UI). As for the printer applet, why do we need to disable printers from that UI? To me, it should just display status and if I click on a printer, either via a pop-up window or in the widget, display current jobs with job control. If I need to disable a printer, I’d go to the printer manager under system settings first, not the widget. Anyway, keep up the good work and thank you for all the hard work.
The reason for the switch on the print-manager plasmoid is two, 1st make it easier to know the printer state (yes the component is not best but still better than a checkbox for this purpose imo), 2nd sometimes you just want to hurry and stop all jobs, for example you work on a school and they all the students send jobs to a printer which is out of ink and you have to first replace. It’s a convenience after all.
My tuppence worth is:
With a touch-pad laptop/netbook (not a touch-screen) it is too easy to click a button or check-box as you guide the cursor from one part of the screen to another. If the action/reaction of the toggle-button/check-box takes a long time, because of a cascade of settings, disk/net reads and installs, then this is a mini disaster or major annoyance. The two action (press and drag) slide switch can save the user from accidental activation, but it is more work to use (like control knobs on a gas cooker).
On a touch screen, you cannot see what you are pressing, so all the controls need feedback (temporarily) larger than a finger.
On paper forms the check-box can be left or right of the explanatory text/label; in a GUI with left aligned text, it is probably better to have the check-box to the left so that it is obvious which check-box belongs with which label.
Aren’t these programs supposed to be on three levels: content/model, navigation/control and presentation/view? The fixed (or slow moving) interfaces between each level and the user allow each to be changed independently. You already need a presentation for each human language, but also for each screen-input combination and you need to allow for uses of differing ability and dexterity (not to slander lefties). Screens: small, medium and large; inputs: keyboard, mouse, touch-pad, gesture and touch-screen; users: new/familiar and ball-catchers/ball-droppers.
But ultimately, you do what you want or agreed – it is open-source, if someone feels strongly they can (pay to have it) implemented differently. One measure of relative success is how easy it is to mash up your code in to another useful thing or feature.
As you and others say, the sliding switch is virtually an indented slider with two values (0 and 100%), when you click the middle it does its page up/down to the other value and clicking on 0 should stay at 0 and clicking on 100% should stay at 100%.
Say you were connecting a scanner/printer or MFP, would the slider allow you to turn on mono printing, colour printing, scanning, faxing, etc.
For connecting something, the electronic symbol for a switch or sentry gate to allow/disallow.
Most toggle-switches/check-boxes have four or more states: disabled, off, on, focus/hover, context-help, etc. Ignoring transition animations. Model: value null, 0 and 1; control: enabled/disabled, changed, unknown/off/on; view: clicked, updated.
“But ultimately, you do what you want or agreed – it is open-source, if someone feels strongly they can (pay to have it) implemented differently. One measure of relative success is how easy it is to mash up your code in to another useful thing or feature.”
It’s no problem for me to do that, but I already have tons of things to do, I don’t like to do another one because the API that I was using changed without proper communication, simply ignoring it’s users ideas.
I can’t really comment on the freeze thing at all, since I didn’t follow the discussion.
About switches, though, I prefer checkboxes.
For one, I find switches confusing, always, even if they have a text on them, since I never know if a clickable widget which says “On” means that the control is enabled, or that clicking it will enable it (this, by the way, also applies to real-world switches ;))
Since, after all, it’s a button which says “On”, so one could expect clicking it to turn on the widget.
Second, clicking something with the mouse and having it slide in effect feels unnatural to me. Adding a tickmark to a box by clicking it seems much more appropriate. Also, they’re sort of huge.
And third, I don’t see any reason to break the checkbox metaphor which has worked for dozens of years. As said by other people, my personal impression is that people started using those switches when Apple started using them, because people like copying what Apple does.
That being said, why not keep both components in the API, with some clear constraints in which cases one or the other must not be used?
Cheers!
“Second, clicking something with the mouse and having it slide in effect feels unnatural to me. Adding a tickmark to a box by clicking it seems much more appropriate. Also, they’re sort of huge.”
What about clicking on a slider end and having it slide to the end?
“And third, I don’t see any reason to break the checkbox metaphor which has worked for dozens of years. As said by other people, my personal impression is that people started using those switches when Apple started using them, because people like copying what Apple does.”
I don’t think introducing another metaphor breaks the other one, I never wanted to replace all checkboxes in the world, actually I think you should use only one switch per context. And I wanted to have switches on QWidgets by the time KDE 3 was current.
“That being said, why not keep both components in the API, with some clear constraints in which cases one or the other must not be used?”
That’s what I believe should be done, once you introduce a feature removing it break others people work unless you control the other people work, but in this case this API is said to be public…
“What about clicking on a slider end and having it slide to the end?”
It feels unnatural too and I find myself avoid using it.
“I don’t think introducing another metaphor breaks the other one, I never wanted to replace all checkboxes in the world, actually I think you should use only one switch per context. And I wanted to have switches on QWidgets by the time KDE 3 was current.”
It doesn’t break it, but it doesn’t make use of its well-established meaning.
Also note that I didn’t want to blame you for copying Apple, that was just a side-note. 😉
I very much appropriate your work for KDE and I can understand your frustration. But even though you may be right in many of your points: sometimes it’s wise not to press one’s point. The KDE team has decided not to support switches on desktops not to annoy you but for a reason, and I think you should respect that, rather than insisting on what you think is right.
typo. I very much appreciate your work […]
Who is the KDE team? Really aren’t we a community. The central point here is where/when was this decision made, I commented on the mailing list when the subject was risen and yet no one gave a final word.
So yes, I fell out of the “team”.
I you think that maybe will be another reason, Is not possible fell out of the team only for a chekbox/switch discussion. there are more important thing in our lives. Your work is great, don’t forget it.
Please, check your usability with themes other than Air. Caledonia, for example, makes the enabled switch look exactly like the disabled switch, but to the right. OTOH, the checkbox solution works always.
It’s not my duty to check for usability in other themes, if you write a theme you should do that properly. And yet there are themes where a enabled/disable state (not checked state) checkbox look the same.
I do not like the switches on my desktop. I kind of got used to it on my tablet. They use more sqreen estate which I need to touch them with my finger but on the desktop I don’t see any advantage. And as other mentioned it already: For me it is always clear which state a checkbox has, but for the switch I compare the states in a list of switches to get what means on and off.
Dantti, there were allready some comments about the touchscreens, I’ll add another one.
The notebooks with touch screens become more and more widespread. I have one, and you can trust me – pressing the checkboxes is difficult as hell.
But I’ve the motivation part at the begining; it’s absolutelly correct you modify the software for your own needs. That’s basicly the idea of OSS. I just hope this won’t become a default.
As an owner of a tx1000 hybrid, I can say: simply slap Plasma Active on the thing, disable the on-screen keyboard, and enjoy your HUGE switches. I’ve been doing that since I found how to install Plasma Active on the thing.
Switches are surely not anachronistic: even my laptop and my phone has some hardware switches and they serve all as a button that preserve its state. In sovtware switches are nowaday present, just look at IOS and GNOME…
The printer plasmoid looks better with checkboxes imo.
You may want to check the ML thread again, since there was a post with hard facts (HIG) against the use of switches on the desktop.
Actually the HIG just show what I tried to say many times, explaining how it should be used and their difference.
Indeed only Gnome have those on the desktop OSX and Widows for desktop doesn’t, but the problem that I face is that the component was there on the Desktop without no notice on the API that I shouldn’t use it.
To me, it appears like a matter of expecting a communication across people of different culture/background. Few things like these were expected to happen when contributor base expands into the new regions. People put their perspectives and expects the communication in their way.
Another aspect to consider is that a lot of emphasis is placed today on integration between components with polish which require heavy testing as well. Decision making can only be done by anticipation, with what comes on the table of the responsible person and some delayed inputs may need to be considered. It is also true that criteria of good decision making is getting 50% of decisions right. The rest needs to be improved and/or improvised.
Creativity is known to be painful process and tolerance is a desired virtue is any community. It appears to me that “pained by community” should also be accepted with dignity. Your friends did it for good intentions. All of us slip sometimes.
It may have been said already among the many many comments but the “switches” do not work well with some themes and colourcombinations. I for one was not even aware they WERE switches until this discussion (both in printer and screen management) as the background of the switchbox is the same as the surrounding colour in the theme I use. So small wonder I raged against the new screenswitcher…
I think checkboxes are much clearer as indicators.
First off all:
The print manager layout just is wrong. The I/O should be on left side. And if you want to use the words “idle” and “paused” you should still using the play/pause buttons.
I suggest you put the widget (anyone) on left and see if the whole thing looks better.
And if you ask me, checkthings on right side are a great design pattern for a four inch wide touch screen who you you operate with your right hand. As a left handed person, they are wrong even in touchs creens for me, I just cant view the text option while using the check thing.
Other point
The main problem with ksceen checkthing is the lack of a label “[checkthing] Enable”, not if is a checkbox or a slider.
Last Thing:
Checkboxes or sliders are just the same, and I have never worried about this. Maybe people of right to left writing seems sliders are a crap, as I think about right positioned checkers on touch devices, (and someone must look at this) but for me boot are the same.
The sliders look prettier for me, but they are huge. Checkboks just are more familiar.
Sorry but you are wrong, Checkboxes must be on the left, and Switches on the right, that’s how all platforms that use them do.
Switches are not the same, where they are used it’s clear they are only used for things like devices and that require immediate change, actually someone finally brought up on the mailing list what I was trying to state as their difference.
Checkthings on touch devices must be on right side, for ergonomy of right handed people. Try to use a touch smartphone with the left hand and you will see why they are on right side.
On desktop, sliders must just follow the desktop patterns and be on left side, because is a lot more natural for a left-to-right-writing society.
And localization must can switch for right-to-left-writing societies.
On touch, checkboxes are on right side too. Why on desktop sliders can’t be on left side?
Just out of curiosity, how would a on-off state switch differ betwen a right-to-left in regards to the left-to-right text individuals? Will right always be on and left off for both? 🙂 Between them I always prefer checkbox anyway.
I think yes, there won’t be a difference as comparing to a real world one there is no distinction for individuals.
Activation of slider follow the same left-to-right pattern of a lot of thing in our civilization, then right-to-left people *maybe* feel uncomfortable with them.
I always found switches quite intuitive and more aesthetically pleasing than checkboxes.
First of all I do see the point of taking this public. I’m not saying it is the right thing to do, I’m not saying it is wrong to do. Just that I can understand why you did it. You really care about KDE as a community and as software and that’s a great thing to see for sure!
As for the point of changing in the API after the freeze: a freeze is meant for something and I agree that everything should stay in a solid state. Before everybody jumps on me: it’s my ‘clean opinion’ without any context as this thread does have way to many replies to read them all.
Now for the usability: Initial I have no idea what those switched/checkboxes do. I think it’s bad design if I have to guess. If I read your explanation I doubt that they are on the right spot. For easy access I would say: put the printjobs on the right if you select a printer and put the controls there too. A stop and play/pause button above a list with printjobs (sort of like a playlist) would tell me exactly what they are meant for. Unless they change that too someday (don’t know how you can replace the play button though) you are save against API changes 😉
I hope you are not too disappointed in KDE and the way some things sometimes happen. It’s taking up much free time and it’s hard to see that somebody is struggling for something that should bring as much joy as possible.
I really enjoy your contributions. I’ve read you do too many things for 80% but I’ll say that you are doing at least SOMETHING. Even if it’s 80%, it’s still more than some others do. And for that, I thank you.
Thanks, indeed this probably wasn’t the most wise thing to do, but I felt so bad about this. I do the best I can to bring something with quality, and if I wasn’t following an unrelated thread about something I helped build I would never know that this change would be made. If people agree with the change is not what triggered my sadness, it was the lack of communication.
And well tomorrow I’ll do another post sharing the print-manager improvements for 4.11 and what I did to this situation.
For me it was not clear in the thread that you felt that bad about this change. In fact I found it very strange that you came up with this topic in a completely unrelated thread. Also I must say that you went overly aggressive into the thread. You were attacking the people working on it. If you wanted to change something, you weakened your position.
I think it would have been much more wise to start a new thread and explain that switches and checkboxes are not the same and try to come up with a way to support both. In your first reply it wasn’t clear at all that you think switches solve a different purpose. It just sounded like you were angry because something you used got removed. The only argument about switches you brought was the usability.
And that’s were I stepped in. To make it clear: I had nothing to do with the API change. I don’t even care about it, except that I don’t want to see those switches on a mouse driven interface as they are completely unusable for me. That’s why I replied and outlined the usability flaws of the switches.
Given your replies and also this blog post I think you failed to understand my usability concerns. I am not an usability expert, but I know some of the ideas behind usability and I can recognize bad usability. If I fail to use an UI paradigm as someone working on user experience as someone who has a Masters degree in Computer Science and had lectures on usability then many people have problems with it. In German we have a joke about software needs to be usable by the most stupid user one can imagine. This component is already failing with me.
This makes this blog post really sad. You discarded all the feedback you got in the thread and did not start to reflect whether it’s really a good idea to use the switch. Yes, for me it would be a reason to not use the print manager because I cannot understand the UI. Just think about it. You defended a position overly aggressive without reflecting the UI concerns. Now I was not the only one having these concerns, Marco mentioned exactly the same arguments as I did.
If I understand you correctly your main concern is that the API doc didn’t tell you that the switch will be replaced by a checkbox. So I just had a look at the API doc and I did not notice that it mentions that it represents a switch at all. It only says it’s like a checkbox without a label. It doesn’t say anything about the visual representation. It really surprises me that you complain about the change of visual representation. You should know after years of Qt development that visual representation is not guaranteed. Visual representation changes with the selected style. I know widget styles for Qt changing the representation of a widget completely. One shouldn’t program with a visual representation in mind. And your usage hasn’t changed at all. It’s still a switch, isn’t it?
Well if you look at this first thread back in 2012 http://mail.kde.org/pipermail/plasma-devel/2012-December/022955.html you can follow till the very end and see no final word on it, as a non native English speaker it’s not the easiest thing for me to explain myself why I find they do cover different use cases as I tried here http://mail.kde.org/pipermail/plasma-devel/2012-December/022959.html of course one can say I was not convincing enough, thankfully someone brought up on the last mailing list thread the HIG of mobile OSes which just state what I was trying to say but failed.
Now, if at that very first thread there was a last email, saying all plasma devs have come to this agreement (notice the thread started with a questioning on what to do) and that starting from 4.11 it would be a checkbox. That way I could be upset, mad or whatever but I would have enough time to think how can I adapt to it, as to me displaying a checkbox ruins the ui, not because I like them but because I feel the same as the HIG of the mobile vendors state about them. The current component had usability issues, still if improved I think people should learn to use them.
About theming I never saw such a drastic change in the representation no. And the component is named Switch which isn’t a CheckBox. Anyways, I know this blog wouldn’t change that decision just the way complaining about Mir won’t too.
I’ll focus on the usability issues and leave the bazaar development issues for another day. In the first two screen shots, I see a few usability issues.
1) I have some difficulty determining in what state the switches are. Are they enabled when right/blue? I think so but I’m not certain and that is not good. Using only colour to represent a state is problematic for people with colour blindness, especially when the brightness is so close in both states like in this case. Also, it is not that clear what the switches enable.
2) In the second screen shot where the switches are replaced with a check boxes, it is clear in what state they are but it is not clear what is enabled. It also looks a bit inconsistent with the rest (and ugly IMHO).
At first, I though of adding some text to the switch or check box as a possible solution but that has localization issues. on/off is not widely understood for non English speaking people and localizing on/off can be result in large words that would cause display issues. Also, it would not be consistent with the other elements.
So, on second thought, an icon may be a solution. A two state toggle-able icon, much like the favourite icon, to be precise. The icon would display a symbol that is widely and easily associated with on/off and enable/disable. This symbol is already used in KDE to the indicate power off and is very widely used in on/off buttons of electrical devices.
The icon would be grey when off (disabled) and bright red when on (enabled). Also, some changes in shape (indicate activity) to make it clear to anyone with vision problems. Possibly an halo as if it was light up.
I think this solution would be easily understandable by the vast majority of people and also would be consistent with the rest of the elements (e.g. icons) displayed. It would also solve the switches or check boxes dilemma/dispute by answering icons it is. 🙂
Finally, thanks for your work. It is much appreciated.
If you use the power icon you have linked too, more common colours would be green for activated and red for standby mode. Red should certainly not be used for activated mode as it is normally indicating standby mode.
I just looked at the thread and well there is a decision. That’s how Plasma team works. The decision was done by the Plasma maintainers agreeing. I see Aaron, Marco and me agree on it. And Nuno while not stating a clear yes disagreeing with you. So overall that was a clear decision. Normaly such threads just start to fade away if it’s clear what the opinion of the team is. In this case it was pretty clear.
I’m outside plasma, I use it’s API as a developer, and a fail to know the main maintainers, I know Aaron and Marco have done lots of stuff so I guess they are probably the ones where the +1 counts.
So let’s pretend I failed to know plasma devs well enough to know which +1 counted, then I wonder, does that justifies for an API change without a single line of update in it’s docs? I see Qt 5.0.1 getting an ABI break and it gains a blog post about it. Here the visualization got broken and it’s all fine, the blame on me for not knowing that.
What if then I wasn’t subscribed to plasma mailing list? Or else wasn’t following the battery discussion which interests me a lot. I would only know that on final release as I don’t run master kdelibs.
“API change without a single line of update in it’s docs?”
But there was no change to the API? It’s a change in the visualization. Any theme could have done the same…
“I would only know that on final release as I don’t run master kdelibs.”
And the same is true if the API docs would have gotten an update. Or are you checking the docs each other day to see if something changes?
switches >> checkboxes
“How do you feel with these screenshots, do you think if a plasmoid is written for Plasma Active where switches are allowed, they can run as checkboxes on the Desktop (with no change)?”
IMO, if something isn’t clear what the meaning is when you switch from checkboxes to switches or vice versa. Then it wasn’t clear enough to begin with.
To be honest as somebody who hasn’t yet touched 4.11 and hasn’t used the printer, I have absolutely no idea what most of those check boxes (or switches) mean in *ANY* of those screenshots.
It’s just simply not clear to the user what you’re trying to say there and it absolutely should be clarified to improve user friendliness.
“Now think for a moment what is that checkbox trying to tell you
Cable connected [Check]
Output enabled [Check]”
I don’t get *ANY* of that at all from the checkbox in the screenshot. The only meaning the checkbox has for me is that it’s “selected” or that the user has a desire to use that.
I’d hope that if you want to say these things, you’d follow something like network manager’s example and write it out…
Networking Interface:
Cable Unplugged
WLAN Interface:
Connected to YourWifi:
Virtual Private Network:
Not Connected.
….
And as far as the switches, I’d think following Android’s lead there and saying “OFF” on the left side of the switch when the switch is off.. And saying only “ON” on the right side of the switch when the switch is on.. Would go a long way to explain what the meaning is of the switches while being in one position vs. the other.
Wow, I read most of the rationale of checkboxes vs. switches but in the end … in this two cases (printer applet, monitor configuration) switches are so much more beautiful!
Heck, a VW might kick the ass of a Ferarri in terms of utility, after all it’s a beautiful car. Please give us switches back!