Gutenberg Contributors Explore Adding Drag-and-Drop and Multi-Column Support for Blocks
The new Gutenberg editor has an open ticket for allowing users to sort blocks via drag and drop. Blocks can currently be sorted with up and down arrows located to the left of the content but the beta only allows for single-column stacking.
One of the goals for Gutenberg is to provide “a page building experience that makes it easy to create rich post layouts.” As far as layout building goes, the first planned versions of the new editor are very primitive as compared to Wix and Weebly’s drag and drop website builders where nearly every element on the page can be easily moved to a different position.
Contributors have been discussing the intricacies of adding this feature to Gutenberg since February. James Nylen summarized some of the challenges that make drag and drop more complicated to implement:
Dragging and dropping a block is not really a one-step operation. It is more like 3:
- Press and hold mouse button or screen
- Move to desired location
- Release
Step 2 is incredibly difficult to get right, and requires a lot of complicated behaviors like duplicating an item (or at least its general shape and size), scroll handling, and determining the intended new location, especially at the beginning and end of the content. We have all used bad drag-and-drop experiences, and I would argue they are worse than not having it at all.
That said, for two-dimensional movement with columns, I agree that arrows alone are probably not a good solution. Though mobile support for that is going to be very tricky no matter how it works.
Several commenters on the ticket agree that repeatedly clicking arrows to move blocks is cumbersome and will become untenable in the future when multi-column support is added. This would require up, down, right, and left arrows to rearrange content. Users have come to expect a drag-and-drop interface, because nearly every page builder application offers it.
“We are thinking of drag and drop as a progressive enhancement for desktops,” Joen Asmussen said. “One that would be great to have, but we should build it after we have explicit button actions in place for doing the same, including splitting into columns in the future. This decision is based on a desire to ensure accessibility as well as mobile devices can play the same game.”
Asmussen marked the ticket priority as low in May and removed it from the beta milestone. At this point, users are not likely to see drag and drop in the first release that ships with WordPress core.
Multi-Column Layouts Planned for Gutenberg V2
The discussion surrounding adding drag-and-drop to the editor naturally leads into adding multi-column support. Limiting users to a single column is a one-dimensional approach to designing pages, but contributors don’t plan to leave Gutenberg without multi-column support for long.
Geoarge Olaru, a designer at PixelGrade, shared a prototype for adding a simple two or three-grid column layout to Gutenberg.
“Extending WordPress further from the default Blog Posts automatically implies the need of multi-column layouts for presentation pages,” Olaru said. “I would prefer to tackle this feature upfront, rather than letting every developer do it on his own (see the multitude of page builders plugins).”
“For the V1 editor, I’m afraid columns like this is out of scope,” Asmussen said in reply to a Olaru’s ticket with mockups and a prototype for multi-column support. “That’s not a ‘no’ — rather, we need some technical foundations to be solid first, before we commit to the really interesting stuff. But it might be a V1.1, or at the very least something for the customization folks later on in the year. Even before that, it would be good to keep this UI in mind, so that perhaps a plugin can add this even earlier.”
Other commenters on the ticket feel more urgency about getting multi-column support into the first version of the editor. One of the concerns is that plugin developers will rush to add columns immediately based on demands from users, who will then have to migrate once core adds support.
“Multi column layouts are a must-have,” Anthony Hortin commented on the ticket. “At the moment, Gutenberg isn’t solving any issue. You still end up with one long column of content. The whole reason page builders are so popular, and why hundreds of thousands of people are using them, is because they provide the ability to easily make multi-column layouts. Without this functionality, you’re not providing any reason to use Gutenberg over a page builder plugin.”
One of the main challenges of adding multi-column support is figuring out what type of grid system to use and making sure that it scales from mobile to desktop. Weston Ruter joined the discussion to say that the foundational work for nested block support is being done now in version 1, but the UI for displaying them hasn’t been implemented yet.
“I appreciate the excitement and urgency to wanting columns,” Asmussen said. “We feel the same urgency. It’s not about not wanting columns, it’s purely about managing resources at this point.”
The good news is if you’ve been testing Gutenberg and wondering where some of these features are on the roadmap, they will be coming in later versions. While there may be disagreements about how much of a priority drag-and-drop and multi-column support should have for version 1, contributors agree that laying a solid technical foundation for these features is crucial for future extensibility.
26 Comments
So essentially, they are building not an editor, but builder, right?
Report
It looks like and that’s not really good news.
Report
I think it’s great. If they want to compete with the likes of Squarespace and Wix they need a builder.
Report
The problem here is that THEY want to compete with them but not necessarily the rest of us who just want to write posts and pages and don’t even care what Wix or Squarespace are doing.
Report
Well, if they create a kind of visual builder that delivers similar results like Page Builder, Beaver Builder or Visual Composer… that could be quite interesting in terms of the content that regular users can create then.
I mean, while TinyMCE is nice and you can do many things with it… it is kind of limited and “traditional”. This kind of editors was around back in the 2010 or earlier… and have not evolved a lot.
Of course, it will push the page builders even more “up”, forcing them to be much more “rich” in features. Or so, to make them “different” and “unique”.
In cases where you can’t afford to have a page builder (whatever reason it may be), having Gutenberg do this might be really useful.
I hope that they eventually deliver. For me, this is a move in the right direction.
Report
No way page builders create enough problems without the default editor becoming one.
Drag and drop is fine but things like columns are presentational so should not be part of an content editor.
Report
You have to think about the average user who just wants to get a website up. They don’t care about the differentiation between content and presentation. They just want to make this page two columns and so will turn to the tool that makes that easiest.
Report
That market will wither in time anyway. The future is using WordPress as a CMS.
Report
Having the chance to create columns if fine. It gives more options about how the regular user can display its content.
Of course, I would never expect for a non-techy person to learn HTML. Much less CSS or anything to just get that going. People are lazy.
Page Builders add bloat to WordPress like maybe Gutenberg will kind of do, but I bet there is a need for it… like it exists for Page Builders… especially at WP.com
Heck, Page Builders can even be hard to learn for non-techy people (you need basic CSS understanding at least)… and if they can’t use them… they will feel frustrated and blame WordPress for it… not the builder.
And I think they are aiming to eliminate that with Gutenberg and to provide a better experience to the regular user.
Report
Whoever has used Mailchimp UI would notice that they already developed a drag and drop feature like what is being tried right now with Gutenberg.
I wonder if the internal Mailchimp editor code is open?
I know that they have free services but their business model resembles the freemium model and not the OpenSource model, so it would not be so easy to study it…
Report
First, I’m glad to see that for the developers at least, accessibility is definitely a priority while building this. That’s encouraging. Hopefully, should the worst case senario happen, (Matt deciding that WCAG holds something up and so it has to be thrown out), the developers have some ammo. Second, I’m rooting for drag and drop to be added because of … wait for it … accessibility. For right now, with the current block-moving functionality, I and others like me who use only a keyboard have an advantage over everyone else. We’re used to interfaces like this, where you have to click arrows to move things. But for mouse users, that’s not something they’re used to, so it means that they have to conform their use patterns to the tech and not the other way around. In order for this to be accessible, it has to allow, (as much as possible), for users to operate it according to their choice, instead of being made to conform to the technology. That applies just as much to mouse users as much as it does to users with disabilities. I think it would be incredible if WordPress builds a page builder that anyone can use, regardless of whether or not they have a disability. It would be the first of its kind.
Report
Editors are for content not presentation.
Adding columns is a presentational feature.
If you want to change presentation ideally this should go in the theme. But if not install a page builder but don’t turn the editor into one.
To do so breaks wordpress as a cms.
Report
I agree. But I think we’re past the point where we can seriously expect that this isn’t going to be a page builder, so the next best option is one that everyone can use. As much as I’d love to force everyone to learn HTML before they could build their first website, that hasn’t worked, page builders have already proliferated, and so WordPress has no choice but to either keep up to compete, or risk becoming irrelevant. As much as it kills me to admit it, the standardistas lost this battle a long time ago.
Report
I agree.
Report
There is no need for the average user to learn HTML without a page builder. They just need a proper theme with a number of flexible options that suit their needs.
Standards usually win in the end. Locking into page builders is hamstringing the future of wp to capture a market in decline.
Report
Respectfully, a properly coded theme doesn’t fix HTML or other specification and standards validity problems inside content. The WordPress theme space, (along with every other web space), has demonstrated, en mass, that it has no regard for standards-compliant markup. So even if it were true that themes could handle any markup issues, they don’t, for the most part. As long as people are building websites, they should have learned or should be learning HTML, because good HTML underpins everything else: JS, PHP, everything but CSS. In the absence of that, any wysiwyg tools developers create need to handle that for them. Most don’t. Since we’re going the page builder route, then the best way forward is to ensure that users don’t have the opportunity to screw up something as foundational as markup without putting some work into that. Standards don’t win in the end. If they did, we wouldn’t have the mess that is current javascript practice, for example. WCAG, (or at least the “understanding” and “informative” docs), would probably be a lot shorter, because it could just assume that everybody writes good HTML and CSS, or that the crappy stuff hasn’t choked the internet. The first technique mentioned in every single accessibility talk wouldn’t have to be “Learn HTML”. So if users shouldn’t have to do this, then developers should ensure that they do their jobs, and make sure that users can build websites that don’t further the brokenness that is the web. I’d love to banish page builders for the sake of purity. That’s never going to happen. Almost from the beginning of wide-spread adoption of the web, they’ve existed. WordPress can’t at this point just say we’re going to avoid them, and we’re not going to have one in core. The community has already demonstrated that they serve a need. On top of that, WordPress either has to compete with what’s out there, (basically page builders but on a larger scale), or become irrelevant. Once irrelevant happens, all the purity in the world isn’t going to matter.
Report
Solid points on either side here. Ultimately I think this goes down to the implementation. An editor that has page building capabilities need not diminish the writing experience. Right now, I think Gutenberg adds far too much friction when purely writing.
If it doesn’t get that right, we’re failing writers.
And then it will be how WordPress created its own page builder just like every other service and cms, it doesn’t separate us from the crowd.
A page builder does not sympathize with an author trying to write good content, it only concerns itself with how it looks. I think the writing experience must come first. So I hope as Gutenberg evolves it manages to achieve that.
Report
Amanda,
You are right in one sense, most themes don’t support a proper seperation and most user don’t care
However:
1. If is perfectly achievable even with the current editor and themes (shortcodes muddy the waters a little).
2. Most users don’t know the harm/problems created by ignoring this separation.
As such I believe WordPress should not make things worse by going page builder with Gutenberg.
Especially as presentation is becoming commodified and the days of brochure sites is ending. The future is wordpress as a cms and page builders are antithetical to running a cms.
You are completely wrong about standards.
They do generally win in the end, especially online. See HTML, browser standards, mobile tech etc.
Report
“Editors are for content not presentation. Adding columns is a presentational feature. To do so breaks wordpress as a cms.”
Agreed. However, IMO most front end builders I’ve seen have already kowtowed to the users that wanted the editor and builder to exist in the same space despite any misgivings they may have had. It would not seem that people care anymore.
Those who have used or made builders like this have already violated this paradigm. So, at the very least the WordPress.org dev team wouldn’t be the first to do so.
Backend builders are often better at keeping things separate but these users don’t like them. That’s not to say that there are not those who don’t still prefer to do editing on the backend. I’m one of them.
Report
As I said in my previous post you are right in terms of user demand.
However I think we should give (and show) users what they need (rather than what they want),
The brochure site market is dying anyway so why not “skate to where the puck wil be” (rather than where it is now.
Report
Unless I missed the future of this….will all users be forced to use this, or can someone still use a third party editor to keep it as a standard method of creating content? I seriously have no desire to use this gutenberg editor.
Report
At this point I really wonder if there is any overall guideline for what goes in core vs not. I mean, if they want to add a full on page builder why not incorporate SEO plugin features? Table editing? Caching and security? Heck, just take the 5 or 10 most popular feature categories and add them to core!
I’m being somewhat facetious, but this direction is moving the editor far beyond simply being a better editor and toward replacing an entire ecosystem of plugins not to mention the content vs presentation issue.
This feels like the team is skating to where the puck is, vs where it will be. If they want to compete on features for the entry level user put that in WordPress.com and make it a plugin for the self-hosted version. But let’s skate to where the puck might be going and look at things like how to make distributed editing better, how to integrate with copy editing products like Google Docs and others, etc.
Report
Great analogy and advice
Report
imho, the content vs presentation paradigm only works until you want to post two images side by side and you don’t have time to figure it out on w3schools. I have angsted on editors since fkeditor showed up in php-nuke. Yet, I have serious issues with the WP page builders I’ve tried, so I don’t use them. I tried the new gutenberg, I’m so not impressed yet. I think we would all be happier if we brought back the use of tables. There was nothing wrong with a few and once you got to know them.
Report
I suggest you need to read up on standards and semantics.
The web is not just (or even) visual, side by side means nothing to a search engine, screen reader, text browser, scraper etc
Report
If Gutenberg gets rolled out without the ability to create multi-column layouts, I’m pretty confident in saying that this will cause a huge flood of complaints. And rightly so, in my opinion. As I intimated in my quote above, Gutenberg doesn’t currently provide any benefit over the existing TinyMCE editor, and in some use cases, actually makes things more cumbersome.
I think it would be significantly better to delay rollout until multi-column support is added, rather than opting to add it in “Version 2”. Let’s provide a half-decent editing experience straight-out-of-the-gate, rather than forcing people to wait even longer for something they’ve been begging for, for years. There are literally tens-of-thousands of people using page builder type functionality and if Gutenberg doesn’t provide, at the bare minimum, some sort of similar functionality such as multi-column support, then they’re only going to drive more and more people towards third-party editors.
Report
Comments are closed.