Human Interface Guidelines

Hello everyone!

The Visual Design Group has been hard at work to improve our Human Interface Guidelines. These set of rules and guidelines are meant for our developers and designers to use when creating applications, submitting patches, suggesting UI changes, etc. Every developer that we work with will feel a little more safe that their application is headed in the right visual direction for KDE.

However, as with most things, our guidelines have become outdated. Recent development into Kirigami and further work into the desktop have made it clear that we must change and update our guidelines to accommodate for these new developments.

In fact, during Akademy 2018 in Vienna, updating our guidelines was one of the most cited suggestions that I received.

Of course, updating our guidelines is a big effort that involves website building, design help, user interaction suggestions, etc. Our team currently has all these people but we needed to start somewhere strong. Fabian decided to jump on this task and moved our outdated guidelines from our wiki to a more modern site using Restructured files.

You can now find this page at:

The page features new navigation panels, a lot easier to find. A universal search at the top and all the same content that we had in the old wiki. Even though we are using Restructured files, you can still contribute to it because it is a markup language similar to wikis. There is a cheat sheet that you can use for editing by going here!

HIG Page

It is so simple to find content now that our contributors should not find it hard to get to the right information. Now the work of updating and beefing up the content starts. Please note that this site is not complete, as you browse through it, there will be some areas with very sparse information. This just means that there are some places where we need help and you can help us by suggesting changes and additions.

For now, the updates are related to the desktop interface mostly. However, our plan is to start integrating more content pertaining to Kirigami. We want to have sections where there are desktop and mobile guidelines. That way our developers don’t have to scramble for content relating to one or the other.

For example, recent work has gone in to our Personas page. The personas page relates the stories of fictional KDE users but that represent some of the audiences we want to reach as a platform. Designers can reference these characters to make sure that their application is geared toward a good audience. It can help making decisions that are more relevant to the people that will use your software.

We also noticed that many sections only have text and don’t have visual representations of what is being communicated. We started adding more graphics to them so it is easier to understand. In other areas, we added more explanations for the visual mission of KDE. That way, if it is hard to understand the guidelines, at least, you can have an introductory paragraph detailing the most important concepts about the section.

We would love it if you have the expertise to help us come up with the visual examples of what the HIG is sharing. We have a lot of text, but not a lot of images and we can generate those pretty easy with your help!

Take a look at this ticket on Phabricator!

If you are interested in helping, let us know! We need you!

A Better Menu Experience in Plasma (PROPOSAL)

Launchers in an OS have become the central point of access and interaction with system content. It is the main way that most people will interact with applications and files. In recent years, other OSs have become increasingly interested in beefing up their application menus. Plasma currently has 3 launchers integrated. Users are asked to select one or the other by right-clicking in the “start” menu button and switch a different launcher. The interaction is somewhat quirky but it is effective.

I wanted to contrast our iteration with something that might be more interactive, more straightforward and help users find the desired content faster. Here is an idea about that.

Please note that these mockups are just images. The layout, color and interaction is what I am trying to discuss. Is there merit to this convergence idea? Does it solve any issues?


Plasma currently has 3 launcher styles added. I believe all of them can be converged or made to look similar. However, given user requests, we have to keep 3 of them and they currently don’t seem to correlate visually. We have the dashboard launcher (WIP), Kickoff and Kicker. Each of them brings different kinds of interactivity and space savings for the users.

I would like to propose a visual merge of these three applications so that they look more cohesive, tight and closer to a Plasma style.

Things to note:

  1. Icons are not meant to be final. They are just a representation
  2. Spacing is relative
  3. Current elements on the screen are meant to be there


Fullscreen button: Will resize from kicker to dashboard launcher, from kickoff to fullscreen launcher. Removed the idea of right-clicking the menu and offered visual controls.

Kickoff Menu: To provide consistency, I preserved the kickoff bottom menu bar throughout the different iterations. This will take care of the category clutter menu that is present in the dashboard launcher.

Things to Consider

  1. I don’t know the possibility of creating this code-wise. I welcome feedback.





System Settings Progress – June 2018

These past few months have been full of work on the KCMs. Our developers have been able to tackle more and more of them for the upcoming version of System Settings.

In the process, there have been a few changes to note. Many of them deal with work that needed to change as we went through. The overall vision of a more clear and concise settings page is still the same. However, I have learned that through compromise we can move forward. That’s what we have been doing.

Here is a list of KCMs that will get some revision with their design:

As you can see, there is a lot of work to be done. We have a huge amount of KCMs. Some of them are very technical and tailor to specific audiences while others have very few options and we discussed ways to move those into other categories where they may fit better.

