Tags: complexity

43

sparkline

Monday, March 25th, 2019

Simple & Boring | CSS-Tricks

Let’s take a meandering waltz through what other people have to say about simplicity.

Monday, March 18th, 2019

The Lean Web video from Boston CSS | Go Make Things

A good talk from from Chris Ferdinandi, who says:

One of the central themes of my talk on The Lean Web is that we as developers repeatedly take all of the great things the web and browsers give us out-of-the-box, break them, and then re-implement them poorly with JavaScript.

Wednesday, March 6th, 2019

The “Backendification” of Frontend Development – Hacker Noon

Are many of the modern frontend tools and practices just technical debt in disguise?

Ooh, good question!

Thursday, February 28th, 2019

Getting help from your worst enemy

Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.

Words become walls.

I love this post from Ben on the value of plain language!

We’re not dumbing things down by using simple terms. We’re being smarter.

Read on for the story of the one exception that Ben makes—it’s a good one.

Tuesday, February 19th, 2019

You probably don’t need a single-page application

If there are no specific reasons to build a single-page application, I will go with a traditional server-rendered architecture every day of the week.

Sunday, February 17th, 2019

Is the universe pro-life? The Fermi paradox can help explain — Quartz

Living things are just a better way for nature to dissipate energy and increase the universe’s entropy.

No anthropocentric exceptionalism here; just the laws of thermodynamics.

According to the inevitable life theory, biological systems spontaneously emerge because they more efficiently disperse, or “dissipate” energy, thereby increasing the entropy of the surroundings. In other words, life is thermodynamically favorable.

As a consequence of this fact, something that seems almost magical happens, but there is nothing supernatural about it. When an inanimate system of particles, like a group of atoms, is bombarded with flowing energy (such as concentrated currents of electricity or heat), that system will often self-organize into a more complex configuration—specifically an arrangement that allows the system to more efficiently dissipate the incoming energy, converting it into entropy.

Monday, February 11th, 2019

A Simpler Web: I Concur

Tales of over-engineering, as experienced by Bridget. This resonates with me, and I think she’s right when she says that these things go in cycles. The pendulum always ends up swinging the other way eventually.

Thursday, January 31st, 2019

Openness and Longevity

A really terrific piece from Garrett on the nature of the web:

Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.

I share his concerns about the maintainability overhead introduced by new tools and frameworks:

I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.

On Simplicity | Max Böck - Frontend Web Developer

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.

The Principle of Least Power looms large over this:

Some of the most important things in the world are intentionally designed “stupid”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.

Sunday, January 27th, 2019

Designing for the web ought to mean making HTML and CSS - Signal v. Noise

The towering demands inherent in certain ways of working with JavaScript are rightfully scaring some designers off from implementing their ideas at all. That’s a travesty.

Hear, hear! And before you dismiss this viewpoint as some lawn-off-getting fist-waving from “the old guard”, bear this in mind:

Basecamp is famously – or infamously, depending on who you ask – not following the industry path down the complexity rabbit hole of heavy SPAs. We build using server-side rendering, Turbolinks, and Stimulus. All tools that are approachable and realistic for designers to adopt, since the major focus is just on HTML and CSS, with a few sprinkles of JavaScript for interactivity.

It’s very heartening to hear that not everyone is choosing to JavaScript All The Things.

The calamity of complexity that the current industry direction on JavaScript is unleashing upon designers is of human choice and design. It’s possible to make different choices and arrive at different designs.

Friday, January 18th, 2019

Building a Progressively-Enhanced Site | Jim Nielsen’s Blog

This is an excellent case study!

The technical details are there if you want them, but far more important is consideration that went into every interaction. Every technical decision has a well thought out justification.

Sunday, January 13th, 2019

Teaching a Correct CSS Mental Model

One facet of this whole CSS debate involves one side saying, “Just learn CSS” and the other side responding, “That’s what I’ve been trying to do!”

I think it’s high time we the teachers of CSS start discussing how exactly we can teach a correct mental model. How do we, in specific and practical ways, help developers get past this point of frustration. Because we have not figured out how to properly teach a mental model of CSS.

Monday, January 7th, 2019

Angular, Autoprefixer, IE11, and CSS Grid Walk into a Bar… - daverupert.com

Dave on the opaqueness of toolchains:

As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.

There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:

In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.

I really like this suggestion for making the invisble visible:

I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.

Monday, October 29th, 2018

Programming Sucks

There’s a theory that you can cure this by following standards, except there are more “standards” than there are things computers can actually do, and these standards are all variously improved and maligned by the personal preferences of the people coding them, so no collection of code has ever made it into the real world without doing a few dozen identical things a few dozen not even remotely similar ways. The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that’s involved, because standards are unicorns.

Monday, September 10th, 2018

Robustness and least power

There’s a great article by Steven Garrity over on A List Apart called Design with Difficult Data. It runs through the advantages of using unusual content to stress-test interfaces, referencing Postel’s Law, AKA the robustness principle:

Be conservative in what you send, be liberal in what you accept.

Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:

Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.

In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:

It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.

In other words, be liberal in what you accept from users.

I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems. When it comes to figuring out what specific tools or technologies to use, there’s an equally useful principle: the rule of least power:

Choose the least powerful language suitable for a given purpose.

On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?

Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.

Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don’t get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

  • Instead of using JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about evaluating technology; choosing the most appropriate technology for the task at hand.

There are some associated principles, like YAGNI: You Ain’t Gonna Need It. That helps you avoid picking a technology that’s too powerful for your current needs, but which might be suitable in the future: premature optimisation. Or, as Rachel put it, stop solving problems you don’t yet have:

So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.

There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.

After all, if they’re good enough for Tim Berners-Lee…

Tuesday, August 21st, 2018

The Web I Want - DEV Community 👩‍💻👨‍💻

Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.

This is very lawnoffgetting but I can relate.

I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you’ll read on here.

20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.

Thursday, May 31st, 2018

The Cult of the Complex · An A List Apart Article

I know that Jeffrey and I sound like old men yelling at kids to get off the lawn when we bemoan the fetishisation of complex tools and build processes, but Jeffrey gets to the heart of it here: it’s about appropriateness.

As a designer who used to love creating web experiences in code, I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.

And not to sound like a broken record, but once again I’m reminded of the rule of least power.

Wednesday, May 30th, 2018

Solving Life’s Problems with CSS | CSS-Tricks

It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.

Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.

That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.

Wednesday, May 23rd, 2018

Saturday, February 24th, 2018

Complexity | CSS-Tricks

We talk about complexity, but it’s all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don’t just break.