Change Details

=Description= Plasma, as a design beacon for the ecosystem, aims to drive a consistent and engaging user experience across a diverse range of digital interfaces. Implementing a design system like Plasma for a desktop user interface involves several key steps. Plasma has stayed behind the times when it comes to modern design systems. This drives a few issues for the platform: ### Developers are Designers Developers in Plasma need to meddle with the look and feel of the systems that they create. While they may be focused on implementation of new features, they have to make a long pit-stop in the design department. Developers have to deal with graphical alignment, fonts, colors, button implementation, states, animations, etc. It’s simply a lot to ask for our developers. ### Designers are Developers On the other hand, many designers have to go out of their design lane to work on implementation issues and deal with the many complexities of code development. Libraries, frameworks, limitations, etc. It all becomes too confusing. It’s no wonder that the majority of our audience in the Visual Design channel are not designers. The barrier to entry for creatives is high and discouraging. ### Multiple Frameworks Added to the trouble of working with different skillsets and extending these skills to areas of un-interest for the audience, we have to time that work by 2 and sometimes 3 given the multiple frameworks we have available in Plasma. This, to a small group of core developers kills initiatives and disincentivizes progress. The many frameworks also divide the community into those who know the older or preceding framework and makes the community pick sides or pick none. ### Visual Inconsistency As a result, the visual consistency of the system is in constant “development”. Multiple ideas become fires, implementing features lag behind other more robust systems. Plasma suffers from constant visual re-development that seems to never end. Buttons, sliders, menus look different depending on the framework of choice and the allowances or limitations of that framework. ### Slow and Overwhelming Development Cycles, Lack of Visual Direction In turn, the resulting mix shows that development cycles, people involved in development have to go the extra mile to achieve results. This is exacerbated by the small development pool, framework development multiplication and community members having to develop skills in difficult areas. This makes it so that accepted features remain small to accommodate to our small resources. The visual direction of the platform also suffers as more features are added they perpetuate teh visual changes we should have. With additional attention from many companies and the choice of popular devices, Plasma should enable systems that speed up development. # Current Developments ### New Human Interface Guidelines Our previous Human Interface Guidelines (HIG), were extremely updated, to put it mildly. Nate Graham took on the work of simplifying the HIG and making it more consumable for our developer audience. As of right now, the new version is live after long revisions from the team. ### 24px Icon Collection Plasma decided to develop (and hopefully adopt) the 24px icon collection. This means we would abandon the non-standard base size of 22px currently used. A small team of designers took the task and has been working for months to adapt from 22px to 24px. The changes go deeper than that as there are other collections that will need to be intervened because of this work. As of right now, the entire 22px collection has been created in 24px. ### Design System Creation The same team of designers took established practices in building design systems and created new sets of foundational elements of the collection. Buttons, typography, colors, spacings, and shadows and blurs are prepared. These elements would become the foundation upon which reusable UI components can be built. ### Theme Builder Arjen has been working on a theme engine that should make it much easier for users to create and submit themes to Plasma. # What we should do! 1. **Creating a Visual Language:** This step involves creating a consistent visual language that includes color schemes, typography, icons, and other UI elements. 1. Using the foundations of the new design system, the team will prepare the basis of the entire new system. While the work is long, the results will go a long way to creating and keeping consistency in the system. 2. Should things change at some point, designers can help in a connected way with developers. 2. **Building Components:** Once the visual language is set, it's time to build reusable components like buttons, forms, and menus. Each should be carefully designed to ensure consistency and usability. 1. This step involves the creation of standard components for buttons, progress bars, radiobuttons, checkboxes, badges, inputs, dropdowns, toggles, avatars, tooltips, etc. 2. Using the guidelines from the design system, developers would have a map set out to exactly what to do. Measurements are all provided by the CSS export from the design application. Easier to interpret and implement. 3. **Establishing Layout Guidelines:** Layout guidelines help in placing components appropriately on the screen, considering factors like alignment, spacing, and grid use. 1. Largely covered, in principle, by the new HIG, our applications will receive a facelift using the simplified components. 4. **Documenting the Design System:** After creating the components and patterns, it's essential to document the system. This document serves as a reference for developers and designers, ensuring consistency across different projects. 1. At the same time that components are created, the design team can provide a documentation space in the HIG to show the changes and preferred patterns. Using a combination of material markdown, the team is able to show actual components from the design application into the HIG. The HIG will contain the latest graphical version of the element being presented making it much easier to document and keep all readers up to date. 5. **Incorporating Feedback and Improving:** A design system is not a one-and-done project. It should continuously evolve based on user feedback and technological advancements. =What it will take= ### Year 1 - Implement design system guidelines - Build the first foundational elements like color and typography ### Year 2 - Create a collection of new UI components - Document components in HIG =How we know we succeeded= //Will we have fluffy kittens? Anything we can measure? How will the world be better once we're done with this?// =Relevant links= //Any links that will help people find more information and understand the goal better?// =Champions= //We want this year's goals to be driven by small teams. Who will be this goals champions if selected? If you don't yet have a small team please mention what you are looking for still so others can step up. We believe a goal generally needs someone who can carry the vision of the goal forward, someone who can technically steer it and someone to promote it.// The team is: * Andy Betts: Andy is a long-time KDE contributor dating back to the year 2000. Andy has provided help all across visual design areas such as the Human Interface Guidelines, KDE 4 design, Breeze theme, wallpapers, System Settings and application design. Andy is a user experience and UI designer currently working on a few graphical projects for the community. * XXX * XXX =I am willing to put work into this= * add your name =I am interested= * add your name

