New blog: Admin theme redesign

[cst989]

Dang you quoted me before I had chance to made my post nicer 😝

[ryan]

Quote

 

maybe a few of us devs will get together and just maintain the UIKit theme if it will not be used for new features in the future by default. 

 

The Uikit theme will continue to be our default and primary theme. And AdminThemeUikit was upgraded with the ability to have themes (or sub-themes) within it. The new "Default" theme is such a sub-theme, a layer on top of AdminThemeUikit. When that layer is turned off, you are back to the "Original" output, without a theme layer on top of it. So AdminThemeUikit will continue to be developed as it is, with the Original look. And themes like the new "Default" will continue to style that output in a way that varies from the Original. But the Original is still the base/foundation of it. The intention is that others can also develop additional sub-themes on top of AdminThemeUikit, using modules. This theme-ability of AdminThemeUikit is not yet documented, but it will be. 

[monollonom]

@ryan I didn’t fully test the new admin yet but I have these few quick questions:

• Are the "reno" and "rock" styles going to be converted into themes to normalize things? This way it would clarify how to create a new theme if one takes a look at the AdminThemeUikit code.
• Expect for inputfields.js, is the "templates-admin" folder (or its content) still needed?

[ryan]

@monollonom Those are part of the admin.less system, and that will remain as-is. For custom theming with LESS, you'd keep AdminThemeUikit in "Original", so that there is no theme layer on top of it, other than your admin.less. 

Since admin themes are modules, the templates-admin dir is basically there as a last ditch fallback. It also serves as a place for any JS that is common to all admin themes, such as inputfields.js and main.js. 

[ryangorley]

3 hours ago, ryan said:

But design is always tough because it's so subjective

@ryan I would say that in most cases design seems subjective because the guiding objectives have not been well defined or communicated. Brand cohesion is a reasonable objective, and it sounds like we're going to eventually get some more visibility into that. Other objectives brought up here are worthy too. When/if @jploch @diogo have a minute, it may be helpful for us here or in a short blog post to learn how you all are prioritizing things. Design by committee doesn't work well, but if we have a rubric for providing feedback, we can provide forward momentum versus resistance. Just my $0.02.

[diogo]

Hey all! This won't be a complete response to everything that was raised in this thread yet. Just wanted to quickly drop some notes before they vanish my mind 🙂

