Appeal to developers: stop changing defaults from under people's feet

Hello! Let me start by actually thanking the developers for all their hard work and fantastic software. KDE software is absolutely amazing and I love it - and have loved using it for years, on all my computers.

Now, it is exactly because I love KDE software that I would like to make an appeal, which is especially relevant with Dolphin in recent months: please stop changing the defaults from under people’s feet. While I understand that you are acting with the best intentions, it very often produces bad results that break people’s expectations and muscle memory.

I will provide three examples. The first is the fix for bug 508196, which completely broke user expectations on how “create a new folder” should work. This caused quite the stir and it broke very well established conventions and people’s muscle memory. The second is bug 492404, which highlights how Dolphin was changed so that, when you navigate from a subfolder back to the parent folder, the parent folder itself isn’t selected any more. There is also bug 494125, which describes how double-clicking on a file opens it, but also deselects it.

All of these issues have good intentions behind them: they came from an attempt to prevent data loss or confusion. The problem is that they also break expectations built over about 40 years on how these things should work. They go against what literally everybody else is doing, has been doing and will be doing. Now, I know that saying “but the others are doing it differently” isn’t a valid argument per se; however, when taken in the context of “what are the user expectations?” it is, indeed, a valid point, because if users find a certain behaviour everywhere else, it is legitimate of them to expect it in Dolphin as well. To provide a further example of this: clicking on an empty space deselects whatever is currently selected; if this was changed on the grounds that it makes it more difficult for people with motory disabilities to select things and keep them selected when using a mouse (which is a valid concern!), this would break a key assumption and a behaviour that has been established for basically forever.

Another good example of “do not change defaults” is the one with the status bar on the bottom. The intention was to make Dolphin leaner and cleaner, which is laudable; the update, however, should not have changed the behaviour of existing installations as that broke what people expected and were used to. A system which has already been set up should not be messed with by the developers, unless that is absolutely necessary - i.e. if a component needs to be removed due to security reasons or other catastrophic issues.

All of the above issues have caused significant discussion and created a huge blowback. While some of the commenters went way beyond what can be deemed acceptable, the vast majority of people seem to agree on one fact: defaults which have always been in place (in Dolphin too!), which are still in place in all other platforms and which will seemingly always be in place in other platforms have been tampered with, breaking assumptions and muscle memory, and therefore workflows.

I, like many others, am passionate about the software I use; however, I want to use the software, not to re-learn how to use it every few months because a feature has been tampered with. I want to use KDE software to do other things - work, play, create, enjoy content. I don’t want to use it to spend my time re-learning how to use it and to fight against seemingly random changes. I think I can speak for the vast majority of people when I write this.

If there is an issue or a worry, please try to think out of the box. The worry about “files could be accidentally deleted” expressed in bugs 492404 and 492125 is valid, but the answer is not to change the basic behaviour of a critical component of our systems, the file manager, to appease this worry. The answer is to change the defaults on new installs (and I can’t stress this enough!) so that when you press the “delete” button it shows a dialogue asking if you really want to delete that file or folder. That dialogue already exists and makes sure that tech-illiterate, older, younger, disabled and other folks (including those with cats who jump on their keyboards) who might be affected by the “might accidentally delete something” issue are protected, while everyone else can keep working happily like they always have. This is also a part of what people talk about when they discuss the differences between KDE and GNOME and say that GNOME has saner defaults: because you don’t have to dig deep into the settings and/or change the way you work for such basic things. (and I say this as someone who does not especially appreciate GNOME, nor the fact that they do often force a certain vision on how to do things on their users!)

Before making changes to a fundamental component of our systems like the file manager, therefore, I invite you to ask yourselves: how does this change impact users? How does it impact their assumptions and expectations? How does it impact their muscle memory? How does it impact their workflows? Is this change making Dolphin behave in a different way compared to what most other file managers do? Is this change actually changing things in “live systems” where things will find that their setup has been changed without their consent after an update?

You’ve created incredible software that makes lots of people happy to use their computers. Dolphin is widely considered to be the most powerful file manager out there, and for good reason. It really is an astounding piece of work. However, in order for it to stay like that, I invite you to not break the unspoken promise between you and us, the users: do not constantly make changes that make us put in effort to re-learn how to use your software on every update. Especially with well-established conventions. Everyone hates this and for good reason! We want to use your software as means to do something else, not as a means to itself. So please keep up on the good work, and try to put yourselves more in our shoes before effecting small, but important changes.

