Fast needs, slow development

Drag-and-drop solutions for front-end development are among the most sought-after technologies out there. Why is that? Because of the accelerated needs of everyone around the world and the current cap in developers and development speed.

 

As businesses and marketing agencies became aware of the need to build their digital presence, the world has developed a growing demand for techies and engineers alike. It may seem great for aspiring and senior developers, as work is not likely to be lacking. But this urgency might hurt the industry and workers, as well.

 

Marketing campaigns and new landing pages are required day by day by companies everywhere. Behind the scenes, there are plenty of developers working their hands off to crunch every project in our fast-paced world of volatile trends. Think fast fashion for development.

 

The problem is: development takes time. That is not saying that the other parts of the business do not (marketing, copy, design, business plans), but the slow step is often development, which links with many things. More often than not, dev teams are short of staff. Also, many companies understate the amount of work that goes into a custom site; and they all want tailor-made.

 

The problem then could be summarized to fast-changing needs with slow (compared to the rest) complex development. That is the world we live in right now. In any case, it is not all grim: many businesses have a good-looking digital presence with an optimized site and even their own app.

 

The thing is, the amount of money and time that goes into those projects can be prohibitive for smaller companies, which often struggle to face these costs upfront and find it even harder to maintain them over time.

 

With this in mind, we started a search for drag-and-drop alternatives that could help ease development. We looked for options for businesses to create new landing pages and marketing campaigns without needing an entire front-end development team. The goal was to find a solution that could prevent them from spending their annual revenue plus a zillion hours of development time, all in just one project.

 

Let’s get started.

The problem with budget: high costs for digital presence

One thing is for sure: innovation is just getting faster every year. That is a fact. We could see it in a positive or negative light. It is hard to say that mobile and internet connectivity is detrimental for us. How easy it became to call family and friends or even meet new people online is a benefit we quickly forget.

 

While it brings people together, this shift towards digital communication and interaction can also create division. Today, more and more people embrace their digital presence with social media and do most of their socializing online. People make plans on their smartphones all the time.

 

What does this create? An increased need to be present in the digital world. For individuals this need is covered by social media like Facebook, Twitter, Instagram, or LinkedIn (for particular use cases). On the other hand, it is not easy for businesses to enter the digital world.

 

As individuals, most of these sites are free to use. That is not the case for companies. Yes, you could create an Instagram account for your business, but that is not the same as having a high-tier SEO-optimized website.

 

The development cost is usually high enough to let most companies out of the game, but upkeep plays a role too. When you finally gather the money and pay for it, it often requires a maintenance fee to keep your website running securely and performant.

 

That situation only aggravates the current separation between small and big companies, making the playing field tilted to the disadvantage of those who cannot afford such investments. I don’t want to sound patronizing, but the problem with the budget is major if we want a competitive internet that assimilates the logic of a free market with equal opportunities.

 

A drag-and-drop solution could solve this issue. The thing is, as we looked for it, we didn't quite get one. Next, I will review some options and why they fall short of business needs.

Fast pace innovation and standardization

The basis of front-end development can be summed up to HTML + CSS + JavaScript, even though JS is not always needed. You could argue that we could manage without it, but some of the reactivity we love on the Internet is due to its existence. With these three languages, the one that changes the most due to the neverending innovations is JS. On top of that, the most performant and efficient sites try to mimic a site with as less JS as possible. Mostly plain HTML and CSS, as Gatsby does.

 

This tendency towards innovation while trying to maintain the performance of simple sites can look like a tug of war from the devs' perspective. Keeping standards in play eases development, makes it faster, but quickly produces elements that become obsolete with the latest trend. Nothing ages as fast as technology nowadays.

 

I don’t mean to rant about programmed obsolescence. Most devs work to produce the best possible product; in a time frame. And that time frame is what could be hurting our industry. It is no news that dev teams have to crunch and work overtime to cover the needs of fleeting projects that have a lifespan of less than a year.

Templates and uniqueness: the search for original presentations

Looking for standard solutions to this problem, we found a battery of templates and pre-made sites that editorial and marketing teams could juggle to make a campaign or simple site. That is the solution, you may think. Well, not quite.

 

Most clients want a particular feeling of uniqueness and sophistication to their site that is hard to come by using templates. With our current marketing paradigm, and maybe because of our inherent human psychology, what is different calls our attention. Imagine going to the supermarket and finding that every rice package looks the same except for the name. They have likely saved plenty of money on design, but none of them stand out. It’s easy to see how this can lead to an arms race of competing looks for your eyes. The same is true online.

 

On top of that, the competition changes according to fashion and design trends. If you were to revisit the sites you used in the ’90s you would probably find them old, clunky, or like them with a touch of nostalgia. These trends not only make designers march forward, with the permitted recycling and revisiting of old trends, but also put devs on an ascending spiral of innovation. These two components are very hard to put side by side with standardization.

 

Is this it then? Aren't there any options? Let’s review one: Drupal Layout Builder.

Drupal Layout Builder

