Reevaluate design vision and principles
Open, NormalPublic

Description

The current "Classic" HIG features the following design vision [1]:

The design vision focuses on two attributes of KDE software that connect its past to its future.

  • Simple by default - Simple and inviting. KDE software is pleasant to experience and easy to use.
  • Powerful when needed - Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive.

And several design principles derived from this vision:

  • Simple by default
    • Make it easy to focus on what matters. - Remove or minimize elements not crucial to the primary or main task. Use spacing to keep things organized. Use color to draw attention. Reveal additional information or optional functions when needed, later in the presentation.
    • I know how to do that! - Make things easier to learn by reusing design patterns from other applications. Other applications that use good design are a precedent to follow.
    • Do the heavy lifting for me. - Make complex tasks simple. Make novices feel like experts. Create ways in which your users can naturally feel empowered by your software.
  • Powerful when needed
    • Solve a problem. - Identify and make very clear to the user what need is addressed and how.
    • Always in control. - It should always be clear what can be done, what is happening and what happened. The user should never feel at the mercy of the tool. Give the user the final say.
    • Be flexible. - Provide sensible defaults but consider optional functionality or customizations that do not interfere with the primary task.

While vision and derived principles still embody certain aspects of the KDE Plasma and KDE Apps experience, I would nevertheless like to reevaluate their overall usefulness nowadays and their formulation in detail. There are mainly three reasons for this:

  1. Vision and principles are old. Formulated several years ago they stayed the same while the workspace and our mobile efforts moved on. In particular we have yet to combine them with Kirigami.
  2. Principles are too abstract. In comparison to other modern software HIGs that do introduce design principles at the start [2][3] our ones are too abstract and not directly relate to graphical concepts.
  3. A finite set of concrete design principles should allow us to easily structure a holistic HIG in our new reST format and we should be able to move individual guideline pages from the Wiki to the right positions in this structure.

A first step to improve upon the current vision and design principles is an evaluation of the status quo. Where did our desktop, mobile platform and apps move in the last few years? How is this still reflected by design vision and principles, and how can the principles be made more tangible in light of this progression? Also in this context what are the design elements, that our users grew to like about recent Plasma/KDE Apps interfaces and how can we formulate the underlying concepts as concrete and comprehensible design principles? At last is our design vision still in line with these principles?

[1] https://community.kde.org/KDE_Visual_Design_Group/HIG/Presentation/DesignVisionPrinciples
[2] https://material.io/guidelines/#introduction-principles
[3] https://docs.microsoft.com/de-de/windows/uwp/design/fluent-design-system/index

romangg created this task.Feb 16 2018, 2:31 PM
romangg triaged this task as Normal priority.
romangg updated the task description. (Show Details)Feb 16 2018, 2:37 PM

Two design patterns, which I took from the Material and Fluent Design HIGs linked in OP compared against our currently implemented interfaces (for example Kickoff, Discover, Dolphin, Kate):

Colors
We use colors very sparsely in our current interfaces. Most of the time we basically have one (subtle) background color, a bright highlight color, that always signals focus, and a bright warning color. Strong colors therefore directly signal functionality to the user. This is for example a clear distinction from Material Design, that works with many bold colors as background to express hierarchy and structure.

A tangible design principle to derive from that could be: "Restricted use of colors to express functionality"

Material/Forms
We use distinct forms very sparsely. When used these are most often only straight lines to express structure. Otherwise we use subtle hue differences to express structure or current state (this is often ambiguous in our current implementations!) and drop shadows for structure.

A tangible design principle to derive from that could be: "Minimal use of lines and shadows to express structure, light to express state"

romangg added a comment.EditedFeb 16 2018, 5:22 PM

The two design principles derived above that are related to colors and material/forms are also good examples on why our current design principles are too abstract.

"Restricted use of colors to express functionality" as an example can be related to the design principle "Make it easy to focus on what matters" from our current HIG. But while the first one gives the developer a clear guideline on how to use visual elements in his/her application, the one from our current HIG can not.