Thank you!

6 Likes

Ah, but you STARTED with the Title…

What you are basically discussing are ‘teething’ issues AFAIK, with the ‘follow focus’.

The status bar is something I remember from Opera, and I really appreciate that…

Though some folks obviously want a thick bar with a ton of icons, I think it’s a waste of space for most of the time.

Well it seems obviously that such changes will ONLY take effect when a new version is installed. How do you define ‘new install’. Perhaps an LTS install, that will guarantee your Dolphin won’t be updated for a couple of years? But then when that LTS system gets a massive upgrade - is that defined as a ‘new install’?

How about mine, it gets a few updates every month - my install is ‘eternally new’.

Many issues only come to light AFTER the new version is released; but care must be taken not to confuse a couple of dozen people who inhabit reddit and YouTube with ‘the vast majority’.

It might be viewed as slightly insulting to suggest that our KDE Developers push out their little pet projects without asking themselves this question perhaps even more than any other…

But it does make me feel more justified when I laughed at your first classic first paragraph (Thank you, now I’m here to RANT).

Actually, I’d suggest that it has prompted many people to actually think about it for the first time… Certainly for a long time, if I wanted to create a folder ‘jpg’ inside another ‘sweet’ I would use F4 do:

➤ mkcd one/two/three
➤ pwd
/home/ben/one/two/three
 ~/one/two/three

So really, you’re not entirely right in your assumption.

There are many things which most of us just overlook as we use Plasma. I’d be interested to hear a very detailed (I mean exact, factual, and without missing any important information) about how this has really affected you in any real or meaningful manner.

I really enjoyed your reference to bugs 492404 and 492125, obviously Warnings when running DTrace testsuite under Valgrind (WARNING: unhandled eBPF command 23) is super relevant and interesting.

You forgot to mention also bug 451408 (a personal favourite) as well as 328987, 434175, and - well I’d like to go on but you must realise that splashing out bug numbers (from anywhere from Plasma 5.24) isn’t going to gain you any support in your arguments.

Dolphin really is great - but it does suck… and work is needed to make it suck less, not simply to make sure that nobody notices any changes.

Not everyone hates this…

And I absolutely reject your idea that I should allow developers to wear my shoes.

That’s just unhygenic!

:vulcan_salute:

A “teething issue” is something that eventually goes away. The changes made to Dolphin won’t go away, as won’t the friction caused by them.

That’s incredibly easy: you look at the one thing that changes between a freshly-installed system and one that has been used, so a “new install” is one that does not have configuration files already in place.

If you have a better idea on how to deliver constructive criticism, I am all ears.

Pal, relax. We all do mistakes, including typos. The link I put in is correct and I think that that is what is relevant in this context. My suggestion, based on this and the rest of your message, is to chill out. If you need to focus on a typo to deliver criticism to my message, I think you would be better off just going out and enjoying some sunshine. There’s no reason whatsoever for you to be this standoffish, given I haven’t insulted anyone (least of all, you).

1 Like

Woah, so you’re saying that over the past 9 years I should be denied my updates!!!

NO thank you. Just one silly question - if you installed KDE 5, how do you suppose you could survive until now without things actually changing?

I’m not just talking about the regressions, which are unfortunate, because what you seem to be implying is that if some changes don’t suit everyone, then they should never be implemented.

I think this argument is already lost.

Not really, just the fact that you start firing random bug numbers in - possibly expecting our developers to remember them all…

Last time I looked, when loading the bug list, it starts with something like the ‘top 500’ with many more besides.

However, stating that Developers don’t try to put themselves in your shoes, or think about their actions and the impact they might have, is truly ridiculous - and I’m surely not alone in thinking it comes across as being grossly offensive.

…no? I have never said anything like that, at all. Please don’t put things in my mouth!

It’s easy:

  • there are already configuration files: if there are changes like hiding something by which was already there by default, then the update makes sure not to change the visibility. This is what happened in System Monitor, by the way: there was an update which changed the pages; the pages which were modified by the user were preserved, so that the user could decide whether to use the new ones or keep the ones they had changed. This prevents friction.
  • there were no configuration files: you apply the new default.

