Disrupting the WordPress experience

(Matt Medeiros) #1

Preface: While this may seem like I’m fishing for product feedback (which is part of it) I’m generally concerned about the user experience as it relates to core WordPress and privately developed plugins.

Because I swim in the uber competitive visual builder market space, I test a lot of “visual builder” plugins. I’ve come across great niche solutions, awful kitchen sink plugins and everything inbetween. Some operate in the traditional backend while others are building new experiences in the front-end. I’d like to comment on both, but will focus on the latter.

Here’s the overarching question: Are you generally attracted to new user experiences being developed by private (GPL aside) companies or do you prefer the broader (albeit slower) core user experience rolled out by .org?

What do I mean by attracted?

  • Smaller teams means faster innovation and iteration. Cutting-edge products, yay!
  • Solving interesting problems for the use case of their product. This (UI/UX) is perfect for my client!
  • Generally like bleeding-edge design versus the need for global adoption. Day-um that’s hot!

Good lord, no! Let .org work on the experience.

  • Safer and wider adoption. This won’t break.
  • Tends to be more scalable with an eye to future growth. I know whatever I do, it will work in the next release.
  • I’m just going to do it the WordPress way.

I’m still on the fence about this, personally. I’ll explain my side of it and hopefully you can chime in with your thoughts.

Your Customizer vs. WordPress Customizer

My quick answer: I’m bullish on the .org customizer.

Not only are we (.org) just beginning to make an effort to move to the front-end, a massive majority of users aren’t even thinking about using it yet. I’m not talking about Joe User either, I’m talking the seasoned Power Users as well. This is what represents the biggest challenge & opportunity, for us anyway.

For instance, when we launched Conductor in September of 2014 at WordCamp NYC, I had people scratching their heads while I was demoing in the WordPress customizer.


Oh so you’re building a drag and drop interface?


No, actually, we’re using WordPress widgets and the customizer to demo the product.

That was (and still is) a hurdle for us. Because we’re not building our own “customizer” the experience is stock WordPress. What does that translate to? It means we’re spending time supporting customers to move to the customizer experience to fully use our product. We’re faced with explaining panels, moving widgets around, debugging other widgets all within the core WordPress experience. Don’t get me wrong, it’s not horrible by any stretch of the imagination – but as a product guy – damn, I’d love to have sexy buttons overlaying on top of the site. :wink:

So, excuse me while I wear my heart on my sleeve for a moment – I am envious of these gorgeous experiences from segment competitors. I’ll go out on a limb and say that when I chatted with Matt Mullenweg, he’s a bit envious too. Looking at the platform landscape, apps like Squarepace and Shopify offer up great UX which compels customers to user their product.

What happens when WordPress crosses that chasm?

Dueling Customizer Experiences

Let me hop into the DeLorian and polish off my hoverboard. When the full-customizer experience arrives, are we ready to support multiple experiences?

For instance, if a visual builder is using their own beautiful UI from above and another widget author requires you to use the WordPress customizer we’re fragment the native experience of designing their site.

Do I use the WordPress customizer? Your customizer? Why aren’t they the same?! I give up.

Invest now for a better future

The best I can do is share what we’re doing now to keep these experiences aligned and protect us for future iterations.

When you’re in the core WordPress customizer experience, the previewer simply shows you the website. There’s no indication of the sidebars that make up your content area or your traditional sidebars. In the above screenshot, our blue helper buttons do the following:

  1. Indicate the sidebar width. You know which sidebar you’re working with and the general layout.
  2. Helper buttons to add a traditional widget or our widget. Reinforcing that you’re building with widgets.

Additionally, when you hover over any widget an edit icon will appear along with a dotted outline that represents the entire widget. These minor adjustments to the customizer + previewer experience really improve the learning curve for our users. While it might not rack up the highest appeal rating, it’s certainly in line (we hope) with how core WordPress will evolve.

Bonus: If you haven’t noticed, when you hover over a widget in your WordPress install you will see: “Shift-click to edit this widget.” Go ahead and try it, I’ll wait. :smile:

Your thoughts?

First, if you’re a developer and you want to learn how to add helper buttons like us or get a primer on working within the customizer, I invite you to read our developer series:

Customizer: Communicating with the Previewer
Customizer: Adding Helpful UI Buttons to the Previewer
Customizing the Customizer User Experience

Now tell me, am I over-engineering this? Perhaps we shouldn’t be concerned about dueling experiences and just see where they chips fall in the end.

The short of it is, I’m interested to know if you think about the overall experience you’re offering up to your client or does none of this matter to you?


Matt, you ask the hard questions! Like you say, on the one hand, staying close to core has many big advantages. Future-proof. Less splintering of UI/UX. And yet sometimes going outside the box is also the best thing to do, for reasons that are less clear.

Personally, I agonize over things that I KNOW my clients/target market could not care less about. Like which form plugin to use? Heck, whatever comes with the theme, as long as it works, is fine with them. But me it is like, Oh my God, Gravity or Ninja? What should I do? What will they like best?

So maybe, to some degree at least, it depends on the target market itself to best define which approach is best.

For myself personally, I tend to like things that are maybe a bit off the “main wheel” but at the same time do not look like a full departure from that wheel. Allowing me to feel comfortable and at the same time provide some “excitement”.

Anyways, that is all I got for now. I can actually be [somewhat] brief :slight_smile:

Hey, I'm Matt Medeiros. Ask me anything
(Nate Wright) #3

A lot of the press/discussion I’ve read around the current flurry of page builders doesn’t dive into segmentation. I think that’s a really critical part of the question you’re raising. I mentioned this a bit with you, @MattMedeiros, after I tried out Conductor, but I’ll expand a bit on how this relates to your question regarding building core or independent experiences.

I think the WordPress ecosystem is too diverse for WP core to have the right experience for all needs. Even for just a few of the largest use-cases. I see page builders filling a few niches which are actually quite distinct:

  1. High-impact blogging and publishing. These builders are designed for writing and drafting articles with rich markup (blockquotes, photos, videos, etc). Front-end editing makes the most sense in this niche because it is focused on individual units where there is strong parity between the drafting process and the final result. The writer is writing a single article and wants to edit for a primary experience (single.php). Lasso by Aesop Interactive is making an explicit bid for this niche. The front-end editor for WP was an attempt to provide something similar for regular bloggers.

  2. Landing pages. The bulk of the market seems to be chasing drag-and-drop or widget-based layout builders, primarily aimed at using content blocks to build landing pages. I’d put Visual Composer, Layers by Obox, Upfront, BeaverBuilder, PageBuilder by SiteOrigin and all the others in this category. I think there are actually two customer segments going on here. One is the low-skilled “developer”, who doesn’t really know how to code but wants maximum capability to build their own site, even if that means wrestling with a large, complex tool. The other segment is the end-user who wants point-and-click tools for editing their site but prefers a simple tool that is easy to learn for 95% of their needs (developers who want to give their clients a limited tool might fit into this segment as well).

  3. Content aggregation and reflow. Conductor is the only plugin out there that I’ve seen that is really streamlined and seems tailored for building archive pages, shop landing pages, seller profiles, directory listings, or any content-heavy sites which need to flow lists of data into aggregate pages. Although many of the layout builder plugins can do this, they aren’t as tailored for this need and so have a lot of bloat for this use-case.

When I gave you this feedback about Conductor being most appropriate for this niche, I think you took it as a challenge to expand Conductor’s use-cases into #2 a bit more. But to be honest I think you’re better off targeting this niche and refining your product specifically for this. Chasing a Visual Composer or Beaver Builder is a bad idea. And it’s such a crowded niche that having your own specific use-case is really valuable.

Now, let’s get back to your original question: is it better to work with core WordPress UI patterns or to build your own? I think it really depends on the segment you’re serving. Where are users going to be building the pages you want with your tool? Where is the easiest place for them to build?

