April’s Genesis Shapers meeting was another excellent gathering of this awesome group helping to shape the future of Genesis.
Before we dive into the details of the April meeting, here are recaps from the previous Shapers events, if you’d like to catch up:
2019:
January, February, March, April, May, July, August, September, October, November, and December.
2020:
As a reminder, the Genesis Shapers are a global, hand-selected, and diverse group of people representing companies from across the community who share a representative voice for the strategic direction of Genesis, which is combined with the feedback we receive directly from customers across social channels, and through Genesis WP on Slack.
The Genesis Shapers as of the date of this meeting, included Bill Erickson, Carrie Dils, David Decker, Gary Jones, Jennifer Bourn, Jon Brown, Jonathan Jeter, Lauren Gaige, Lee Anthony, Mike Hemberger, Nahuai Badiola, Remkus de Vries, Robin Cornett, Anita Carter, Sridhar Katakam, Ryan Murray, and Nick Croft.
With that, here’s the Genesis Shapers meeting recap for April 2020
The April Shapers meeting was focused around Full Site Editing in WordPress #Core and the future version of Genesis that will support Full Site Editing. This future version of Genesis is code named “Genesis X” and was distributed to the Shapers in advance of this meeting, so they could give their feedback live.
As discussed in a prior post, this future version of Genesis will be freely available and supported for StudioPress customers.
Serving as moderator, I kicked things off with the following question:
What are your thoughts about Full Site Editing?
Nick Croft jumped in first, “For end users I think it’s a great experience. For clients, I think the goal will be trying to figure out how to limit editing or making an ‘on rails’ experience. For example, we’d want to have a fixed template that puts header, navigation, footer, etc. in place and locks some elements while allowing clients to update their menus and other common elements similar to the experience they have now.”
Carrie Dils added, “tl;dr on FSE: It’s an exciting advancement for users. For devs and designers, they’ve got to be able to set guardrails.”
I responded to Carrie with my two cents, “I see the value for the users of course, but I think there’s great value for development teams. Giving more power to the user means dev teams can scale their innovation. In other words, instead of spending time remaking different variants of the same things, they can add more functionality and revenue-generating experiences to the site. IMO developers don’t like being buried in soul-crushing landing page tickets.”
While the conversation on FSE got a bit sidetracked into development workflows and user choice, I decided to post our second question:
What are your initial impressions of Genesis as a plugin? Is there anything you’re especially excited by or concerned about?
Jon Brown responded first, offering a dual perspective, “Excited: Genesis is (maybe) becoming a plugin! Concerned: is there anything from old Genesis making it into the plugin?”
To which I responded, “@nickcernis and others are looking at it through this lens, so my short answer is yes.”
Bill Erickson asked, “Will the normal Genesis and Genesis X both be maintained, or is it expected that everyone will use Genesis X? I don’t expect everyone to jump on the Full Site Editing bandwagon.”
Bryan Smith answered, “Hey Bill, we’re still in an experimental phase so seeking as much feedback from you all as possible. We want Genesis to become a plugin AND we want Genesis to support FSE (Full Site Editing). Assuming, the Gen X path is the path we go down, we will need to maintain normal Genesis for a period of time.”
Bryan didn’t fully address the question of maintaining the Genesis parent theme version in his response, but I’ll clarify that here. We are committed to maintaining the parent theme version including after the plugin version is released toward the end of the year. This will include security patching and updates to Genesis necessary to keep pace with WordPress #Core. Of course, much of WordPress #Core will be moving toward Full Site Editing in the future which is why we will be releasing the plugin version of Genesis to allow the entire Genesis community to benefit from having the fastest path to building high-quality websites with WordPress & FSE just like the community enjoys today.
Jon also added in, “I’m not really concerned about a migration path from G3 (Genesis v. 3) to GenX as much as I am still having the tools in G3 available in GenX. What I mean is, I’d hope that in GenX I could still build a traditional (non-FSE) type theme/template. Not sure if that’s completely off the table… or seen as pointless, but it would be a hope.”
In response, Gary Jones said, “From Nick’s answers, it seems that GenX has been created to address the FSE issue, and not necessarily the “Turn Genesis into a plugin” issue directly.”
Bryan added to that, “The intent is that Genesis becomes a plugin even aside from FSE.”
I would add to that and say FSE is the driving force in the switch to a plugin in the future; albeit, there are other compelling benefits to switching Genesis from a parent theme into a plugin as Bryan pointed out in his reply.
Switching gears, Bill said, “Personally I think the most valuable feature in Genesis is the hook system, and it’s unlikely that would make it to an FSE version.”
In response, Mike Hemberger said, “With FSE, hooks get in the way.”
Although a number of additional questions and concerns were raised, the most consistent theme was something along the lines of: “What will happen to all those Genesis things I use to build my themes?!?“
As I told the group, this is of course on our radar, and the Genesis engineering team are hard at work evaluating feature-by-feature what existing and new features will be available in the plugin version.
We are currently in a very early alpha testing of an experimental version of Genesis as a plugin and are receiving direct feedback from the Shapers and 3rd party theme developers as to what existing & new Genesis features are most important. As the project continues, we’ll also be seeking your feedback in public betas and posting about our progress along the way in posts like this.
Our next question for the group was:
Please describe the overall experience of using the Style Pack and Style Pack Switcher. What worked and didn’t work for you? Was anything missing? How valuable did you find the tool?
To set the stage for these responses, Style Packs and the Style Pack Switcher are basically the design system of your site within FSE & Genesis as a plugin. You could think of these a bit like “skins”.
Nahuai Badiola answered first, “It worked fine in the tests I did and it was fairly easy to create a new style.”
Robin Cornett also answered, “Creating a new style pack for the front end was fairly easy, but I wonder how many places I need to define things…if I set up custom colors in the .json file, it would be great if they were added to my custom color palette in the block editor, too.”
Ryan Murray added, “If the theme variables are directly editable in the editor for end-user that’d be a good shift. I have clients trying to change their own fonts. This is something that will be easier w/ the JSON file.”
Mike Hemberger had a different take, saying, “I don’t wanna be the hater here, but can someone explain the benefit of Style Packs to an end-user? I’m not seeing it. When would a user buy a theme and want 3+ style variations? I think they’d benefit greater from some simple branding settings to match the theme to their color palette.”
This generated a number of responses, but a few of the more detailed ones came from Nick Cernis, who said, “Can you imagine shipping a single theme and using style/content packs as a replacement to themes? Would that provide added value to you and end-users? You get a consistent way to deliver themes, with reduced duplication and better modularization. End users can swap styling without having to re-import content. Or import new content while maintaining current styling.”
Additionally, Jon Brown added, “I can think of good uses for style packs. Just like we used to sell themes with red, green, blue….Because red didn’t mean “red”, it meant 5 different colors that worked well together. End users picking 5 colors that work well together rarely works. Especially if you’re doing things like picking complementary colors for buttons. A Red style might use black buttons with white text. A Green style might use orange buttons with blue text. Designers can think these things out. A customizer panel can never match that unless it has 12 explicit toggles for everything…..and even then the user doesn’t have the design sense to do it well.”
Summing up those comments, and a few others that came later, it seemed like most of the perceived value with style packs was anchored in the premium theme creator and for the user within their experience setting up the site.
It also seemed like understanding the role of style packs when redesigning would also be helpful. Which led to the next question, relative to the switcher itself:
What, if anything, would improve the value for Style Packs and the Style Pack Switcher? How about improving ease of use?
Ryan Murray answered first, saying, “It’s a list. Can’t get simpler—and the JSON file is a list.”
Nahuai Badiola offered the following suggestion, “If possible, display a small preview of the final design (especially if there are a lot of styles).”
I noted that Nahuai’s was a great suggestion and I do like his idea of a small preview in the UI.
Nick Cernis agreed, saying, “Previewing depends on having a filter on Global Styles in Gutenberg that doesn’t exist yet. But it’s something we’d want to enable.”
On a separate thread, Robin Cornett asked, “if I buy a GenX theme and then edit its style packs myself, could the developer push updates and overwrite them?
Carrie Dils replied to her, “If Genesis is a plugin, then users could make customizations in a child theme.”
Phil Johnston of WP Engine added, “I think it might be safe to say that if a user modified a style pack, it would save as a variation of that style pack, rather than as a replacement. I would think that if that scenario were to be created, you could always revert to the “factory” style pack.”
After a number of other questions—which we’ll likely pick back up on in a future meeting—I moved on to the next question:
As Genesis transitions into a plugin, what features currently in the framework do you want to see the most? The least?
Ryan Murray jumped in first, saying, “A+ Pagespeed on Mobile and Desktop out-of-the-box.”
I asked, “ Is SEO on your list?” To which Bill Erickson replied, “No, let the best SEO plugins keep up with that for us.”
Remkus de Vries echoed Bill, saying, “No, there’s plugins out there that handle this perfectly. Hooks & Performance is where it’s at .”
Robin Cornett added, “Security, filter/action hooks. Things like SEO are deep topics and better off being handled by a dedicated plugin.”
Anita Carter also added, “I’d like to see the Archive template put back. We typically used that for User Sitemaps. Google wants to see a User Sitemap and that Archive template was great. I add it back to all of my projects.”
As mentioned above, we’ll be exploring the features to bring into Genesis as a plugin with the Shapers, 3rd party theme developers, and all of you in the community. Our goal is to help you continue to win with WordPress & Genesis as WordPress evolves.
Compared to the traditional WordPress theme development workflow present today, what would be the: Benefits of using Style Packs & Content Packs Drawbacks of using Style Packs & Content Packs?
Jon Brown answered first, “I like style packs…I liked the color switcher for the same reason. I love the idea of ‘light and dark’ themes that @garyj brought up…especially if that could be exposed on the front end.”
Nahuai Badiola went next, saying, “ I like the idea of separated content packs, similar to what we have now on Genesis onboarding but using (the upcoming) block patterns maybe.”
Nick Croft added his thoughts, “ I’ve listed what I think is the most interesting benefit to content packs. I think there is a great future for something like the layouts in AB. A way to spin up a page with a full template including content for a starting point or a full site to quick start that experience. I love this.
I think a big drawback is potential to accidentally spin up a full site content after it was already set up. This needs some really clear UX thinking.
For Style Packs, I’m a little less excited about that. It’s a cool concept but it’s not dramatically different from theming, just moving it to a different place. It’s cool, works well, and could be the future. I don’t have any big positives or negatives to say on it other than my suggestions above.”
Carrie Dils added, “General comment (not necessarily a drawback of style packs), but accessible color schemes are not the easiest thing to come up with. When designing multiple color/style schemes in style packs, visual accessibility would just be something to keep in mind.”
And that wrapped up the Shaper’s meeting for April 2020
Recap
Thanks for reading our recap of the April 2020 Genesis Shapers meeting. I’m looking forward to the changes coming to WordPress and the ways we—in both the WordPress and Genesis communities—will embrace and lead with these changes. Stay tuned, we’ll continue to keep you updated with all things Genesis and WordPress.
As a reminder, the Genesis Shapers are a global, hand-selected, and diverse group of people representing companies from across the community who share a representative voice for the strategic direction of Genesis, which is combined with the feedback we receive directly from customers across social channels, and through Genesis WP on Slack.