New blog: Admin theme redesign

[adrian]

40 minutes ago, ryan said:

Ah okay, I see it now. Adding to our list of updates. 

Actually, on this note, why do RM fields use buttons, but repeater fields don't?

[ryan]

Quote

I've honestly never looked at that option - it seems like a lot of work though on a site with a lot of fields. As I mentioned in my post about this, I thought the "Input types that should be offset with additional top/bottom margin." via Modules > Core > AdminThemeUikit would be the place to set this, but it doesn't seem to do anything. Even if it did, it's still a decent amount of work to set all types. 

That's the way I use it at least. And it's not much work because it's something usually done while setting up a field, so it's just part of the field creation process. But if you are going back to add it onto lots of existing fields, then maybe that might seem more laborious, as it would be for any field setting, but you'd only have to do it once. In addition, it's not something you'd want to do for every field. I find it useful for certain fieldsets, repeaters, etc. It's kind of a case-by-case basis. 

I'd forgotten about that setting in AdminThemeUikit where you can select it by Fieldtype. It appears that does not work in the new theme, so I'll have to look into that. 

Quote

Actually, on this note, why do RM fields use buttons, but repeater fields don't?

Since adding a matrix field involves selecting a type, it's a different kind of input. But there shouldn't be a button on the matrix type at all, so it's most likely a new theme bug to figure out. 

[Mikel]

Wenn using the admin theme on touch devices (iOS) the visual aid of the highlighted background is missing. This is kind of irritating, especially when pages are hidden, because the page title does not get highlighted either.

  

[Mikel]

We just discovered something funny:

 

The design of the column width slider handle is from a galaxy far, far away, isn´t it? 😉

[elabx]

6 hours ago, Mikel said:

The design of the column width slider handle is from a galaxy far, far away, isn´t it? 😉

Skeumorphism is so back! Ask Airbnb crew! /j

[szabesz]

4 hours ago, elabx said:

Skeumorphism is so back!

Back or not, having only one lone icon/image among non-skeuomorph icons/images is, at the very least, questionable.

[BrendonKoz]

3 hours ago, szabesz said:

Back or not, having only one lone icon/image among non-skeuomorph icons/images is, at the very least, questionable.

It's a holdout from the original theme, it likely was overlooked in the new. Probably should be removed in the base theme (imho) realistically, though that's a matter of opinion. I'd imagine it would potentially be easier to style it if it were a browser-native control instead of a range slider that was created prior to browsers having native interfaces for it.

This CSS might clean it up a bit. The new theme could likely use some CSS variables in place of the colors below, I simply targeted the base CSS instead.

.ui-slider .ui-slider-handle {
  border-width:0;
  outline:none;
  border:none;
  width:17px;
  height:17px;
  background-color:transparent;
  background:currentColor 0 0 no-repeat;
  border-radius:21px;
  box-shadow: 0 2px 2px gray;
}

@ryan If we're using the admin.css override, and users are allowed to choose their admin theme, is there currently a way to target our overrides to the sub-themes/styles individually? I see the main theme name is appended to the body classes, but not the sub-theme name, and since we can only have one override file, currently... Is there a way to handle that scenario that I'm not seeing?

I'm also wondering if there might be opportunity for others to provide sub-themes to the AdminStyleUiKit, and if so, perhaps the naming of the options should be something other than "Original" and "Default"? Default is typically a word assigned to what would be chosen for someone, not a choice to be made. (I do understand the reasoning, though.) I'd be quite happy if Konkat chose a name for their theme/style, whether it just be Konkat, 2025, some iteration therein, or anything their hearts desire! If a body class were added for subthemes, it'd be weird seeing "Original" or "Default". 😉

- - -

