• Theme resources

    I don’t know about you, but I find so many good resources around themes lately that I feel I am constantly juggling links and saving things in the best way. I wanted to solve that a bit as I prepared for a talk this week, so I created a GitHub repo and have begun filing a page with the links that I come back to.

    I chose to create a repo as my thinking was that others likely had links to share, and I wanted to be open to catching those by allowing people to add issues and even their own links. I have no big plans for this beyond it serves a useful purpose for myself and might, therefore, others. Things get lost in my bookmarks, so it’s great to surface them out of there.

    I’ve linked the resources to the top of this site as a guide because it’s going to be something I know I’m going to come back to.

  • The implications of set forced play spaces in work

    I was listening to the Post Status podcast this week where Cory Miller and David Bisset discussed creating time for play within work. I write this not thinking they were advocating for what I disagree with, but the podcast inspired me to share my perspective.

    Creating space for play absolutely resonates; we learn through play and grow as a child through it – play stages are a critical part of human development and even used in many therapeutic practices. However, I think aspects often get overlooked in the enthusiasm to create a space for play, those of cultural and wider inclusion. As a result, those spaces become exclusionary and sometimes daunting to participate in when the opposite was intended.

    A set time, a set space where everyone is designated to be social, can be problematic. First up, if you have a team across timezones, someone will be suffering either bleary-eyed morning, juggling child feeding times or needing sleep. Second, culturally being told to do things by your boss can impact heavily. Even if it’s fun, you might think there’s a performance measure aspect here. Depending on your language barriers, the activity also might be incredibly stressful.

    One approach to deal with time zones is to split the team or group into sub-teams to play. This is almost even worse at times. This likely sees certain people with some leads and others with none. It can make people feel they haven’t got time with some and if you regularly do playtime like this, it forces divides. I would strongly advise avoiding splitting people ever like this.

    Remote work enables people, so forcing a set time to do anything can remove some benefits. What if that person has a medical condition which remote work allows them to work around, and they have a flair for that hour of designated playtime? Sure, they can miss it, but they both might then feel guilt, and they missed out on bonding or, even worse, some communication shorthand that others gain through that activity.

    Another aspect to understand is what work means to many. Being able to play within work is a concept not all cultures or mindsets will find natural. If your team is diverse across timezones and types, you have to understand each person probably comes to play differently as an adult. Children are open to play; adults get more closed the older they get in many respects unless they practice it or are given space. This is shaped by their lived experiences, their type and the culture around them. You also need to have a space of trust to play; as a leader, you can assume trust where maybe others don’t feel it all the time.

    Our brains have different experiences of social play. Some might have been bullied when younger, so picking teams even is a trigger point for them; imagine how they might feel if a team picking happens and gets picked last. Or if they do badly in front of their team and now get memories of that happening when they were a child. What for some are incredible social experiences aren’t for others. This needs to be considered in whatever activity takes place. Give options for participation.

    Don’t get me wrong, I am not against play space or even designating and setting time for it for everyone. It can work in several situations very well. I actually think it should be a part of work constantly. My biggest point is that play space should become a space of exploring and also constant.

    One other aspect of this is that it needs to start slowly, be earnt. I honestly think if you can start with instantly it working, that’s incredible but rare. You have to probably start by setting some boundaries, which I know goes against the idea of true play. This is about safe trust-building though, here are some recommendations:

    • Allow everyone to set the time to work for them.
    • Set themes for exploring as a leader: this removes the worry from others. Mix in a combination of work and learning a new skill.
    • Allow space for simply sharing. This is far easier for many than play and gets them learning to trust. Always give alternatives for example just saying share a book you’ve read that month and if someone struggles to read every month – that’s a worry. By saying ‘share a book, film, piece of music or something you liked this month’ – suddenly that’s less stressful.
    • Create a devoted playspace where people can share things as they create async. This lets everyone have comfort and nobody gets put on the spot in a meeting. Sharing can be the start of play and is often overlooked as a starting point – it’s a key stage in play for chidren.
    • Encourage collaborative play but find ways as a leader to make it async. If you do this right you can even combine to increase communication across roles/areas.
    • Start using play formats in meetups/workshops and retros. By incorporating play thinking closely into work practices it says to everyone that play is part of working here and welcome.
    • Always set a start and end point if you set play topics. Open and close the designated play even if async.
    • Your experience as a leader or person that sets the play won’t be the true measure, so open all your senses to others.

    As people learn to trust, increased connections will be made, and likely self-organised play will happen. You should leave space for suggestions for play because that is when the magic happens when those playing start directing it.

    There are various types of play; lean into those. I don’t see play just as a set time to play an online game remotely. I like this definition to start exploring a bit more:

    “Play is a free activity standing quite consciously outside ‘ordinary’ life as being ‘not serious,’ but at the same time absorbing the player intensely and utterly. It is an activity connected with no material interest, and no profit can be gained by it. It proceeds within its own proper boundaries of time and space according to fixed rules and in an orderly manner.”

    Johan Huizinga

    Play is magic; the effects of someone realising they can safely play within work, on their terms, will be felt not only in how much better they will work but also in their improved relationships and ideas. However, it’s not something instant. The space also needs curating, tending and nurturing. Play has a lot of benefits, so it’s worth taking those considerations.

  • People see content not terms

    Naming can get very complicated. Often labels are put on things, and heated views are delivered around what should or shouldn’t be called. When it comes down to it, what is essential is to observe how someone will use the experience, what they will think of and then name from there. Most of the naming is the best guess, so iterations should happen. All of that is why for me when talking about the editing interface in WordPress, patterns, templates, blocks – it’s all just content – because to most people; it will be.

    I am not referring to the structure or development, the architecture here. The reference is about pure usability. As a user, the case is that everything is content – it’s all something to be added, styled and published. As product creators, we might have words and frameworks to add complexity to that process, but we can’t deny that interaction. The customer doesn’t have those terms, and that’s ok; they call it content, and we need to recognise that.

    Imagine someone sitting down to create a post reasonably early into their discovery of WordPress. They probably don’t call it that. They likely say they are adding content or writing. Even the term ‘post’ is one you gain much later in your WordPress journey. They add a header, add an image – probably along the way, if asked, they’d refer to this as adding content even. They likely don’t make a distinction between hierarchy, between types – it’s all just what they are creating, and that is fine; they don’t have to see it or know about it. If we expose that to them, it will confuse them and get in the way. Maybe they can discover it at some point, but the start of the journey isn’t the place for that.

    I am not suggesting we drop all the excellent progress made in understanding complexities or nuances. However, I suggest we focus on what matters a little more and less on the frameworks and complexities. That we stop, observe what is going on with the product. See that someone doesn’t care what we are calling things, see how they are using them. That we perhaps are open to changing our terms, making sure we are more consistent and in line with how people are using the experience. Being consistent means being inclusive, thinking about how those terms translate also.

    If we do this, we might create experiences that have a lot more impact, but we might also learn the words we were caught up on were wrong and confused, got in the way of the experience. When we do this, we are being led by the experience, by those experiencing it.

  • Patterns empower

    One of the most frequent things someone says when creating something using WordPress is I ‘want it like this’. They look at a site and want something, but then they are stuck. The ‘how’ seems far, and the chasm across implementation is vast. Creating is just too complex, and often the end result is one of those cake shows where the end result is nothing like what the intended caterpillar cake was at the start. Patterns unlock the magic of ‘making it like that for so many more. That’s empowering and something incredibly significant in the shift of usability.

    That first paragraph sounds quite grand, but honestly, something is compelling in the concept of patterns. Blocks are great, don’t get me wrong. However, they are granular. Granules are excellent, but you don’t want to pick up each grain of sugar; you want a sugar lump or a bag of sugar. I am a little flippant in illustrating the point of how granularity isn’t always best.

    Blocks also are the way we create from a code view, not typically how someone thinks of a design. When someone thinks of a design, who isn’t a designer, they tend to think of it more as a whole or at least in larger sections. They don’t break it down into tiny details. They want ‘that’, and ‘that’ is typically a pretty large section copied over.

    Those of us that use the editor a lot presume that finding and combining blocks is a fairly low friction task. It’s actually not. There are so many points of choice and doubt along the way. So many places where you have to feel trust, that you know what does. Even simple forms like combining 2 blocks often aren’t something unless given a tutorial many might without time to explore consider. That’s also a point here, we have had time to learn the space, grow used to it. Many don’t and shouldn’t have time. They are using it as a tool to create and it needs to function to earn.

    Patterns are a boost to productivity. You can lay your content out in patterns, then add it, curate and go. That’s a fantastic way to start thinking about your site itself. You could bring more variety to your content and even unlock the power of really impressive art direction in your content that before felt unachievable unless you had access to someone to create for you. As everything is a block, it’s also straightforward to dive into the pattern and start using it.

    One aspect of patterns that isn’t maybe always considered is their portability. Because they are made of blocks, you can just like blocks, copy them and take them anywhere you want. This means you can share them across sites with a simple copy and paste. How cool is that?

    Patterns truly are empowering, and I’d go as far as to say I think they will be potentially more impactful for users than blocks. A block is excellent, but the true power comes when you combine blocks. If you then have that all in one portable package of a pattern, curated with care by someone – that’s true content empowerment. That’s the ability to ‘make it like this’ with a browse in a directory and adding to your editor. That’s the power of patterns.

  • Seek the sketching state

    Sketching state is where everyone in product creation is collaborating enough and sharing enough that sketches work. All too often, spending lengthy time coming up with a complete prototype can be far too time-consuming. Passing pixel precision backwards and forth limits the flow and stops that spark of creativity. However, it’s not a state that doesn’t need evolving as a team and careful tending to as a designer.

    I want to be clear; there is a place for almost every form of presentation you can think of for a design concept. I am not talking about stopping using whatever works for you. However, getting to a position where you can share early, sketch often and be open about those early ideas – that’s gold for any creative. It’s not something instantly achieve, though and takes work collectively.

    I find myself when joining a team testing the waters with how ‘sketch’ I can go. This is an excellent thing to do; it allows me to see where communication is, where collaboration needs to grow. By doing this type of testing, I can refine and adjust my communication, learn where I need to improve and what communication style works for my joining team. One size never fits all when delivering design – that’s why we have a toolkit. I also use sketching as a tool to test during later team development as we grow.

    I also think it’s important to frame that sketch doesn’t mean half baked; you still should have a solid idea to share, it should be at least complete as an idea sentence, your visual though might be very raw. Sketching is valuable short-hand communication and key as the product grows and iterations happen rapidly. I encourage not just designers to talk in sketches if the space is comfortable for that – it takes trust across roles for that, though, and safety has to be at its peak for everyone.

    Design is as much about judging the way you can deliver the message as delivering at times. I don’t get it right all the time; nobody does. It helps if you have a range of methods to try. I haven’t found one process that works for everyone, although you might have different outcomes. My processes are chameleons, but the one that consistently fails are words alone.

    Similarly, talking in flat files passed as complete packs to make, that never works – signoffs lead to silos all too often, and frequent conversations need to happen as work is going on. The design needs to be iterative and respond to the actual product work, not remain stuck on ice. This is actually where having a design system that can prototype sketch comes in useful.

    Being in a sketching state as a team means a high level of collaboration; it’s a strong flow of trust and space for each member to bring ideas openly. This is powerful to create in and one personally I seek constantly to create within.

  • Opening your project for contributions

    So you want to open source your project for others to contribute? That’s great, but where do you start? With a few things to consider, you can start on the right path from the start with contributions and avoid some of the common first step problems. This guide is a minimal viable opener if you will – a start.

    Have a welcome

    If you think of the project as your house, welcoming someone in is great. Even better is the tradition of a welcome mat and then sitting someone down, making them feel at home and give them a cup of tea. Your project version of that is solid documentation (no matter where it’s hosted). This sets the tone of your project, the voice many will hear before they even start contributing to it.

    Provide signposts to contribution

    If you want contributions, be sure to show how and where they are wanted. It’s one thing to say ‘all contributions are welcome’, but that’s open-source theatre because honestly, it’s likely not all are in every area as welcome as others. There are always more areas needed than some. Highlight these and make sure someone gets off to contribution success from the start.

    Document everything possible

    I’ve hinted at this with my previous points around a welcome and signpost, but you also need to have documented everything possible. From code to vision and everything possible – ensure there is something written about it if possible. You might want to have documentation as a contribution, but if that contributor has to guess what you were thinking, that will not be someone who will stay around a long time. Give everyone a start with some basic documentation.

    Show the small ways

    By highlighting not just the big things to contribute to, but the little wins – someone can dip in and support right away. Show how to test, report a bug (using templates to make easier reporting is fantastic) and show the level of commitment of fixes. If something requires a certain skill or understanding, clearly mark that also – it helps people focus where they are going to be the most effective.

    Say thank you

    The biggest thing you can do to someone contributing is to say thank you no matter what size that contribution is. Recognise that contribution, say thank you. If someone takes the time to contribute, make sure you engage with them. You wanted them to, so don’t leave them contributing without interacting. That’s a lost contributor and one that will rapidly find another project.

    Include and recognise contributions

    Opening your project to contributions isn’t a checkbox. It’s not something to do if you genuinely don’t want to accept and merge in contributions. Otherwise, it’s performance, not actual, and you are unfair to people who try and contribute.

    Beyond including, recognise those contributions. If you have a release, put those contributors are in front of it, celebrate them. They have helped you make what it is; you wouldn’t be there without them.

    Be open about roadmaps and releases

    If you have contributors pretty soon, you need to be open about plans you have for your project, goals and releases. I believe you should have at least a project roadmap table somewhere—ideally, open project boards and a roadmap. I like the way Github do theirs.

    Opening your project up can be incredibly rewarding, but do it respectfully and then who knows what incredible contributors will join you on the adventure.

  • Theme creation is now easier

    The way that themes have evolved within WordPress has made creating them easier. That feels like a bold statement, but it’s true. Themes have been on quite a journey from their origins of simple files through to complex compilers, frameworks and now have come back almost full circle with more levels, options for creation and simplicity.

    History

    Before considering how easy something is or not, it’s essential to look at how hard it was and its situation in context. Like many, I’ve been around themes for quite a long time. Those of us that have been, worked around issues that we felt got better in each release. What we thought was getting easy often was us getting further from a starting state, not the process itself. The ‘WP way’ was said half as a joke, mainly as a reality of the acceptance you had to do things a particular way to workaround.

    Over time, things got more complex, and everyone searched for their solution. Some of us went on a process journey, working on _s and other skeletons, even generators thinking those held the answer – I was one of those. Others adopted frameworks, which was a natural and right choice for many. It made business sense and often brought ease, but it also meant being fixed into an ecosystem.

    The creators of themes passed on the message of accepting the problems because it was at that point all anyone knew, the ‘WP way’. Designers moved to other areas of the project, which was great for those areas but left themes with a few brave souls keeping the fires going. I at that point, also moved to the work on the editor, so I understand why others left themes. It all just became ‘the same’, too complex and limiting. Between the race for options in frameworks and how you had to work constantly around WP, something needed to change foundationally.

    It’s worth noting many of those that moved to the editor had themes in their heart, their roots. Theme creation was a process that they knew needed soothing, and that is where we move to the now and change.

    Change

    The world is different now. The editor is a thing. Modern web development has progressed, and even how we consider things like viewports, scaling of fonts has changed. Progress is incredible; it is as it also should be. Development, technology wasn’t ever meant to stay still and never has historically. Open source projects as they grow can, unfortunately, tend to become a bit like a huge ship, which means their technology becomes more challenging to turn around a corner.

    I used the term theme creation because I honestly think we should start using that over theme developer. There are now levels of creation open that aren’t just making a theme:

    • Create using patterns and design tools.
    • Create using patterns and global styling.
    • Create using patterns, templates and global styling.
    • Create using a theme you create.

    That’s a lot of options and even more, combinations are possible, and only one I listed of those requires you potentially open a code editor. Even then, you might only do that to copy and paste in what you create within the site editor. Themes are now open again and that couldn’t be more exciting for someone like me that felt it was closing, losing the creativity that once drew me to the form.

    Future

    I hope that we are setting up for themes to have new life in all of this, and I am pretty sure that’s the case. I am so excited to see what creators will make with the new tools – what I can make and learn.

    I can’t judge today’s development processes with my mindset that I learned Java all those decades ago or how excited I was about the new PHP language when it appeared. It was a different time. I learnt jQuery because told javaScript wasn’t necessary, which in hindsight, was probably not the best advice. 

    What we can take from this is things change, languages and processes evolve. It happens in development, and it happens in design. I have to learn new things, and honestly, sometimes in my mid-40s, it’s not the easiest thing, but there’s this core belief in me that technology gets better and to trust in the evolution of development, of open source. I also recall how I’ve never stopped learning throughout my life and certainly am not going to now.

    Outside of myself, those coming to the project now to create a theme don’t know the past. Should they? Well, maybe, but also probably not unless they need to learn some history. I don’t need to know the history of most applications to use. New people to the project bring new perspectives and stories; these shape the project – that is, after all, the foundation of open source.

    The new things today stand on the shoulders of the past, exist because of them. That’s great, and those of us that have been around for a while have mentoring to give and so much experience to offer those joining the project.

    Will themes be different? Yes, they likely won’t be what we call themes today. However, there will always be a place for styling your content and, saving that, sharing. There is also now a scale for that, which opens up the possibility to so many.

  • Designers grow in open source

    When design is mentioned in open source, it’s often as a scarce resource, one yearned for or maybe hasn’t had an easy time. I think this might be problematic and needs changing. Designers can use open source projects as a growth opportunity and learn in a space that is accessible. I would go as far as saying it would benefit every designer from being in that space.

    Designers need open source projects just as much as those projects need them. These projects have the growth opportunities many designers crave and need to develop their portfolios and prospects. They can provide ground for a budding new designer, a way to shift from one focused discipline of design to another.

    Finding a junior role in design right now is not the easiest thing; it’s even more complicated if you live in a location that’s not a city or country that’s not where the most prominent companies are. Remote works, but that is often meaning a lot fewer junior roles – a problem in itself.

    Open source projects allow a designer to often learn by doing, really fill their portfolio with meaningful examples and often without the hurdle of interviews that might not even be in their language. It likely even has onboarding in multiple languages or contributions days (even remote) if it’s a long-standing project. A newer designer can work alongside seasoned designers, growing in skills through observing and collaborating. That’s a powerful gift provided freely within open source projects.

    A designer in open source gets on the ground practice in feedback processing. They are constantly the advocate for the user and learn to collaborate with other roles by doing. They are often also opening up to exploring far more areas than they might in their daily roles to see where they want to grow, even where they need to develop. Teamwork is a crucial part of any open source contribution, so that’s an essential skill taught, along with remote collaboration.

    Should you want to, you can move into operational roles such as team rep or lead. You can even look to lead releases: something beneficial for any designer looking to explore that type of role as a career direction. The types of design being offered are also incredibly varied in these projects, from product, visual through to marketing and much more.

    The time has come for us to change our perspective on open source and not focus on highlighting how much we need designers, but show what the designer can get from working in open source. Most projects are focused on inclusion efforts and trying to create better projects, so the time couldn’t be better to join. You also don’t just have to stick with the big ones you might have heard. You can move around projects, go where you want. Perhaps there is a tool or resource you use that could do with your help; that’s actually how many of the more significant open source projects evolved. Open source has grown me as a designer and it can grow you.

  • The importance of testing early and often

    This week saw the release of WordPress 5.8 ‘Tatum’. It’s a huge milestone on the full site editing journey, the new WordPress experience’s grand adventure. With every release comes a pause, a moment to reflect, yet it’s important to consider testing continually.

    We all create this experience together by testing and finding the problems, the edges, collectively. That’s by writing posts, creating themes, building plugins and shaking the code. Boundaries are found by pushing them, not by observing them from afar. Calls for testing often feel tied to release points; I think seeing them as daily, weekly practice is important. They also are trying to replicate real; nothing can truly take the place of using frequently.

    When someone talks about testing, it often can feel epic, hard to make time for or a gigantic mountain you have no idea how to climb. Testing, though, is simply often using. That’s a large part of my motivation for creating this site, learning how the editor provides for themes and exploring. Most times, as I venture, I will find bugs, create issues and report things. I am testing by doing, reporting by a discovery – that’s one of the most useful forms of testing anyone can do. You don’t get more real-world than this type of testing.

    I would encourage everyone who has an interest in this space to challenge themselves to use the editor more, if they don’t want to make a theme or a plugin, write more, perhaps learn to create a pattern or even see how far you can get using trying on other’s full site editing themes. Make it a weekly habit to try something new in the space. A new theme, a new plugin, a new way of creating using the design tools, perhaps using a different core block you’ve not before. Each time you do this, you’ll likely find hitches or bugs, and there’s a whole amazing group of people ready, willing and able to fix those, so don’t forget to report those issues.

  • Technical words matter

    Words matter; we put labels on things, we put labels on each other. Those labels lead to judgements. The ways we judge what capability someone has or hasn’t in something technical only tend to lead to harm, I’ve found. It’s a way to limit before you even know someone, and that’s one way to block ourselves rapidly from a potentially beneficial experience.

    This tweet inspired this post:

    https://twitter.com/joshsimmons/status/1417694331532570624

    I’m a designer who can code, hardly a rare creature. However, I’ve seen so many times throughout my career where labels of non-technical were attached to me and boundaries were drawn with verbal chalk where I shouldn’t go. Anyone around any time in the software industry might have more than one discipline: designer/writer, design/development, business/systems. There are so many potential variations because you gather exciting knowledge. That is what makes everyone more valuable as they travel their career.

    The most significant impact of labelling wasn’t just limiting my worth because it did limit my value in my role. What it did was also end up me mirroring that behaviour. That’s a part of human nature; this type of role dividing is infectious. You are limiting resources, so someone will clutch to the little they have because we are human. I was feeling threatened and devalued, so I responded from that place and mental state. It’s a cycle that you learn and then take to the next role – it goes around and around. It’s a cycle we, a product making industry, have to stop.

    By using that label, you impact that moment but also future moments. There is, for example, psychological proof this happens when using the term bully to someone or labelling someone’s mental diagnosis. It’s why incredible care is taken before confirming the diagnosis, which can be a relief to many but, when wrong, a dangerous situation. Limiting someone in this way is potentially dangerous because if you say to someone they aren’t technical, they might assume that is always the case and never reach their potential. Historically, people were told you could be artistic or scientific, left or right brain; women can’t code. As someone that grew up in an age where that happened (it’s not that distant), experiencing that, anything we can do not to repeat that I welcome. Collectively moving beyond this isn’t always easy as it’s ingrained, but it’s gratifying to do so.

    Another part of this cycle that’s also just toxic is the resume and background boasting. Nobody should have to prove what they have done to be heard. It means you end up falling into the trap of proclaiming your ‘technical’ or proving. This limits just to the role of development, ruling out other technical backgrounds, and that’s a massive part of this. Technical isn’t and never was just about code. This myth of the divide, the gatekeeping, the ‘us’, and ‘them’ isn’t your product because every person goes into it.

    I’ve seen this the other way around, too; I worked a long time ago in development roles and was told ‘just technical’, so I couldn’t comment on the experience. That discounted my background – again, words matter, and it wasn’t using my total value. No matter which angle you come at this from, it hurts. Most of the reactions you see are from hurt people who have learnt that hurt because words matter.

    Often you see in a space where this happens; walls go up around the disciplines. You will see increased gatekeeping, process creation can often escalate, and people frequently across the company will be on high alert to prove themselves. The reaction you see is a symptom of people hurt; they are wounded, not united. It just took language – language is that powerful. This space is ripe for other us v them behaviours. All they need is that one fertile ground of divide, suspicion of the other, and you instantly have combative thoughts in your team, and inclusion is more brutal to nurture from that point.

    If you take it from a business perspective, it makes no sense to have every skill someone can use. You hire someone for being the incredible person they are, not to use a small percentage. Similarly, more robust products come from allowing more disciplines equal input. I’ve seen remarkable changes come every time this opening; this welcoming approach to creation is at heart. Amazing things happen when nobody feels they have to prove themselves or each decision is a round of combative discussion where proof has to be seen of validity to join in. You don’t want to block any possible revenue stream as a business, so why stop creation streams inside your production process?

    Perhaps the next time you go to use the word ‘non-technical’ to describe someone or ‘non-coder’ and even ‘non-developer’, pause. Do you even need to label? What is that doing to them? Does it help move that conversation on? Are you doing it because you’ve learnt it? Am I saying it because someone once told me that? Perhaps leave the label to the side no matter what role you might be labelling and see what a difference it makes to how you feel – I know I’m going to try that for a while to see how it fits. None of us is perfect, and we all do this, so we need to change our mental models collectively.