It makes perfect sense for Lasso to build its own, slick front-end editing experience, because the niche it serves is full of authors and writers and people who are already embedded into the singular document flow of their site. They also have a very limited number of options and configuration settings. Each component is self-contained, so they don’t need to see an overview of all the active components on a page or anything like that.

Page builders that are designed for landing pages make sense working in WordPress’s post/page editor. If you’re going to be customizing a lot of individual pages differently, the Customizer is the wrong place for it, IMHO. This is especially true if there are a lot of quite complex settings. The Customizer is a really restricted, small editing panel and it will quickly spiral out of control if every editing feature is built into it. I think the Customizer is best for site-wide changes or changes that are going to happen across multiple pages.

Each segment described above is going to have a different ideal UI/UX. WordPress will never cater to all of them. Building your UI to integrate with WordPress core comes with a lot of benefits. But if it’s not the right fit for the kind of tool you’re building, you shouldn’t remain bound to it. Because WordPress core has its own set of priorities and they will never be the same as yours.


Thanks Nate for the extremely cogent analysis of this niche. The thing I notice about WordPress in general and this nice as wells most other n inches within WordPress is that nothing is true for everyone all the time. With the possible exception of “Democratize Publishing” :slight_smile:

I agree that for a product like Conductor to “chase” a product like Beaver Builder would be not the way to go. There needs to be differentiation in this arena.

One of the main reasons I chose WordPress back a few years ago was because I sensed the inmate ability of it to solve many types of problems. Sure, there would be very specific vertical market areas that MAYBE something else would serve better, but for the most part, and certainly for my and my clients needs, WordPress solves any problem that I may come across. I knew I would hit my limitations long before I would hit those of WordPress.

And in the inimitable words of Chris Lema, which I kind of think that in this instance he borrowed from me :), “If there is not a plugin for what you want, just wait”. This philosophy has served me very well :slight_smile:

And I agree also that putting too many things in the Customizer does get awkward fairly fast. It seems like a good idea in theory, but in practice is a different beast.

For me, Beaver Builder combined the most of what I needed. Being originally from NetObjects school, I need easy and visual and just overall… easy. If you are not familiar with NetObjects, it wrote probably the worst code of anything ever. Gave Front Page a serious run for its money :slight_smile: Here is an example of a site that I did back when www.carvedhomesigns.com . Have a look at that code if you want a good laugh. And yet, that darn little site has been doing roughly $50K per year in business SINCE its inception. Yikes!

(Leland Fiegel) #5

Private companies. Hands down.

Private company innovations have occasionally made their way into core, like WooNav (eventually) becoming the WordPress 3.0+ menu system. I see it as the perfect breeding ground for innovation, whether it’s “core worthy” or not.

Not to detract from the core team, they’re doing a good job designing software for the masses, and the process understandably takes longer than a more nimble private product team that can pretty much do whatever they want without much consideration of the average WordPress user.

The experiences I’m attracted to are much more segmented, much like how @NateWr broke them down, and not really suitable one-size-fits-all solution for millions of sites. They’re better off in plugins. The most agreeable thing I can think of is a Lasso-style front-end editor.

As far as disrupting the WordPress experience goes, beyond some sort of page building functionality, I see a lot more Pickle in our future. Although it’s built on top of WordPress, you basically forget you’re using it.

(Nate Wright) #6

I like what Pickle is trying out, but it’s not a tool or a framework or even maybe a contribution to the ecosystem - except insofar as it is a cool proof-of-concept for people who want to build really tailored client experiences in the future.

I don’t mean that as a criticism of Pickle in any way. It’s a cool looking solution to a problem. But my gut feeling is that the target which could most benefit from it (self-starters, small-scale freelancers) won’t want to cut themselves off from the wider WP ecosystem by using such a ring-fenced solution. I’m glad he’s moved into a hosted solution. Although Happy Tables has a big head-start on him, it seems a much more appropriate market fit.

