by Sandijs Ruluks

My interest in coding my designs was lost at the the moment I realized how much trickery had to be done to make it happen. Seemingly simple issues could be solved in so many ways. Yet it still might not have worked on some browsers.
One thing that always made me wonder is why there’s a division between design and code. Why difficult things become more simpler, but simple things become more difficult?

So instead of debating whether designers should learn code or developers should learn design, let’s set some common ground on how design for the web evolved and how we could bridge the gap between code and design.

The dark ages of web design (1989)

The very beginning of web design was pretty dark, as screens were literally black and only few monochrome pixels lived therein. Design was made by symbols and tabulation (Tab key). So let’s fast forward to the time when Graphic User Interface was the main way of surfing the web – the Wild West era of tables.

Tables – The beginning (1995)

The birth of browsers that could display images was the first step into web design as we know it. The closest option available to structure information was the concept of tables already existing in HTML. So putting tables within tables, figuring out clever ways to mix static cells with fluid cells was the thing, started by David’s Siegel’s book Creating Killer Sites. Though it didn’t feel totally right since the main purpose of a table is to structure numbers, it was still the common method to design the web for quite some time. The other problem was the difficulty to maintain these fragile structures. This is also the time when the term slicing designs became popular. Designers would make a fancy layout, but it was up to developers to break it into small pieces and figure out the best way to make that design work. On the other hand, tables had some awesome features like the ability to align things vertically, be defined in pixels or in percentages. The main benefit was that it was the closest to a grid we could get back then. It was also the time when so many developers decided not to like front-end coding.

JavaScript comes to the rescue (1995)

JavaScript was the answer to the limitations of HTML. For instance, need a popup window, want to dynamically modify the order of something? The answer was JavaScript. However, the main problem here is that JavaScript is layered on top of the fabric that makes the web work and has to be loaded separately. Very often it is used as an easy patch for a lazy developer, yet it is very powerful if used wisely. Nowadays we prefer to avoid JavaScript if the same feature can be delivered using CSS. Yet JavaScript itself stays strong as in front-end (jQuery) as on the back-end (Node.js).

The golden era of freedom – Flash (1996)

To break the limitations of existing web design, a technology was born that promised a freedom never seen before. The designer could design any shapes, layouts, animations, interactions, use any font and all this in one tool – Flash. The end-result is packed as one file and then sent to the browser to be displayed. That is, as long as a user had the latest flash plugin and some free time to wait until it loads, it worked like magic. This was the golden era for splash pages, intro animations, all kinds of interactive effects. Unfortunately, it wasn’t too open or search-friendly and certainly consumed a lot of processing power. When Apple decided to abandon it on their first iPhone (2007), Flash started to decay. At least for web design.

CSS (1998)

Around the same time as Flash, a better approach to structuring design from a technical standpoint was born – Cascading Style Sheets (CSS). The basic concept here is to separate content from the presentation. So the look and formatting are defined in CSS, but the content in HTML. The first versions of CSS were far from flexible, but the biggest problem was the adoption rate by browsers. It took a few years before browsers started to fully support it and often it was quite buggy. This is also the time when one browser had the newest feature, while another was lacking it, which is a nightmare for a developer. To be clear, CSS isn’t a coding language, it is rather a declarative language. Should web designers learn how to code? Maybe. Should they understand how CSS works? Absolutely!

Mobile uprising – Grids and frameworks (2007)

Browsing the web on mobile phones was a whole challenge in itself. Besides all the different layouts for devices, it introduced content-parity problems – should the design be the same on the tiny screen or should it be stripped down? Where to put all the nice, blinking ads on that tiny screen? Speed was also an issue, as loading a lot of content burns your internet money pretty fast. The first step to improvement was an idea of column grids. After a few iterations, the 960 grid system won, and the 12-column division became something designers were using every day. The next step was standardising the commonly used elements like forms, navigation, buttons, and to pack them in an easy, reusable way. Basically, making a library of visual elements that contains all the code in it. The winners here are Bootstrap and Foundation, which is also related to the fact that line between a website and an app is fading. The downside is that designs often look the same and designers still can’t access them without knowing how the code works.

Responsive web design (2010)

A brilliant guy named Ethan Marcotte decided to challenge the existing approach by proposing to use the same content, but different layouts for the design, and coined the term Responsive web design. Technically we still use HTML and CSS, so it is rather a conceptual advancement. Yet there are lot of misconceptions here. For a designer, responsive means mocking up multiple layouts. For the client, it means it works on the phone. For a developer, it is the way how images are served, download speeds, semantics, mobile/desktop first and more. The main benefit here is the content parity, meaning that it’s the same website that works everywhere. Hope we can agree on that, at the least.

The times of the flat (2010)

Designing more layouts takes more time, so luckily we decided to streamline the process by ditching fancy shadow effects and getting back to the roots of design by prioritising the content. Fine photography, typography, sharp illustrations and thoughtful layouts is how we design now. Simplifying visual elements or so called Flat design is also part of the process. The main benefit here is that much more thought is being put into copy, into hierarchy of the message and content in general. Glossy buttons are replaced by icons and that allows us to use vector images and icon fonts. Web fonts deliver beautiful typography. The funny thing is, the web was close to this from the very beginning. But well, that’s what the young years are for.

The bright future (2014)

The holy grail of web design has been to actually make it visual and bring it into the browser. Imagine that designers simply move things around the screen and a clean code comes out! And I don’t mean changing the order of things, but having full flexibility and control! Imagine that developers don’t have to worry about browser compatibility and can focus on actual problem solving!

Technically there are a few new concepts that support the move into that direction. New units in CSS like vh, vw (viewport height and width) allow much greater flexibility to position elements. It will also solve the problem that has puzzled so many designers – why centering something vertically in CSS is such a pain. Flexbox is another cool concept which is a part of CSS. It allows to create layouts and modify them with a single property instead of writing lot of code. And finally web components is an even bigger take. It is a set of elements bundled together, i.e. a gallery, signup form etc. That introduces an easier workflow, where elements become building blocks that can be reused and updated separately.