New blog: Admin theme redesign

[bernhard]

I already got used to the new toggles. In some cases though they still feel wrong. Like in the example above.

Also note that the description clearly says "Check the box next to ..."

That means we'd also need to change descriptions across the admin. And we'd need to ask all the translators to update their language packs as well.

I think a better approach would be to let checkboxes be checkboxes unless they are whitelisted to be converted to toggles (eg by applying a class like "pw-toggles" to any parent dom element).

[jploch]

2 hours ago, bernhard said:

already got used to the new toggles. In some cases though they still feel wrong. Like in the example above.

Also note that the description clearly says "Check the box next to ..."

Good point about the description. I already talked to Ryan about the toggles. We will most likely go back to regular checkboxes as the default (most seem to prefer checkboxes here). 

[ryan]

Quote

I don't understand why such fundamental decisions are taken behind closed doors. Why you (Ryan and Konkat) didn't reach out to the community upfront. I even asked Ryan to connect once he announced that someone is working on a new theme. It didn't happen.

I worked as a designer for many years and learned you don’t get good results from the process you described, getting others involved upfront. There would be no point in having professional designer if it’s “design by community”. It’s important to me to get unhampered original creative thinking until the designer is happy with it. Following that, then it’s reaching out to the community, which is exactly what we are doing. 

I also did not see the the redesign until it was finished. I strongly believe in finding a designer you trust and then trusting them to do what they do best. Though I am thrilled with the result, it’s the first time I’ve used an admin design that felt like home to me in the same way that the original one does, and even improved upon it. But that’s the subjective aspect, we’ll all have different opinions.

Quote

Why has it been a mystery who is working on this?

So that they could work without interference until they were ready to share. But also I like to build anticipation and reasons for people to visit the website. 

Quote

Why not just create a module, like everybody else did in the past (AdminThemeBoss, AdminStyleChroma, etc.)?

Because the code of the module would be identical to AdminThemeUikit, and the new theme is still all Uikit. I want AdminThemeUikit to remain PW’s main admin theme, just with more options for the appearance of it; especially one that helps us attract new users. Were it a 3rd party thing for people to install then a separate module would still make sense. But for this case, it would just be unnecessary overhead.  

Quote

That early adopters can test, provide feedback and maybe think about some decisions before it is too late?

This is where we are. Both you and I are early adopters that are testing and providing feedback. 

Quote

Ryan has always been very careful about any new additions. 

I still am. This is why everything is optional and the Original theme option will always be there. The dev branch is historically stable, but it’s also always been the branch where new things are introduced and tested. 

Quote

why else would you develop everything secretly?

Nothing has been developed secretly, I’ve been writing about it every week since we started, and it’s been shared with everyone months before it will be on our main/master branch. I get the impression that you think we should micro-manage the designer, and that’s not an approach that I think is helpful. 

Quote

I'm just sad as it seems to be too late for many things that I would have considered to be more important.

It’s not too late for anything. You are welcome to share ideas and make suggestions, that’s what I was hoping people would do. But we need constructive ideas and suggestions, and saying “this theme is fundamentally wrong” is not helpful.

Quote

Adding overrides one by one as they pop up still does not feel good, sorry. 

Diogo added what you asked for, and then this was your response. It sounds like your modules use some Uikit features that traditionally aren’t used in PW’s admin, so that became apparent when your module was used in dark mode. Since we want thorough Uikit support regardless of mode, it makes sense to me that that we should find and correct issues to account for display issues as they pop up. But you are saying it doesn’t make you feel good. Maybe this will make you feel better:

I have added an option where you or your module(s) can disable dark mode entirely:

$config->AdminThemeUikit(‘noDarkMode’, true); 

I have added an option where you or your module(s) can disable toggle style checkboxes entirely, even if someone enabled it in the AdminThemeUikit module config:

$config->AdminThemeUikit(‘noTogcbx’, true); 

Though note that since it's been requested so much, toggle-style checkboxes are no longer a default.

These options above can be set globally or on a per request basis. For instance, if you want to limit the “no dark mode” option to just when your Process module runs, then you could set it from your Process module’s execute() method. If you wanted to disable it for all requests, you could set it from an autoload module’s ready() method or directly in your /site/config.php file.

Quote

Also note that the description clearly says "Check the box next to …”. That means we'd also need to change descriptions across the admin. And we'd need to ask all the translators to update their language packs as well.