A practical example would be Discover, that currently uses lines in highlight color to express structure at some instances in lists and in application pages. I know that this led to discussions in the past. The principle to use colors only to express functionality and not structure would directly decide this discussion in favor of not using highlight color. The principle to make it easy to focus on what matters from our current HIG on the other side does not give a clear guideline on how to deal with it, because it is more a slogan, that any given interface design would try to follow and without clear right/wrong criteria. It therefore becomes meaningless to the developer.

abetts added a subscriber: abetts.Feb 17 2018, 6:25 PM

The two design principles derived above that are related to colors and material/forms are also good examples on why our current design principles are too abstract.

"Restricted use of colors to express functionality" as an example can be related to the design principle "Make it easy to focus on what matters" from our current HIG. But while the first one gives the developer a clear guideline on how to use visual elements in his/her application, the one from our current HIG can not.

A practical example would be Discover, that currently uses lines in highlight color to express structure at some instances in lists and in application pages. I know that this led to discussions in the past. The principle to use colors only to express functionality and not structure would directly decide this discussion in favor of not using highlight color. The principle to make it easy to focus on what matters from our current HIG on the other side does not give a clear guideline on how to deal with it, because it is more a slogan, that any given interface design would try to follow and without clear right/wrong criteria. It therefore becomes meaningless to the developer.

I don't particularly like having a divider line that is blue. A divider line, yes, but blue gives it a highlight that probably shouldn't be there.

I made some changes to the wiki to express my feelings about streamlining the design efforts for the community. Please review the changes and let's discuss it.

https://community.kde.org/KDE_Visual_Design_Group/HIG/Presentation/DesignVisionPrinciples

Thank you

mart added a subscriber: mart.Feb 22 2018, 6:02 PM

A vision is always very abstract by definition, anything that goes more in details simply doesn't belong there

maybe in a mission statement (which is, how to achieve the vision), or in the hig itself

what is needed is probably another pacge/thing that would be a checklist of "am i doing something wrong?" which things like when not use color would be adressed

To me Simple by default, powerfull when needed is only a usability vision, but it says nothing about the design. There is no "Breeze vision" to go along with it. E.g. at the moment there are a lot of activities regarding shadows and elevation (windows decoration, cards, ...) .
But there is nothing on why. Are we just elevating components that seem visually pleasing? Or to important parts of the document? Or is this supposed to show an interaction parent -> child pattern?
Like roman already noted, the same with colors. We have a breeze color palette, we have a HIG page for it, but there is nothing on it how to actually use color. And we have no breeze vision to deprive it from either.
There probably once was something like a vision and an mission statement for Breeze? But I couldn't find anything in the net and vdg channel nobody knew either.

In my opinion Simple by default, powerfull when needed is a quiet good vision for usability, but we should add a Breeze vision to it and add mission statements to both.

To me Simple by default, powerfull when needed is only a usability vision, but it says nothing about the design. There is no "Breeze vision" to go along with it. E.g. at the moment there are a lot of activities regarding shadows and elevation (windows decoration, cards, ...) .
But there is nothing on why. Are we just elevating components that seem visually pleasing? Or to important parts of the document? Or is this supposed to show an interaction parent -> child pattern?
Like roman already noted, the same with colors. We have a breeze color palette, we have a HIG page for it, but there is nothing on it how to actually use color. And we have no breeze vision to deprive it from either.
There probably once was something like a vision and an mission statement for Breeze? But I couldn't find anything in the net and vdg channel nobody knew either.

In my opinion Simple by default, powerfull when needed is a quiet good vision for usability, but we should add a Breeze vision to it and add mission statements to both.

I love these comments. I can add something along those lines, the way that I perceive them, but I would also invite Hugo and others that worked in creating the theme.

Thank you

What do you think of something like this to start with?

Color: is meaningful and it emphasizes meaning.

Depth: Provides relevancy and organization.

