This page catalogs the results of various discussions that appear over and over again.

Basic/advanced modes

This design pattern is not always wrong, but must be used sparingly. The pattern can work when implemented as a sort of progressive disclosure model where a view first presents data in a simplified form, but more detail about each item can be shown if desired. For example, the Colors KCM has a "basic" grid view of all the installed color schemes, but each color scheme can be edited in another window--the "advanced" view.

However the basic/advanced paradigm does not work for grouping and separating features, especially when explicitly using the terms "basic" and "advanced" in the user interface. The problem is that different users have different needs, and what one user considers advanced will be considered basic to another user. Also, even "basic" users may very occasionally have a need to use or configure "advanced" features. Users who doubt their technical prowess will fear entering the advanced view, while users of great ego will find the basic view insulting even if it meets their needs better than the advanced view.

First-run wizard

It is often suggested that Plasma should have a first-run wizard shown on boot that asks the user to choose their preferences: light vs dark theme, traditional task manager vs dock, and so forth. See for example https://bugs.kde.org/show_bug.cgi?id=211144.

It's important to understand that wizards are one of the worst ways to ask the user for input regarding their preferences. They tend to request information that the user does not know the answer to or have an opinion on without a lot of context, and it isn't clear how to later change a setting that's set in a wizard.

For this reason, wizards should be used sparingly, if at all.

The questions asked during system installation can be considered a kind of first-run wizard. Note the kinds of questions that are typically asked: only those absolutely necessary to proceed (e.g. keyboard layout, system language, password for the user account), plus a few more about the user's preferences regarding things they are guaranteed to have an opinion about (e.g. telemetry vs no telemetry).

If a first-run wizard were ever to be implemented, the best place for it would be in the installer itself, as the last set of steps. It should indicate to the user where to go to change whatever selection they make in the wizard. And it should only ever ask questions whose answers the user is guaranteed to know or have an opinion about, and possibly very simple aesthetic choices. For example:

Would you like to turn on telemetry [with an explanation of what this means]?
Are you right-handed or left-handed [for the purpose of choosing the default button in Libinput]
Do you prefer text to be compact or large? [with a visual depiction of the options]
Would you like to use a light or dark color scheme? [with a visual depiction of the two options]

Inappropriate questions would include the following:

Choose KDE style vs macOS style vs Unity style
Choose preferred web browser/text editor/video player/etc.
Choose between Kickoff/Kicker/SimpleMenu/etc.
Right-click by using virtual buttons or by pressing with two fingers on the touchpad?
Open files and folders by double-clicking or single-clicking?

In the above cases, the user is being asked to choose from among options they may not be familiar with or understand.

New off-by-default features

Most people never change most of the default settings for their software. Any feature which is off by default is likely to be missed by most users. Therefore, when proposing a new feature, don't make it configurable and leave it off by default. Have confidence in your designs and features! New features and design changes should be on by default, if they should even be configurable at all. If you are tempted to add a feature and make it off by default, consider your motivation: do you think it's too nerdy and esoteric a feature? In that case maybe it should be an optional downloadable plugin or even a separate app. Do you think the design changes might be too controversial? In that case consider working with VDG to improve the design so that you feel more confident about it, or implement your design in a downloadable theme instead of the default Breeze theme.

Note that this does not apply to adding the ability to turn off existing features which are currently always on. This should be done carefully and sparingly to prevent options overload, but is not necessary a bad idea.

Copying Apple

Apple is fantastically successful at getting people to lust after their products and envy their style; their marketing department spends hundreds of millions of dollars to create this desire in people. But copying their products and style can't succeed; Apple will always be better at being Apple than anyone else, and those who try will end up creating a cheap copy which can never satisfy the urge for the real thing.

We need to be aware of this so we can look at Apple dispassionately, and take from them what works and what's applicable to us and our world, while confidently ignoring the rest.

Constant redesign proposals is a warning sign

When a piece of software's visual or functional design is not ideal, designers will come out of the woodwork to propose redesigns. Many of these proposals will be terrible, and the software' developers will feel the need to shoot them down. However these proposals indicate that some kind of change is needed, even if any one individual redesign proposal is not the solution. In this case, engagement with the VDG is advised, and hopefully developers and designers can work together to implement some changes that make everyone happy. Once adequate changes to the design have been made, you will know because designers will stop proposing redesigns, as if by magic.

Timeless design

In all artistic matters, there is a dichotomy between minimalism and ornamentation. Throughout history, artistic styles have bounced between these extremes: when art is seen as too ornamental, it feels gaudy, excessive, smothering, or even ridiculous, and a pressure emerges to pare things down to basics. But going to far in the direction of minimalism makes art feel cold, sterile, unfriendly, and even amateurish.

To avoid the ping-pong between these extremes in our own software's visual design, we must aspire to a timelessness that combines minimalism and ornamentation in a pleasing fusion. We must remove all that is not necessary, but make what remains feel rich and beautiful. This balance is hard to get right, but you will know when it has been achieved because designers will stop coming out of the woodwork to try to redesign it (see #Constant_redesign_proposals_is_a_warning_sign)

Hacks vs purity

We all prefer to write elegant code with no workarounds for other people's bugs (i.e. "hacks). When a bug is discovered at a higher or lower level of the stack, ideally the bug gets fixed there. However there are various circumstances where this is impractical or impossible and a hack is required. A common scenario is when a depended-upon library is buggy but poorly maintained--for example X11. Another scenario is when a popular but poorly-behaving closed-source app or game triggers the wrong behavior in Plasma.

When a bug at a different layer of the stack cannot be fixed in the correct place for whatever reason, it needs to be worked around (AKA "put in a hack"). While this is unpleasant, insisting on purity of code and avoiding all hacks will result in software that's very buggy and produce a torrent of angry users whose expressions of anger will de-motivate developers, designers, bug triagers, and other users. In a for-profit company, management chains and power structures exist to compel engineers who don't understand this to implement the hacks anyway so that the end product meets requirements and satisfies users. In a FOSS community, it's up to the engineers themselves to have the humility and wisdom to admit this and act accordingly to implement whatever unavoidable hacks are necessary to produce a high-quality end result.

When implementing a hack, it's critically important to include a comment in the relevant code describing why the hack is needed, including the URL of a bug report filed against the component being worked around. This ensures that the hack can be removed if and when the bug gets fixed, because anybody can visit the URL of the bug report to see the status of the bug being worked around.

Names of different scrolling effects

Kinetic/inertial/momentum scrolling: After a touchpad or touchscreen scroll event finishes, the view continues to scroll and eventually comes to a smooth stop, rather than immediately ending. Never do this for mouse wheel scroll events.
Bouncy scrolling: When a scroll causes the view to reach the top or bottom, the view visibly "bounces" rather than the scroll event immediately ending. Only ever used in conjunction with kinetic scrolling; never do this for mouse wheel scroll events.
Pixel/Pixel-by-pixel scrolling: When scrolling with a touchpad or touchscreen, the view moves pixel-by-pixel, as though it were glued to your finger(s). Not used or relevant for mouse wheel scroll events.
Smooth/animated scrolling: When scrolling using a mouse wheel, the arrow keys, PgUp/PgDn keys or spacebar/shift+spacebar keys, there is an animated transition between the old and new view positions, rather than the view jumping straight to the new position with no animation or transition.

Finding a third way rather than taking sides and defending a position

Especially with visual changes, it is common for a proposed change to be polarizing such that people align in different factions: one faction loves it, while an opposing faction hates it and feels the need to try to block it. In such an environment, emotions flare and productive conversation becomes difficult. Everyone walks away upset, no matter what the final outcome is. And any changes made with only minority or slim majority support will experience pressure to revert them when users start complaining and the original opponents say "see, I told you so!"

In such a situation, it's helpful to step back and try to find a third way that satisfies everyone--or at least more people. The result will hopefully be a larger majority in support, which will help the new proposal avoid controversy, get merged more quickly, and be more defensible if and when users complain.

Examples where this worked:

Instead of unconditionally increasing the transparency of Plasma panels and apps, make it adapt to the environment such that it becomes more transparent normally, but opaque when there is a maximized window