It’s not like nobody ever gets new features (how would that even work?), it’s more that people who have customised their setup do not have settings altered. Sometimes that is inevitable (e.g. a feature is removed, or a completely new one is added), and in those cases it is obviously fine to go with whatever default the developers deem appropriate.

That is the reason why I included links, you might want to go back and check because it looks like you have missed them!

Again: I invite you to be less standoffish. If you won’t, I will block you and/or report you. Thanks.

2 Likes

I followed links…

One was for the behaviour about double-click to open a file also deselecting the file upon opening – is the expected and standard visual feedback in the “double-click” mode.

The single click of your double-click action first selects the file, and the subsequent action (the second click completing the double-click) is interpreted as the command to open it, at which point the file manager’s focus moves away from the selection.

It is also long held that ‘double-click’ is not the optimal answer - but is actually a default demanded by the masses (and something I’m willing to live with, as it’s the way I always worked and struggle without).

But you did insult all developers involved in the issues you described, first stating the obvious (warning them ‘not to disturb the way someone’s muscle memory works’ - however right or wrong it might be) and then stating that the ‘fix’ for one bug had unfortunate side effects…

This is to be expected… not complained about - we raise the issue and discuss it, then the project works out the best way forward.

The ‘other’ example you made was about folders being de-selected; and if you’d read through, it was established that the real problem there (which I agreed with) was that the issue was mostly about making sure that the highlight is more visible; which I can see has been actioned (and not only on Fresh Installed systems).

This bug report remains open, which means the developer is considering that the issue may be valid and the behavior could be changed back, or modified in some way.

I really appreciate that we now enter ‘selection mode’ if we go UP to a parent folder and hit the DEL key and touching the Spacebar to re-establish ‘SELECTED’ status is trivial at best… though I did notice in that discussion that @ngraham had an issue thinking the only way to achieve this was to use arrow keys (to move to another folder then back).

The truth is that, not only are KDE Developers constantly trying to ‘Think outside the box’ as well as put themselves in USER’s shoes - they are also trying to balance development with user expectations.

The bug to which you linked is actually about the UNDERLINE upon returning to a parent folder, and that bug has absolutely been fixed now… a few updates ago now, they made the keyboard focus indicator way more obvious.

It is no longer just an underline but a focus rectangle around the item.

However, this fix did absolutely involve changing an existing behaviour right from under people’s feet (though in my case, I prefer to use my hands).

I see that you have no intention of discussing in good faith and do a whole lot of projecting; I won’t answer to your messages any more. Enjoy your Sunday!

@Ben2Talk please try to avoid derailing discussions like this. The OP is clearly bringing up the topic in good faith and has made reasonable points.

@Slater91 Thanks for your patience. FWIW the new folder changes have been reverted, and I’ve submitted a patch to revert the selection changes, too: Revert "Avoid implicitly selecting items" (!1098) · Merge requests · System / Dolphin · GitLab.

Personally the status bar changes I think should be at least a bit less controversial, especially since unlike the other two, there’s an option to go back to the older style if you preferred it.

Software can’t remain fully static; there’s a give-and-take between “keep it relevant for the next generation and up to modern design standards” and “don’t break existing users’ workflows and familiarity” that can be very tricky to get right. We don’t always hit the mark, of course.

Personally I think what’s most important is that we have the humility to admit when this is the case and reverse course. There’s also the benefit of making changes reversible so people who don’t like them can self-satisfy. But this too has pitfalls since over time it produces “options overload” that people also complain about, and makes the software’s internal state more complex and fragile, increasing the number of bugs over time.

Nobody ever said software development was easy! :laughing:

11 Likes

I agree with the OP fully here. I’ve just jumped into the Linux desktop bandwagon, and selected KDE not because of its customizabilty, but rather due to the small learning curve of doing things in the KDE desktop the way I’ve used to in Windows. Even Windows+Shift+S worked for screenshots (and with far better options)!