Shapes: Convey information and solve questions.

Textures: Provide solidity and ground themselves in the real world.

This came up in the VDG room today: we should clarify where sharp vs rounded elements should be used, and why. Breeze currently has a mix, so it seems important to help people understand why this mix exists, and what's appropriate for being rounded vs sharp.

Right now, Breeze seems to mostly follow the convention of sharp things within soft things (e.g sharp icons within rounded buttons). This is sort of an interesting point since sharp elements are likely to be seen as "masculine" and soft elements as "feminine" (see https://en.wikipedia.org/wiki/Bouba/kiki_effect). Breeze's default presentation is actually an inversion of the stereotypical traditional masculine and feminine roles: it has the soft feminine outside protecting the sharp core. I rather like this as a visual representation of the philosophy of "Simple by default, powerful when needed".

I like this idea:

We can probably just ask for a balance of the two. The category can be called "Shapes" as mentioned above.

For example:

"Shapes: Breeze favors a shape convention around softness and robustness. Therefore, we gravitate our shapes toward circles and squares. We use triangular shapes sparingly, and others that have multiple faces like hexagons, etc."

Don't take that literally, but does that address your point @ngraham ?

Partially. We might want to add something about what the shape styles communicate and where/why one might want to use them. For example, why does Breeze typically have sharpness inside softness, and what design vision does that communicate to the user?

fabianr added a comment.EditedFeb 28 2018, 12:58 PM

A suggestion about color.

That's what Apple:

Consider choosing a key color to indicate interactivity throughout your app. In Notes, interactive elements are yellow. In Calendar, interactive elements are red. If you define a key color that denotes interactivity, make sure other colors don’t compete with it.

https://developer.apple.com/ios/human-interface-guidelines/visual-design/color/

and MS:

Use color to indicate interactivity. It's a good idea to choose one color to indicate elements of your application that are interactive. For example, many web pages use blue text to denote a hyperlink. This also means you should avoid using the same color for noninteractive elements, as users may find this confusing.

https://docs.microsoft.com/de-de/windows/uwp/design/style/color

recomend regarding highlight colors.

I would suggest we, too, should encourage the use of Plasma Blue (our highlight color) only for interactive elements or to indicate the active state of elements, but not for decoration or chrome.

When you look at the color roles at https://community.kde.org/KDE_Visual_Design_Group/HIG/Color this is probably already the intended behavior, but it nowhere stated explicitly.

A suggestion about color.

That's what Apple:

Consider choosing a key color to indicate interactivity throughout your app. In Notes, interactive elements are yellow. In Calendar, interactive elements are red. If you define a key color that denotes interactivity, make sure other colors don’t compete with it.

https://developer.apple.com/ios/human-interface-guidelines/visual-design/color/

and MS:

Use color to indicate interactivity. It's a good idea to choose one color to indicate elements of your application that are interactive. For example, many web pages use blue text to denote a hyperlink. This also means you should avoid using the same color for noninteractive elements, as users may find this confusing.

https://docs.microsoft.com/de-de/windows/uwp/design/style/color

recomend regarding highlight colors.

I would suggest we, too, should encourage the use of Plasma Blue (our highlight color) only for interactive elements or to indicate the active state of elements, but not for decoration or chrome.

When you look at the color roles at https://community.kde.org/KDE_Visual_Design_Group/HIG/Color this is probably already the intended behavior, but it nowhere stated explicitly.

I am in favor of this!

Are we doing anything in particular with this information now?

TL;DR I think the KDE HIG needs to use a unifying concept as its main principle. This is likely to be vague but you can explain how it relates to the HIG. An example of such a unifying concept is kirigami (the art of folding and cutting).

As I understand it, the principles of a Human Interface Guidelines specification (i.e. the HIG) are the underlying concepts upon which all the guidelines in the specification are based. In essence, they are the guidelines for your guidelines, the principles upon which your guidelines are built. So all your guidelines need to be consistent with these principles.

Looking at the Material and Fluent Design principles, I noticed that there are generally very few principles. They essentially provide a unifying concept for their HIG.

  • With Material Design, there is only 1 principle: "being inspired by the physical world and its textures". This is further explained, revealing how this relates to their HIG, but it all relates to this single unifying concept.
  • With Fluent Design, there are 3 principles: Adaptive, Empathetic and Beautiful. Each of these is again explained, revealing how they relate to their HIG.

I think this is where the KDE HIG is lacking. There is no real unifying concept being explained in the principles of the HIG. This probably also makes it hard to make guidelines that are consistent with each other. And it makes it practically impossible to judge whether an idea fits within the style expressed by the KDE HIG.

I don't know much about design or UX but here is an example of principles for the KDE HIG that should show how such principles could relate to the actual guidelines in the HIG. These principles are no longer based on the "Simple by default, powerful when needed" characteristic of KDE software. While this is definitely something to keep in mind, I don't think it directly relates to the design principles.

Example
As unifying concept for the KDE HIG, I'd like to use kirigami. I'm referring to the actual art of folding and cutting, though the choice is obviously driven by the name of the KDE UI framework. Similar to Material Design, this provides a single unifying principle which does need to be explained further.

One way that this principle relates to the HIG is that applications should feel like they are crafted from a single piece of paper. In the actual guidelines of the HIG, you will likely define only 1 primary color. Another guideline could be that side panels should fold out like paper. One more guideline would be that the texture of surfaces should be matte, like paper.

So far, this is very similar to Material Design, which is not strange given that this unifying principle is very similar to that of Material Design. So in order to illustrate how this principle based on kirigami could differentiate itself, you may explain another way how it relates to the HIG. For example, applications should provide their minor elements as folded cut-outs (I'm thinking of things like this: https://i.pinimg.com/originals/0b/1f/ae/0b1fae8bdc4167bb18c4679390339d1e.jpg). In the guidelines, this might be expressed as the extent to which shadows must be used on elements. Or you can specify how elements relate to each other with regard to their depth relative to the base of the application.

I hope this example was easy enough to understand. I think a big benefit of this approach is that designers can get inspired by looking at existing kirigami art and techniques to see how they could be applied in an application's design. Aside from a consistent design, this may also provide innovative designs. I don't know if the actual guidelines I provided in the example are any good, from a design perspective. The example merely illustrates how the principle, as a unifying concept, relates to the more concrete guidelines. And that it's okay to further explain your principle, so it's clear how such a vague thing actually relates to the HIG.

ngraham added a project: VDG.EditedSep 7 2018, 2:03 AM

What it seems is that we have a coherent philosophy ("Simple by default, powerful when needed") but not a coherent style. In other words, we know how we want to do things, but we're less clear regarding the form with which we want to present them.

This makes sense to explain the disunity of visual styles we already have through our software stack: Plasma style, QWidgets app style, and Kirigami app style. Then we have System Settings which mixes all three!

@Arucard, regarding your "everything is paper" idea, it's an interesting concept worth exploring for sure--considering we already have a UI framework named after it that kind of implements some of those principles already. In particular I would appreciate the return of very light and subtle textures. Apple used to do something similar with various subtle textures and patterns all over the place, and I thought it was really classy before they went a bit overboard with it and purged everything in the Great Flat Backlash of 2013.

Speaking for myself here, I'm pretty tired of "flat everything". I feel like this design trend was a legitimate response to visually overwhelming skeumorphism, much in the same way that in a historical context, cold sharp modernism rejected and replaced the unnecessarily foofy ornamentation and sentimentality of classicism, romanticism, and beaux-arts architecture. We are part of a global aesthetic cycle here. In the wider world today, modernism is (IMHO appropriately) being rejected as too hard, barren, unemotional, and difficult to fall in love with. People are gradually returning to a measured dose of visually pleasing ornamentation; they like things that look clean and modern, but also rich and beautiful at the same time. In user interface terms, this would mean re-adding a little bit of depth, color, and visual flair to our generally very flat interface. I already see this with Kirigami apps for example in their use of animations, color, and depth (e.g. with pop-ups). Nothing gaudy or attention-getting, of course; rather, things would be subtly artistic and rich in the way that I feel was lost with the flat trend.

To use Breeze icons as a concrete example, I feel like the small symbolic line-art icons (particularly the action icons) are a bit too monochromatic and simplistic, and go overboard to be flat, while the large colored ones come pretty close to the mark for me with their bold colors and subtle use of gradients and shadows.

abetts added a comment.Sep 7 2018, 3:38 AM

Good style visions generally have very high-level concepts that, no matter what you create, still stay true to the overall vision. For example, if we said that KDE is creative, fun, and engaging, we could present those ideas to the public in so many different ways and iterations. It would allow us to evolve overtime and produce changes in the ui that will always feel at home. In the past, something that has helped KDE have that vision has been work done by different contributors and then merged together to form one big theme that inspires. In essence, we started backwards from what most designers will do. We present a UI, everyone likes it, we adopt it and then we realize that we didn't really have a strong direction or justification for it in the first place.

I think this discussion can help us start from a good beginning. Defining the vision and style we want. I quite like simple by default, powerful when needed. However, that motto feels a lot like an operational motto. It is the way we "do" things rather than the way things "are", a more "procedural" approach rather than a visual one. Hopefully this is not too abstract.

I would propose that we come up with a few words of visual style that can help us and then we can ask the rest of the community what they feel describe us best.

For example, I want KDE to be:

  1. Functional
  2. Expressive
  3. Vibrant

What would be your words?

Good idea, Andy. I like "functional" and "vibrant". But I'm not sure what "expressive" means in this context.

Off the top of my head, the words that come to mind are:

  • Functional
  • Solid
  • Sensible
  • Rich/Vibrant
  • Beautiful

Whatever visual design we come up with, I think it's important that it both is and looks like a visual evolution of what we currently have--which let us remember is pretty good! Users and developers alike are generally more conservative than designers and have a lower tolerance for total visual redesigns, even if it's amazing. So this effort should be about naming the status quo as much as defining the future.

However, that motto feels a lot like an operational motto. It is the way we "do" things rather than the way things "are", a more "procedural" approach rather than a visual one.

This was exactly why I didn't think this motto worked as design principle. Thanks for explaining it so clearly.

Regarding the "visual words" approach, I think this would be very similar to the Fluent Design approach. That means we should strongly limit the amount of words, I'd say no more than 3. You also need to explain how to interpret each word, otherwise it would still be too vague to work as a unifying concept. For example, "Functional" could be interpreted as creating a design that works well but also as creating a design that's sparse or minimalistic. This might be confusing as it could be seen to conflict with the "Rich/Vibrant" principle.

I do agree that a total visual redesign would be a bad idea. So perhaps we don't try to think of words or principles that would represent a good style for KDE in general. Instead we try to think of words or principles that capture the unifying factor in the current style. Of course, the current style isn't entirely unified but it would allow us to determine what underlying principles we like about the current style. And that should provide a base from which to start evolving the style.

I've said this before, I'm not very good at design. But here's my attempt at describing some underlying principles of the current style.

  • Subtle
    • Both the visual elements and the colors used should be very subtle. Visual elements should blend into the background so they don't draw the user's attention. Colors should be simple, not too flashy, with subtle highlights used for functional purposes (also not too flashy)
  • Adaptable
    • Given the flexibility offered by KDE software, the visual elements shouldn't rely too strongly on each other. It should be possible to remove or change some of them without ruining the overall style.

I'm not sure if these 2 cover enough of the style to be useful. But I think that just having 2 principles makes it easier to ensure that the principles themselves are consistent with one another. And more importantly, it should be quite easy to explain to users (though maybe my phrasing isn't that clear yet).

@Arucard, regarding your "everything is paper" idea, it's an interesting concept worth exploring for sure--considering we already have a UI framework named after it that kind of implements some of those principles already. In particular I would appreciate the return of very light and subtle textures. Apple used to do something similar with various subtle textures and patterns all over the place, and I thought it was really classy before they went a bit overboard with it and purged everything in the Great Flat Backlash of 2013.

As far as I know the original design of Breeze and Plasma was heavily inspired by paper ( and parchment for semi transparent surfaces). One could consider Kirigami as an evolution to the Breeze/Plasma concept, as in Plasma the paper could have different dimensions, could grow and shrink and with Kirigami the paper can additionally be cut, it can be split and join again, and it can fold.

  • Subtle
    • Both the visual elements and the colors used should be very subtle. Visual elements should blend into the background so they don't draw the user's attention. Colors should be simple, not too flashy, with subtle highlights used for functional purposes (also not too flashy)

I would not consider the Breeze color palette https://hig.kde.org/style/color/default.html very subtle, but rather strong and vibrant.

abetts added a comment.EditedSep 7 2018, 3:38 PM

The idea of paper was a thought, I think most people took it as an idea of surfaces and not necessarily as folding. Maybe with a better vision, we can explore that more.

@Arucard Let's chat some more about this on Telegram where our team is at (If you haven't been there yet) VDG Telegram

