Posted on

Upsells, Barriers, and the End/Beginning of the Quality $free Themes Era

The WordPress.org theme directory is becoming little more than a crippleware distributor. I suppose it was inevitable given its reach, which can be worth $1,000s/month for theme authors.

Justin Tadlock via Twitter

As I think back on that tweet from 2019, I realize how unfair it was to refer to the themes coming into the directory as “crippleware.” At the time, I was a part of the Themes Team (formerly the Theme Review Team). However, there were real cases of crippleware submitted to the directory when I wrote that.

To define crippleware: some themes blocked core WordPress features and made them available via the “pro” versions. It was one of the more blatant abuses of the free themes directory I had seen for a profit.

However, the term does not represent the majority of themes submitted. Most of what we see today are “lite” themes. Some of them are well-designed themes that provide value to end-users at no cost. Others are stripped-down versions of what you would typically see from a starter theme. While they are fully functional — the Themes Team’s rules have been strict on this requirement — the real value of the theme is in the upsell.

This is not the start of an anti-commercial theme rant. When WordPress developers and agencies are successful, it benefits the whole ecosystem. But, how do we balance that with providing value — which is subjective, I know — to the free theme directory? How do we transition the theme directory to something flowing with more artistic or even experimental ideas?

Guidelines and Stumbling Blocks

Matt Mullenweg, WordPress co-founder and project lead, posted the following on the Post Status Slack two weeks ago:

The .org theme directory is particularly bad when you compare it to any half-decent commercial theme marketing page, or the designs available on other site building services or Themeforest directories. The .org theme directory rules and update mechanism have driven out creative contributions, it’s largely crowded out by upsell motived contributions.

There is a lot to unpack in his statement. I agree with most of it. The Themes Team agrees with at least some of it. However, its members lack direct control over the system outside of the guidelines.

“I actually agree with this in a sense,” said Themes Team rep William Patton. “Creativity has not prospered in the directory, and I think a large part of it is the barrier of entry. ‘Don’t do bad things’ is the overarching guideline for the theme directory, but that can be viewed very subjectively. If it were the only guideline we would see a lot of things that might not be best suited here. If we want to encourage creativity then more freedom to express it would likely be a good way to start bringing it back. However, it can be hard to know where the line should be placed.”

The team sometimes gets pulled in two different directions. When the project lead asks for things to be more open, many members rally around that idea. On the other hand, the call for stricter accessibility requirements, for example, are popular with others in the community. It is a choice between two ends of the spectrum that are tough to pull together as the gatekeepers to the official directory.

“Why couldn’t it be more like the plugin directory?” asked Mullenweg. “That has all the same potential issues and has been working pretty well. I’d like it to work just like the plugin directory, with direct access for authors, and most reviews being post-review vs. pre-review.”

The Themes Team is not against the idea. More than anything, they just need the help to make any significant change.

“Having the themes directory work like the plugins directory would be great!” said Themes Team rep Ari Stathopoulos. “And, in fact, it’s something we’ve all been asking for years, but there are many technical challenges because they are built fundamentally differently. Plugin authors have access to their plugin’s SVN while themes don’t. Theme reviews are public while plugin reviews are private and closed. There would need to be lots of changes in systems and meta. Not to mention that, as far as I know, plugins don’t do post-reviews, they do pre-reviews the first time a plugin is uploaded and post-reviews for updates (which is exactly what happens in themes too).”

The team has created tickets, asked for help, and have generally awaited a champion to push innovative ideas — or any ideas — forward. Seven-year-old ticket to support the standard readme files available to plugins? No takers as of yet. Allowing block-based themes to be uploaded? Maybe we can make that happen sometime soon.

The guidelines are likely less crippling than the outdated Trac review system, uploading ZIP files for updates (which Mullenweg mentioned), the limitation of a style.css header for the theme description, and the lackluster theme previewer.

WordPress.org theme review Trac system.
Theme review system on Trac.

For the most part, nearly every guideline has been put in place in hindsight. The team finds consistent abuse or issues and course-corrects.

“I don’t think that Matt’s idea of a creative theme is a theme that is not secure or not compatible with GPL,” said team repo Carolina Nymark. “Creativity is not limited by being asked to sanitize options. It is not limited by making sure that your theme can be translated. If the reviewers saw creative, beautiful themes that lacked in some other aspect like basic accessibility, then the team could help explain to the theme author what kind of changes are necessary. But that is not the kind of themes that are being submitted.”

Financial Incentive

In the mid-2000s, the average theme developer could get away with building an entire theme on a lazy weekend afternoon. WordPress was far less complicated. Theme development was not a race to the bottom, bundling every feature imaginable.

Today, we live in the era of the multi-purpose theme. To soar to the top of the popular list, most themes need to handle everything from being the online face of a pizza restaurant to masonry grids for artist portfolios. They also either need good luck, name recognition, or good marketing. That is the reality for the average theme developers trying to make a name for themselves.

It makes for boring themes in a free theme directory. If the theme author has any financial motivation behind creating a WordPress theme, they need to bundle the nicer features into a paid package.

As Eric Karkovack wrote in his piece for Speckyboy, Are High-Quality Free WordPress Themes a Thing of the Past?, “Money changed the equation.”

There is not much incentive to push a free theme out to the directory just for fun. Most themers are spending a month or more of their time in today’s ecosystem to build a theme. The days of the weekend-afternoon project seem all but gone.

Even releasing a theme to give back can often be a letdown. There is little chance of any name recognition as the developer’s creation is swamped by the hordes of lite themes in control of the directory. There is no way for unknown players to get any exposure through the directory except in the brief moments their theme lands in the latest themes list. It is that one make-or-break moment that could potentially help best the algorithm and slip into the nearly unattainable popular list.

