New blog: Admin theme redesign

[Mikel]

Thanks @jploch for your time, the thoughtful perspectives and the in-depth explanations behind the new theme direction.

I’d like to add that – regardless of trends like monochrome color palettes – there are universal usability best practices, especially when it comes to complex interfaces. Renowned usability experts like Jakob Nielsen have shown that color differentiation and clear visual hierarchies are crucial for orientation, error prevention, and efficiency. Relying on just one color (even with accent tones) can make it harder for the user to distinguish between navigation, controls, content areas, and information messages, particularly in a CMS as flexible and powerful as ProcessWire.

On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group?

I believe clarity in both design and communication about the intended audience will help keep PW competitive and attract the right users, whether they value flexibility and control, or are seeking quick, plug-and-play solutions.

Thanks again for all your efforts and the open dialogue – these conversations are what keep the community strong!

[jploch]

2 hours ago, JayGee said:

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? 

Thanks for pointing that out! I think we should also apply the new theme to the frontend editing UI. Will put it on the list..

[jploch]

5 hours ago, Mikel said:

I’d like to add that – regardless of trends like monochrome color palettes – there are universal usability best practices, especially when it comes to complex interfaces. Renowned usability experts like Jakob Nielsen have shown that color differentiation and clear visual hierarchies are crucial for orientation, error prevention, and efficiency. Relying on just one color (even with accent tones) can make it harder for the user to distinguish between navigation, controls, content areas, and information messages, particularly in a CMS as flexible and powerful as ProcessWire.

While truly "mono-color" in the strictest sense (only one hue, with only black, white, and gray variations) can be rare for an entire complex web app, many apps employ a highly restricted, minimalist color palette that leans heavily into a single primary color, often with neutrals (like what we do with the new theme). In our theme we have one primary color, but also other colors for alerts/warnings, for code, notes, etc. We also establish hierarchy and contrast through color shades (from light to dark), inverting color (dark on light becomes light on dark), form (E.g. round vs. not round), icons, typography (different sizes, bold/regular), spacing (to group items) etc. Using too many different colors can also have the opposite effect and cause a sensory overload (E.g. in a super market, where everything screams for attention, some of the more subtle designs can stand out more then another red box among the others). There are many successful examples of good working mono color UI’s (not in the strict sense, but mostly neutrals + primary color), from very complex systems like operating systems (eg. MacOs/iOs, Windows, Android), most desktop apps and a lot of popular web apps (E.g. Youtube, Google Docs, Gmail, Netflix, etc). 

5 hours ago, Mikel said:

On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group?

Thats a good and very important point. We where also discussing with Ryan how the CMS landscape changed and where we see PW fit in. It seems there is still a market for a CMS like PW. Take Kirby for example (they clearly took some inspiration from the PW API and they have a similar audience), it's thriving (at least here in Germany). I think that also shows how important marketing is, and that they are doing a good job with it.

[diogo]

Thank you for taking the time to write these insightful answers @jploch!

On vacation, and only with the mobile, is hard to keep up with the thread, i feel like I’m getting way behind and missing a lot of stuff.

I just want to respond to a  post from @bernhard that I had in mind, but couldn’t find to quote. It’s concerning the look of the UIkit buttons. If I took your request out of context, it was not intentionally, and probably because I didn’t understand your question. I just copied the examples from the UIkit documents, and pasted them directly inside a process module, and they got styled accordingly. Just like with the UIkit alerts previously, whose style I added to our CSS, I honestly thought that’s what you wanted.

 Please just let me know if I was way off in my understanding.

[diogo]

Ah, also, I’m happy to isolate the fixed menu and command palette css and js into modules that can be used with the original theme.

[matjazp]

Maybe this should be an option in the default theme?

[adrian]

1 hour ago, diogo said:

Ah, also, I’m happy to isolate the fixed menu and command palette css and js into modules that can be used with the original theme.

@diogo - that's a kind suggestion, but I don't honestly think that is the right route to take. I strongly believe that we all need to move to adopt your new theme to avoid issues with some users being on the old and some on the new. Despite all the assurances, I am still certain that the old theme will be problematic at some point with core functionality and/or some new modules. 