I would not consider the Breeze color palette https://hig.kde.org/style/color/default.html very subtle, but rather strong and vibrant.

Looking at the Breeze color palette, I think most of the colors are matte (which I think is a good thing). They aren't highly saturated colors, if that's the right term for it. But my reason for choosing "Subtle" as a design principle isn't just because the colors are somewhat matte. If you look at how they are applied, you usually see a single color (or very few main colors) which are decorated/highlighted with a few other colors. To me, this comes over as a very subtle use of color.

Of course, my choice for the design principle of "Subtle" isn't limited to the use of color. It also indicates that the design should stay out of the user's way. The user should only really notice the visual elements when they are needed. That doesn't mean that you make them invisible or hide them or anything like that. It just means that you can make them blend into the background.

A good example of both of these approaches is the system tray in Plasma. Tray icons are hidden in the additional menu when the user has no need to see them but they are shown in the taskbar section again when the icon needs the user's attention (e.g. the notifications icon). But other icons are always shown in the taskbar section because they are always considered to be needed by the user. However, if they require special attention the icon gets highlighted with a contrasting color. For example, the volume icon is always shown but when you mute the icon this is indicated with a red minus sign. This ensures that the icon grabs a little more attention than normal, which is needed because the user needs to know that the system's volume has been muted.

