Jump to content

Goals/Consistency: Difference between revisions

From KDE Community Wiki
Ngraham (talk | contribs)
No edit summary
Ngraham (talk | contribs)
No edit summary
Line 1: Line 1:
== Intro ==
== Intro ==


KDE community has [https://phabricator.kde.org/T11093 elected] to put Consistency as a main goal for the coming years.
KDE community has [https://phabricator.kde.org/T11093 selected] Consistency as a main goal for the coming years.


Consistency here is meant as implementing the same type of user interface elements in the same way across apps. For example, sidebars in settings windows should all have the same appearance and behavior.
"Consistency" here is meant as implementing the same type of user interface elements in the same way across apps. For example, sidebars in settings windows should all have the same appearance and behavior.


Benefits of consistency include:
Benefits of consistency include:
* Better software usability: users will recognize patterns across KDE applications, making each one easier to use and master.
* Better software usability: users will recognize patterns across KDE applications, making each one easier to learn and master.
* Use of consistent visual elements throughout KDE software improves KDE branding, and users will be able to quickly recognize KDE Apps.
* Use of consistent visual elements throughout KDE software improves KDE branding, and users will be able to quickly recognize KDE Apps.
* Reduced code redundancy and easier maintainability of the codebase.
* Reduced code redundancy and easier maintainability of the codebase.
* Reduce difficulty of writing new software because re-usable components are available, with high enough quality that nobody will want to create their own implementations.
* Reduce difficulty of writing new software because re-usable components are available, with high enough quality that nobody will want to create their own implementations.


Line 25: Line 25:
=== Defining clear Human Interface Guidelines ===
=== Defining clear Human Interface Guidelines ===


When there is consensus regarding the new design, this should be documented clearly in the Human Interface Guidelines (HIG) in order for future developers to know how they should implement their applications. Again, it's not necessary to have coding skills! It's possible to read the current HIG [https://hig.kde.org/ in its webpage] and propose changes in [https://invent.kde.org/websites/hig-kde-org its repository].
When a consensus is reached regarding the new design, this should be documented clearly in the Human Interface Guidelines (HIG) in order for future developers to know how they should implement their applications. Again, it's not necessary to have coding skills! It's possible to read the current HIG [https://hig.kde.org/ in its webpage] and propose changes in [https://invent.kde.org/websites/hig-kde-org its repository].


=== Implementing changes ===
=== Implementing changes ===


Finally, it's now time to implement the new design in all KDE Applications. This requires some development skills, but in the process you'll learn portable, industry-standard skills like C++, Qt, and CMake, and collaborate with people from all around the world. It's a challenging and fun experience. [https://community.kde.org/Get_Involved/development Find out more about becoming a KDE developer].
Finally, it's now time to implement the new design in all KDE Applications. This requires some development abilities, but in the process you'll learn portable, industry-standard skills like C++, Qt, and CMake, and collaborate with people from all around the world. It's a challenging and fun experience. [https://community.kde.org/Get_Involved/development Find out more about becoming a KDE developer].


=== Consistency group ===
=== Consistency group ===


There's a [https://webchat.kde.org/#/room/%23consistency:kde.org specific channel] for consistency-related topics on Matrix in which everybody can join and help. Furthermore, it's also possible to follow consistency improvements and tasks in its [https://phabricator.kde.org/project/view/312/ phabricator project].
There's a [https://webchat.kde.org/#/room/%23consistency:kde.org specific channel] for consistency-related topics on Matrix in which everybody can join and help. Furthermore, it's also possible to follow consistency improvements and tasks in its [https://phabricator.kde.org/project/view/312/ phabricator project].

Revision as of 19:26, 6 October 2019

Intro

KDE community has selected Consistency as a main goal for the coming years.

"Consistency" here is meant as implementing the same type of user interface elements in the same way across apps. For example, sidebars in settings windows should all have the same appearance and behavior.

Benefits of consistency include:

  • Better software usability: users will recognize patterns across KDE applications, making each one easier to learn and master.
  • Use of consistent visual elements throughout KDE software improves KDE branding, and users will be able to quickly recognize KDE Apps.
  • Reduced code redundancy and easier maintainability of the codebase.
  • Reduce difficulty of writing new software because re-usable components are available, with high enough quality that nobody will want to create their own implementations.

Improving Consistency

There are various ways to help to improve consistency, regardless of anybody's level of technical expertise.

Reporting Inconsistencies

A very important task is to actually find the inconsistencies to fix in KDE Applications. This can be done by any user, even with limited or no knowledge about coding. Helping with this task is as easy as using multiple KDE Applications and trying to find visual elements that are implemented in different ways. When an inconsistency is found, it can be reported to the bugtracker or a task can be created on the Consistency phabricator workboard.

Designing consistent elements

When an inconsistency is found, it's the Visual Design Group's (VDG) job to design an element that can be used consistently throughout all KDE Applications. It's really easy to join the VDG to help with this task! Find out more about joining the KDE documentation team.

Defining clear Human Interface Guidelines

When a consensus is reached regarding the new design, this should be documented clearly in the Human Interface Guidelines (HIG) in order for future developers to know how they should implement their applications. Again, it's not necessary to have coding skills! It's possible to read the current HIG in its webpage and propose changes in its repository.

Implementing changes

Finally, it's now time to implement the new design in all KDE Applications. This requires some development abilities, but in the process you'll learn portable, industry-standard skills like C++, Qt, and CMake, and collaborate with people from all around the world. It's a challenging and fun experience. Find out more about becoming a KDE developer.

Consistency group

There's a specific channel for consistency-related topics on Matrix in which everybody can join and help. Furthermore, it's also possible to follow consistency improvements and tasks in its phabricator project.