I think we just need some refactoring (to prevent the reported issues with the core and modules) and other bug fixes along with more distinct css vars so that any aspects of the new theme's color scheme can be modified easily and so that these css vars will work in the future should PW ditch UiKit at some point.

[ryangorley]

6 hours ago, Mikel said:

On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group?

3 hours ago, jploch said:

Thats a good and very important point. We where also discussing with Ryan how the CMS landscape changed and where we see PW fit in. It seems there is still a market for a CMS like PW. Take Kirby for example (they clearly took some inspiration from the PW API and they have a similar audience), it's thriving (at least here in Germany). I think that also shows how important marketing is, and that they are doing a good job with it.

I think it's important to acknowledge where ProcessWire is positioned relative to alternatives. As someone who is 67% designer and 33% developer, and an open-source enthusiast, I love ProcessWire. The API is intuitive and the documentation is excellent, making it easy to pick up and run with. I'm delighted by the attention to detail and the friendly community. Unlike Kirby, it's truly open source. I want to build every website with ProcessWire, but I don't.

I use ProcessWire when a client needs a multilingual CMS and has the budget for a custom front-end. For everything else, I reluctantly end up using WordPress with Bricks Builder and Simply Static for easier-to-build, secure sites that need a CMS, or Webstudio for easier-to-build, secure sites that don't need a CMS. If ProcessWire had a RESTful or GraphQL API that didn't require extensive work to implement, I could pair it with Webstudio and drop WordPress in many cases. But it doesn't. As much as I wish otherwise, I don't feel like I am an ideal ProcessWire user. Today, I think that user would be someone who meets most of these requirements:

• Someone who can build a site faster with code than with a visual builder
• Someone for whom multilingual support is necessary
• Someone who wants an open-source solution
• Someone who already knows PHP or wants to learn it (the "kids" are all learning JavaScript first)
• Someone with the power to choose something new or unknown (no one got fired for choosing WordPress)

A new website will help the project better reach those who fit this profile, and I'm excited about that. What we need to ask in all soberness, as well, is how many of these people exist today and will in the future. If this is not a growing audience, the product may need to evolve into something more people are seeking in the first place to restore the growth ProcessWire had in the past. 

One could do so by creating a first-class experience for those who could use ProcessWire alongside static site generators to attract a whole new audience where commercial options are prohibitively expensive and community options are limited or abandoned. Leaning into the best of a kindred JS framework like Astro could make ProcessWire a landing place for those coming from that very popular ecosystem or tempted to go there. Perhaps ProcessWire should depend upon third-party modules for some of this, but if that be the case, then let's make it easier for those creating them to commercialize their efforts or better surface those modules that are actively being maintained or at least known to be compatible with the latest release.

A new website is a huge step, and I'm excited to see it take shape. You all are so generous with your talents and have been a great blessing to me. So don't read this as some big complaint or demand. I just love the product and the community, and want ProcessWire to succeed. I hope this perspective leads to some thinking in other areas. Like I said, I just want to build every website with ProcessWire! 🙂

[adrian]

@diogo - I mentioned this elsewhere, but that fixed header is proving problematic with Tracy because the effective z-index of the main nav is different to the dropdowns. The way things used to work I could set Tracy's panels to 100 and they would appear over the main nav, but the dropdowns would appear over the Tracy panels (which is the behavior we want). Do you know how that can be done with the new fixed nav? It seems I have to drop Tracy panels to less than 50 (maybe something higher but that works) for the dropdowns to appear over the Tracy panels, but I need 200 (maybe less, but 100 isn't enough) for the panels to be above the top nav. If they go below it's hard to grab their title and move them.

[diogo]

@adrian hm, after your other message, i thought Tracy panels should be over everything, and dropped the z-index of the dropdowns and the nav to accommodate for that (i think 98 and 99, but not completely sure). But if you want the dropdowns to be over the panels, i would need to separate the numbers more. I can’t really imagine how that would work though, don’t you need the nav to trigger the dropdowns? Or am I seeing it wrong?

[adrian]

@diogo - yes, you need to be able to trigger the nav dropdowns, but that's not an issue with the current theme because the main nav and dropdowns are set to different z-index values and it works great with Tracy panels set to 100. 

[elabx]

