Get Involved/Design/Lessons Learned

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. 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. Note the kinds of questions that are typically asked: only those absolutely necessary to proceed (e.g. keyboard layout, system language, timezone, 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). In cases where Plasma is pre-installed, the user would not see an installer, so it would be appropriate to use a first-run wizard for these things.

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.
  • Choose preferred panel layout
  • Choose light mode/dark mode/mixed mode/adaptive mode etc.
  • Choose preferred text size
  • 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. Appropriate default settings should be used instead, with configurability being made simple and obvious,


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, it 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, people will come out of the woodwork to propose changes and redesigns. Many of these proposals will be terrible or contradict one another if they were all implemented, 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 people 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 too 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/1:1 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.


System Tray popup sizing

It is often asked: "Why can't system tray popups fit their contents with no extra wasted space"? The "wasted space" effect is particularly noticeable in the Bluetooth Plasmoid when only a single device is paired, or the Audio Plasmoid when using simple audio hardware.

However there is a good reason why this is not done: if it did, then each Plasmoid would have a different size, because it has different content. As a result, every time you opened a Plasmoid, the buttons on its header and its internal UI elements or list items would be in different locations compared to other Plasmoid, or even compared to the last time it was opened, if content had been added or removed since the last time. This would destroy the user's muscle memory and make interaction slower. Furthermore, for Plasmoid that have dynamic content that changes in real-time (such as the Disks & Devices, Networks, Notifications, and KDE Connect Plasmoid), the popup would dynamically resize itself while the user was attempting to interact with it! This would be extremely frustrating and cause the user to mis-click frequently.


Context menus are not enough

Context menus offer fast access to functionality for mouse users, but they do not work well for:

  • People using the system with a screen reader
  • People using the system with a touchscreen
  • People using the system with a buttonless touchpad who have not become comfortable doing a two-finger right-click or pressing the hidden invisible right-click zone in the corner
  • People using the system with a weird mouse that only has one button or whose surface is a big touchpad (like Apple mice; see the previous group of people)
  • People using the system with a device that has a nice easy right-click button but who just don't use it because they never developed the habit of randomly right-clicking everything

For these reasons, no functionality should only be accessible from a context menu, and context menus should be considered accelerators for experts, like like keyboard shortcuts.


Why not a Control Center?

Many other desktop environments have not implemented a "Control Center" UI in place of the "System Tray" style that Plasma uses. These Control Centers offer the user two-click access to simple controls such as changing the volume, and toggling bluetooth, night color, or dark mode. It is often suggested that KDE should copy them and implement such a thing for the Plasma System Tray.

So far no consensus has been achieved on this question, but there are a number of reasons not to and challenges that would need to be overcome if we decided to do it:

  • Many Plasmoids offer richer interaction opportunities than a Control Center that simply consists of toggles and sliders, and their functionality cannot be condensed into just a single button. For example: Clipboard, Battery & Brightness, Disks & Devices, Display Configuration, KDE Connect, Printers, Media Player, Notifications, and Vaults. That's most of them, in fact! So we could never fully migrate to a Control Center style anyway without losing a lot of functionality.
  • In terms of implementation, a Control Center would require adding an additional representation type for all Plasmoids (perhaps named ControlCenterRepresentation?) that would consist of simply a toggle button; this would have to be be opt-in so each Plasmoid could define its own appropriate Control Center button, which means a lot of porting work and 3rd-party Plasmoids would not be compatible for some time.
  • Our current System Tray offers 2-3 click access to most settings; for ported Plasmoids, all that would be saved by switching to a Control Center would be at most one click, and often zero.
  • Any UI changes that made access to the full Plasmoids require additional clicks beyond what we have right now would reduce the advantages of using them instead of simply opening System Settings, which is the entire point of this UI.

For these reasons, it does not seem like a Control Center is fully compatible with the richness of what the Plasma System Tray currently offers, and all of them would need to be addressed in the design phase before we could consider implementing it. One such promising proposal can be found at https://bugs.kde.org/show_bug.cgi?id=460125!


Global Themes to mimic other platforms

This has been proposed many times in the past, and was almost implemented; see https://phabricator.kde.org/D24223.

Ultimately the team decided against it because allowing users to set up layouts that mimic other platforms would establish the expectation that *everything* is similar to that platform. But 100% fidelity would be impossible, so the promise of mimicking the platform would never be kept.

In essence it would prime people's brains to enter "nitpicky conservative mode" and focus on the differences from what's expected, rather than "open-minded exploration mode" where it's possible to feel playful and curious and enjoy the distinctiveness of our system. People would feel angered and disgusted, rather than intrigued and curious.

Accordingly, formalizing this by offering global themes out of the box that provide similarly imperfect mimicry of other platforms would make that problem worse, not better.


This page was last edited on 20 November 2022, at 21:27. Content is available under Creative Commons License SA 4.0 unless otherwise noted.