Get Involved/design: Difference between revisions

From KDE Community Wiki
m (Alexmerry moved page Get Involved/art to Get Involved/design: Pointing people to the VDG is more appropriate these days)
(→‎Know Yourself: Make it a list)
(26 intermediate revisions by 5 users not shown)
Line 1: Line 1:
__NOTOC__
== About the VDG ==
== Becoming a KDE Artist ==
[[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.


[[Image:art.png|Art|left]] Are you able to create images that move people? Projects in KDE are always in need of good art. Icons, splash screens and themes create an identity for an application. By creating art for the KDE project, your portfolio will be seen by a large audience and will help KDE products have a strong branding.
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.


== Communicating with the team ==
{{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.)}}


New KDE Artists are encouraged to start at [irc://irc.kde.org/kde-artists <nowiki>#kde-artists</nowiki>] on irc.freenode.net, (or [http://kde.org/support/#irc learn more about IRC]), which is the most active. The team also discusses activities on the [http://mail.kde.org/mailman/listinfo/kde-artists kde-artists mailing list], [http://kde.org/support/#mailinglists learn about mailing lists].


== Documentation ==
== 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:
* 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]].
* 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]


The art in KDE follows certain guidelines, you will want to keep these for reference. These links may be outdated, so it is always best to check with the team:
== Communication and Workflow ==
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]]).


* [http://web.archive.org/web/20080116142850/kde-artists.org/node/102 Artwork Guidelines] - explain the proper use of logo and implementation of splash screens
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]].
* [http://techbase.kde.org/Projects/Oxygen/Style Icon Guidelines] - detail the proper creation of icons
* [http://techbase.kde.org/Projects/Oxygen/Style#Color_Usage Oxygen Color Palette] - colors for KDE 4


== Tasks ==
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!


To get started, demonstrate your skills by completing the [http://web.archive.org/web/20071217104813/kde-artists.org/node/116 KDE Icon Bootcamp] and bringing the results to the team.
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.


Then find inspiration at [http://websvn.kde.org/trunk/playground/artwork/Oxygen/docs/ The KDE Icon Request List].
Once there's general agreement in the Phabricator task, work should begin and folks can start submitting patches!


== Mentor program ==
== 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:
* 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 produce designs that people aren't very enthusiastic about, try to solicit honest feedback regarding what could be improved rather than pushing on them
* If you don't have any skill or background in human/computer interaction, leave those discussions to the pros


For getting started, feel free to direct any questions to a mentor for this project:
== Lessons learned ==
Over the years, certain design conversations and ideas seem to recur. We have collected the result at [[Get Involved/Design/Lessons Learned]].


* Nuno Pinheiro (<span class="mailme">nuno at oxygen-icons dot org</span>)<br /> Style theme and cursor theme art director and core icon designer
==Old Things==
* [[KDE_Visual_Design_Group/Archive | Archive of outdated documents that may still be useful for reference]]

Revision as of 23:49, 23 June 2020

About the VDG

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 KDE Human Interface Guidelines and the Breeze theme used throughout KDE Plasma and applications.

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.

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.)


Current Projects

Feel free to have a look at VDG's current projects, which are are listed on the Phabricator workboard. In addition, here are some timeless ways to get involved in ongoing work:

Communication and Workflow

First, subscribe to the 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 #kde-vdg channel on Matrix or the freenode IRC channel (which is bridged to the 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 Mockup Toolkit.

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!

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.

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

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:

  • 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 produce designs that people aren't very enthusiastic about, try to solicit honest feedback regarding what could be improved rather than pushing on them
  • If you don't have any skill or background in human/computer interaction, leave those discussions to the pros

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