December’s meeting of the Genesis Shapers group wrapped up, marking the 12th installment of what has now been a full year of monthly meetings.
The inaugural meet-up of the Shapers took place December 2018, at WordCamp U.S., and one year in, I’m happy to report that these meetings have consistently served as a great opportunity for the growing group of Genesis Shapers to invest in the future of Genesis and share new developments and insights with the wider community of Genesis users.
Before diving into the details of December’s meeting, here are recaps from previous Shapers meetings, if you’d like to catch up:
January, February, March, April, May, July, August, September, October, and November.
With that, here’s the Genesis Shapers meeting recap for December.
As usual, December’s meeting saw a strong showing from veteran members of the group as well as input from some new members. The focus for December was on Speed, Full-Site Editing, and Building Quickly, with a few sub-questions included that followed those trains of thought.
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,
- Greg Boser,
- Jennifer Bourn,
- Jon Brown,
- Jonathan Jeter,
- Lauren Gaige,
- Lee Anthony,
- Mike Hemberger,
- Nahuai Badiola,
- Remkus de Vries,
- Robin Cornett,
- Anita Carter,
- Sridhar Katakam,
- and Ryan Murray.
The meeting began with a question about Shapers member Nahuai Badiola, who recently hosted a Genesis event in Barcelona, Spain:
What questions do you have for Nahuai on how the event went and what it was like getting so many people on board with Genesis?
I kicked things off, asking Nahuai,
“Were most of the audience new to Genesis or had they already used Genesis and wanted to get better?”
He replied, “I’d say 50/50. Also, we were +50 attendees, 50% of whom were developers and the other 50% were users, designers, or marketers.”
The event featured three separate discussions, with each one showcasing a different benefit of using Genesis.
“One was about business, how Genesis makes it easier to run one,” Nahuai said, “ another one was about the developer point of view, i.e the time developers can save by using Genesis, and the last one was about all the nice features that were launched over the last year, both for devs and users. One-click demo was one of the top things we highlighted.”
Quite a few people, Nahuai added, were interested in a hypothetical Starter Theme for Genesis, which could be used to by experienced developers interested in trying Genesis out.
I clarified: “You mean Genesis Sample or creating your own starter theme?”
“Having something like Genesis Sample but with more flexibility to build something with it,” Nahuai said.
Jon Brown replied: “I hear that a lot…what’s a good starter theme for Genesis? Many feel “Sample” is too simple…”
After some additional, similar comments, I said: “That’s good feedback. Maybe we should switch things up and ask our upcoming question on the agenda…”
What would you hope to see in a Genesis Sample design refresh?
Robin Cornett was the first to reply, saying: “Not design, but I’d love to see it switch over to Sass, or offer a developer version,” which generated agreement from others in the group.
Carrie Dils added to that: “I’d love to see some basic build tools. Less about inclusion of particular packages and more scaffolding.”
WP Engine Founder and CTO Jason Cohen also offered his thoughts: “Maybe worthwhile to have a sample that’s very simple, e.g. think “designer who knows just enough PHP to be dangerous” and another for the advanced dev, e.g. uses sass, has a build toolchain, etc.”
Jon Brown responded, “Modularize CSS” But it’s unclear to me if that encompases build tools too.”
Responding to Robin’s point above, I asked the group, “’I’m guessing the devil is in the details, but why two separate themes for devs and ‘users’ rather than one theme serving both masters?”
Nathan Rice responded, “Theoretically, an advanced dev theme could generate a simple starter ‘user’ theme.”
To which Bill Erickson replied, “ I think one theme could work, set it to compile un-minified CSS/JS and tell basic users to delete the directory that contains the Sass partials. Advanced developers would have instructions on how to compile minified CSS/JS.”
Nick Cernis replied, “That’s how I’ve always envisioned it working too.”
The discussion continued from there, but ultimately led to our next item on the agenda, speed, and our next question:
How do you feel about the default performance of the Genesis sites you build? Would dropping jQuery in Genesis affect you? How?
Mike Hemberger was the first to reply, saying, “The idea of removing jQuery is great, but it seems like 90% of regularly used plugins require it anyway. But still… it may be beneficial to at least know we don’t need it, for the times it would make a difference.”
David Decker added his thoughts, saying, “Performance is always very good. However, removing jQuery makes sense. A lot of competitors did it already (GeneratePress, Astra, ….).”
Robin Cornett also chimed in, saying, “Because a lot of plugins require it as a dependency, I think it’s likely it would load anyway.”
To which Genesis engineer Nick Cernis replied, “But still… it may be beneficial to at least know we don’t need it. This is the main goal, yes. At the moment it’s hard to create a Genesis child theme that doesn’t depend on jQuery via Genesis.”
Jon Brown capped the answers off, saying, ”I’d love to see jQuery removed… but as David pointed out 99% of plugins will include it anyway. For little things (most of what we do) we favor writing JS over JQ unless it’s something really hard to do in plain JS… just feels safer for long term compatibility.”
After a few more answers, we moved on to the next question on the agenda:
Is anyone still using the Classic editor for new site builds? And, if so, what stops you from adopting blocks for all new sites today?
Carrie Dils replied first, saying, “I’m all Gutenberg,” which generated numerous positive responses from the group.
Robin Cornett echoed that sentiment, saying, “I’ve dropped the classic editor plugin completely.”
While other similar answers followed, Jennifer Bourn noted that she used the Classic editor “still on some old sites. Anything new is Gutenberg.”
While other similar answers followed, Jon Brown had an interesting point, saying, “We don’t talk about Gutenberg with new clients, just like we don’t talk about WordPress…. it’s just assumed.”
I noted that I had also noticed this lingo switch in a lot of areas, where people will say, “We build X w/ WordPress,” and the default editor is assumed.
From there, we tee’d up our last question of the meeting:
People seem to be using their StudioPress portal as a “repo” of sorts for the themes they use (through SP anyways). What could we be doing with Genesis to make it easier for folks to access and use the themes they rely on with StudioPress, themes from 3rd party theme providers, or themes they create themselves?
Robin Cornett answered first: “Having a useful features filter in the portal would be nice. Right now you have to go to the themes shop page.”
David Decker added, “In the download area: Changelogs, better and more filters.”
Carrie Dils said, “I would love to be able to install both genesis and a child theme via wp-cli.”
Anita Carter closed the final question off, saying, “I direct people to Changelogs all the time. Some of the theme designers though, don’t include the changes in the files themselves but point people to their websites.”
With that, the meeting wrapped up.
Recap
Thanks to everyone for reading our recap of the December 2019 Genesis Shapers meeting. I’m looking forward to what 2020 brings for this group! We have a ton of great feedback from this year’s Shapers meetings and we’re excited to use this feedback to continue to make an even more powerful framework for you and even more open and helpful community!