I really like these subtle approaches in the design. As a design principle, I think it advocates for using a light touch in any design and really just supporting the user in their workflows. But just to be clear, this shouldn't result in highly simplified user interfaces where you can only do what the designers expect you want to do. It should still be as flexible as always, which is also where the "Adaptable" design principle comes in to a certain extent. I can't really explain it well, but I hope I managed to at least clarify it a little bit.

@abetts I joined the room through IRC, I hope I can be of help.

Breeze colors themselves are vibrant, though their usage is subtle.

I wouldn't mind a bit more color in action and symbolic icons, but I think the generally subtle use of color in app views and layouts themselves is a good thing. I've mentioned before that I think we can leverage this into a very strong navigational aid by colorizing the control corresponding to the "obvious next action" to make it stand out and draw the user's attention to it. We are now doing this in Discover, and Kirigami has an API for it. But this is taking the conversation in a very micro direction, whereas my impression is that this task wants to focus on the macro. Maybe we should get back to the words idea.

I agree that we shouldn't focus too much on specific guidelines (the micro direction) but I do think it helps us understand how these principles could be applied to such guidelines. That in turn should help define the principles in a way that they can correctly be applied to new guidelines later on. Especially since we're essentially working with a bottom-up approach, trying to extract the principles from the currently applied style, I do think a bit of micro discussion is unavoidable. But it's definitely good to keep the conversation on track.