Two points that I’d like to make:

  1. With regard to changes to existiing apps: I’ve passed my easy learning age though and I’d welcome my environment to behave the same way it did, with new functionality and tricks becoming opt-in options. Definitely avoiding UI unexpected behaviour after some package update.

  2. With regard to application defaults on fresh installations: In the majority of cases, the KDE user is someone that has already used Windows. What works out there for the masses is not something necessarily evil or sub-optimal. It could be the “default” (with minor changes, if absolutely needed), to make people feel at home. There’s a reason why CTRL+V is selected for copy, and even though selective paste (from a multi-paste-capable clipboard) existed before MS configured Windows+V to do so, the fact that KDE manages to make a Windows user feel at home is because some developer made the well-thought move to implement the same shortcut in KDE, instead of setting something else up. Or instead of giving the app a much different look. It does have more functionality in KDE, but its sane defaults are the same as what people are used to.

PS: Thanks for offering an awesome DE experience with plasma, which makes me and the family members right at home :slight_smile:

2 Likes

Thank you, Nate (also for the MR!), I appreciate you taking the time to answer. I wasn’t personally too fussed about the status bar either, but I thought that the way the change was implemented was poor as it wasn’t clear that a setting existed and that you could therefore revert to the previous behaviour, whereas the way System Monitor managed the transition to the new pages was great, as it gave the user a choice.

I agree that software can’t stay too static and I appreciate the fact that KDE software often manages to strike the right balance between innovation and keeping things consistent. I think, however, that sometimes there are things which should receive more care as they alter fundamental bits of the experience; the file manager is one of those things.

I see your point and I do agree that KDE developers often walk back when it becomes clear that the changes aren’t welcome by the users or otherwise practical/desirable/etc, and that is something I have always deeply appreciated (in fact, the management of feedback was one of the main reasons why I chose to switch to KDE!). What we, as a community, need to consider is also that some people will find that these changes to fundamental interactions are (sometimes) too slow to revert and will abandon ship. We shouldn’t let this dictate the development for everyone, of course, but nonetheless I think that the famous “first impression” by newcomers to the platform (the reason for the 15-minute bugs initiative, IIRC) and the fact that some changes will be seen as “bad enough that I will leave to another platform entirely" should be taken into consideration - or, they should be taken more into consideration than they are now. As much as I love KDE, I have personally sometimes thought of jumping ship to LXQt or other platforms that are surely less innovative, but also less likely to disrupt the way I do basic things.

2 Likes

That’s one bug. Just, nobody knew that until they fixed part of it, and it uncovered the other parts. It was a surprise. This didn’t happen because of the lack of forethought or care from the devs. It was just a tricky sonofagun.

I don’t think people are able to understand (because most people aren’t watching them do it all day every day like I am) just how deep the devs dig to make sure this kind of thing doesn’t happen, all the time.

No it’s not. Everyone can be wrong. It happens a lot, and it’s what happened here. Most people had a false conception of how selection works in this and every other operating system, and had a false understanding of how dolphin works compared to how every other file manager works.

People talk about this racecar as though it should drive and haul like all the trucks, because they all have four wheels and an engine. I know a baby-boomer who complained about the broken accelerator in their first electric car.

Get me? Dolphin isn’t like the others, and it shouldn’t work like the others. And people sometimes think they understand how the mechanism works, only to find out they were wrong. That’s not the fault of the mechanism.

Now don’t get me wrong, devs should still account for that, and find a way to make it work the best that they can, and make it feel right, etc, sure… But that doesn’t make a false expectation any less false or more legitimate.

And KDE devs are already busting their hump to avoid stuff like this… Obviously.

2 Likes

No, it was three different bugs stemming from three different MRs which changed the way Dolphin works. It was no surprise: they were the products of intentional changes to how Dolphin should act; as much as those changes were well-intentioned, they were also ill-conceived, because they changed the way Dolphin works at a fundamental level. Even Nate, in the MR he linked, said that he couldn’t get used to the change. I think that Felix and Meven, who effected the changes, had good intentions, but didn’t think that the changes would be as problematic as they turned out to be.

I do get you, just like I got ben2talk, but I think you are wrong. To use your example, you do expect the accelerator pedal to make the car accelerate. If it acts as a brake because you swapped the two, you do have an issue because everyone will be confused. If all cars have the accelerator pedal in the same place, you have to put it there, too, even though it might not be the best design ever. People will complain if you put it somewhere else and they will have every right to, since literally every other car in existence has the accelerator in the same place. You don’t want to re-learn how to drive every time you try a new car, you just want to be on the road and get where you want to.