In comparison to Themeforest, the WordPress.org directory is lacking. Themeforest is inviting to users because it provides the backend tools for theme authors to market their themes. They can load up custom demos, provide screenshots, use a modern categorization system, and provide all sorts of extra data to end-users. They’re in the business of selling a product to users.

Screenshot of the Themeforest WordPress themes page.
WordPress themes on ThemeForest

While WordPress.org may be free, it should still be selling the promise of a beautiful website to its users. I have always said it, the themes available on WordPress.org are the face of WordPress.

Users deserve better. Theme authors deserve better tools to make it happen.

Even with better tools and a better-designed directory in place, there is no guarantee of an uptick of creative contributions or a better overall balance that keeps pure upsells in check.

“I think that due to the reach a theme or plugin that becomes popular quickly commands, monetization is a necessity to be able to properly ‘support’ such an endeavor,” said Joost de Valk, CEO of Yoast, in response to Mullenweg’s statement on Post Stats. “I think the community also ‘demands’ a certain stability and a certain level of support that is simply unfeasible to expect from any non paid contributor. Because WordPress.org has no way of doing that monetization ‘on platform,’ this is what you end up with.”

He also argued that something akin to an app store would make things like the “balkanization from non-G-based site builders” less attractive to theme authors. Such a store has little or no chance of becoming a reality.

“I think we first need to agree on what the theme directory should be,” he said. “We need a ‘mission statement,’ of sorts. And I think we probably need less control than we currently have, be much more like the plugin directory. But if we have a vision of what it should be, then we could work towards that.”

There is an opportunity to turn things around. Full Site Editing will leave ample room for releasing creative, fully-featured themes with upsells. There is plenty of reason to be excited about pattern design and template packs, better value-adds for theme authors who want to upsell. The problem is going to be getting authors to abandon traditional themes and explore new terrain.

Changes Are Coming, Maybe, Hopefully

Popular themes list on WordPress.org.
Popular listing on the WordPress theme directory.

For some, this is a song and dance they already know the lyrics and steps to. It is a years-long conversation that has netted little in return.

However, the WordPress.org theme directory may be forced to change one way or another. Block-based themes are not arriving in some distant future; they are knocking at the door. Full Site Editing is slated to land in WordPress 5.8 this June.

With this change, the WordPress.org theme directory needs to be prepared. Even with a move today, it will be a mad scramble to get systems ready in a handful of months. If waiting for the last minute, it is just asking for chaos. Block-based themes should already be allowed to be uploaded, for example.

As we saw earlier this week, Automattic launched its Blank Canvas theme. It is designed to work on single-page websites. It does not support commenting out of the box, which is a requirement for inclusion into the official directory.

Block-based themes will forever change the system. In the past, traditional themes needed to cover all their bases, integrating with every front-end feature of WordPress. In the future, that is not necessarily the case. Because everything will be built from blocks and users will have direct access to customize those blocks, a theme has no need to cover everything. The user can add and remove features at their leisure. The review guidelines need to be molded for this future.

Full Site Editing almost seems purpose-built for outside-the-box theme designers. Whether it is a simple, one-page wedding invitation or an author’s book landing page, there are more possibilities upcoming than there ever were in the past. And, these things will be far easier to build on the theme-design side of things. It will remove a lot of burden from developers and from the Themes Team during reviews.

“Regarding the FSE themes: to be honest all my hopes are there,” said Stathopoulos. “They are very different, and it’s a fresh start for the repository. New theme paradigm, a different set of rules (with of course some overlap for basic things), and a new way of doing things and thinking about themes. However, if they are presented in the same way in the same repo we have now, then nothing will change. the theme repo needs to change, and there’s no way around that. But that’s a decision that will have to be made from the WordPress leadership and implemented by meta.”

As always, I remain optimistic about the future of WordPress themes, hoping for the ushering in of a new era. I get the sense that the Themes Team shares some of that enthusiasm, at least cautiously so. More than anything, they need the community, particularly theme authors, to chip in and shape that vision of what the WordPress theme directory should be.

Perhaps today, the stars are nearing alignment. Mullenweg plans to chat with the team and gather feedback in the coming weeks.

Posted on

Carrd-Like Theme Experiment Provides a Glimpse Into the Future of Theming

Front page template in the site editor for a Carrd-like layout.
Carrd-like theme front page template.

It is no secret that I think the future of theming with WordPress is bright, that the Gutenberg project will eventually pay off. As a former full-time theme developer, I lived through the years where there were no standards for how to build certain features. It was much like the Wild West. There were vast, unexplored territories. Each themer was setting off to find gold with the latest tricks and techniques they had learned.

One of the reasons I remain a fanboy of the Gutenberg project is because of experiments like the Two Column Landing Page theme (yes, that’s literally the theme name) that Kjell Reigstad put together in less than an hour. It is a Carrd-like layout. It is a simple one-page theme that is essentially an “about me” page. Under the hood, it required no custom framework or non-standard options. It simply utilized existing tools from WordPress and Gutenberg.

Two Column Landing Page is an unfinished product. Technically, it is a pull request that has yet to be officially merged into the WordPress theme experiments repository. Automattic Theme Wrangler Ian Stewart passed a Carrd demo link along, and Reigstad pieced together a block-based version for WordPress.

The theme was easy to customize via the site editor, which continually improves with each release of Gutenberg (9.2 had some nice improvements with its template switcher).

Customized version of the Carrd-like theme front page template.
Customized theme front page.

For anyone who wants to give the theme a spin, they will need to grab the two-column-landing-page theme folder from the try/two-col-landing-page branch of the theme experiments repository. Enabling full-site editing within the Gutenberg plugin is also a requirement.

Why This Theme Is the Future

This Cardd-like theme is special not because it is anything extraordinary from a front-end design standpoint. It is special because it showcases how simple WordPress theming can be.