Maybe it’s a language thing, but at least in English, and where I'm from, a checkbox is an option with a selected or non-selected state, that doesn’t behave like a radio. You could just as easily call a check-mark in a box a toggle, because that's also what it does, toggling something selected or not selected. A typical client is going to see checkbox and toggle as synonyms, that's my experience. If we used the term checkbox literally, then we’d be talking about paper and pens, and instead debating whether marking an “X” in the box counts as “selected” or if they have to draw a literal 2-line check mark. When we’re talking about checking on a computer, we’re talking about clicking something to select it (or deselect it). This is the style of checkboxes many of our phones use too. No need to change the description. That's my experience anyway, but I'm sure someone will reply to tell me I'm wrong because someone wrote a blog post. 🙂 

Quote

But I try to be more constructive with my feedback in the future.

Thank you. 

[jploch]

The term @ryan is referring to is called "Design by committee". 

Here is what Gemini says about it: "Design by committee" is a pejorative term used to describe a project, product, or design that has been created or approved by a large group of people (a committee), where all input is treated equally and decisions are made by consensus or compromise. The common saying, "A camel is a horse designed by committee," perfectly encapsulates the idea: the final product often lacks a clear, cohesive vision and can be over-complicated, ineffective, or even nonsensical, as it tries to incorporate every individual's idea and preference.

[ryangorley]

2 hours ago, jploch said:

The term @ryan is referring to is called "Design by committee". 

Here is what Gemini says about it: "Design by committee" is a pejorative term used to describe a project, product, or design that has been created or approved by a large group of people (a committee), where all input is treated equally and decisions are made by consensus or compromise. The common saying, "A camel is a horse designed by committee," perfectly encapsulates the idea: the final product often lacks a clear, cohesive vision and can be over-complicated, ineffective, or even nonsensical, as it tries to incorporate every individual's idea and preference.

Would you say @jploch that what you want are expressions of functional concerns (e.g. "I'm having a hard time knowing this is expandable", "The text is hard to read", etc.) instead of design preferences (e.g. "Make the buttons bigger", "Make all the text brown")? I suggested at one point that less contrast was easier on my eyes when reading a lot of text, but maybe that was too design-by-committee-like. What would helpful feedback look like?

[jploch]

We (Konkat) would not have taken on the task of redesigning if a larger group of people had been involved in the initial design process. And I'm sorry if anyone felt left out. We have limited time and capacity and this was the most productive way for us to work on the project. That said, we are now listening and are open to constructive feedback and bug reports. The theme is not set in stone, we are open to adjust things.

[jploch]

11 hours ago, ryangorley said:

Would you say @jploch that what you want are expressions of functional concerns (e.g. "I'm having a hard time knowing this is expandable", "The text is hard to read", etc.) instead of design preferences (e.g. "Make the buttons bigger", "Make all the text brown")? I suggested at one point that less contrast was easier on my eyes when reading a lot of text, but maybe that was too design-by-committee-like. What would helpful feedback look like?

Thanks for asking. Yes I think it would be helpful to have specific feedback that expresses functional concerns like this. But I think your feedback was in line with that.

About the concern that less contrast is easier on the eyes for text: I agree that harsh contrasts (eg. Black on White on screens) can be a strain on the eyes when reading long paragraphs of text, at least for me. But we usually don’t have a lot of text that is black on white. E.g. the field descriptions and notes are muted and text inside inputs, textareas (also tinyMCE) are on light grey. It’s also important that the contrast between the dark and the muted text is big enough to establish hierarchy, so I would not go to light with it. We also have dark mode now, which is supposed to be easier on the eyes, so if a editor writes/reads a lot of text they could switch. I would also be interested if there are any studies that show that this is actually a thing. I feel like mostly on the web we have the opposite problem that text contrast is too low for reading. E.g. on the original theme the contrast with the muted blue text was too low and was not in line with Web Content Accessibility Guidelines.

[Mikel]

Thank you for your response, @jploch. I really appreciate when a conversation is held at this level.

Regarding data on user preferences: We have such data because we regularly collect it during design processes for user interfaces through test series. These tests have shown us a clear pattern so far:

• decision-makers—i.e., those who pay for the project—are generally drawn to sleek, modern, and shiny interfaces;
• those who actually work with them (daily) prefer a bit more color in the interfaces because it allows them to orient themselves more quickly.