2 Likes

No, you don’t get me. You’re miles away from the point I’m making.

Yes, it was one bug. Nobody knew that, so it existed in several MRs and bug reports. None of those MRs or reports can be separated in their effects. Changing the behaviour of any one of these issues directly effects them all. It’s one bug.

It was no surprise

It was a complete surprise, obviously. Don’t be silly, nobody knew that all this would happen and went ahead anyway. If the relationship between these bugs was known, they would have been rolled into one bug report way back then, and handled together.

they changed the way Dolphin works at a fundamental level

Yeh, they fixed it. It only had one actual faulty behaviour left which was that nested folders in detail view thing. But people were used to it being broken, so fixing things wasn’t necessarily as smooth as it should be.

I’m one of those people. Like Nate who you quoted and like most of us, the change threw me for a loop. The difference between you and I is that I’m looking for an actual solution that fixes it and does NOT throw us all for a loop, but IS technically correct and properly functional. You’re willing to gimp Dolphin so it will feel like Explorer, and you don’t have to learn to drive an electric.

Regarding the accelerator pedal: it’s not an accelerator pedal. It looks kinda like one and acts kinda like one, but it ain’t one. The driver was wrong. Just like how the users here thought they understood how the selection mechanism worked, because Dolphin’s one looks and acts kinda like Windows’ one, and were wrong.

It’s a reasonable mistake to make, and a mistake nonetheless.

Yes they will and they do have that right. And immediately after they find out they’re doing it wrong they should “oh I’m doing it wrong, this is a me problem, it’s actually working correctly” and not do it wrong any more and stop complaining. But they don’t because that involves admitting a mistake. And here we are.

But regardless of users failing to understand the machine they’re driving (fair, not everyone is an engineer) and complaining about the mechanism (fair, it was confusing at first) because they operated it incorrectly, and then lacking the ability to recognise the error was theirs and not the mechanism’s…

NONE OF THIS SUGGESTS ANY FAULT BY THE DEVS. The oversight you imply with your post just doesn’t exist. On the contrary, the devs already try very hard to make sure that problems like this doesn’t happen. All the mistakes, dev side and user side, leading up to this, are totally reasonable.

The part where the wheels fall off is “it must be KDE because I don’t make mistakes and it should work like Windows even though this is totally different and that makes zero sense, and also, devs, stop doing this, why would you do this on purpose”

Dude, as if they need to be told not to do it. As if they do it knowingly. That’s the point you’re not getting. The implication you make with this post is an oversight by the devs, which simply doesn’t exist.

People raging at the devs for something they didn’t even do is a bit much. This entire thread is just for you to vent without being in the existing thread.

Again: I understand you, it’s just that I think that you are wrong in your approach. I think the difference between us is that I think that there is no “technically correct” and “properly functional” solution. I think there are conventions, like where the accelerator pedal is, and if you deviate from them, you throw people in a loop. I’ve never said that the solutions that the developers found were inferior or incorrect; I have said that they are impractical because they deviate from design rules which every single file manager out there follows and has followed for the past 40-odd years. So it’s not a matter of “gimping Dolphin”, but of making it useful and relevant for everyone by leaving the accelerator pedal where it is.

I find it funny that you say that I think I don’t make mistakes because, like ben2talk, you come across as if you think you are the one holding the Truth with a capital T, and everyone else is wrong. I’m afraid that is not the case, and I have found through experience that normally, if you happen to think that way, you are the one being wrong. You are not the only one understanding how file managers work and/or should work and no, other people are not wrong for disagreeing with you on that point. If I can give you a bit of (unrequested, fair enough) advice: get off your high horse, because it’s easy to hurt yourself if you happen to fall off it!

Just to be clear, in case that wasn’t apparent from all I’ve written, I am not saying that I am right or that one solution is better than the others. I am saying that in order to make the platform usable and more appealing to a wide audience, it is useful to not make it work in a completely different way from what everyone else is doing. If you think that it is advisable, I invite you try selling a car where the brake and accelerator pedals are inverted. Apart from laws preventing you from doing that (for rather obvious reasons), I think you might find that people wouldn’t buy the car (again, for rather obvious reasons).

4 Likes