Theme authors will continue to build and experiment with old and new ideas. It will simply be much less hassle to do so. With traditional theming, developers who wanted to achieve this same Carrd-like layout for the front page of the site would have needed to build several customizer options and often provide extensive instructions on how to piece it together. When full-site editing finally lands in core, themers will be able to define a single template with predefined blocks.

No hooking into the customizer.

No need to register a database option.

No need to register a form field.

No need to sanitize user input for security.

No conditional checks before outputting front-end content.

WordPress will handle all these bits. If theme authors are not excited about this, they have not been paying attention. Now is the time to start.

This has been the problem with theme “design” over the years. More and more, it has become a business of learning relatively advanced PHP just to build out basic options. Because WordPress fell so far behind alternative solutions, far too much responsibility was placed onto the shoulders of theme developers. They were doing less and less design work and an increasing amount of programming. They were forced to build custom solutions to push past the shortcomings of WordPress.

Full-site editing is flipping the switch. It is transitioning toward a design framework that simplifies the process of building themes.

With block-based themes and the site editor, theme authors can simply define an HTML template with blocks. The user can then customize it how they like via the site editor.

To non-developers, it is hard to explain how revolutionary it is to take this step back from programming and a step toward designing. Themes are getting put into their proper place. This Carrd-like layout may be simple. However, with traditional theming, it would have been massively more complex.

The Two Column Landing Page theme supports other views, such as the posts page, single posts, and more. However, it should not have to. The future of theming should mean that the theme itself could be nothing more than a front-page.html file — the template that controls the front page output — and nothing more.

This means that the Themes Team, the gatekeepers to the official theme directory, may need to loosen the reins a bit. While the team currently allows experimental block-based themes, guidelines in the new era will need to be scaled back to the point that they are almost nonexistent if we want to see an explosion of artistry in the theme directory. Many of those rules were put into place because of the limitations of the system. When full-site editing lands in core and developers are building themes from blocks, many of the rules will become antiquated.

Posted on

Kick off Block-Based WordPress Theme Development With the Theme.json Creator

Gutenberg 9.1 made a backward-incompatible change to its theme.json file (experimental-theme.json while full-site editing is under the experimental flag). This is the configuration file that theme developers will need to create as part of their block-based themes. Staying up to date with such changes can be a challenge for theme authors, but Ari Stathopoulos, a Themes Team representative, wrote a full guide for developers.

Jon Quach, a Principal Designer at Automattic, has also been busy creating a tool to help theme authors transition to block-based themes. He recently built a UI-based project called Theme.json Creator that builds out the JSON code for theme authors. Plus, it is up to date with the most recent changes in the Gutenberg plugin.

Tools like these will be what the development community needs as it gets over the inevitable hump of moving away from the traditional theme development paradigm and into a new era where themes are made almost entirely of blocks and a config file.

While plugin development is becoming more complex with the addition of JavaScript, theme development is taking a sharp turn toward its roots of HTML and CSS. We are barreling toward a future in which far more people will be able to create WordPress themes. Even the possibility of sharing pieces of themes (e.g., template parts and patterns) is on the table. This could not only empower theme designers by lowering the barrier to entry, it could also empower some end-users to make the jump into theme building.

However, the theme.json file is one aspect of future theme authorship that is extremely developer-oriented. JSON is a universal format shared between various programming languages. It is meant to be read by machines and is not quite as human-friendly as other formats. As the theme.json file grows to accommodate more configuration options over time, the less friendly it will become to simply typing keys and values in.

It makes sense to build tools to simplify this part of the theme building process.

That is where the Theme.json Creator tool comes in. Theme authors pick and choose the options they want to support and input custom values. Then, the tool spits out everything in properly-formatted JSON.

Screenshot of the Theme.json Creator web page.
Using the Theme.json Creator tool.

One big thing the tool does not yet cover is custom CSS variables. This feature is a recent addition to the theme.json specification. It allows theme authors to create any custom property that WordPress will automatically output as CSS. In his announcement post, Stathopoulos covered how to create a typographic scale with custom properties and use those variables for editor features, such as line-height and font-size values.

Currently, Theme.json Creator’s primary focus is on global styles. However, Gutenberg allows theme authors to configure default styles on the block level. For example, theme designers can set the color or typography options for the core Heading block to be different from the default global styles. This provides theme authors with fine-tuned control over every block.

Theme.json Creator does not yet support configuration at this level. However, it would be interesting to see if Quach adds it in the future.

The focus on setting up global styles is a good start for now. This is still an experimental feature. The great thing about it is that it can help theme authors begin to see how one piece of the block-based themes puzzle fits in. It is a starting point for an entirely new method of adding theme support for features when most are accustomed to adding multiple add_theme_support() PHP function calls.

With the direction that theme development seems to be heading, it is easy to imagine that it could evolve into a completely UI-based affair at some point down the line. If templates are made up of blocks and patterns, which anyone can already build with the block editor, and if styles will essentially boil down to a config file, there will be little-to-no programming required to build a basic WordPress theme.

If someone is not already at least jotting down notes for a plugin that allows users to create and package a block-based theme, I would be surprised. For now, Theme.json Creator is removing the need to write code for at least one part of the theme design process.

Posted on

Exploring Full-Site Editing With the Q WordPress Theme

I have been eagerly awaiting the moment when I could install a theme and truly test Gutenberg’s full-site editing feature. By and large, each time I have tested it over the past few months, the experience has felt utterly broken. This is why I have remained skeptical of seeing the feature land in WordPress 5.6 this December.

The Q theme by Ari Stathopoulos is the first theme that seems to be a decent working example. Whether that is a stroke of luck with timing or that this particular theme is simply built correctly is hard to tell — Stathopoulos is a team rep for the Themes Team. Gutenberg 9.1 dropped last week with continued work toward site editing.

