Development of an editor for creating web sites / landing pages (experience)

(Art by http://www.simonstalenhag.se/ )

Background / Disclaimer

Hello everyone, this article is in fact material for my performance on Monday at the marathon in Kiev. But do not think that you are the audience on which I work out the text, it's just easier for me to prepare.

At the moment I am a front-end developer at Conductor / WeWork. We are not engaged in the development of editors, as I, in the evenings, do not develop such things. This is more about the experience that I received on the past project in the company UTI (abbreviated), use it,…. It was a long time ago, but as it turns out, the topic is relevant to this day, as are the jambs associated with it.

This is usually about the site business cards, landing pages, and less functional sites, but of course not about the back office or admin.

UTIEditor special for you <3

Why do we need such editors?

There are quite a lot of answers to this question, many of you, I am sure, guess so.
I will answer this question from the point of view of UTI, a company that provides website development services.

UTI is essentially a company of consumer goods. I am sure that everyone worked in such a time, a dozen business card sites per person, a dozen online stores and a branded cherry - its own CMS.

You made another landing page, a business card site and gave it to the client, and he resorts in a day and asks to change the text. After another day, change the background color and add just one picture. For the client, it looks like something simple and fast. It's hard to argue with that, it is. But for you, this means that you need to pull the developer / designer out of his current tasks. Not to mention the work of a manager who spends time on communication. Accordingly, you invoice and it is not small. The customer is indignant and complains. The next time you think in advance about such things and start asking questions, lay the editing functionality in the TOR.

It is probably worth going to discuss this functionality, because it is very different.
I would like to add that I will not include such CMS as WrodPress, Drupal in this conversation, we will concentrate on the market of editors.

Wilds UTI

The first thing that comes to mind is to make a form where the user can change what he wants:

The name of the fields is not a bit of real life, but you have caught the essence.

From the point of view of the company, she fulfilled her duty and even took care of "customization". But this approach still has a number of limitations.

Advantages of this approach:

• Easy to implement
• Easy to use
• Solves the problem

Cons of this approach:

• There is no possibility to change the design
• No way to change behavior
• No positioning
• You can edit, only, what was put in the form

Have you thought about KEeditor yet ? The star of all time. By complaining this is the next step to improve the editable content on the site.

There is a kind of possibility to format the text and even insert some additional elements. Somewhere in this place, before I came to the company, the guys had an idea, to make a page editor with drag and drop right in CKEditor. I unfortunately do not have anything left that I could show, but you try to imagine this horror :)

But at the moment, in 2018, so to speak, CKEditor has advanced a bit in this direction, which is quite funny. What is not a full page?

But all this was not convenient both in development and in use. And knowing only backbone and jquery, I already boldly called myself a front-end developer and decided to offer them to develop a full-fledged editor, like Wix, Squarespace, Tilda, LPGenerator ... Then they were in fact my competitors. But since UTI is a no-name company, they did not know about it. And they did not know and will not know. Although the marathon sponsor is Wix. Oh, this is just a coincidence.

They did not recognize, because everything according to the classics - the companies did not care about the project.

These are two screencasts, they are not perfect, with jambs, but I am sure they will provide a general idea of ​​the editor.

On this project, I was alone. Designer, product manager, front and back, and there were no tests and no. But the truth was the manual testers who, when they came to the company, were tempered in the fire of the reactor. Of course, testers were fun. What would you understand the level - once, one of them knocked out:

And I filed a bug, they say the site does not work. The guy just dropped the internet cord from the system unit :)

Every time I had to explain in a new way, what could be done in the editor, what was wrong and why it worked like that, and that’s how it was. In fact, for me it was fun. A kind of first line of feedback. There were practically no customers and the editor evolved for the most part thanks to them.

Does anyone have any idea what stack I used? The app looks great, solid so to speak. It is not buggy as it was not buggy 5 years ago.

Oh, and what a smart CI / CD process I have. In prod left as much as you want once a day. Codenamed Filezilla, drag and drop, repeat. First you connect via FTP using filezilla, do a build, download the current build, put it in a folder called backup, download a new build, and check if anyone died there. If all the same died, then upload the file from the backup folder. But to be honest, the moment with backup, I did not always depend on a set of new functionality. And considering that the editor was in several projects, to say that I went into each one and checked if it fell there, that I wouldn't either. Did we still use svn, adds flavor?

What about the stack?

Backbone + jquery + 0 tests.

Module, asynchronous loading ala code spliting and serverside rendering. Then such terms were not particularly used, it was a de facto simple optimization. But now is the time marketing in open source and its revolution!