Of course, I agree that one can fine-tune the use of colors in the “Classic” style of the admin theme, but our clients – or rather, those who actually worked with it 😉 – have always been happy with the look and feel. By the way: in our view, a CMS is not meant to reflect corporate design any more than MS Word, InDesign, or any other software solution is. 

Since you want concrete feedback and suggestions, we are currently developing a small test tool with the most common UI elements that we use in the backends we manage to identify any potential issues. We usually provide our clients with 2–3 different admin themes that they can choose freely. (That is also where our data comes from.) Here is a first example (more to come) showing why we would like the option for a second color – on the left, the AdminTheme UIKit “classic” style; on the right, the new “default” style:

By the way, we really like the decision to have the open/close arrow point in the correct directions!

In closing, we would like to thank you again for the openness of the discussion and your willingness to engage! As a design agency, we unreservedly support your stance on “design by committee.” At the same time, we also understand developers like @bernhard, who have invested a lot of time in creating their modules and make their living from it, and who would have welcomed a discussion beforehand.

At frameless, we have been convinced by ProcessWire for many years and use it for every web related project we develop ourselves. We currently see an opportunity with this redesign to position the platform as effectively as possible in the changing market for the coming years. So, thank you for your thoughts and implementations!

[cb2004]

49 minutes ago, Mikel said:

In closing, we would like to thank you again for the openness of the discussion and your willingness to engage! As a design agency, we unreservedly support your stance on “design by committee.” At the same time, we also understand developers like @bernhard, who have invested a lot of time in creating their modules and make their living from it, and who would have welcomed a discussion beforehand.

Very well said. Although if you start inviting module developers into a conversation where does/should it stop. I agree with the way this was approached, and the dev branch has always been available for this sort of thing. Some of the criticism has come across as negative but I don't think it was meant to, it seems everybody wants the best from this especially KONKAT. 

[jploch]

1 hour ago, Mikel said:

Here is a first example (more to come) showing why we would like the option for a second color – on the left, the AdminTheme UIKit “classic” style; on the right, the new “default” style:

Thanks for the feedback. We have a color for Delete/Error/Danger, that should be used in this case. I would consider it a bug if that is not the case. Adding the class "uk-button-danger" should do it, but that doesn't seem to work. We will fix it, I think we need to carefully go through the UIKIT docs and cover all the color based classes they are using. It should look like this:

on a side note: To me the contrast of the secondary button of the original theme is way to low, I know that it is supposed to be muted, but it is barely readable. And the blue field title on light blue background is also to low in contrast.

[bernhard]

17 hours ago, ryan said:

It’s not too late for anything. You are welcome to share ideas and make suggestions, that’s what I was hoping people would do. But we need constructive ideas and suggestions, and saying “this theme is fundamentally wrong” is not helpful.

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful?

17 hours ago, ryan said:

Since we want thorough Uikit support regardless of mode, it makes sense to me that that we should find and correct issues to account for display issues as they pop up.

What I tried to point out is that when using UIkit like explained in their docs, then we would not have these issues at all. To change the primary color all you'd have to do is this:

@global-primary-background: red;

Then all primary buttons will use that color. All progressbars will use that color. All UIkit components will use that color. And any component that they might add in the future will use that color as well. Which means that any developer in the world can not only use what the core uses but anything UIkit has to offer. Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful.

We, on the other hand, are using thousands of overrides at the moment. Anything that Diogo didn't think of will possibly cause issues. Cause frustration or ugly fixes on our side and cause Github issues on your side and I think your time can be spent better.

