jploch

Quick Tree This module is great for productivity when editing many pages within the admin, as it gives you direct access to the page tree navigation without having to hover the tree icon first. Download from Github For non-superusers the page dropdown currently looks like this (if no bookmarks are defined): With this module it looks like this: For super-users or users with all permissions set it looks like this: These changes are achieved width a small js file that triggers the ajax tree navigation after the dom has been loaded. While I have tested it already a bit, I release this for now as a beta version. I hope others find it useful as well.

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?

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?

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

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

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

Since design is subjective you might not agree that the new theme is actually an improvement over the old one. So let me add some reasons for our design decisions (sorry this will be a longer post): The original theme had too much branding: The original theme added a lot of PW specific branding to the backend. The 3 main colors of the original theme add a lot of character and it wasn’t very subtle with it. Since the CMS is used to create websites/apps for clients wich have their own branding, there was a clash. I think this is also one of the reason why people went to such an extend to customize the look of the backend. Of cause you can argue that the look of the original theme was more unique, and I would agree with that. But as described above it’s not the primary functionality for the CMS to promote the PW brand (E.g. Exel is also not promoting Microsoft but rather keeps it look tied to the operation system). I also don’t think the backend needs to promote the client brand either (It won't be used by potential customers, so why push the client marketing here?). Rather it should be a neutral frame that works for any client/project out of the box without the need to customize it a lot (we still want to support customization as much as possible, as everyone uses PW differently, but the defaults should work out of the box). More in line with the new website/brand relaunch: Once we designed the new homepage, we felt that the original theme doesn’t fit with the promises and brand values we communicate on the new website. (E.g. PW stands out of the way, doesn’t force a look on your frontend/backend, simplicity for editors, modern UI, etc.) Improving contrast and accessibility: The original theme had some problems with accessibility. And while we are not solving all of it in the new theme (it would have been to much work for us), we at least improve some of it: Improved color contrasts: Higher contrast between font and background color (better in line WCAG guidelines) Improved text readability: The old theme used a font stack that relies on system fonts. E.g. users on windows saw a different font (Arial for the most part) than users on mac (Apple System Font). Depending on what fonts you installed you might also saw others. The new theme uses the Inter font for all users. Inter was designed specifically for screens and user interfaces. It has high contrast letter forms and a tall x-height to aid in readability of mixed-case and lower-case text. this might seem like a subtle change, but it actually makes a difference especially for smaller text and text in bold. (This is less about if you like the font and more a decision based on functionality). Improved keyboard accessibility: The new theme improves how the tab key can be used to navigate the backend. You can compare the original theme to ours to see this for yourself (eg. you can now navigate the tree with your keyboard). It’s still far from perfect and I think we can make an effort to improve in this area (there would need to be some changes in the markup, especially how the tab-navigation works). We also added a shortcut to open the search, which gives access to a lot of PW’s features, and we think it would be nice to transform the search into a command palette to access other shortcut actions for the CMS like creating fields/templates/pages in the future (think of it like Macs spotlight or Raycast). A more modern look and feel: I know this one is very subjective. We looked at other CMS options out there that seem to be somewhat similar to PW (e.g. Kirby, Craft, Statamic, Sulu, Datocms and others). And we could see a certain UI trend in their backends: They all use a mono color theme with subtle colors + a main color (a trend you find in a lot of UI’s now a days). To me that makes a lot of sense: It is easier to direct a user through an interface and apply hierarchy when not too many elements scream for attention. To me the way the colors where used on the original theme lacked a clear functional direction and instead where more of a decorative distraction for editors. This also seem to align with feedback we got from our clients (at Konkat we used the AdminThemeCanvas for most project since most clients seem to prefer it over the original theme). Fixed and more integrated nav-bar: I think most people here agreed that the fixed nav-bar is an improvement. Some said they prefer that the navigation is more separated from the rest of the design. We thought because the nav is now fixed it actually is already functionally separated from the rest of the UI (once you scrol), so there is less need for separation. Also users are expecting a navigation to be at the top of the page. If we put the nav in an unusual place (which would not be a good idea anyway), then it would make sense to make it more visible, but like it is now we don’t see the need for it. It would also break the concept of the mono color theme. Support for Dark mode: I already said it, I really don’t care much about a dark mode, but other people do and I think it’s a good feature to attract new users. One benefit of the mono color theme is that it’s easier to support a dark mode. But if dark mode creates too many problems for module developers I would consider removing that feature, but that needs to be discussed with Ryan and Diogo. @bernhard I will also discuss your other technical concerns regarding the CSS overwrites, as I think you made some good points. I will check with Diogo and Ryan and get back to you, I am confident that we can find a solution. If we (Konkat) had more time we would have liked to completely redesign the PW backend from the ground up (E.g. we had early concept with a sidebar instead of the top nav-bar, fixed save buttons and other things). But that would also have been a massive change for everyone, so we were going for a more subtle enhancement with the new theme instead. I hope this helps to get some insight on our decisions for the design of the new theme. We hope to improve it further over time so please keep up the feedback and bug reports.

@Mikel I agree with you. The website and the theme/CMS backend have indeed very different functions. To use an analogy: It’s like an advertisement for a car versus the actual dashboard inside the car. Both are designed for very different purposes. Here is how I would describe the differences in our specific case: The website is mainly a marketing and documentation tool. It’s the face of the brand online. It's what our audience sees, interacts with, and ultimately uses to form an opinion about the business/product (in this case the CMS is the product). The design should reflect the values of the brand and is primarily about attracting, informing, and persuading potential users. The design of the theme/CMS backend (the product) is mostly about usability, functionality, and creating a delightful and efficient experience inside the product. The product also needs to be convincing and coherent with the brand values und promises made on the website. While their primary functions differ, the marketing-focused design and the app interface design are not isolated: Marketing sets expectations for the app's interface: If your marketing promises a "sleek and intuitive" app, the app's actual interface must deliver on that promise. Discrepancy leads to disappointment and uninstalls. A great app interface becomes a marketing tool: If people enjoy working with PW it might lead to positive reviews, word-of-mouth recommendations, and higher retention – all good for marketing. Brand consistency is key across both: This doesn’t mean they need to look the same. But they should both reflect the brand values.

@ryangorley Thats a really nice website! I also like the 3D assets. I am not sure if/how 3D will fit with our current design approach. But I will keep it in mind and discuss with the others.

Hey folks, sorry for not responding earlier; I was swamped with work and then got sick afterward. Thanks for all the feedback so far! And thanks again, @ryan, for asking and trusting us to help with the redesign. The discussion seems a bit heated, but that only shows how passionate the community is about PW. I will leave it to @diogo (he is on vacation for a week) and @ryan to answer some of the technical concerns, as they are the ones doing the implementation. Just know that we are reading and discussing them and take them seriously. I want to add a bit of context to our general design approach and goals with the redesign of the theme and PW website. You might not agree with everything I am saying here, and that's fine. I don't claim to be right in all of it; this is just our current approach. We started out by asking questions to Ryan, reading the forum, and identifying problems with PW's current marketing and brand strategy. As well as doing research and comparing other CMS offerings to PW. here is what we found out: PW user numbers seem to be stagnating (not a lot of new users on the forum). PW's marketing mostly seems to speak to developers (= making clients, agencies, content creators, marketers, editors, and designers look for other options). Lately, more and more of our own clients had been choosing other CMS options over PW because they said it looks too "technical" or "dated" (they looked at the PW website). The design of the PW homepage is too "crowded" to identify the most compelling features of PW (= clients couldn't understand at a glance how PW can solve their problems). The PW website lacks recognition (basic UIKIT look) and doesn't look very approachable/friendly for newcomers. The way the admin backend is shown on the website is not very attractive, and the theme itself looks dated compared to other CMS solutions. The look of the website doesn't reflect most of PW's brand values (Flexible, Powerful, Simple, Easy, Friendly, Open, Secure, Stable, Free). And here are some of our goals with the new website and theme design: Attract new users to PW (developers are still the main target audience, but we want to target a more diverse group of users, see above). Make PW more approachable for new users. Keep existing users happy. Make the PW brand more recognizable. Better highlight PW's strengths and key features. Communicate PW's brand values through the design. Improve the docs. Make it easier to find modules. We realized that it would not be enough to just redesign the website, as the admin theme is the "main product." If people check out the new website and we can make them interested in PW, the second thing they do is install the CMS. So it's important to have good-looking defaults for the new theme that are coherent with the new website, as new users won't do a lot of customization. The reason we decided to include a dark mode in the admin theme is also mainly to appeal to new users. I personally don't care much about a dark mode, but for some it's a selling point. This trend can also be seen in other CMSs that now support it. I hope once the website is launched, it will be a bit more clear where we are going with this. Also be aware that we are not getting paid to do this, we did it because Ryan asked us and we love PW. But our time is limited and we have to make the most out of it. We will probably not achive all of these goals immediately, but we hope to set a good direction for things to come.

@joe_g Glad to hear it! I would like to feature the website on the showcase. If you are ok with it send me the URL as DM or post it here and I will add the site. THX!