What would you understand, Wix of that time, now is not very different from the Wix editor. Is that more templates, blanks and finished components. They migrated the reactor, completely or not, I do not know. It is absolutely buggy in the same way, only on MacBooks with 16gigov RAM, with a steeper rendering system called Virtual House and cool web engines. In projects of this scale, tools do not play a special role, this is more a conversation about architecture and UI / UX. And UI / UX is much more important. It depends on the complexity of implementation, performance and the level of desire to kill yourself when creating a web site by your editor. Clients will generally be far from development, far from all of these CSS rules, properties, DOM attributes and parameters. Among them will be more or less knowledgeable people who will serve your customers and continue to divert them. But let's not talk about sad things, let's try to consider generations of editors a little further.

Clients, if they are given the perfect editing tool, will still not be able to use it. Their crafts will look something like this:

This is true and not true, since the web is just difficult for the humanities, and on the other hand, somewhere there is a perfect UI / UX that will allow you to click a button to make a website, do what you want.

But sometimes it is impossible and have to look for a middle ground.

Visual HTML editor

The initial task was this - do it the same way as in CKEditor, so that you can move the elements (text, pictures) and somehow edit / format them.

Also one of the main requirements was the ability to load custom HTML, for further work.

I started by making elements on a draggable page. That is, the user could move them. At first, everything seemed fine, but the more different pieces I tried, the worse it looked. The fact is that custom HTML can be completely arbitrary and not predictable. This leads to the problems of the elementary drag and drop task, the impossibility of understanding what the user has chosen for the element and even it is banal to have control over the page. It was chaos.

Grapesjs allows you to upload your HTML. The text wrapped in obvious tags, he sees, and the text that is just in the body , he does not feel:

Restrictions

Making it possible to upload your HTML, and edit it, is of course a bold move. From the point of view of the user, this is a great freedom. But here is a wonderful example of how things are on the web - A Blue Box .

I am sure there are not even all implementation options. The fact is that the same things in terms of semantics can be implemented in completely different ways, using completely different approaches. And imagine, on the page, something more complicated than a blue square. The same picture can be added to the page using the <img /> tag or set using the background. The button can be <button>, or it can be convoluted by a <div> or the same picture. And how to understand which editing tool to show?

No

00 limit

The next choice is to prohibit a particular layout, make a styling guide or prohibit uploading custom HTML. Of course we chose the second :)

Limit 01

Since we have banned loading custom HTML, we need our own components / elements, and this is the first step to the real editor.

Limit 02

Since the user will work with a number of our elements, we must prohibit the editor to work with not "our elements" and teach them how to work with them.

Work environment

Not the most interesting topic, but important. I really like the photoshop interface. There are a number of panels and a workspace. You can manipulate the work area as you want, it is centered and, depending on the size, you can scroll both horizontally and vertically.

Just a lot of me touched my design Google Web Designer:

By the way, is it some kind of Google editor, did someone use it?

The most difficult thing is to split the page in this way. I am not a CSS expert, and this time it was much easier for me, but then it was dancing with tabular layout. Before we go any further, let's see what kind of working area laites are in general.

Photoshop

LPGenerator

My creation

Grapesjs

In fact, we have already discussed this layau above. On the left are frequently used tools, on the right are the parameters, on the top is something extra, on the bottom is the information bar. The most obvious option, but at the same time overloaded for the user. He is afraid of all these buttons, as if he is in the cockpit and he needs to make an emergency landing.

So overwhelmed to hide everything

Wix

For 5 years, the design of Vicks has changed little. Going into the LPGenerator, you immediately realize that you can drag an element to the page, see the settings, and so on. In the case of Wix, everything is initially hidden. This is a good approach. The fact is that the user does not need to see what he most likely will not need at the moment. But here you need to keep a balance. Wix.com has too many elements that you can add to the page and that’s why they made a whole gallery of elements. But of course, obvious things like text or a button could be put on one of the panels for quick access.

When you click on an element, additional functionality appears above it, which refers to the element.

Implement such a thing that still hemorrhagic, we will talk about this a little later.

Minimalist

Squarespace

The minimal design, the work area occupies most of the screen, from the interface the most necessary minimum. The tool kit is very strange. For example, this is how the first screen with a button is edited:

The button here is represented by text.

By itself, the editing mode is very similar to the preview and only with a double click on some screens, it turns out to go into editing mode.

At the same time, the editor moves us to another part of the application.

I eat grut

Tilda

Editing the site, you seem to be on it. Very similar to Wordpress and its top panel with editing / publishing functionality and more. But at the same time, the functionality is not as stop as that of Squarespace and the same text is much easier to edit.