Q is as experimental as it gets. The Themes Team put out an open call for experimental, block-based themes as far back as March this year. However, not many have taken the team up on this offer. If approved, Q stands to be the first block-based theme to go live in the official WordPress directory. It still has to work its way through the standard review process, awaiting its turn in the coming weeks.

On the whole, full-site editing remains a frustrating and confusing experience. I still remain skeptical about its readiness, even in beta form, to show off to the world in WordPress 5.6.

However, Q is an interesting theme to explore at this point for both end-users and theme developers. Users can install it and start tinkering with the site editing screen via the Gutenberg plugin. Developers can learn how global styles, templates, and template parts fit together from a working theme.

Using the Site Editor

Gutenberg plugin in site editor mode.
Editing a single post in the site editor.

The Q theme requires the Gutenberg plugin and its full-site editing mode to be enabled. Generally, requiring a plugin is not allowed for themes in the directory. However, experimental Gutenberg themes are allowed to bypass this guideline.

Stathopoulos pointed out that the theme is highly experimental and should not be used on a production site. However, he is hopeful that it will get more eyes focused on full-site editing.

He mentioned that several items are broken, such as category archives not showing the correct posts. This is a current limitation of the Query block in Gutenberg. However, one of the best ways to find and recognize these types of issues is to have a theme that stays up with the pace of development.

Currently, the site editor feels like it is biting off more than it can chew. Not only can users edit the layout and design of the page, but they can also directly edit existing post content — don’t try this at home unless you are willing for your post titles to get switched to the hyphenated slug. Should the site editor be handling the double-duty of design and content editing? If so, should design and content editing be handled in separate locations in the long term or be merged into one feature?

It feels raw. It is not geared toward users at this point.

The bright spot with the site editor is the current progress on template parts in the editor. Template parts are essentially “modules” that handle one part of the page. For example, the typical theme will have a header and footer template part. Currently, end-users can insert custom template parts or switch one template part for another. This opens a world of possibilities, such as users choosing between multiple header designs (template parts) for their sites.

Selecting a template part for the header in Gutenberg's site editor.
Switching the header template part.

The downside to the entire template system is that it seems so divorced from the site editor that it is hard to believe the average user would understand what is going on. Templates and template parts reside under the Appearance menu in the admin. The Site Editor is a separate, top-level menu item. Without any preexisting knowledge of how these pieces work together, it can be confusing.

Template parts worked for me in the site editor from the outset. However, they did not work on the front end at first. I continually received the “template part not found” message for hours. Then, at some point — whether through magic or a random save that pulled everything together — the feature began to output the previously-missing header and footer template parts.

Glimpse Into the Future of Theme Development

The Q theme has a scant few style rules, which it loads directly in the <head> section of the site in lieu of adding an extra stylesheet. It relies on the stock Gutenberg block styles on the front end with a few minor overrides. Most other custom styles are handled via the global styles system, which pulls from the theme’s experimental-theme.json config file (will be theme.json in the future).

It begs the question of whether themes will necessarily need much in the way of CSS when full-site editing lands.

If WordPress allows users to configure most styles via block options and global styles overrides, themes may not need much more than their config files. After that, it would come down to registering custom block styles and patterns.

If this is the future that we are headed toward, anyone could essentially create a WordPress theme. And, those pieces, such as template parts and patterns, could all be shared between any site. In that future, themes may simply not matter anymore.

Last year, Mike Schinkel proposed deprecating the theme system altogether and replacing it with web components.

“Rather than look for a theme that has all the features one needs — which I have found always limits the choices to zero — a site owner could look for the components and modules they need and then assemble their site from those modules,” he said. “They could pick a header, a footer, a home-page hero, a set of article cards, a pricing module, and so on.”

The more I tinker with full-site editing, the more it feels like that is the lane that it will ultimately merge into. Imagine a future where end-users could pick and choose the pieces they wanted and simply have it look right on the front end.

It is exciting to think about that possibility. Both Schinkel and I have more of a background in programming than we do in design. It makes sense from that sort of analytical mindset to put everything into neat, reusable boxes because reuse is a cornerstone of smart programming.

However, I worry about the state of design in such a system with so many replaceable parts. Will designers be able to take holistic approaches to theme development, creating truly intricate pieces of art? Will that system essentially create a web of cookie-cutter sites? Or, will designers simply find ways to think outside the box while within the constraints of the block system?

Posted on

Why Accessibility Matters for WordPress Themes and Their Users

“Do you ever read the subtitles on a video so you didn’t need to unmute it?” asked William Patton, a representative from the WordPress Themes Team. “Used the ‘beep’ from a crosswalk to know when to cross the road? Found yourself reading the info panel at an airport? Those things are considered features, but in reality, they are aids for people with additional needs.”

As I talked with Patton and other reps from the Themes Team, it was clear they believed accessibility was a vital piece of the theme-building puzzle. The team has made small moves in the last year to bring more themes up to standards. However, it has been a slow-going process.

Last July, the team initiated a plan to add a new guideline every two months or so that would address a single accessibility issue. It would become every theme author’s responsibility to make sure they were meeting the new guidelines. It would be every reviewer’s responsibility to understand how to test guidelines as they were implemented. Thus far, the team has required only that themes have a working skip-to-content link and keyboard-capable navigation menus.

Not every theme author was excited about the move. Some have still shown resistance a year later.

Last week, we covered the Astra theme’s news of hitting 1 million active installs. A commenter made a point that the data shows that end-users do not care about accessibility — the Astra theme makes no mention of being accessibility-ready. The conclusion was that the Themes Team should not be implementing such guidelines based on the success of one of the directory’s most popular themes.

While there are several things we could do to pick apart the original comment and the limited view of the situation, we can instead use it as a catalyst to discuss why accessibility is something that should be at the forefront of every theme author’s mind. Patton, along with Themes Team representatives Carolina Nymark and Denis Žoljom, had a lot to say on the subject.

