If someone’s been driven to Google something you’ve written, they’re stuck. Being stuck is, to one degree or another, upsetting and annoying. So try not to make them feel worse by telling them how straightforward they should be finding it. It gets in the way of them learning what you want them to learn.
The interactive widgets embedded in this article are excellent teaching tools!
Spot-on analysis by Max:
Generally speaking: The more independence a technology gives you, the higher its barrier for adoption.
I really hope that this when smart folks start putting their skills towards making the ideas of the indie web more widely available:
I think we’re at a special moment right now. People have been fed up with social media and its various problems (surveillance capitalism, erosion of mental health, active destruction of democracy, bla bla bla) for quite a while now. But it needs a special bang to get a critical mass of users to actually pack up their stuff and move.
If, like me, you despair at the tech stacking and JavaScriptification of everything, shut that out and pay attention to those who understand the material of the web, its inherent resilience and efficiency. We’re lucky that principled voices still advocate for simple and inclusive methods because building with efficiency and a lightness of touch makes the work feel meaningful and, sometimes, fun.
Can you feel the energy?
Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”
I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).
I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).
If you rely on Word, Evernote or Notion, for example, then you can’t work unless you have Word, Evernote, or Notion. You are helpless without them. You are dependent.
But if you only use plain text, you can use any program on any device, forever. It gives great flexibility and peace of mind.
Not only was fire always dangerous as well as beneficial, so was the wheel. A spear could injure or kill your friends, not only your dinner. With clothes came not only protection but also body lice. With farming came not only a more reliable food supply but also hard, repetitive work – and plunder by hungry bandits.
Every solution creates new problems. But they can be better problems. Lesser evils. More and greater delights.
That’s what progress is. That is what is most visible today. And that is what cynicism must therefore besmirch, obfuscate and argue away if it is to make itself, and pessimism, superficially plausible.
Comparing and contrasting two different takes on long-term thinking in sci-fi: Dune and Foundation.
In a moment of broader cultural gloominess, Dune’s perspective may resonate more with the current movie-going public. Its themes of long-term ecological destruction, terraforming, and the specter of religious extremism seem in many ways ripped out of the headlines, while Asimov’s technocratic belief in scholarly wisdom as a shining light may be less in vogue. Ultimately, though, the core appeal of these works is not in how each matches with the fashion of today, but in how they look forward through thousands of years of human futures, keeping our imagination of long-term thinking alive.
My web browser has been perfectly competent at submitting HTML forms for the past 28 years, but for some stupid reason some asshole developer decided to reimplement all of the form semantics in JavaScript, and now I can’t pay my electricity bill without opening up the dev tools. Imagine what it’s like to not know how to do that. Imagine if you were blind.
Folks, this is not okay. Our industry is characterized by institutional recklessness and a callous lack of empathy for our users.
A great tool is not a universal tool it’s a tool well suited to a specific problem.
The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them.
Progressive enhancement in meatspace:
IRL progressive enhancement is quite common when you think of it. You can board planes with paper boarding cards, but also with technology like QR codes and digital wallets. You can pay for a coffee with cash, card or phone. The variety serves diverse sets of people. Just like in web development, not dismissing the baseline lets us cover use cases we didn’t know existed. It is fragile, though: some manager somewhere probably has a fantasy about replacing everything with fancy tech and fancy tech only.
The modern web wouldn’t be possible without big ol’ JavaScript frameworks, but—but—much of the web today is held back because of these frameworks. There’s a lot of folks out there that think that every website must use their framework of choice even when it’s not necessary. And although those frameworks solve a great number of problems, they introduce a substantial number of trade-offs; performance issues you have to deal with, complex build processes you have to learn, and endless dependency updates that can introduce bugs.
I work with words. Sometimes they’re my words. Sometimes they’re words that my colleagues have written:
One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.
I also work with web technologies, usually front-of-the-front-end stuff. HTML, CSS, and JavaScript. The technologies that users experience directly in web browsers.
I think a lot about design principles for the web. The two principles I keep coming back to are the robustness principle and the principle of least power.
When it comes to words, the guide that I return to again and again is George Orwell, specifically his short essay, Politics and the English Language.
Towards the end, he offers some rules for writing.
- Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
- Never use a long word where a short one will do.
- If it is possible to cut a word out, always cut it out.
- Never use the passive where you can use the active.
- Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
- Break any of these rules sooner than say anything outright barbarous.
These look a lot like design principles. Not only that, but some of them look like specific design principles. Take the robustness principle:
Be conservative in what you send, be liberal in what you accept.
That first part applies to Orwell’s third rule:
If it is possible to cut a word out, always cut it out.
Be conservative in what words you send.
Then there’s the principle of least power:
Choose the least powerful language suitable for a given purpose.
Compare that to Orwell’s second rule:
Never use a long word where a short one will do.
That could be rephrased as:
Choose the shortest word suitable for a given purpose.
Or, going in the other direction, the principle of least power could be rephrased in Orwell’s terms as:
Never use a powerful language where a simple language will do.
Oh, I like that! I like that a lot.
Many, if not all, of our world’s most wicked problems are rooted in the excessive hiding of complexity behind illusions of simplicity—the relentless shielding of messy details in favor of easy-to-use interfaces.
But there’s always a tradeoff between complexity, truth, and control. The more details are hidden, the harder it is to understand how the system actually works. (And the harder it is to control). The map becomes less and less representative of the territory. We often trade completeness and control for simplicity. We’d rather have a map that’s easy to navigate than a map that shows us every single detail about the territory. We’d rather have a simple user interface than an infinitely flexible one that exposes a bunch of switches and settings. We don’t want to have to think too hard. We just want to get where we’re going.
Seamful and seamless design are reframed here as ethical and deceptive design:
Ethical design is like a glove. It obscures the underlying structure (i.e. your hand) but preserves some truth about its shape and how it works. Deceptive design is like a mitten. It obscures the underlying structure and also hides a lot about its shape and how it works.
The problem with developing front end projects isn’t that it’s harder or more complicated, it’s that you made it harder and more complicated.
Yes! THIS!
Web development did not change. Web development grew. There are more options now, not different options.
You choose complexity. You can also choose simplicity.
The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:
- Reusing good software is easy; it is what allows you to build good things quickly;
- Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
- The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.
Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:
- Start as simple as possible;
- Seek out problems and iterate; and
- Hire the best engineers you can.
Another nice alternative to Google Analytics with a focus on privacy.
If we, as a community, start to appreciate the complexity of writing CSS, perhaps we can ask for help instead of blaming the language when we’re confused or stuck. We might also stop looking down on CSS specialists.
More on battling entropy:
Ever needed to change “just a small thing” on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.
The solution:
That’s why starting with HTML, CSS and JavaScript without the need to ever compile anything on your local machine is a good idea. Changing some colors on such a page would indeed only take minutes and not a whole day.
I like this mindset:
Be boring by default and enhance on the way.