Drupal Layout Builder started as a stand-alone module for Drupal CMS. After it proved to be an essential part of the Drupal community through usage, it became part of the Drupal Core.

 

That could happen because Drupal is open-source software and has an active community of developers committed to providing the best possible product. Drupal CMS can evolve and keep up to date thanks to people who put its quality before economic gain or time to market.

 

Not every open-source project is better than proprietary ones. But looking at similar projects, the open one has a different drive that may set it up to be better in the long term if it survives its natural selection.

 

Layout Builder allows site builders and content creators a quick way to create or rearrange an user interface. With it, users easily manage custom landing pages thanks to its drag-and-drop functionality. That is it? Did we solve it? Again, not quite.

 

Even if my heart is with Drupal, it simply does not cut it for those who strive to set up a site that outperforms the rest and meets Google’s web vitals for loading speed. In that case, Drupal Layout Builder might not be the tool for the job.

 

As much as it solves the problem, to an extent, it creates a new one. If you are looking for a template site with average performance and having an online URL, it is okay. If you want to rank at the top on search engines, it may not be the solution you want. And everyone is looking for that first place in Google, right?

 

So Drupal could be a solution in the future. Layout Builder becoming part of Drupal core is a step in the right direction, and we hope to see a better implementation and more optimized code that turns it into a competitive choice. In the meantime, using Drupal as a headless CMS with Gatsby remains our choice.

 

Drupal Layout Builder was a way to solve both content structure and design in a single place. What if we went the other way around? What if we started with design?

Content structure: connecting front and back end in Figma

You gotta love Figma. Our designer illustrated Awkbit's site on Figma and we use this platform for every project we start. From the wireframes to the prototype, we embrace Figma's versatility and how easy it is for our design and development team to work together.

 

As it stands, Figma simplified many communication processes and issues that arose from having multiple versions of the design. While its design and collaboration utility is undeniable, we wanted a way to convert that slick UI design into code without having to build everything from scratch. We are familiar with UI kits and design systems (I’ll talk about them later), so that was covered, but what if we could export them to code directly? Here is where we hit a wall: content structure.

 

Figma solves most of the reactive problems of the design. We can use it to relativize every component on the front-end to each other, which is crucial for developers to set percentages, viewport height and width, and much more, allowing for responsive design.

 

Solving this is already a blessing, even if it took extra learning from our designers and extra care from our devs. As any company that tried breaking down silos would tell you, most people work better when they know what their counterparts are doing. When building on foundations based on communication, our projects grow stronger.

 

That would be lovely if it weren’t for the coding logic behind it all. Figma is a collaborative tool, but for design, not for development. As good as it is, we found some limitations, mostly related to establishing the inner workings, especially the reactive part.

 

We wanted to turn Figma documents into React components automatically. Anyone can dream, couldn’t we too? But turning the UI mockup into React code is not as easy as it looks. First, we would need a third-party API or make our working prototype. Then, we would need to keep it updated as Figma evolves. That wasn’t possible in our current situation.

 

For more than a year, we worked on transforming Figma to React manually through the sweat and tears of designers and developers alike. Every landing page and marketing campaign took so many hours, but we made it worth it.

 

Finally, we found out that many were in the same situation; some even started working on how to solve it. We are still considering the possibilities. If you are curious, investigate Karl’s Jiang work or Pagedraw’s product.

 

Still, this technology is in its infancy. Many problems we had with Drupal’s performance are fixed this way, but as we saw the demos and trials, some new layout problems appeared. God giveth, God taketh away.

 

With all of this in mind, we went back to our design board, literally, and started devising the best possible foundations for when this translation could be made. Meet the new frameworks: design systems.

Design systems: an internal standard

According to Nielsen and Norman: "a design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels".

 

That is it! I thought, naively, when I saw the definition. That is what we were looking for, a way to reduce redundancy and create faster. With a set of components, we could prepare everything beforehand. So, where is the problem? As many times, it was the proprietary problem.

 

I read about design systems through Brad Frost’s Atomic Design. He set down the ground rules for design systems and building up from standard elements. That way, designers have a straightforward toolkit to work with, and developers do not need to code as much.

 

Using a model of atom, molecule, organism, template, and page, we could build a site much faster, thanks to pre-written code and reusing the same assets as an animation studio would do. Think of the difference between hand-drawn animation and 3D.

 

As we looked for a design system that suited our needs, most were still proprietary endeavors. Yes, we found IBM’s Carbon Design System, an open-source one, but it was the exception, not the rule.

 

As a software factory, we can freely create and write the code of our own design system. But I fear that many small businesses will have the same issues as before: large budgets and high maintenance costs. Until this goes mainstream and viable open-source solutions are available, drag and drop will remain unattainable from most businesses.

 

At Awkbit, we believe that the path is open source. Also, I know that history is on our side. I have seen the growth of the open-source community and their endeavors to places no one imagined. Linux beating Windows was unthinkable just two decades ago; now, it seems unavoidable. Making technology available to everyone and allowing small businesses to stand an equal chance of success is a path worth taking.

 

Are you willing to take the open-source path that combines layout builders and performance, individuals and communities, design and development?