Seeing reno green shine through tells me that the new theme must be extending (if you don't want to call it overriding) the reno theme and not the base theme, that I carefully split apart from the reno theme in 2021 to make exactly that possible: Properly extending the base theme without applying layer by layer of overrides. Exactly like you mentioned with PHP classes. What I see in the new theme does not match what I read in your announcements and explanations, sorry.

I consider that to be a very valuable feedback for anyone that is open to hearing it.

Unfortunately for many reasons I got the impression that it's too late for such input. And I understand that this is a difficult situation. That's why I apologised. It does indeed not help if anybody complains about fundamental issues if it's not possible to change them. I get that and as I said I'll try to be more constructive with that situation. But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost.

17 hours ago, ryan said:

Nothing has been developed secretly, I’ve been writing about it every week since we started, and it’s been shared with everyone months before it will be on our main/master branch. I get the impression that you think we should micro-manage the designer, and that’s not an approach that I think is helpful. 

Obviously I also do not think that micro-managing a professional designer would be helpful and that's not what I have been suggesting.

I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been.

It does of course not mean to ask the community to decide every button's color. But it might help to reduce the risk of having blind spots. It might make the process even more creative, not less. It might help in making the community feel heard, accepted and valued. And it might even help in saving development time by cutting on features that sounded/looked cool at first but raised serious concerns in the community.

And one more thing about the term "secret": You have some good evidence here. It was not my point though, and it might have been more constructive to ask me what made me feel like that than proving me wrong. I know I'm not the only one feeling like this.

17 hours ago, ryan said:

But you are saying it doesn’t make you feel good. Maybe this will make you feel better:

I have added an option where you or your module(s) can disable dark mode entirely:

$config->AdminThemeUikit(‘noDarkMode’, true); 

English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised.

17 hours ago, ryan said:

These options above can be set globally or on a per request basis. For instance, if you want to limit the “no dark mode” option to just when your Process module runs, then you could set it from your Process module’s execute() method. If you wanted to disable it for all requests, you could set it from an autoload module’s ready() method or directly in your /site/config.php file.

I'm not sure how a user will feel when using dark mode for everything and some pages suddenly appear in light mode, but at least this means that it's no longer a go/no-go decision when somebody wants to use one of my modules, so thank you for that. Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay?

---

@ryan please be reminded that I still very much admire what you have built and achieved. I'm sorry that you have expected a different feedback. But I hope it's ok to not only cheer if we like what we see but also raise our voice if we don't.

Thx and all the best

[Mikel]

I have to add that my example from above already uses a custom CSS for the buttons. Out of the box the example would look like this:

The Code:

<div style="display: flex; gap: 10px; margin-top: 15px;">
  <button class="uk-button uk-button-primary uk-border-rounded">Primary</button>
  <button class="uk-button uk-button-secondary uk-border-rounded">Secondary</button>
  <button class="uk-button uk-button-danger uk-border-rounded">Danger</button>
</div>

 

 

[jploch]

@bernhard We value your input very much and I think you are a blessing to the PW project. But currently I am focusing on covering the general design concerns. Since Diogo is out of office I would like you to give us some time for a proper response. But let me quickly address one of your main concerns. I agree that we should make an effort to keep the CSS layers as low as possible, at the same time I see a lot of benefits of CSS vars (also for module development, e.g. for PAGEGRID in my case, we can get into that later). Initially Diogo had the idea to base the new theme/skin on the stripped down version (without the reno-less files) you are using. I'm not sure what impact that had at the time or why we didn't do it. And maybe there's something I'm not considering at the moment, but to me it makes perfect sense to remove all Reno styling from our theme and use the base UIKIT as a foundation. 

[markus-th]

There is a lot of talk about “design by committee,” which I also think is wrong. 

But nobody asked for this, not even @bernhard. I have followed his posts very closely and all I can see is that he had hoped that the community would be consulted before the design phase. And I absolutely agree with him on this point, because if wishes and ideas had been solicited beforehand, I am quite sure that this thread would have been much less emotional.

Now to my “problems”

I currently manage nearly 50 active ProcessWire projects, and the advance announcements of a more modern admin theme naturally raised expectations that have now turned to disappointment for me, as many of my installations run on UIKit-based custom modules that are sure to cause problems with the CSS overrides. For me, this means that all development systems will soon need to be updated to the DEV version in order to identify and address any problems. 

I hope to find the time soon to contribute constructively to improving the theme.

[jploch]

35 minutes ago, bernhard said:

I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been.

We did a skin on top on an existing theme, it was never the plan to add a lot of new features. Thats why we did not ask for feature ideas. It's mainly a design release.

[bernhard]

19 hours ago, ryan said:

Quote

Why not just create a module, like everybody else did in the past (AdminThemeBoss, AdminStyleChroma, etc.)?

Because the code of the module would be identical to AdminThemeUikit, and the new theme is still all Uikit. I want AdminThemeUikit to remain PW’s main admin theme, just with more options for the appearance of it; especially one that helps us attract new users. Were it a 3rd party thing for people to install then a separate module would still make sense. But for this case, it would just be unnecessary overhead.  

I forgot to respond to this one and I'd consider it important. It sounds like you totally misunderstood my request. I'm very much for using AdminThemeUikit and I very much support all the mentioned goals. I was just questioning why it was not built in a way that followed what we pushed to the core in 2021. And probably released as a module first, and then, when early adopters had time to test and give feedback, was merged to the core and set as the new default.

I think this approach would have signalled the appropriate care and it would also have helped to identify which parts need to be part of the new theme and which parts need to be addressed in the base theme. If keeping and supporting all existing themes is a goal, then I think this approach would have best signalled this and would have had the best chance to make it happen.

Take this comment for example from my rock theme:

// @ryan
// early stage idea
// can we move those colors to the base theme (eg --pw-gray-200)?
// then all styles could inherit those colors
// and all module developers could rely on them.
// the problem now is that modules use their own colors
// often based on reno, which make the style break when
// someone uses AdminStyleRock or any other style/theme

You see that I even used css variables in this comment, so I'm definitely aware of their possibilities and benefits. But the more complex things get the more careful we have to be.

---

I can't understand what you mean by "code would be identical to AdminThemeUikit". Just have a look at AdminStyleHello if you did not already. I built it in 2022 to propose a clean way of how to extend the base uikit theme in ProcessWire. I don't see how that would be considered to be "identical to AdminThemeUikit"?

As it is not too late for anything may I ask if the current setup can be changed? Could the new theme be called "AdminStyleKonkat" and could it be built in a way that I proposed with AdminStyleHello in 2022 (or better 😄 )? I think this would help in reducing confusion about what is a theme and what is a skin and it would clearly show that all styles are just a skin on top of AdminThemeUikit and all are equally supported and the user can choose whatever he/she wants.

If AdminStyleKonkat was built in that way I'm not sure whether supporting AdminStyleRock made sense, as it tackled the same goals, but I think this does not matter. I think the current situation is confusing.

We have AdminThemeUikit and there we have two options. The "default" theme and the "original" theme. Then we have some themes and styles lying around somewhere in the modules directory. Like AdminThemeBoss (which is also a skin on top of AdminThemeUikit as far as I know and which seems to also tackle similar goals with having neutral colors and one primary color) or AdminStyleRock.

If a user wanted to use one of these modules he had to install it as a module and then he had to go to AdminThemeUikit to select "original" theme. If he didn't do that, the style might cause problems and the user would likely think that the style is broken and can not be used. This has already happened in only two weeks of having the new theme on the dev branch: https://github.com/processwire/processwire-issues/issues/2078

I think this setup is confusing and I think the process for users is currently confusing as well.

I could think of the new style being a module (AdminStyleKonkat) and any other style being the same. Being a module does not mean it can not be in the core. I don't understand that conclusion. We have many modules in the core, some of them being installed by default, some being ready to install with the click of a button.

AdminThemeUikit could, for example, then pick up all modules that are installed and follow the naming convention "AdminStyle..." and list them as an option to choose from:

 vs. 

[bernhard]

9 minutes ago, markus-th said:

But nobody asked for this, not even @bernhard. I have followed his posts very closely and all I can see is that he had hoped that the community would be consulted before the design phase. And I absolutely agree with him on this point, because if wishes and ideas had been solicited beforehand, I am quite sure that this thread would have been much less emotional.

Thank you.

20 minutes ago, jploch said:

@bernhard Let me start by this. We value your input very much and I think you are a blessing to the PW project. But currently I am focusing on covering the general design concerns. Since Diogo is out of office I would like you to give us some time for a proper response. But let me quickly address one of your main concerns. I agree that we should make an effort to keep the CSS layers as low as possible, at the same time I see a lot of benefits of CSS vars (also for module development, e.g. for PAGEGRID in my case, we can get into that later). Initially Diogo had the idea to base the new theme/skin on the stripped down version (without the reno-less files) you are using. I'm not sure what impact that had at the time or why we didn't do it. And maybe there's something I'm not considering at the moment, but to me it makes perfect sense to remove all Reno styling from our theme and use the base UIKIT as a foundation. 

Thank you.

[bernhard]

@jploch sorry for all the posts, but as you can tell I'm spending a lot of time in the PW backend, so I report things as they pop up. Take your time to evaluate them and to respond.

1 hour ago, bernhard said:

AdminThemeUikit could, for example, then pick up all modules that are installed and follow the naming convention "AdminStyle..." and list them as an option to choose from:

 vs. 

Expanding on this suggestion it confuses me a lot to see this part of the GUI inside of AdminThemeUikit:

I think it would make much more sense if these settings were defined on the settings page of AdminStyleKonkat, as it makes no sense to me to allow darkmode settings on AdminThemeUikit if I'm using AdminStyleRock which does not offer a darkmode.

@ryan I hope this is considered to be constructive feedback and I hope it helps you to understand why I got a very different impression of what this new "theme" is or should be.

[markus-th]

7 minutes ago, bernhard said:

I think it would make much more sense if these settings were defined on the settings page of AdminStyleKonkat, as it makes no sense to me to allow darkmode settings on AdminThemeUikit if I'm using AdminStyleRock which does not offer a darkmode.

@bernhard this Setting-Options only appears when you Choose "Default" not when you go to "Original".

1 hour ago, bernhard said:

AdminThemeUikit could, for example, then pick up all modules that are installed and follow the naming convention "AdminStyle..." and list them as an option to choose from:

 vs. 

I agree, the options to choose the favorite theme would be a good solution.

[bernhard]

2 hours ago, markus-th said:

@bernhard this Setting-Options only appears when you Choose "Default" not when you go to "Original".

Thx for adding that detail! Considering that Ryan mentioned the nature of the new style being like extending PHP classes, I wonder why settings of the default theme are part of the AdminThemeUikit module. Visible or not - technically they are built into AdminThemeUikit, which feels strange.

I'd expect AdminStyleKonkat to be a separate module and therefore all dedicated settings would be on the module config of AdminStyleKonkat. Again, this module could still be part of the core and it could still be turned on by default. At least for new installations - I still think it would be good to not change the style with the upgrade without asking.

Settings that apply to all styles on the other hand would be part of the module config of AdminThemeUikit. For example the CMD+K hotkey is independent of the style and thus would belong on the config screen of AdminThemeUikit, which would mean this feature can be used by any style.

I think this would be a very clear setup that clearly separates the responsibilities of the THEME and the STYLE and this would very well reflect what Ryan mentioned as strategy.

[bernhard]

Regarding the new scrollbars on the menu dropdowns. I think that's a great improvement! Is that part of the new style or is that considered to be part of the base style for all AdminThemeUikit styles? I think it would be great to have it in the base style!

[ryan]

Quote

I wonder why settings of the default theme are part of the AdminThemeUikit module. Visible or not - technically they are built into AdminThemeUikit, which feels strange.

They don’t have to be. It’s for my own reference and documentation, since I maintain the module PHP. I could delete the lines defining those settings and it would make no difference. If a 3rd party adds another theme in the same way, any of its custom settings defined in its config.php file will get stored alongside those of AdminThemeUikit in the same way. That’s why they are namespaced with the theme name, i.e. the prefix “default”. 

Quote

I still think it would be good to not change the style with the upgrade without asking.

I agree. The main/master branch will keep existing installations on the Original theme. But on the dev branch, I think we have more room and I didn’t think most would know about it unless they were in our small regular group of people that visit here. We want to encourage those on the dev branch to use and help test it. 

Quote

...it makes no sense to me to allow darkmode settings on AdminThemeUikit if I'm using AdminStyleRock which does not offer a darkmode.

If the original theme is selected, none of the other theme settings (like dark mode) appear. 

Quote

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful?

The feedback I’m referring to is “this theme is fundamentally wrong”. That’s a broad overarching negative statement referring to the entire theme and by extension those of us working on it, and I’m not sure how to read that as anything other than dismissive. To be taken seriously, I’d suggest wording like: “My opinion is that [some aspect] of the theme might work better if [it did something you suggest]”. That way you narrow down to specific things, and not the overall project and people. Anyway, I think you’ve already been following up with more specifics and GitHub reports, and that is useful feedback.

Quote

Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful.

Whether helpful or not, it is the true reason why some things may not be appearing the way you expect at this stage. When it comes to Uikit features that we have not used in ProcessWire, we would not have known to style them, and would not have provided custom styles for those. So if you don’t report them, we won’t know about them. I think it may have appeared that we accounted for them before because there was no dark theme to make them obvious, and the fallback Uikit styles weren’t too objectionable. I think it’s good the dark theme is pointing out the things that we hadn’t thought to give design consideration to before, because now we can. 

Quote

What I see in the new theme does not match what I read in your announcements and explanations, sorry.

Can you be more specific?

Quote

But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost.

I don’t think it’s too late for anything. But if your definition of “anything” is “everything” (i.e. “throw everything out and start over”) then that is not something I’d consider. 

Personally I love the new theme, it’s exactly what I think was needed, for new users at least. When it comes to the design and CSS behind it, I consider this more outside my expertise, so I aim to learn from it. I’m interested in the quality and usability of the result and not as concerned about how it achieves that result. Though I do like the technical aspect of the CSS variables, where I can customize so much without having to compile anything. I’m running my own custom version of the theme (with a custom CSS file) where I’ve been able to tweak things exactly as I like them with very little effort. 

Quote

I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process

That’s good, and if we were starting from scratch and building a new admin theme from the ground up, I think we might take a similar approach. But we are talking about a new skin of the existing admin theme with a focus on attracting new users. This is not about reinventing the wheel, it’s about making design improvements to what’s already there. This project is not about implementing everyone’s feature requests (though that is an ongoing and long-term goal). There is no budget and nobody is getting paid. It’s funded entirely on the generosity of KONKAT. They are donating their skills and time to benefit all of us, and the entire project, and to help ProcessWire grow, and I’m very thankful for that. They are a business, not a charity, so they have to work within their bandwidth and means. So it’s up to them to decide how best to work with the time they have.

Quote

English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised.

I don’t follow. Either you are confused, I am, or we both are. 

Quote

Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay?

Dark mode is experimental because it is something new we’ve not had to account for before. So there are likely more situations to uncover and fix in dark mode than light mode. But I also think it is here to stay. If there are people that don’t want it or have situations where it’s best not to have it, it’s completely optional and can be disabled site-wide or just for specific cases or modules. 

[adrian]

I honestly quite like much of how the new theme looks and appreciate lots of the decisions and work that has been put into it. It's the problems with tweaking it that are proving the killer for me - css vars should make it easier, but they way they currently are is making it harder.

1 hour ago, ryan said:

I’m running my own custom version of the theme (with a custom CSS file) where I’ve been able to tweak things exactly as I like them with very little effort. 

Please try to change the top menu to a darker background with white text you'll quickly notice that many side-effects aren't easy to fix.

1 hour ago, ryan said:

If there are people that don’t want it or have situations where it’s best not to have it, it’s completely optional and can be disabled site-wide or just for specific cases or modules. 

The problem is that if it doesn't work for some modules but the project developer really wants to use it (or their client does) but then later they discover a new module they want to use doesn't work well with it, then what to do?

[ryan]

Quote

Please try to change the top menu to a darker background with white text you'll quickly notice that many side-effects aren't easy to fix.

@adrian I tried this but didn't run into any side-effects, it seems to work really well. I based it off one of Diogo's examples. In this case, my main color is the "red" predefined option, but you could set the main color to be any darker color that you want, and the CSS rules below should still work. What side-effects were you running into?

:root {
    --masthead-background: var(--main-color);
    --masthead-active-color: white;
    --masthead-text-color: rgba(255,255,255,0.8);
    --masthead-border-color: var(--main-background);
    --masthead-logo-color: white;
    --masthead-input-background: var(--masthead-background);
    --masthead-input-color: var(--masthead-active-color);
    --masthead-input-border: var(--masthead-text-color);
    --menu-item-backgroud-hover: rgba(255,255,255,0.25); /* "background" without "n" required for the moment */
}
#pw-masthead .uk-navbar li a.hover { color: white }

[ryan]

Quote

The problem is that if it doesn't work for some modules but the project developer really wants to use it (or their client does) but then later they discover a new module they want to use doesn't work well with it, then what to do?

What are you suggesting with the question, that we should drop dark mode? But to answer your question, I would say the same thing you'd do in any issue situation, report the issue. But by the time this is on the main/master branch, I don't think there will be any remaining concerns about dark mode. In any case, we already have options for disabling dark mode in the module configuration, in your /site/config.php file, or dynamically at runtime, enabling you to disable dark mode entirely, or just in specific cases. It seems like we already have a lot of options for those that aren't keen on dark mode.