adrian

@Robin S - I just did a little bit of testing between various online Flesch Kincaid Reading Ease calculators and the same text resulted in very different "reading ease" scores. Your module - 52.5 https://serpninja.io/tools/flesch-kincaid-calculator/ - 37.85 https://hemingwayapp.com/articles/readability/flesch-kincaid-readability-test - 50 https://goodcalculators.com/flesch-kincaid-calculator/ - 46.8 https://charactercalculator.com/flesch-reading-ease/ - 43.16 https://codebeautify.org/flesch-kincaid-grade-level-calculator - 31.9 https://app.readable.com/text/?demo - 50.4 ChatGTP - 47.2 ChatGPT also tells me that the reason for the differences I am seeing is due to the counting of syllables and sentence boundaries, etc so I guess the key thing is getting used to what your module returns and compare relatively with other field content on the site. One thing I didn't understand though is why the readable.com demo wasn't returning the same score as your module given that https://github.com/DaveChild/Text-Statistics?tab=readme-ov-file#useful-links links directly to it as a demo of it in action. But looking into it, I realized that when I was pasting the text into these calculators, it was just text and not the HTML that is part of RTE field content. So, I added $text = strip_tags($text) and now I get the same 50.4 that the demo on readable.com does. Do you think it makes sense to add that?

Thanks @Robin S - good point on the color coding. Thank you for the formatted content fix and a great implementation of the tooltip info. Much appreciated as always.

And/or maybe a hover tooltip that shows some more info about each particular score, eg if the Automated Readability Score is 5, then the tooltip would display: Age: 1-18 Grade Level: 5th If you want some help setting this up, I'd be happy to create some JSON that contained all this info for all the scores that your module could parse. Actually, ChatPT to the rescue. This prompt "Automated Readability Index JSON of scores to ages and grades" returns: { "0": { "grade": "Kindergarten", "ages": "5-6" }, "1": { "grade": "1st Grade", "ages": "6-7" }, "2": { "grade": "2nd Grade", "ages": "7-8" }, "3": { "grade": "3rd Grade", "ages": "8-9" }, "4": { "grade": "4th Grade", "ages": "9-10" }, "5": { "grade": "5th Grade", "ages": "10-11" }, "6": { "grade": "6th Grade", "ages": "11-12" }, "7": { "grade": "7th Grade", "ages": "12-13" }, "8": { "grade": "8th Grade", "ages": "13-14" }, "9": { "grade": "9th Grade (Freshman)", "ages": "14-15" }, "10": { "grade": "10th Grade (Sophomore)", "ages": "15-16" }, "11": { "grade": "11th Grade (Junior)", "ages": "16-17" }, "12": { "grade": "12th Grade (Senior)", "ages": "17-18" }, "13": { "grade": "College Freshman", "ages": "18-19" }, "14": { "grade": "College Sophomore", "ages": "19-20" }, "15": { "grade": "College Junior", "ages": "20-21" }, "16": { "grade": "College Senior", "ages": "21-22" }, "17": { "grade": "Graduate Level", "ages": "22+" }, "18": { "grade": "Graduate Level", "ages": "22+" }, "19": { "grade": "Professional Level", "ages": "22+" }, "20": { "grade": "Professional Level", "ages": "22+" } } So it should be easy to do the same for all the other indices.

Hey @Robin S - this is really useful, thank you as always. A couple of thoughts. Would you mind passing the text through Hanna first. I have a lot of tags in some content and readability is very poor unless I add this to your module. $hanna = $this->wire('modules')->get('TextFormatterHannaCode'); $text = $hanna->render($text); What do you think about adding some easy way to identify if each of the scores is good or not - at the moment you have to look up the docs, but perhaps color coding the values (red, orange, green) or some other way would help to alert us to issues. Thanks again!

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

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. Can you confirm if that setting is also supposed to do the same thing and if so, can we have an option for all? Or maybe I should just use some CSS for this.

@ryan - did you see my comments about top and bottom margins between fields when on PageEdit? Is that setting supposed to make it look like the ProcessModule interface?

@ryan - what do you think about adding the scrollbar (like the menu dropdowns now have) to the Page List > Add New button - I have enough of these that they extend well beyond the viewport.

