So if not Gutenberg then...?

Projects Core Development
1

I was told it would be worth opening a discussion here. As I type this, I’m entering text into a field that looks radically out of date. It’s not terrible, and I’m not faulting anyone, but this text area concept is very forum-esk (get to the point).

The point is, when we all create high quality, engaging experiences, things like the spacing around this area matter. The capabilities of this space, the body blob of a post / comment / page / etc, really matter if we’re going to sell the content experiences that we can produce. WordPress / ClassicPress might be the most easy tool in the world to use, but if it doesn’t have a second to none Authoring experience, it’s only going to have a maximal audience of about what it is currently: A lot, but not getting bigger and the forces of closed source (wix, squarespace, etc) will gobble it up.

I see Gutenberg as a reaction to attempting to combat these forces. The forces of the JS community that will destroy all the amazing things we’ve all made (I come from Drupal originally, 13 years there, 100+ module contributions). So I’m here to offer a conversation starter around authoring experience, and the notion of discussing alternatives to Gutenberg that offer parts of it’s promise (ease of use, slick presentation, extensibility) without all the negatives (accessibility an after thought, React centric world view, content lock in, lack of compatibility with what’s previously been made).

I’ve been telling the Drupal community for 2 years we need a way to survive the coming slick presentation methodologies that are nipping at the heals of CMS monoliths and they’ve largely sat on their hands; tied to sunk cost paradigms. So here, I offer an alternative vision to the madness called HAXTheWeb (https://haxtheweb.org/wordpress).

HAX is short for Headless Authoring Experience. It’s pieces of the vision of Gutenberg, but untethered from any CMS-isms. It has an integration methodology much closer to TinyMCE. In fact, to use HAX in WordPress, the integration takes the TinyMCE text area and then swaps it out at load with HAX.

HAX operates by understanding what’s inside of it’s tag () area. HAX is headless and able to be plugged into so many things so rapidly (we have Drupal 6,7,8, Backdrop, GravCMS, WordPress, desktop work, and a headless CMS called HAXcms integrations) because it leverages the web component standard. Unlike Gutenberg, you extend HAX by extending the web. Custom elements (let’s say tab-list) are built as pure design assets that leverage the Web components specification like an API on the front end. This allows us to build out visual assets that work on any website.

On the HAX editor side, HAX doesn’t understand anything beyond HTML primitives out of the box. The Web components / design assets that wish to work with HAX, emit an abstraction of JSON Schema via a normalized event. This way those assets work without HAX present, though if HAX is on the interface (via that tag) it’s listening for the event and then grabs the definition. When the user selects a custom element in the page that matches a definition it knows, HAX is able to headlessly build the input form to match.

(So why am I here)
I see that you’ve forked from WordPress at least in part because of the lack of future thinking direction involving Gutenberg. Gberg is a cool system, but it’s fatally flawed. It assumes too much knowledge of react to develop for. It breaks compatibility w/ large parts of a vibrant ecosystem. And it was built inspite of mass community uproar about it. It’s also ensuring a future in which WordPress is the system for running Gutenberg, making future migrations more difficult (I’ve seen this in Drupal for years so…).

So I’m here to see if we can find common ground. See if there’s any interest in a Gutenberg alternative that could drive more WordPress people here or force change within the WordPress community as a result of one of there forks having a better, more flexible, future focused editor then they have. For additional context on HAX you can read through the doc site, or you can play with it in a code pen loaded headlessly in the page and see all that it has to offer already and know that a major university is backing the development and future of it – https://codepen.io/btopro/pen/VqBjPw

I look forward to any discussion that might arise from this, thank you for your courage in standing up to the direction of the crowd. BackDropCMS did this in Drupal 7-8 transition and it’s created a brighter, more vibrant community alternative as well as a legitimate conversation starter and challenge to a community going off course.

6 Likes
2

A couple of months before Matt Mullenweg announced the Gutenberg project, I had started looking at possible alternatives to TinyMCE. I tried a lot of them. So I was certainly ready for a new editor. But Gutenberg was not it: far from it!

I remain interested in replacing TinyMCE with something lighter and nicer to use. But my brief trial of HAX didn’t suggest it was what I personally am looking for. It seems to me to make the same fundamental mistake as Gutenberg in that it wants me to define a component before I create it. Why? When I’m writing – and I write a lot – I don’t want to be constantly interrupted by the software asking me questions. It needs to get out of my way and let me write. I can come back later and decide how to designate each section.

Maybe I’m not your target market. (My favorite writing software – by a long way – is LyX. It does the very opposite of Gutenberg and keeps form and content separate.) But I’ll keep an eye on HAX’s progress to see how it develops.

4 Likes
3

My guess is you like ghost, medium, markdown style pure writing. I get that though I wrote all the docs for the system recently using the editor itself which is way more text heavy. We still have work to do for sure but I agree with you writing should be the primary / emphasized method.

4

Sorry, but I hate Markdown. I don’t want to be typing symbols or code. I just want to type in the language in which I am thinking.

3 Likes
5

@james is our lead dev so I’m tagging him here — thanks for opening this discussion!

3 Likes
6

not a huge MD fan either because of design limitations, just meant in concept. A lot of ppl claim to enjoy MD based solutions because of the pure writing form (went to a humanities conference where non-technical ppl are teaching each other markdown for this reason).

7

Yes, I know the sort of people you mean!

I like LyX because it gives me the power of LaTeX without having to learn LaTeX. It’s like being able to type in the WP/CP editor and then letting the theme make it all look good.

8

Yes, this is the way it should work. I don’t trust a lot of users with page builders / block editors. They end up changing the look and feel of the site. They are good for certain things, but not for general post writing.

I do like markdown. To me the biggest distraction is using the mouse. With markdown I can set headings, bold, and italics from the keyboard without breaking my rhythm.

1 Like
9

Might be worthwhile creating a plugin for ClassicPress as (a) proof concept and (b) for community testing.

Once tried and tested the community can vote on retaining it as a plugin or request for it to be merged into CP core

Might gain traction as a plugin since the community is advocating for a leaner bloat less core code

5 Likes
10

Everything has purpose for people that need it, and it doesn’t for people that don’t.

Markdown isn’t for writers, it’s for developers. You can’t bold or italicize when writing in console, so you use markdown.

Even Gutenberg has its purpose, as ugly as it is. It helps WordPress.com compete against website builders and against page builder plugins. At least that’s what I think, why Gutenberg was pushed down our throats.

Many bloggers (most?) hate Gutenberg because it completely changed UI/UX making it harder to simply write. Now they have to build a blog post, not just write it. This is akin to UK switching to driving on the right side of the road. Or US using metric system.

People are used to writing using TinyMCE because many text editors - online and desktop - conditioned users to this type of UI/UX to write. MS Word, Open Office, Google Docs, etc.

One thing to consider, since CP is business focused, business customers might expect to see TinyMCE because that’s what they used to and that’s what they use internally. This is just a thought, I don’t know if it’s valid or not.

And HAX, it’s quiet an annoying text editor. That toolbar always visible as you write right above is very distracting and it visually forces you into blocks. Having a border around paragraphs. The UI/UX is not intuitive, it’s asking me to waste time trying to figure it out. We’d be back with our own Gutenberg fiasco.

This was discussed before, and to quote James:

I wouldn’t replace TinyMCE in the core, but making it easier to allow a plugin to replace it if needed could definitely be something worth exploring.

9 Likes
11

But that is surely just a criticism of this forum software which does seem a bit confusing and clunky.

There are other forum softwares (e.g. Xenforo) that are a lot better (IMO), more intuitive to understand.

As I see it though, the old WP editor was very good. Surely it would have been possible to integrate some blocks into it for those people who wanted blocks, but could be ignored by those who just wanted to write.

For example, inserting an image with a caption is a block as far as I can see. You admit, edit the alignment and size it floats on the page how you want.

Something similar but a text box would be ideal, something like you might at in MS Word or Mac pages for a floating text box.

But this may be what so many people are bashing WP for on the forums, making Gutenberg the cor default not something as an option for those who want it.

12

The forum text area (which is fine for this type of conversation) was an entry point to the authoring experience setup :slight_smile:.

I believe this is the case too (as an outsider). I can’t believe they replaced Tiny as core editor and have said they are deprecating that. I’m obviously building something that at least will draw comparisons and I’d never force that option on anyone without having Tiny / a baseline editor for fallback among my own user base. Now, if there was like Gutenberg: a WP Production and it was default there… I think there would be less headaches for all :slight_smile:

13

Hi @btopro, thanks for starting this thread. It’s clear already that different people want very different things out of an editor.

I like Markdown, personally. Though I think it depends somewhat on what you are trying to do. Most of what I write is text with lists and links.

If I were making more image-heavy landing pages, I’d probably want something that knows how to deal with components or blocks.

Ok, I suppose now is as good a time as any to unpack this quote a bit :slight_smile:

We’ll definitely keep TinyMCE for our initial long-term-support release series, v1.x. The goal there is to provide a stable, predictable option for people to build websites on, and what better platform than the classic editor with TinyMCE? This is stable, proven technology that has been used for millions of sites and billions of conent edits.

Which editor ClassicPress uses by default in future versions is up to the committee. We’ve already set the direction for the v2 release series, which is around building a ClassicPress plugin directory and moving some less-used features of the core software out into plugins.

Having our own plugin directory will also allow us to provide and recommend plugins like an alternative editing experience. This would be opt-in by default, and I could definitely see HAX fitting into that kind of role in the ClassicPress ecosystem.

In order to change from TinyMCE to another default editor in a future version of ClassicPress, we’d have to get lots of testing via a plugin, and wide agreement among the community that this is a change we want to make.

So far the way we collect and measure this agreement is via votes on our petitions site, but I’m happy to discuss future plans and HAX in general here too.

:clap: :clap: :clap:

Thank you for using web components!

I will make some time to try out HAX soon, in the meantime I have a few questions:

  • I’ve shared a bit of my perspective here, but what do you think HAX’s role could be in the ClassicPress ecosystem?

  • How does the HAX editor behave in terms of backwards and forwards compatibility with TinyMCE? If I make a complicated post in TinyMCE, how does it translate over to the HAX editor? If I make a complicated post in HAX, and then disable it and edit it via TinyMCE, what happens?

  • I’ve thought for a while that it could be interesting to leave post_content as rich text using TinyMCE, but start to think of a post as a list of one or more custom fields, of which post_content is just one. This could avoid some of the pitfalls of storing a blob of structured content inside the unstructured not-quite-HTML post_content field, and it could also be a way around many potential backwards compatibility issues. Is storing each component as a custom field a direction that you considered for HAX?

2 Likes
14

great discussion, thank you for the feedback and reasoning

Absolutely, starting this was more to hash that out then anything else really. While I work in HAX land, my intention wasn’t to suggest “make this your default editor” it was more as you suggest in the plugin ecosystem. If there’s a place for HAX in the ClassicPress ecosystem where we work on HAX to passively support the use-case you suggest (needs to work with Tiny, needs to work with older stuff, needs to work before and after HAX is enabled).

This was intended less of a “ADOPT HAX OR DIE” (that’s the slant for Drupal :wink: ) and more that our mindsets of “hey I have a lot of stuff I made before and you can’t break all that compatibility over night without pissing me off” which could help provide a place for ideas to bounce back and forth.

It could also be that when people eventually say “but I kinda want to play with a block editor” that if we can get HAX to a point where people in this community feel it’s a viable enhancement to ClassicPress because it’s philosophically aligned, to do so (organically, not as like some edict).

To your questions (the above is addressing the 1st one)…
The current plugin’s integration requires TinyMCE… as it then jumps in and hollows it out and replaces the body blob of contents of Tiny as the starting point for HAX’s editor. It’s similar integration to how Tiny injects it’s JS and hijacks what otherwise would be a bland textarea input.

I’m not sure how it translates complex post over to HAX, should render, it’s just presenting HTML after all. If the DOM of that tiny area is deeper then 2 levels of hierarchy it won’t break HAX just many conventions in it won’t recognize it to do anything meaningful. HAX is a “block” editor but without rigidly defined BS react blocks. our “Blocks” are normal paragraph tags, divs, iframes, and yes custom elements / web components.

HAX doesn’t have a concept of fields, though if you’ve played with any of the demos you might be referencing the edit form for a video or any other web component. HAX is reading JSON Schema dynamically off of the web component and building a form which is saving the data by writing HTML in the page that matches the properties, attributes, and slotted (inner HTML that’s tagged) areas. By doing this, you can get highly structured content in concept yet in the DOM it’s still a single or handful of tags being placed in the page with properties filled out in the tag. Complex (array / object) data is json encoded and stored w/ the element though we only have a few elements that operate this way and largely don’t recommend it unless it’s absolutely necessary (image gallery, tab list, play list of media as possible examples).

Again, not trying to coopt nor would I want HAX to be the default editor of an ecosystem (I’ve got 6 ecosystems I’m playing in at the same time + 2 of my own platform I’m building that it’ll be the default in). But, given the philosophical alignment we have in our projects if there’s any room for people in this community to try HAX inside of ClassicPress (via plugin) and offer feedback on how we can make it work better with TinyMCE to augment when needed, or provide an alternative perspective, it’s something that I think could help both projects.

My community wants to simplify the transition from old to new world editors instead of just flipping people the bird so feedback in how we can make the more possible is invaluable to us. Also, long term, the Gutenberg question from clients of having website tonight software and “why dont I just use Wix” will keep being a nagging issue and maybe, if it becomes a viable solution to people, HAX can be one of those options without people going back to Gutenberg which will not adopt our vision of the future.

7 Likes
15

I love medium way of writing ( i hoped Gutemberg was like that when they announced it).
to say the truth also Facebook note editor and Linkedin is Ok…

Manolo

16

This is how a proper CMS should be buildt. Even having opportunity to install Gutenberg editor, if someone misses that. Freedom (in form of plugins) vs. dictatorship.

7 Likes
17

:heart_eyes:

4 Likes
18

4 posts were split to a new topic: Accesibility and UX in HAX

19

I think the future is about properly structured content, like https://sanity.io.

The thing that most put me off about Gutenberg (apart from the dictatorial approach), was the use of html comments to delineate the blocks in the DB. This is just crazy, and a nightmare if you wish to consume data from WordPress with another system like Gatsby. Blocks done right, with their own DB tables and all, would be fantastic for WordPress / ClassicPress.

8 Likes
20

Absolutely right about the use of HTML comments. Sheer madness!

4 Likes