Let’s Redesign Web Design
Since the birth of the web over 25 years ago, the practice of web design has been focused on writing code. Nearly every industry resource, blog, and magazine focuses on improving our code workflows so we can create for the web. For most practitioners and influencers, it seems a foregone conclusion that code will always dominate serious web design work.
But I’d like to explore an alternative future — one that applies valuable lessons learned from the user of software in other creative disciplines.
The Way It Is
Nearly every practitioner and thought leader seems to agree: “web designers should learn to code.” All too often, resistance to this advice is met with ridicule.
While learning to code is undoubtedly empowering, it’s a painstaking process, especially for those who primarily think and work visually. It can take at least months — and in many cases, years — to become good enough with code to tackle many problems in web design.
Even web industry experts who have been writing code for decades have no idea what they are doing sometimes — so how can we expect someone who is just starting to catch up with the always-changing world of web development?
In his paper Magic Ink, Bret Victor sums up a designer’s predicament (emphasis mine):
Software tools for drawing static graphics or composing static animations have long been commonplace. But the designer who wants to create dynamic graphics — graphics whose properties are data-dependent — currently has two undesirable options:
1) She can learn some sort of programming language. Many designers are intimidated by engineering and may lack the talent or desire to program. They are completely justified — drawing is a visual activity, and working with textual abstractions is entirely inappropriate. Painters, illustrators, and sculptors manipulate the artifact directly — there is no abstraction, and visual feedback is immediate. Would we have any of our great works of art if the creators had to work with “rectangle.width = 17” instead of visible brushstrokes?
2) Alternately, a designer can draw a series of mockups, snapshots of how the graphic should look for various data sets, and present these to an engineer along with a verbal description of what they mean. This results in ridiculously large feedback loops — seeing the effect of a change might take a day instead of a second. It involves coordination and communication between at least two people, and requires that the designer justify herself — she must convince the engineer and possibly layers of management that each change is worth the engineer’s time. This is no environment for creative exploration.
Unfortunately, many designers find themselves caught in this uncanny valley where they fully understand what they want to accomplish, but lack the ability to actually bring their ideas to life.
The Way It Should Be
Recently, Josh Puckett explored two great ideas for a general design tool that would let us design for a wide range of devices and variations: Adaptive Layouts and Using Real Data. He made a critical observation:
Design tools should have the same properties as the medium for which we are designing. — Josh Puckett
In this post, I’ll apply these ideas to a tool built specifically for web design, and outline a novel way of creating dynamic websites powered by real data — without diving into the nitty-gritty of writing code.
To illustrate this concept, let’s pick a real-world dynamic website we want to rebuild to be responsive and mobile-friendly. Sandwich Video’s site makes a great candidate, since it has a lot of custom content — Companies, Projects, People, Testimonials — that falls outside the realm of any out-of-the-box CMS solution or a do-it-yourself website builder.
The status quo approach to starting such a rebuild would be to create a MySQL database, set up a data schema, download and set up a CMS framework, and then go to town in a text editor to create a template. With that done, you still have to hook up your data to the HTML that renders the site. This process typically requires an entire team of people, usually takes months of work, and will cost the client an arm and a leg to boot.
But what if we could sidestep a lot of that complexity and create tooling to focus on our content and our designs?
What if adding dynamic content to a website was as easy as dragging an element inside of a design and linking it to a piece of content?
This approach becomes possible if we first break down the problem into several primitives. The first is our various types of content, which we’ll call Collections.
Focus first on designing the system of real-world objects, then on designing a system of implementation to bring it all to life. — Sophia Voychehovski
Now let’s see what happens when Adam (the founder of Sandwich Video) wants to add some glowing testimonials to the site.
Instead of diving into code, we can create a Testimonials Collection, describe its structure, and create a few actual testimonials to kick off our design.
Once we’ve structured our Testimonials Collection and created a few instances of that Collection, we can now design this content live on the canvas.
To do this, we’ll introduce a new primitive — a Dynamic List — which takes elements in a Collection and repeats them on the canvas, remembering the exact content of each item.
We can then add elements to the list and bind them to a field in the Collection (or a referenced Collection) and watch as our design populates with the real content we just created.
Editorial designers know that the secret isn’t content first or content last … it’s content and design at the same time. –Travis Gertz
Working with real content like this also lets us do all the things developers are used to doing with databases — like sorting and filtering — while preserving our design.
Working with real content also lets you immediately see how variations affect your layout.
When we don’t work with real data, we deceive ourselves. –Josh Puckett
So let’s see what happens if we change our design to center the testimonial text and make one of our quotes long enough to span three lines instead of two — enough so that it “breaks” the design.
We can immediately see that the longer text breaks the layout and adjust accordingly — something you just can’t do in Photoshop or Sketch.
Dynamic content also empowers us to get really creative with our designs. For example, let’s give our Companies Collection a new field called Brand Color, and use that color to create a custom border in our testimonials grid. In seconds, we have a new design option we can apply in a variety of ways.
We can go one step further by adding another primitive: a Collection Template Page. With this, we can create a design that shows a detailed view of each item in a Collection.
For example, let’s design a page for a team member — an item in our People Collection. With that done, our tool automatically replicates the page for each person, so we can immediately make sure the design works for every team member.
With these primitives — collections, dynamic lists, and collection template pages — at our fingertips, we can quickly build complex websites and easily identify edge cases.
This also creates a clear separation between content and design, so we can let a stakeholder or collaborator make content changes directly, knowing that any change will immediately reflect in all parts of the design.
The magical thing with this approach is that once you follow these principles of separating your design from the content that informs it, you don’t need to do anything else to make it work in the browser. It’s already in the browser, it already works — what you see is what you get.
By the way, all of the screen captures above are from Webflow. (Full disclosure: I work at Webflow. But it’s the only web design tool currently available that implements these principles, so it presented a convenient way to illustrate my points.)
The Way Forward
Digital artists, 3D animators, video editors, graphic designers, painters, writers — you name the creative discipline — already work in their medium via tailor-made software. They manipulate their medium directly until they are happy with the result. There’s no need to translate their work into the real working thing.
We need to make this a reality for web design, so we can free designers to work directly on the rich canvas of the web. Sure, working on the web has tangible constraints — such as having to understand the CSS box model — but it’s entirely possible to build tooling around these constraints and even use them to our advantage.
The way forward is to create better tools for web design — tools rooted in the medium we design for, and that don’t use code to manipulate things better suited to visual manipulation.
A tool converts what we can do into what we want to do. A great tool is designed to fit both sides. — Bret Victor
If you want to learn more about how Webflow works with content, watch this overview video, or try it yourself at webflow.com