On 5/30/2025 at 1:15 PM, bernhard said:

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 am a big UIkit user too so I might be biased but I kind of share this sentiment! 

Maybe something we could work out as a community it to have a clear pathway to handle UI in the admin, so in order of "theming relevance" (?) have something in the docs that explain this pathway:

• jQuery UI CSS
• UIKit Less compiling of its theme (eg. keeping the UIkit's flavor of dark mode to keep the rest of components that are not used in the core admin UIs)
• ProcessWire theme CSS variables

Aside from the visual nuances, I think having this part as organized as we can will benefit us all since all parts are useful in their own way!

Then again, thanks for all the work put into this! 

[cwsoft]

Used UIkit mainly for the PW backend as it is included by default. Never used it standalone or on frontend pages set. Seems this framework declines and isn‘t used that much in 2025.

https://w3techs.com/technologies/details/cs-uikit#:~:text=UIkit is used by 0.9,is 0.2% of all websites.

I choosed PW as I am 85% a developer, just 15% a „designer“ mainly due to it‘s great API. 

[Mikel]

15 hours ago, jploch said:

While truly "mono-color" in the strictest sense (only one hue, with only black, white, and gray variations) can be rare for an entire complex web app, many apps employ a highly restricted, minimalist color palette that leans heavily into a single primary color, often with neutrals (like what we do with the new theme). In our theme we have one primary color, but also other colors for alerts/warnings, for code, notes, etc. We also establish hierarchy and contrast through color shades (from light to dark), inverting color (dark on light becomes light on dark), form (E.g. round vs. not round), icons, typography (different sizes, bold/regular), spacing (to group items) etc. Using too many different colors can also have the opposite effect and cause a sensory overload (E.g. in a super market, where everything screams for attention, some of the more subtle designs can stand out more then another red box among the others). There are many successful examples of good working mono color UI’s (not in the strict sense, but mostly neutrals + primary color), from very complex systems like operating systems (eg. MacOs/iOs, Windows, Android), most desktop apps and a lot of popular web apps (E.g. Youtube, Google Docs, Gmail, Netflix, etc). 

I fully agree on your example of the supermarket, which is something I often mention myself when talking to clients. But nobody would claim that the “classic” ProcessWire theme is too colorful, would they? It is well coordinated and offers enough possibilities to make COLORFUL distinctions if you need them. Deciding between "green, red and yellow button" will always be more self explaining and less prone to errors as deciding between "left, middle and right button" 

Because you mentioned UIs from OSs, just a small example from the Apple Developer Docs:

Having three equally colored buttons at the top left corner would not be that practical, would it? 😉 As someone who has developed many interfaces, I can only say that our user tests have ALWAYS shown that more than one color is needed in addition to black, grey, white, which, as we know, are basically not colors 😉  

For us, the new default style of the UIKit Admin theme is currently not a viable option. We’ve decided to hold off until the final release, ideally with the ability to define a secondary color.

[Claus]

I have the TinyMCE editor text area in black text on white background despite having set dark mode. I see from the blog announcement that the screenshot there is correctly white text on black background in dark mode. Do I have to set a dark-mode specifically for TinyMCE somewhere? (Also I had to remove my old customised CKEditor so *perhaps* that has left some crud causing this… perhaps…)

[jploch]

On 6/4/2025 at 10:24 AM, Mikel said:

But nobody would claim that the “classic” ProcessWire theme is too colorful, would they?

Again this is highly subjective (you/we don't have any metrics to prove which theme works better for clients). But we had clients who said the admin looked dated and too colorful, compared to the CMS solutions they used before. Some years ago I worked at a design agency (Juno) and they decided to use Kirby over PW because they preferred the admin UI (they do a lot of custom web stuff for design sensitive clients). If the original theme worked so well, why was there such a demand for customization by the community (especially for customizing the colors). I think it’s because people realized that the colors were not the right fit for some of the clients/projects they worked on. I think a more neutral default theme that does not clash so much with the client branding is the right way to go. And as I explained before it's part of a bigger strategy to attract more users to PW. The new theme also improves on usability/accessibility when compared to the orginal theme.

On 6/4/2025 at 10:24 AM, Mikel said:

Because you mentioned UIs from OSs, just a small example from the Apple Developer Docs:

Maybe I wasn’t clear. My point was that most OS UI's use a mono color theme (mostly neutrals + primary color (for Mac it's blue) + colors for specific UI actions), like we do. The neutrals are mainly used to divide space (like we do it in the new theme). To adress your example: In the context of MacOs this is an important action so it makes sense to use these colors here and I think they improve usablity, in our context errors are important, and we mark them clearly in red. If your point is to implement more colors for specific UI elements/actions to improve usability, then I am totally open to discuss specific cases where you think it fits. My problem with the colors of the original theme is mainly how they are used, as I think they lack a clear function (as opposite to your example here) and add complexity to the theme. 