The overarching theme was that awareness is vital and that theme developers play a crucial role in making the web more accessible.

Awareness Is Key

Decorative image of a closeup-view of a human eye.

Žoljom likened the awareness of accessibility to that of a cisgender person looking at the world from the perspective of a transgender person. Once he became aware of larger issues, he made sure to address gender-specific pronouns in his code comments, such as replacing instances of “he” with “they.” He hopes such small changes spark similar changes from others.

He said the situation was the same with accessibility. “It might not mean much to a person who doesn’t have any disabilities, but putting yourself in somebody else’s shoes changes one’s perspective. This is why we started to include things like skip links, keyboard nav, etc.”

The team does not hope theme authors will merely become technically proficient at addressing accessibility issues in their themes. While that would be a help from a review standpoint, it addresses only the symptoms rather than root causes of the issues. Instead, by making more developers aware, they will begin to look at development from multiple perspectives. They will ask how a screen-readers will handle their theme. They will ask whether their colors have enough contrast for low-vision users to read. They will wonder if non-mouse users can navigate their users’ sites.

The technical stuff is the easy part. Changing perspectives and becoming more empathetic toward those who are different is much more difficult. But not impossible.

“A lot of us who build for the web are lacking some basic insights into what it is like to have additional needs beyond what is our own normal,” said Patton. “There is a saying: ‘if you could see it through my eyes, you would see it differently.’ If you could see through the eyes of someone with color blindness or impaired vision, you quite literally would see things differently.”

The trouble with humans, in general, is that it can sometimes be hard to see things through someone else’s eyes. Of course, there are tools to simulate accessibility issues for developers, so that helps. However, these tools do not replicate what it is like to walk through life with a particular impairment or disability. Some of us can only partially glimpse the difficulties that others may have when navigating the web. This does not mean that we cannot address the downfalls of the software we build and become more inclusive to all people, especially if we are proactive when issues are raised.

Nymark identified a few areas where the community can improve awareness:

  • Make sure that all contributors are aware of the WordPress accessibility requirements so that all new features are accessible.
  • Highlight accessibility improvements when WordPress is updated.
  • Feature more diverse use cases and highlight areas where the accessibility that is built into WordPress has helped people share and access important content.

“The themes team hopes that by making theme authors aware of accessibility issues, authors will learn that even small changes to their code and design can have a great positive impact,” she said.

Is Accessibility Important to End-Users?

Decorative image of a laptop, book, and artwork.

Certainly, accessibility is important for some users. It certainly mattered to Guillermo Robles, a blind man who sued pizza chain Domino’s in 2016 for an inaccessible website. The court case was important enough that it moved through the system all the way to the U.S. Supreme Court. Ultimately, the higher court denied Domino’s appeal of an earlier ruling. The U.S. 9th Circuit court had previously ruled that business websites fall under Title III of the American with Disabilities Act (ADA) and must meet accessibility standards.

This was a landmark case in the U.S. for accessibility advocates last October. It is also worth remembering as we near the upcoming 30th anniversary of the ADA on July 26.

Domino’s is a billion-dollar business. The company has enough money to fight such battles for years. They also have the money to hire world-class web developers to correct any accessibility issues.

However, for small business owners, hiring a single developer, much less an entire agency or team, is often a non-starter. Many small businesses are fortunate to break even. WordPress and its ecosystem of free or low-cost solutions have democratized eCommerce on a scale previously unwitnessed. It means that mom-and-pop stores can have an online presence. It means teens can begin selling their custom art and a multitude of others can make money online without the backing of wads of cash.

For these small business owners, many are unaware of accessibility concerns. They pick up a few plugins and find a theme that suitably matches their branding. The possibility of an impending accessibility-related lawsuit is the furthest thing from their mind. This is a major reason that WordPress needs to be a leader in meeting accessibility standards. Themes, which are the part of the site that visitors will interact with, are possibly the most important part of that equation.

Some would argue that small business owners should understand the laws of their jurisdiction. That is true. However, it is also partly the responsibility of the software creators, says the Theme Team representatives.

“Yes, the technology should account for additional needs,” said Patton. “Yes, the tooling should enable people to make good choices with regards to this. Yes, it should be easy to meet a minimum level of accessibility in the things we create with ease. Yes, it should be a fair assumption that the choices available to pick from are accessible.”

The web is inherently accessible out of the box. Raw HTML is read and output by web browsers in such a way that the content can be accessed by anyone. Patton says that it is the things that developers do from that point forward that makes that experience better or worse.

“Trade-offs are made that are well-intentioned but not always helpful,” he said. “Design trade-offs are the easiest to point out. Taking text and embedding it into an image means that some of its value is lost in exchange for it looking pretty. Using closely matching colors for text and background might create an interesting effect to some people but for others, it makes it impossible to read. Sometimes it’s about balancing those trade-offs with the needs of others, but it is those kinds of trade-offs that most people struggle to give up.”

Nymark described some more technical issues that the average end-user should expect to simply be a non-issue. For example, it is reasonable to assume that a theme installed from the official WordPress directory would be free from HTML, PHP, and JavaScript errors. These are items that users should not have to worry about checking before activating the theme on their site. The errors should simply not exist.

It is that level of quality control that end-users should expect in terms of accessibility, an assurance that the theme does all the things it is supposed to do. It is not about whether end-users “care” about accessibility.

“If a form on a shop checkout page is not working, this can lead to loss of income,” she said. “Users rely on the technical solution provided by plugins and themes and expect everyone to be able to use their shop. Whether or not the site owner recognizes this as an accessibility issue is irrelevant because their page just needs to work.”

Why Theme Authors Should Care

Decorative image of a white desktop with an assortment of items, including an Apple computer and coffee mug.

“If those who choose themes don’t consider accessibility and the theme author did not consider it, then the [visitors] of the sites built with those themes are the ones that lose out,” said Patton. “It’s not a huge leap to realize that low accessibility on your site directly equates to a reduction of potential users.”

