diogo

@markus-th In my view there's no reason to be confused, there's a disagreement on the strategy, that's all. Your position doesn't confuse me, I understand it perfectly, I just don't necessarily agree that it's the best path. Also notice that I carefully worded that sentence to convey that this is only one of the aspects that we discussed. It doesn't mean that it was the most important one and it doesn't mean we discarded other targets. We still think the site will convince developers to go deeper and discover PW. What we did, in that aspect, is not much different from what greatly successful tools aimed at developers are doing. From the top of my mind, see Next, Astro and Svelte

Thanks you for your opinions and suggestions, they are very welcome! We can always count on this community for engagement 👍 One aspect that we discussed, and that I don't think Ryan mentioned, is that Jan and I had several clients express concern about the tool after visiting the previous website. PW has some recognition among developers, but zero recognition among non technical potential clients, who we need to accept PW as our CMS suggestion. That's also one of the reasons of having "CMS" and not "CMS/CMF" front and center. Design decisions will never please everyone, we were aware of that and decided to go bold anyway. Hopefully it will prove to have been the right decision 🙂 That could be a fun animation to make 😆 Seriously, though, I think we discussed this at a certain point. Not sure why we dropped it, maybe because being headless in PW is a possibility and not a feature, while all the other things on the homepage are inherent to PW. The GraphQL plugin could certainly be on the modules area in the homepage, though.

@markus-th I had this on my list, but somehow didn't get to doing it. Yes, it should be an easy fix.

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.

This should be a fairly easy fix. Thanks for reporting it!

Thanks

@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?

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.

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.

Ah, almost forgot about the toggles vs checkboxes. Independently of what is decided concerning the usage of toggles, our css selector is clearly too aggressive and id trying to turn, into toggles, some checkboxes that should be left alone. We’ll need to fix that. Funny, just before submitting, i noticed this 😆

@adrian i maintain that we can tweak the variables for scenarios like yours. I don't see the default theme as highly customisable, and that's not the intention. For that we have Less. In my view, the default theme should be easily customisable, to a certain extent, for those who don't want many changes and also don't want to use Less. I'll be on vacation for a week, so I won't be able to discuss changes with Jan and Ryan in the next days. For now you can change the color of the menus with: .pw-dropdown-menu { --masthead-active-color: var(--masthead-text-color); } This changes the --masthead-active-color, but only inside the menus. For everything else, it remains how it is defined in the :root. The theme itself defines variables only in the root, exactly so that defining variables in other elements always overrides them without using !important.

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 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.

@ryan thanks for doing this work! For process modules, I want to point out that you can use variables like this color: var(--text-color, #000); This will use the light/dark color from the new theme, but default to black if the variable doesn't exist and, therefore, work on the current theme also. I tend not to agree with this. The submenus have a completely different feeling than the main menu, since they are boxed and stacked vertically and allow for a much stronger marking with the background. The size of the font is also smaller and denser, and it's readability would suffer more with a lighter color. Also, unlike the main menu, the links in the submenus are not even marked with the active class, since many of them don't even represent pages, but actions. There seems to be a strong reaction against the toggles, and some good arguments. Although I would argue that, comparing to the light switch situation (referred on a blog post linked in the other thread), our toggles on and off states are unequivocally clear because of the use of muted vs strong colors. @jploch and I really like how the toggles look like in the theme, but are not insensitive to the requests. We'll discuss possible solutions with @ryan. I personally made a point in keeping the number of css vars low. I'm totally open to tweaking them, and adding a couple more, but I will definitely not add a bunch more. The idea of these variables is to allow users very easily create a different feeling to the admin, by only changing a few colors. Having few variables and making them depend, by default, on other variables, allows you to completely change all the colors with defining only 5 or 6 variables. You are correct that changing the background also changes the button text, the reason is that, like this I know for sure, that whatever colors you chose, there will be contrast between the background of the button and the text even if you don't define the (--button-color) variable yourself. For a complete change and control of the admin theme (not only colors), I would say it's better to with the original theme or AdminStyleRock and LESS. Again, this doesn't mean that we can't tweak the variables to account for cases like in your example. There's no special reason why it's --muted-color and not --muted-text-color. In our opinion, the most important information on pages list is the the name of the the pages, and the most important action is to find the page you need to work on. The action buttons are always the same, and so, it's much easier for you to find the one you want to activate, then looking for the correct page on the list. Most of the time you will even be clicking "edit", which is the first one to the right of the page name. That's a very automated process. Also, in our case, "muted" does not mean unreadable. We want the hidden pages to be as easy to find as the non hidden pages, and easier to find than the action buttons. For us, using a softer color makes it softer to the eyes that a string of words appears from nowhere when you hover the pages in the list. Again, I'm willing to tweak the name of the variables to make them clearer, and even add a couple more variables to the list, but I wouldn't be happy to add a bunch of new variables and make the system more complex.

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 🏆

Hi all 👋 Just dropping in to thank everyone for your input and to acknowledge that I read through the thread. I don't have time to respond at the moment, but will do as soon as possible.