I really don’t understand why you have to be so utterly and indefatigably unpleasant and confrontational, but that is ultimately your problem. Just like with ben2talk, I’ll end my replies to you here.

Before that, however, since you think your opinion is correct and everyone else’s is wrong: yes, I did do my research, and that is why I invite you to look up “principle of least astonishment”. It is something that designers of everything need to take into account (you might even say it is the technically correct way of doing things). You might also want to read “The design of everyday things” by Donald Norman. You might find that your “Truth” is, after all, just your opinion (and that, from the perspective of the PoLA, it is the… least optimal one too!).

Have a good start to your week!

there is alot of back n forth here and linking and talking about bug that i haven’t looked at but generally i’ll say i agree with OP .

for example when spectacle got an update not too long ago it changed the default behavior from having a menu with the options to not having them and just the area by default . it was confusing and i made a post about it. thankfully someone was nice enough to tell me how to revert things to show the settings it previously had , but the issue was they took something i used often enough and all of a sudden it was different without my wanting it changed to have a different behavior on opening.

its changes like this that i think OP is getting at that your taking something thats already working X way for a person and making it do Y instead. its not that Y isn’t good for some ppl but its not the same and causes confusion that could be avoided by not messing with something thats already set ,even moreso if the option to revert is there. instead i think something in this given case would’ve been hey we made these improvements to this or that and if you want it to function this way instead of the old way its in the settings/options vs taking the old and changing it to the new.

anyway sorry if this is worried poorly , i haven’t been up long and i’ve been sick so my brain isn’t all there.

1 Like

Mods, you can’t just remove things because people complain. I didn’t say anything offensive. I’m allowed to defend myself when people put false words in my mouth.

Not really. The change you’re talking about was intentional and there was good reason for it, but it was an actual deliberate change of the default behaviour. OP is complaining about an accidental unforeseen side-effect of resolving a bug.

1 Like

@ben2talk your sound a bit harsh on what the OP presented: he took the time to present some issues when changing the way an app interacts, presenting actual cases and his arguments. Stating “OP isn’t interested in solutions, only in preserving their personal status quo” sounds a bit on the offensive side, considering he detailed specific cases, provided solid arguments (with which I also agree as a recent KDE user), and also outline a (not the best possibly/probably) approach to deal with these changes:

The answer is to change the defaults on new installs (and I can’t stress this enough!) so that when you press the “delete” button it shows a dialogue asking if you really want to delete that file or folder. That dialogue already exists and makes sure that tech-illiterate, older, younger, disabled and other folks (including those with cats who jump on their keyboards) who might be affected by the “might accidentally delete something” issue are protected, while everyone else can keep working happily like they always have

Granted, this is something propose by a user, devs might have a better look at what could/should/might be done. Still, please keep in mind we are all here because we like KDE, and want in our (even non-techie in my case) way to push it forward to keep working better.

You mention release notes and changelogs. A lot of people do not even know what these are and never will. I’ve installed Linux on a laptop given to my 85-year old dad and I’m reaching 60. Expecting things to be operating the same way is always an advantage. IOW, documentation is always needed, however it is not “visible” by many users out there.

What sounds much better is your second bullet:

What I mostly disagree with is your last line:

The summary of the OP and the views supporting do come down to three things basically:

  1. it is a plus for a KDE app to behave like other desktop environments out there (windows included)
  2. for existing installations, and for apps that have workflows similar to other environments, please do not change them when introducing different ways to do the same thing; do notify and educate on the alternative way, which might be enabled by a GUI option
  3. finally, for new installations, it is a toughie: does one prefer to offer an environment with an option configured so that certain functionality is functionally consistent? Or is it preferred for the option to be configured so the certain functionality mimics what is out there?

The post here is not some rage against devs. What it is, is constructive criticism, supported by other KDE users as well (even if the title comes off a bit, the OP is excellent in describing the issue, providing specific examples, and offering some possible way to implement new functionality). If certain devs or other users do not share the same opinions, it does not necessarily invalidate our own. After all, what matters in opinions is not only their popularity, but also their validity. And in this latter part, we do have some valid points and we do want to keep working with KDE. So thanks for taking the time to read this long post.

PS: This is a bit OT. Stopped working with UI design some 20+ years ago, but intended to ask: is there some general Plasma documentation for guidelines?

2 Likes