He said that end-users would naturally assume the themes they are picking from do not have accessibility issues. However, that assumption is typically far from accurate.

“Theme authors should care about the accessibility of their creations so that the people picking their themes don’t need to use it as a deciding factor,” he said.

My go-to response is that developers should concern themselves with accessibility because it is for the collective good. Humans should care about making sure that all other humans have the same freedoms that they enjoy, which are often take for granted.

Even those who cannot view it from that perspective should be able to appreciate that it is a smart business decision. It makes little sense to leave money on the table, especially if you are a developer who is selling a theme or upselling additional features on top of a free theme. There is an entire segment of users that represents money lost.

Additionally, more and more countries are implementing laws around web accessibility. Over time, such laws will be commonplace, particularly in the business sector. Inaccessible themes will lose users as such laws are enforced. Now is a good time to get ahead of impending change.

More Guidelines Ahead

The WordPress Themes Team has been slow about adopting additional guidelines surrounding accessibility. However, more are expected to land at some point. Team reps want to work with authors and reviewers alike to make the transition as painless as possible.

“We have not added anything else because theme authors are still not releasing themes with working implementations of skip links and usable keyboard navigation,” said Patton. “When those two things become habitual, it will be time to introduce another aspect as a requirement.”

The next guideline in line is expected to be underlined links in the post content. This would be an easy win if the team can get past the current stage. Right now, the team reps are unsure when that will happen.

“The fact that this has taken so long for authors to get this right probably indicates that we need to do better at guiding them to resources to learn how to do it and why it is important,” said Patton. “Perhaps that is a better avenue to pursue than looking to implement additional asks of them.”

Posted on

Should WordPress Themes Add a Top-Level Admin Menu Item?

WordPress has almost always provided a top-level admin menu item for themes. It is clearly labeled “Appearance.” It is the single location that all WordPress users know to visit to modify any appearance-related things for their WordPress site. However, there is a movement within the Themes Team to allow themes to place an additional top-level menu link in the admin. The big question: should this idea move forward?

When the Themes Team (originally called the Theme Review Team) was formed, its members created a set of guidelines that would be shaped and reshaped over the years. They were a set of living guidelines that could always be changed with the times.

One of the oldest guidelines required that themes must place any custom admin pages under the Appearance menu item. It made sense. WordPress provided a standard location for any theme-related pages. The custom header and background features lived under Appearance. Widgets, also defined by the current theme, were housed as a sub-page. Eventually, WordPress’s custom nav menu system came along and was — you guessed it — situated under Appearance. The core developers even put the customizer link in the same place.

For over a decade, there was a well-defined standard. Sure, commercial themes outside of the official directory would sometimes break the mold. However, themes from the directory followed the pattern.

Now, the Themes Team is proposing that themes should be able to break from tradition.

The discussion arose after a question of whether themes should be able to add a custom panel to the block editor sidebar, which is not allowed.

“To keep the editor free from clutter, advertising and upsell, with the customizer being used less, and no dashboard widgets being allowed, can we give theme authors a better place to include their information, and limit upsell to that area?” wrote Carolina Nymark in last week’s team meeting notes.

The proposal seems to settle on the idea that themes will lose visibility as WordPress moves toward full-site editing and the customizer becomes less important. The customizer is not an ideal place for anything but theme options, but that notion seems to have been overlooked in the discussion. Nevertheless, the original guideline that disallowed themes from creating top-level menu items preceded the advent of the customizer by several years. Advertising, documentation, plugin recommendations, and similar pages were always allowed under the existing Appearance menu. The usefulness of the customizer was never a necessary part of that conversation.

Ultimately, the question should be about what is best for users. There is no data to support making the change or sticking with the status quo. However, we do have a standard that has existed for years.

The Proposed Guidelines

The proposal would create several new guidelines for theme authors to follow and reviewers to check, assuming the theme created a top-level admin menu item:

  • No admin menu priority may be used.
  • No UI or color changes are allowed for the menu item.
  • The title must be kept short and not include spam.
  • No more than three sub-pages.
  • Child themes are limited to one sub-page or can remove the parent’s pages and add its own.

Some of these make sense and follow along with existing guidelines, such as not spamming or changing the admin UI. However, others could be problematic.

If moving forward with the proposal, setting a menu item priority should be required rather than not allowed. If anything, it would make sense to require a specific priority to place the custom menu item immediately after the existing Appearance item. This would at least group them together by default. If changing the place where users are accustomed to seeing theme-related pages, it is probably best not to break too far from the standard location.

No more than three sub-pages? Surely there will be a theme with a top-level admin menu item that needs four sub-pages at some point. If giving theme authors the freedom to take up valuable real estate in the admin, a limit of three sub-pages seems like a rule to fix the mistake of allowing the top-level item in the first place. It is an arbitrary number at best. There would be no reason to cap it once making the guideline change. It also adds one more item that the team will need to police.

The limitation of sub-pages for child themes seems just as arbitrary. No such limitation exists when placing sub-pages under the standard Appearance screen.

The entire proposal is little more than extra work on a team that is already strained for resources.

Instead of the simple rule that has existed for years, the proposal adds a new rule with several sub-rules. If the team desires the extra work, I suppose this point doesn’t matter.

The Elephant in the Room

There is one aspect of this discussion that everyone knows about but few are willing to broach. Underneath all the guidelines from the Themes Team and whether most theme authors support a particular decision is how this affects the financial bottom line. When we talk about visibility of a theme’s admin pages, we are primarily talking about providing another avenue for commercial upsells.

Some of this discussion on visibility is shrouded in concepts such as surfacing end-user documentation or adding a visible readme for the user’s benefit. These are legitimate concerns, especially when theme developers have watched tickets to address such downfalls seemingly dwindle into obscurity over the years. Whether a top-level admin menu item makes sense for exposing theme documentation might be worth discussing, but there is no world in which this would be the primary use case.

