What You Pay Is What You Get: The Future of WYSIWYG Editors
Do we really need Web designers and developers? It’s a question that keeps being asked every few years when a new ground-breaking tool gets released. These tools aim to bring standards compliant code to the masses (with minimal user effort and cost), often in a well designed web, console, or desktop application. It all sounds too good to be true – and as history has shown, frequently (with a few exceptions) it is!
In this article – we’re going to explore the history of code-free editors. We’ll examine what they’ve brought to the table, how they’ve impacted the industry, what milestones they’ve reached, and why we shouldn’t write them off as a gimmick intended to put designers out of business (or give users poor value for money). In fact, they’ve often aided our workflow, focusing our attention toward more important or relevant issues.
The Future of Code-Free Editors
FrontPage & Geocities: The First Generation
In the beginning times were tough. The Web was experimental and tools were rather like the Wild West, unwieldy and producing code that any professional today would weep at. Software like Microsoft FrontPage, Geocities Web Editor and Adobe Dreamweaver were the forerunners of code-free editing, treating the Web like a fixed width and height desktop publishing package.
This saw the first wave of hostility from designers proclaiming that such tools would put them out of work. Web designers and developers didn’t have much to worry about though, these tools output such terrible code quality, that sites frequently broke and required fixing by hand. For a business wanting an online presence, especially one with scripts, there was no substitute for a skilled Web craftsperson during the uneasy browser wars.
Bringing affordable software to the masses made a huge impact on the design industry. For the first time, anyone without coding experience could have a basic site, and they could move between the visual and code view to see how the mechanics of Web coding worked. It gave people a taste for what could be achieved if they learned to code properly, leading the way for IDE’s like Sublime Text, increasing our productivity over plaintext editors.
Tuts & Templates: The Second Generation
Once we had all come to terms with the fact that WYSIWYG editors were here to stay, and (to a large extent) their code left much to be desired; we found ourselves going through an era that left a sour taste in many a developer’s mouth. The generation of cut-and-paste scripts. However, this time of quickly hashed together source code tutorials did lead to templates and many years later, the firmly established sub-industry we have today.
The biggest milestone made during the cut-and-paste era was that of volume. We started our love affair with sharing code during this phase of the Web: JavaScript, CGI – every language you can think of! Before GitHub, before community projects like jQuery, these were often poorly written anti-right click and marquee scripts on sites like DynamicDrive. You copied the code, put it in your source and off you went. A real timesaver for coders.
While this wasn’t an editor, it’s worth noting because this method of code accumulation lead to the more refined community based system we have today. It’s impact can be measured by the sheer amount of libraries, frameworks, boilerplates and the “off-the-rack” templates people can buy from sites like ThemeForest. These don’t replace the need for pros either, because, while they might be good “starter homes”, they are not unique to that site nor are they catering for a target audience.
WordPress & CMS’s: The Third Generation
While a template provided a low cost way to have a well made website (unlike early WYSIWYG editors), it lacked the design uniqueness and custom coding that a designer or developer could bring to the table. What was needed to bring the movement of user generated sites forward was a tool that gave the user the control they needed to make a site look unique, but focus on content rather than code to avoid messy output – enter the CMS.
Content management systems (like WordPress) made a lot of Web designers feel like they were (again) being put out of the job. A web based solution that you just add a theme and content and everything else is managed remotely? Where do we fit in now! But like with all the past scare stories, we simply adapted to meet the new environment. It opened up new opportunities to design themes, work fixing installs and some use CMS’s day-to-day.
The impact of CMS’s has been quite amazing when you consider that they have helped in the popularity of Markdown, syndication formats (RSS), and rather than putting designers or developers out of business, they’ve created specialist job roles for people who know how to work with specific platforms like WordPress or Joomla (in the same way that cut-and-paste scripts eventually created jobs for specialists in Angular and Node development).
IDE’s and CLI: The Next Generation
So we’ve been on a journey from the WYSIWYG, to the cut-and-paste script era, to the themes, and CMS’s that we still use to this day. Well there is one more important generation left to cover, the exciting one we’re in right now. The second age of IDE’s (WYSIWYG code drawing editors) like Macaw and Webflow and the first age of CLI’s (command line interfaces) like Jekyll, Hugo and MetalSmith; where pre-processing has become king.
Over the years, WYSIWYG editors have come on leaps and bounds, the quality of their code output has markedly improved to such an extent that it’s no longer a garbled mess. Additionally, With many developers working in terminal windows and using tools like NPM, LiveReload and SASS, making the most out of your code gives us an opportunity to build static sites without typing a single line of code into an IDE. A few keystrokes into our favorite package manager can build a pre-packaged template ready-to-go!
The impact of ever more efficient and powerful tools has allowed us to avoid wasting time on repetitive tasks – freeing our busy schedules to take on more diverse and interesting work. In the past we would often reuse a lot of the same code, making a few changes as we went. Now we can generate static sites that avoid wasting bytes, focus on performance and load libraries only when they are needed. The new WYSIWYG editors especially are useful for building quick and dirty prototypes of a layout or theme.
Web Design and the Marketplace
While code-free editors have had a rocky path; often being met with fear and hostility from both the design and development community, they have also brought many improvements that we utilize in our modern workflow. They are still far from perfect due to the quality of code and layout they output – especially when users are left in control. However, they emphasize that for years, consumers have wanted to be involved in the design process only to be locked out due to the steep learning curve.
Conclusion
It’s my belief that WYSIWYG tools aren’t to be feared. They won’t replace the aesthetic eye of a designer, nor the custom coding skill of a developer. So as far as putting us out of business, such tools actually create more work by highlighting use-cases they cannot meet, forcing consumers to seek a custom built solution from highly skilled professionals. The value we provide is what we need to focus on getting across to clients!
As such, when the next big thing comes along, don’t be fooled; we won’t stop needing designers, or developers. But with these tools eliminating the most primitive projects, designers and developers may find themselves fitting a more complimentary role; building aesthetics, functionality, and performance in ever more bespoke, niche and creative ways. Simply, don’t fear WYSIWYG’s or tools, because they’ll never be as useful as you.
