A blogging chain is going around, that has folks sharing their typical days. It’s interesting to read through everyone’s responses, especially given the whole pandemic situation. It can feel like everyone’s just carrying on (we’re all tired of the “this is fine” meme, but that), so reading the real, everyday experiences feels very… soothing. I don’t know, maybe that’s the wrong way to phrase it. I was tagged by Mel, who was tagged by Eric. Colin Devroe, who started this whole thing, has collected a bunch of the posts here
My biggest switch with the pandemic was that I stopped working from cafes and coworking spaces – I’d already been working remotely for years. I don’t really schedule out my workdays, I try to leave space open so I can really dive into something if I’m feeling focused, or catch up on assorted chats/projects/etc if I’m not. Actually, writing this out has been an interesting process in how I might want to use my time differently.
In a recent post on make.wordpress.org/core, Kirsty started the conversation on implementing custom properties in the WordPress admin. One recurring question is – how do we balance customization and ease of use? Ideally we’ll come out of this with a system that is understandable, that both core and plugin creators can use to create new admin color schemes, without needing to override any CSS.
To think about the variable problem, I threw together what a dark mode might look like. This is currently very difficult with the current admin scheme system, and is a goal of the revamp. It had me asking questions like…
How does the page background color relate to the “cards” on the dashboard?
How many variables would we need for buttons, with primary and secondary designs, each with hover and focus states? That’ll add up…
What variables might we need for list tables?
Should the “error”/”warning”/”success” colors be variables? Do schemes need to change that?
I quickly mocked up the WordPress admin in sketch, showing two pages that are pretty representative of the whole thing, the dashboard (plus some extra button states), and a list table with actions.
Then I created a dark mode version (this was so easy using the new color palette!) (while I like this start, this isn’t meant to be a design proposal). I left the menu alone. I have a good idea what variables are needed for the menu & toolbar, since those already exist – I’m going to suggest reducing them though.
This let me pull out a number of things I would want to see as separate variables. In some schemes, these might use the same colors, but they should each be individually controlled.
Page background
Surface (card) background
Surface (card) border (maybe another for list tables? inputs?)
Main text color
Secondary text color
Link color
Link (hover & focus) color
Action-link colors
Notification border colors (info, success, warning, error)
Alternate row background (in list tables)
Row status backgrounds (in list tables)
A detour about buttons…
Buttons might need some more thought, but if we’re willing to simplify the current default scheme, we might only need 4 variables. I’m not sure how to name them though. I’ve split them up like this:
Color A (a primary color)
- Primary button background
- Secondary button text
- Secondary button border
Color B (a gray with contrast against A)
- Primary button text
- Secondary button background
Color C (lighter/darker of A)
- Primary button (hover & focus) background
- Secondary button (hover & focus) text
- Secondary button (hover & focus) border
Color D (a gray with contrast against C)
- Primary button (hover & focus) text
- Secondary button (hover & focus) background
The alternative, which would create more variables but be easier to name & conceptualize, would be to break them out into primary- / secondary-, -background- / -foreground- (or text and border), with separate properties for default, hover, and focus. This gives a lot of control to the scheme designer, but I’m not sure if that level of control is necessary.
Generating variables, or: Why can’t we use just one action color, and darken it for hover?
This has been brought up, but doesn’t work across all schemes. For example, on a dark background, decreasing the “action” color might decrease the contrast too much. Or darkening a light color might be a more noticeable difference than a dark color, so the change is not the same. A high contrast scheme will need more of a difference than a low contrast scheme. For all those cases, the calculation can’t be universal.
The way variables are calculated in the current admin color schemes has been a point of difficulty, which in an extreme example has led me to redefine a lot of the “internal” variables and still need to override styles with CSS.
There’s plenty here that I haven’t touched on – entire screens (the customizer), form inputs, modals, plugins, etc. But I hope this explains a little more my thought process in the custom properties discussion.
This seems to be a tradition now, reflecting on the year in a “last post of…”. I’ve done it for two years now, in 2018, and 2019.
This year has obviously gone differently than anyone could have planned. Most of my (loosely defined) goals last year were related to work, and when everything changed those got put on hold. Also in March, my little dev squad merged with another small team, combining everyone who works on community & contributor tools into one team. Between the team change & coronavirus, it felt like it took months to really catch my footing, but I’ve ended the year feeling pretty successful— if not in the ways I expected a year ago.
I didn’t expect to get commit to WordPress, for one thing.
In WordPress, there are nine available color schemes for use in the admin. They’re generated from a base _admin.scss file, and if I make a change, I need to go and test it out nine different times. I also have a plugin that adds another ten schemes… so you can see where this is going.
I needed something to take a bunch of screenshots, over and over again. Luckily (since the last time I wanted something like this, 5+ years ago…), I knew that puppeteer could handle most of the heavy lifting here. Also, there are some helpers from Gutenberg published to @wordpress/e2e-test-utils for navigating around wp-admin.
Honestly, it all came together so quickly. You can see my end result on GitHub, grab-screenshots.
Series of screenshots of the Themes page in every color scheme.
How does it work?
Puppeteer is a tool that runs a “headless browser” (Chrome, in this case), which means it runs all the rendering that Chrome would do, but without human interaction. It has an API for navigating pages and performing actions on pages like hovering, clicking, typing, etc. The @wordpress/e2e-test-utils package is a set of helper functions that build on the puppeteer API. To be honest, I only needed visitAdminPage, but it’s worth it because it handles logging in if necessary.
First, I set up a list of the core color schemes, and loop​*​ over them so every action is repeated for all schemes. The first step in each loop is to set the color scheme. Next, set up the viewport to the size of the screenshot I want – these will be “desktop” sized, at 1024px Ă— 600px. Now we can start taking screenshots.
Yep, that’s it. Visit /wp-admin/index.php (Dashboard), take a screenshot and save it to the filename I specified. Since this is in the loop, I save it with the scheme name in the file name: dashboard-fresh.png, dashboard-coffee.png, etc.
A lot of the color schemes’ accents only appear on focus or hover, so I want to get some of those as well.
The browser instance is still on the Dashboard from above. Trigger focus on the big button in the Welcome panel. Take a screenshot of just the welcome panel, since I already have the full dashboard (using a helper function from this gist).
Series of screenshots of the “Welcome Panel” on the dashboard, with the big Customize button focused.
Continuing like this, I grab a few more pages – themes, post list, and the customizer. For the customizer screenshots, I used the helper function again to only capture the customizer itself – I don’t want to waste processing time on capturing the frontend of the site.
I’ve noticed some inconsistencies with the color schemes on small screens, so now I want to take some screenshots with a smaller viewport.
This resizes the screen to 425px Ă— 600px and fakes a retina screen. Then we go back to the Posts page, hover over the “home” icon in the toolbar, and take a screenshot. Sure enough, the home icon should be the highlight color like in the default scheme, but it’s white.
Screenshots of “fresh” (default), coffee, and modern.
At this point, we’re done with the content of the loop, and it circles back to the top to switch to the next color scheme and do it all again. When it’s finished, there are 72 screenshots, and it only took a few minutes to run.
I’m not sure how much I’ll use this particular script, but now that I have the framework it’ll make color scheme fixes a lot less tedious.
I also have two other scripts in this project, but I think I’ll save those for another post.
​*​
I’m using a for loop here (instead of schemes.forEach) since I need this to be synchronous.
