Christian Heilmann

A winter of discontent in the web design world?

Wednesday, December 21st, 2011 at 12:59 am

There is a lot of discontent in our ranks lately. Almost every week there is something people get overly excited about and blame others for doing wrong. There are endless blog comment and Twitter arguments and they turn personal rather quickly. Or they are being labeled personal attacks where in reality there is not much to them (beware the wrong use of “ad hominem” there). All in all it feels uncomfortable and people start to not say anything for fear of being misunderstood.

And that pains me. It annoys me as I have spent almost my whole career as a web developer. It annoys me as our success so far is based on communication, publication and open discussion. It also annoys me as we are ungrateful to a job that is unique, incredibly liberating and creative.

  • We do what we like to do as a job – this is rare
  • We get away with much more than in any other job I ever had
  • We learn from another and with lots and lots of free resources
  • Our market has not enough people to fill the demand
  • Companies apply to us for hiring us

Instead of being happy and amazed about that it seems to me that there is a constant craving for things to be unhappy about and complain. Maybe this is just because we like to do things in the open – the way other jobs are not done. Or maybe it is a kind of guilt syndrome cause if you don’t get just how damn privileged we are as web developers, then you are a very spoilt person.

Change is a constant, not a threat

A lot of this discontent has to do with change. Change is good, but change that repeats mistakes of the past is dangerous. Sometimes it is change for the sake of change. It is the prerogative of a new generation of makers to question the ways of old and move the craft ahead. But it is also a fact that to learn a craft, you should learn from good masters, who have experience and can prevent you from repeating their follies.

“That’s the duty of the old,” said the Librarian, “to be anxious on behalf of the young. And the duty of the young is to scorn the anxiety of the old.”

They sat for a while longer, and then parted, for it was late, and they were old and anxious.

Philip Pullman, Northern Lights

Craving controversy to win arguments

It seems that instead of trying to find a consensus, the speed and rules of internet conversations are much more likely to make people concentrate on “winning an argument”. This is where “expert panels” with added controversy at conferences come in. We stoke the fire of discontent for entertainment purposes and wonder when we don’t get anywhere when people repeat the truisms uttered there for the sake of a quick laugh or to one-up one another. The repetition of these and the quoting out of context of experts by others is what causes a lot of quarrels and discontent.

In order to understand better what is going on I wanted to explain a few things I found looking back into the history of what we do.

Bumpy beginnings

When web design started we were the joke of the design industry. The market saw the web as something that can be generated by software, Frontpage and the likes.

The battles we fought were not only of technical nature but mostly outdated and limited understanding of the web as a platform for design. People tried to control every pixel and make things look and behave exactly like print.

We had no guidelines or ideas to follow – it was pure trial and error.

One main difference to industries like interactive CD-ROMs or the likes is that when we found out how to achieve something we shared it with others. This is how the web design community started – people sharing ideas and discussing solutions.

Structuring our approach and finding our niche

Later on browsers got better and we started separating concerns of development. CSS is where the look and feel goes, HTML is there to structure the document and JavaScript and Flash brings the extra bling that can’t be added server-side.

We thought we are on a good track there. Our jobs were much more defined, we got more respect in the market and were recognised as a profession. Before we started showing a structured approach and measurable successes with web technologies we were just “designers” or “HTML monkeys”.

A hero who turned villain – IE6

IE6 was the main browser used. It was also the most capable browser when you wrote code only available in it. Tied in with developer tools and environments that were Windows only it became a very natural choice for a lot of companies to concentrate on exclusively.

And this is what we still suffer from now. A lot of work and a lot of expensive systems were built for one browser only, a browser that is now outdated and annoying. The problem is that re-writing these systems is much more expensive than writing new ones and writing new ones is more expensive than just “letting them stay the way they are”. By writing browser-specific code, we painted ourselves into a corner of “never change a running system”, and the people who suffer are the visitors having to use these now terribly dated systems and the maintaining developers.

Starting the fight for standards

This is the time where the hardliners on one side of the web development battle come from. We proved we can build amazing things on the web and now we wanted to add style and standardisation.

We wanted to make what we do predictable, teachable and understandable. For this, you need standards and style guides and they’ve served us well.

Many a man hour was not wasted by trying to understand what other developers have done. As their work applied to a standard, we knew what was supposed to happen and debugging got much easier.

Standards need to embrace change, too

What we fail to do on the web these days is to understand that our standards were defined for a time that is in the past. Instead of understanding that there is a change in what we are doing on the web we still talk about the old techniques we needed to fight the WYSIWYG editors and browser specific code that wasn’t based on an agreed standard.

So yes, at times it is totally OK not to close your tags. Some applications are fine to rely on JavaScript. And it is very much pointless to complain about the markup quality of an application that was built using GWT.

On the other hand not everything needs to be a web app the likes of Google Docs and the best practices there do violate good ideas that for example need to be followed when writing a blogging system.

We need a “pick and mix” best practice approach – not the “one size doesn’t quite fit all” we do now.

Think of the maintainers

All in all this is about maintainability. You are totally welcome to violate any best practices and ideas from the past but you should not be surprised when people maintaining your code are slow in doing so. You should also not be surprised when your projects get totally scrapped and re-build from scratch when changes need to be done.

Maybe this is a dream we have to give up. Maybe there is no such thing as longevity in web design. Maybe our job is to start from scratch every single time and maybe that is what keeps us fresh and fun to work in our environment.

From craft to commodity

The old standards for “best practices” do not apply to today’s world any longer. We wanted web development to be a craft, but it actually is becoming a commodity. The people who laughed at web developers for “not being engineers” are the ones trying to do our jobs now as we are one of the few markets that are booming.

Not so hidden agenda: getting graduates hit the ground running

And this is where a lot of the “forget the old ways, here, write less and achieve more” mentality comes from. Companies are hard pushed to hire as many engineers as they need so they want to make web development interesting for people who just came out of university. Now, in university we learn nothing that is of much use in web development. Re-educating people is a long and arduous process so let’s bring the things we learn in university into the market deliveries.

This is a good idea to hire people and to stop them from building native code (Android, iOS) instead of thinking about becoming web developers. It washes out the craft though, which is always the case when things become mainstream and need lots of people.

Where we think we build Chippendale furniture, the market needs more IKEA Billies and it makes sense to teach new people to build those.

The best change is to avoid repeating mistakes

All in all our market is changing and there is no point in taking sides and trying to torpedo each other. It is fun and damn easy to do, but it is a waste of our time.

To me, our energies should be spent on preventing repeating mistakes of the past like:

  • Relying on a single browser to be the one to support – Webkit should not be the next IE6
  • Write sloppy code that obviously works now but will become a nightmare to maintain in the future – shorter is not better when it needs long explanations how to change it
  • Stick to tried and true old ideas and technologies by any means necessary (no, IE6 does not need animation when you can do it in CSS for other browsers)

Furthermore we should stop thinking as limited as we do right now

  • Complaining about the symptoms and not the causes (we try to educate people far too late about the merits of “old school” standards web development)
  • Cut corners relying on certain environments and call it “best practice”
  • Embrace the idea that a semantically marked up blog is as much web development as is an app like Google Docs and an interactive video like Wilderness Downtown.
  • Ask for the reason why something was done the way it was instead of flat out shooting it down in flames
  • Fix things for people instead of telling them off for not doing it – most of our code is open source, so if you are unhappy with an implementation, fix it!

I don’t think that we are split in two as a community. I think we all want the same things, we just fail to be aware of the reasons, pressures and end goals that drive certain people to do things in a certain way.

Share on Mastodon (needs instance)

Share on Twitter

My other work: