Jargon Is Bad
We use a lot of jargon when discussing, designing and creating our software. When we're working on something that's complex or new, new words and phrases (or new meanings on old ones) will crop up in our language when discussing it with each other. The world outside our creative circles remains innocent to these new bits of language floating about. This is all well and good .. until the jargon starts creeping outwards and meets people using the software.
In Plasma, we try to keep the jargon we've invented to help us work together out of the user interfaces. It's not a cashew, it's a toolbox. It's not a Plasmoid, it's a Plasma Widget. It's not "Plasma" it's "the desktop shell" or "the workspace" (if we're being more inclusive and talking about KWin, etc as well). It's not a Containment, it's an Activity if it's on a main, full-screen layer (e.g. desktop or dashboard) and something descriptive for the context (e.g. Panel) if elsewhere. It's not always easy because to us these words are just second-nature.
There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely. We should instead be using terms that describe what it does or why I should care about it when I'm using it.
Micro-Options Suck
KDE has a great history of configuration options. Sometimes, however, we use that as a cop out and instead of making a good decision or a hard decision we make no decision and instead put an option in there. Besides the cost on the code itself (more code paths, etc, etc) there's a cost to the usage of the software.
Every option shown to the person using the software is something they have to read and understand. Then they have to choose whether to interact with that option or not. Is it what they are looking for? What happens if they toggle it? Where is that thing I'd like to control? At some point, people will give up, get frustrated or both. At best it slows them down, at worst it causes them to stop using the software all together.
So when deciding which options should be there, know the audience and its needs (e.g. technical applications will often have a lot more gadgetry to them) and be ready to make hard decisions. If it turns out that it does indeed need to be made optional, it can be added later. Taking back an option once offered is really hard, though. It makes people sad.
The good news is that if a few hard choices are made, including the occasional "no, I'm not going to make that optional even though you and your friend have asked for it nicely", there will be lots of room for other options that are highly valuable and useful.
So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).
62 comments:
Altering the behavior without asking the users (or providing an option) also sucks. Productivity is all about having the same applications behave the same, over version changes (even if the "old" behavior was non-intuitive at the first poing).
Example: knotes now ask for a title, we can't just leave a note any more.
Some jargon is good IMHO. E.g. the name Plasma and Plasmoid which are brilliant names and gives a branding to KDE. The problem is that they have to be communicated to entry level KDE users. The first time a user starts KDE he/she should be greeted with a *brief* introduction to the desktop shell.
Aaron, I agree TOTALLY with you.
I was never so agree with someone like now.
At the moment the KDE problem is this. Wants user all these choices? Are necessary all these choices? KDE 4 must be for power users or for all users?
I think the solution is:
fewer and simple choise;
simple and descriptive names for system tools and applications;
I am frequently asked "Why can't I configure things to work as I like? I could before!". KDE appeals to people who like to configure every last thing. Taking away options is not the right path - sane defaults are the key to helping new users.
One thing to note: KDE in French uses the word "plasmoïde" everywhere you would expect "applet plasma", maybe the l10n teams should have some rules on what jargon not to use?
The first reason I ditched Gnome and choose KDE soon after I tried both was the reconfigurability. I really hate the "developers know best" attitude, I like to be able to tune and change stuff to my liking. I hate when I am forced a interface choice, breaking everything I had before and liked, not because there aren't options, but because developers actively reject code changes that would enable those options, on the argument that the new choice is the best for me.
I want choice - If I didn't, I'd be using Gnome or some MSFT offering.
I have to agree with aseigo.
Jargon: a few exciting new names can help sell the thing, but too much jargon or new names will confuse and lose the sale.
Options: even as a technical user, having to make a choice about some option, when busy trying to get some job done before some deadline, can make Linux (and its desktops) a pain to use and might discourage new users.
Things probably have to evolve, otherwise we would probably be still using WordStar commands for editing, but they should evolve to ask LESS, not more from us - knotes could probably create a title from the note, and not delay you unnecessarily.
(Paraphrasing Cooper, Spolsky and others) your users will fall into three main groups: beginners, intermediates and experts. You want your system easy to use (consistent, intuitive, smart, helpful, etc. and not chatty, not forgetful, not vague, etc. ) so that beginners soon move up to intermediates. Very few intermediates will move up to experts - they are too busy doing their field of interest - so you will have about 5% beginners, 5% experts, and 90% intermediates - your target user should be the intermediates. That means not insulting them with the tip-of-day dialogue, not forgetting the answer given from last time and asking it again.
When I quit KWrite, either I want you (the application) to save my work or I don't care what you do with it - rarely, if ever, would I want you to discard it - so please just save it with some logical name (based on day, date, user-name, host-name, content or something) - in fact why weren't you saving as I went along, in case there was a power cut or something.
This touches on the real problem for user experience, which is visual clutter, not options per se.
As long as general users don't feel overwhelmed, they're totally comfortable with a million options they'll never use. A simple common solution other developers use is to hide everything behind an "Advanced >>" button or some system-wide configuration, then to make Basic interface the default.
Example: what if I were to go to KDE's System Settings and set my Configuration Level. By default it's Basic. In Basic, every KDE configuration dialog is simple, light-weight, most common options only, etc. In Advanced, anything goes. Maybe there's multiple levels and a slider to move from Basic to Advanced. Whatever.
This example would put the 'option necessity' burden on developers to make the decision, not the user, yet still not limit developers into making dumbed down GUI configuration interfaces.
Make it standard in the KDE configuration libraries, do what you can to force developers to mark options by Level or require creating dialogs specifically for each Level, slap a HIG on it and you're done.
General users are important but power users like GUIs (over editing config files) and limitless options, just as well). Why not cater to everybody, wherever possible. I don't see the two competing needs as a zero sum conflict.
Isn't it time to overhaul the configuration system anyway? I still wonder why I have to click "Apply" a dozen times to cycle through my desktop wallpapers. Ever try to individually test plasmoid options (not even an "Apply" button)? It feels like getting a tooth pulled. GNOME has a good auto-apply approach on a lot or most of its standard options interfaces. Just put it an adequate Revert function and you're set. Who knows, maybe instant feedback on most KDE options would help these frustrated general users decide whether they need all these options in the first place.
@Robert: [quote]When I quit KWrite, either I want you (the application) to save my work or I don't care what you do with it - rarely, if ever, would I want you to discard it - so please just save it with some logical name (based on day, date, user-name, host-name, content or something) - in fact why weren't you saving as I went along, in case there was a power cut or something.[/quote]
Conversely, I frequently use kwrite as a scratchpad - particularly if I want to note things to talk about later. I then do discard it, so I definitely don't want to lose that ability
I agree with the larger points entirely.
However, as a concrete case, I think "Widget" is rather jargony itself -- even moreso than "Plasmoid", actually. And calling them "Plasma Widgets" makes little sense when you're not calling the whole thing "Plasma", rather the "desktop shell" or whatever. (And I'm not so sure about "shell", either.)
On the other hand, I'm not exactly overflowing with better ideas.
Just give users the options, but make best defaults what you can. That means as well asking from older users what configs they have set.
Limiting amount of options is not good direction. But that does not mean there must be always somekind options. Gnome is good example about DE what does not have features what users needs. Even the default's are such that you first feel "hey, how simple :D" and sooner or later you just say it aloud "Yeah, how simple... >:/" and they switch software.
And when someone talks about "Advanced" part for options, I always remember the discussion before KDE4 started even be on alpha state, how the "Advanced" and "Basic" modes were bad.
What I would ask, is that there is enough information on every option what to tweak, what it does and how it affects other things. Right now there are few places where this is done. Too many places tries to be too short and simple and user really need the "Apply" button and little testing what just happened.
And I hate the Gnome auto-apply feature. And I remember how it was discussed as well on usability postlists and so on. It did not get so much fanfares.
And what comes to jargon, it is not good to reinvent new name for older. Okay, example by widget vs plasmoid. That is not samekind comparision as widget vs gadget. But the KDE widget is something more, it is way better way integrated to desktop. They allows multiple different technologies and so on it would need new name, because they are not just widgets.
The worst thing what can happend, is when people start using different technologys terminology to another, what would not even be correct by the logic. But because the other one sounds nice and such way tech-oriented, it helps boost marketing, even it is totally wrong. One example of this could be the "operating system" or "core" and now on these days especially when new users start using technology and they do not know the history and technology what they have meant.
I think options are important, even options, which are not used often. Sane defaults are the right way.
Ok, when there are much options, it is sometimes difficult, to find the right one, or find out, what it is for: but in my optinion you can solve that always with
a) good structured configuration layout (good named pages/tabs) and
b) good named options, and using tooltips (which is done much too less)
By the way, before a few days I explored this "activity" page on the desktop by accidence. I was very confused, and still don't know what it does/what it is for. Is there a page with an explanation?
@Configurability:
While I understand your arguments, I as a user never ever suffered from "too much options". On the other hand I DID suffer from to few options.
I think the 20/80 rule shall apply here:
In 80% of the cases only 20% of the functionality (options) are used. So make these 20% easily accessible and hide the other 80% under some "advanced options" dialog.
I don't agree, but I won't argue this time. "tomwinkler" said everything instead of me. Most of apps that I use are full of options. If I have a choice, I always choose ones which are more configurable. Same applies to KDE and plasma.
Options are here to add power, if the are well organize, keep them, that's all. Don't start this gnomism crappy principal that make user of various options mad every time they hide it deeper to just remove it at the end.
Those usability concern are true, but it is one of those choice, and my point of view is that they should be kept it they make sense for at least 1 user.
Oh please do not go to same direction as GNOME has gone always. Keep up the options and bring configurations possibilities for users. That is the power of KDE!! Power user can always customise the KDE for people who have specific needs and who can not configure computer itself. With other DE's that is not possible at all!
What comes to the panel. I have seen one intresting one what I would like to see on 4.5.
http://kde-look.org/content/show.php/KDE+4.3+new+plasma-panel?content=96882
@everyone:
WRT: So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).
Aaron was not talking about removing options and having good defaults. He was talking about having the cake and eating it too! a.k.a. both. Good configurability (If that is a word) and good defaults.
Reading many comments I not understand because "few choises" must be bad.
I think that:
* few choise\options != less customise
* many choise\options == many questions and frustration for users
* many questions and frustrations for users == bad
* few choise == the liberty to customise
* few choise\options == less frustrations == proper customization
Ultimately, "few choise" is compatible with "the liberty to customise".
Another question is to use for system tools and applications user friendly names and self explanatory.
@Panos: "Altering the behavior without asking the users"
that's hardly feasible in most cases, decisions get made and the developers can not be in contact with every user as they do.
that said, you chose a very specific case that you didn't agree with. in that very specific case it may have been the wrong decision. (personally, i agree with you in this case)
however, "changing things is bad" is not a general statement that can be. "changing things in a way that makes the workflow the appliction is intended to aide in harder to accomplish" is.
@Thomas "Tanghus" Olsen: "the name Plasma and Plasmoid which are brilliant names and gives a branding to KDE."
they bring no value to the end user. we can use them for branding and what not, particularly amongst the enthusiast community, but they do not need to and in fact should not show up in the actual software's user interface since they only serve to increase the difficulty of using the software.
branding and marketing can (and does) happen elsewhere. the user interface is a place to work, not engage in marketing exercises.
@gp: "fewer and simple choise;"
that doesn't work, either, though. it's a simple and obvious answer, but it FAILS miserably because we do work in different ways and we do need our information tools to do several things.
it's a far more difficult set of answers than just 'lots of configuration' or 'as little configuration as possible'. the answer is closer to "a good set of configuration options, each of which deliver a high value in being there"
@AnneW: "I am frequently asked "Why can't I configure things to work as I like? I could before!"."
often those questions are not exactly, well, HONEST. what they usually mean is "this one feature i used is now gone, and i'm going to complain about it as if it's a general problem hoping i can convince someone to change it back to my liking"
this is just another expression of "i dislike change". it rarely, if ever, comes with a "why this option was really needed".
when it comes to plasma, there are generally one of three reasons something has gone "missing":
* we haven't gotten to it yet (that's less an less these days, however)
* it was a BAD IDEA in the first place and caused problems for other options
* it was used by so few people that catering the software to those 18 people cost the other Nx10million unduly
software that is used by many will often compromise on the exact feature set. there's a reason why plasma is so flexible, though: so that when people want to make changes that only make a specific vertical market happy they can.
those who complain because the don't put the effort in to do so do not gain any sympathy from me.
"KDE appeals to people who like to configure every last thing."
yes, it may appeal to those people. but the vast, vast majority of our users out there are not those people. if we focus on those "configure every last thing" people who use our software, we screw over the 98%+ of the rest of our users. how is that fair?
"Taking away options is not the right path - sane defaults are the key to helping new users."
this completely ignores the fact that some options are mutually exclusive, some options are plain stupid (recently someone added an option to not focus the edit line in a widget when it was clicked on; what's the use case for that?!) and that there is limited room in both our maintenance schedule and our config ui to support them all.
options are good, and i said as much in the blog entry .. but there are SO MANY OPTIONS that are possible that we need to PICK WISELY so that we can offer AS MANY POSSIBLE without making the software PAINFUL TO USE.
to be frank, KDE3 was failing for MANY people due to this. those who would keep it that way are doing a disservice to the rest of us.
@smarter : "KDE in French uses the word "plasmoïde" everywhere you would expect "applet plasma","
that's unfortunate, and it should be fixed.
@josebernardo: "I really hate the "developers know best" attitude, I like to be able to tune and change stuff to my liking."
here's the blunt and hard truth: sometimes the developers do know best. just like the plumber or the electrician or the doctor sometimes knows their topic a bit better than you do.
however, you are right that featureless software SUCKS.
i'm not talking about featureless software, though. i'm talking about software that has LOTS of features and options, but only ones that well presented and have high value.
that way you get software will lots of really great punch and utility that is still easy to use.
as opposed to software cluttered with dozens of niche options that each make a couple people out there happy and make the application less appealing for everyone else.
if you want lots of features and options, just as i do, then you should be encouraging developers to be thoughtful about which features and options they implement. there are more possible options than can be possibly implemented in any sane fashion, so we need to pick wisely.
why is that so hard to understand, exactly?
@Robert: "knotes could probably create a title from the note, and not delay you unnecessarily."
exactly.
@cicked: "This touches on the real problem for user experience, which is visual clutter, not options per se."
that's a huge part of it.
(other arts include the conundrum of conflicting options, options that make the code base so difficult to maintain that bugs are impossible to fix, so many options that there's never enough manpower to finish many of them very well, etc)
"As long as general users don't feel overwhelmed, they're totally comfortable with a million options they'll never use"
generally true; unfortunately it's really hard to have a million options they don't use and not have them feel overwhelmed. there's a middle ground to be found.
"hide everything behind an "Advanced >>" button"
besides not at all addressing the other issue listed above, this is really really hard to "Get right". it also spreads options that belong together semantically out across a larger navigation system leading quite quickly to a rather nonsensical system. "Advanced" does not say at all what lays behind it, so people spend time rooting around in little corners of the configuration UI.
what if it turned out that all those options could be presented in a way that didn't need an Advanced button, esp if one or two of them that were used by vanishingly few people or were just outright broken by design had never been put there in the first place?
Advanced is a cop out most of the time.
"what you can to force developers to mark options by Level or require creating dialogs specifically for each Level"
that has been shown over and over and over again in practice to not work. i've been debunking this idea in f/oss forums for getting pretty close to 10 years now. it keeps coming up, though. why? because it's one of those ideas that springs quickly to mind when thinking of possible solutions.
unfortunately, there is no uniform "level" between people and topics (being an expert in A doesn't mean you are in B), among many other fatal flaws to this idea.
which makes "selecting options wisely" all the more important. prevent the problem before you have to fix it with solutions that don't even work in the first place.
@illisius: "However, as a concrete case, I think "Widget" is rather jargony itself"
yes, "widget" is jargony, but it's a bit of jargon that's at least widely used for these kinds of things. the least worst choice kind of thing :)
"gadget" is anther option, but that's newer (and not really popular at all when we started plasma) and, imho, rather corny sounding. "Gadget" itself is jargon introduced by companies not wanting to appear like they are following along with the rest of the crowd doing "widgets" because they showed up so late to the game. "no, look, we're doing something new, really! it's not a widget, it's a.. it's a.. a GADGET!" *sigh*
@Fri13: "Just give users the options,"
no one is saying to NOT give people options. i'm just saying not to burden everyone with infinite options.
"but make best defaults what you can. "
good defaults are a must, yes, no matter what one does otherwise with options (many, few, wise choices, random smatterings, etc).
but what does that have to do with offering sane options that work well together and can be sanely managed by people using the software?
the implication here is that if the defaults are great, then we can abuse the options UI however we wish because nobody will see those options except for supermen of configuration.
that's a myth on two points: good defaults are great because it makes as many people as possible feel good right from the start when using the software, but it will never capture the majority all the time. moreover, people DO go and configure their software. that's just a FACT we need to deal with. and those who don't often don't because they find doing so TOO HARD, not because the just LOVE how the software works.
so good defaults are something to strive for, but in terms of option availability it's a cop out.
"Gnome is good example about DE what does not have features what users needs. "
agreed; and it's not at all the kind of strategy i'm talking about.
"too few options" is not the only alternative to "insane optionizing".
there's a reasonable middle ground here, and i wish more people would take the time to try and find it.
@panzi: "I as a user never ever suffered from "too much options". On the other hand I DID suffer from to few options."
yes, there can be too few options.
you're also lucky that you've never suffered from too many options, or perhaps you haven't been aware of the downsides at times. but it does happen quite a lot.
too bad we aren't writing software just for you as the only user of it. ;)
@vedranf: "Most of apps that I use are full of options. If I have a choice, I always choose ones which are more configurable"
you are in the minority, then. sorry.
@Elv13: "Options are here to add power,"
agreed
"if the are well organize, keep them, that's all."
agreed; and what i'm pointing out are things that get in the way of "well organized", which includes not thinking about which options to include.
"Don't start this gnomism crappy principal that make user of various options mad every time they hide it deeper to just remove it at the end."
that's not what i'm saying at all. this is a knee jerk reaction on your part because you don't like what GNOME did. fine, we have no argument there.
but try and read what i have written free from that. there's a better place than "featureless" or "just pile the features in by the truck load!"
@Paristo: "Oh please do not go to same direction as GNOME has gone always."
that's not what i'm saying at all.
"Power user can always customise the KDE for people who have specific needs"
yes, just like the sys admin can always do it for all the people who have one sitting at their desk all day, right? no, that's a myth and an excuse.
the point is to make software as featureful as possible without making it unusable. the question is how to get there, and that's what i'm trying to have a discussion about.
knee jerk reactions aside.
"What comes to the panel. I have seen one intresting one what I would like to see on 4.5."
patches welcome. i'm already pretty busy as is everyone else. "make me a dock" is one of those things some people ask for and nobody steps up to write and/or pay for.
@alien: "Aaron was not talking about removing options and having good defaults. He was talking about having the cake and eating it too! a.k.a. both. Good configurability (If that is a word) and good defaults."
exactly.. thank you!
Hi Aaron,
Always follow your posts and as always, I like this jargon-busting post :-)
However, not sure if this is the place to mention it but dual-monitor setup is still a pipe dream in KDE. Krandr gui allows me to setup the multiple monitor resolutions but does not allow me to move the monitor representations around to simulate the actual positions on my desk.
Frankly, this has been in Windows for years and even in GNOME display manager for quite sometime now.
For now, I have to manually do this with xrandr command every time I start my desktop.
Is it planned for KDE 4.4 at least?
Cheers,
Kanwar
Mine and TomWinklers posts were not "make me a dock" posts.
It was valid critism of the current state of the taskbar (esp. in vertical) and multi monitor support.
I don't think posts like that need to be deleted.
And saying that we should pay for those features or send patches is a cop out on your part. There are patches. They are just not integrated because they don't fit into some grander KDE vision. IDK.
@aseigo [quote]often those questions are not exactly, well, HONEST. what they usually mean is "this one feature i used is now gone, and i'm going to complain about it as if it's a general problem hoping i can convince someone to change it back to my liking"
this is just another expression of "i dislike change". it rarely, if ever, comes with a "why this option was really needed". [/quote]
While in some cases that is true, in many cases there is no truth at all there. Many people have given perfectly reasonable explanations of why something was really needed.
[quote]
when it comes to plasma, there are generally one of three reasons something has gone "missing":
* we haven't gotten to it yet (that's less an less these days, however)
* it was a BAD IDEA in the first place and caused problems for other options
* it was used by so few people that catering the software to those 18 people cost the other Nx10million unduly
[/quote]
The first I totally accept. To some extent I accept the others also. That does not mean that you can ignore the fact that some people do have reasonable requests. It's only when they are told that what they want will not be done, without any explanation, that they get really angry.
[quote]
software that is used by many will often compromise on the exact feature set. there's a reason why plasma is so flexible, though: so that when people want to make changes that only make a specific vertical market happy they can.
those who complain because the don't put the effort in to do so do not gain any sympathy from me.[/quote]
Nor do the whiners get any sympathy from me. The ones that explain their problem and are ignored do get my sympathy. They are definitely entitled to a reasonable explanation if they are to lose something they value.
[quote]
"KDE appeals to people who like to configure every last thing."
yes, it may appeal to those people. but the vast, vast majority of our users out there are not those people. if we focus on those "configure every last thing" people who use our software, we screw over the 98%+ of the rest of our users. how is that fair? [/quote]
So all the people who have made a case here in these comments are not the people you want to appeal to. Nice to know where we stand.
[quote]
"Taking away options is not the right path - sane defaults are the key to helping new users."
this completely ignores the fact that some options are mutually exclusive, some options are plain stupid (recently someone added an option to not focus the edit line in a widget when it was clicked on; what's the use case for that?!) and that there is limited room in both our maintenance schedule and our config ui to support them all. [/quote]
I said "sane defaults". I do not see anything in your argument that refutes that.
@Tom: "Mine and TomWinklers posts were not "make me a dock" posts."
yes, i know.
"It was valid critism of the current state of the taskbar (esp. in vertical) and multi monitor support.
I don't think posts like that need to be deleted."
they were not only off topic, they stooped to name calling and what not. i have a zero tolerance policy for that. you can be civil and get a civil response, or you can decide to not be civil and find somewhere else to discuss things with other people.
"And saying that we should pay for those features or send patches is a cop out on your part."
why, because i should implement everything you want right now the way you want it, regardless of what other people need or what my time allows for? that doesn't add up.
"There are patches."
where?
"They are just not integrated because they don't fit into some grander KDE vision."
i can't say without know which patches you are referring to, but i don't know of many projects (or, any, for that matter) that have a "any patch, even if it's broken" policy.
but show me the patch, and i'll happily look at it.
@AnneW: "Many people have given perfectly reasonable explanations of why something was really needed."
sometimes they have; and in those cases we've usually eventually gotten to it.
sometimes, though, it's something that only affects a very small number of people in a very specific set of conditions. it's not realistic to include every possible feature and option that someone may find useful.
in the past many features/options were offered in kicker/kdesktop that weren't very helpful to many people at all. there have been places we've exchanged one feature for a another feature (or another whole set of features in some cases) that is more useful to more people and/or can be presented in a more approachable manner.
it isn't -only- "was there at least one person out there who decided they liked that option in previous versions". the decision making process is a lot harder than that.
but please, give me something specific. talking in generalities is really, really hard because these are all case-by-case judgment calls.
"That does not mean that you can ignore the fact that some people do have reasonable requests."
and we do address those as we can. there isn't a pattern of behaviour here where we ignore requests, including some that aren't exactly "reasonable". so i refute the basis of your comment here and find it a little unhelpful as it just gives others fuel to jump on the flames and go, "see, see! they don't listen to people! that person said they don't!" when that's really not the case.
we're talking about a small fraction of people who get denied in their request. those same people who are also, btw, making it a mess for everyone else.
"It's only when they are told that what they want will not be done, without any explanation, that they get really angry."
sorry, but that is patently false. there are many people who have been given patient and extensive explanations who still get angry. in fact, the _majority_ of angry people i've faced in the last few years have started out receiving a reasonable, patient answer that they decide they won't accept and that i am now some sort of evil that should be dealt with angrily.
those people do make it less probably that such patience remains the norm. which is sad, but to be expected when people abuse a commons.
"The ones that explain their problem and are ignored do get my sympathy. They are definitely entitled to a reasonable explanation if they are to lose something they value."
you keep making this accusation as if its something that happens regularly.
so show me the examples. perhaps i need to apologize, recant or improve in some way. but i don't know of any such pattern in behavior.
"So all the people who have made a case here in these comments are not the people you want to appeal to."
there are also other people who have made other cases in these comments. also, the bulk of KDE users don't read my blog, don't know i have blog and don't even know i exist.
this blog is not the parliament for KDE decision making. it is a place for me to express my thoughts and for others to respond. it is not a representative sample of the people who rely on KDE.
that said, i do want to appeal to the people here. but not at the expense of others. an it would be nice if we could all understand that sharing a software product means making some compromises to do so.
"Nice to know where we stand."
i really don't want to deal with snide comments.
"I said "sane defaults". I do not see anything in your argument that refutes that."
the suggestion was that sane defaults would allow us to avoid being careful about feature additions.
i am trying to show that even with sane defaults there are mitigating circumstances which still require us to do so.
i'm not refuting sane defaults (quite the opposite, as can be seen in other comments i've made here), i'm refuting that they are a solution to unlimited or poorly chosen sets of options to offer the user.
Its a "program", not a plasmoid, widget, gadget etc etc etc
Widget is used in economics as an arbitrary product.
The point about the jargon is correct, in contracts there is usually a "definitions" section just for this very reason.
As to the functionality proliferation I don't think removing it is necessarily the best solution. Making the most used or most useful easily accessible on the top screens, and burying the less used a few screens deeper might be a better solution.
@Ian: program has another meaning already, actually. as does application. fun, isn't it? in any case, these little things are being called "widgets" or "gadgets" more than anything else.
@bigpicture: "The point about the jargon is correct, in contracts there is usually a "definitions" section just for this very reason."
that's a good analogy ...
"As to the functionality proliferation I don't think removing it is necessarily the best solution."
that's a vast over-simplification of what i wrote.
"Making the most used or most useful easily accessible on the top screens, and burying the less used a few screens deeper might be a better solution."
i've explained above in the forest of comments why that doesn't work out very well either.
Aaron, I understand what you mean but most normal users not involved in the IT industry will not. To a normal user the name "program" is meaningful to them. Even "application" is IT jargon to the normal user along with widget etc. If you ask a lot of users about memory, they cannot even differentiate between hard disk and RAM.
@aseigo [quote]sometimes, though, it's something that only affects a very small number of people in a very specific set of conditions. it's not realistic to include every possible feature and option that someone may find useful.[/quote]
Few would deny that. However, there are other things that do have significant effect on workflow, where a problem has been known since 4.0. You ask for examples. The vertical panel has been mentioned here. It has no significance for me, but there are others where it has a great significance in their working day. And it's not just one or two people. On the MLs I see many people asking when it will be workable.
[quote]there isn't a pattern of behaviour here where we ignore requests, including some that aren't exactly "reasonable".[/quote]
I have never denied that - in fact I have said so many times on MLs. The cases I complain about are in fact few, but like the example above, affect specific areas of the user base. For my own needs, little is missing now. For the needs of some others they are probably only missing one or two things, but they are very significant to their work.
I do not and will not give any support to those who simply whine because things are different from the last x years.
As for angry people, I totally agree that many are in fact quite unreasonable. I should have made it clear that I was talking about the small group that have a legitimate concern, such as those needing the vertical panel.
[quote]that said, i do want to appeal to the people here. but not at the expense of others. an it would be nice if we could all understand that sharing a software product means making some compromises to do so.[/quote]
Of course, but compromise in something that looks and feels nice is one thing, and compromise in something that seriously affects your work is quite another. There are many people that have claimed that KDE4 aims at those who want eye candy, to the detriment of those who want to use it for serious work. I do try to refute this, but sometimes find it difficult to give a convincing argument. I do believe that we need to have a convincing answer to this, and it probably needs a good deal more thought than we can give in this thread.
[quote] "Nice to know where we stand."
i really don't want to deal with snide comments. [/quote]
Not a snide comment, but a frustrated one.
[quote]i'm not refuting sane defaults (quite the opposite, as can be seen in other comments i've made here), i'm refuting that they are a solution to unlimited or poorly chosen sets of options to offer the user.[/quote]
It seems to me that people work with good intentions but without any concrete knowledge of what is actually needed, and what is merely wishful thinking. How do we get meaningful statistics about things like this? I don't know, but I think we have to find a way.
Please understand, I totally accept the good intentions of KDE developers. At the same time I'm seriously concerned that they are having to make judgements that make sense within their development work, but without any way of knowing to what degree those decisions will impact work. I'm calling for a serious think about how we can address these problems, not simply ranting.
Hello,
I'm sad to see that my posting was deleted. I'm not sure why this was done - I do not think that I used e.g. any rude language. If I did hurt anybodies feelings I hereby would like to apologize for that. Still I do not believe that simply deleting posts that do not conform with what others are thinking is an educated, grown-up way to deal with criticism.
All I wanted to point out is an issue I have with the current behaviour of KDE 4's panel. I try to stick with the established mechanisms within KDE to deal with such wishes (see bugs.kde.org ID 206721). If this request is not considered a valid issue by KDE developers then that is something I have to deal with (unfortunately I do not have the skills to produce a patch myself). But what I would hope for is some explanation why exactly this is not a valid request. So far nobody could give me an explanation of the design background why the KDE 4 panel in a multi-monitor setup can not / should not / must not behave in the same way as it did with KDE 3.5 (or as it does in Windows or OS X).
Thank you,
Thomas
@TomWinkler
I reread the commentss. They were a bit whiny, but still valid and I don't see any name calling or them being off-topic as Aaron claimed.
People probably get defensive when you suggest taking something away from them. That is why these comments are bit more heated than usual. IMHO FOSS should treat regressions very seriously, like the kernel do.
The broken vertical task applet is well known, there are a lot of patches to make it icon only for example (as an _option_ so it is very valid here http://mail.kde.org/pipermail/plasma-devel/2009-January/003339.html )
It may not be the perfect solution, but it is better than shipping another 4 versions of KDE4 with a broken applet.
I don't want start a flamefest, so feel free to ignore this comment (ignoring is better than censoring.)
@tomwinkler: "Still I do not believe that simply deleting posts that do not conform with what others are thinking is an educated, grown-up way to deal with criticism."
Neither do I; but that wasn't why I deleted your comment. I agree that we should deal with things in an educated, grown-up way. When your comments reflect that concept, they won't get deleted.
"All I wanted to point out is an issue I have with the current behaviour of KDE 4's panel"
That's fine. Note that it has been done numerous times and isn't remotely on topic for this blog entry. I know that "on topic" doesn't stop people, just do it with some style and respect next time.
"So far nobody could give me an explanation of the design background why the KDE 4 panel in a multi-monitor setup can not / should not / must not behave in the same way as it did with KDE 3.5 (or as it does in Windows or OS X)."
It has been explained extensively on bug reports on bugs.kde.org, along with what I'd like to see as an improvement for that. My time is too limited to repeat this for each individual, but it is on "the public record" so to speak on bugs.kde.org.
I'll also stress once more in case it was lost on you that when you come at me like you did in your previous comment, I deprioritize your issues so that I can deal with other issues of similar important from people who know how to be civil to others. When you treat me with the respect others, particularly those who are giving you their time for free, deserve then you get what you want faster.
I have more to do than I have time, so I have to pick and choose. Your behaviour helps me decide how to do that.
@Tom: "They were a bit whiny"
They were more than whiny. They resorted to name calling and what I could best describe as "hissy fits".
"That is why these comments are bit more heated than usual."
If you wish to let of steam, do it elsewhere. If you wish to discuss things you are passionate about, do so with some style. But no matter what you do not have the right or privilege to drag non-constructive garbage into my day here.
"IMHO FOSS should treat regressions very seriously, like the kernel do."
Treating things seriously doesn't mean treating each other badly.
"The broken vertical task applet is well known, there are a lot of patches to make it icon only for example"
There are actually very few patches, and:
"It may not be the perfect solution"
Exactly; it has issues. There are better ways of dealing with it, and as I noted in my reply that while that patch reads fine that I'd rather see a dock widget that provides such functionality rather than making the current tasks widget even more complicated both internally and for user configuration.
What's odd, in light of your belly aching about regression, is that right now the tasks widget behaves nearly the same in a vertical panel in plasma as it does in kicker. I just fired up kicker to check.
Here are the differences:
* kicker's tasks widget doesn't expand to take up space; it will crunch down into tiny little buttons
* plasma's tasks widget draws a button around the entire item, taking some space from the left / right edges
* kicker allows hiding the icon so you have just text
beyond that (and looking a hell of a lot better visually), plasma offers mouse-over thumbnails that work much nicer (including being able to click on them) and integration with kwin features such as the "peek" effect. kicker didn't.
plasma allows you to manually re-arrange or group task items. kicker didn't.
plasma allows you to change the svg and therefore the look of the taskbar, kicker offered one of three visual options none of which were themable.
so it seems we're doing pretty well in the regression area, given that we have gained several features that were OFTEN asked for. manual arrangement was probably #1 amongst those. that was a non-trivial amount of code (it still has some issues here and there, actually) and was done because people requested it for years during KDE 2 and 3.
"but it is better than shipping another 4 versions of KDE4 with a broken applet."
You know, I'm running a vertical panel with a taskbar in it right now, and I honestly don't see what is overly broken with it.
One thing I have noticed is that it's really hard to drag new items (e.g. launchers) on to a vertical panel once it has a tasks widget on it. There's an easy fix for that, however.
"ignoring is better than censoring"
You won't get censored if you behave in a civil manner. It's not hard, but I do require it of people who wish to engage with me. Life is too short to do otherwise.
This is 100% verbatim copy of what I wrote:
"
But shipping a fairly broken vertical taskbar and exspecting the user to hunt down out-of-repo kde-apps to get it working (or install something else) and ignoring/rejecting patches to ease users pain does not seem like the best solution either.
Windows 7 taskbar and OSX Dock work just fine in vertical.
That is what a user considers a basic requirement, those have to be met by what ships as default. There are no excuses IMHO.
"
I know I could work on my tone. For that I have to apologize. But I don't see the name calling.
My gripe with my narrow vertical task bar is that the icons are really really small (like 2x2 pixels) and the text is unreadable, so it is quite hard to tell tasks apart. (KDE 4.3 Kubuntu 9.10)
Maybe do an automatic switch to icon only when the text cannot be displayed because there just isn't enough space?
@AnneW: "Few would deny that."
Many do, particularly when it comes to their pet feature.
"However, there are other things that do have significant effect on workflow, where a problem has been known since 4.0."
Extremely few such issues, with many others where things are much better than they were in KDE3.
"You ask for examples. The vertical panel has been mentioned here."
It's a bad example, though. It has been improved quite a bit during the KDE 4 releases and actually now behaves very similarly to what Kicker did.
"It has no significance for me, but there are others where it has a great significance in their working day."
There are many others who have their own issues as well. To reiterate what I've said elsewhere before, there are three kinds of issues:
* those we're getting to
* those we've fulfilled in a novel way (usually improving on what was before despite protests; c.f. folder view)
* those we do not regard as valid due, but always with good reason and thought put into it
"And it's not just one or two people. On the MLs I see many people asking when it will be workable."
It is workable. I'm looking at my vertical panel *right now*.
"The cases I complain about are in fact few, but like the example above, affect specific areas of the user base."
I was responding to the issue you raised that people were not getting an explanation, which is untrue.
"I should have made it clear that I was talking about the small group that have a legitimate concern, such as those needing the vertical panel."
A better example is Tom Winkler's issue. I have offered explanations on bugs.kde.org. So again, aside from wondering why people aren't offering patches to fix things properly, I don't know what else to offer.
"compromise in something that seriously affects your work is quite another."
With 4.3 such statements border on the dramatic.
But some people will have gotten used to working in a certain way because there were mis- or poorly thought out features in software they used previously. Those ways of working may no longer be supported as the software progresses and provides new, usually better, ways to accomplish certain tasks.
I've been through a large number of projects in the past (several of which were proprietary projects) where this same thing has happened and it tends to work out for the best in the end.
Still, for some of the remaining issues, we'll get to them eventually, unless someone steps up and does some work just as we are first. We're also working on a large number of projects that are equally and in some cases far more important than "how many pixels does the vertical taskbar use in KDE 4 versus KDE 3" and those need time and attention too.
"There are many people that have claimed that KDE4 aims at those who want eye candy, to the detriment of those who want to use it for serious work. I do try to refute this, but sometimes find it difficult to give a convincing argument."
It's quite easy to refute as we can point to feature after feature that has nothing to do with eye candy and is about pure functionality.
I won't even get into the brashness of suggesting that they are the ones doing "serious work" as if others aren't or that "eye candy" has no practical value (some of it is extremely practical).
But even if we list features, like the one I mentioned earlier in reply to Tom about manually reorganizing the entries in the tasks widget, many of those people will reply with: "but that has no value to me, this is what matters to me" right before they launch right back into their pet feature and their serious work habits.
"At the same time I'm seriously concerned that they are having to make judgements that make sense within their development work, but without any way of knowing to what degree those decisions will impact work."
This is a baseless concern. Find me on irc or by email and we can talk further about it, but this is so far out into left field that I'm quite honestly dumbfounded at this point.
@Tom: "For that I have to apologize."
Thanks; I appreciate that.
"But I don't see the name calling."
That was in Winkler's comment.
"My gripe with my narrow vertical task bar is that the icons are really really small (like 2x2 pixels) and the text is unreadable, so it is quite hard to tell tasks apart. (KDE 4.3 Kubuntu 9.10)"
We've been through this discussion how many times now? Write patches or leave it alone. It will eventually get addressed, sooner if someone steps up and improves it properly before I get to it. Until then, I'm completely uninterested in discussing the topic, doubly uninterested in being chided over it and triply uninterested in people bringing it up on blog entries that have nothing to do with the topic thereby diminishing the possibility of talking about the rather serious issues I raised in this blog entry originally.
No, wait. Keep options and configurability. The question of how to expose it is another issue entirely.
Allow the distromaker to create (eg) "Easy" "Advanced" (etc) levels. In one case, the KDE configuration might be very limited (and maybe even done ahead of time based on information given by the user and/or derived from past actions). In the other they get more info.
Of course, who creates these interfaces into configuration can be anyone.
Point is to have configurations allowed and then separately exposed (through any of a number of ways).
[So a build of KDE might enable 1000 configurations, but a deployment might only expose 100.]
Guys remember, this is not a feature request page - By logic, it should only contain comments to Aaron's blog at hand. He is one developer of the many plasma devs, by specifically requesting aaron in his blog, you are implying that _he alone_ has to implement it.
If the feature exists in bugs.kde.org, I am sure that they will get in some day (In a much better form than what was requested) - but in time. There are just so many hours in a day directly implying that the number of features in a release is also limited. KDE 4.4 (I am using OpenSuSE snapshots) has come a _long_ way from KDE 4.0. I cannot even imagine that it has been just 2 years!
Coming to configuration, I'd want to add to Aaron.
Most of times, it is more important _where_ an option is rather than its simple availability. Having an option which cannot be found is useless. But finding out where to put an option and how it should be displayed is an art in itself. If it was up to me, all you guys would have text files! :-)
As an example, I am glad that the theme selection has been moved away (In 4.4) from the activity options - It just confused the user (Why does changing the theme in activity A change it for Activity B too?)
PS: I did not realize this issue till I saw it fixed in 4.4.
@k: "So who is KDE4's audience?
that question doesn't actually parse; different parts of KDE 4 have different audiences. consider the difference in audiences between KDevelop, Kontact and Plasma Desktop.
i assume you probably are refering to the KDE Workspace and Plasma Desktop in particular, so:
Plasma Desktop has to cater to the general populace that uses KDE, which happens to be overwhelming "average computer users".
we also need to cater to power users as well, and we do provide a large number of features, including easy extensibility, for them. the average computer user doesn't find much desire to manually arrange the items in their task bar, for instance.
i can tell you our audience is _not_, however: it isn't people who have never used a computer before (there are much better things we could do in that case than the traditional panels-n-desktops stuff) nor is it people who want huge dialogs crammed with switches to turn every pixel this way or that way (it conflicts with the goals of elegance and beauty).
"Did you abandon that idiot "Joe Average"?"
that's completely unacceptable here; find a civil tongue or i will start removing your comments as well. you could have said the same thing without being the negative arrogance that insults everyone who you lump into "Joe Average".
besides that, dichotomizing between "average" and "power user" is false. elegant interfaces can also be powerful and serve both parties well. it's generally the "i want tons of options, or at least MY options, and i self-identify as a power user" group that tries to lump all power users in with them. knowing many power users, i can confidently say that simply isn't true.
in that way, we're trying to free power users who want elegance from the tyranny of interfaces designed for the small population of power users who think high option density in configuration dialogs is the goal and that someone else ought to maintain and figure out how to rationalize all those features.
that audience's time has come to an end. they are a minority, they do not represent even the contributing population, and catering to such whims is not in the general best interest.
interestingly, some who previously saw themselves as being in that camp have, over time, decided they aren't. they now use KDE 4, MacOS or GNOME.
So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).
---------------
I think you are wrong because 'good looking' is a question of taste and personal choice as is 'highly usable'.
These claims can be made about many things and often are.
For example: I dont use the default themes, window manager or wallpapers.
There is no right answer to whether Air is better than Slim Glow (which I use) because its my choice as to which I find more usable while you have to make a decision for a default.
Great configurability can make good desktop better and more useful while 'Good looking' is a subjective judgement.
As someone who has very bad vision, what is good for some is not acceptable or usable for others in many cases.
----
I understand what youre trying to say but that thinking is often the mantra of the 'other group', less is more.
I know also that too many choices can be scary (whether it be in politics or distros!) for some but there are ways to have your cake and eat it and that's having an option for a basic setup and an advanced setup.
The newbie who needs the basic functionality is served yet not scared by the '300 options look' and the power users get all the configurability they need one button click away. (Im not taking account the extra code but this is about users.)
As a matter of fact I think all apps should be like that.
For example, having a simple interface for Amarok for those that want to use the basic functions (the Now Playing widget needs a few more options but its just about right) and one interface a click away for the full monty. Same for KDEnlive, simple interface for dad and the kids who want to put a few clips together with music and text and then put the videos on Youtube and have an advanced one with more options for more elaborate work.
I know many people who ask me if there is a simple Recorder program where they can record, crop and save in various formats because Audacity scares them. Why couldnt that program be Audacity but with a simple interface option?
One easy interface with the basic 5-10 most used functions usually covers most people's needs because they are creatures of habits.
This approach should also be used for various settings as well as.
I think VLC settings does this the best. You can choose the Show Settings button on either Simple or All and it serves you the options depending on your needs. I usually have it on Simple since it takes care of all I need but for the rare times that I want more, the option is there too.
One interface doesnt interfere with the other yet makes it less 'scary' to use.
PC
@v: "I think you are wrong because 'good looking' is a question of taste and personal choice as is 'highly usable'."
i think you missed the point of the article. which is: avoid making things configurable which don't need to be so that we can make more things that ought to be configurable, like good theming control for people with various visual or physical needs.
"I understand what youre trying to say but that thinking is often the mantra of the 'other group', less is more. "
no, more is more, but you need the right set of more. and that means cutting out the crap. less crap is more room for good options.
moreover, if we think hard about how we present things as options, we can often do so very cleanly and sometimes without even showing an overt "click this button to make it happen" type event.
(i didn't cover that last point in this blog entry, i thought it was already going to be hard enough to get the ideas across that were included; apparently they were :)
@k: "Great, how does kde4 deliver the new desktop experience to these different audiences? How do you satisfy all of them?"
i answered that, but what you seem to have also missed is that each of those applications have different audiences and so have different design allowances.
"Do they all need that light blue background with white balls?"
no, and so that's configurable offering a huge number of features along with it .. in an extensible way so that they can be easily added and removed using plugins. what was your point?
"I could be wrong but I get exactly the opposite impression - that kde users are very diverse with very very different needs. There isn't much uniformity here."
if we want to get technical, there is no "average joe". "average joe" is an amalgamation of the middle, and they are a very diverse group. diversity, however, does not mean that they all have different needs for everything.
in the case of "how do i interact with the flexibility provided by the software" it's actually pretty narrow.
and kde's user base long ago crossed into being mostly "mainstream".
"Depends on what is perceived as elegant and what's the purpose of "powerful" tool"
well, yes, which is what i pointed out in my first reply to you.
"for example I would never call KDE4 in its current state elegant"
that's fine; perhaps it's not for you.
"μTorrent and VLC media player on windows platform have tons of options, do you know how madly popular they are?"
look at who the audience for bittorrent and alternative media players are and what they are expected to do. besides that, i'm not sure either of those apps are amazing examples of design.
***
(i wonder how many people commenting here work in design? hm)
Removing options IMHO seems like doing justice for one set of people, and alienating the others.
As a user of a widescreen laptop, each option to configure the toolbars, the Panel, apps like Kate & Okular - are all important for me.
You may hide the options, put them in an "Advanced" tab, or even make them accessible only when a specific shortcut is pressed ;-) But disabling an option altogether - I'm sorry, but that's injustice to me. I'd simply switch over because I can't get the most out of my screen.
Turns out that - at first glance the options seem wasteful. But when we're ticking that checkbox, we're really needing it.
I'd like to say a word about the "Joe Average" issue. In most discussions, when people talk about "Joe Average" they are actually talking about an age group - approximately 12-25, IMO. Let's look at the situation in Windows. There is a huge group that buy a computer with Windows installed. The menu gives access to the programs they most need for browsing, email, playing music and videos and maybe one or two more applications. They use them just as they come. Windows has had a degree of configurability for the last 15 years or so, yet only a small minority outside that distinct age-group actually use those options.
The key to this is that they do not do their own install. I'd offer as evidence the fact that a few weeks ago I set up two users' computers to KDE4, without giving them any instruction whatsoever. I made sure that the applications they use were easily found from Favourites or panel links. Interestingly, the only 'complaint' I had was the same from both of them - they couldn't immediately find how to shut down!
Setting up the visibility of their favourite applications was all I did, so I would say that the current defaults are actually pretty sane ones.
This is not entirely off-topic, as I hope I'm demonstrating that currently KDE4 does address most of the needs of both types of users.
Forgive me for being a little off the topic, but I just had a pleasant FOSS experience (Okular handling a large PDF perfectly on my tiny Linux laptop while Acrobat had big problems on my lean mean Windows development machine) and I was wondering: why do we programmers have whole infrastructures for handling bug reports and wishlists (Jira, Bugzilla..) but nothing similar for expressing support for existing features & products? Shouldn't providing positive feedback be of similar importance than bugs, something we would like to encourage our customers/users to do? Feature hunts in addition to bug hunts?
That way we'd have a way of knowing just how important something, for example customization, is to KDE users.
Anyway, this is my favorite FOSS blog so I decided to just post this here :P Now excuse me while I write a nice thank-you email to the Okular team :)
@GregC: That sounds to be something that should go on http://brainstorm.forum.kde.org :-)
The best example of option-itis,and its many symptoms (and how the developers finally brought it under control) is x264.
As the premiere h264 encoder, it's got tons and tons of options. So many, in fact, that if you spend any time on the doom9 forums in the h264 section, many of the questions were (and still are to some degree), how do I get good quality or what does this do?
Needless to say, lots of encodes popped up with crappy settings, or just bizarre/insane settings because people weren't really sure what the options were, or thought they knew better.
The first step was setting decent defaults for the important settings- this helped somewhat, but one of the major users of x264 didn't set these.
So one of the lead programmers developed a set of presets that handled all the common cases. He then forced the software to error out if a preset wasn't selected to avoid complaints about crappy quality.
Quality has gone up, questions have gone down, and it's now very easy to point to settings that work for the vast majority.
Whether this can work in a graphical program, I don't know- but it is clear that well-designed defaults make all the difference in the world.
@k: "hey are treated equally disregarding their computing excellence, hardware or application preference, introduced to the same ui."
go look through all the options that are provided (and yes, your pet feature evidently isn't one of them) and then realize that this statement is utter garbage.
"In that aspect you don't really innovate much more than other desktop environments."
compare plasma-desktop with plasma-netbook. consider that others haven't take the opportunity to do the same for their own ideas of how a desktop should be. consider that other desktops don't allow for such things at all.
@Steven: "He then forced the software to error out if a preset wasn't selected to avoid complaints about crappy quality."
so he didn't just set defaults, he limited the options available.
which is exactly my point.
if you carefully (not stupidly) limit the options you can offer more options with less headache for everyone involved.
your example is therefore not one of just "good defaults" but managing the possibilities.
@k: "hey are treated equally disregarding their computing excellence, hardware or application preference, introduced to the same ui."
go look through all the options that are provided (and yes, your pet feature evidently isn't one of them) and then realize that this statement is utter garbage.
"In that aspect you don't really innovate much more than other desktop environments."
compare plasma-desktop with plasma-netbook. consider that others haven't take the opportunity to do the same for their own ideas of how a desktop should be. consider that other desktops don't allow for such things at all.
@Steven: "He then forced the software to error out if a preset wasn't selected to avoid complaints about crappy quality."
so he didn't just set defaults, he limited the options available.
which is exactly my point.
if you carefully (not stupidly) limit the options you can offer more options with less headache for everyone involved.
your example is therefore not one of just "good defaults" but managing the possibilities.
I do understand and to some extent experienced myself the options in some KDE apps are overwhelming. I just wish & hope limiting them will be done elegantly and does not go overboard as with gnome. Moreover, few thoughtful options implies less bugs and more quality time of devs on more important ones. Cutting the features will have to be considered on case to case basis. I do have to appreciate the current pace at which the project progresses even with current featureset though ;) As for the other comments, the growth of KDE & Linux overall also means less techie people, meaning KDE must take them into account as well. We will have to think beyond our own, and think through KDE's vision.
As I already wrote in a comment to a previous blog entry from you, I think precise "jargon" (such as "plasmoids") is much better than fuzzy paraphrases (such as "widgets" which has at least 2 meanings within KDE and many more outside of it) which are hard for developers to understand (widget? Like QWidget? Oh, you mean a plasmoid!) and thus for users to get help with. They're also hard to search for in a search engine (to get help, again), as you'll find many irrelevant hits, whereas an invented "jargon" word will only match sites actually talking about the subject.
And often, understanding a fuzzy term is much harder than understanding a precise technical term: the technical "jargon" term is something you learn once and subsequently recognize and understand, the fuzzy paraphrases often vary from application to application (especially if you use non-KDE applications too, terms like "duplex" or "suspend to RAM/disk" have many confusing paraphrases) and can often be misunderstood (because some other app uses the same paraphrase for something different (see e.g. "widget", and generic words like "suspend", "hibernate" or "standby" can sometimes mean "to RAM" and sometimes "to disk"), because the paraphrase is not precise enough (e.g. is "print 2 pages on one sheet" duplex or 2-up? Not sure if that (bad) paraphrase is actually used anywhere, it's just an example because I don't remember the exact bad paraphrases I've encountered over time) or because the translation is ambiguous (e.g. in a firewall configuration application, does "sicheres Service" in German, which translates to "safe/secure service", but was used as a translation for "trusted service" because there isn't a word meaning exactly "trusted", mean the service is trusted to be "safe" ("sicher") to share or does it mean it gets made "secure" ("sicher") by the firewall by blocking the port; and yes, I've actually seen that term used in a (non-KDE) firewall configuration app, later versions resort to keep "trusted" untranslated instead; a precise translation of the word "trusted" would be some ugly paraphrase like "Services, denen vertraut werden kann" and even that would not be understood as easily as "trusted services")). And speaking of translations, some fuzzy terms like "widget" don't translate at all to other languages, so I'm not surprised some translation teams are using "plasmoid" (and using the local equivalent of the "oid" suffix, which exists at least in most European languages) instead. An untranslated "widget" will sound just as much as "jargon" to a French user as "plasmoïde" and there's no French word for "widget".
One of the reasons I like KDE is the great konfigurability. I *want* to read and understand options. Playing with things and configuring them the way I want is fun. Do retain the micro-options!
About configurability, as a developer I can understand very well its limitations: You have to draw a line somewhere or you end up with asking the user to basically write the program for you. ;-) See also Soft Coding (at The Daily WTF). But let's not forget in all this that configurability is one of the big selling points of KDE and what distinguishes it from the alternatives. So please don't refuse options users have a genuine need for, even if they are in the minority. (And yes, being able to turn off something really annoying the user is a genuine need, even if it doesn't strictly keep him/her from doing his/her work.)
This is a very well-written article, and I think it makes a good point: sometimes, there are features that the user simply doesn't want the ability to turn off somewhere. Dolphin's + selection overlay on icons is an example. Imagine if someone approached you and said, "Hey, those icons are really annoying me - give me a way to switch them off!" I know my answer would be, "No. Just... no." Sticking a tick-box in some configuration dialogue somewhere to switch that off, for the niche audience that might just possibly want to switch it off, makes no sense to me.
On the other hand, there are ways to give something MORE features without them being a burden: the Plasma team have done this especially well with panels. When the panel's locked, I can't change _anything_, which makes sense. If I want to change _anything_, the first thing I do is go for the toolbox icon on the right. That also makes sense. It's also much more pleasing to have the panel configuration attached to the panel the way it is, instead of having some configuration dialogue somewhere that only clutters my task-bar and spreads out configuration items so I have to go looking for them somewhere. It also beats having to configure, click "apply", check if I like the setting, go back and change it if I don't, click, "apply", check... (I know I've done this a number of times with Kicker.)
If I take the (supposed) leader of usability, Microsoft, and their panel (I suppose they call it a task bar) as an example, then we can see how, even though it's less configurable, the way the options are presented are just irritating. When you have the task bar unlocked, you can configure everything, but resizing the panel and moving (a very limited set of) the... erm, widgets (damn!) can be done right there, while auto-hiding... needs me to go and right-click on it, then click, "Properties", then search for some tick-box somewhere, click, "Apply" then click, "OK" for it to work. Then, when the task-bar is locked, you can't move anything/resize it... but you can still go to, "Properties" and find a bunch of stuff to change there, and even still remove widgets (or components, or whatever they call it in Windows). I find it daft, since locking the task bar isn't actually _locking_ it, it's just, "some parts are locked but some are still configurable for no explicitly given reason". After KDE 4.1, it almost feels cheap. After KDE 4.2, it IS cheap.
Totally agree. Having Apearance, Desktop and Display as different sections of the Control panel is ridiculous
Post a Comment