Simplicity is a funny adjective in web design and development. I'm sure it's a quoted goal for just about every project ever done. Nobody walks into a kickoff meeting like, "Hey team, design something complicated for me. Oh, and make sure the implementation is convoluted as well. Over-engineer that sucker, would ya?"
Of course they want simple. Everybody wants simple. We want simple designs because simple means our customers will understand it and like it. We want simplicity in development. Nobody dreams of going to work to spend all day wrapping their head around a complex system to fix one bug.
Still, there is plenty to talk about when it comes to simplicity. It would be very hard to argue that web development has gotten simpler over the years. As such, the word has lately been on the tongues of many web designers and developers. Let's take a meandering waltz through what other people have to say about simplicity.
Bridget Stewart recalls a frustrating battle against over-engineering in "A Simpler Web: I Concur." After being hired as an expert in UI implementation and given the task of getting a video to play on a click...
I looked under the hood and got lost in all the looping functions and the variables and couldn't figure out what the code was supposed to do. I couldn't find any HTML
<video>being referenced. I couldn't see where a link or a button might be generated. I was lost.I asked him to explain what the functions were doing so I could help figure out what could be the cause, because the browser can play video without much prodding. Instead of successfully getting me to understand what he had built, he argued with me about whether or not it was even possible to do. I tried, at first calmly, to explain to him I had done it many times before in my previous job, so I was absolutely certain it could be done. As he continued to refuse my explanation, things got heated. When I was done yelling at him (not the most professional way to conduct myself, I know), I returned to my work area and fired up a branch of the repo to implement it. 20 minutes later, I had it working.
It sounds like the main problem here is that the dude was a territorial dingus, but also his complicated approach literally stood in the way of getting work done.
Simplicity on the web often times means letting the browser do things for us. How many times have you seen a complex re-engineering of a select menu not be as usable or accessible as a <select>?
Jeremy Wagner writes in Make it Boring:
My guess is the rise of static site generators — and sites that find a way to get as much server-rendered as possible — is a symptom of the industry yearning for that brand of resilience.
Do less, as they say. Lyza Danger Gardner found a lot of value in this in her own job:
... we need to try to do as little as possible when we build the future web.
This isn’t a rationalization for laziness or shirking responsibility—those characteristics are arguably not ones you’d find in successful web devs. Nor it is a suggestion that we build bland, homogeneous sites and apps that sacrifice all nuance or spark to the Greater Good of total compatibility.
Instead it is an appeal for simplicity and elegance: putting commonality first, approaching differentiation carefully, and advocating for consistency in the creation and application of web standards.
Christopher T. Miller writes in "A Simpler Web":
Should we find our way to something simpler, something more accessible?
I think we can. By simplifying our sites we achieve greater reach, better performance, and more reliable conveying of the information which is at the core of any website. I think we are seeing this in the uptick of passionate conversations around user experience, but it cannot stop with the UX team. Developers need to take ownership for the complexity they add to the Web.
It's good to remember that the complexity we layer onto building websites is opt-in. We often do it for good reason, but it's possible not to. Garrett Dimon:
You can build a robust, reliable, and fully responsive web application today using only semantic HTML on the front-end. No images. No CSS. No JavaScript. It’s entirely possible. It will work in every modern browser. It will be straightforward to maintain. It may not fit the standard definition of beauty as far as web experiences go, but it will work. In many cases, it will be more usable and accessible than those built with modern front-end frameworks.
That’s not to say that this is the best approach, but it’s a good reminder that the web works by default without all of our additional layers. When we add those additional layers, things break. Or, if we neglect good markup and CSS to begin with, we start out with something that’s already broken and then spend time trying to make it work again.
We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process, we create another layer of complexity that, in turn, causes its own set of issues.
— Max Böck, "On Simplicity"
Perhaps the worst reason to choose a complex solution is that it's new, and the newness makes it feel like choosing it makes you on top of technology and doing your job well. Old and boring may just what you need to do your job well.
Dan McKinley writes:
“Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
Rachel Andrew wrote that choosing established technology for the CMS she builds was a no-brainer because it's what her customers had.
You're going to hear less about old and boring technology. If you're consuming a healthy diet of tech news, you probably won't read many blog posts about old and boring technology. It's too bad really, I, for one, would enjoy that. But I get it, publications need to have fresh writing and writers are less excited about topics that have been well-trod over decades.
As David DeSandro says, "New tech gets chatter". When there is little to say, you just don't say it.
You don't hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.
While we hear more about new tech, it's old tech that is more well known, including what it's bad at. If newer tech, perhaps more complicated tech, is needed because it solves a known pain point, that's great, but when it doesn't...
You are perfectly okay to stick with what works for you. The more you use something, the clearer its pain points become. Try new technologies when you're ready to address those pain points. Don't feel obligated to change your workflow because of chatter. New tech gets chatter, but that doesn't make it any better.
Adam Silver says that a boring developer is full of questions:
"Will debugging code be more difficult?", "Might performance degrade?" and "Will I be slowed down due to compile times?"
Dan Kim is also proud of being boring:
I have a confession to make — I’m not a rock star programmer. Nor am I a hacker. I don’t know ninjutsu. Nobody has ever called me a wizard.
Still, I take pride in the fact that I’m a good, solid programmer.
Complexity isn't an enemy. Complexity is valuable. If what we work on had no complexity, it would worth far less, as there would be nothing slowing down the competition. Our job is complexity. Or rather, our job is managing the level of complexity so it's valuable while still manageable.
Santi Metz has a great article digging into various aspects of this, part of which is about considering how much complicated code needs to change:
We abhor complication, but if the code never changes, it's not costing us money.
Your CMS might be extremely complicated under the hood, but if you never touch that, who cares. But if your CMS limits what you're able to do, and you spend a lot of time fighting it, that complexity matters a lot.
It's satisfying to read Sandi's analysis that it's possible to predict where code breaks, and those points are defined by complexity. "Outlier classes" (parts of a code base that cause the most problems) can be identified without even seeing the code base:
I'm not familiar with the source code for these apps, but sight unseen I feel confident making a few predictions about the outlying classes. I suspect that they:
- are larger than most other classes,
- are laden with conditionals, and
- represent core concepts in the domain
I feel seen.
Cap Watkins writes in "The Boring Designer":
The boring designer is trusted and valued because people know they’re in it for the product and the user. The boring designer asks questions and leans on others’ experience and expertise, creating even more trust over time. They rarely assume they know the answer.
The boring designer is capable of being one of the best leaders a team can have.
So be great. Be boring.
It’s so hard to convince a designer to use a standard select box over a custom themed version. If we stick with the standard, we’re inheriting all the functionality, accessibility, and cross-platform capabilities out of the box. Such low overhead, with no maintenance.
But instead we spend hours upon hours trying to recreate a decent custom designed select box. Facepalm.
21,000% Agreement.
yep – I agree as well. It’s almost as if we’re getting to the phase of preaching to the choir with this ‘be simple’ mantra. I think we know this (or at least a lot of devs are buying into this now)—the next step is figuring out how to get buy-in from additional stakeholders (designers and brand managers that want a unique brand experience, which I totally understand). When we can crack that, we’ll be making real progress.
While framework and tools could speed up development, it could also slows down the process. I had experienced setback where framework not properly set, conflict with updates and relying too much on specific dev process.
I like to put this in an example of car. While the exterior and interior look are important for sales, the performance, reliability and maintenance are the key to increase customer loyalty.
I see a lot of vitriol directed at some of the popular JavaScript frameworks (Node, React, Vue, etc), and I must admit, I have been guilty of that myself. But honestly, they’re not the problem, at least, not in and of themselves. Rather, it’s how indiscriminately they get used. They have their appropriate use cases, and static landing pages are typically not among them,
I agree with you. “Indiscriminately” is a great way to put it.
This article gives me a lot of think about when building new apps with trending technologies or the good old boring tech.
Well written hands down!!!
I appreciate this post. The last couple years of tech blogs/articles/discussions have been overwhelmingly front end systems that require a huge tech stack just for a “hello world”.
I have intentionally stayed away from the bleeding edge for years, and have saved myself from investing in useless trends. But every so often, a “seemingly” complex trend is actually useful for simplifying other things.
But if we are always bent on the latest and greatest, our ability to discern between “a complex system to keep up with a trend” vs “a complex system to make other things simple” becomes greatly diminished.
Complex systems, frameworks, JavaScript solutions, they all break accessibility, unless you go to extra lengths, sometimes extraordinary lengths, to add in the accessibility as well. HTML has basic accessibility built in, and assistive technology like screen readers for the blind all follow the HTML spec.
In countries where equality and accessibility laws have teeth, all those complex solutions may look very pretty, but they can land your business with an expensive lawsuit or a visit from whatever legal compliance inspectors your country has. Keep it simple; it can still look pretty, and everyone can use it as well.
Yes!
I often see two major issues –
Designers are inconsistent. Typography changes from screen to screen, things which are almost the same and could be made modular, are just different enough to require conditional styling. This adds complexity for everyone, including the designer who is unable to reuse her own work in future.
“UX” Designers often do not know who they are designing for. They don’t spend time with the people they are supposedly solving for. So they waste time in detail that is low value. Spend regular time with your users, and you’ll design the right thing in the right order. And you’ll be way less worried about embellishment.
I am graphic/web designer and front end developer.
In my experience, most people, including managers and even customers view my effective and simple design solutions with suspicion. Because there is no perceived complexity in the solution they feel they aren’t getting their money’s worth. Often I here people say, “I could have designed that.”
Until our reward system is based on creating simple and effective work, complexity will remain king.
I’m not sure about to be able to build a fully responsive web application using only semantic HTML on the front-end, without CSS and without JavaScript.
Same here, that sentence raised and bent one of my eyebrows.
From my experience, existing complexity of web applications and software in general is often caused by developers missing the point of their job, which is – making software do what it is supposed to. A lot of developers are focusing too much on technologies and forget that their primary concern should be working, maintainable and robust software that serves well for solving problems it was designed to solve.
We allow ourselves to enjoy technologies more than we should and forget that they are just tools.
You’ll thank yourself for being boring when you have to update your own code that’s several years old.
I’ve been trying to stay boring in an ocean of CMS nonsense for a looong long time. It’s nice to see I’m not the only one that feels it’s important. Go check out my site rgbk.org and View Source and you’ll see what I mean :)
Michael Scharnagl: