Get Involved/Design/Frequently Discussed Topics

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 at to use 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.

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 preferences 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. But copying their products and style can't succeed; Apple will always be better at being Apple than anyone else, and those who try end up creating a cheap copy which can never satisfy the urge for the real thing. But the desire to try is totally normal; their marketing department spends hundreds of millions of dollars to create that desire in people.

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.

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

1. 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.
2. 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.
3. 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. Not used or relevant for mouse wheel scroll events.
4. 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.