I think you’re right, @leland, that we’ll see a lot more of this in the future. But I wonder how viable solutions like this will be in the product space (rather than SaaS). I suspect the “page builders” or “layout managers” or “content editors” that survive will provide some sugar to WordPress without leaving it behind.

That’s entirely speculation though. In some sense, Visual Composer has created a market segment all by itself. Maybe a Pickle-like product can do the same.

(Benjamin Intal) #7

For me the core experience being updated by .org is really too slow. But I can’t blame the core team for it. WordPress is being used by a ton of people, and drastically changing stuff may not be well received.

Drastic and/or experimental changes are better off being brought upon by the private sector. As @leland pointed out, the menu system came from WooNav (didn’t know this beforehand, thanks for cool tidbit).

Regarding disrupting the whole experience, I’m all for it. There’s one major caveat for me on doing this though. Doing this shouldn’t affect the rest of the WordPress experience.

What do I mean by this? Take for example Visual Composer. It overhauled the entire visual editor, and it added a lot of new nifty stuff that you can now do because of it, however, it also somewhat limits you in other aspects. Yes you can view your items in visual blocks, but you lose the direct text editing experience. And you can’t go back to the normal way either since the contents get jumbled up with shortcodes. I’m just stating VC as an example though, I have nothing against Visual Composer, in fact I have a few plugins for sale which are extensions of it.

Dual experiences are okay, but it would be better if it was one.

(I’m plugging in our plugin, but it’s relevant in the discussion so I hope it’s okay). It’s for this reason why we came up with Page Builder Sandwich. It’s a page builder, but it’s on top of the existing visual editor. When you have it on you can actually forget that you have it turned on, since it just blends into the normal experience. You can edit your content normally, except now your shortcodes (if supported) look like actual rendered shortcodes, you can add columns that actually look like columns, and you can drag them around. So now instead of splitting up the experience between 1. the normal way and 2. the page builder and allowing the users to choose between the two, we’re just giving them 1. a page builder within the normal way

Give Page Builder Sandwich a try to see what I’m talking about :slight_smile:

(Ben) #8

Your plugin looks quite interesting - hadn’t seen it before. Thanks for the tip.

Out of interest have you seen the Shortcake plugin? It’s now a featured plugin so has the potential to be added to core one day. It works in a very similar way to your plugin.

There’s info on shortcake here: http://wptavern.com/shortcake-is-now-a-wordpress-feature-plugin

(Benjamin Intal) #9

@BinaryMoon Yup, we’re using it inside Sandwich and we’re also contributing to it :slight_smile:

Shortcake by itself is only a portion of Sandwich, but what’s great is that any shortcake-shortcode would be auto-supported by the page builder.

(Ben) #10

Ah - nice. Didn’t realise it made use of Shortcake. That’s even cooler then (and explains the similarities :)).

I totally agree with you that this form of Shortcodes is the future for page builders (at least as far as I require) - and being part of core means it will work nicely if/ when we get front end editing added to core.

I have a shortcode plugin that I worked on a while ago (and use on my personal site) that adds columns and other Medium style boxes/ quotes and I had been planning to wait for Shortcake support before publishing it. Will have to check out your plugin since it seems to do a lot of what I want to use! :smile:

(Benjamin Intal) #11

@BinaryMoon that would be great! Let me know what you think of it :slight_smile:

OT: I wanna make it extensible so if you’re interested in something like that let me know too :smile:

(Dan Knauss) #12

I’d like to have a both/and option. If I have to choose one, I prefer safer and slower, tried and true stuff that once was hot but now is taken for granted.

I think the pace of core development is pretty fast, all things considered, but the proliferation of “builders” does respond to a real deficit. I am sure one or more of them will influence core (and vice versa) until that deficit is a thing of the past, but the problem today is deciding what to use right now with so many options.

I’m attracted to a few of the new “builders” that are built and backed like they’re here for the long run. I don’t value them as hot or cutting edge; I value them for making WordPress more useful, usable, efficient, and versatile. I dislike but am less concerned about the UX fragmentation you describe than the prospect of adopting something that doesn’t hold up a year or two down the road.