Simple & Boring

The term "simple" in web design and development is quite ironic. The goal of almost every project contains the word "concise", which has become a cliché. No one would say at a project launch conference: "Team members, design something complicated for me. Oh, and make sure the implementation process is just as complicated. Over-design, okay?"

Of course, everyone wants simplicity. A simple design means that customers can understand and like it. We also hope that the development process will be concise and clear. No one dreams of racking his brains at work every day to fix a bug.

However, there is much more to discuss about simplicity. It's hard to argue that over the years, web development has become easier. Therefore, this word has been lingering in the mouths of many web designers and developers lately. Let's talk about other people's views on simplicity.

Bridget Stewart recalls her frustrations in her battle against overengineering in her article “Simpler Web: I agree.” After she was hired as a UI implementation expert and was given the task of playing videos on click...

I looked inside the code, lost in all looping functions and variables, and couldn't figure out what the code should do. I can't find any cited HTML<video></video> Label. I can't see where the link or button is generated. I'm lost.

I asked him to explain what these functions do so I can help figure out why, because the browser can play videos without excessive intervention. But he didn't succeed in getting me to understand what he built, but argued with me whether this could be possible. At first I calmly tried to explain to him that I had done it many times at my previous company, so I was absolutely sure I could do it. Things get intense as he continues to reject my explanation. After I yelled at him (I know, this is not the most professional way of behaving), I went back to my workspace and started a repository branch to implement it. After 20 minutes, I finished the work.

The main problem here seems to be that this guy is a persevering guy and his complex approach actually hinders the completion of the job.

Simplicity on the web usually means letting the browser do things for us. How many times have you seen complex select menu redesigns?<select></select> Elements are easy to use or easy to access?

Jeremy Wagner wrote in Make It Boring:

When simplicity becomes the default, extremely easy-to-use designs and architectures are created. This is why simple HTML works so well. It perfectly solves the problem of presenting documents to the screen, and we haven't even considered the thought of carefully designed in user agent style sheets that provide its extremely tedious way of rendering. We can learn from this, especially in the age of increasing number of websites being used as web applications, making them more resilient by adhering to semantics and native web technologies. I guess the rise of static website generators—and websites that do as much server-side rendering as possible—is a symptom of the industry’s desire to get this resilience.

As they said, do less. Lyza Danger Gardner found a lot of this value in her own work:

…When we build the future web, we need to do as little as possible.

This is not an excuse for laziness or evasion of responsibility—these traits may not be common among successful web developers. Nor is this suggesting that we build bland, cookie-cutter websites and applications, sacrificing all nuances or highlights for greater compatibility.

Instead, it is a call for simplicity and elegance: prioritize commonality, handle differentiation carefully, and advocate consistency in the creation and application of web standards.

Christopher T. Miller wrote in "Simpler Web":

Should we find something simpler and easier to access?

I think we can. By simplifying our website, we can achieve greater coverage, better performance, and more reliably convey the core information of any website. I think we saw this in a heated discussion around user experience, but that can't be limited to the UX team. Developers need to be responsible for the complexity they add to the web.

Remember that the complexity we add to our website builds is optional. We usually do this for good reason, but we can also not do it. Garrett Dimon:

Today, you can build a robust, reliable and fully responsive web application using just front-end semantic HTML. No images are required. No CSS required. No JavaScript required. This is entirely possible. It will run in every modern browser. It is easy to maintain. As far as web experience goes, it may not meet the standard definition of beauty, but it will work. In many cases, it is easier to use and access than those built with modern front-end frameworks.

This is not to say that this is the best way to do it, but it is a reminder that the web works fine without all the layers we add. Things go wrong when we add these extra layers. Or, if we ignore good markings and CSS in the beginning, we start with something that has been damaged and then spend time trying to get it to work again.

We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and techniques to solve problems; but in this process we create another layer of complexity, which in turn leads to a series of problems of our own.

——Max Böck, “On Conciseness”

The worst reason to choose a complex solution is that it’s new, and this “novelty” will make you feel that choosing it will let you master the technology and do your job well. Old and boring may be exactly what you need to do your job well.

Dan McKinley wrote:

"Bored" should not be confused with "bad". Some techniques are boring and terrible. You shouldn't use any of these techniques. However, there are many technical choices that are both boring and good, or at least good enough. MySQL is boring. Postgres are boring. PHP is boring. Python is boring. Memcached was boring. Squid is bored. Cron is bored.

The benefit of boredom (so constrained) is that the function of these things is well known. But more importantly, their failure modes are well known.

Rachel Andrew wrote that choosing mature technology for the CMS she built is obvious because it is what her clients have.

You will hear less and less news about old and boring technologies. If you are reading a lot of tech news, you probably won’t read a lot of blog posts about old tech and boring tech. This is really bad, I personally like it. But I understand that publications need fresh writing, and writers are not very interested in topics that have been repeatedly discussed for decades.

As David DeSandro said, "new technology will cause heated discussion." When there is nothing to say, you say nothing.

You won't hear about TextMate because TextMate is outdated. What tweets would I post? Still using TextMate. Still good.

While we hear more about new technologies, old technologies are more well known , including what it is not good at. It would be great if the need for an updated technology (probably more complex one) is because it solves known pain points, but if not…

You can absolutely stick to what works for you. The longer you use something, the clearer its pain points will be. When you are ready to solve these pain points, try new technologies. Don't be forced to change your workflow because of hot discussions. New technology will cause heated discussion, but that doesn't mean it's better.

Adam Silver said a boring developer was full of questions:

"Will debugging code be more difficult?", "Can performance be degraded?" and "Will compile time slow me down?"

Dan Kim is also proud of his boredom:

I want to confess-I am not a rock star programmer. I'm not a hacker either. I don't understand ninjutsu. No one ever called me a wizard.

Despite this, I am still proud that I am a good, reliable programmer.

Complexity is not the enemy. Complexity is valuable. If the content we work has no complexity, it will be much less valuable because nothing can slow down the competition. Our job is complexity. Or rather, our job is to manage the level of complexity so that it is both valuable and manageable.

Santi Metz has a great article that goes into various aspects of this, part of which is about considering how much complex code needs to be changed:

We hate complexity, but if the code never changes, it will not cause us any losses.

Your CMS can be extremely complicated behind the scenes, but if you've never touched it, who cares? But if your CMS limits what you can do and you spend a lot of time fighting it, then this complexity is very important.

Reading Sandi's analysis is satisfying because it can predict where the code breaks, and these points are defined by complexity. "Exception class" (the most error-prone part of the code base) can even be recognized without even looking at the code base:

I'm not familiar with the source code of these applications, but even if I don't see it, I'm very confident to make some predictions about exception classes. I suspect them:

1. Larger than most other classes,
2. Full of conditional statements, and
3. Represents the core concepts in the domain

I feel like I'm seen.

Cap Watkins wrote in "Born Designer":

Boring designers are trustworthy and valued because people know they work for the product and users. Boring designers ask questions and rely on the experience and expertise of others, building more trust over time. They rarely assume that they know the answer.

A boring designer may be one of the best leaders a team can have.

So be excellent. Be bored.

Be bored!

The above is the detailed content of Simple & Boring. For more information, please follow other related articles on the PHP Chinese website!