Layers has the absolute best onboarding process I’ve seen in any tool like this. Also, the experience for creating new pages is very nice. While I have many disagreements with certain choices they made from a design perspective, overall I am very impressed with what they have done for the page building user experience.
Layers user experience sets a high bar
Layers has some very “wow” worthy features.
I am very impressed with Obox’s onboarding. Upon theme activation, it takes you straight to a progressive walk-through that helps you learn about and setup Layers. It includes videos that operate like playable GIFs that show you what it’s referencing in each stage.
The editor itself is also impressive. Layers are managed totally through the customizer. There is a single customizer tab that opens up panels for Layer widgets, which is very in tune with default WordPress.
I call this method “going all in on the customizer”, which some people love and some people hate. I haven’t yet made up my mind, but I definitely like this better than many other methods I’ve seen — such as completely going outside of the WordPress UI.
Within the WordPress page itself, it calls you to go to the Layers customizer to edit the content, but also has options for duplicating, importing, or exporting Layers templates.
I like the way Layers makes getting started pretty easy. And I’m sure they will offer more templates going forward to help users quickly build pages that would otherwise require custom code.
Obox is really stretching their legs on UX, and they are unabashedly prioritizing UX over everything else.
David Perel — co-founder of Obox — tells me, “We believe in UX more than anything. Code is solveable; it just takes time. But user experience isn’t black and white.” I encouraged him to get more involved with core WordPress’ various UX projects, as I completely agree with his sentiment.
Behind the curtains of Layers code
When I first looked under the hood of Layers, I was completely baffled by some of the code decisions. Saving a page in Layers does not save anything to the actual
post_content in WordPress, nor even in meta. No, content is essentially grouped — across any page ID — and stored in the options table, depending on the type of module in use.
So, if you view the options field of
widget_layers-widget-column, you see this:
The above image is content for any column module in the Layers theme. Meanwhile, the
post_content for the page you create is completely empty.
I was baffled by this architecture decision, as it means that I can never recover that content or use it again unless I’m using Layers. While the UX may fit well into the WordPress experience, the code seemed far, far from it; and it was a complete blocker for me. Then I talked to David Perel.
Thank goodness he showed me their backup tool. Before that, this post looked much, much different.
They are working to automatically port content to the proper field in the database, but for now you can manually do it, so that your markup at least is preserved for if you change themes. This methodology is in line with other responsible page building tools like The Theme Foundry’s Make theme.
I also talked to David about disappointing front-end performance. The theme loads 16 styles and scripts on every page, no matter what. Scripts like Masonry are loading — and more than one Masonry related script — whether the page uses Masonry or not. Those are just the scripts that are not conditional at all. On page inspection of some of their common templates, I was seeing well over 20 HTTP requests for styles and scripts. This simply should not be acceptable. This, at least, is fixable.
After discussing this with David, they are already working to implement a fix that will combine many of these files, and conditionally load others. Layers is 1.0, so while I wish this wasn’t an afterthought, I’m glad they’re moving fast to improve.
Overall, Obox is trying really hard on Layers; and they’ve shipped an impressive 1.0. They are doing active reviews still with some highly qualified WordPress developers whose names we all would know, and we can expect further improvements on performance down the line.
Where to get Layers, and notes on the monetization model
Layers is free, and on Github. They also have developer notes and general docs available. The Obox team is also working to get the product on WordPress.org, but there are some things they have to work out before they can.
For monetization, they intend to charge for pre-built child themes and commercial extensions. For now, they want to get mass adoption for Layers — a tactic that has worked really well for others in the space.
Thoughts on page builders
I am definitely not on the bandwagon for page builders, though it seems the WordPress product world is. Where traditional options heavy theme sales have died away, page builders have risen from their ashes.
I think anyone building a tool like this needs someone at their side forcing them to justify every feature — as it seems to me that most of these are giving way too many options in their products.
I may have a follow-up post in my mind that I’ll probably publish sometime soon describing why I think it is a bad thing for page builders (in the context of theming) to be the future of the web.
I’m afraid, however, that end user “demand” may make it so whether I like it or not; but it won’t be for their own good. I think there is a better way. I think “page building”, as it seems we’ve standardized the term, is broken when too many granular design elements are allowed. Instead, I’d like to see content building, where structured content can be created with a tool, but theming and styles are still left to, well, themes.
Tools like Aesop story engine, Make, and Layers are all making what I consider valiant efforts at evolving complex content creation for WordPress. I don’t think anyone is quite nailing it, but I like where at least these three projects are going for the most part. I’m happy to see Obox release their vision of what content creation should be in WordPress, with Layers.