Behind The Design Of Elementor

Developer – Hates controls. Prefers a clean interface. I think Reddit is a good example of the kind of interface developers love. The developer doesn’t want controls that distract from coding. The developer thinks that regardless of the interface, if something needs to be done it can always be hardcoded.

Client / Novice – The clients don’t want to code AND don’t want too many confusing controls. The want the simplest of tools, to let them easily create their site (even though as most of you web designers know they can be very specific as to the end result they want to reach).

So, how would go about building a solution that would cater to at least two of these ever so different personas? Our answer was to handle it one decision at a time, and for each decision have an old fashion fight out. If the designer was more determined and strong willed, then the designer side won. If the developer’s side was more resolute, his side wins. Each side has the right to veto a decision, if the issue seemed important enough.

This might not seem like the best managerial decision making process. It certainly can’t be taught in business schools (“First lesson – make sure you have a designer and a developer as co-founders”). But for us I can think of no other way to make sure both personas end up loving the product, as they finally did.

Deciding on key areas that guided us

Apart from the personas, we had three key guidelines following our process:

1. Fast frontend page editing
2. An interface that was fun and easy to use
3. The possibility to edit every small detail

These guidelines were important for our process, because they functioned as touchstones to which we could measure each feature and element added to the plugin.

Why did we choose these 3 guidelines and not others?

1. Fast frontend page editing.

The speed at which a product reacts to a user request has crucial importance for any user interface.

Think about going back to using a landline internet connection.
Think about going back to using one of the earliest version of a Samsung smartphone.

It’s torture. Inconceivable.

Eran from Dapulse puts it wonderfully in a long post that deals specifically of the importance of a lightning speed interface:
10 Seconds load time gives the user the odd feeling that something’s wrong. It’s like you’re just waiting and waiting… 10 seconds feels like the app doesn’t work.

1 second and up, makes users go into a “mental context switch”. In other words — they start thinking about other stuff, like picking up shirts from the cleaners.

0.5 load time — or anywhere between 300-1000 ms — makes users feel that it’s working. Nothing to write home about, but at least they’re engaged.

100-300 ms, feels OK. It feels like normal behaviour.

0-100 ms feels instant. This is where the magic happens. This is what we call the BOOM Effect.

To get lightning speed you have to have the right code infrastructure. You also have to make sure speed and performance are not sacrificed when adding or updating new features.

We knew that other page builders on WordPress were slow, and that by creating a page builder with no lag we would create the addiction effect discussed in the Dapulse post.

2. Easy to use interface

It’s a real painstaking process to make a user interface friendly and easy to use. You sometimes realize you have to make a complete and significant change only after you’ve implemented a certain design and found out it just doesn’t work.

This caused us to sometimes throw away weeks worth of work. It’s quite possible that similar changes will be made in our interface in the future.

A friendly interface is always important, but for a frontend page builder this importance is even more crucial. This is a visual plugin, one that is used every day. For designers, they sometimes use it for hours every day, as their main designing tool.

This means that all elements in the plugin must have the most convenience and logic, so even after a short test drive the user understand how it works. The user should  also be able understand how a newly added widget works, because of the consistent build.

3. Designer oriented page builder

There is a serious drawback of Bootstrap: lack of customization.

When you get a page builder with default and limited set of widget settings, however finely crafted, it will produce designs that look very much the same.

This is a drawback we insisted on avoiding. We made every widget fully customizable, while still maintaining the previous friendly UI discussed above.

There is a fine balance we always had to juggle between full customization and user friendliness. We didn’t want to create a confusing interface that resembles a cockpit. Again I return to the Photoshop interface example. There are endless controls and menus that just aren’t a good fit for a browser based page builder.

On the other hand, we didn’t want to go the way most page builders go, and have a limited preset settings that don’t allow for a flexible and custom made design.

A great example is the button widget. You might think that it’s no big deal, it’s just a button. What special customization could you possibly have?

Let’s take the sizing of the button. With Elementor, we’ve made sure you could not only control the spacing of the button, and increase the space between the text and the border, but could also set a different width for the top, bottom, right and left space. This enables you to create a wider array of buttons. Narrow, wide, rounded, spaced out etc.

The panel dilemma

The panel is the place that lists the different widgets, and also lets you tinker with their settings.

