Today I happened to be taking a tea break and saw a post in Slack by Cory Miller sharing a challenge he’s embarking on of 30 days clicking publish. I paused; I found myself wanting to click away, but for some reason, I wasn’t able to, and I found myself in this editor writing this post.
I’ve slowly been getting back to writing again after falling somewhat away from the very thing that started me on this WordPress adventure – blogging. It’s been incredible to start discovering that again. This is the nudge I need, so I am taking it with both hands.
I have no plans, but I do want to continue the pace I have writing around the new theme space. I also have so many posts and ideas that I have postponed because of ‘what ifs’.. well, I have no excuse because if I am committing to 30 days of writing, I need material!
All too often, we stop because of assumed fear, but that means we might miss out on something awesome – there are enough barriers without becoming one for ourselves. There’s been so much that happened lately I personally want to miss out on less so here goes!
A few days ago, I wrote about creating themes and my current process. I wanted to share some things that have made it easier for me using the full site editor.
Reset and undo are friendly
There are tools to undo anything. Even if you save something, you can remove a template, template part or undo that change. All this means exploration can be safer than ever before in your theme.
Undo
You can find undo here:
Reset
There are a few resets; you can find them in global styles, but also beside most block specific styling – such as layout or font family.
Removing a template part or templates
Your theme might have templates or parts, but they appear on your site saved just like custom content as you also create them. At any point, you can decide to remove these. A little note, before you do remove any template part or templates, I would always export them. You can export by clicking here:
Once you’ve done that, you can visit the menu and delete your part or template just like any content.
Set things on the group, not the entire page
Previously, if you wanted to set a 20px around the edge of a site, you might do this even on the HTML element. When using the editor, the problem with doing this is if you want to change the background color on a different template, you are stuck with that across the entire site or having to override in CSS.
Using the group block, even as a wrapper to your main content, you can then change anything you like per template. The less styling you have that sets across all templates, the better. In the future, applying per template spacing will be helpful, but this method works for now.
Always keep an export
Exporting and adding via the template editor in wp-admin is a useful workaround when things get a little confusing with why something might not be working. For example, at times, you might find one template works because of nesting, where another has a slight nesting variation you can’t track down. A quick solution is to delete that template and replace it with a working one. This has saved me more than once!
Different sized fonts help for navigation
If you aren’t using any CSS, you can vary your navigation using the typography format options available and color options. A further tip for header areas is to use a column layout and spacer blocks to adjust to get that perfect fit, even if using different font sizes.
Check if you are in global styles or not
It’s easy to forget as you are adjusting that you are in global styles. You might change something and then edit the template. It’s easy to not realise you are in global styles and then save without remembering. Always check what tab is active when you are styling. If you’d like to see this improve there’s an issue I created for conversation.
Be careful about using too many custom colors
Whilst it might seem exciting to dive in, it’s hard to keep track of what is what and get that exact color everywhere. If you have access to theme.json I would advise using that as your source of colors specifically. It’s easier to keep track and avoids guessing what custom color is where.
Make sure you have ‘theme font’ set
By default, theme font isn’t set on any typography. You can set this yourself, but you do have to set it on every element that could use typography. When you add a block, remember to do this. You can also save globally by block type if you want for future block types. To do this, simply set it to ‘theme font’ and you will use the font set in theme.json.
Don’t miss the + to add a template in the site editor
This is one that hopefully will get iterated but you can very easily miss the + button. From there you can add directly a template. I created an issue to continue the discussion.
Test in all devices
You can test in a variety of views right there in the site editor. By doing this, you can quickly check what your layout will shape up like.
Use list view
My final tip for today is if you get lost, don’t forget about the list view. This shows you the entire structure of your site. You can’t yet interact with it beyond finding a block (my hope is that will change), but it’s so incredibly useful to find things when you get deep into nesting.
The editor is powerful, but there are always things to learn along the way. What we are interacting with right now is also going to grow and adapt rapidly, which is incredibly exciting. I look forward to being able to share some more tips as I find new things and more features get created.
I am still like many discovering how I create themes using site editing, but I wanted to share my current process and some observations I’ve made along the way. The image for this post is a picture of yarn because at times I’ve felt like I am untangling yarn as I piece together my process in this. That’s a natural part of learning and finding those threads is also fun as the reward of discovery can be shared.
My current workflow
My process has ended up having a few stages to it; this reflected the creative process of creating a theme:
Figma: I gather inspiration, colours and typography. I may have created a sketch elsewhere or do there roughly of a concept.
Theme files: From the concept, I have a recipe list of things to add to my styling, from hierarchy, colours to fonts. At this point, I am typically only setting up the theme name, basics and also foundational styling values.
Site editor: Create the theme, taking the foundations and applying them to each page template.
After I have the templates formed, I typically export the templates and parts, put them in the theme files, and then push them to Github to keep a record outside the site.
Observations on theme.json
Theme.json is the foundation of my process; it’s where I set the scene of my theme. Here are some notes from using that as my foundation; I share these known issues exist to resolve things and also that sometimes it was my workflow being the issue:
From time to time, variables have got stuck. For example, content width when using variables can get blocked on a value or not even work at times. I am still working out how and when I use variables.
Your file can rapidly get long, so having some supporting documentation with it might help to come back to later.
Use names that make sense for colours. Right now, there are no conventions around this (although conversations around this excite me), but coming back to this, you will thank yourself if you give terms that are easy to make sense.
The most significant change beyond the file structure for me is creating in the editor. Although it is a little like going back to Dreamweaver, I guess, or other ‘create in place tools’. I have some notes from that experience:
What you see isn’t always what you get. Gradients are ‘unexpected’ between the front and back. A lot of what you see when editing, particularly around spacing, won’t look the same on the show. Often it looks better, which is a pleasant surprise, but things like spacing aren’t always accurate.
Be at one with group blocks. Whilst it is something I want to reduce the use of, the number of group blocks I have used is significant in many templates.
Creating in the editor forces you to think content first. This way of thinking is a huge benefit. I am laying out not with fake content; I am from the start interacting with reality.
The spacer block is a good fix for things, but I wonder about the overuse and yearn for those incoming better controls, just like the group block.
Query block is powerful but delicate to use currently; when you remove a block from within it, you can easily break the entire block. It will get better, but until then, be a little careful where you click.
The side list navigation is your friend as you get quickly into deep nesting in these templates, so you need a clear, simple way to find things.
Featured image block can be placed in an area outside query loop and pick up the last content if in an archive or the post feature image if in single.
Styling templates
Overall, the process is a matter of getting used to it. What is being created by many is right now minimal because of that process. There is also the limit of the editor itself, and unless you want to mix in the prior theme styling, you will find lighter styling options. The tools are growing, just like I am learning rapidly, so complexity increases in what I create.
Being able to have templates just for content, created on the page itself, is incredibly powerful. For example, this post itself has a template that changes the colouring. I plan on writing a tutorial on this because I think the idea of single art directed templates is exciting.
Wishlist
Here is where I get a little hopeful for things to come. I will also be going along to Github and see if there is an existing conversation; if not, perhaps start one. This list focuses on the editor’s tools because ‘how’ creation happens should be explored collectively; everyone will likely have varying methods.
Adaptive points: more granular control around this, although I don’t think it needs to be too much and I know this is planned.
Template styles: whilst global styles are great; I find myself wanting to set styles for the whole template itself- not easy as you’d think without a group block around it all.
Consideration over what should be exposed as global options: as more get added, extended, there is an impact on usability. I think it is going to be an ongoing discussion. I want more as a creator but as a user a more straightforward interface and less confusion.
A way to reduce group or spacer block use.
A visual indicator that is a little stronger when in global styles. I have reset my entire styling for the theme more than once, thinking I was just in a template.
Ability lock templates would be great, perhaps relating to my mishaps with the above overwriting of styles.
Road to go
There is a road to travel with full site editing. I am also aware that many of the processes and ways I am doing things right now will change. Where there are boundaries, those will also move as the features improve. That’s the point of this early stage exploring and also part of the joy. We are all getting to discover the new features, tools and give feedback to make them better. It’s an exciting time for themes.
When travelling, way stations are great to pause, refuel, check your gear, and even observe the incredible scenery around you. I am taking a moment to do just that as I’ve been busy the past few weeks getting to know the current space of themes.
Never travel alone
As I have journeyed through this, I have realised the connections between the theme, patterns, and blocks are where things come alive. I think of them as the perfect travelling companions. This has opened up a spiral of discovery for me, which I welcome and has led me into block development. A long while ago, I explored this, but with @wordpress/create-block, things have come on so rapidly it is a lot more refreshing. I am loving greatly block.json and find it incredibly powerful with the recent additions.
Levels of companionship
There are levels of companionship between the theme, blocks and patterns. You don’t have to work with all 3 – although things come alive if you do. You might have a theme with just some patterns or adventure into block styles. I’ll add here that block styles have become a tried and trusted practice I lean into more and more.
You have a few more options now you aren’t tangled in the theme. I find this refreshing and have significantly enjoyed being able to switch modes.
Sometimes, there are dragons
Things are early in some areas. Sometimes it works, and sometimes it works in ways you stare at the screen wondering why it worked that way. I found many of the issues I came against already logged or that others were also hitting them and had workarounds. I want to share my own knowledge; because if you see a dragon, report it.
Working processes need learning
I plan on writing a post that goes in-depth into my process of creating themes this way. However, it’s worth noting I kept across a few areas finding resources either fragmented or a little lacking. This happened less for theme.json and recent documentation.
More significant issues came as I ventured into even working out how to create a plugin that compiled. It reminded me we sometimes presume the paths are known, but often a new traveller or even ourselves in the future might now know. 5.0 was a long time ago; we shouldn’t presume knowledge is held yet.
What have I created so far
If I have linked a repo, know it’s very early, and anything could change; I am experimenting right now, so consider the contents in that mindset.
✔️ Updated Lithosphere as a FSE theme to roll not only onto this site but across my site and blog. There are things to do across sites, but I am working through them.
✔️ Begun working on Sender, a theme that focuses on writing.
✔️ Initiated work on the blocks for Sender: signature (a block that allows you to sign content), stamp (a stamp for site logo).
I have quite a few ideas, but for now, these are the works in progress. I am starting to see this space a little more like a journal for myself as I go on these adventures – anyone is welcome to join me.
WordPress themes have been stuck. It wasn’t their fault they were being asked to do so much and often had to pretend they were plugins. The end result of this was seen in code weight, style stagnation and generally a lack of excitement around themes compared to the years gone past. I don’t say this to call anything out specifically, it was a situation of circumstance. It is a situation changing and one of the huge factors of that is theme.json which is bringing the first major theme process change to core in years.
The power of changing process
Theme json if you aren’t aware if this magical little file that can sit in your theme and send all kinds of amazing presets to the editor, using global styles for example things spark alive in the full site editor. This post though isn’t a ‘how to’ about theme.json, it’s about how the use and existance is a process change that not only brings us closer to the rest of front end development, but unburdens themes.
A statement to make
I am very aware that saying ‘first major theme process to core’ in years is quite a statement. Theme.json to me is that though. I don’t say this ignoring iterations and improvements, WordPress is a project flowing with the energy of those. However, themes were on life support stuck in a land when the rest of front end development was moving on. It wasn’t for some trying to change that, mostly when they did the time wasn’t right and as it didn’t come from core it was always a harder change.
Block based template parts and templates are a companion to theme.json, to make a block based theme – that’s a lot of blocks. I am therefore, aware in just calling out theme.json that it might seem a little unexpected. Theme.json though seperates style from form. It allows thinking of the art direction, the true effect of the theme. This is a mental model shift. You aren’t patching at the CSS level, you are thinking holistically. Combine that with the other tools and you’ve got a powerful combination.
The burden of themes
For years, most themes had PHP, HTML and CSS. Then along came JS, with at the start a few jQuery scripts and overtime some rolling of the theme author’s own. Many use Sass.. there’s a stack to theme creation that grew more and more over time. With each thing added the burden got more, the hurdle to learning more for those coming in.
We not only were creating more issues for ourselves in creating themes, as we navigated around more complex interfaces, but we were putting walls in the way of the knowledge. I remember like so many viewing the code of Kubrick, it was how I learnt themes. We had reached a point where honestly, I am not sure how you’d learn themes.
Not just adding but removing
I am aware as I type making it sound like this is all a simplification magic wand, that I am using language that sounds technical. Even the notion of a JSON is ‘another thing’. However, what theme.json is doing isn’t just adding another thing, it’s allowing to remove a lot of other things to. This is one of the key points.
There is also a readability to the way theme.json is created, kudos to those that worked on it. It flows, it makes sense and because it’s core there is an incredible documentation effort underway.
Putting themes back in the hands of designers
I am incredibly excited to not just have those designers that code be able to make themes. Whilst we are great, the designs that haven’t been able to be made into themes make me so sad. The designs that sit waiting for a developer, or that a designer couldn’t turn to their vision because the tools weren’t there.
Theme.json, it’s friends block templates and parts, start us on the road to that by being part of the process of full site editing. It’s not quite there, but eventually no-code themes will be possible and that is going to see I hope those designers free to create their theme dreams.
For those of us that do dabble in code, these new processes take the hard work out of themes, they free us to be creative. To truly explore and that can only lead to incredibly exciting things.
The start of something
I see theme.json as the start of things in many ways. There are going to be so many iterations and exciting tools along the way. Themes can get back to being just themes and that can only be good for WordPress because that’s when they can be beautiful, inspirational and creative.
I had a Labrador that was fearless about jumping into the water. No matter what body of water it was, she would launch herself into it, seemingly without checking the depth or anything in a blissful trust of the water. Of course, we’d all love to have that total trust as we start a project or come into one.
The reality is she did some checking it was just invisible to me stood watching. There was instincts and likely an assessment, although done at speed. Treating every project with a baseline of checking ensures you don’t leap without knowing.
Projects are usually a black box, particularly those you come to in progress. Taking time to observe the lay of the land before diving in is critical. Pause, open your eyes. Engage observation mode; listen before just diving into creating. Deep breathing here fills your lungs for the dive ahead. It stops wasting time, stress and allows you to start from a place of strength, not hope.
Check the reviews
When booking a restaurant, you often check out the reviews. If you wouldn’t eat somewhere without checking those out why are you ok just diving in without asking those working on it or who might have? Often you may find someone is working on it already or has gone down a path now abandoned you can be aware of and not waste time doing the same.
This pause is an opportunity to listen, channel your inner archaeologist. Context is critical before making any decisions so ask, observe and make sure you know what has come before. You never know someone might already have found a solution, or be very close.
One toe at a time
You don’t jump straight into a bath, or maybe you do once then learn. You check how warm the water is and then go in. Often if you jump both feet first, the sound of the splash will ring so loud you’ll not be able to focus. Taking time at the start means a stronger project and a better experience for everyone.
Check for monsters under the bed
Part of the eyes open approach to starting a project involves being honest about what could be lurking. If you give a monster a name in fairytales it often got less scary, do this to your project monsters. Name them, note where they are and be ready to slay them with your sword of preparedness.
Make sure you’ve checked everywhere, those project monsters like to hide in tiny places. If you are coming to a project already in progress be sure to ask where the monsters are hiding.
Take a map, snacks and don’t go alone
Starting a project is a journey so prepare like you would for any adventure. Pack your project backpack, take snacks, make a map and above all, don’t go alone. While you might be leading or the point person on a project, you never have to go alone. A travelling companion makes everything seem a shorter and less arduous task. Plan the next steps and where you are going to go.
Measure twice cut once
The crux of this is about taking time at the start of a project. If you do this, you will rapidly get on the same page. While there is a little pause as you catch up to everyone’s breath and get in sync, then you can increase the pace from a strong foundation.
Mistakes cost trust, so by taking time to be careful, check the situation, you can ensure everyone has the best project adventure possible. Looking before you work enables you to work effectively and get a lot more done with a lot less stress.
Over the years, the way I write talks has varied. It’s morphed and iterated to a place where there is a particular flow I go through every talk. I wanted to share this as often I feel the creating of talk is an unknown thing, so here is how I do just that.
Note storming
My start is probably the most hectic of the stages. I typically begin with an empty wall, a full playlist and a fresh cup of tea. I then start filling up this wall with ideas from my brain. I don’t care about duplicate thoughts; they all go up. There is no editing, just the flowing of ideas out into his space.
I often form a colour code for the talk; this can vary as I do different ones and typically is around types of content or focus — for example, quotes, demos and my thoughts.
Physical iteration
My wall at this point is full. I enter a phase of iteration usually over a week or so. I make a point of looking at it each day, a few times a day regularly. This check-in ensures I have it close enough to my mind.
A big part of this is thinking about the flow, how each section will connect. At this point, I look at my description, the seed that started this talk. I always try and keep to the description; however, if I have strayed, I can check back in now and see where.
A lot of moving of post-its happens at this point, I usually also layer on others as I add-in for extra sections, further meaning. The visual on my wall is growing as I then move onto the next phase.
Outline
Next, I copy all the notes from my wall into usually at this point Bear (which I write a lot of my content in). I bring in each using headers, and from there I typically spend some time creating those and lists.
Usually, pretty rapidly this takes me to a process of iterating the outline, it’s typically easy to see where my hitches are, where things I thought worked just aren’t going to or duplicate thoughts.
Fleshing out
Once everything is in the outline, I get into focus part of the talk. I tend to have to be in a particular mindset for this. It often is later at night. I have this weird habit formed lately during this state of hooking into one song or type of songs for a talk.
I will rapidly start forming around the outline. At this stage, it’s not the full talk, but it will involve a lot of details coming in. I typically reorder pretty strongly the outline at that point. Lately, this process has flowed naturally on from the outline. I do try and time box this though to make sure I get the talk sit and come back to it another day.
Content magpie
Next up is hunting for content to bolster my talk. This will depend on what talk giving, but I often include a quote. I might need some statistics or data at this point if giving a particular talk. Should I need screenshots, I take them now.
Part of this process stage is also going over past talks to see if there is anything I can include. I often tie back with quotes; similarly, I might have examples I now can bring into this talk. I also might want not to repeat a point I’ve been overly stating.
Moving to their home
At this point, I tend to move my slides to their home in the presentation application. Lately, I have been trying to use the fantastic Slide plugin for Gutenberg by Ella van Durpe. I set up a test site and share the link for slide checks by organisers, but you can also export into PDF. By moving the slides, I begin to see where gaps are; this brings it back to an outline again.
Sketch forming
Most of the content is now at least hung up in the talk. At the point of sketching visuals to be used on slides, I begin thinking deeper. I tend to hand draw often my talk. This gets me into the tonal space of it. It can be at this stage I do a substantial rewrite.
Distil, recite
Once the talk is in the presentation format, it’s then a case of rehearsing, and minor iterations as they happen. I find by running through the talk a lot of distilling often occurs due to the nature of that process.
Well, that’s my talk process. I’d love to know what yours is.
I took some time over the holidays to plant a seed and create a new theme for this and a few sites. I had a few objectives this time around that I wanted to achieve and the biggest of these was to create a foundation I could experiment from over the coming year.
Keep it simple but with readability.
Where possible have everything from the block editor, including navigation.
A minimal base to build upon.
Share my journey (starting with this post).
I began with a simple sketch, starting to think about what I would like this theme to be.
The lithosphere is the solid, outer part of the Earth. The lithosphere includes the brittle upper portion of the mantle and the crust, the outermost layers of Earth’s structure. This theme is a foundation which will be built on by the editor. With the functionality below and styling above.
I began by using the Gutenberg starter theme as my base. It’s a terrific boost to any theme project. I didn’t have to reinvent any wheels and was already off to a great start.
I picked ‘Libre Franklin’ as the font; it balanced readability with the larger, crisp font sizes I wanted. I decided to make the typography scale bigger than have in the past on themes to improve readability. Colours, again I went for blue with a brighter variation on hover.
The most prominent styling element was a top strip which had the title. I choose to use emojis for titles. I was pretty happy to discover you could do that in the Customizer. I then added a little background to it to create a logo.
Navigating
I didn’t want to have traditional navigation. Previously, I was using a reusable block made from a list and styling for navigation. Now with the new navigation block, I could use that to create my own.
I wanted to link my sites through this navigation, having each going to a type of content. By doing this, it was a way for me to bring in some different sites I use and over have them separate to titles, link to what they are specifically about. I also linked in my reading list and speaking page. As a final point, I tied in a contact email using a plane emoji.
One cool thing I found was the ability to copy and paste blocks even across sites. I have rolled this theme out onto various sites to tie in with the navigation and each one I could add the navigation and social links block by copying – so cool!
Layout using blocks
For the front page, I wanted to create a summary layout. The latest posts block was just perfect for this. I added it and set to a grid layout. You can adjust the excerpt length, so I did that. It’s a great way to create a starting page to content.
I also added in a search block to the top of the page and a quote block to frame the latest posts. Building layout using the blocks gives me the flexibility to change what I want effortlessly.
Block styles
Along the way, I brought in some styles to particular blocks. For example, the search block got a wide style using the following code:
I also brought in some adjustments for the navigation block, and social links as the default Gutenberg starter theme has some margins I didn’t want for those list styles.
Adding dark mode switch
The foundation of my theme was in place, but I wanted to add a few extras. I have only got around to one of those so far, and that’s adding dark mode. I remember having one on my blog that would change the season and having lots of others – they were such a part of sites for a while. I wanted to simplify back to a light and dark mode as for me often dark mode is easier to read, but it’s personal so having the option makes sense.
My searching for a solution took me down the path of using CSS variables. I ended up finding a tutorial by Ananya Neogi ‘Create A Dark/Light Mode Switch with CSS Variables’. After some adjusting to suit my styling, I ended up with the switch that is here. It’s an exciting solution using:
I on purpose am ok with the theme being pretty rough and ready at this point. I want to see it as a work in progress over the coming months. As more features get added to the block editor, I want a space where I can explore them. I’ll try and share those as I do.
Here is a list of a few things I want to do coming up:
Create some editor layout templates for the portfolio, reading list, speaking and front page.
Improve dark mode styling for blocks and form elements.
Iterate on smaller device styles.
Find a way to change quotes. Maybe a quotation block could be my next block to make.
Editor styles to reflect front: some don’t now so want to tie back.
Add a day/night option to the header. Possibly, also add weather to it.
I also have a fair bit of styling to polish for things like comments and forms. As a bonus to doing this, I also got a few bugs and ideas for enhancements.
If you’d like to see the work so far, it’s all up on GitHub, and I’ll be updating there.
Block boost
There is no doubt, creating a theme and the layouts were faster because I use blocks. I do recognise the considerable push forward that the Gutenberg starter theme gave me. It’s incredible how you can create almost a full layout using just blocks, a taste of amazing things to come with site-building this year.
I am looking forward to from this base theme exploring as the months unfold.
Over the holiday break, I set myself a challenge of building an editor block. While I have worked within blocks and the editor, I have yet to make a block. The time had come to change that.
Now, I want to be clear before I write this post that my JavaScript skills are still light at this point. I have been trying to learn more and getting there, but I don’t enter this block building adventure with many tools in my backpack. Nevertheless, I bravely began my journey because this is part of learning more by doing. I started in a comfortable place, planning. I was going to build a knitting pattern block.
Planning the block
I knew my abilities for block building were likely not to be where my vision was going to be for this. That’s ok as I don’t just see this as a one-stop project, it’s something I plan over the next year to continue on this quest. My rough block though I wanted to be as simple as possible.
I distilled down what I thought a knitting pattern would need and each format:
Project title (Heading)
What you need to make it (List)
Steps to make (List)
Some others I thought were optional:
An image to encourage to make (Image)
Level of difficulty (Rating)
Notes (Paragraph)
Stitches going to use (List)
I had my plan; now, it was time to think about how I was going to build this.
Learning by viewing
One of the bedrocks for me in WordPress is learning through reading code. It’s how I got started in themes, pursuing Kubrick and iterating. Blocks, however, there’s an issue here. Many have build scripts, bundling, compiling and output that isn’t readable or is for someone reviewing incredibly confusing.
I found myself with a problem. I would browse blocks and look at their code baffled. I thought a little and took my planning back to the documentation; this is where I remembered the excellent resource of the Gutenberg examples, linked in the handbook. These are simple blocks going up in complexity.
Focusing on steps
I want to pause a bit on my journey to note how complicated the language and stack we use right now is. While there are benefits to someone learning, it’s well quite frankly a lot. It was for me, and it is for everyone. The biggest issue right now is knowing whether you are doing the right or wrong thing, that combined with some pretty complicated terminology is daunting.
The reality is, at the start, you likely aren’t doing the right thing, but that’s also ok. I noticed myself spiralling down a few rabbit holes trying to work out if I should go ‘esx’ to not. I caught myself, pulling back and reminding myself that I wanted to keep it simple, focus on just creating a block. I choose to, as a result, begin going through the examples copying one by one, letter by letter and building up.
Modifying the recipe block
As I followed each example, the recipe block came up. Having run each block, I was already riding on a high of happy; there was something magical about getting input to work and just loading my block. The recipe block, after I ran through the example, felt an excellent spot to modify from and create my knitting pattern block.
I changed the field names and ended up with:
Title (Heading)
Image (Media button)
Materials (List)
Pattern (List)
After some fun with variable changes, not working, it worked! I was pretty joyous at that point, while simple, I had the foundation of my block!
Over the next few days I added some iterations to get to the version I have now:
Separated materials into yarn and needles.
Added placeholder styling to media button.
Moving forward
I have a list of things I plan on doing, which more or less go up along the list in difficulty.
Learn how to change the icon. Currently using copied one from recipe block.
Document and tidy up comments in the block.
Add some front end styles.
Look at how not just to have media button but have media placeholder and block.
Explore ratings.
Look into ‘esx’ and how that could be better for me to use. Along with this going to have to explore compiling, I think (although need to get there to know).
Explore nesting as I feel this might be better as nested block to allow various types.
At some point I would also like to consider releasing this block, however, for now, you can find it on GitHub.
Reflections so far
My journey into block building is successful in the sense that I have a block. It’s a pretty simple block though, and as noted, I have a few plans outlined above on next steps, but I achieved my first block. There are a few things though I feel worth calling out in the little journey I’ve gone on.
As noted, the examples are critical. I was quite frankly spiralling down so many rabbit holes until found them. That said, the examples themselves were a little confusing at the start between things like compilers and ‘esx’. I also wish there were more examples, and that’s something those of us learning can maybe help both with feedback and sharing what we create.
I acknowledge my light JavaScript skills probably didn’t help much in both knowing the differences or understanding examples. I also know I was taking the harder road by not using a block builder. There are many great builders out there and helpful scripts, but I am on this journey to learn. For me, this works best with getting as close to the code as possible.
I am coding a block character by character from scratch over use a generator as trying to learn the nuts and bolts. It’s easy to be removed from what is going on and never learn. For similar reasons I am going back to commandline Git this year.
Although I experienced some pretty long head scratches and ponders, I could find the information. The docs are there, and also it’s pretty easy to search for anything you get majorly stuck on. You do have to have confidence you can quickly get out of anything (undo! undo!), but that’s part of coding, to breathe and back up your mental truck. I often was confused and unsure if, on the right path, I could though fall back on reminding myself if it worked, it was good enough for now.
A journey
I have reached a short stop on a long journey. While I achieved making a block, I know it’s not where I want it to be, and there is still a whole lot to learn. That’s exciting, even though I am reasonably sure I am about to enter a steep learning curve, that’s also fun. As a bonus part to this, I also levelled up my use of GitHub command line, which was great.
If you are thinking about diving into making a block, I encourage you to try it. You never know what you might be able to create and what journey you can start on.
This post is from a talk given as part of the Joint Futures conference and is the transcript presented. You can find the full slides here.
Imagine a space where anyone can comment on everything you create. Where people across the world unite to create something given away for free. Where no matter what your skill you could turn up, contribute and be part of creating a widely used product. That runs async, fuelled by passion.
This is WordPress, an open source project. I want to show what happens in the project, how design works and functions within open source. The challenges, but also some solutions, some ways it’s starting to evolve.
There’s a phrase used a lot around OS of ‘free as in beer’. I personally prefer the phrase I’ve seen used of ‘free as in kitten’. A project is relatively easy to set up, but the maintenance, growth and nurturing… that is where the effort needs to be. You’ve got to grow your kitten, feed it and keep it safe. Design Ops brings that to design, you sow the seed, support and then weed.
Open source isn’t just a checkbox, you can’t declare something OS and it’s ‘so’. An open source project needs process, boundaries and a community needs to have structure otherwise it isn’t open source it’s a free for all and the kitten goes without food and maybe just walks away to fork itself into another project. Open source is made of people, something we often forget when downloading a project. It’s made of their passion, often their spare time.
Open source projects are typically remote by default. People collaborate around the world, from wherever they are. The way communication happens in a project like this is usually async. This could be on a variety of platforms from IRC to Slack, forums to message boards.
Each format typically has specific types of communication, more suited to them. Mixed in with this is tracking systems and ways to work on issues and projects.
Challenges
There are a number of often unique or amplified challenges working in the open. I want to spend a little time highlighting a few before showing how a more operational approach to design can ease them. It’s important to note that whilst this talk is focusing on design, the challenges bridge often across roles. Within a project, the roles often blur far more than in a company structure. Like any design problem, by knowing the challenges you can suggest solutions.
Firehose
Imagine you start contributing to an open source project. You are excited to be part of this amazing project. You maybe get an introduction at a contribution day, or you turn up to a meeting in Slack. Everything seems calm to start off. Then pretty soon after replying to a few things the emails start coming in, first just a few, then as threads of issues get longer they grow with each comment on an issue and ticket. You subscribe to a few key blogs for the project. Then you start getting notifications as you participate. Before you know it when you wake up your notifications are lit up across multiple platforms.
This isn’t unusual, the firehose is real in big projects. Most rapidly are hit in the brain for 1000 points within a very short time. This all assumes you can even find a way into the project through the firehose, that’s often where the first problem starts.
Raining Stick-holders
Whenever someone says stakeholder my mind skips to seeing them as stickholders, often waving those sticks. It’s just not a great word. In a project depending on the size you can have quite a few of these. Not only might you have project leads, focus leads and team leads. You have the added angle of drive by stickholders. Someone can come into an issue on GitHub for example and derail or kill it with one comment.
I’ve seen cases where social media is used to rally opinions and almost campaign like approaches.
Jumper Thread issues
Often even starting is a mirage, what seems to be one thing rapidly turns into something else, you pull that jumper thread and suddenly realise it’s unravelling. This could also be entitled good first issues are a trap! So many things in a large, established project are just not as simple as they seem. To someone new to a project this is a horrible experience, you turn up and as a volunteer end up in a spiral, stuck.
Herding time-warping cats
I use this term lightly and with respect because when everyone is a volunteer and you are trying to coordinate a project timeline, it can truly feel a little like herding cats, not only cats but ones that time warp, in different timezones. You can’t demand to keep to a strict timeline in this case… Volunteers are the fuel that runs open source projects.
If someone is a volunteer they might have a lot going on and only be contributing on Sundays, once a month. They also might rightly only want to contribute to a certain thing. Not all tasks though are attractive.
Culture
By it’s nature a global project needs a different mindset to a local one. When you mix in async and also multiple languages, you get quite a complicated experience.
Familiarity breeds exclusion. I know I’ve fallen into this. As you know someone you have a shorthand for communicating and understanding. My own communication style also defaults to casual, emoji fuelled. Checking this is a quest, but an important one. You have to be careful also of regional references and emojis.
Imagine someone contributing in Australia, their experience is often getting up to decisions having been made and going to bed leaving messages in hope they get included.
Nothing Fits
The reality is most tools, from tracking systems to testing in open source are created by developers for developers. It’s like from the start even the tools are saying you aren’t one of the project, you are other.
GitHub opens up far more potential, however it still can be used to suppress voices, through thumbs down drive by emojis that you can leave without commenting. The tools that are offered from setting up a testing space, to running a patch easily without one, to even reporting a bug and giving feedback, they are often ill fitting and the last worked on.
In practice
In truth Design Ops as a practice has existed for a quite some time. It is important to not see anything being done here as new. It’s often interpreting existing organisational psychology. You need to always look outside and learn. Within WordPress the community team is a great source of knowledge and insights. How does designOps work in a project like this though?
Adapt, morph, bend
DesignOps should not be static, be like a reed.
This is one thing I think sometimes is forgotten in this work is like design it needs iteration. You don’t release a design and say that’s never changing, so why would any operational practice in design do that? Just like design, it should respond to feedback, testing and data. It also shouldn’t be applied without feedback, testing and collaboration.
It’s a journey not a single destination.
Focus on soothing tasks
Often in thinking about how to aid, the impact is focused on. Actually the biggest way to help is by soothing tasks. There’s a lot of hitch points in OS and finding little ways to ease is really the best way forward. Support comes from giving structure, clearing the way for work to be done.
From an operational perspective, because everyone has their own way of working, it’s about adapting, suggesting, sprinkling not dictating.
Contribution is a design problem.
In practice
I loosely break down how Design Ops works in open source as sow, support and weed. I wanted to dig a bit more into how that flow works with some examples. It’s a flow, constantly moving through each phase and repeating. Like crop rotation and companion planting, sometimes running at the same time or staggering.
Sow
Activate design across roles
Most projects aren’t overwhelmed with number of designers. It’s a fact that is slowly improving but even in WordPress which arguably has a larger number than most projects, it’s not a high number.
As a result, one focus that is key is enabling and empowering design across roles. A dev can create a good first idea when supported and given space.
Related to this is having a design system that supports a dev exploring. In WordPress this is at the very early stages but already seeing rewards of easier prototyping.
Clear space
Design needs to be given space to thrive.
I love simulation games, so imagine you are playing a farming game, you set the clear space where your field will be, set the boundaries out to denote the field. Like in games, the clearing is key. Show ways people can contribute and then signpost, show options, paths.
By breaking down into tasks, clearly defining stages, phases, this helps designers get on with designing.
Support
Single points of failure will end up failing so constantly looking at those is key to where to bring more people into tasks. Note taking for example is a great starting point.
To grow, that needs nurturing, trust and a starting point. Just saying people are design leads is a pretty sure way to have that not work. There needs to be some structure in place to support that role. There also needs to be opportunities beyond big project leading.
Establish cadence
Regular practices bind an open source project. Be it the weekly meetings or updates.
An agenda posted 24hours before the meeting ensures anyone no matter what timezone can comment. Similarly notes and using Slack to record meetings, linking archive in notes, ensures anyone unable to attend can still comment and have their say.
Humans are creatures of habit. It’s easy to forget this. If you as a team have a strong weekly cadence it soothes and people know what to expect.
One way to reduce the firehose here if a schedule seems overwhelming is to highlight what is required and what is optional. By doing this you give people options for deep work and to ease the pressure.
Document everything
Documenting leads to future contributors needing less hands on, which opens up to timezones with less active contributors. For example, a contribution day in Taiwan can run by itself for design as there is a contribution guide in the design handbook.
There is a lot of oral history in a project that’s been around a while like WordPress, this needs to change. Breaking this down into simple workflows, small actionable flows that someone can follow is great to enable people to do for themselves. For example, how to run a triage session or even lead a focus.
Weed
Just setting and forgetting isn’t an option. You need to check/iterate and adapt. Static ops are death. Constantly you need to check how strong your feedback loop is.
Make triage daily practice
In design, we also run triage sessions twice a week as a team. The time is the same each week and this gives an opportunity for people to come along and start participating. Also as a group, we are working together, something really important for designers. It’s a way someone can start to give feedback. You don’t need to get over the hurdle of technology, just turn up and join the conversation remotely.
Triage is not just an event though, it should be a daily practice. Both issues but also of processes. If something isn’t working, weed it out.
Roll up your sleeves
In some spaces an operational role means that person doesn’t get involved with the design, this just isn’t one of those. It’s important to see where you can best help and do that. Perhaps you need to get deep into triage, perhaps break down a project into tasks and dive into a plan… other times you need to boost some mocks or run some usability tests.
You walk together, as a group. Whatever clears, whatever keeps the pace going and flow of a project, that’s what working in this space is about.
The nature of OS means often it’s all hands on deck, that means everyone.
Anyone coming into this can’t sit in an ops tower looking down, you have to get hands-on, that’s the nature of this space. I actually would argue that this should be the way Design Ops happens
The future
What of the future? Everything is done today is foundational. Projects are starting to recognise the need for design over designers being seen as pixel pushers and ‘i dotters’.
Code committing though is still the top currency and that model doesn’t work so well for non-developers, so there’s a way to go.
For many, working async brings an inclusion that working sync doesn’t. Remote brings opportunities to those that would have to move otherwise. Open source projects are spaces where people can skill up, often even changing their careers and running their own businesses.
Open source allows you to reach beyond your perspective. Being involved in a project can open you to different cultures, views. It also allows people to make a living without some of the barriers maybe they have due to location or economics.
We don’t need to shout as loudly as have in past, Design Ops is at the table and recognised.
Design is part of Design Ops and we can’t lose the design process in its practice. Getting fixated on it being the solution in isolation only harms. It has to respond, blend with other practices like DevOps and become part of the process. It only works when done like this, when it’s something not separate, but part of the holistic practice, entire solution.
Open source can truly change the world and people’s own worlds.
For a designer, it’s a truly exciting space, one of experimentation and so many opportunities to improve experiences.
As an individual you can make an impact in a project, but also through your work you can truly make a difference in the wider world, to reach further than you have before. Open source can enable everyone to have access to good design that does good. Access can also be open to anyone that wants to learn design.
These projects need DesignOps to open up those opportunities, to sustain growth and create a space where design flourishes. The seed has been sown, it’s now about supporting, weeding and watching it grow.
