jploch

I think we need both. Clients usually ask what CMS the developer uses and more often then not visits the website. So the website should also help the developer to convince the client.

We are still targeting developers. But we are trying to be more accessible. Many of us where not trained developers when we started to use PW. And programming can feel intimidating. For example Diogo and I where designers and then became developers when we discovered PW. The great thing about PW is that it’s relatively easy for beginners to get started. Even with little coding experience. I think it’s not a bad idea to make PW approachable for more users.

Thank you for your feedback! And thanks to @ryan for the technical implementation. I am currently on vacation and am only now able to respond here. I understand that it takes some time to get used to change, especially when you are attached to something. And there will always be different evaluations and opinions about design. However, it is important to me to say that there are reasons for our design decisions and that they were not made arbitrarily. Due to time constraints, I will only be able to address a few points here. The overarching theme of the design is “friendly flexibility.” All design decisions were made to emphasize this theme and find a consistent visual language. With the new design, we want to appear less technical and also include user groups other than developers, such as designers, marketers, and editors/content creators. At the same time, we want to differentiate ourselves from other comparable CMS products and highlight PW's uniqueness. The morphing animations are intended to communicate the versatility and flexibility of PW and engage users. For example, we used many adjectives on the old site (flexible, stable, secure, open, free, powerful, etc.) and our idea was to communicate this directly in the first headline. The font (“Apfel Grotesk”) we used has many curves and a friendly character, which is especially noticeable when used in larger headlines. The colors used have been part of PW's branding from the beginning, so we thought it would be good to continue using them. By mixing these colors, we want to communicate versatility again and move away from the rather technical and dominant blue of the old site. We also greatly reduced the amount of text per scroll on the homepage, because we felt the old site was lacking visual hierarchy and felt to crowded. We have a much more guided flow on the homepage now that makes users actually read the text and it's easier to scan the content. We have also improved the visibility of features and modules and adjusted the navigation structure. I can provide more details on this when I have more time. I hope it adds some context to our decisions.

Thank you all for testing and providing feedback! The latest dev version has many bug fixes and improvements for the new theme. Check out Ryans post for more details. If you find any issues please post them here.

Just adding this here as note for me and others. There is also an alternative way to append custom markup to an inputfield: $inputfield->appendMarkup('<div class="test">Hello</div>');

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

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.

Thanks for your feedback for the new skin/theme. I would suggest we keep the feedback to this thread to make it easier for everyone to contribute and follow along:

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.

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.

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.

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

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

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