=Description= Plasma, as a design beacon for the ecosystem, aims to drive a consistent and engaging user experience across a diverse range of digital interfaces. Implementing a design system like Plasma for a desktop user interface involves several key steps. Plasma has stayed behind the times when it comes to modern design systems. This drives a few issues for the platform: ### Developers are Designers Developers in Plasma need to meddle with the look and feel of the systems that they create. While they may be focused on implementation of new features, they have to make a long pit-stop in the design department. Developers have to deal with graphical alignment, fonts, colors, button implementation, states, animations, etc. It’s simply a lot to ask for our developers. ### Designers are Developers On the other hand, many designers have to go out of their design lane to work on implementation issues and deal with the many complexities of code development. Libraries, frameworks, limitations, etc. It all becomes too confusing. It’s no wonder that the majority of our audience in the Visual Design channel are not designers. The barrier to entry for creatives is high and discouraging. ### Multiple Frameworks Added to the trouble of working with different skillsets and extending these skills to areas of un-interest for the audience, we have to time that work by 2 and sometimes 3 given the multiple frameworks we have available in Plasma. This, to a small group of core developers kills initiatives and disincentivizes progress. The many frameworks also divide the community into those who know the older or preceding framework and makes the community pick sides or pick none. ### Visual Inconsistency As a result, the visual consistency of the system is in constant “development”. Multiple ideas become fires, implementing features lag behind other more robust systems. Plasma suffers from constant visual re-development that seems to never end. Buttons, sliders, menus look different depending on the framework of choice and the allowances or limitations of that framework. ### Slow and Overwhelming Development Cycles, Lack of Visual Direction In turn, the resulting mix shows that development cycles, people involved in development have to go the extra mile to achieve results. This is exacerbated by the small development pool, framework development multiplication and community members having to develop skills in difficult areas. This makes it so that accepted features remain small to accommodate to our small resources. The visual direction of the platform also suffers as more features are added they perpetuate teh visual changes we should have. With additional attention from many companies and the choice of popular devices, Plasma should enable systems that speed up development. ## Current Developments ### New Human Interface Guidelines Our previous Human Interface Guidelines (HIG), were extremely updated, to put it mildly. Nate Graham took on the work of simplifying the HIG and making it more consumable for our developer audience. As of right now, the new version is live after long revisions from the team. ### 24px Icon Collection Plasma decided to develop (and hopefully adopt) the 24px icon collection. This means we would abandon the non-standard base size of 22px currently used. A small team of designers took the task and has been working for months to adapt from 22px to 24px. The changes go deeper than that as there are other collections that will need to be intervened because of this work. As of right now, the entire 22px collection has been created in 24px. ### Design System Creation The same team of designers took established practices in building design systems and created new sets of foundational elements of the collection. Buttons, typography, colors, spacings, and shadows and blurs are prepared. These elements would become the foundation upon which reusable UI components can be built. ### Theme Builder Arjen has been working on a theme engine that should make it much easier for users to create and submit themes to Plasma. ## What we should do! 1. **Creating a Visual Language:** This step involves creating a consistent visual language that includes color schemes, typography, icons, and other UI elements. 1. Using the foundations of the new design system, the team will prepare the basis of the entire new system. While the work is long, the results will go a long way to creating and keeping consistency in the system. 2. Should things change at some point, designers can help in a connected way with developers. 2. **Building Components:** Once the visual language is set, it's time to build reusable components like buttons, forms, and menus. Each should be carefully designed to ensure consistency and usability. 1. This step involves the creation of standard components for buttons, progress bars, radiobuttons, checkboxes, badges, inputs, dropdowns, toggles, avatars, tooltips, etc. 2. Using the guidelines from the design system, developers would have a map set out to exactly what to do. Measurements are all provided by the CSS export from the design application. Easier to interpret and implement. 3. **Establishing Layout Guidelines:** Layout guidelines help in placing components appropriately on the screen, considering factors like alignment, spacing, and grid use. 1. Largely covered, in principle, by the new HIG, our applications will receive a facelift using the simplified components. 4. **Documenting the Design System:** After creating the components and patterns, it's essential to document the system. This document serves as a reference for developers and designers, ensuring consistency across different projects. 1. At the same time that components are created, the design team can provide a documentation space in the HIG to show the changes and preferred patterns. Using a combination of material markdown, the team is able to show actual components from the design application into the HIG. The HIG will contain the latest graphical version of the element being presented making it much easier to document and keep all readers up to date. 5. **Incorporating Feedback and Improving:** A design system is not a one-and-done project. It should continuously evolve based on user feedback and technological advancements. =What it will take= ### Year 1 - Implement design system guidelines - Build the first foundational elements like color and typography ### Year 2 - Create a collection of new UI components - Document components in HIG =How we know we succeeded= //Will we have fluffy kittens? Anything we can measure? How will the world be better once we're done with this?// =Relevant links= //Any links that will help people find more information and understand the goal better?// =Champions= The team is: * Andy Betts: Andy is a long-time KDE contributor dating back to the year 2000. Andy has provided help all across visual design areas such as the Human Interface Guidelines, KDE 4 design, Breeze theme, wallpapers, System Settings and application design. Andy is a user experience and UI designer currently working on a few graphical projects for the community. * XXX * XXX =I am willing to put work into this= * add your name =I am interested= * add your name

