Get Involved/design: Difference between revisions

From KDE Community Wiki

Latest revision as of 16:48, 19 December 2024

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 current visual style (Breeze) is constantly improving based on user and designer feedback. Because it's an inherently moving target (and the implementation that really matters is the one that's shipping to users rather than the ones in design toolkits), we recommend using wireframes or low-fidelity mockups in general. This way everyone can focus on UX changes rather than the differences between current components and the (inevitably different) implementation in your design tool. We recommend trying to reuse existing UX patterns from both Breeze and other systems users are already familiar with (like Material Design, Apple's HIG, etc) if applicable.

We're also planning on incorporating Penpot for VDG workflows – expect to have a reasonably complete component library and other VDG-specific plugins later this year.

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

Icons

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.
Icon workflow tips

Wallpapers

Human Interface Guidelines

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 VDG ==
 [[File:Mascot konqi-app-graphics.png|frameless|right|200px|]]
-The VDG started out as the Visual Design Group, but has grown into a team dedicated to the whole user experience, including what is often called human interface design. The aim is to help KDE create software that is both beautiful and a pleasure to use. VDG has created and maintains the [https://hig.kde.org/ KDE Human Interface Guidelines] and the [[Get_Involved/design/Breeze | Breeze theme]] used throughout KDE Plasma and applications.
+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 [https://develop.kde.org/hig KDE Human Interface Guidelines] and the [[Get_Involved/design/Breeze | Breeze theme]] used throughout KDE Plasma and applications.
+== Getting Started ==
+==='''Learn first, then do!'''===
-VDG is always looking for 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 you to join in. Our group regularly interfaces with users, developers, and the Promo team, so flexibility and the ability to communicate with many different kinds of people are a boon.
+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.
-{{Note|VDG task and project tracking will be in GitLab in the future once the GitLab migration is complete. However for now we still use Phabricator for this.)}}
+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 [https://go.kde.org/matrix/#/#visualdesigngroup:kde.org Matrix].
+<gallery>
+MatrixLogo.jpg|Matrix|link=https://go.kde.org/matrix/#/#visualdesigngroup:kde.org
+</gallery>
+== 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 [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.
+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 [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.
 == Current Projects ==
-Feel free to have a look at VDG's current projects, which are are listed on the [https://phabricator.kde.org/project/board/89/ Phabricator workboard]. In addition, here are some timeless ways to get involved in ongoing work:
+Our current visual style (Breeze) is constantly improving based on user and designer feedback. Because it's an inherently moving target (and the implementation that really matters is the one that's shipping to users rather than the ones in design toolkits), we recommend using wireframes or low-fidelity mockups in general. This way everyone can focus on UX changes rather than the differences between current components and the (inevitably different) implementation in your design tool.
-* Learn how to design Breeze icons by reading [https://hig.kde.org/style/icons/index.html 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]].
+We recommend trying to reuse existing UX patterns from both Breeze and other systems users are already familiar with (like Material Design, Apple's HIG, etc) if applicable.
-* Submit patches (using [https://invent.kde.org/websites/hig-kde-org/merge_requests GitLab]) for corrections and improvements to the [http://hig.kde.org Human Interface Guidelines]
-== Communication and Workflow ==
+We're also planning on incorporating Penpot for VDG workflows – expect to have a reasonably complete component library and other VDG-specific plugins later this year.
-First, subscribe to the [https://mail.kde.org/mailman/listinfo/visual-design visual-design] mailing list to hear about general news and updates. You'll also want to become a member of the VDG team in GitLab. YOu can request access here: https://invent.kde.org/groups/teams/vdg/-/group_members Finally, join the [https://webchat.kde.org/#/room/#kde-vdg:kde.org #kde-vdg] channel on [[Matrix]] or the freenode [[Internet Relay Chat | IRC channel]] (which is bridged to the [https://telegram.me/vdgmainroom VDG] Telegram room, if you prefer [[Telegram]]).
-Most VDG discussions start out informally, in the chat channel. Once there's general agreement in the real-time chat, the discussion moves to a Phabricator task. The goal here is to open the discussion to include developers, and make the proposal more concrete using images and mockups. Mockups can be created using KDE's [[KDE Visual Design Group/HIG/MockupToolkit | Mockup Toolkit]].
+Beyond that, here are some timeless ways to get involved in ongoing work:
-It's important that VDG Phabricator tasks subscribe all the developers who may be affected by the proposed work. Try to honestly and fairly summarize the discussion and initial VDG conclusion when writing the task's initial description. It's important not to lose context or history!
+=== Icons ===
+* 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]].
+* [[Guidelines and HOWTOs/Icon Workflow Tips|Icon workflow tips]]
-In the Phabricator task, it's common for the details or scope to change based on developer feedback. This is normal! Developers have a better idea of what's technically possible or reasonable to change. Listen to developer feedback and change the design accordingly. At the same time, encourage them to listen to your expertise, and gently stand your ground if a developer tries to dictate design decisions to you.
+=== Wallpapers ===
+* [[Design/Wallpapers/Wallpaper design guidelines|Wallpaper design guidelines]]
+* [[Design/Wallpapers/Change the default_wallpaper|How to change the default wallpaper]]
+* [[Design/Wallpapers|More about wallpapers]]
-Once there's general agreement in the Phabricator task, work should begin and folks can start submitting patches!
+=== Human Interface Guidelines ===
+* 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 know 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 your own limitations. 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, don't involve yourself heavily in design work, and accept direction from experienced designers
+* If you know you're not very artistically skilled, listen attentively to developers and experienced designers on what we look for.
-* If you produce designs that people aren't very enthusiastic about, try to solicit honest feedback regarding what could be improved rather than pushing on them
+* Request honest feedback for your design proposals regarding what could be improved rather than blindly pushing on them.
-* If you don't have any skill or background in human/computer interaction, leave those discussions to the pros
+* If you want to learn more about human-computer interaction, offer to help in testing interactions and providing feedback.
-== Lessons learned ==
-Over the years, certain design conversations and ideas seem to recur. We have collected the result at [[Get Involved/Design/Lessons Learned]].
-==Old Things==
+== See also ==
-* [[KDE_Visual_Design_Group/Archive | Archive of outdated documents that may still be useful for reference]]
+* [[Get Involved/Design/Frequently Discussed Topics|Frequently Discussed Topics]]
+* [[KDE Visual Design Group/Archive|Archive of outdated documents that may still be useful for historical reference]]