The topic of visibility rests on the idea of upselling the pro version of the theme, add-ons, or other services.

Far too many plugins already go overboard, creating a billboard of the WordPress admin. One of the things users could almost be assured of is that themes from the official directory were constrained enough that they were not the hot mess that plugins have become as of late. However, that could all change.

Do we really want an extra top-level admin menu item that will be, for all intents and purposes, to advertise?

Maybe it doesn’t matter in the end. Users are so accustomed to the clutter produced by the dozens of plugins on their sites. One more may not matter at this point.

Or, should we be having a different conversation altogether? If this ultimately boils down to advertising, are there ways we can open this up for theme authors while still creating a user experience that keeps the WordPress admin free of clutter?

Posted on

WordCamp Attendance Badges Could Be a Good Thing, but That’s the Wrong Discussion

Example screenshot of multiple WordPress profile badges.
WordPress profile badges.

On July 3, Timi Wahalahti opened a discussion on the Community WordPress blog on whether WordCamp volunteers, WordCamp attendees, or Meetup attendees should be awarded a WordPress.org profile badge. The discussion stemmed from a nearly two-year-old Meta ticket that was recently resurfaced.

The general consensus from the comments on the post seems to be that volunteers should receive badges because they are making direct contributions to the community. Most argue that merely attending an event is not badge-worthy. There are also some technical concerns. However, they should not be a real issue considering we are a community of programmers and problem solvers.

I see the rationale behind not giving badges to attendees. In one way, it feels like it diminishes the badges that others have earned, quite often, through hours of valuable time freely given back to the project.

I am taking a wild guess here and will say that most people would agree that direct, measurable contributions should be rewarded. Whether it is contributing a patch to core, reviewing code as part of the Themes Team, or handing out sandwiches at your local WordCamp lunch line, you should be recognized for giving back to the community.

WordCamp attendance badges would become the participation trophies of the WordPress world.

I get the argument. I do. When I first read the community post, my gut reaction was to make that same argument.

In some parts of American culture, at least, participation trophies are often looked upon as something to be ashamed of — if you don’t earn MVP, it’s not a real trophy. I have seen the culture change, seemingly overnight, in my local community. Fathers will not allow their sons to accept a trophy for merely being on the football team (anyone deserves a trophy for making it through training camp in Alabama’s sweltering August heat). I watch as community members — grown adults — tear down others’ kids on Facebook over the same idea.

The discussion on WordCamp attendance badges feels much the same. However, the argument is valid only because that is how the system is set up. It was created to award based on merit. The awards go to those who put in the time and effort, typically over the long haul.

On the surface, that feels like a good system. However, other systems have benefits that perhaps our community has been overlooking, particularly those that gamify participation. Currently, WordPress profile badges are not being utilized to their full potential. The missing piece is that we are not encouraging more participation. We are not helping the first-time user level up and earn more badges/awards.

NaNoWriMo writing and personal achievement badges.
NaNoWriMo writing and personal achievement badges.

In 2018, I successfully completed National Novel Writing Month (NaNoWriMo). It is an event where thousands of people go through the insane process of writing a 50,000-word novel in 30 days. One of the things that pushed me through the month, aside from sheer willpower and encouragement from family and friends, was the encouragement from the NaNoWriMo website itself.

The website has two categories of badges. The first category is its writing badges. These badges are awarded based on actually doing work. They are also awarded in stages. Write for a two-day streak. Earn a badge. Surpass 5,000 words. Earn a badge. Finish the month-long challenge. Earn a badge. Throughout the process of NaNoWriMo, earning these writing badges was a big motivator toward keeping the dream of writing a novel alive. If I wasn’t motivated to write on a particular day, I could look at the next badge I would earn by just putting pen to paper for another half hour or so.

The thing about these writing badges that was so important was not that they gave me any bragging rights. The badges were not for showing other people how awesome I was. They were deeply personal. They were things that helped motivate me to continue on. OK, I did brag about them a little bit.

At the end of the day, these achievement-based badges were not about other people. They made me feel good about myself, and that is what mattered.

NaNoWriMo’s second category was for personal badges. They were not awarded for any achievement. Every user on the site could pick and choose the badges they wanted. They were reflections of the person. It told others a little something about you.

One of my favorite badges was the “pantser” badge. It let people in the NaNoWriMo community know that I was writing without a novel outline or any real plan — literally by the seat of my pants. Others would choose the “planner” or even the combo “plantser” badge. And, the site had several other badges that simply added to the fun.

We do not have to think about badges as something that must be awarded based on hard work. Sure, we should have those “gold level” badges that are earned through direct contributions and being on a particular team. Joining the Documentation Team or submitting a plugin to the official plugin directory is a big deal. Those achievements should be shown on your profile. However, they are not the only achievements that matter.

Remember that badges are sometimes personal. Being awarded for even the smallest of things can help build the confidence that some people need to do that second small thing.

Simple badges for asking or answering your first support forum question could be a great motivator to become more involved. Attending a WordCamp for the first time? Get a badge. That might help motivate you to earn the five-time WordCamp attendee badge next.

I would even love to see badges for individual WordCamps. How cool would it be for someone to earn a badge for attending a WordCamp in every corner of the world? Or just on one continent?

There is so much lost potential with the current badge system. We are having the wrong discussion. Whether someone should earn a badge for attending a WordCamp is too narrow of a focus. Let’s start looking at how we can gamify participation in the WordPress community and use that system to get more people involved.

If we maintain the current system of giving badges only for contributions and teams, yeah, WordCamp volunteers should get those. Attendees have done nothing to earn a badge in that system. That seems like an easy call to make and not worth much discussion. But, since we are here, let’s rethink this whole thing.

