Get Involved/design

The Visual Design Group is a team dedicated to bettering the entire user experience of KDE software, including human interface design, graphical design, user interface design and interaction design. The aim is to help KDE create software that is both beautiful and a pleasure to use.

The VDG welcomes people with skills in art, visual design, and human-computer interaction--or even just an interest in elegant design! If you have good ideas about how software should look and behave, you are a designer too, and we'd love for you to join in. Our group regularly interfaces with users, developers, and the Promo Team.

The VDG created and maintains the KDE Human Interface Guidelines and the Breeze theme used throughout KDE Plasma and applications.

Getting started

Learn, then do.

It's important to get a feel for the group's social conventions and workflow before contributing. First, read through Get Involved/Design/Lessons Learned. This page explains often-talked design ideas and how the VDG understands them, so we don't end up re-discussing the same things over and over again.

Then, understand that the KDE VDG very much designs in an incremental way. We try to avoid huge redesigns as they tend to introduce as many issues as they fix, on top of the effort required to implement them. At the moment our focus is on polishing and refining what we have, and redesigning only as a last resort when the existing design is unsalvageably bad. These cases exist, but are rare.

Finally, join the real-time chatroom, accessed using Matrix or Telegram (your choice, but Matrix is preferred). Lurk for a while and see how things work before proposing new work.

Communication and Workflow

Note

VDG task and project-tracking was done on Phabricator in the past, but is now moving to GitLab. Click here to start a new discussion on GitLab.

Most VDG discussions start out informally in the real-time chatroom mentioned earlier. Once there is general agreement in the real-time chat, the discussion moves to a GitLab task. Our goal is to open the discussion to include developers, and make the proposal more concrete using images and mockups.

Make sure to tag all the relevant participants in a GitLab issue discussion. Summarize the discussion and initial VDG conclusion when writing the task's initial description. Include before/after images of the proposed change. Explain the benefits for the user and possible red flags.

In the GitLab task, it's common for details and scope to change based on developer feedback. This is normal! Developers may have a better idea of what is technically possible or reasonable to change given our constraints. Listen to developer feedback and change your design accordingly. At the same time, encourage them to listen to your expertise, and provide good evidence of your decisions as varying views will challenge your proposal.

Once there's general agreement in the GitLab task, work should begin and folks can start submitting patches!

It can also be helpful to subscribe to the VDG mailing list to keep abreast of general information relevant to all VDG contributors. This is a very low-traffic mailing list so you will not be spammed with nonsense.

Current Projects

Our default "Breeze" visual style is undergoing many changes as part of the "Breeze Evolution" project. If you would like to submit mockups for our consideration, use the new New Figmt-based Breeze SVG Kit have the most updated graphics for your mockups. This helps our developers visualize your design ideas better.

Beyond that, here are some timeless ways to get involved in ongoing work:

• Learn how to design Breeze icons by reading the applicable HIG page, and then work on Breeze icon bugs. Here's how to submit an icon.
• Submit patches (using GitLab) for corrections and improvements to the Human Interface Guidelines

Know Yourself

In a highly technical field like programming, it's easy to encounter the limits of your expertise. This is more difficult in subjective fields like art and design, and it's very important to have a firm grasp of what you can do. For example:

• If you know you're not very artistically skilled, listen attentively to developers and experienced designers on what we look for.
• Request honest feedback for your design proposals regarding what could be improved rather than blindly pushing on them.
• If you want to learn more about human-computer interaction, offer to help in testing interactions and providing feedback.

VDG-related HowTos

• How to change the default wallpaper
• How to submit changes to an icon or submit a new icon
• Icon workflow tips

Old Things

• Archive of outdated documents that may still be useful for reference