Overall, the main changes have been the new alignment pattern for title labels and controls. They are now centered and titles are on the left while controls are on the right. There has also been plenty of work in explaining KCMs more naturally, especially in English. The idea is that the title labels are short and concise, and that the control options read more like a paragraph. That way, it feels more natural for the user to find the right settings and not be lost in word puzzles.

Another cool thing that we are considering is to include this new design on more application settings, for example Dolphin:

However, this is a work in progress. We will see if it gets implemented. If other applications want to follow the System Settings direction, it only makes sense to extend the work further.

The touchpad KCM is also getting some love:

My next step is to create new “model KCMs” that can showcase some of the design changes we have made as we set out to redesign System Settings and that way, more people can use them as a basis for their designs or contributions.

Feedback is always welcomed. Just add a few comments below.

System Settings Progress

I would like to provide some information on working with System Settings. This is a big endeavor and not an easy one. System Settings is a good expression of the power of Plasma KDE and also the many influences that have shaped it over the years.

Trying to untangle the work that has gone into System Settings requires time and patience. I have always been interested in working in revamping this UI. We worked with the team in the VDG on this some time ago, and although there were many great and interesting changes, the scope of the work was too great. Therefore, we decided only to move forward with those things that were achievable at the time.

We reorganized our settings.

In recent iterations of the software, we have also decided to change a few more visuals with the application and have added a second column for specific KCMs.

However, I feel we want to go further in the future and achieve even more. It is because of that vision that I have decided to keep working with System Settings to help the modules arrive at a good place in the near future. I have taken consideration of a few ideas and initiatives that our team has, some reported bugs and overall perception. I suggested that I become a lead designer for this project.

But I can’t do it alone. If you have ideas and thoughts (albeit without drastically changing the direction that I am taking) please share them.

This is somewhat rough, but here is something that I can show for now, please note this is a graphic mockup, not a working UI:


Please note that these ideas here are still in progress. They are developing and changing a lot. Further things that I would like to design are:

  •  Work on labels and develop a tone and angle for descriptions. Right now labels don’t have a consistent sound and tend to lead to confusion, at least in English.
  • Work on removing tabs in favor of a one-page interface where settings can be together without the need for more than 3 clicks before getting to the desired content.
  • Design new interactions for certain KCMs and follow a predictable structure for information presentation.

I hope this helps understand where System Settings can be.

Our KDE team is working hard these days in many areas. Adding System Settings to the mix might take time. For now, they are focused on getting people at our next sprint at Randa. They will be working on accessibility. I am hoping that we can bring System Settings to those discussions as well.

UPDATE: I should make a statement as it seems that others have been misled. This mockup is only a graphical concept, not a developed application. I am not a developer, I am a visual designer. This mockup is intended to have the KDE team review and come to a consensus to develop System Settings to something like I have proposed. The mockup is missing a few things, title bar, search fields, labels, and buttons. I hope it is evident that those changes will be included.

Akademy 2017 Takeaways

Akademy 2017 Review

Akademy 2017 was held in Almeria, Spain for a week full of discussion around the Plasma project. Our VDG team was represented by Jens Reutenberg (jensreu) and Andy Betts (anditosan). Our aim at the event was to provide help to many of the developers who gathered at the event and needed help in designing new applications using guidelines or just coming up with design ideas.

There are a few things that the VDG will be helping with going forward. Some of them are short term, medium term and others are long-term. These goals are about Plasma as a desktop. There are also other areas where the VDG can also help in individual work for developers working on specific applications.

Here are the details

  • Applets, Config Dialogs – Needs a review and design
  • Adding helpful animations to the boot-up process started by Andy Betts
  • Renaming, when needed, desktop animations – The aim here is to brand and make effects more recognizable
  • Tooltips, margins and spacing review – Led by Eike Hein
  • General alignment and spacing throughout menus and applications – Led by VDG
  • Keyboard shortcuts review – Led by VDG
  • Notifications made persistent until dismissed – Led by VDG
  • Highlight styles and consistency throughout the UI – Led by VDG
  • Review of current and future implementation of helpful animations throughout the desktop UI – Leaded by VDG
  • Plasma Future – Design future looks and interaction for the entire Plasma Desktop – Led by VDG
  • Mycroft Project – Needs help in designing a helpful, newer UI for the desktop client
  • Babe Music Player – Needs help in defining some aspects of the UI to better adjust the application to Human Interface Guidelines
  • Korganizer: need help to modernize the UI, and make it more usable.


While the VDG is helpful in a few of these initiatives, our aim is to plan these features and changes first, then start doing mock-ups, reviewing and approving all these changes internally as a group first. We then hope to work with our developers in strategizing about the changes.

Please note that mock-ups first may not always be the ideal solution. We hope to create a space where discussion and revision are important.

Our team will be bringing these ideas to the table in the coming weeks and months.