To add something, you need to click on +. To transfer the button to any place convenient for you, it will not be so easy. All is limited.

The consequence of this are such galleries with a bunch of different variants of the same element.

As you could understand, I'm a fan of photoshop. I once suffered with a table layout, but now 2018 and for educational purposes, we can give a damn about support and implement barking on CSS Grids.

If someone is not familiar with CSS grids, then this is one of the latest ways to lay out page layup. If Flexbox is preferable to use for menus, molds and other elements of the elements, then CSS Grids, feel great in global things.

This is not a CSS Grids tutorial, so I’ll explain in a nutshell, but without mega details.

And so our task is to make the left and right panels, and in the middle of the working area where the content of the web site will be displayed.

Working with grids is a bit easier in FireFox, which is strange, but chrome is lagging behind in this. In one of the past articles I have already talked about this.

What does the grid inspection in chrome look like:

At the same time in the mace:

There is a mini grid view, semantic column / row labels are shown. So if you want more information, use FireFox for now. Strange, I feel recommending this browser. Bugzilla time has passed.

Let's start with simple markup.

 <div class="main"> <div class="left"></div> <div class="content"> <div class="site"></div> </div> <div class="right"></div> </div> 

.left - left panel
.content - the middle where the site will be displayed
.right - right panel

As long as it is small on what looks like. We want our interface to be equal to Viewport. This can be done with the help of height: 100% , but there is also a viewport units vh and vw . We will use them.

 .main { height: 100vw; } 

By default, children are converted to strings. This is a kind of flexbox axis. We need to specify the columns, it can be done in the following way:

 .main { display: grid; /* grid-template-columns: 1fr 2fr 1fr; */ grid-template-columns: minmax(200px, .4fr) minmax(560px, 2fr) minmax(200px, .4fr); } 

By trial and error I came to a rather complicated template. The minmax function allows you to set the maximum and minimum sizes. fr is a universal unit that saves us from counting the sizes in pixels or percentages. The fact is that such properties as grid-gap affect the size of a border . fr designed to save us from this pain.

We tint a little and remove the margin on the body , it hinders us a little:

  body { margin: 0px; } .left, .content, .right { box-sizing: border-box; border: solid 1px; } 

Super. But it was the easiest part. Now we need to make the workspace.
.site is our imaginary site. Let's make it into standard 960px and highlight it.

 .site { height: 2000px; width: 960px; background: rebeccapurple; } 

If you squeeze this thing, it's still more fun:

But

 .content { overflow: scroll; } 

Solves the problem. Only the aesthetic part remains. Indentation.

This can be done using the margin :

  margin: auto; margin-top: 20px; margin-bottom: 20px; 

20px few or many to you. But there is another problem. If the screen is too small, there will be no padding on the left and right. Since maring: auto will be cramped. The first thing that comes to mind is to set margin-left and margin-right , but there’s another joke. Indent will be only at the left side. If you skip to the right, then it will not be there. This is such a feature.

Without going into details, this can be fixed using display: inline-block . Yeah. But at the same time, we will break the margin: auto which behaves very well with large screen sizes. The next most obvious solution is to use Media Queries. On large screens, display: block + margin: auto , on small display: inline-block; margin-left/right: 20px display: inline-block; margin-left/right: 20px .

  .site{ height: 2000px; width: 960px; margin: auto; margin-top: 20px; margin-bottom: 20px; background: rebeccapurple; } @media(max-width: 1350px) { .site { display: inline-block; margin: 20px; } } 

Something like that. If someone has better ideas, welcome to the comments.

Site display

Layout is ready, now you need to display the site that the user will edit. This is a very important thing. A number of decisions depend on it. Display a site for editing after the fact, in two ways. In the document , where is the interface of your editor or in the iframe . Both options have positive and not very positive properties.

Same document

It is easier, both mentally and technically. But much more problematic in the future. The fact is that if you add, and you add, the ability to insert custom CSS and JS, your editor will be blown up after a few minutes.

Users who did not explain how to use the mug:

Encapsulated CSS is not yet a reality like it was 5 years ago. There are options, but they are either too heavy or do not fully protect. When the user skews the entire interface and accidentally deletes all of their work, they will blame you. Running a little ahead, when you decide to add a number of your ready-made templates, your developers will suffer with this. How not to override some style. Now if you look at Tilda, they have trouble with this.

Take for example the first UI of this editor. Text formatting buttons:

Do you see these styles? !important on color? These styles are not needed at all, if you turn them off, then nothing will change. In any case, redefining them is very simple by inserting custom HTML into the site page:

