Revision as of 22:42, 14 July 2020

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.

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). However, sometimes it's required. 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. A common scenario is when a depended-upon library is buggy but poorly maintained--for example X11. Another scenario is when a poorly-behaving closed-source app 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, there's a whole management and power structure in place to compel engineers who don't realize 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.