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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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:
Image (Media button)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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
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.
This post is from a talk given as part of the JS for WP conference and is the transcript presented. You can find the full slides here.
The word ‘brave’, means different things to different people. What comes into your mind when you think of being brave? Is it of someone saving someone? Is it of someone pushing the boundaries of what they can do? Is it perhaps of someone just doing something they thought unable to do?
This is the definition of bravery. Bravery is different for each person. We measure bravery by our own gauge. There are also levels of bravery. Courage is linked to the term bravery. It’s seen as a positive. People are congratulated when they show it. Bravery is something to be praised. Words like valour and fearlessness champion those that show it.
Is being brave out of fashion?
In this day and age, you could think so. Whilst not a robust data point to use to only base a theory on, this graph of the use of the word bravery in books, from Google I found really interesting.
As mentioned, there are different levels of brave. It’s maybe easy to jump to the biggest ones when thinking of this. Bravery could be asking for a raise, it could be creating. It could be a small act or a large one. This all depends on our perspective. Without bravery though there is no progress. It takes someone to make the first step.
When you are new to the business, you think if you give a really bad performance, that’s one they will print. You will be judged. You just have to be brave.
Limits to bravery
The fear of being judged often gets in the way of bravery. This limit restricts and confines not just people but projects, entire generations. We learn the foundations of bravery through play. If you are fearful of play then you limit bravery. Without play, without just exploring there is no good performance.
Play in children is a rehearsal, a space they experiment, test boundaries, learn and discover the world. Curious minds explore the possibilities and find the consequences of those in a safe environment of play. As adults, that fades, distilled by rigid minds, stuck notions of reality and the idea that fools play. Judgement weighs on people, crushing their imagination and limiting what could be.
As a child, you are taught to colour inside the lines. It’s those that colour outside the lines that get to really push the boundaries of the world. The projects we work on limits us with their lines to confine, the tools, the regulations, the processes, each a hurdle to experimentation, to growth and a threat to the project’s future.
Exclusion isn’t bravery. Thinking just in your headspace and colouring in the lines isn’t brave. Thinking for the 1% isn’t brave. Creating just for today isn’t brave. All of these things will limit, confine and again ultimately result in lack of growth.
Are humans brave?
Well. If it wasn’t for brave humans we’d never have got here. That’s sort of how natural selection, evolution works. Yes, our amygdala fuelled brain leans towards change aversion. But, really at the core of it, all bravery is what got us here as a species and it’s what is going to keep us going.
Bravery isn’t a clear cut binary thing, there can be blocks to even the bravest of souls. There is a privilege of being brave. You need support, ground that is fertile, an opportunity. Access to even the tools or position needed to take that brave leap may need time and may need far more than someone has. The situation is often an agent of bravery.
There also needs to be a dose of reality when talking about bravery. To be brave without thinking of consequence is rash and selfish. The bravery that moves forward is bravery of consideration regarding impacts. Ethics and inclusion don’t have to take a back seat to be brave. Bravery is a drink to sip and not drown in. Pushing forward then needs a time of stability, growth and assurance.
Moral excellence comes about as a result of habit. We become just by doing just acts, temperate by doing temperate acts, brave by doing brave acts.
I want to talk about bravery in terms of creating. I am going to look specifically at how you can and should be braver in the work you do. How WordPress itself as a project needs to brave. How if we don’t, the future is uncertain and a lot less bountiful.
Bravery isn’t something you can do once and be done. It’s about a mindset. The type of bravery I am talking about here isn’t about running into a burning building, it’s about daring, having the courage to colour outside the lines. It’s about practising bravery in our craft and from creating a culture that is pushing the boundaries of what if.
How to be brave
If you were to think of a guide to being brave in their work, it could probably be distilled to a few points.
Know the foundations
First, it’s about knowing the boundaries, after all, if you are going to colour outside the lines, you need to know where the lines are. This could involve thinking outside the process, outside what is possible today. Outside is a mindset. Knowing your own boundaries is also part of this. Level up what you don’t know, pair and don’t be afraid to learn. Once you know, you can push.
Have an experimental mindset
It’s crucial to have an experimental mindset. To be ok with things going wrong, things not working. Experimentation leads to discovery. Have a think, when was the last time you created something just because? Think again of all the progress in technology, most got there through experimentation. Practising this type of experimentation leads to discovery. It is how you move forward.
Time is critical
Time is critical to bravery. This could be time to experiment or time to just educate. Making time each week, be it a few hours or even a day, for that time to live the laboratory mindset, that’s really how you get to free yourself and explore.
This could be seen a little as finding your bat cave. Your space to create. To think what if, to dream beyond. If you think of a camp or pillow fort as a kid, it was a space of possibilities. Maker spaces are adult versions of these. Think about how you create your own physical or virtual ones of those. It’s worth noting it doesn’t have to be a shed at the bottom of your garden, it could be a shed in your mind. This mind shed is where you can go, create.
Play is important
Play is also important. Having space to create with the purity of play. Having your own sandbox. These points all tie, because being brave is about setting the right conditions. When was the last time you sat down and just played, freely, without setting a goal or focusing on a deliverable?
Bravery doesn’t have to start big. Start small. If you are limited on time, start small there too. Little steps in bravery can become larger ones as your confidence grows. Maybe it is about learning something new. Do that thing 15 minutes a day, build up. Maybe it starts with setting aside one afternoon a month to play, see how far you can take something.
You can’t expect to have the freedom of experimental play if you set a rigid, high goal to stick to. That’s why starting small eases you in. It’s practice, being brave is a mindset you want to become a habit.
You need feedback
To be brave in your work you need feedback. The phrase release early, release often not only sets the stage for this but it creates a space of fluidity within production. Having a culture of feedback also allows growth, but it takes cultivating, nurturing and growth. Without feedback though you will never grow as a creator. It has to also be feedback, not judgement. The feedback you can build on, the judgement you can only have feelings about.
You can’t be brave without being inspired
You can’t be brave without being inspired. I wanted to take a little time today to share some work that inspired me lately. Inspiration is the fuel of experimentation. For me, this often comes in the form of experiences or art. I wanted to share 2 sources of inspiration for me right now and after this talk, I would love to know what inspires you.
It’s important to note that not everything has to be tangible, inspiration comes in all shapes and forms. You can be inspired on a walk, seeing a flower, a story or a work of art.
Mirages and miracles combine ar with drawings and sculptures. There is an incredible video I would encourage you to check out. Drawings come alive through screens. Flowing and moving. Little figures dance over rocks and balance over stones. There’s a sense of delight in this work. The static images come alive through technology.
Teamlab is an art collective that creates experiences that are totally immersive. They explore a new relationship between humans and nature, between oneself and the world, through art. I was lucky enough to experience Planets in Tokyo and recently their video piece in the Barbican.
This is an experience that completely moves. To be able to create experiences that touch this deep, this whole, whilst yes this is an art piece, you can take this into the work you create. How can that emotion, the immerse experience, be translated for example into an application, the act of writing or of editing a photo.
If that’s how to be brave yourself. Let’s look at the wider work of a project. How did we get to where we are today in technology, in WordPress as a project? Well, we didn’t get there by not being brave.
WordPress as a project had a lot of ground untrodden to grow from what it was, to what it is today. This gave the opportunity for bravery, for exploration. There were even in some cases no lines to colour within, it’s easy to be brave when nothing matters as much. When it’s all an experiment. A lot of WP has been shaped by experimentation. By brave thoughts of what if. Plugins that tried something different, that explored. Patches that were just to see. Many features grew from a passion, an idea that someone had and took to the project, grew into a reality.
Open source itself moves forward through these experiments, it doesn’t move ahead through cautious lack of bravery. Even the idea of open source is pretty brave itself when faced with the majority of the world. The idea of our community even functioning is a brave one.
Gutenberg is the past now as far as phase one being grown. It was a brave idea seed. Created through experimentation. This was done in the open. To experiment in the open really takes bravery. Feedback comes in all shapes when you do this type of work. During Gutenberg phase one there were many ‘what if’ moments. Play leads to trying things that hadn’t been done before. Creation was done with a curious mind, an open to pushing beyond what was before. This is how we got to where we are today.
That’s the past, what about the present? Today our situation is a space we’ve got to through bravery, experimentation and a passion for the project. How though can we get to the future?
At times it can feel like we’re stuck, static. Our brain freezes because of too much, we are in overload. There has been an arms racing of tooling, a snowstorm of change and the space we’re in seems confusing, antagonistic and complicated. In times like this, we drown in nostalgia, it’s not a time to be brave, it’s a time to batten down our mental hatches and soothe our amygdala. Everything is big, everything is too important, deadlines mount and paralysis of options is the mode of work for many in this space.
What if though, rather than being at a peak, rather than being stuck we were at a cliff edge… we could jump and soar but are we brave enough to make that leap?
Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it.
Our tools bind us in the work we do. They are line enforcers. They have created this paralysing space where it’s easier to process out the same work than dream beyond.
Creating today can make you feel like you are cast adrift on a sea of processes. A prime example of this feeling is even setting up a local development environment, something like Vagrant. Whilst the setup screen is fun if you want to pretend you are a hacker, one slight issue and it all falls down again. The technology we depend on seems shockingly fragile and so cryptic to fix when it inevitably does break.
Even the process of committing has become so high it often leads to confusion. An example of this is Travis on a GitHub project, whilst this is amazing when it works as checks commit, when it doesn’t debug the cryptic messages is similar to reading ancient texts. If you are able to commit then you should be able to understand how to fix what you break, all too often that’s not the case. We shouldn’t be forcing people out of being able to commit because of overly complicated processes, they should make it easier for more to be included.
So many of us have stopped blogging. The once space of our dreams and theories now lies vacant with the last post a year ago of ‘must blog more’. Maybe we make an excuse that we will update the theme and then suddenly be able to blog, or we are ignoring it hoping it will go away. Through posts, we used to share ideas, dare to dream. It all got a little too serious, too fearful that every word matters, will be analysed and you’ll be held up to it.
The same goes for Codepens and design experiments. These are confined to our best work, nobody shows their sketchbooks anymore because all too many assumptions get made and blog posts hook into it being the ‘only way’, ignoring it’s just an idea, a flotsam of the mind. We are scared to share because everything is a big deal.
In a climate like this what is created becomes predictable, stifled and limited. Safe becomes the style and suffocation of creativity in the process. There is a fear of deviation, a fear of standing out. Ideas are analysed with magnifying glasses and pitchforks, why would you create if space feels like that? It’s easier, safer and a lot less traumatic to just toe the line. To colour in the lines.
Oh you’ve never used Contract, XXLJS with pikachu.js or the LSD-Module Cross-bow launcher that is backwards compatible with MollyJS, you’re like so last season!
It seems like not a day, even hour, goes past without some new amazing framework or outstanding technique that you “just have to try”. Posts stream past social media on this breakthrough, that amazing new hotness and ‘oh my wow this just changes everything’! It feels like we are all stuck in some next framework idol popularity contest. In all this excitement, all this wonder, haven’t we forgotten something? What about the users? What about the users experiencing the product? What about those learning to create? There are many users and we’re failing them all in ways we can prevent.
We in all the process.. forgot about what matters.. the users. Whilst we are caught up in this, those users cope. They learn the ‘way’ of processes and are forced into accepting experiences. They shout their frustrations in one room while most of us are in the other room having our minds blown by a process. This has to change, when that happens we can start to truly create experiences that are what users want, deserve and need. That isn’t created just for our headspace, our friends, our colleagues and bubble. That is inclusive and actually, enable those that use them.
WP of today is weighed down by history, by Trac legacy and a mindset of the ‘WP way’. This blinkers even the most enthusiastic, passionate contributor. You colour in the lines because there is just so much to do that it’s easier. The new ground seems non-existent. Everything feels like there’s already a solution, so why boundary push when there is no space to push into? There is too much to do, which clouds innovation and creative thought. Yet, there are glimmers…there are people coming fresh to this project and questioning the ‘WP way’. This is a seed of bravery.
The Gutenberg of today is a huge, daunting repo. Finding new ground seems impossible. Where do you start? Maintenance mounts up in vast towering stacks, overshadowing any space to create or experiment. But, like the seeds in WP, there is a light. There are people are showing the way. Gutenberg has created a foundation that is enabling people to explore in brave, exciting ways. There are plugins sprouting up with leaves of potential. Nimble, free to think ‘what if’ and play with the new toys available. This is the present but a path to the future.
I may have painted quite a bleak present but it isn’t untruly the space we’re in. There is hope. Nimble minds and free expressions are that hope. There are tools, often too many and not the right ones.. but there is a foundation, an environment that could if we are aware lead to incredible, exciting, brave growth.
The mindset really does have to be one of going back to the lab, to discover the paths and explore them. We need to myth bust the ‘WP way’ and look to what the future ways could be. We don’t grow as a project accepting what we know now as the only route forward. Creating a lab means creating a space for experimenting. A nurturing, supporting community that accepts not everything is fully baked. One that is ok seeing cookie dough and first pancakes. One that gives feedback not judgement. That has enough structure enough to encourage growth, but not so much it’s paralysed by hierarchy and process. A collective focused on what could be.
Our tools need to be rooted in play. Contributions should be grown through play not through wading through the process. It all just needs to be fun again. Applications like Glitch show a glimmer of what this could be. Space where experimentation, remixing is the mindset. As a project, we could learn so much from this. How do we make contribution fun again? How do we grow through play?
One little brave step was recently taken by the design team with the design experiments plugin. This, as shown here, doesn’t have to be just the individual, sometimes it’s scary to be brave alone. By being collectively brave you can start to really see what if. This plugin has a series of things either talked about in Slack conversations or in dusty Trac tickets, now made real. It’s designed to not be used in production, to always be experimental. No weight, no expectations but all the freedom to just see. Going back and forth in theory only gets you so far. There is something powerful in just trying. In doing. This type of plugin shows what can happen when some just try. When the conversation turns to action.
To get to the future one point needs to be underlined. We don’t get there by clinging to job titles or judging those that step between. Developers should be allowed to experiment in design, designers if they want to code. No matter what you want to do, an experiment should be given feedback (never judged) on its own merit, not on the background of the person. This is easier said than done but we’ve not got this far by drawing lines around roles and territorial mindset, intact whenever that happens we regress, where we limit.
The future can be incredibly bright but we get there by less closed groups, more open sharing. Fewer conversations and more ‘do’. We get there by letting anyone play in the sandbox and create castles.
Like many, I learnt to code by following the example of others, viewing the source and making connections. I remember starting to discover writing themes for WordPress and learning by the example of Kubrick. It was simple, open code that I could easily access and understand. I learnt by connecting the dots, finding the paths. When I learnt to design, the tools were simple. You just opened and used, there was no design system, framework or complex syncing. Countless people have learnt to work this way, you’re likely amongst them too. I wonder though if I was starting today would I have been able to learn so easily?
The flip side of this is that a system that enables this type of fast, rapid onboard benefits. A good, design system does that. A good process does that. We need that going forward.
How can you progress and learn when you do so from a bubble? It’s cosy certainly but this bubble thinking only stalls causes growth problems. It’s a basic lesson learnt but one we all too easily forget when we get caught up in the new. Within the bubble grows a state of acceptance.
The steep learning curve is seen as a rite of passage over a problem that needs to be fixed. The complicated language hurdle becomes the norm and blinked thinking is standard. It seems almost like the web is being split into lands with really high, difficult borders to scale, rather than the fluid universe of discovery it was meant to be. It’s bad enough for those of us that live in this state, meanwhile, users live in another universe completely, outside any bubble, out of mind.
I want to finish up today by sharing some of my own brave thoughts. I share these not as unique things only I think, human nature means others will also be thinking the same. I share them because after talking about being brave, it’s a good time to share.
The devices of tomorrow aren’t those of today. What we create for today isn’t going to be what we will create for tomorrow. We can guess, but we can’t really know. If you are limiting your experience to just one device, you also limit your mind to what you can create. Play comes in using different platforms, different devices. Explore, change up your phone. Start exploring what is coming up, make yourself aware of the changing space.
Similarly, the situations and use cases we create for today, aren’t those of tomorrow either. Looking to explorations in wearables and future thinking is where maybe we can start to see what could be. As creators, playing and exploring these is crucial to really grow into that future. Don’t focus on the new shiny of this year or the next. Look beyond what is coming up.
Figlab: future interfaces group, is an interdisciplinary research lab within the Human-Computer Interaction Institute at Carnegie Mellon University. This is just one of the many places exploring what the future of interaction could be. They have some pretty interesting explorations worth exploring. There is also a GitHub account for fig lab that has some OS goodies.
What if everything we thought we knew about interfaces today was wrong Experiments like this one show what could be.
The users of today aren’t those of tomorrow.
We can and should run usability tests but we have to also consider who is coming. Who are the upcoming markets, what are their needs? Who aren’t we serving today as an experience? This is where looking into how accessible or diverse our experience can be, matters. To grow as a platform, you need to look beyond those you serve today.
The creators of today aren’t those of tomorrow.
In this all, in all this overcomplexity and confusion, where are the future creators? How can someone learn to code? To design on the web? Where in the sea of this is a way for them to learn? Our processes aren’t inclusive, they have not only a barrier to learn but also a hurdle to access. You have to know where is the right information. They are processes of privilege. How can a web truly for everyone be created when the system to create isn’t inclusive?
When you have this disconnect and lack of diversity in those creating, you ensure a fast track to products that also aren’t inclusive. The bubble has created a system of privilege that applies not just to those making the product but actually making it.
It doesn’t matter who you are or what level you are, the next solution may be something you hold. Hierarchy, when focused on instead of creativity, limits our growth to discovery. As a project within WordPress we have to leave room for happy accidents and welcome everyone. Elitism is the death of projects. If we judge we will limit that growth and become the 1%.
The experience of today isn’t natural.
Users accept way too much than they should. We have formed mental models around how we interact with products, also as to how we create. Understanding how really humans work gets you to the point of being able to understand what is natural. Just like looking outside of the bubble, looking into psychology and neurology to really understand how humans’ work is essential to creating the future.
We only get to where we are going by putting users at the heart of everything. Perfect polished robots failed to take off as they were too perfect. Humans are imperfect. We have to understand that. We have to put users and their experience at the heart of everything. If we remove the human element, we remove the growth, we remove connection and we won’t grow.
The technology of today harms
To build a future it needs to enable, empower and break down barriers not create them. This ties in with the two previous points. Too much today is gamified to the point it harms. Sticky to the point it sucks humanity from those interacting.
There is so much good can come from technology, it just takes being brave to not follow the fastest path to clickbait. Experiences for good are the way forward as people aren’t stupid and cynicism is growing in those that interact.
The solution isn’t within WP.
The future lies outside. What is WordPress today won’t be WordPress tomorrow. The product you work on today, won’t be the one you work on tomorrow. Look to art, look to science.. look to science fiction. Look outside the daily work you do. Be open to all that the future could be.
Dream and think beyond the confines of what your experience is today. Bravery doesn’t come with limiting yourself to this reality. You get to the future by visualising it. By learning, by being open, what is WP can evolve. If it’s closed then it will wither and not be around for long. Evolution of technology is natural, we sometimes forget to look outside our bubble. Outside is where the good stuff is going on and how we truly create a platform for the future.
The legacy of our technology matters.
The future lies in less, not more. Recently the race for technology has seen an ignoring of the world around, this can’t continue and to truly create experiences that connect, empower and enable, they have to respect and not damage the space people inhabit.
What we create today is the rubbish of tomorrow, the toxic digital waste that will have to be cleared or lived around. We can do better, we can create with a mind that doesn’t focus within the microchip, but on the space the person interacting inhabits.
We can look outside the processor and ensure the footprint, the digital legacy isn’t one that forces people to retreat into screens to escape the broken world. That is just as good for people as it is for the environment they exist in.
These are brave thoughts about the future, about how we maybe can start to get there as a project within WordPress, as creators and as those that want to create a better future. Let’s think more about what if because that’s how we move forward.
You’ll never do a whole lot unless you’re brave enough to try.
When I was thinking about this, I wanted to create one just for this conference. It’s a luxury I was grateful for. I had no limits on what to speak about and that really was exciting. As I began writing this, I didn’t realise I’d be not only writing a talk but a promise to myself. You see, somewhere along the line I also forgot to be as brave as I was before. I stopped sharing my sketchbook. That was a lesson I learnt studying art and somewhere along the line, I unlearnt it. It all got a little too serious. It all became about work, about the release.. it all became too big. I stopped playing as much and I stopped if I am honest having as much fun as I was. In writing this talk I got to reflect, to remember and I was given a space to have some brave thoughts.
If I can leave you with one point, I would encourage you to take that first step. Write that blog post on an idea, sketch that thought, create that experiment… build up your time in your lab. I promise I am going to and I can’t wait to see what everyone does when we all are a little braver.
As 2019 begins and the noise of social networks rings in our ears, I can’t but help reflect on the state of communities online. Can anything be salvaged from this current state of noise? What can design bring to the table in enabling communities.
Back in 2013, I was lucky enough in May of that year to speak at Future of Web Design on ‘Beyond the noise of Social Networks‘. The noise and pressure felt intense back then, ironically it’s even more intense now but it feels we’ve all just reluctantly accepted this as the norm. Living in a constant state of reaction to tweets, pokes, dms and interruptions doesn’t get anything productive done, it’s not a natural state for any of us or one we thrive in.
Before moving to my current job, my focus for a long time was on designing and enabling niche communities to grow. I worked on a wide range of projects and each one bolstered my feeling that the connections within those were far closer than any social network. A community like that can be a support system and research resource for someone with a medical condition. They all had real connections in common and a safe space for people coming together.
A community is not a social network
There is this foundational confusion that a social network is a community. It ‘could’ be one but it rarely is. Whilst a community unites for the same reason, to say a social network does based on ‘connecting’ is a little flimsy a baseline to call something a community. In many ways they mask as a community and that’s where a lot of the problems come from.
Social networks won’t foster passion, commitment, or identity on a large scale. For that, you need to form relationships and gradually form the gravitational attraction between them that characterizes community.
Andy Oram ‘Social networks are not communities and other discussions from the Community Leadership Summit
This quote for me whilst a little older, still stands. In a lot of respects communities are about uniting and often social networks are almost the opposite, dividing. History is marked by people grouping together to do more than the single, isolated human can. It could be uniting to take down a large animal, or to overthrow a government.
Social networks are often about the individual. Their connections, their promotion. Interactions are at a distance, a casual like or thumbs up. Carefully curated plastic profiles tell a story that is often removed from the real person. Any connection is often not a true one, it’s half presences uniting with other unrealities.
The rise of Slack
Slack has risen up as a connector. It’s a step towards a community but I would argue it’s not one in itself. Community comes not just from a platform or application. What it has given is an opportunity for niche communities to form, this is something social networks promised but never delivered. The addition of apps to Slack also combines to try and take it beyond just communication. They don’t fill the void though and it’s still whilst a powerful tool not the right out of the box option.
Ownership of the community
I still believe strongly one aspect social networks that apps often fail to solve, is owning the content is key. The WordPress mission is ‘democratise publishing’, I feel a similar drive towards community tools. How can people be empowered to create the communities that people need? In this day of privacy concerns and the nature of communities often being sensitive, owning that content is crucial for trust to form.
I don’t feel there is as easy option that exists today. This was missing back in 2013 and I still feel projects like BuddyPress could be that, yet aren’t currently. That isn’t saying they won’t and I sincerely truly hope they do grow to meet that need.
The rise of collaborative communities
The need for a space to create together is a strong drive. Glitch is one shining example of a space that really works well. There are a lot of these collaborative spaces with some interesting, personal takes on what community looks like for their members. This is one area that really shows a path forward and has right now some of the more forward thinking explorations into design thinking being used to enable a community.
I don’t claim to have a single solution here. I’ve been thinking again lately about where design fits in providing an alternative to the dysfunctional social networks. Community isn’t something you can simply add design to and say it’s complete. Design thinking can be used to create a space and enable that community.
The future is beyond the noise of social networks. Niche communities to me still are even more so the way forward than they ever were. It’s about meaningful connections where the experience is focused and united. To get there exploration needs to start happening again and this is something I am really interested in doing this year.
This weekend I spoke at WordCamp Manchester and again feel privileged for every chance I get to have space for my voice. This isn’t a talk where I share my slides and notes though, this is a little more personal.
Speaking for me often seems something every part of me isn’t made for. This isn’t where I ask for sympathy though as I want to be clear there are many reasons why I do speak, one being every time I do it improves me. What do I mean though by being not made for speaking? I am Dyslexic and whilst that’s not in itself a reason to not speak, for me it manifests verbally at times with word retrieval being difficult. This happens more when stressed and standing on a stage in front of people is never stressful right?
Like many I also am by nature shy. If I know you then I am talkative but it’s not my default. I have spent many of my 43 years learning from people who aren’t and I am a good mimic. My wish to be in the shadows is perpetual though and my happy place is being unnoticed. I also have some hearing loss in my left ear. Whilst daily not an issue to me, this causes some difficulties when on stage with noise behind me or heavy accents asking questions in quiet voices high up in a dimly lit audience. I have at times totally mixed up what question was being asked and then ended up answering a different one. Little fact, around 1 in 6 people in the UK have some form of hearing loss, it is incredibly common, also that increases with age. Combining hearing complications with my under pressure brain’s stumbling to process complex language fast, can make for an interesting interpretation of any question.
I repeat though this isn’t a post asking for hugs and puppies. Every single person has their own story, their own experience and this is just mine. It’s easy to assume when you see a rehearsed speaker who they are and what they are experiencing. Different people have different motivations for speaking. Just like the swan, gracefully gliding on the top of the water, yet underneath all action below frantically paddling. You never see what goes on underneath the speaker’s surface you see.
About now you are probably wondering why I even speak. Why I stood in front of an audience yesterday and mentally reached for a word having to on spot swap for another. I found the new word and moved on. For anyone that this happens to every success is therapeutic. You prove to yourself survival and thriving. Those that know me will see when this happens and support by not pointing it out. The reality I have accepted over time is those that don’t know me, rarely notice, despite what my mind assumes. This single fact has given me confidence and along with both speaking and practicing speaking, I have learnt and grown in my coping mechanisms.
There are things that enable me to speak. Over time learning to appear to make eye content but not making it really was something opened up question sessions for me. If you look in-between the eyes it is easier. Rehearsing and reaching for words as I forget has given me a range of options to swap in. Similarly taking time with questions asked me, learning to repeat them back to those that asked and even asking for it to be said again, these add up to a great confidence practice. Dark mode for keynote has also been incredible for me. I make notes in my own ‘me-hand’ that makes sense for me and likely makes no sense for anyone, but allows me to have a support in speaking. I distill from full sentences as they would mean I’d be more likely to misread if had to lean on them.
Why I do this goes beyond the therapeutic, beyond the challenge and not accepting anything I feel or experience I can’t (stubborn is my natural state). I am driven to share my experience, like many. It’s a privilege to speak. I have been supported in doing this and that matters. Giving space to anyone to speak is something crucial, it’s how we get more voices. Over time I’ve realised nobody is really made for speaking. Speaking for me actually has benefits it doesn’t for others. It’s given me confidence, skills to communicate in large groups and made me realise I have things worth saying, that can be said by me. I am who I am today and can do what I do today because of speaking. It is exercise for me and I am growing stronger every talk.
Have you ever wondered what something is called within Gutenberg? This guide is meant to help by giving the names and the expected behaviour of some of the basic design elements. If you want to build blocks and extend Gutenberg, knowing what to use or not is important. This is meant as a starting point, not a full description of all design elements.
There are two toolbars:
The Editor toolbar: This controls document tools like undo and information. Also within this toolbar are preview, publishing and saved state.
The Block toolbar: This controls block specific behaviour, for example in a paragraph block bold/italic and adding a link. As a guide, place common settings that a user would want for every version of that block in the block toolbar.
These are also referred to as 'advanced settings' when linked from the block toolbar.
There are two settings:
Document: This gives you global settings for the entire document like visibility and reviewing. Think of this like your settings panel for your content.
Format: This is per block and changes depending on the block and if it even has settings. These differ from the toolbar as are secondary block settings, for example adding a CSS class (in most blocks) and doing styling that isn’t as common.
These come in 2 locations:
Document: These contain document settings such as switching display modes, position of toolbar. Anything that is not specific to a block or the document would go here, for example display modes or something like a spell check.
Block: When beside the block there are commonalities found in all blocks:
Hide Advanced Settings (if visible) or Show (if hidden)
Edit as HTML
Convert to Reusable Block
Convert to another Block and a list of those blocks.
As a guide you’d not be adding to these menus in a custom block. You’d ideally use something like the advanced settings here.
It's worth noting that insert is changing to add potentially. There are multiple ways to add a block in Gutenberg to content:
Toolbar (although this may be removed)
Above a block: a ‘+’ appears on hover
Below the block: a ‘+’ shows all the time to interact with
The library appears when you click to add and then you see all blocks available. You can also search for the block by name. Blocks are in sections both through tabs and in within each section there are categories.
Recent blocks also shows all the blocks a user has been using frequently.
You can view information about a block by clicking ‘i’. This contains helpful document information like number or words written.
I set myself a little holiday project this year, to consolidate and create a theme to use across a few of my sites. With this move I merged my two writing blogs into one and began a long needed update to my portfolio. I wanted to do this using Gutenberg and the Gutenberg theme as a base. The Gutenberg theme is based on _s, open source and a community project, so a great starting point.
Gutenberg for those who don’t know is the new publishing experience for WordPress. It’s a block based approach to creating content that focuses on an easier experience for every user.
One of the big drives for me wasn’t just that I am working on the project, focusing on the editor – although testing is always a strong motivation of mine. I was using Gutenberg already on this blog, I wanted to take it further. How much could be done just in Gutenberg with a simple theme style guide? How reduced could the theme go?
A bonus reason in doing this project, was that I could add to the Gutenberg theme. It’s worth saying that Gutenberg doesn’t need a specific theme to work. The Gutenberg theme is designed to showcase what a theme could be with Gutenberg. It’s an experiment into how close can both the front and back look and has the styling for blocks rolled in.
I wanted from the start to strip right back everything and then have a solid base to grow from. I knew I wanted a minimal theme and that the footprint should be as light as possible. I also want this coming year to learn more about performance optimising on the front end, so this is a good starting point. Where possible, as much styling and functionality was to come from Gutenberg, without adding in the theme. As far as it could be, this would be a pure CSS design.
I set myself some fairly strict boundaries. Firstly, I wanted to make sure this was released and live on the sites by the 29th December, this post was the final step. I wanted to use just one feature colour, that I haven’t before so picked the Pantone 2018 color of the year, Ultraviolet. I also wanted to have an off-white background to make it easier to read longer posts. Typography wise, I restricted myself to one font, in this case Roboto.
One of the big things I wanted to do was make as few changes as possible to the base of Gutenberg theme, to really make this as much just CSS as possible. This was fairly easy to do as the theme itself has styling for most blocks and as part of this exercise I got to commit some pull requests that added some additional styling.
I began sketching and this was what I came up with as a first version:
The following were the changes aside from colors and typorgaphy, that I made to the theme:
Social icon SVG menu: A good potential future block, but not one that exists today.
Removed menu and reduced header: I removed pretty much all the header and menu in the Gutenberg theme. I wanted this to come within the content so used a reusable block for this. Once Gutenberg has a menu block this can be changed to that, probably coming in the Customization focus.
Reduced footer: Again I wanted to use the social menu in the footer and remove as much there from the theme. In the Customization focus things like reusable layout blocks may become a reality, so this steps towards that.
Animation for link and text loading on page: These animations are subtle but they load gradually content. Gutenberg allows me to add a style to each block and using this I can gradually fade in a page’s content.
Distilled a lot of post meta: I only wanted to show the date for now.
What is up now will change over time and is very much a first step. I plan to iterate as I add content and Gutenberg nears release in WordPress 5.0. I now have a base to build up from and a great starting point. One of my 2018 goals is going to be to blog more, so it’s a great start to that goal.
Overall, it was a pretty smooth experience creating this theme and putting Gutenberg at the heart. I do know Gutenberg, so therefore the headstart was something I had. I also am ok with any rough edges at this point, there’s a lot of experimenting here and I have that luxury with it being my own sites. This is very much a work in progress but that’s a good thing as I can now take time iterating.
On the testing side, I have several issues I can report and some enhancements to suggest. Doing this reminded me how important using the products you are making is. When you are actually working with what you are creating, there are insights to be gained that when busy designing the product, you just don’t get.
For those of you that want to explore it, the theme can be found here with all my styling changes. The vanilla Gutenberg theme can be found here, and is a better starting point, pull requests and issues welcome.
Every designer at Automattic is writing a monthly design post, this month my post was about triage practice. For me the process is an integral part of being a designer. Triage for me is a constant part of my journey within Automattic and in the wider WordPress community. It continues to be really important to me as a designer, it keeps my feedback and testing muscles healthy.