I admit, I inserted this code in manual. But I found a free 2-week period with the ability to insert custom HTML and CSS, and achieved exactly the same effect.

How can you? Just imagine, you bought services to develop a site in Tilda for n thousand dollars, and you wanted to set your own style for links. Everything, the site cannot be edited by the user Well, I exaggerate with the boarders, but you can imagine any other style, not to mention the custom JS. Moreover, the conflict extends to even some nested interface, although it is obvious.

Not allowing users to insert their own code will be the solution to this problem. But in the real world it is almost impossible. You will not do custom integration for each user. This is possible with fat clients. But not when you have 90% of the functionality is 5-10 bucks.

Iframe

Almost completely encapsulate the page, iframe will help us. This is probably the only place where I used the iframe so long. We can reach the content of the iframe and even vice versa, if they are on the same domain. That's why we have everything under control. But all such encapsulation puzzles us a little. For example, the selection of elements, which we will discuss later. Select it with elements at the interface level positioning above the iframe , or in the iframe itself?

Of course, it will be easier to do this in the iframe itself. The fact is that when scrolling content, you do not have to update the position of the selection / think about the sly layout (although better so), and an additional interface. But calculating whether your interface overlaps, the editor interface will be easier if you render such things over an iframe in one document . For this example, Grapesjs combines these two approaches:

Selection occurs with elements in the iframe , and additional functionality that is sensitive to overlap is rendered on top of the iframe .

But to support your styles, you have to import everything you need into an iframe . Immediately you will have to attach the boot screen, so that the user does not see the site / interface is not made up.

Wix <head>

Therefore, you should understand that doing this is necessary only when editing. And do not forget about the user style or you will again have problems.

Grapesjs class which I "accidentally" updated the border:

Grapesjs adds the gjs-comp-selected class gjs-comp-selected , which is clearly visible during the inspection and believe it will be the first thing the user will copy for customization.

Select items

We are a little ahead of ourselves, because we have not yet understood how to teach the editor to see elements on the page, but this does not hurt us. Before delving into a more technologically complex topic, let's see how technologically difficult it is to make the selection of elements on the page :) Do you think it is difficult? If you are very self-confident, then this is how all the above-mentioned editors deal with this with the text as an example:

My editor

Tilda

Grapesjs

Google Web Designer

Wix

And when editing

Part of the text is not visible at all. Okay. From the point of view of the front-end developer, this is a feature.

The fact is that the editors distinguish for the most part the DOM model. But judge for yourself, you as a user, far from the development of sites, think it is ok? No, it is not ok. Content is more than what the editor shows you. In the case of some, there is a chance of losing the ability to select an item. It is normal for a browser to be allocated in this way for developers, this is true by specification.

What the user sees (blue, the text made transparent, for obvious problems), which is highlighted by editors, browsers (red):

Chrome

Firefox

When selecting text in FF, chrome does not know how.

So why such a joint in all editors? In my experience I will say that this is noodles on the ears of product managers and / or testers. Anyone who works on an editor is usually unlikely to put line-height: 1px , or try to play with different styles and sizes of text. They have zamylennye eyes and such shoals at first glance, the elementary remain in the blind zone. And customers believe, they face them during the first minutes.

From the point of view of UI / UX, this may not be a technically understandable thing, and such implementation details are usually left to the discretion of the developer.

So is it possible to make a selection of user friendly? Any ideas how to highlight an item?
It is necessary to include such things as selection. margin , padding, border. Sizing model is not simple:

From my sandbox:

Perhaps the most useful information I extracted from msdn:

But even here there is no answer to our question.

Let's try what the DOM provides to us first. We have such a layout:

  font-size: 54px; line-height: 0px; /*   ,     */ border: 10px solid; padding: 10px; 

The size of visible content is 62px, the browser shows us 40px. How to get 62px?

getBoundingClientRect returns us - 40px
clientHeight - 20px
scrollHeight - 41px

You can play with mathematics for a very long time, but I did not find solutions using this approach.
But, like ~ 5 years ago, I knew that the solution to the selection of the text. Well, look, if you select the text, the selection is exactly the same as we need:

Not a good example, but the height with which we have the main problem - everything is cool. But how to allocate as it does some kind of systemic magic?

After so many years, I googled (learned!), Unfortunately I was googling and the link was lost, but here’s the solution:

  const range = document.createRange(); let rangeRect; range.selectNode(elm); rangeRect = range.getBoundingClientRect(); 