Maybe it's a bit too ambitious to start suggesting principles right away. As I understand them, these principles are inherently vague. So whatever principle we suggest right now, it will be possible to interpret them in a way that's different from our current style. I think that's what's happened with this "Subtle" case.

Perhaps a better approach is to just describe some of the design aspects of the current style that we think are good. From an aggregated list of such aspects, it may be easier to extrapolate what principles have been most relevant in this design. If I rephrase my earlier principles in this way, it would look something like this:

  • Making subtle use of highlights and visual cues
  • Allowing visual elements to be changed or replaced without ruining the overall style

I'm not sure if that second one is all that valid. So some people can disagree and maybe that one doesn't make it to the final list. I think this seems like an easier way to get to the design principles. Of course, if no one agrees, we can get back to suggesting principles as words.

Well the thing is that we have that already expressed in our HIGs, so we are basically going back in circles if we take this approach. I think we have evaluated what we have already. Now is the time to move forward. I can explain the design principles that I proposed a little better.

For example, VIBRANT

Vibrant is inviting, exciting, full of color but also full of features. I think this is one word that describes the desktop, but only to an extent currently. One thing, I feel, that happened with Breeze is that we brought our light grey color everywhere. So now, most of our applications look rather plain. They are very full-featured but not "vibrant" enough. So my suggestion for this principle is that designers will think of "vibrant" as a guideline that will prompt them to shift colors, use negative space in different ways and also make their applications "cool" or "impressive" to use.