I will start by the end though, since it was @ryangorley mention that brought me here. You're completely right about how a clear communication of objectives helps everyone to accept the inevitable subjectivity of design (yes, I believe that, even with very defined objectives, design is still highly subjective). @jploch and I planned to write a blog post detailing, not only our thought process, but also a detailed description of how to customize the new design. We didn't have the time or headspace to do it but, with Ryan, we decided to launch on the DEV branch anyway, so this discussion and bug finding could happen as soon as possible. I now believe that this blog post wouldn't have answered most of the questions that people are raising, so in hindsight I think launching early, even with it's shortcomings, was the right choice. I would also like to remind everyone that, as Ryan referred multiple times, this is not a new theme but a skin on top of the uikit theme (it's ok to call it a sidegrade, although we consider that some aspects of it are definitely upgrades).

Again, we accept and expect that not everyone will genuinely like the new theme more than the current one. Those people will have a natural resistance to this change, and there's not much we can do about it, either than respecting (the biggest sign of respect is that the current theme will stay in the core, with an easy switch). For others the resistance will stem from a feeling of "lost opportunity", in thinking that this will inevitably be the ProcessWire theme for the next multiple years. We discussed changes much more profound than these, but those would take time and would certainly not involve the community, if done in closed doors. So we decided to go with the more "superficial" and quick solution. The goal is for it to work in this moment, and to welcome new users who may come with the new site with something more coherent with what they'll find there. Those bigger changes, and others, can still happen as much as they could before.

To finish. Meanwhile I sent Ryan a few small corrections based on things pointed out throughout the whole thread. Hopefully they will make it soon enough to the DEV branch. Thank you all for testing, giving your opinions and finding these bugs 🏆

 

[AndZyk]

15 hours ago, ryan said:

Do you mean the headers of repeater items, or literally the inputs? I like using the main-color as the background color for AsmSelect items, PageAutocomplete items, and repeater headers, so that's part of my custom CSS. 

Hello @ryan,

I meant the headers of repeater items. For my taste they are to subtle in the new admin theme and should be styled more likes button, as they were before.

They contain most of the time the most content in my case and therefore should be styled more important.

Regards, Andreas

[MSP01]

23 hours ago, Nicolas said:

@MSP01 As stated by Ryan the original UIKit will still be available (though not as default). Regarding the color palette setting one that is pleasing to your eyes is as easy as tweaking some CSS variables in the admin.css file.

 

Thanks for pointing that out. I had read all the previous comments when this post was made, but had either forgotten or missed that the old theme will still be around!

I'd like to offer something more constructive about the new theme and how to improve it, but it's not easy to do. Differences are subtle and yet many at the same time, yet I cannot shake my initial negative experience, especially since it hasn't really changed after a week. If I have time and chance I'll try to offer some suggestions, though as someone mentioned, design by commitee is indeed not the way to go.

[Tiberium]

Quote

I meant the headers of repeater items. For my taste they are to subtle in the new admin theme and should be styled more likes button, as they were before.

They contain most of the time the most content in my case and therefore should be styled more important.

Funny how it is completely the opposite for me / my collogues. I thought the more "bulky" design of the native repeaters was too much. More like: "You can't see the forest for the trees" (German: "Vor lauter Bäume den Wald nicht sehen"). The reason why I prefer more the way of Berhards RockPageBuilder. Where the content elements not jumping in your face.

 

So the new design is here more align with our prefer in the agency i working.

[MSP01]

2 minutes ago, Tiberium said:

 

Funny how it is completely the opposite for me. I thought the more "bulky" design of the native repeaters was too much. More like: "You can't see the forest for the trees" (German: "Vor lauter Bäume den Wald nicht sehen"). The reason why I prefer more the way of Berhards RockPageBuilder. Where the content elements not jumping in your face.

Just to pipe in because the new look of the repeaters bothered me as well. I like both yours and @AndZyk suggestion better than what the new theme provides. There's something in it that makes the fields hard to look at for me.

[MrSnoozles]

12 hours ago, diogo said:

We discussed changes much more profound than these, but those would take time and would certainly not involve the community, if done in closed doors. So we decided to go with the more "superficial" and quick solution. The goal is for it to work in this moment, and to welcome new users who may come with the new site with something more coherent with what they'll find there. Those bigger changes, and others, can still happen as much as they could before.

@diogoDo you have anything planned for these bigger changes already? I have a vision in my head how the ProcessWire backend could look more modern and at the same time be faster to use and cover more use cases, especially when ProcessWire is used for applications rather than websites. If you're planning on working on more profound changes I'd love to discuss some ideas.

[ryan]

Quote

I meant the headers of repeater items. For my taste they are to subtle in the new admin theme and should be styled more likes button, as they were before.

@AndZyk Yes, my preferences mostly align with yours on this, so this is the sort of thing I've been experimenting with in my custom styles (repeater headers, asmSelect items, etc.).  Though for me it does kind of depend on quantity of items... sometimes I like the lighter touch, other times I prefer the darker (main color), so I'm still kind of hashing out where to settle. For Repeater items, since they open and then represent the toolbar for an entire item, I do think they might potentially benefit from having headers with a darker background, at least when open.

Quote

it is completely the opposite for me / my collogues. I thought the more "bulky" design of the native repeaters was too much.

What quantity of repeater items do you typically deal with? What do you think about the idea I mentioned above where closed repeater items are light, and open ones (or maybe even hovered ones) have a darker header that uses the main-color (and light text)?

[elabx]

5 hours ago, MSP01 said:

There's something in it that makes the fields hard to look at for me.

I think the lack of contrast between the the background of the repeater and the current background makes the whole repeater group like a blob of text, diminishing the effect of the vertical spacing of the items. I'd also vote for having a stronger contrast, maybe if not the main color, the same "inverted" color scheme. I'd also argue that completely turning the background white could help! 

Although this new color scheme got me thinking I would love nested repeaters to have a lower contrast version haha, with CSS variables it's now super easy to make ti work, no CSS overrides! Exciting times!

[bernhard]

Hey @ryan

I'm preparing to add some new features to RockCalendar (looking at you @FireWire 😉 ), so I thought it's a good opportunity to see how it works with the new theme!

 

As you can see, the light mode looks a lot better and the dark mode totally loses the day headlines (Sun, Mon, ...)

On 5/12/2025 at 4:07 PM, ryan said:

Since PW has not had a dark mode before, I'm sure there will be modules that aren't ready for it, including some of my own too. But hopefully there won't be a lot of such cases, and most should be easy to resolve. 

Could you please share some information how we as module developers can make our modules work with the new style? It might sound easy for you or the style authors or any CSS ninja out there, but it might not be easy for backend-focused devs. In this specific case I'm wondering:

• How can I make the headlines show up properly in dark mode? Which color would I set? Which css variable would I use?
• How can I make buttons like "today" and "left / right" at the top right look like all other buttons (like publish, for example)?

Regarding the buttons I'm quite confused for a long time and it might be the right time to mention it now: Many buttons use "ui-button" as class. As far as I understand this was the class coming from jQueryUI and with the old style this was giving it some rounded corners (compared to default uikit buttons). Then UIkit was added to the mix and from that time on I thought we can use "uk-button uk-button-primary" to style our buttons. At least to get matching colours. That meant that anybody using admin.less to customise their backend and changing the primary color saw a button in the primary color.

Now we have another layer on top. A style using CSS variables, overriding UIkit, which overrides jQueryUI. This might be wrong - I don't yet understand how all of them play together and which layer overrides another, but I think you get my point and I'm happy to be corrected or get an explanation of how these layers are supposed to work together.

May I also ask for some help or explanation how we can deal with that to provide good and reliable modules? What classes shall we use for which elements of the UI? This also brings me back to this question I raised earlier regarding all the UIkit UI components:

On 5/12/2025 at 4:07 PM, ryan said:

Quote

Regular UIkit <div class='uk-alert'> are not styled properly (they use the default uikit blueish), which is even worse in dark mode:

Most likely it's something that PW doesn't use, so it isn't styled, but I'm sure it can be. I think we do use uk-alert boxes, but always of a type like "primary" or "warning" or "danger", etc. So maybe we just need to add a style for alerts that aren't of a specific type. 

To be honest I'm very confused about your statement, so it would be great to get some more details here.

I understand that jQueryUI has been used for several aspects of the admin (like the drag&drop etc). And I understand why UIkit was added to the mix in 2017.

What I do not understand is how UIkit is supposed to be used by us developers now. Using ProcessWire as the CMS of choice does not only mean to use the backend and all its features as is, it also means (for me and I guess many others) to build something on top of it. This does often not only involve the frontend (where we have full freedom), but also the backend. It might involve adding some details here and there via hooks, it might involve building custom inputfields or it might involve building custom process modules (aka custom admin pages).

I always thought that having UIkit as a common ground is something that I/we can rely on. At least as long as the UIkit theme would be supported. That meant to me, that I can build anything for my clients (both direct clients or clients using my modules) that is based on any of the UIkit components listed on their docs (eg https://getuikit.com/docs/accordion). Now your statement makes me wonder whether that is still the case. It sounds a bit like that some components are simply not supposed to be used, which would be unfortunate and less than ideal, in my opinion.

I'm a bit confused and afraid how I would ideally build a module (or upgrade any of my existing ones, which are a lot...) to make them work well with the new style, the old default style and maybe also the rock style, if anybody prefers it over the others. As you stated several times anybody is free to choose whatever admin style he/she wants. But that means in return for me as a module developer that I have to support all these options.

When using UIkit, there are some proven standards that the company Yootheme defined. We have "uk-button-primary" for primary buttons. We have "uk-text-lead" for slightly bigger leading text. We have "uk-text-muted" for subtile grey text for explanations and such. We have tooltips to add additional information on hover, etc.

All this is documented well on their docs. So it is obvious for anybody how to use it.

It is not obvious to me any more in how to use anything related to UIkit when I have to expect that at least one of my clients/users might possibly be using the new style and might possibly be using dark mode 😞 

For example I just added this hook to ready.php:

wire()->addHookBefore('Inputfield::render', function ($event) {
  $inputfield = $event->object;
  if ($inputfield->name != 'title') return;
  $inputfield->description = '<div class="uk-text-lead">This is a test</div>';
  $inputfield->entityEncodeText = false;
});

Which renders fine in light mode:

But does break on dark mode 😞 

I wonder what the idea is to solve such issues? Are we supposed to NOT add any standard-UIkit markup to any of our backends that is not part of the PW core admin theme and that is not supported by the new style? Or are we supposed to add custom css overrides for such cases to our modules? Or are we supposed to report such issues whenever we find them and then wait for you or the authors of the new style to add support for it? Or do you think the the new style could be improved to support default UIkit markup without breaking?

What would be the correct way to add a slightly more prominent intro text to my title field that works properly across all new and old (uikit based) styles?

Thx in advance - it got a bit long, sorry! But this change basically effects years of my work...

[bernhard]

Another checkbox issue, here on my calendar module:

Also the space on top of the tabs inside the modal is far too big. But I think that has been reported already.

And on darkmode we see another example of how problematic using default uikit markup got with this update. I'm using "uk-background-muted" for the "enter time" and "enter range" elements. These visual helpers get lost on dark mode:

[bernhard]

Ok... the list goes on

Light is OK...

Dark is basically a nightmare:

That also means that any of my RockGrid customers (or RockCommerce, which also uses it) will not be able to use those modules with dark mode 😮 

@ryan I'm "a bit" concerned... I agree that the new style looks nice. But at what cost? 😞 I'm not sure whether they have been properly considered this time, sorry.

To be honest I think the decision to offer a dark mode in that way was a mistake. Or does anybody have some good ideas or answers? Am I missing any obvious solutions?

[ryan]

@bernhard Dark mode in particular is experimental, so I definitely wouldn't expect everything to work perfectly at this stage. Plenty of my stuff doesn't display perfectly either. It would be good to start a GitHub issue report to keep a list of things like Uikit classes not yet accounted for in the styles. In light mode, we didn't necessarily have to account for everything since it would fallback to Uikit's defaults, so dark mode is a good pointer to finding such things. If Uikit supports something then we want to also. It would be best to open a GitHub issue report for it rather than here. Perhaps it can be one of those ongoing ones that we keep open for awhile until everything is covered. As far as targeting dark or light mode with a CSS selector, prefix your CSS selector with ".dark-theme" or ".light-theme". I've only had one instance where I needed to do that, as I've been able to cover most other light/dark things with the CSS variables, but it's good to know about nevertheless. 

[diogo]

17 hours ago, bernhard said:

Could you please share some information how we as module developers can make our modules work with the new style? It might sound easy for you or the style authors or any CSS ninja out there, but it might not be easy for backend-focused devs. In this specific case I'm wondering:

• How can I make the headlines show up properly in dark mode? Which color would I set? Which css variable would I use?
• How can I make buttons like "today" and "left / right" at the top right look like all other buttons (like publish, for example)?

Regarding the buttons I'm quite confused for a long time and it might be the right time to mention it now: Many buttons use "ui-button" as class. As far as I understand this was the class coming from jQueryUI and with the old style this was giving it some rounded corners (compared to default uikit buttons). Then UIkit was added to the mix and from that time on I thought we can use "uk-button uk-button-primary" to style our buttons. At least to get matching colours. That meant that anybody using admin.less to customise their backend and changing the primary color saw a button in the primary color.

In your specific case, you would style the headlines with

color: var(--text-color, #000);

This will use the text color of the light or dark theme, and default to black, if the variable is not present.

For the "today" and "left / right" buttons you can use

background-color: var(--button-background);
color: var(--button-color);

// and for the hover state

background-color: --button-hover-background
color: --button-hover-color

 

Adding

<button class="uk-button uk-button-default">normal button</button>
<button class="uk-button uk-button-primary">primary button</button>

styles the buttons correctly for me

 

17 hours ago, bernhard said:

Now we have another layer on top. A style using CSS variables, overriding UIkit, which overrides jQueryUI. This might be wrong - I don't yet understand how all of them play together and which layer overrides another, but I think you get my point and I'm happy to be corrected or get an explanation of how these layers are supposed to work together.

May I also ask for some help or explanation how we can deal with that to provide good and reliable modules? What classes shall we use for which elements of the UI?

It's true that this is a skin on top of Uikit, and we inherit the decisions of Uikit to style every single element individually instead of inheriting colors. This means that you can use Uikit elements, but that their colors will aggressively try to override ours. This works well in most part for light themes, but, in your case it is breaking on the dark theme. There are two things we can do simultaneously to mitigate the problem:

1. switch to a dark uikit base for the dark theme.
2. override the uikit color with our variables for at least their most important components.

For now, the most reliable way to style markup that you add to the admin, is to do what I described before for your calendar.

[jploch]

Hey folks, sorry for not responding earlier; I was swamped with work and then got sick afterward.

Thanks for all the feedback so far! And thanks again, @ryan, for asking and trusting us to help with the redesign. The discussion seems a bit heated, but that only shows how passionate the community is about PW. I will leave it to @diogo (he is on vacation for a week) and @ryan to answer some of the technical concerns, as they are the ones doing the implementation. Just know that we are reading and discussing them and take them seriously.

I want to add a bit of context to our general design approach and goals with the redesign of the theme and PW website. You might not agree with everything I am saying here, and that's fine. I don't claim to be right in all of it; this is just our current approach.

We started out by asking questions to Ryan, reading the forum, and identifying problems with PW's current marketing and brand strategy. As well as doing research and comparing other CMS offerings to PW. here is what we found out:

• PW user numbers seem to be stagnating (not a lot of new users on the forum).
• PW's marketing mostly seems to speak to developers (= making clients, agencies, content creators, marketers, editors, and designers look for other options).
• Lately, more and more of our own clients had been choosing other CMS options over PW because they said it looks too "technical" or "dated" (they looked at the PW website).
• The design of the PW homepage is too "crowded" to identify the most compelling features of PW (= clients couldn't understand at a glance how PW can solve their problems).
• The PW website lacks recognition (basic UIKIT look) and doesn't look very approachable/friendly for newcomers.
• The way the admin backend is shown on the website is not very attractive, and the theme itself looks dated compared to other CMS solutions.
• The look of the website doesn't reflect most of PW's brand values (Flexible, Powerful, Simple, Easy, Friendly, Open, Secure, Stable, Free).

And here are some of our goals with the new website and theme design:

• Attract new users to PW (developers are still the main target audience, but we want to target a more diverse group of users, see above).
• Make PW more approachable for new users.
• Keep existing users happy.
• Make the PW brand more recognizable.
• Better highlight PW's strengths and key features.
• Communicate PW's brand values through the design.
• Improve the docs.
• Make it easier to find modules.

We realized that it would not be enough to just redesign the website, as the admin theme is the "main product." If people check out the new website and we can make them interested in PW, the second thing they do is install the CMS. So it's important to have good-looking defaults for the new theme that are coherent with the new website, as new users won't do a lot of customization.

The reason we decided to include a dark mode in the admin theme is also mainly to appeal to new users. I personally don't care much about a dark mode, but for some it's a selling point. This trend can also be seen in other CMSs that now support it.

I hope once the website is launched, it will be a bit more clear where we are going with this. Also be aware that we are not getting paid to do this, we did it because Ryan asked us and we love PW. But our time is limited and we have to make the most out of it. We will probably not achive all of these goals immediately, but we hope to set a good direction for things to come.

[ryangorley]

@jploch Thank you for this background, and these are awesome goals. Thank you as well for doing this on your own time. If you want to take a look around at the Thunderbird website we worked on a few months ago and see if any comparable 3D assets would be of value for the PW site, let me know. I don't know if it's compatible with the aesthetic, but I'd be happy to contribute the hours to create those for the cause.

[jploch]

@ryangorley Thats a really nice website! I also like the 3D assets. I am not sure if/how 3D will fit with our current design approach. But I will keep it in mind and discuss with the others.

[Mikel]

Thanks for the details @jploch about the goals and considerations that preceded the design process. Some things become clearer because of that, while others still interest me, as I can’t fully comprehend them yet.

Let’s perhaps first establish that although both a website and a CMS are interfaces, the latter must follow a different set of visual rules. The approach of trying to unify both visually is understandable in the context you described, but it results in a dysfunctional design language for a CMS. A not ideal interface is either too loud or too quiet – like the new theme. What’s missing is clear differentiation between various element groups (navigation, controls, content, info, to name a few).

I‘ve been working in the design field for nearly 30 years and am aware of many trends, fashions, and viewpoints. I’m by no means looking to argue about matters of taste – instead, I’m interested in the underlying design philosophy that guided the development of the new admin style.

That said, once again, many thanks for all the work that went into this project!

[jploch]

@Mikel I agree with you. The website and the theme/CMS backend have indeed very different functions. To use an analogy: It’s like an advertisement for a car versus the actual dashboard inside the car. Both are designed for very different purposes.

Here is how I would describe the differences in our specific case:

• The website is mainly a marketing and documentation tool. It’s the face of the brand online. It's what our audience sees, interacts with, and ultimately uses to form an opinion about the business/product (in this case the CMS is the product). The design should reflect the values of the brand and is primarily about attracting, informing, and persuading potential users.
• The design of the theme/CMS backend (the product) is mostly about usability, functionality, and creating a delightful and efficient experience inside the product. The product also needs to be convincing and coherent with the brand values und promises made on the website.

While their primary functions differ, the marketing-focused design and the app interface design are not isolated:

• Marketing sets expectations for the app's interface: If your marketing promises a "sleek and intuitive" app, the app's actual interface must deliver on that promise. Discrepancy leads to disappointment and uninstalls.
• A great app interface becomes a marketing tool: If people enjoy working with PW it might lead to positive reviews, word-of-mouth recommendations, and higher retention – all good for marketing.
• Brand consistency is key across both: This doesn’t mean they need to look the same. But they should both reflect the brand values.

[jploch]

Since design is subjective you might not agree that the new theme is actually an improvement over the old one.

So let me add some reasons for our design decisions (sorry this will be a longer post):

• The original theme had too much branding: The original theme added a lot of PW specific branding to the backend. The 3 main colors of the original theme add a lot of character and it wasn’t very subtle with it. Since the CMS is used to create websites/apps for clients wich have their own branding, there was a clash. I think this is also one of the reason why people went to such an extend to customize the look of the backend. Of cause you can argue that the look of the original theme was more unique, and I would agree with that. But as described above it’s not the primary functionality for the CMS to promote the PW brand (E.g. Exel is also not promoting Microsoft but rather keeps it look tied to the operation system). I also don’t think the backend needs to promote the client brand either (It won't be used by potential customers, so why push the client marketing here?). Rather it should be a neutral frame that works for any client/project out of the box without the need to customize it a lot (we still want to support customization as much as possible, as everyone uses PW differently, but the defaults should work out of the box).
• More in line with the new website/brand relaunch: Once we designed the new homepage, we felt that the original theme doesn’t fit with the promises and brand values we communicate on the new website. (E.g. PW stands out of the way, doesn’t  force a look on your frontend/backend, simplicity for editors, modern UI, etc.)
• Improving contrast and accessibility: The original theme had some problems with accessibility. And while we are not solving all of it in the new theme (it would have been to much work for us), we at least improve some of it:
  • Improved color contrasts: Higher contrast between font and background color (better in line WCAG guidelines)
  • Improved text readability: The old theme used a font stack that relies on system fonts. E.g. users on windows saw a different font (Arial for the most part) than users on mac (Apple System Font). Depending on what fonts you installed you might also saw others. The new theme uses the Inter font for all users. Inter was designed specifically for screens and user interfaces. It has high contrast letter forms and a tall x-height to aid in readability of mixed-case and lower-case text. this might seem like a subtle change, but it actually makes a difference especially for smaller text and text in bold. (This is less about if you like the font and more a decision based on functionality).
  • Improved keyboard accessibility: The new theme improves how the tab key can be used to navigate the backend. You can compare the original theme to ours to see this for yourself (eg. you can now navigate the tree with your keyboard). It’s still far from perfect and I think we can make an effort to improve in this area (there would need to be some changes in the markup, especially how the tab-navigation works). We also added a shortcut to open the search, which gives access to a lot of PW’s features, and we think it would be nice to transform the search into a command palette to access other shortcut actions for the CMS like creating fields/templates/pages in the future (think of it like Macs spotlight or Raycast).
• A more modern look and feel: I know this one is very subjective. We looked at other CMS options out there that seem to be somewhat similar to PW (e.g. Kirby, Craft, Statamic, Sulu, Datocms and others). And we could see a certain UI trend in their backends: They all use a mono color theme with subtle colors + a main color (a trend you find in a lot of UI’s now a days). To me that makes a lot of sense: It is easier to direct a user through an interface and apply hierarchy when not too many elements scream for attention. To me the way the colors where used on the original theme lacked a clear functional direction and instead where more of a decorative distraction for editors. This also seem to align with feedback we got from our clients (at Konkat we used the AdminThemeCanvas for most project since most clients seem to prefer it over the original theme). 
• Fixed and more integrated nav-bar: I think most people here agreed that the fixed nav-bar is an improvement. Some said they prefer that the navigation is more separated from the rest of the design. We thought because the nav is now fixed it actually is already functionally separated from the rest of the UI (once you scrol), so there is less need for separation. Also users are expecting a navigation to be at the top of the page. If we put the nav in an unusual place (which would not be a good idea anyway), then it would make sense to make it more visible, but like it is now we don’t see the need for it. It would also break the concept of the mono color theme.
• Support for Dark mode: I already said it, I really don’t care much about a dark mode, but other people do and I think it’s a good feature to attract new users. One benefit of the mono color theme is that it’s easier to support a dark mode. But if dark mode creates too many problems for module developers I would consider removing that feature, but that needs to be discussed with Ryan and Diogo. @bernhard I will also discuss your other technical concerns regarding the CSS overwrites, as I think you made some good points. I will check with Diogo and Ryan and get back to you, I am confident that we can find a solution.

If we (Konkat) had more time we would have liked to completely redesign the PW backend from the ground up (E.g. we had early concept with a sidebar instead of the top nav-bar, fixed save buttons and other things). But that would also have been a massive change for everyone, so we were going for a more subtle enhancement with the new theme instead. I hope this helps to get some insight on our decisions for the design of the new theme. We hope to improve it further over time so please keep up the feedback and bug reports.

[JayGee]

Hi @jploch,

Great work on the redesign so far. I don't think it has been asked yet, but just wondering if any of the design changes are being applied to the frontend editing UI or is any particular details being looked at on this?