Create a range , select the node, and take from the range ClientRect . Voila! Moreover, the selection works for everything. You can select whole pieces of the page ( https://developer.mozilla.org/en-US/docs/Web/API/Range ).

Both in height and width, the perfect selection.

(The selection in the editor will be a blue border, no background. I selected the text to show the system selection.)

Another less important part of the selection is how to show it? Any ideas? Ways a bunch. Starting from the boarder, ending with an additional floating element.

First of all, decide to do it in the iframe or above the iframe , we talked about the pros and cons above.

Border does not fit, as it adds the size of the element and that if the user sets his border element? The same is the outline , Grapesjs sins by making a selection through it.

In my case, I used :: before, but this is not cool either. The most reliable way to do this is either 4 strips, and position them along the edges (which later will be elements of the element reysing), or block them on top. Choose the best of these two options, the maximum combining them. Too much positioning on the page is not help in optimizing an already overloaded UI. So, the more multi-functional things you position, the better.

It's not all

We just implemented the selection. But this selection at the level of "brought and saw." Two problems are still connected with it which I will leave to you to think for yourself. They are not so nasty.

1. Element dimensions change when editing. You need to monitor this and update the selection. This is what my editor and Google Web Designer are ill with. Not always, but often.
2. To make a label / selection on an element, letting the user know what kind of element it is, you need to know yourself what it is. For this element must be initialized in your editor. From this depends on the performance of the editor. There can be more than one hundred elements on a page, and simply taking and initializing everything at the start is not always the best idea. But in the case of my editor, like ok. haha Initialization can be done on click, on hover, on the theory of frequency of use.

Editing

Since we are talking about the selection of the text as an example, let's quickly go through editing it.

In fact, the text is the second important part in the editor after picture and highlighting :)

Well, how to make it so that when I selected a part of the text and clicked on some formatting functionality, I formatted the selected text?

If you are the son of my mother's girlfriend and a genius developer, then you will surely say - wrap the selected text. Oh, and you will be right, approximately as if Ilon replied that he should build a rocket === to hire a hundred engineers.

Wrapping selected text is not easy. As a result, there will be a bunch of tags, and how to merge them with the next selection and formatting is a big question. I studied the same CKEditor for a long time and found a miracle:

 contentEditable 

( https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/contentEditable )

This is a pancake editor in the browser. He does not just give us the opportunity to write text, but also to format it.

Related articles:

• https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content/Rich-Text_Editing_in_Mozilla
• https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content

This API allows you to execute formatting commands on selected text:

 bool = document.execCommand(aCommandName, aShowDefaultUI, aValueArgument) 

, , , .

. , , . , . . , .

contentEditable . , . . , . .

, contentEditable , CKEditor, CodeMirror, . . , .

, . , , CKEditor. , . , , . iframe . , . , /. contentEditable . contentEditable . Wix, 2018 . , iframe . :) , , . , , . . , . , .

:

:

.

, , , , / , / . 0,0 , :

(svg/dom element)

, VC++, MVC

, , Visual C++, C#, Delphi . - , Backbone , , //.

, - , , , . :

, , .

, CSS, .

Backbone, (View), (Model) (Collection). (Router). View. MV*, MVV, .

, Backbone, . View . CSS . , View .

, , View . View Model . , . , View . , . , .parent .

View , View Model, data- . , Model , . , Backbone, React, DOM, . , . 50-100 - .

, , HTML. , , . virtual dom, JS. — . !, . Wix, :

:

:

, :

, . . React.

CSS , . , HTML, . , .

, <style> . , . .

Data storage

data- , html . !== . html . , ID, , .

//

. , . . , , .

. . .

React? Polymer? Vue ( )? Angular (!)?

3 , React Polymer, React Web Components.

, (Polymer), . . . Shady DOM , , . , .

React

:) . React :

 const rootElement = document.getElementById("root").contentDocument.body; ReactDOM.render(<App />, rootElement); 

HTML, ReactDOM.hydrate(element, container[, callback]) , - DOM React. . . , , Virtual DOM . .

, . Redux, Flux, Mobx . Redux, .

Marrionett . Backbone. . .

, . ? React, . DOM? ? ReactDOM.hydrate HTML? , .

Responsive and Adaptive

. , , . 960px. , , - . .

, , . , .

, relative . , . . . .

( )

, . , , , . .

03

, . . .

960px, . .

, , . Wix, . , .

. Yes Yes. , , , — .

. :)

12 , , .

12 , ? https://grapesjs.com/ , .

, , . , . . .

, /,

. . , . . , UI/UX.

- , , , — .

, , , . . , , .

. C . UI/UX. , undo/redo , . , HTML localStorage… , .

. , , — . , , .

PS . , . , :)