With our engineering team always looking to make shortcuts to an activity, I feel that KDE has some very strong applications that do things no one else does. We try to simplify as much as we can and make our desktop vibrant with functionality that is powerful and solution-rich.

If you have a specific principle you feel strong about, share it, document your reasoning and let's keep going forward.

(I am not married to the 3 I proposed, it was just the first ones that I could think of when proposing this conversation)

VIBRANT

I like this word.

But in all things, there must be a marriage of liberal and conservative, novelty and traditionalism, the exciting and the stable. "Vibrant" is liberal/novel/exciting. It needs to be balanced with a word that's that's conservative, traditional, stable. A word like "solid" "functional" or "sensible" would balance it out.

Now that I think about it, I think we need an even number of words to make sure that we achieve this balance and don't wind up with a set of words that's biased towards one end of the personality spectrum.

VIBRANT

I like this word.

But in all things, there must be a marriage of liberal and conservative, novelty and traditionalism, the exciting and the stable. "Vibrant" is liberal/novel/exciting. It needs to be balanced with a word that's that's conservative, traditional, stable. A word like "solid" "functional" or "sensible" would balance it out.

Now that I think about it, I think we need an even number of words to make sure that we achieve this balance and don't wind up with a set of words that's biased towards one end of the personality spectrum.

I like this train of thought.

I would go with "SOLID" to balance it out.

I have actually entertained solid before. It evokes feelings of stability, rigid materials (graphically), reliable and steady. I think KDE, and Linux in general, are perceived as very stable pieces of software. Graphically, I imagine this as using UI elements that evoke good grounding, buttons that seem taken out of dense materials, etc.

ngraham added a comment.EditedSep 10 2018, 10:05 PM

"Solid" is one of the big reasons why I keep trying to do D14850: [effects] Turn off Translucency by default. Our software can't feel solid when it literally becomes transparent when you move a window. :)

Even with "Solid" as design principle, I wouldn't say that this translates to translucency being off by default. Moving a window is inherently a transient state, so it might feel strange if we try to make this stable or rigid (in UI/UX terms).

Returning to the topic of the design principles, I noticed this piece of text in the HIG (on the Style page):

The Style layer is concerned with emotion, tone, and visual vocabulary. Because it is the most visible and concrete aspect of an interface, it typically accounts for people’s first impression of a product.

I think this describes what the design principles are intended for. The design principles are an abstraction above style which determine what kind of impression the style should make on the user.

