Toggle the table of contents

Get Involved/design: Difference between revisions

From KDE Community Wiki

Latest revision as of 18:20, 13 December 2023

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 first, then do!

Before contributing, it's essential to familiarize yourself with the group's social conventions and workflow. Start by reading through Get Involved/Design/Frequently Discussed Topics, which explains commonly discussed design ideas and the VDG's understanding, avoiding repetitive discussions.

Keep in mind that the KDE VDG prefers incremental design changes over major redesigns. Large overhauls often introduce new issues and require significant effort to implement. Currently, our focus is on refining and polishing existing designs, reserving complete redesigns for rare cases when the existing design is beyond salvage.

Join the real-time chatroom, accessed using Matrix.

Matrix

Communication and Workflow

In the VDG, discussions typically begin in an informal and friendly atmosphere within the real-time chatroom mentioned earlier. Once a general consensus is reached in the chat, the conversation transitions to a GitLab GitLab issue, where developers become involved. When writing the task's initial description, summarize the discussion and initial VDG conclusion from the chatroom, and make sure to tag all the relevant participants. Include before/after images or mockups of the proposed change. Explain the benefits for the user and possible red flags.

In the GitLab task, expect details and scope to evolve based on valuable developer feedback. Embrace this natural process, as developers bring technical insights and constraints into play. Be open to adapting your design accordingly while also encouraging them to consider your expertise. Present solid evidence to support your decisions, as diverse perspectives will help refine your proposal. Collaboration leads to the best outcomes!

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

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 Figma-based Breeze SVG Kit have the most updated graphics for your mockups. This helps our developers visualize your design ideas better.

We are also scoping PenPot for future designs. We will have more news soon.

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.

@@ Line 1: / Line 1: @@
-== About the Visual Design Group (VDG) ==
 [[File:Mascot konqi-app-graphics.png|frameless|right|200px|]]
 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.
