The OK button can also be "Open", "Select", "Delete", etc, but let's say they are OK buttons. Rationale: - Having an OK button in the window corner makes it easy to see that it is a primary button. - In many dialogs the OK button is highlighted with an accent color. Visually, IMHO it looks better if the highlighted button were in the window corner. - Some dialogs have an OK button but no Cancel button (e.g. KCMs, "About" screen in plasmoid settings windows). Always placing the OK button in the bottom right corner will be consistent with those dialogs. - In dialogs with "Next" and "Back" buttons (e.g. plasma-welcome), the Next button (approximately OK button) is placed on the right and the Back button (approximately Cancel button) is placed on the left. This proposal matches those dialogs as well. (Rightmost buttons are primary.) - GTK, Chromium and Firefox have adopted it. Matching the basic UI layout with those popular third-party apps improves the user experience. - Other systems like Material Design, Android, iOS, macOS and GNOME have adopted it. So it's easier to use for people who are familiar with them. (I'm not sure about Microsoft's Fluent Design though. Looking at their doc, OK buttons may be placed leftmost, rightmost, or neither.) ----- I'm sorry if this is not the right place to report. I'm unsure if a normal user like me could file this to the plasma-desktop repo directly...
FWIW, I asked ChatGPT "OK button v.s. Cancel button; which should be on the bottom right corner in dialogs?" and here's the answer: --- START QUOTE --- Traditionally, in dialog boxes or user interfaces, the "OK" button is placed on the bottom right corner, while the "Cancel" button is placed next to it, on the left. This convention has been followed in many operating systems and applications for several reasons: 1. Visual Hierarchy: Placing the primary action (usually "OK" or "Confirm") on the right side draws attention and emphasizes it as the default or preferred choice. 2. Reading Order: In cultures that read from left to right, the natural flow of reading moves from left to right and top to bottom. Placing the "OK" button on the bottom right aligns with this reading pattern. 3. User Expectations: Users have become accustomed to this layout over time, making it a familiar and predictable pattern across various applications. Deviating from this convention might lead to confusion and an inconsistent user experience. 4. Accessibility: It is essential to consider the needs of users with disabilities. Placing the primary action button on the bottom right ensures that users who navigate through the interface using keyboard controls can easily find and activate the main action. However, it's important to note that design conventions can evolve over time, and different user interfaces or platforms may adapt to newer layouts. Always consider the specific context, user base, and platform guidelines when designing dialog boxes or any other user interface components. If you are designing for a specific platform or application, it's a good idea to review their design guidelines and recommendations for button placement to ensure your design aligns with their conventions and provides the best user experience. --- END QUOTE ---
Please do not try to convice us to do something by telling us what ChatGPT thinks is a good idea.
(In reply to Tobias Fella from comment #2) > Please do not try to convice us to do something by telling us what ChatGPT > thinks is a good idea. Sorry, I thought the reasons are interesting and might be worth sharing for your reference. I don't intend to tell something like "ChatGPT thinks it's better, so you should do this"...
In don't find any of those reasons particularly compelling; I think this is one of those things that doesn't really matter as long as you're internally consistent--which we are. So any issue here is for users migrating from another platform who can have their muscle memory and expectations respected or broken. We're basically copying what Windows does here, so if we change, we'd be breaking the expectations of migrating Windows users. But by sticking with the status quo, we break the expectations of migrating users from other platforms. Do we get more people migrating to Plasma from Windows, compared to other platforms? Probably. But that's just a guess, I don't have numbers. Maybe I'm wrong. Because this isn't really a case where there's an obvious right answer, and we lack the data to say that making a change would improve things on average, I think we won't be making a change here. But thanks for engaging anyway!
Thank you very much for your consideration. Personally I still believe that the "Cancel/OK" button placement is obviously better from the viewpoint of UX and consistency, though. For example this article explains very well why OK buttons work best on the right, with visual images: https://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/ Particularly the three visual fixations mentioned in the article (OK->Cancel->OK) are quite annoying to me, which I don't experience on other platforms. > as long as you're internally consistent--which we are. Personally I always feel that the current button placement is inconsistent with OK-only dialogs, as I argued in my original post. I understand that Plasma may be getting more people migrating from Windows than other platforms, and my proposal may break the expectations of the majority of them. However, on the other hand, I think many people will be using iPhone/Android along with Plasma. I don't know how many people will use Windows along with Plasma, but I'd guess less than the former. Also many websites follow the iPhone/Android convention for a reason. So I'm a bit doubtful if this proposal will really break the expectations of the majority of them, to be honest.
Thanks, that document is quite convincing to me. Re-opening for re-consideration.
That said, any actual implementation would need to be done in Qt itself, to change what QDialogButtonBox::KdeLayout means. That comes from Qt, so if we agree on it here, the changes will need to be done upstream.
Is there an option to colorize the background of a confirmation button that leads to a destructive action? Ie make it red or something? :\
tl;dr of what I wrote in the VDG channel: not a huge fan, as this will break muscle memory with potential destructive / hard to restore consequences. The linked article is correct in a lot of things, but it's also rather "we read a UI from top left to bottom right"-centric, which is not the case in all languages / writing systems. Providing information (e.g. "destructive action") mainly or only via colour is unfortunately a bad idea due to colour blindness being quite common, thus other means of providing that information should be considered instead. tl;dr of tl;dr: -1 from me
(In reply to Christian (Fuchs) from comment #9) > The linked article is correct in a lot of things, but it's also rather "we > read a UI from top left to bottom right"-centric, which is not the case in > all languages / writing systems. FWIW the button order automatically reverses when using an RTL language/writing system, so this isn't an issue in practice.
So, I found my text-only explanation is probably not very clear and less convincing, I decided to create a comparison table with visual images: https://gist.github.com/eatsu/7db85d564fde71b3a4e3088ead3aae43 Regarding muscle memory of existing users, I'd guess it's not that hard to retrain it (given that it's pretty common today apart from KDE and Windows), but I'm not entirely sure. 🤷
Thanks, that's fairly convincing to me.
> Regarding muscle memory of existing users, I'd guess it's not that hard to > retrain it (given that it's pretty common today apart from KDE and Windows), > but I'm not entirely sure. 🤷 Windows with it's way past 90 percent of market share is imho not an "apart", and I would guess we have more people coming from or using Windows in parallel than e.g. GNOME. Also please note that this will affect actions that are destruktive and can't be undone, e.g.confirming deletion of a file bypassing trash. I would not recommend toying around with that kind of muscle memory easily.
I looked into this and it looks amusingly like we can't change this in the correct way ourselves in KDE code. The button order is per-platform and the platform button mappings are in Qt. So the "KDE button order" is hardcoded there! See https://doc.qt.io/qt-6/qdialogbuttonbox.html#ButtonLayout-enum. We could theoretically switch to using the GNOME or Mac OS button layouts in our code, but that would be totally wrong. The correct approach would be to change what the "KDE button order" means in Qt itself. So to proceed here, Qt changes are needed. If you'd like to proceed here, I'd recommend submitting a Qt bug report/feature request for it.
Sorry if my understanding is something wrong, but before submitting a Qt bug report/feature request for it, don't we need a consensus among KDE devs/designers? Or should the design discussion continue in a Qt bug report? Or is this already approved by the KDE side?
If I undeestood this correctly and the order is defined by Qt, this is even trickier, not to say worse. Such a massive change should, if at all, have come with a major version change. If it comes with a Qt change, there is no chance for us to steer when it is shipped, as that would be entirely up with Qt and distro packaging of Qt, which makes me be even more against it.
Practically speaking, is there a way to configure this on a per-user basis? E.g. can users override something in the application style to configure it there? Or is the only way to patch the layout in QDialogButtonBox?
(In reply to Paul Martin from comment #17) > Practically speaking, is there a way to configure this on a per-user basis? > E.g. can users override something in the application style to configure it > there? Or is the only way to patch the layout in QDialogButtonBox? Because I feel like this might be better if it were somehow user configurable.