Posted on

Where Gutenberg Went Wrong: Theme Developer Edition

Screenshot of the block-based themes in the WordPress theme directory.
Themes with block editor styles on WordPress.org.

With full-site editing just around the bend, it is a fair question to ask whether the WordPress ecosystem is prepared for such a transition, particularly on the theme development side of things.

It is no secret that theme developers have struggled to keep up with the barrage of changes between Gutenberg plugin updates and, ultimately, major WordPress versions. It is also a fair question to ask who is steering the ship. Where are the site developers, theme authors, and other designers who spend every day crafting the front end of the web? Where are the forward-thinking solutions that make sure the project maintains backward compatibility?

There have been some efforts to mend the broken divide between the Gutenberg project and theme developers such as the fortnightly block-based themes meetings. However, those meetings, by and large, are general updates on things the Gutenberg team has already developed or will ship soon. Those meetings are a good stepping stone toward better communication, but the project needs a project planner with both the vision of the future landscape and a sense of the day-to-day issues that theme authors contend with.

The reality is that there are only 132 themes out of 7,455 that list block editor styles as a feature in the official repository. We are a year and a half into the lifespan of the block editor officially merging into WordPress, yet the face of the platform is made up mostly of themes that have shoehorned some basic block styles into mediocre designs. The themes that truly stand out with full block-editor support are few and far between. Many of those are also bidding heavily on Elementor or other page builders.

Whether you like the block editor is of little consequence when there is no buy-in from theme authors. Every week, I check the theme directory for new themes, hoping to find a hidden gem. Every week, I am disappointed to see new themes dropping in 2020 with no support for the block editor. There is an entire segment of users who might enjoy the editor if only they had something more than Twenty Twenty to play around with — it is a fine theme but is not everyone’s cup of tea.

Screenshot of ThemeForest's block-based themes.
ThemeForest’s listing of block-styled themes.

ThemeForest sellers are besting free WordPress.org theme authors 18 to 1 in terms of support with over 2,300 themes listed as Gutenberg-optimized. Granted, themes from the massive marketplace are known to have every feature they can in an attempt to one-up the competition. Also, many of them either have built-in page builders or support third-party solutions.

Still, for the flagship feature of the platform, end-users should expect something more from the official theme directory. A third-party marketplace should not be the only game in town. At the moment, much of the offerings on WordPress.org feel lackluster at best. The handful that go the extra mile, such as the Rosa 2 and Go themes, have mature businesses funding the effort.

There is some broken trust between theme authors and WordPress at the moment. Some shout it loudly (as folks can attest from WP Tavern comments section). Others are more quietly trying to figure all this out.

Even Carolina Nymark, one of the representatives for the official Themes Team, shared some concern. “How do all of you theme authors keep up with the changes to Gutenberg?” she asked in a tweet. When the team leads are not up to speed, it is not good for the project as a whole.

“I don’t,” replied Anders Norén, the primary developer behind Twenty Twenty, to Nymark’s question. “I wait until something breaks (in the beta releases) and try to fix it then. Trying to support changes in the Gutenberg plugin while maintaining support for the block editor in Core is bad for your health.”

There is a major concern from theme authors about the future. It is hard to get excited about the current possibilities when there is uncertainty over what theme development will look like in 12 months. There is no clear and detailed roadmap about how things will work, and many theme designers feel like they are playing catchup from week to week. Instead, they should be able to more clearly look ahead and push early ideas into play.

My ultimate fear is that the Themes Team will one day flip the switch and require all themes going into the directory to support the block editor like it had to do with the customizer in 2015. If theme authors do not organically make the transition such a day may come. The team will be stuck as the bad guys in the middle.

Where Do We Go from Here?

It is easy to identify some of the major pain points for theme authors. Changes between updates will inevitably break something with the theme design.

Breaking HTML changes.

Breaking CSS changes.

Missing class names.

Different methods of handling alignment, depending on the block.

Dealing with inline styles after years of being taught to avoid them.

All of these issues are roadblocks for theme authors. And, when things get in the way of theme authors doing their jobs, they trickle down to end-users.

This is not the WordPress of the last decade. The WordPress that promised to not break things with updates. The WordPress where a one-off theme by a non-professional designer still worked four months later.

The Gutenberg project is still in its infancy. It can be fun to play with, but it can also be messy. I am as much of an evangelist for the block editor as anyone, but I can recognize when there is a clear and present issue of trust between theme authors and the developers of the project.

Currently, theme authors who are attempting to cover all of their bases are designing for at least a couple of versions of WordPress, multiple versions of Gutenberg, and the classic editor plugin. It is a dizzying array of testing for one theme. Those with a dozen or more themes…well, it is not an ideal situation.

A holistic approach needs to be taken toward theme and site design. Theme authors need to see the details of the roadmap and contribute to it, carving the features they see as relevant into stone for the coming years. They need to know that the buttons block design they sweated over for hours this past week will continue working next week.

It all starts at the project management level.

If a breaking HTML change needs to happen, theme authors need more than, “X change needs to happen for Y feature to work.” They need to see ownership of the mistake in the initial planning phase for X, backward-compatible code solutions, and a path toward fewer of the same mistakes happening.

Theme designers still need some sort of design framework. The current utility classes are like a poor man’s version of Tailwind that is being pieced together as the project adds new features without the foresight to look at the future landscape. Maybe the upcoming Global Styles feature can tackle that on a larger scale that provides compatibility across themes.

Ultimately, there needs to be more communication between the Gutenberg team and theme authors who are building themes for the official WordPress theme directory. Perhaps there should even be a new team or sub-team formed focused solely on theming in the block era and working directly with Gutenberg developers to identify pain points. Whatever happens, someone needs to inspire the next generation of themes into being. Until then, most theme authors are stuck wondering what they will need to fix next.

Up next: block/plugin development edition?