There are two main ways of placing the panel: As a floating window or as a docked panel attached to the left/right of the page. Each of these choices have advantages and disadvantages, and we spent a long time thinking which way suited us most.

Going the floating panel way

A floating panel has the advantage that it doesn’t hide the screen, or rather that it hides a different part of the screen, and can be easily dragged to reveal it. This display allows for the screen to be displayed through the full width of the page.

Going the docked panel way

The docked panel is much more easy to use. You get used to the panel being in a set place, and can learn to work fast because of the habit to always go to the left of the screen. It doesn’t bother you in the content area, like the floating panel. It is always set apart. It is less limited in size.

The docked panel provided a content area which was 1,000 pixels wide. If you are using a small laptop, this means you are left with a very small content area. We finally decided to go with this option, because we researched and found out that our core target audience, designers and developers, used large screens that could manage this reduction in the content area size reduction.

For the users who did have a smaller screen, we added a scroll bar to the content area, so they could still get the real view of the entire width of the page.

A short time after we had launched, we made the panel responsive, so now it adjusts according to the user’s screen resolution. We also added the option to widen and narrow the panel, making it more convenient when editing text for example. This actually makes the docked panel an even better choice.

Choosing the interface and editing options

Deciding on docking the panel in the left side of the screen was a major decision, but was just the first step in our long journey towards the final interface we ended up launching. An even more difficult decision concerned the whole editing concept.

Because we had already developed a  backend page builder in the past, we already had experience as to what it takes to build the architecture of the builder. Basically, you need to come up with an easy way to use one visual interface to edit 4 different layers: the widget itself, the row, column and section.

This poses a lot of UI questions, like: when a user clicks on a box to drag it, what exactly is to be dragged? The widget, row, column or section?

In all our interface versions one thing was clear. We wanted the user to only have one single frame to deal with. Photoshop was the inspiration here. You choose a layer and can edit and make changes only to that single layer. No fidgeting and moving the mouse in an effort to “catch” the right frame to edit. We actually went along and built over 100 interface versions, before finally deciding on our unique solution.

The drag and drop was also under debate. Another option is to have a plus sign that opens a menu with all the controls. This saves you a lot of screen real estate, but is less visually convenient.

Here is the current interface architecture

You only see one layer at a time

The default is the widget. You have two buttons to the top left of the box that give you control over the column and the section. The row control is available by adding another column widget.

Having one layer has its pros and cons, and we are currently considering other options, so this may well change in the future.

The left panel is always divided into content, style and advanced settings
This consistency makes the whole process of learning to use Elementor much easier.

The three distinctions are used mainly to simplify the interface, and prevent the “cockpit” feeling of bewilderment when faced with too many controls.

We’ve used the same methodology to de-confuse each of the three tabs, and created more divisions by dividing the tabs sections or dividers. This is especially useful for the more advanced widgets that have more intricate settings like the Forms and Posts widgets.

Improved workflow
As mentioned, we went back and forth through various versions, and sometimes decided to throw away hundreds of hours of work. Apart from the basic three guidelines I mentioned, there is a flow that we’ve searched for. A speed of design and an intuitive feeling as if everything is within reach. For the first months our focus was on improving the workflow for the single page. Lately we started to move towards improving a wider extent of the designer’s workflow, such as how they manage sections that appear across the website from one place.

Mobile Editing

From the very early planning stages it was clear to us that Elementor had to deliver an outstanding solution for mobile. Responsive design has transitioned from being a trendy buzz word to a practical everyday task for every web designer. Today between 50-60 percent of all internet surfing is done on mobile.

The ‘100% responsive’ label you get with your theme is nice, but isn’t nearly enough for proper web design. Surfing with a mobile device poses many challenges, and this is why we created a list of features we call Mobile Editing. This includes many options to customize parameters, like font-size, text alignment and margins, and set them differently per device.

When we considered the UI management of mobile editing we had two options. One was to add a forth tab to each element (besides the current Style, Content and Advanced) that will present the mobile settings. The advantage of this solution is having one place where all mobile settings are set.

The downside of this is that you don’t really need the control over 100% of the settings, so going with this solution would force you to constantly zigzag between the different tabs just to design for mobile.

We finally decided to go with another solution, and today Elementor displays mobile buttons alongside each parameter. You can click on the mobile button and set different settings for mobile, and when you do, the editor automatically goes to mobile mode so you can see the result live.