Get Involved/Design/Frequently Discussed Topics

This page catalogs the results of various discussions that appear over and over again, as well as useful bits of wisdom and institutional knowledge relevant to development and design. Additional information can be found on the KDE Culture page.

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 on a sub-page, separate window, or a collapsed view. For example, the Colors KCM has a "basic" accent color feature and a grid view of all the installed color schemes, but each color scheme can be fully edited in a separate window, by clicking "Edit" on it -- 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]
• Gamma adjustment for their screen, with visuals to help people choose
• 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 other platforms

Oftentimes, people will explicitly bring up the fact that a feature or visual style is already present in another OS as a justification for implementing the same thing in a piece of KDE software.

In KDE, we don't copy other platforms explicitly, or use the fact that a feature/workflow/visual style/etc. is already implemented elsewhere as evidence that we need to implement it as well. When we do implement something that is already present on another platform, is must be because we want to solve the same problem and have arrived at the same place by chance, not because we were explicitly trying to copy another platform.

This reason for this is that other platforms don't always get everything right. We must look at them 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's 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, not trend-chasing

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 heavy, gaudy, excessive, 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, or even amateurish.

In the software world, this manifests as user interface design trends, such as the "brutalist" trend of the 1990s, the "skeumorphic" trend of the 2000s, the "flat" trend of the 2010s, and the current "modern" trend. Each of these trends eventually flames out and gets replaced by a new one because its controversial visual style turns off some people, and it broadly fails to satisfy people who like ornamentation and also people who like minimalism.

To avoid the ping-pong between these extremes in our own software's visual design, we must aspire to a timelessness that combines both minimalism and ornamentation in a pleasing fusion. We must remove all that is not necessary, but make what remains feel rich and beautiful without being in-your-face about it. 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).

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(s). 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.

Pixel-alignment for SVG icons

It is often asked, "you use vector SVG icons; why doesn't this let you scale the icons up or down to arbitrary sizes and keep them always looking good no matter the scale?"

The answer is because despite the use of a vector icon format, we still draw our SVG icons to be pixel-aligned when displayed at their native size (16x16 px, 22x22 px, etc). An icon's 1px lines will be perfectly aligned to the screen's physical pixels when displayed at either its native size (i.e. 100%) or at a multiple of its native size (200%, 300%). The result is nice crisp icons with no blurriness. However if you scale such an icon to 150% size, then the 1px strokes become 1.5px strokes. However the physical pixels on your screen are still the same size that they were before. The result is blurriness as the system attempts to figure out how to display a 1.5px line on a pixel grid that is not fine enough.

This effect is less pronounced for large colorful icons that are scaled up by greater amounts, but the effect can still be noticeable. However the effect produces particularly undesirable results for small monochrome line-art icons with 1px strokes which are scaled up or down by a non-integer amount.

For a more technically in-depth explanation, see https://phabricator.kde.org/T13722#255733

Auto-hiding/invisible scrollbars

Scrollbars serve three related purposes:

1. Allow the user to change the current view position
2. Indicate the current view position relative to the whole view
3. Indicate how large the current view is relative to the whole view

Depending on the user's current set of input devices and apps, scrollbars might rarely or ever be used directly, obviating the need for #1. And users who grew up with smartphones and are accustomed to auto-hiding scrollbars may question the need for #2 and #3. Nonetheless, all are important even if any one of their functions may not be used at any given point in time. Scrollbars cannot ever be completely hidden or else at-a-glance information about the view's size and position relative to the whole is lost, which may be quite disruptive, depending on the view in question. Scrollbars must also always be accessible because mouse users in particular interact with scrollbars somewhat frequently for very long scrollable views, as mouse wheel scrolling is generally rather slow. Even touchpad users may do the same for very large views in apps where scroll acceleration has not been implemented. And if the scrollbars auto-hide or become invisible when not hovered, the precise location of where to click to access the bar or the track is not obvious, which slows down interaction.

Visually separating scrollbars from content areas

When a scrollview's content area uses a highlight effect that spans the full width of the scrollview, some sort of visual separator to delineate the bounds of the scrollbar track is needed, to provide an anchoring point for anything that touches the edge of the scrollbar track. Examples include full-width highlight effects and table view headers. Without some visual separation, those UI elements seem to be "floating in space" on their right side, but connected to the edge of the view on their left side, which looks weird.

On the other hand, if all of those elements use a style where the entire thing is "floating in space" and not visually attached to anything on any side of it (in the case of list view highlight effects), or drawn above the scrollview (in the case of table headers), then it becomes okay to omit a visual scrollbar separator, since it no longer serves an anchoring function.