[jploch]

1 hour ago, Claus said:

I have the TinyMCE editor text area in black text on white background despite having set dark mode. I see from the blog announcement that the screenshot there is correctly white text on black background in dark mode. Do I have to set a dark-mode specifically for TinyMCE somewhere? (Also I had to remove my old customised CKEditor so *perhaps* that has left some crud causing this… perhaps…)

It should work out of the box, just by switching to dark mode. At least it does for me. Could it be that there is any custom CSS interfering? Can you inspect the element with chrome dev tools and see where the CSS comes from?

[Claus]

I can see an iframe and its CSS. Does this look familiar/correct?

[jploch]

19 minutes ago, Claus said:

I can see an iframe and its CSS. Does this look familiar/correct?

CSS looks good to me. Are you sure you use the latest dev branch?

[Claus]

I just tried to login using Chrome and Firefox and these works as expected. The issue is with Safari. I also tried to login using Safari in a Private session to avoid caching issues but got the same result. Safari again, urg.

[jploch]

Just now, Claus said:

I just tried to login using Chrome and Firefox and these works as expected. The issue is with Safari. I also tried to login using Safari in a Private session to avoid caching issues but got the same result. Safari again, urg.

I can't duplicate it here. It also works in Safari (Version 18.5) for me. What version of Safari are you using?

[Claus]

Here is another little issue. When you show the images then the `Description…` text is dark blue on the black background. When you place the cursor in the field the text turn white.

[Claus]

1 minute ago, jploch said:

I can't duplicate it here. It also works in Safari (Version 18.5) for me. What version of Safari are you using?

Newest version: Version 18.5 (20621.2.5.11.8)

[bernhard]

20 hours ago, diogo said:

I just want to respond to a  post from @bernhard that I had in mind, but couldn’t find to quote. It’s concerning the look of the UIkit buttons. If I took your request out of context, it was not intentionally, and probably because I didn’t understand your question. I just copied the examples from the UIkit documents, and pasted them directly inside a process module, and they got styled accordingly.

Thx and sorry for the confusion. It was probably not the best example.

20 hours ago, diogo said:

Just like with the UIkit alerts previously, whose style I added to our CSS, I honestly thought that’s what you wanted.

Thank you for adding those.

What I wanted... Not really. To be honest I just wanted to show why I think the approach you took with this theme is fundamentally wrong.

Admittedly, some of my posts lately have not been very constructive, and I apologise for that. The thing is: As you can tell I'm heavily invested in ProcessWire. 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.

Why has it been a mystery who is working on this? It's some awesome goals you are tackling. Why not tell that upfront? Why not ask for feedback, concerns or help? Why not just create a module, like everybody else did in the past (AdminThemeBoss, AdminStyleChroma, etc.)? That early adopters can test, provide feedback and maybe think about some decisions before it is too late?

I have been on the dev branch for years without any big issues that I can remember. I have always had a lot of trust in the dev branch. Ryan has always been very careful about any new additions. Very careful about not breaking any existing installations. Now that changed. Suddenly we had a new default theme. A theme, that turns checkboxes into toggles. That causes my modules to break, at least in dark mode. All of that enabled by default. And with all the context from the past I had the impression that there must not be much interest in feedback from the community - why else would you develop everything secretly?

I'm sorry if that was a misinterpretation as you seem to be open to feedback. I'm just sad as it seems to be too late now for many things.

Adding overrides one by one as they pop up still does not feel good, sorry. But I try to be more constructive with my feedback in the future.

[diogo]

2 hours ago, bernhard said:

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

Thanks