Leaderboard

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.

@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

I second that. While I completely appreciate all the work that has been put into the redesign, but I think the "brand spirit" is off. I feel like I've arrived at a typographer's portfolio site. To me, the new design conveys no message other than bold typography. All the messages are explicitly spelled out in writing, which is fine, but aside from that, we have plain, rounded boxes, practically no colors, no images and that is all there is to it.

I'm using a keyboard and can't access menu items. I can, for an example, tab to "The CMS", Enter (or Space) opens a menu, but how to go to (focus on) "Features"?

I'm glad to see that print stylesheets were not completely forgotten about, but testing may have been missed after a basic style was applied. 🙂 There are quite a few elements that simply don't need to be printed, and page margins are far too minimal for the default browser configurations of printing (there is overflow from the browser default configurations of headers and footers). At the very least, increasing the @page margin from 0.5cm would make a world of difference. Ironically, the first page's header spacing seems OK, but I haven't identified why. Thankfully it shouldn't require much fiddling to make a huge difference to the print styles! Things that could immediately be hidden in print media: #content-secondary #breadcrumbs (optionally; some may find this is useful in prints) #topnav footer #site-search-q The comment form is part of the body of the blog/news posts, but is unnecessary for printing. Comments themselves may be useful, but the style of them is a bit jarringly large. The "Post a comment" header and the related form aren't in their own section/div, so it can't be (easily) targeted as a whole. Overall body text size could probably be reduced for print (save on paper), but that's more preferential, as it also might just be easier to read at a larger size when printed - a JS text size adjustment would be the only way to allow the visitor to choose that, and I'm thinking that's unnecessary. The ProcessWire logo has what appears to be an underscore between the iconic P and the logotype/wordmark. This whole part of the API wouldn't need to be printed as its an interactive interface only. Windows 11 Pro 24H2, Firefox Developer Edition (v142.0b9)

Hey @Pete - if you want to try it out: https://github.com/adrianbj/TracyDebugger/tree/namespaced I am not ready to commit to the master branch yet because there were a lot of changes required and I have a feeling I still might have missed some things - most likely core PHP things like DirectoryIterator etc that need to be prepended by \ to get them called from the global namespace.

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.

@DV-JF It's already merged with main but will be noted in the next release with credit for your contribution. Thanks again!

@ryan any feedback on my related suggestion? https://processwire.com/talk/topic/31404-weekly-update-– 8-august-2025/?do=findComment&comment=249930 What I forgot to mention: For that to work and to make it secure we'd have two options: Add a secret token to the users module directory profile that anybody can use to send update info to the modules directory Use a push-pull concept. The user just triggers and endpoint on processwire.com (like processwire.com/update-module/?module-id=1234) and then PW calls a predefined endpoint to grab data from (eg baumrock.com/get-module-info/?pw-module-id=1234) This endpoint would have to be defined in the module's directory of the user so that anybody can use their own endpoint. I'd prefer (1) as this would be a one-time setup on your end and anybody can just copy and paste that token and add it to the request payload for the trigger, eg: { "token": "abcdefg", "module-id": "1234", "version": "1.2.3", "readme": "This is a calendar module for PW" } And I think (1) would even be easier to implement on your end as well 🙂

Can I humbly make an overarching statement on my thoughts about website design. I think there are certain types of sites that should have artsy, flashy, animated content and large fonts - these can make the right impression and be part of the visual experience. But when it comes to technology, I think clean, simple, and free of distractions is needed. Take a look at how clean https://www.contentful.com/ is and compare with https://www.sanity.io/ which is mess of moving stuff that I just want to gloss over. I also think you might have missed a key marketing point - "headless"

I find that the "number" input type is an enhancement for fields that are only to contain whole numbers. It lets you use the spinner arrows at the right of the input or your keyboard arrow keys to increment the number up and down, and it avoids invalid decimal or text values from being entered into the field. The PW admin uses number inputs for InputfieldInteger in some places but these are not used consistently and I regularly find myself trying and failing to increment values in an integer field that isn't using input type number. For example, in the "Rows" setting of a textarea field. With a simple hook in /site/ready.php you can ensure that all integer fields use input type number: $wire->addHookAfter('InputfieldInteger::renderReadyHook', function(HookEvent $event) { $event->return->type = 'number'; });