@@ Line 7: / Line 7: @@
 The VDG created and maintains the [https://develop.kde.org/hig KDE Human Interface Guidelines] and the [[Get_Involved/design/Breeze | Breeze theme]] used throughout KDE Plasma and applications.
-First read through [[Get Involved/Design/Lessons Learned]]. This page contains often-talked design ideas and how the VDG understands them. This page can give context to some of the discussions happening in our live channels.
+== Getting Started ==
+==='''Learn first, then do!'''===
-=== Recent Changes ===
+Before contributing, it's essential to familiarize yourself with the group's social conventions and workflow. Start by reading through [[Get Involved/Design/Frequently Discussed Topics]], which explains commonly discussed design ideas and the VDG's understanding, avoiding repetitive discussions.
-Our team is currently working on a couple of changes. First, we are moving design discussions into Gitlab (link below). Our work of merging changes and discussing visual design changes is now moving to the same location. To get started with a new discussion, use the link below and create a new issue.
+Keep in mind that the KDE VDG prefers incremental design changes over major redesigns. Large overhauls often introduce new issues and require significant effort to implement. Currently, our focus is on refining and polishing existing designs, reserving complete redesigns for rare cases when the existing design is beyond salvage.
-The second change is with our default visual style called Breeze. If you would like to submit mockups for our consideration, use the new Breeze SVG Kit link below to have the most updated graphics for your mockups. This helps our developers visualize your design ideas better.
+Join the real-time chatroom, accessed using [https://go.kde.org/matrix/#/#visualdesigngroup:kde.org Matrix].
+<gallery>
-== Current Projects ==
+MatrixLogo.jpg|Matrix|link=https://go.kde.org/matrix/#/#visualdesigngroup:kde.org
-Here are some timeless ways to get involved in ongoing work:
+</gallery>
-* Learn how to design Breeze icons by reading [https://develop.kde.org/hig/style/icons/ the applicable HIG page], and then work on [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&component=Icons&list_id=1536878&product=Breeze&query_format=advanced Breeze icon bugs]. Here's [[Guidelines and HOWTOs/Submit an icon | how to submit an icon]].
-* Submit patches (using [https://invent.kde.org/websites/hig-kde-org/merge_requests GitLab]) for corrections and improvements to the [https://develop.kde.org/hig/ Human Interface Guidelines]
 == Communication and Workflow ==
-Most VDG discussions start out informally. 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.
+In the VDG, discussions typically begin in an informal and friendly atmosphere within the real-time chatroom mentioned earlier. Once a general consensus is reached in the chat, the conversation transitions to a GitLab [https://invent.kde.org/teams/vdg/issues/-/issues GitLab issue], where developers become involved. When writing the task's initial description, summarize the discussion and initial VDG conclusion from the chatroom, and make sure to tag all the relevant participants. Include before/after images or mockups of the proposed change. Explain the benefits for the user and possible red flags.
-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, expect details and scope to evolve based on valuable developer feedback. Embrace this natural process, as developers bring technical insights and constraints into play. Be open to adapting your design accordingly while also encouraging them to consider your expertise. Present solid evidence to support your decisions, as diverse perspectives will help refine your proposal. Collaboration leads to the best outcomes!
-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!
-Once there's general agreement in the Gitlab task, work should begin and folks can start submitting patches! Explore the links below and get started in open source design!
+Subscribe to the [https://mail.kde.org/mailman/listinfo/visual-design 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.
-{| class="wikitable"
+== Current Projects ==
-|+
+Our default "Breeze" visual style is undergoing many changes as part of the [https://phabricator.kde.org/T10891 "Breeze Evolution" project]. If you would like to submit mockups for our consideration, use the new [https://www.figma.com/file/gjuIy1rxU9xHkaJXM0pasK/ocean-v3?node-id=1336%3A7194 New Figma-based Breeze SVG Kit] have the most updated graphics for your mockups. This helps our developers visualize your design ideas better.
-|-
-! Communication !! Discussion !! Documentation
-|-
-| [https://app.element.io/#/room/#visualdesigngroup:kde.org Matrix Channel] || [https://phabricator.kde.org/ Phabricator (for legacy discussions)] || [https://develop.kde.org/hig/ Human Interface Guidelines]
-|-
-| [https://t.me/vdgmainroom Telegram Channel] || [https://invent.kde.org/teams/vdg Gitlab Issues (For current discussions)] || [https://www.figma.com/file/gjuIy1rxU9xHkaJXM0pasK/ocean-v3?node-id=1336%3A7194 New Breeze SVG Kit - Figma]
-|-
-| [https://mail.kde.org/mailman/listinfo/visual-design Mailing List] || ||
-|}
-{{Note|VDG task and project-tracking is moving to GitLab. [https://invent.kde.org/teams/vdg/issues/-/issues/new Click here to start a new discussion]}}
+We are also scoping PenPot for future designs. We will have more news soon.
+Beyond that, here are some timeless ways to get involved in ongoing work:
+* Learn how to design Breeze icons by reading [https://develop.kde.org/hig/style/icons/ the applicable HIG page], and then work on [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&component=Icons&list_id=1536878&product=Breeze&query_format=advanced Breeze icon bugs]. Here's [[Guidelines and HOWTOs/Submit an icon | how to submit an icon]].
+* Submit patches (using [https://invent.kde.org/documentation/hig-kde-org/merge_requests GitLab]) for corrections and improvements to the [https://develop.kde.org/hig/ Human Interface Guidelines]
 == Know Yourself ==
-In a highly technical field like programming, it's easy to ecnounter 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:
+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 ==
+== See also ==
-* [[Guidelines_and_HOWTOs/Change_the_default_wallpaper|How to change the default wallpaper]]
+* [[Get Involved/Design/Frequently Discussed Topics|Frequently Discussed Topics]]
-* [[Guidelines and HOWTOs/Submit an icon | How to submit changes to an icon or submit a new icon]]
+* [[Guidelines and HOWTOs/Change_the_default_wallpaper|How to change the default wallpaper]]
-* [[Guidelines and HOWTOs/Icon Workflow Tips| Icon workflow tips]]
+* [[Guidelines and HOWTOs/Submit an icon|How to submit changes to an icon or submit a new icon]]
+* [[Guidelines and HOWTOs/Icon Workflow Tips|Icon workflow tips]]
+* [[KDE Visual Design Group/Archive|Archive of outdated documents that may still be useful for historical reference]]
-== Old Things ==
-* [[KDE_Visual_Design_Group/Archive | Archive of outdated documents that may still be useful for reference]]