This past summer, I gave a lecture at a web conference & afterwards got into a very interesting conversation with a young digital design student. It was fun to compare where we were in our careers.
I had fifteen years of experience designing for web clients, she had one year, yet we were in the same situation: we enjoyed the work, but were confused & overwhelmed by the rapidly increasing complexity of it all. What the hell happened? (That’s a rhetorical question.)
Neither of us had an answer, but a bit of time and distance has shown me that we must do both. I’d like to extend that conversation today and attempt to capture my perspective on that confusion and what it costs us.
Absence was the main source of confusion. Three years ago, I stopped making websites for clients to focus on Abstract, the software company I co-founded. My work there ended at the beginning of last year, and after some time off, I decided to reopen the design studio I was running beforehand.
And wouldn’t you know it? The first few jobs through the door were websites. A lot can change in three years, so I decided to brush up on the latest developments in how to best make websites… and oh my…
Things have gotten messy, haven't they?
{ ●´⌓`● }
Things
have
gotten
messy,
haven't
they?
{ ●´⌓`
● }
At first I was bummed about my studio’s lack of progress, but then it hit me: what if I nailed it? Why change if it’s working? I've been able to approach projects from various angles and I’m happy to report that I’ve gotten pretty good at a lot of it!
Except with the websites, because I don’t feel much better at making them after 20 years. My knowledge and skills develop a bit, then things change, and half of what I know turns into dead weight. This hardly ever happens with any of the other work I do.
I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times. If you have worked in the technology industry a while, please tell me this sounds familiar to you.
I made my very first website twenty years ago. I know this because I was a teenager doing the Lord’s work: I was transcribing the lyrics to Radiohead’s OK Computer. It was 1997, I was learning HTML, and there was one issue with the design that was confusing me: how do I put two things next to each other?
Twenty years later, we’re still working out the answer to that very basic question.
<table>
<tr>
<td>Hi</td>
<td>Mom</td>
</tr>
</table>
In 1997, we used tables & spacer gifs. It was like designing a website in a spreadsheet from hell. I found this process fun for some reason. Perhaps I was interested by the potential of just bashing something together in my room, hitting a button, then having it be “out there.”
{ float: left; }
Around five years later, websites moved to using floats in CSS because tables were not semantic. Fair enough! Since then, I’ve spent about 200 hours reading about how to get floats to clear. I’m still not sure I understand it; I type clear: both and pray to the box model.
{ display: flex; }
I was saved by Flexbox after five years of guess work. It is my baby. I was trained as a print designer, and with flexbox, I can type 3 or 4 lines of CSS, and have two blocks of text line up at the baseline. Hallelujah. I needed only to wait a decade to get to use this.
{ display: grid; }
And now, after flexing with flexbox, along comes CSS Grid: a powerful new feature that promises to make responsive web design even more confusing. Of course, I'm joking, because Grid is a big improvement in layout control on the web.
I’m reminded of the table layouts I was doing in 1997. I know Grid and Table layouts are fundamentally different in their capabilities and approach, but that doesn’t stop me from being unreasonable and irrational about their surface similarities.
We have completed a lap on a cycle which will go around forever. A new approach for layout will come along five years from now. It will probably resemble floats & not knowing how to clear a float will probably bite me in the ass for the second time in my career.
Things are so often only understood by those who are well-positioned in the middle of the current wave of thought. If you’re before the sweet spot in the wave, your inexperience means you know nothing.
One argument says that continual change in methodology is rigorous and healthy. I agree. Keeping things in play helps us to more easily fix what’s wrong. However I also agree with the other argument:
People only have
so much patien-ce.
{ ● ̀_ ́● }
{ ● ̀_ ́● }
People
only
have
so much
patien
-
ce.
Methods that were once taboo are back on the table. For instance, I was reading a post about the benefits of not using stylesheets, and instead having inline styles for everything.
So much of how we build websites & software comes down to how we think. The churn of tools, methods, and abstractions also signify the replacement of ideology.
Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that is work, too). The second is to remain open-minded and willing to engage with what is new, even if it just seems like a new take on something you decided against long ago.
We don’t necessarily look for better tools or fancier processes. In the past, I’ve called this following the grain of the web, which is to use design choices that swing with what HTML & CSS make easy, flexible, and resilient.
To test how much complexity comes along with my limited needs, I wrote down the technical requirements of my web design practice. It’s not a long list:
simple, responsive layout
web fonts
& nicely set text
performant, scalable images
All of these have been more than met for at least five years, but the complexity of even these very fundamental needs has ballooned in the last few years.
For instance, I showed you 4 different ways to put two things next to each other. Each new method mostly replaces the last, so hopefully we are reaching a stabilization point with flexbox and CSS Grid. But who knows what will come out five years from now?
Webfonts? I thought we could jot down a few lines with @font-face, but A Book Apart just published a 90 page e-book on how to load those fonts. This was very surprising to me: I thought implementing webfonts was an easy procedure, but I guess not!
My point is that the foundations are sufficiently complicated enough on their own. It seems foolish to add even more optional complexity on top of it.
I have kept my examples to the most basic of web implementations, I haven’t even touched on Javascript, animation, package managers, frameworks, pre-processors, deployment, libraries, or automation. Whew.
simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlc
If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. This is when code is opaque overwrought, unorganized, and snarled with dependencies.
I perked up when I heard the term used for the first time, because, while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows & spaghetti toolchains.
The best way to help someone write markup is to make sure they can read markup.
I wonder what young designers think of this situation, how they’re educating themselves in a complicated field. How do they learn if the code is illegible? Does it seem like more experienced people are pulling up the ladder of opportunity?
Silicon Valley has tried to provide a few of these. All are about speed. The most famous comes from Facebook, with their “Move fast and break things” mantra. This phrase has been thrown under the bus enough times by now, but it's interesting that so few are willing to commit to its opposite:
Go
slow
& fix things.
{ ⌐■_■ }
Go
slow
&
fix
things.
⌐■  ■
{   ●_● }
This has been my favorite internet discovery of the last few months. The rabbit doesn’t lose because he gets tired, but because he gets confused about which direction to go. Notice how it stops in the middle and stares while everyone around it yells about things it doesn’t understand? That's me on Twitter.
The web also needs diligent people so that the idea of what the web is and what it does remains legible to everyone. The call for legibility should also humbly apply to writing legible code and designs systems that are easy for nearly anyone to interpret thanks to their elegance.
It’s by keeping our work legible that we keep the door open to the next generation of our co-workers.
What works for them, works for us. Whether you are just out of school or have 20 years of experience, you will eventually end up in the same spot: your first year of making websites.