A Brief History of Web Design Tools And the original sin
How much have design tools changed since the dawn of Xerox technologies in the 80s? Have the basic conventions shifted much? Let’s find out that and more.
The guys at Xerox probably didn’t have the biggest idea of how far things would go when they came up with the laser printing technologies back in the mid-1980s. However, the world of print and design hasn’t been the same since. Growing with new capabilities at the turn of every passing decade and becoming a firmly established industry with its place in the “global market of opportunities”.
It sure would be interesting to look at the whole thing in a retrospective — from Xerox’s bright minds laying the groundwork for future design tools to the digital evolution of design methods. Such a retrospective should also help us point out a peculiar question — have the typical design approaches changed that much since the dawn of first implementations in the niche?
Let’s try to find out.
Early Major Design Players
Xerox
Everybody knows Xerox. The name is practically synonymous with paperwork services provided at every corner of your town or city. In the technology-pushing 80s, the team of specialists at Xerox PARC, a subsidiary of Xerox Holdings, introduced some essential modern computing capabilities in office work, including laser printers, early editing software, Ethernet(!), OOP and prototype-based programming, MVC architecture, AspectJ, Interpress, and more.
Impressive, isn’t it? Bet many people don’t realize how much of the company’s contribution to digital technologies in general. Though, one particular pioneer design method stands out especially.
Interpress — the first brick of modern design
Xerox PARC came up with Interpress to enable the basic design of pages for printing. Specialists coded the required layout for pages. Back then, the focus was on newspaper printing; i.e., it all started on a pretty large, enterprise-grade scale.
Ultimately, Xerox wanted to teach organizations to work with Interpress and sell it to enterprises but two of its creators saw a massively different opportunity.
Adobe
Pioneers in modern printing, Chuck Geschke and John Warnock realized the massive potential of print. They wanted to commoditize it, make it available to people at large.
The decision was made to leave Xerox and form Adobe Systems to produce a similar (yet better) convention called PostScript.
PostScript takes off
The commoditization effort manifested in PostScript, with freely available specifications and general compatibility with any machine. Anyone could learn it, and manufacturers could simply buy a license and employ PostScript for any of their in-house purposes.
The innovative capabilities of PostScript were then noticed by Steve Jobs, who offered to partner up and create a controller for the Apple LaserWriter.
Aldus Pagemaker 1.0 was the first design tool with native support of Adobe Systems’ PostScript. It was released in July 1985 for the Macintosh, and for the first time enabled the most direct manipulation of paper through a screen.
Soon after that, Aldus got acquired by Adobe, also getting individual assets like Pagemaker, FreeHand, and PressWise.
PDF — Electronic equivalent to paper
In 1993, Adobe released the first version of PDF — a “digital paper” format that makes things all the more accessible and simpler to manage.
“Imagine being able to send full text and graphics documents over electronic mail distribution networks”
All because at its core, PDF is not a programming language (unlike PostScript and Interpress). So it makes it ultimately easy to view and manipulate paper on the screen. And this is how…
Desktop publishing was born.
Design and desktop publishing as we know it was commoditized and democratized. This was the major step of design technologies reaching a mass audience of regular users. And the perfect medium for their applications and implementations didn’t take long to appear.
The wild wild web
The internet was establishing itself as a new medium for a wide range of efforts and initiatives right at the moment when desktop publishing was skyrocketing. The emerging world wide web was a big mess back then where anyone could do anything. This opened massive opportunities for everybody looking to come up with the next big thing. Under such competitive circumstances, browser wars were waging.
Early web creation tools
The early web creation tools were pretty complicated. When there simply weren’t any best practices to let one learn from the “doing it right” examples, it was kind of a trial and error scenario for all emerging solutions. For one thing, there wasn’t a standard, most commonly used browser to tailor content to — there were a bunch of options, all struggling to satisfy users.
We had back then interfaces overloaded with functional elements, software creation expertise requirements, and solutions that are great at achieving certain things but lag behind rivals in other aspects. And, in general, there were still too many ways to do things.
These early tools were complicating the design process, delivering fractured design approaches requiring more effort than coding from scratch. Back then, early creators, publishers, and webmasters (why aren’t we using this fantastic term anymore?) were simply craving some industry-wide conventions that would lead their work in the most fruitful direction.
Making a short leap to the future, today, the industry isn’t standardized per se. Yet, there are commonly accepted conventions and directions for market players. For instance, when you create a digital product, you have a whole list of standard elements, parameters, and capabilities you need to provide from the get-go.
Flash
When early web tools like Frontpage, Dreamweaver, and others proved only further to complicate the programming process, Flash came as a major game-changer. Flash was a fantastic world where designers could work in free form and design whatever they wanted.
It was more than another standalone tool. Instead, it was a whole separate platform outside the browser that could live inside the browser and finally set things straight for generations of web creators ahead.
If you could break the code barrier, you would then write an Action Script to make your designs come to life. There was no proper version control, cloud, APIs, and other stuff. Yet, it was the glory days for creative professionals who could do incredible things. Things that are maybe complicated today with plain HTML and CSS.
The eventual downfall of Flash spawned the ground for the design/development gap. Steve Jobs killed Flash, calling it buggy, a CPU hog, and crash causer.
Designing for the web today: Issues and Challenges
Not many people discuss so eagerly nowadays — how “the original sin” hasn’t changed that much at the core. Yes, we are using modern, digitized visual design tools. And yet, we are still doing everything based on the conventions created in the golden days of printing.
Come to think of it, how much have web design tools developed as a whole? Today’s design software faces a number of challenges that one certainly has to overcome to reach efficiency. These include the following.
Page paradigm
All the tools we know and design today are built with the page paradigm in mind — they are based on pixels or vector images developed for print — but the internet doesn’t work this way. Working in an environment essentially different from the final medium may not be the best way to do things. After all, the goal is to create a medium-specific output.
Every attempt of the popular design tools to mimic the medium works weird. The internet is created for content, purpose, and meaning. We can’t work via a print outlook of the world when we experience our design via screens.
Maybe we’re over-romanticizing the tools we use?
As creative professionals, we work with tools that are not “in the medium”. We think in pages while the thing we’re actually working on is far more complex and specific in its final form. So wouldn’t it be more reasonable to find a way to better reach the medium in our design work?
Connection to the medium
The tools we use today try to embrace the “form follows content” paradigm but can’t since they are firmly attached to the dogmas of the past. The design is a shallow wrapper without underlying content, serving more as a decoration rather than a wholesome, meaningful, and impactful element. The design can come out quite abstract when done in some superficial format far from the final product looks.
For that same reason, we need to get rid of the “page thinking” tendency. My firm belief is that today’s specialists should do their utmost to achieve a more wholesome design creation approach. Again, this is where modern tools and emerging methods come to the rescue.
Using advanced tools that allow previewing the final results and editing them in real-time helps preserve a direct connection to the medium.
That way, more wholesome, consistent, and bigger projects can be achieved. Designers would make the contribution they should make, taking their seats at the table.
Collaboration
A common mistake in a full-cycle project is working on design, content, and coding separately. Many specialists nowadays create a design that developers have to adapt to the software architecture and vice versa.
The design, however, should instead be tailored to the software foundation from the very beginning. I look at code as though it was a grain of salt, a fundamental element — its definition is the meaning we give it. This definition should be implied in a system as the natural byproduct of our work. Design-as-code.
Then, there’s also the moment of the design-to-code. Or design-to-development handoff. The transition of design assets has to be smooth and integral so that not a single tiny thing is lost or neglected in the process.
Close collaboration between design, marketing, and development teams is paramount for achieving the highest quality products, happy customers, and great companies.
Looking at history, I think we’re not using the right tools for the right job. We all throw around the term “product design,” but the design has no direct influence on the final product. It can be different, and it should be different.
Bridging the Gap Between Design and Development
In the mid-2000s, we shifted to the no-code or low-code revolution. We’re now living in an era where design and the tools we use are changing rapidly.
To help push the changes, new solutions enable humans who do not code to work on projects at a bigger scale, directly impacting the development stages.
And other prominent new tools, like Webflow, Wix, Figma, Sketch, Marvel, Framer, etc., took up the initiative. All in all, it seems that design is finally transitioning the core principles and capabilities to a more accessible form.
But the classic design process conventions stuck firmly inside designers’ heads.
Yes, the software becomes more accessible where it can and offers more convenient formats for manipulating assets. But, still, they are all about the craft-limiting “page thinking” metaphor.
This is why creators need the next generation of tools — content-focused solutions with more development-adapted features and in-depth medium thinking.
The future of the web
As promising as the prospects in the market may be, new design tools are still functioning via a printed outlook of the world rather than fully via digital screens. And we still need to do something about it.
Looking at all the “original sin” history, challenges, and specifics, it goes without saying that it’s still pretty tricky for creators to present new generation tools that would offer both accessibility and freedom of web creation.
And this is unfair — the web is open to everybody, and anyone should be able to put their two cents into it if they like. Most existing web builders are either too complex to grasp or closed at their core. I.e., solutions that offer flexibility and vast web building opportunities are quite tricky to use while simpler tools set many usabilities and scaling restrictions, limiting the medium’s possibilities.
So that’s exactly why we decided to build Relate — to offer a completely open platform that you can use to quickly translate your web creativity as you like and get real working products. It is a simple, intuitive web design tool that speaks the web’s natural language, with an interface built around intent and meaning, allowing anyone to create web products rapidly.
We believe in creating where the product finally lives. Imagining while seeing it fits into reality.
At Relate, our aim is to touch the medium. Code that is visually controlled, flexible enough to create great things without restrictions.
Don’t you think it’s time for an up-to-date design-as-code revolution? Share your thoughts.