It's dropdowns on submit buttons, the Add New button (page tree) and the top menu. What actually happens here (and maybe it is expected, but seems weird to me) is that if I want to override: --main-background for the page background at the root level, this automatically sets the --menu-item-backgroud-hover to the same color because of the reference to it. This means I need to re-set --menu-item-backgroud-hover again which works, but I think these references might might be part of the confusion we'll all be having and it's not initially obvious that changing one will impact the other so you might break things without realizing it. So maybe all that is needed is not referencing one var with the value of another? Sometimes it works, but often it doesn't. If I do that though, I can avoid that lower level override of --main-background and just go with the following - in this case I am playing with the menu hovers matching the main color, but you can also easily just reset it to the: #eee which I still might go back to. :root { --text-color: #444; --muted-color: #999; --button-radius: 10px; --main-background: #FFF; --menu-item-backgroud-hover: var(--main-color); } .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } h1, .uk-h1 { font-size: 1.6rem; } Sorry, it's only impact repeater matrix fields from what I can see.

PS - please don't forget about repeater buttons:

Thanks @ryan One thing I have been playing around with is setting the background to white everywhere (not just the page tree) - not sure if I want it or not yet, but tried: .ProcessPageList, .ProcessPageEdit, .ProcessModule, .ProcessUser, .ProcessPageLister, .ProcessPageListerPro { --main-background: #FFF; } but the problem does come back to process modules - you would need to specify each process module separately. So I tried: .AdminThemeUikit { --main-background: #FFF; } which does work, but maybe there are unintended side-effects I haven't noticed yet. I guess my point is that because --main-background is used for the body background as well as menu and dropdown button item hover background, we have to do this weird hack. I really do feel that these need separating.

Actually, in case anyone is interested, this is my current complete setup. I've given up on the colored top nav because it really doesn't add anything and in reality does look kinda ugly :) :root { --text-color: #444; --muted-color: #999; --button-radius: 10px; } .ProcessPageList { --main-background: #FFF; } .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } h1, .uk-h1 { font-size: 1.6rem; } This results in: @ryan - this still needs fixing though: But, otherwise pretty happy. Toggles and dark mode are disabled in config.php and we still have branding accents, no horrid grey background for the page tree (sorry KONKAT) and my eyes aren't bleeding from the #000 text 😁 Not sure if everything is perfect yet, and I'd rather not have to override CSS vars at non-root level, but it's time to move on and enjoy the fixed nav, scrolling fields and templates dropdowns although we still do need the dropdowns to have a higher z-index than the top-level menu so that Tracy panels can slot into place like they used to. @ryan - is that something you could look into please?

Thanks for all your thoughts there @ryan - really appreciate your input. The one thing I would say about the new grey background is that I think it looks OK when editing a page - I think the contrast between the background and the input fields is quite nice. What I really struggle with is the page tree and the action buttons white background on hover - that is probably my biggest issue with the new theme. Everything else works (except for some bugs that need ironing out), but that page tree view is just really ugly IMO and I know I am not the only one with concerns about it. One solution to this is: .ProcessPageList { --main-background: #FFF; } and of course to need to deal with the action hover, but in this case I like the buttons back so I have also added: .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } One other thought for now - I really like the margins between fields when editing module settings, eg: but when editing a page, there are no margins: I thought the setting below would change that, but it doesn't seem to have any impact that I can easily see - it least it certainly doesn't match the module editing layout: Is it another option somewhere else?

Really appreciate your input and problem solving here @ryan. I feel like there has been lots of discussion about whether we should need to override CSS at non-root levels and I tend to agree that we shouldn't have to, hence my suggestion for --submenu-xxx vars. Regarding the choice of green - it's the color of a company brand and it works fine for the menu background, but not great for links when there is a background behind (like that blue). I think perhaps the core issue here is how --main-color is used. It seems weird to me where it is and isn't used. Do you think it would make sense to have a separate css var for link color and link hover color? I think "main" is too generic and will always come down t personal preferences regarding where it should be used. And regarding --main-background I do feel pretty strongly about this being white, so that --menu-item-backgroud-hover is always going to be problematic for non-menu dropdowns (like from Add New and Save buttons) unless I go and do more overrides at non root levels. The problem with non-root level overrides is that it takes a lot more fiddling to get things right and they are subject to future changes to the PW admin classes, but if we had more variables for more things at the root level, we know they will always work - this is their beauty. The network response is: {"status":"ok","adminDarkMode":0} so it appears to be ok and no JS errors.

Another issue with --main-color looking weird because of those blue backgrounds that I think bernhard noted:

It also impacts save buttons - no hover color (because it's white). And, also note the weirdness with the main color on the button dropdown arrow only.

Hey @ryan - one side-effect from your example: setting --menu-item-backgroud-hover to a white like you have also sets it for the big Add New button on the page list screen, which means it doesn't show anything. This is one of the reasons I really believe we need separate CSS vars for the main nav vs other elements and also separate ones for the top level as well as the dropdowns, and perhaps even the next level down again (Pages > Tree etc), because the font size and padding on these is not easily adjustable (not critical though).

I tested using your example and that does work quite nicely - one of the key things I missed was the --masthead-input-xxxx vars which make a big difference. But as I have noted, the key thing I want is a dark back for the top level of the menu, but not for the dropdowns which is where things get particularly problematic. One thing I noticed while testing your example CSS is an issue with setting light vs dark mode from the user's profile settings. The first time I tried to set to light mode (instead of auto), the page list hover background went black - going to back to auto fixed it, but now it's stuck on dark mode and no matter what I do, I can't change it to light mode - even after clearing all cookies/sessions. As long as we are working towards no bugs in any situation, I am OK with it, but honestly I think it's a waste of effort. I know it's a personal thing, but I feel like the whole dark mode thing will fall out of favor once people realize it's not actually a better experience for user interfaces.

I honestly quite like much of how the new theme looks and appreciate lots of the decisions and work that has been put into it. It's the problems with tweaking it that are proving the killer for me - css vars should make it easier, but they way they currently are is making it harder. Please try to change the top menu to a darker background with white text you'll quickly notice that many side-effects aren't easy to fix. The problem is that if it doesn't work for some modules but the project developer really wants to use it (or their client does) but then later they discover a new module they want to use doesn't work well with it, then what to do?

@diogo - yes, you need to be able to trigger the nav dropdowns, but that's not an issue with the current theme because the main nav and dropdowns are set to different z-index values and it works great with Tracy panels set to 100.

@diogo - I mentioned this elsewhere, but that fixed header is proving problematic with Tracy because the effective z-index of the main nav is different to the dropdowns. The way things used to work I could set Tracy's panels to 100 and they would appear over the main nav, but the dropdowns would appear over the Tracy panels (which is the behavior we want). Do you know how that can be done with the new fixed nav? It seems I have to drop Tracy panels to less than 50 (maybe something higher but that works) for the dropdowns to appear over the Tracy panels, but I need 200 (maybe less, but 100 isn't enough) for the panels to be above the top nav. If they go below it's hard to grab their title and move them.

@diogo - that's a kind suggestion, but I don't honestly think that is the right route to take. I strongly believe that we all need to move to adopt your new theme to avoid issues with some users being on the old and some on the new. Despite all the assurances, I am still certain that the old theme will be problematic at some point with core functionality and/or some new modules. I think we just need some refactoring (to prevent the reported issues with the core and modules) and other bug fixes along with more distinct css vars so that any aspects of the new theme's color scheme can be modified easily and so that these css vars will work in the future should PW ditch UiKit at some point.

I agree with a lot of @bernhard's issues, but if I am understanding his suggestions about aligning CSS vars with UiKit's classes, then I don't agree with that suggestion. I think the CSS vars need to be agnostic in this regard (for when PW moves away from Uikit at some point). This is why I am wanting things like: --text-color --text-color-hidden --text-color-active --text-color-hover --top-menu-text-color --top-menu-background-color --top-menu-text-color-active --top-menu-background-color-active --top-menu-text-color-hover --top-menu-background-color-hover --dropdown-menu-text-color --dropdown-menu-background-color --dropdown-menu-text-color-active --dropdown-menu-background-color-active --dropdown-menu-text-color-hover --dropdown-menu-background-color-hover Same for button text, color, background, border-radius including hover state, etc. It's really not that many but will mean that we don't have situations like where --blocks-background is used for the text color of a button. I haven't put proper thought into these yet, but hopefully you get the idea. And, definitely no vars that reference other vars meaning that you can't override one without affecting the other. There are actually a lot of good articles online for css variable best practices - I know I need to read more about this.

On this note, I have already noted that this has affected Tracy and the z-index I need to set for its panels. How can I support it to work properly for the base UIKit and the new theme?

I really agree with @teppo here - setting css vars outside of the root context seems dangerous. I am not expecting an infinite number of css vars, just not reusing of ones that don't seem semantically correct, like my example of --masthead-active-color also being used for all submenu items and --muted-color being used for hidden pages along with page list actions. It honestly feels like --muted-color may as well be called --light-grey in the sense that it's describing a color, rather than a usage which defeats the flexibility of css vars. I'd be happy to compile a starting list of the vars that I think we need (and what they should be used for) and then have other passionate and skilled folks her chime in to help refine. I think with a little brainstorming we can end up with something really powerful and flexible and all defined at the root level.