I think this is the problem I have with what we've come up with so far. It doesn't give me any idea of what kind of impression we want to make on the user. This is something I did get from the Material and Fluent Design principles. I think this is a subtle but important thing to get right since everything else follows from there.

Just for reference:

https://developer.android.com/design/
https://developer.apple.com/design/human-interface-guidelines/macos/overview/themes/
https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/
https://developer.apple.com/design/human-interface-guidelines/tvos/overview/themes/
https://developer.apple.com/design/human-interface-guidelines/watchos/overview/themes/

I am not sure that the stuff we are coming up with is really off what users expect. However, we can try to run a survey to ask. My feeling is that we will get very diverging ideas of what the the desktop is described as. Plus, the concepts we are discussing are very abstract and very design-oriented. I feel what we have to do is put in our most educated guess and put it to practice. Otherwise, we might be going in circles for a while and this conversation won't move forward. Gathering feedback in our space is a huge challenge, mostly because we don't have the infrastructure to ask users beyond our own community that is highly technical.

If anything, what we are doing here is not redesign the system, we are just aligning the design principles to what we have. We already have a foundation to build upon. Now we have to take that and define it in design principles that could help us.

fabianr added a comment.EditedSep 19 2018, 7:03 PM

Some observations and claims about the characteristics of surfaces in breeze:

Surfaces in breeze are inspired by paper and parchment

• Surfaces can be stacked (z-axis)
• Surfaces have varying x & y dimensions
• Surfaces have uniform thickness of 1px
• Surfaces can not pass trough each other
• Surfaces cast shadows and reflect light
• 3D world with light and shadows (of the 1px deep surfaces) 
• Surfaces are solid. User interaction cannot pass through them.
• Surfaces can fold, but don't bend or flip
• Surfaces can grow, shrink or change shape.
• Surfaces can change opacity.
• Surfaces can have 
    ◦ fixed size, 
    ◦ dynamic size within limits
    ◦ can be scrollable within there area
• Surfaces can contain all three types
• Surfaces can be semi-transparent or opaque. Semi-transparent surfaces are always blurred
• Surfaces can join and split
• Surfaces can move along x/y/z axis
• A 1px solid line is the default indicator for edges. Shadows, background color and opacity are secondary indicators.

Open questions to me

• Can surfaces flip? As in having more information on the back
• Are there different levels off opaque?
    ◦ Do they depend on the app hirachy like in Liquid Design acrylic?
ngraham added a comment.EditedSep 21 2018, 3:15 AM

Open questions to me

• What is the default indicator for edges? e.g. in material design it‘s shadows and secondary indicators is different background color and/or opacity. We often use lines.

We use shadows for window edges. I think we should use single-pixel lines to separate things. We're already doing this in Kirigami apps and Plasma, and I think we should move in the same direction for QWidgets apps too.

You mean single-pixel* lines right? Just to be clear.

Whoops! I do indeed. Edited the original to be accurate. :)

ndavis added a subscriber: ndavis.Sep 24 2018, 2:25 AM

"Solid" is one of the big reasons why I keep trying to do D14850: [effects] Turn off Translucency by default. Our software can't feel solid when it literally becomes transparent when you move a window. :)

In my opinion, "Solid" should have more to do with usability than visual aesthetics. We should be careful not to let the idea behind a theme get in the way of practicality. I think keeping an emphasis on practicality would do more to make Plasma and other KDE software feel "solid" than removing some transparency.

I updated my observations posting regarding the default indicator for edges.

Some observations and claims about color in breeze:

The breeze color theme has a fixed palette. Applications are not supposed to choose their own colors for branding or the like. Text and important elements, like icons, should meet legibility standards when appearing on colored backgrounds, across all screen and device types.

Facts

• Color (Plasma blue) indicates activation/focus.
• Color (hover blue) indicates interactivity – but only when hovered with pointer device.
• Bold colors should be used very sparsely, but are encouraged for icons and artwork. 
• Background color be used to communicate hierarchy