Installed the DEV branch. The dark mode looks more like a high contrast mode to me. I'm not yet sure what suggestions I have for it, but compared to the light mode, it's quite jarring. (For what it's worth, I use dark mode by default in systems that offer it.) I'll try to think on that a bit more.

[Mikel]

From the start, I asked myself why I was somehow not completely satisfied with the display of the checkboxes as switches:

We actually use switches quite heavily in some of our webapps, so I looked at the examples and therefore suggest making the “inactive” status brighter. This makes it easier to recognize the status of the checkbox. Below is an example of iOS switches.

I also find it problematic when the theme color is red: To me, this makes the checkbox appear “false” even though it is “true”. Making the “unchecked” state lighter in color, also would help in this case. Below is an example of one of our web apps. There we chose to give both states a color: That makes it easy to understand the state of the toggle (checkbox).

[bernhard]

2 hours ago, Mikel said:

That makes it easy to understand the state of the toggle (checkbox).

As long as you are not color blind I guess 🙂 

[Pete]

Re. toggles I think the iOS way of doing toggles is the most understandable as lack of colour is "inactive" in this case and one colour for the "on" state - preferable not red, or if you do choose red as your primary theme colour at least a simple way to override that in CSS.

I've not really looked at the new theme yet but do primary action buttons still have a separate class to secondary? I was quite used to overriding a bunch of stuff on the current admin theme - probably more than was intended - via admin.less so I'll have to take a peek at some point.

[Mikel]

11 hours ago, bernhard said:

As long as you are not color blind I guess 🙂 

 😄 Yes, that would be not so nice. But we created the app (and the toggles) for a small user group with no color blind members and the mission was to visualize the states of many projects and subtasks at one glance. The green/red scheme achieved the best results in our test settings, so we went with that. 😉👍 But have a look for yourself: https://frameless.at/en/case-studies/real-estate-marketing/

[bernhard]

Using the new theme on mobile seems very hard to me at the moment. The menu button is not available and the page tree with all pagelist actions is... somewhat strange. pagelist actions are sometimes not visible at all, sometimes they appear when clicked, sometimes they don't.

[stehlo]

REMOVE

Edited June 20 by stehlo

[ryan]

@stehlo 

Quote

Releasing a grossly unfinished and cross-browser incompatible subproduct, completely neglecting minority browsers, as a default version is not the best idea. Ryan's original themes do not make this mistake.

We are beta testing this admin design on the dev branch, nothing has been released in an official version. If you feel strongly about the new design, you may prefer to stick with the main/master branch while we continue testing and optimizing the new design. I have no idea what you are talking about with regard to being unfinished or cross-browser incompatible, so if you are running into specific issues it would help if you open a GitHub issue report where you can elaborate on what it is you are observing as being unfinished or cross-browser incompatible. 

Quote

Running after numbers whilst going against the current user base – that is a trap, which many have fallen into.

I've mentioned this a few times before, but we are not replacing the Original theme, we are adding another styling option for it. If you prefer the original, you should keep using it. Understand that not everyone has the same preferences here. I prefer the new design, it sounds like you prefer the original. We are not taking anything away from the current user base. Providing more options to appeal to a broader audience is not a trap. 

Quote

Using the new theme on mobile seems very hard to me at the moment. The menu button is not available and the page tree with all pagelist actions is... somewhat strange. pagelist actions are sometimes not visible at all, sometimes they appear when clicked, sometimes they don't.

@bernhard I can't fully duplicate what you've described, using current Chrome on Android 15 (Pixel). Can you provide more details on what device you are using? I am seeing the larger margins between some pages though, it appears for any longer page titles that wrap when the page actions appear, so I can duplicate that part at least. But everything still works as expected, menus, etc., so need more detail on the parts that aren't working there. 

[diogo]

11 hours ago, stehlo said:

@jploch @diogo @ryan

Running after numbers whilst going against the current user base – that is a trap, which many have fallen into.

Masses are not making sane decisions; therefore, sacrificing the unique quality aspects of a niche product by trying to appeal to "others" or "all" tends to lead to "neither" and "none."

Releasing a grossly unfinished and cross-browser incompatible subproduct, completely neglecting minority browsers, as a default version is not the best idea. Ryan's original themes do not make this mistake.

Tagging three people on your post must mean you really wanted to be heard. Why such an unhelpful post, then?
If you want to vent your frustration, at least put a minimum effort on it.

[AndZyk]

 

Captured on iPhone 8 Safari (yes my phone is old)

The navigation has issues and the page tree could look more compact. 😉

Edited June 14 by AndZyk

[bernhard]

I'm using a regular UIkit modal...

Original theme:

With the default theme the modal is vertically centered, which causes a weird glitch when closing it:

As the UIkit docs mention there is a standardised way to center the modal: https://getuikit.com/docs/modal#center-modal. And as you can see there it will work properly if used properly. I don't know why the default modal is vertically centered with the new theme, but I know that adding these kind of visual "optimisations" causes problems.

Could you please stick to default UIkit markup and concepts as much as possible with your overrides to avoid these kind of issues? Thank you.

 

[gornycreative]

I am so very late to this party. I will not probably have a chance to dig deep into the dev default theme for some time. I like the functionality of adding a light/dark toggle.

Having had to deal with uikit less and pw less and other things... hmm there is still a little bit of technical debt from Reno that occasionally appears. I've had to put in a number of overrides to manage different aspects for different plugins - core and wire.

Not many have probably tried Chroma, but much of the complexity I felt necessary came from a lot of concerns I have read here - monochrome vs duotone, different text color globals. But Chroma is particularly opinionated - like dark mode, it's not for everyone.

I have found this gets more complex with uikit because they recognized the need to preserve contrast across dynamic elements or transparent elements where a variety of images can make text color choice a challenge. But their inverse mode doesn't really accommodate for a true dark mode either - so I needed to work out my own method for overriding their style choices to get a functional dark mode.

Color selection for most end-users is a nightmare to deal with. This was why I tried to implement very simple controls with opinionated math on the back to generate the palette necessary for uikit globals.

While functionality and directing intent is paramount in the new design, if users can't read text or lack element cues that allow them to intuitively interact with the application the costs to handle user requests outweigh the feature. I appreciate the A/B tests folks are using, and sometimes just a little guidance from end-users goes a long way. I don't like working in isolation as a developer away from test users or non-technical people, but that's just my preference.

As you work with color, remember you have a uikit kit style layer, then a pw style layer, and I guess there is now a dynamic css variable layer.

I'm not against that design choice, as it makes a number of toggles possible to bring into the dynamic - but this also shifts the weight around a bit when it comes to bringing definitions client-side.

When I get a chance to play with the mode and work it into Chroma, any overrides or variable splits I've had to build in terms of style will be available there.

Thanks @diogo and @jploch for engaging this process. I look forward to seeing where it goes.

[Mikel]

While making Screenshots for a support reply I noticed a little bug: The logged in user in the screenshots has a specific role that allows him to view existing DataTables of our module ProcessDataTables in the backend but nothing more. The user has logged in at the admin URL, what normally will not be the preferred way.  But anyway, with Reno it looks as expected:

With AdminUIKit it shows some minor visual bugs:

 

[zilli]

On 5/22/2025 at 12:04 PM, ryan said:

@zilli I don’t understand this statement, especially in the context of this conversation. Tight control is not a term I’ve had attributed to me before, in any area. If I think about where I would value control being tight, it would be with matters of security or avoiding scope creep. 

Hey @ryan. After some time off, I’m back, and I can already notice a lot of improvements to the admin theme. Great work!

I wanted to touch on the topic of the tight control you have over the project. I think I didn’t explain it clearly before, so let me try again. First off, I truly believe in your intentions and your commitment to ProcessWire — that’s never been in question. My perspective is just from someone looking at things with fresh eyes.

Since this project has been with you for over a decade, it’s totally natural that some aspects might go into autopilot or get a bit of tunnel vision. What I meant by "tight control" is that it feels like most things — or nearly everything — end up depending on you. A few things that stood out to me:

• You're the only one who can commit. That can give the impression that there's a lack of trust in the community. I get that quality matters, but even the most successful open-source projects had to open up at some point. There are many long-time users and proven professionals here who could help with small fixes and improvements — which would make things move faster and ease the burden on you.
• The master branch is still the default, even though folks on the forum have already pointed out that switching to the dev branch might help newcomers see the project as more active.
• The development of the new admin theme, while impressive, also felt like a missed opportunity to leverage community input earlier in the process.
• What exactly does “community” mean in this project? For many of us — like @bernhard and others — PW isn’t just a hobby, it’s the foundation of a businesses. That’s why transparency and shared involvement matter so much.
• And just as a practical thought — what would happen if, for some unforeseen reason, you were no longer able to maintain the project? Things like GitHub access, the website, and the forum are all critical. It might be worth thinking about a foundation or even just a small board to help guide the future of PW together.

That’s the kind of "tight control" I was referring to, and I hope this version makes more sense. Again, I really do appreciate everything you’ve built — and I say all this in the spirit of constructive feedback and shared care for the future of the project.

All the best!