A wall of lego bricks

… it's eeeaasyyy… 🎶

This is a song by Danko Jones and besides being a very good rock song, it has nothing to do with the topic of this post*, but I recommend that you listen to it while you are reading this. :-)

*Or has it?

Over the last two days I again attended the Beyond Tellerrand Conference. I won't go into details why this is the best conference for creative and productive people interested in all things web and beyond, you can read my other posts if you like.

Among the great set of talks (as always) there was one talk that this time stood out for me: Manuel Matuzović's "Lost in Translation".

Make sure to watch the video of the talk if you can, it should be available soonis now on youtube and vimeo. His topic was based on the simple question how, after now nearly 30 years since its inception, can it be that most web sites still suck in regards to their markup and the quality of hte HMTL? Why are 70% of the top million web sites littered with bad markup leading to failures in regards to the Web Content Accessibilty Guidelines?

I don't want to spoil too much, but one of the reasons he sees is the gap between "Design" and "Development", to put it simply.

Screenshot Slide of the talk: Design to Code translation, showing a step "understanding" in between "design" and "development"

"(visual) design" -> understanding what structure this implies -> translating this into the correct HTML -> "development"

But what most people think in regard to web sites is:

"(visual) design" -> "development".

So the "understanding what structure this implies -> translating this into the correct HTML" is left out, either the Designers or the Developers are doing this anyway as a part of their job. Right? Well, obviously, no. Not if the result is web sites with bad markup and 97% of them with WCAG2 failures.

Somehow, this is the story of my professional life. I am a Designer (and Illustrator from time to time), got my Diploma in communications design in the mid-nineties, and right at that time discovered the Web. And after I kind-of understood (or thought I had a grasp, haha) how important the "right" HTML is, I also discovered how unimportant this was to ALL OF THE PEOPLE I HAD TO WORK WITH. From the beginning, and to this day, there still is the notion out there, among clients, among agencies (and among development-focussed shops as well), that in order to make a web site, you need a "design", and then somewhere somebody "just" has to develop this.

That there is a huge, HUGE, invisible part, a skill of its own right, between these supposedly Start and End points of the site creation, is seldom seen or factored in. I wonder about this for over a decade now. How is it possible, that the very essence of what is needed to get a browser to display (or read out) the sites' contents is seen as a somewhat clumsy step between what the designer sees on her screen when working in Figma or XD or Sketch to what then is seen on her screen in the browser? Why does nobody in that space listen to the few people in the web industry who for decades now insist on the importance of HTML markup and the semantic meaning that these innocent looking and deceptively simple <tag>Tags</tag> can convey?

How is it, that even after TWENTY YEARS since its publication, John Allsopps "the DAO of Web design" still seems foreign to many "Designers"?

… its the future of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility…John Allsopp, A DAO of web design, 2000

I still don't have an answer to that, but I have a theory, and I think it is rooted in the history of how the web went from being a tool for linked information to become a communication platform replacing things that only were available as printed before. And with this, from an early stage on, as soon as there was a way to "style" things visually (hello CSS, old friend), people like me, who had ingrained from years of training and education, that there's always the confinement of "the page", translated this into "the canvas". Composition, the use of space, all this needs a confinement to design against. This all is nothing new and was rightfully challenged with the rise of mobile web and the iPhone, and let to the Responsive Design thinking, first presented by Ethan Marcotte, 12 years ago, and currently, with the rise of modern CSS capabilities like grid, the concept of Reflow (another recommended Btconf talk by Stephanie Eckles)

And yet, where are the "true" web designers? This is a craft on its own. These are the people who need a deep understanding of HTML (and CSS and basic JS), and a thorough understanding of design principles. Somehow web sites today remind me of the difference between a Designer's drawing of a new car, and then the same car as it is seen on the streets. Frankly, I don't know how car design works, but I bet you all know the hyperdynamic drawings, then a nearly as flashing looking prototype car for the car conventions, and later the car is in production and very little of the funky elements survived the real-world check. Who in his right mind would estimate the complete production solely based on that first drawing? And yet, this is how the production of web sites is treated.

So what is needed for a "real web designer"? I think you need to shift the focus from the confinement of a "page" to the confinement of "the content" and how this is not only visually pleasing (and on whatever display size), but also how it is discoverable and meaningful for non-visual consumers.
Again, this is nothing new, and is being "preached" on web conferences again and again - but it seems not to get outside of this bubble. I once thought, that this new craft is the "Front End Designer / Developer", but looking at what our industry is expecting, we are shooting in the opposite side of the design/development spectrum and "Front End" today is so, so heavily driven by reigning in Javascript tools and frameworks that, again, the skill of crafting robust and correct HTML is overlooked. Plus, few "design"minded people are attracted by that development-heavy position, and the trend over the recent years seems to be that, finally, "real" software developers are needed in that position of the stack.
Plus, as soon as you are entering the dirty trenches of ordinary client work, you are again dealing with this "design is sold, now please make it somebody work (and cheap, we're in 2022 now and surely everything is kind of a page builder already, right?)" scenario. Argh.

I don't know what's going on in art schools, universities or whereever "Designer" are trained, but judging from my own experience, even "UX" designers are still way too much into the visual aspects of their trade.

And so, as a result, we are still faced with this problem, as Manuel put it in his talk: We're wrongfully downplaying the complexity of HTML due to the simplicity of its syntax.

And this: issues don't just come from whats visible in a design, but from whats NOT visible.

And this is exactly the problem. How to design for the unknown. How to design for things, that are NOT VISIBLE, but EQUALLY IMPORTANT.

Funny enough, this is what the old guard of web design - the "web masters" of the late 90ies and early 2000s - knew. We had to wrangle with the HTML first, and then make it somehow "look" good. (and to be honest, we also sucked and distorted and tweaked the markup to fit our wishes - layout tables and spacer gifs anyone?). But for us it is natural to think in HTML structures when we see a design. If only someone would listen. :-)

So, to come to an end here, I think what is needed is either a "true web designer" or, and this is way more practicable, a collaboration as early as possible between "visual" designers and people who have a deep understanding of HTML. To make sure that the foundation of whats going to be delivered out into the web is getting the best treatment and helps the browser to do its job. As a bonus, things like acessibility and performance are less of a scare then.

So why is it still not the norm?

Photo by Omar Flores on Unsplash