Description

A frequent criticism and pain point when it comes to KDE/Linux adoption is lack of basic support. It is not uncommon to come across people recommending against Linux due to bad anecdotal experiences when it comes to troubleshooting and/or diagnosing issues, as search engines will often provide results that are:

1. Highly specific to a particular Linux distribution, or,
2. Make heavy use of the command-line and/or sudo.

KDE, being a common denominator and provider of graphical interfaces that can probably solve the vast majority of problems users frequently encounter, should provide extensive documentation (with figures) on accomplishing such tasks. This will remove, in my opinion, a massive barrier to KDE/Linux adoption by a broader user base.

While KDE does currently have some documentation, it is inadequate or it’s distributed and difficult to use. Using Google, then first result searching for “KDE documentation”, leads to this, upon seeing that an end-user would very easily just put whatever help they needed into the “too hard” basket and move on. You might get lucky and stumble across the UserBase wiki, but it looks incredibly dated, things are not laid out that well, and it is difficult to navigate to a page which might answer your question. Another result when searching for “KDE documentation” is this page. Not to mention, none of these sites will appear at the top of a search engines result page when trying to troubleshoot something more specific.

Compare and contrast to both the Windows and macOS documentation pages. They are centralised, there is a prominent search bar, and there are quick links to very common articles that they have put in the work and identified that people need help with the most. KDE should work to replicate these.

A contributing factor to the issue is that end-users use the search term “Linux”, when instead they should be using “KDE”. Part of this effort should involve educating users to prefer the term “KDE” instead. Users of competing software know to include the term "Windows" or "Mac"/"macOS", allowing them to quickly get relevant support.

What it will take

• Centralising all of KDE’s user documentation into one place (Plasma, and Apps) – keep layout similar to most knowledge base sites that users are familiar with, e.g. Windows Support, macOS Support, ZenDesk Help Centre, etc.
  • Prominent search bar,
  • The following are all examples. Check out the macOS support page (including clicking the "Table of Contents" link), or Windows support page for more ideas.
  • Cards that point to commonly used software within KDE:
    • Getting Started,
    • Desktop,
    • Files & Storage (Dolphin),
    • Installing Software (Intro to installing software with Discover),
    • Keeping Updated (Intro to checking for updates with Discover),
    • Network & Internet (Setup internet, Bluetooth, VPN, proxy, etc),
    • Troubleshooting (should also include where to get more help, community forums, etc)
  • Frequently Asked Questions:
    • Add a new Bluetooth device,
    • Setting up an internet connection,
    • Setup a printer,
    • Getting started with Gaming,
    • Browsing the internet,
    • Backing up your computer,
    • Keyboard shortcuts,
    • Fix Bluetooth problems,
    • Fix internet problems,
    • How to use the taskbar,
    • Desktop themes,
    • Setting up office software.
• All support articles should incorporate extensive use of graphical figures to aid the user to achieve their goal.
• All support articles should be independent of a Linux distribution, and should only incorporate things capable within KDE (Plasma, System Settings, Apps, etc).
• Educate users to use “KDE” in place of “Linux” when searching for support.
  • This could be a prominent “Help & Support” button within Plasma, Settings, etc, opening up the default web browser to KDE’s documentation page, where “KDE” (and not “Linux”) is prominently presented to the end user, so they will eventually associate that term with the software they are using.
• Make it easy for end-users to get to the KDE documentation page (could be a button titled “Help & Support” within the menu widget).
• Documentation should be available offline (separate packages, one for Plasma, one for Apps), but identical in presentation to the equivalent online documentation page.
  • Goal: Users should be able to navigate to the documentation very quickly with no delays.
• Given the varied release cadence of distributions, we must take into account the fact that a user might be searching for support for potentially outdated software. We cannot expect a user to know the version of Plasma or Apps they are using and so a version selector drop-down might not be appropriate.
  • Of course, accessing “Help & Support” from within KDE itself should take the user to the appropriate documentation for their software version (e.g. &version=6.1).
• All support articles should assume KDE has been packaged and distributed correctly by distributions (which itself is a different problem, and I believe has/is already been/being worked on?).

How we know we succeeded

• Hard to quantify, but we should see an increase in users on various media knowing the term “KDE”, and recommending “KDE”, as opposed to just “Linux”.
  • People would be less scared of Linux in general.
• Every piece of KDE software & system settings page should have corresponding support articles.
  • Depending on software complexity, maybe aim for at least 5 support articles for common support questions & 5 support articles for troubleshooting common issues (maintainers discretion as to what is “common”). For more complex software, we could increase it to a larger number?

Potential Issues:

• Translations?
• How do we ensure articles are kept up-to- date? Do we keep support article source code (Markdown, reStructuredText, etc) in a Git repository that are checked as part of Pull Request reviews?
• Will probably require using software other than MediaWiki. Are there existing open-source solutions that make an appropriate and modern-looking knowledge base? Could leverage static site generators like Hugo, or Jekyll.
• Have to start using friendlier names that beginner users can identify, instead of/next to technical names (i.e. what currently is on docs.kde.org).
  • Note: macOS uses different names than Windows (e.g. “Finder” instead of “Explorer”), check out how they educate users about their software & names.

Relevant Links:

• Microsoft Support: https://support.microsoft.com/en-US
  • Windows Support: https://support.microsoft.com/en-au/windows
• macOS Support: https://support.apple.com/en-au/macos
  • macOS User Guide (check out the "Table of Contents" link on the page): https://support.apple.com/en-au/guide/mac-help/welcome/14.0/mac/14.0
  • macOS Getting Started: https://support.apple.com/en-au/guide/mac-help/mchl3a2c2cb0/14.0/mac/14.0
• Other sample help centres for inspiration (notice how most are laid out similarly):
  • ZenDesk,
  • DigitalOcean docs,
  • Canva,
  • Monday,
  • Slack.

Champions

The team is:

• XXX
• XXX
• XXX

I am willing to put work into this

• add your name

I am interested

• add your name