=Description= Plasma, as a design beacon for the ecosystem, aims to drive a consistent and engaging user experience across a diverse range of digital interfaces. Implementing a design system like Plasma for a desktop user interface involves several key steps. Plasma has stayed behind the times when it comes to modern design systems. This drives a few issues for the platform: ### Developers are Designers Developers in Plasma need to meddle with the look and feel of the systems that they create. While they may be focused on implementation of new features, they have to make a long pit-stop in the design department. Developers have to deal with graphical alignment, fonts, colors, button implementation, states, animations, etc. It’s simply a lot to ask for our developers. ### Designers are Developers On the other hand, many designers have to go out of their design lane to work on implementation issues and deal with the many complexities of code development. Libraries, frameworks, limitations, etc. It all becomes too confusing. It’s no wonder that the majority of our audience in the Visual Design channel are not designers. The barrier to entry for creatives is high and discouraging. ### Multiple Frameworks Added to the trouble of working with different skillsets and extending these skills to areas of un-interest for the audience, we have to time that work by 2 and sometimes 3 given the multiple frameworks we have available in Plasma. This, to a small group of core developers kills initiatives and disincentivizes progress. The many frameworks also divide the community into those who know the older or preceding framework and makes the community pick sides or pick none. ### Visual Inconsistency As a result, the visual consistency of the system is in constant “development”. Multiple ideas become fires, implementing features lag behind other more robust systems. Plasma suffers from constant visual re-development that seems to never end. Buttons, sliders, menus look different depending on the framework of choice and the allowances or limitations of that framework. ### Slow and Overwhelming Development Cycles, Lack of Visual Direction In turn, the resulting mix shows that development cycles, people involved in development have to go the extra mile to achieve results. This is exacerbated by the small development pool, framework development multiplication and community members having to develop skills in difficult areas. This makes it so that accepted features remain small to accommodate to our small resources. The visual direction of the platform also suffers as more features are added they perpetuate teh visual changes we should have. With additional attention from many companies and the choice of popular devices, Plasma should enable systems that speed up development. ## Current Developments ### New Human Interface Guidelines Our previous Human Interface Guidelines (HIG), were extremely updated, to put it mildly. Nate Graham took on the work of simplifying the HIG and making it more consumable for our developer audience. As of right now, the new version is live after long revisions from the team. ### 24px Icon Collection Plasma decided to develop (and hopefully adopt) the 24px icon collection. This means we would abandon the non-standard base size of 22px currently used. A small team of designers took the task and has been working for months to adapt from 22px to 24px. The changes go deeper than that as there are other collections that will need to be intervened because of this work. As of right now, the entire 22px collection has been created in 24px. ### Design System Creation The same team of designers took established practices in building design systems and created new sets of foundational elements of the collection. Buttons, typography, colors, spacings, and shadows and blurs are prepared. These elements would become the foundation upon which reusable UI components can be built. ### Theme Builder Arjen has been working on a theme engine that should make it much easier for users to create and submit themes to Plasma. ## What we should do! 1. **Creating a Visual Language:** This step involves creating a consistent visual language that includes color schemes, typography, icons, and other UI elements. 1. Using the foundations of the new design system, the team will prepare the basis of the entire new system. While the work is long, the results will go a long way to creating and keeping consistency in the system. 2. Should things change at some point, designers can help in a connected way with developers. 2. **Building Components:** Once the visual language is set, it's time to build reusable components like buttons, forms, and menus. Each should be carefully designed to ensure consistency and usability. 1. This step involves the creation of standard components for buttons, progress bars, radiobuttons, checkboxes, badges, inputs, dropdowns, toggles, avatars, tooltips, etc. 2. Using the guidelines from the design system, developers would have a map set out to exactly what to do. Measurements are all provided by the CSS export from the design application. Easier to interpret and implement. 3. **Establishing Layout Guidelines:** Layout guidelines help in placing components appropriately on the screen, considering factors like alignment, spacing, and grid use. 1. Largely covered, in principle, by the new HIG, our applications will receive a facelift using the simplified components. 4. **Documenting the Design System:** After creating the components and patterns, it's essential to document the system. This document serves as a reference for developers and designers, ensuring consistency across different projects. 1. At the same time that components are created, the design team can provide a documentation space in the HIG to show the changes and preferred patterns. Using a combination of material markdown, the team is able to show actual components from the design application into the HIG. The HIG will contain the latest graphical version of the element being presented making it much easier to document and keep all readers up to date. 5. **Incorporating Feedback and Improving:** A design system is not a one-and-done project. It should continuously evolve based on user feedback and technological advancements. =What it will take= ### Year 1 - Implement design system guidelines - Build the first foundational elements like color and typography ### Year 2 - Create a collection of new UI components - Document components in HIG =How we know we succeeded= //Will we have fluffy kittens? Anything we can measure? How will the world be better once we're done with this?// =Relevant links= //Any links that will help people find more information and understand the goal better?// =Champions= //We want this year's goals to be driven by small teams. Who will be this goals champions if selected? If you don't yet have a small team please mention what you are looking for still so others can step up. We believe a goal generally needs someone who can carry the vision of the goal forward, someone who can technically steer it and someone to promote it.// The team is: * Andy Betts: Andy is a long-time KDE contributor dating back to the year 2000. Andy has provided help all across visual design areas such as the Human Interface Guidelines, KDE 4 design, Breeze theme, wallpapers, System Settings and application design. Andy is a user experience and UI designer currently working on a few graphical projects for the community. * XXX * XXX =I am willing to put work into this= * add your name =I am interested= * add your name