Last year, a study found that cars are steadily getting less colourful. In the US, around 80% of cars are now black, white, gray, or silver, up from 60% in 2004. This trend has been attributed to cost savings and consumer preferences. Whatever the reasons, the result is hard to deny: a big part of daily life isn’t as colourful as it used to be.

The colourfulness of mass consumer products is hardly the bellwether for how vibrant life is as a whole, but the study captures a trend a lot of us recognise — offline and on. From colour to design to public discourse, a lot of life is getting less varied, more grayscale.

The web is caught in the same current. There is plenty right with it — it retains plenty of its founding principles — but its state is not healthy. From AI slop to shoddy service providers to enshittification, the digital world faces its own grayscale problem.

This bears talking about. One of life’s great fallacies is that things get better over time on their own. They can, but it’s certainly not a given. I don’t think the moral arc of the universe does not bend towards justice, not on its own; I think it bends wherever it is dragged, kicking and screaming, by those with the will and the means to do so.

Much of the modern web, and the forces of optimisation and standardisation that drive it, bear an uncanny resemblance to the trend of car colours. Processes like market research and A/B testing — the process by which two options are compared to see which ‘performs’ better on clickthrough, engagement, etc. — have their value, but they don’t lend themselves to particularly stimulating design choices.

The spirit of free expression that made the formative years of the internet so exciting — think GeoCities, personal blogging, and so on — is on the slide.

The ongoing transition to a more decentralised, privacy-aware Web3 holds some promise. Two-thirds of the world’s population now has online access — though that still leaves plenty of work to do — with a wealth of platforms allowing billions of people to connect. The dream of a digital world that is open, connected, and flat endures, but is tainted.

Monopolies

One of the main sources of concern for me is that although more people are online than ever, they are concentrating on fewer and fewer sites. A study published in 2021 found that activity is concentrated in a handful of websites. Think Google, Amazon, Facebook, Instagram, and, more recently, ChatGPT:

“So, while there is still growth in the functions, features, and applications offered on the web, the number of entities providing these functions is shrinking. [...] The authority, influence, and visibility of the top 1,000 global websites (as measured by network centrality or PageRank) is growing every month, at the expense of all other sites.”

Monopolies by nature reduce variance, both through their domination of the market and (understandably in fairness) internal preferences for consistency. And, let’s be frank, they have a vested interest in crushing any potential upstarts.

• “Readability Algorithms Should Be Tools, Not Targets”
• “Towards An Ad-Free Web: Diversifying The Online Economy”

Dominant websites often fall victim to what I like to call Internet Explorer Syndrome, where their dominance breeds a certain amount of complacency. Why improve your quality when you’re sitting on 90% market share? No wonder the likes of Google are getting worse.

The most immediate sign of this is obviously how sites are designed and how they look. A lot of the big players look an awful lot like each other. Even personal websites are built atop third-party website builders. Millions of people wind up using the same handful of templates, and that’s if they have their own website at all. On social media, we are little more than a profile picture and a pithy tagline. The rest is boilerplate.

Should there be sleek, minimalist, ‘grayscale’ design systems and websites? Absolutely. But there should be colourful, kooky ones too, and if anything, they’re fading away. Do we really want to spend our online lives in the digital equivalent of Levittowns? Even logos are contriving to be less eye-catching. It feels like a matter of time before every major logo is a circle in a pastel colour.

The arrival of Artificial Intelligence into our everyday lives (and a decent chunk of the digital services we use) has put all of this into overdrive. Amalgamating — and hallucinating from — content that was already trending towards a perfect average, it is grayscale in its purest form.

Mix all the colours together, and what do you get? A muddy gray gloop.

I’m not railing against best practice. A lot of conventions have become the standard for good reason. One could just as easily shake their fist at the sky and wonder why all newspapers look the same, or all books. I hope the difference here is clear, though.

The web is a flexible enough domain that I think it belongs in the realm of architecture. A city where all buildings look alike has a soul-crushing quality about it. The same is true, I think, of the web.

“

In the Oscar Wilde play Lady Windermere’s Fan, a character quips that a cynic “knows the price of everything and the value of nothing.” In fairness, another quips back that a sentimentalist “sees an absurd value in everything, and doesn’t know the market price of any single thing.”

The sweet spot is somewhere in between. Structure goes a long way, but life needs a bit of variety too.

So, how do we go about bringing that variety? We probably shouldn’t hold our breath on big players to lead the way. They have the most to lose, after all. Why risk being colourful or dynamic if it impacts the bottom line?

We, the citizens of the web, have more power than we realise. This is the web, remember, a place where if you can imagine it, odds are you can make it. And at zero cost. No materials to buy and ship, no shareholders to appease. A place as flexible — and limitless — as the web has no business being boring.

There are plenty of ways, big and small, of keeping this place colourful. Whether our digital footprints are on third-party websites or ones we build ourselves, we needn’t toe the line.

Colour seems an appropriate place to start. When given the choice, try something audacious rather than safe. The worst that can happen is that it doesn’t work. It’s not like the sunk cost of painting a room; if you don’t like the palette, you simply change the hex codes. The same is true of fonts, icons, and other building blocks of the web.

As an example, a couple of friends and I listen to and review albums occasionally as a hobby. On the website, the palette of each review page reflects the album artwork:

I couldn’t tell you if reviews ‘perform’ better or worse than if they had a grayscale palette, because I don’t care. I think it’s a lot nicer to look at. And for those wondering, yes, I have tried to make every page meet AA Web Accessibility standards. Vibrant and accessible aren’t mutually exclusive.

Another great way of bringing vibrancy to the web is a degree of randomisation. Bruno Simon of Three Journey and awesome portfolio fame weaves random generation into a lot of his projects, and the results are gorgeous. What’s more, they feel familiar, natural, because life is full of wildcards.

This needn’t be in fancy 3D models. You could lightly rotate images to create a more informal, photo album mood, or chuck in the occasional random link in a list of recommended articles, just to shake things up.

In a lot of ways, it boils down to an attitude of just trying stuff out. Make your own font, give the site a sepia filter, and add that easter egg you keep thinking about. Just because someone, somewhere has already done it doesn’t mean you can’t do it your own way. And who knows, maybe your way stumbles onto someplace wholly new.

I’m wary of being too prescriptive. I don’t have the keys to a colourful web. No one person does. A vibrant community is the sum total of its people. What keeps things interesting is individuals trying wacky ideas and putting them out there. Expression for expression’s sake. Experimentation for experimentation’s sake. Tinkering for tinkering’s sake.

As users, there’s also plenty of room to be adventurous and try out open source alternatives to the software monopolies that shape so much of today’s Web. Being active in the communities that shape those tools helps to sustain a more open, collaborative digital world.

Although there are lessons to be taken from it, we won’t get a more colourful web by idealising the past or pining to get back to the ‘90s. Nor is there any point in resisting new technologies. AI is here; the choice is whether we use it or it uses us. We must have the courage to carry forward what still holds true, drop what doesn’t, and explore new ideas with a spirit of play.

Here are a few more Smashing articles in that spirit:

• “Playfulness In Code: Supercharge Your Learning By Having Fun” by Jhey Tompkins
• “The Psychology Of Color In UX And Digital Products” by Rodolpho Henrique
• “Creativity In A World Of Technology: Does It Exist?” By Maggie Mackenzie
• “What Zen And The Art Of Motorcycle Maintenance Can Teach Us About Web Design”
• “An Ode To Side Project Time”

I do think there’s a broader discussion to be had about the extent to which A/B tests, bottom lines, and focus groups seem to dictate much of how the modern web looks and feels. With sites being squeezed tighter and tighter by dwindling advertising revenues, and AI answers muscling in on search traffic, the corporate entities behind larger websites can’t justify doing anything other than what is safe and proven, for fear of shrinking their slice of the pie.

Lest we forget, though, most of the web isn’t beholden to those types of pressure. From pet projects to wikis to forums to community news outlets to all manner of other things, there are countless reasons for websites to exist, and they needn’t take design cues from the handful of sites slugging it out at the top.

Connected with this is the dire need for digital literacy (PDF) — ‘the confident and critical use of a full range of digital technologies for information, communication and basic problem-solving in all aspects of life.’ For as long as using third-party platforms is a necessity rather than a choice, the needle’s only going to move so much.

There’s a reason why Minecraft is the world’s best-selling game. People are creative. When given the tools — and the opportunity — that creativity will manifest in weird and wonderful ways. That game is a lot of things, but gray ain’t one of them.

The web has all of that flexibility and more. It is a manifestation of imagination. Imagination trends towards colour, not grayness. It doesn’t always feel like it, but where the internet goes is decided by its citizens. The internet is ours. If we want to, we can make it technicolor.

(yk)

A few years ago, I was in a design review at a fintech company, polishing the expense management flows. It was a routine session where we reviewed the logic behind content and design decisions.

While looking over the statuses for submitted expenses, I noticed a label saying ‘In approval’. I paused, re-read it again, and asked myself:

“Where is it? Are the results in? Where can I find them? Are they sending me to the app section called “Approval”?”

This tiny label made me question what was happening with my money, and this feeling of uncertainty was quite anxiety-inducing.

My team, all native English speakers, did not flinch, even for a second, and moved forward to discuss other parts of the flow. I was the only non-native speaker in the room, and while the label made perfect sense to them, it still felt off to me.

After a quick discussion, we landed on ‘Pending approval’ — the simplest and widely recognised option internationally. More importantly, this wording makes it clear that there’s an approval process, and it hasn’t taken place yet. There’s no need to go anywhere to do it.

Some might call it nitpicking, but that was exactly the moment I realised how invisible — yet powerful — the non-native speaker’s perspective can be.

In a reality where user testing budgets aren’t unlimited, designing with familiar language patterns from the start helps you prevent costly confusions in the user journey.

“

Those same confusions often lead to:

• Higher rate of customer service queries,
• Lower adoption rates,
• Higher churn,
• Distrust and confusion.

As A Native Speaker, You Don’t See The Whole Picture

Global products are often designed with English as their primary language. This seems logical, but here’s the catch:

Roughly 75% of English-speaking users are not native speakers, which means 3 out of every 4 users.

Native speakers often write on instinct, which works much like autopilot. This can often lead to overconfidence in content that, in reality, is too culturally specific, vague, or complex. And that content may not be understood by 3 in 4 people who read it.

If your team shares the same native language, content clarity remains assumed by default rather than proven through pressure testing.

The price for that is the accessibility of your product. A study by National Library of Medicine found that US adults who had proficiency in English but did not use it as their primary language were significantly less likely to be insured, even when provided with the same level of service as everyone else.

In other words, they did not finish the process of securing a healthcare provider — a process that’s vital to their well-being, in part, due to unclear or inaccessible communication.

If people abandon the process of getting something as vital as healthcare insurance, it’s easy to imagine them dropping out during checkout, account setup, or app onboarding.

Non-native content designers, by contrast, do not write on autopilot. Because of their experience learning English, they’re much more likely to tune into nuances, complexity, and cultural exclusions that natives often overlook. That’s the key to designing for everyone rather than 1 in 4.

Non-native Content Designers Make Your UX Global

Spotting The Clutter And Cognitive Load Issues

When a non-native speaker has to pause, re-read something, or question the meaning of what’s written, they quickly identify it as a friction point in the user experience.

Why it’s important: Every extra second users have to spend understanding your content makes them more likely to abandon the task. This is a high price that companies pay for not prioritising clarity.

Cognitive load is not just about complex sentences but also about the speed. There’s plenty of research confirming that non-native speakers read more slowly than native speakers. This is especially important when you work on the visibility of system status — time-sensitive content that the user needs to scan and understand quickly.

One example you can experience firsthand is an ATM displaying a number of updates and instructions. Even when they’re quite similar, it still overwhelms you when you realise that you missed one, not being able to finish reading.

This kind of rapid-fire updates can increase frustration and the chances of errors.

Always Advocating For Plain English

They tend to review and rewrite things more often to find the easiest way to communicate the message. What a native speaker may consider clear enough might be dense or difficult for a non-native to understand.

Why it’s important: Simple content better scales across countries, languages, and cultures.

Catching Culture-specific Assumptions And References

When things do not make sense, non-native speakers challenge them. Besides the idioms and other obvious traps, native speakers tend to fall into considering their life experience to be shared with most English-speaking users.

Cultural differences might even exist within one globally shared language. Have you tried saying ‘soccer’ instead of ‘football’ in a conversation with someone from the UK? These details may not only cause confusion but also upset people.

Why it’s important: Making sure your product is free from culture-specific references makes your product more inclusive and safeguards you from alienating your users.

They Have Another Level Of Empathy For The Global Audience

Being a non-native speaker themselves, they have experience with products that do not speak clearly to them. They’ve been in the global user’s shoes and know how it impacts the experience.

Why it’s important: Empathy is a key driver towards design decisions that take into account the diverse cultural and linguistic background of the users.

How Non-native Content Design Can Shape Your Approach To Design

Your product won’t become better overnight simply because you read an inspiring article telling you that you need to have a more diverse team. I get it. So here are concrete changes that you can make in your design workflows and hiring routines to make sure your content is accessible globally.

Run Copy Reviews With Non-native Readers

When you launch a new feature or product, it’s a standard practice to run QA sessions to review visuals and interactions. When your team does not include the non-native perspective, the content is usually overlooked and considered fine as long as it’s grammatically correct.

I know, having a dedicated localisation team to pressure-test your content for clarity is a privilege, but you can always start small.

At one of my previous companies, we established a ‘clarity heroes council’ — a small team of non-native English speakers with diverse cultural and linguistic backgrounds. During our reviews, they often asked questions that surprised us and highlighted where clarity was missing:

• What’s a “grace period”?
• What will happen when I tap “settle the payment”?

These questions flag potential problems and help you save both money and reputation by avoiding thousands of customer service tickets.

Review Existing Flows For Clarity

Even if your product does not have major releases regularly, it accumulates small changes over time. They’re often plugged in as fixes or small improvements, and can be easily overlooked from a QA perspective.

A good start will be a regular look at the flows that are critical to your business metrics: onboarding, checkout, and so on. Fence off some time for your team quarterly or even annually, depending on your product size, to come together and check whether your key content pieces serve the global audience well.

Usually, a proper review is conducted by a team: a product designer, a content designer, an engineer, a product manager, and a researcher. The idea is to go over the flows, research insights, and customer feedback together. For that, having a non-native speaker on the audit task force will be essential.

If you’ve never done an audit before, try this template as it covers everything you need to start.

Make Sure Your Content Guidelines Are Global-ready

If you haven’t done it already, make sure your voice & tone documentation includes details about the level of English your company is catering to.

This might mean working with the brand team to find ways to make sure your brand voice comes through to all users without sacrificing clarity and comprehension. Use examples and showcase the difference between sounding smart or playful vs sounding clear.

Leaning too much towards brand personality is where cultural differences usually shine through. As a user, you might’ve seen it many times. Here’s a banking app that wanted to seem relaxed and relatable by introducing ‘Dang it’ as the only call-to-action on the screen.

However, users with different linguistic backgrounds might not be familiar with this expression. Worse, they might see it as an action, leaving them unsure of what will actually happen after tapping it.

Considering how much content is generated with AI today, your guidelines have to account for both tone and clarity. This way, when you feed these requirements to the AI, you’ll see the output that will not just be grammatically correct but also easy to understand.

Incorporate Global English Heuristics Into Your Definition Of Success

Basic heuristic principles are often documented as a part of overarching guidelines to help UX teams do a better job. The Nielsen Norman Group usability heuristics cover the essential ones, but it doesn’t mean you shouldn’t introduce your own. To complement this list, add this principle:

Aim for global understanding: Content and design should communicate clearly to any user regardless of cultural or language background.

You can suggest criteria to ensure it’s clear how to evaluate this:

• Action transparency: Is it clear what happens next when the user proceeds to the next screen or page?
• Minimal ambiguity: Is the content open to multiple interpretations?
• International clarity: Does this content work in a non-Western context?

Bring A Non-native Perspective To Your Research, Too

This one is often overlooked, but collaboration between the research team and non-native speaking writers is super helpful. If your research involves a survey or interview, they can help you double-check whether there is complex or ambiguous language used in the questions unintentionally.

In a study by the Journal of Usability Studies, 37% of non-native speakers did not manage to answer the question that included a word they did not recognise or could not recall the meaning of. The question was whether they found the system to be “cumbersome to use”, and the consequences of getting unreliable data and measurements on this would have a negative impact on the UX of your product.

Another study by UX Journal of User Experience highlights how important clarity is in surveys. While most people in their study interpreted the question “How do you feel about … ?” as “What’s your opinion on …?”, some took it literally and proceeded to describe their emotions instead.

This means that even familiar terms can be misinterpreted. To get precise research results, it’s worth defining key terms and concepts to ensure common understanding with participants.

Globalise Your Glossary

At Klarna, we often ran into a challenge of inconsistent translation for key terms. A well-defined English term could end up having from three to five different versions in Italian or German. Sometimes, even the same features or app sections could be referred to differently depending on the market — this led to user confusion.

To address this, we introduced a shared term base — a controlled vocabulary that included:

• English term,
• Definition,
• Approved translations for all markets,
• Approved and forbidden synonyms.

Importantly, the term selection was dictated by user research, not by assumption or personal preferences of the team.

If you’re unsure where to begin, use this product content vocabulary template for Notion. Duplicate it for free and start adding your terms.

We used a similar setup. Our new glossary was shared internally across teams, from product to customer service. Results? Reducing the support tickets related to unclear language used in UI (or directions in the user journey) by 18%. This included tasks like finding instructions on how to make a payment (especially with the least popular payment methods like bank transfer), where the late fee details are located, or whether it’s possible to postpone the payment. And yes, all of these features were available, and the team believed they were quite easy to find.

A glossary like this can live as an add-on to your guidelines. This way, you will be able to quickly get up to speed new joiners, keep product copy ready for localisation, and defend your decisions with stakeholders.

Approach Your Team Growth With An Open Mind

‘Looking for a native speaker’ still remains a part of the job listing for UX Writers and content designers. There’s no point in assuming it’s intentional discrimination. It’s just a misunderstanding that stems from not fully accepting that our job is more about building the user experience than writing texts that are grammatically correct.

Here are a few tips to make sure you hire the best talent and treat your applicants fairly:

• Remove the ‘native speaker’ and ‘fluency’ requirement.

Instead, focus on the core part of our job: add ‘clear communicator’, ‘ability to simplify’, or ‘experience writing for a global audience’.

• Judge the work, not the accent.

Over the years, there have been plenty of studies confirming that the accent bias is real — people having an unusual or foreign accent are considered less hirable. While some may argue that it can have an impact on the efficiency of internal communications, it’s not enough to justify the reason to overlook the good work of the applicant.

My personal experience with the accent is that it mostly depends on the situation you’re in. When I’m in a friendly environment and do not feel anxiety, my English flows much better as I do not overthink how I sound. Ironically, sometimes when I’m in a room with my team full of British native speakers, I sometimes default to my Slavic accent. The question is: does it make my content design expertise or writing any worse? Not in the slightest.

Therefore, make sure you judge the portfolios, the ideas behind the interview answers, and whiteboard challenge presentations, instead of focusing on whether the candidate’s accent implies that they might not be good writers.

Good Global Products Need Great Non-native Content Design

Non-native content designers do not have a negative impact on your team’s writing. They sharpen it by helping you look at your content through the lens of your real user base. In the globalised world, linguistic purity no longer benefits your product’s user experience.

Try these practical steps and leverage the non-native speaking lens of your content designers to design better international products.

(yk)

There seemed to be a hot minute when the tech industry understood the value of idle tinkering and made a point of providing ‘side project time’ as an explicit working perk. The concept endures — I’m lucky enough to work somewhere that has it — but it seems to have been outpaced in recent years by the endless charge toward efficiency.

This seems a shame. We can’t optimize our way to quality solutions and original ideas. To try is a self-defeating fantasy. The value of side project time is hard to overstate, and more workplaces should not just provide it but actively encourage it.

Here’s why.

What Is Side Project Time?

Side project time pops up under different names. At the Guardian, it’s 10% time, for example. Whatever the name, it amounts to the same thing: dedicated space and time during working hours for people to work on pet projects, independent learning, and personal development.

Google founders Larry Page and Sergey Brin famously highlighted the practice as part of the company’s initial public offering in 2004, writing:

“We encourage our employees, in addition to their regular projects, to spend 20% of their time working on what they think will most benefit Google. This empowers them to be more creative and innovative. Many of our significant advances have happened in this manner. For example, AdSense for content and Google News were both prototyped in “20% time.” Most risky projects fizzle, often teaching us something. Others succeed and become attractive businesses.”

— Larry Page and Sergey Brin

The extent to which Google still supports the practice 20 years on is hazy, and though other tech big hitters talk a good game, it doesn’t seem terribly widespread. The concept threatened to become mainstream for a while but has receded.

The Ode

There are countless benefits to side project time, both on an individual and corporate level. Whether your priorities are personal growth or making lines, it ought to be on your radar.

Individuals

On an individual level, side project time frees up people to explore ideas and concepts that interest them. This is good in itself. We all, of course, hope to nurture existing skills and develop new ones in our day-to-day work. Sometimes day to day work provides that. Sometimes it doesn’t. In either case, side project time opens up new avenues for exploration.

It is also a space in which the waters can clear. I’ve previously written about the lessons of zen philosophy as they relate to pet project maintenance, with a major aspect being the value of not doing. Getting things done isn’t always the same as making things better.

The fog of constant activity — or productivity — can actually keep us from seeing better solutions to problems. Side project time makes for clearer minds to take back with us into the day-to-day grind.

“

Dedicated side project time facilitates personal growth, exploration, and learning. This is obviously good for the individual, but for the project too, because where are the benefits going to be felt?

Companies

There are a couple of examples of similar company outlooks I’d like to highlight. One is Pixar’s philosophy — as outlined by co-founder Ed Catmull — of protecting ‘ugly babies’, i.e. rough, unformed ideas:

“A new thing is hard to define; it’s not attractive, and it requires protection. When I was a researcher at DARPA, I had protection for what was ill-defined. Every new idea in any field needs protection. Pixar is set up to protect our director’s ugly baby.”

— Ed Catmull

He goes on to point out that they must eventually stand on their own two feet if they are to step out of the sandbox, but that formative time is vital to their development.

The mention of DARPA (the Defense Advanced Research Projects Agency), a research and development agency, highlights this outlook, with Bell Labs being one of its shining examples. Its work has received ten Nobel Prizes and five Turing Awards over the years.

As journalist Jon Gertner summarised in The Idea Factory: Bell Labs and the Great Age of American Innovation:

“It is now received wisdom that innovation and competitiveness are closely linked. But Bell Labs’ history demonstrates that the truth is actually far more complicated…creative environments that foster a rich exchange of ideas are far more important in eliciting new insights than are the forces of competition.”

— Jon Gertner

It’s a long-term outlook. One Bell employee recalled: “When I first came, there was the philosophy: look, what you’re doing might not be important for ten years or twenty years, but that’s fine, we’ll be there then.”

The cynic might say side project time is research and development for companies without the budget allocation. Even if there is some truth to that, I think the former speaks to a more entwined culture. It’s not innovation over here with these people and business as usual over there with those other people.

Side project time is also a cultural statement: you and your interests are valuable here. It encourages autonomy and innovation. If we only did OKRs with proven value, then original thinking would inevitably fade away.

“

And let’s be frank: even in purely Machiavellian terms, it benefits employers. You’ll be rewarded with happier, more knowledgeable employees and higher retention. You may even wind up with a surprising new product.

Give It A Spin

Side project time is a slow burner but an invaluable thing to cultivate. Any readers in a position to try side project time will reap the benefits in time.

Some of the best things in life come from idle tinkering. Let people do their thing. Give their ideas space to grow, and they will. And they might just be brilliant.

Further Reading

• “Side Project Programs Can Have Major Benefits for Employers” by Tammy Xu
• “What made Bell Labs special?” by Andrew Gelman (PDF)
• “Why Bell Labs Was So Important To Innovation In The 20th Century,” Forbes
• “Google’s ’20% rule’ shows exactly how much time you should spend learning new skills—and why it works,” Dorie Clark
• Creativity, Inc. by Ed Catmull

(yk)

As expected from anyone who has ever tried building anything solo, my goal was not to build an app but the app — the one app that’s so good you wonder how you ever survived without it. I had everything in place: wireframes, a to-do list, project structure — you name it. Then I started building. Just not the product. I started with the landing page for it, which took me four days, and I hadn’t even touched the app’s core features yet. The idea itself was so good I had to start marketing it right away!

I found myself making every detail perfect: every color, shadow, gradient, font size, margin, and padding had to be spot on. I don’t even want to say how long the logo took.

Spoiler:
No one cares about your logo.

Why did I get so stuck on something that was never even part of the core app I wanted so badly to build? Why wasn’t I nagging myself to move on when I clearly needed to?

The reality of solo development is that there is no one to tell you when to stop or simply say, “Yo, this is good enough! Move on.“ Most users don’t care whether a login button is yellow or green. What they want (and need) is a button that works and solves their problem when clicking it.

Test Early And Often

Unnecessary tweaks, indecisive UI decisions, and perfectionism are the core reasons I spend more time on things than necessary.

Like most solo developers, I also started with the hope of pushing out builds with the efficiency of a large-scale team. But it is easier said than done.

When building solo, you start coding, then you maybe notice a design flaw, and you switch to fixing it, then a bug appears, and you try fixing that, and voilà — the day is gone. There comes a time when it hits you that, “You know what? It’s time to build messy.” That’s when good intentions of project and product management go out the window, and that’s when I find myself working by the seat of my pants rather than plowing forward with defined goals and actionable tasks that are based on good UI/UX principles, like storyboards, user personas, and basic prioritization.

This realization is something you have to experience to grasp fully. The trick I’ve learned is to focus on getting something out there for people to see and then work on actual feedback. In other words,

It’s more important to get the idea out there and iterate on it than reaching for perfection right out of the gate.

“

Because guess what? Even if you have the greatest app idea in the world, you’re never going to make it perfect until you start receiving feedback on it. You’re no mind reader — as much as we all want to be one — and some insights (often the most relevant) can only be received through real user feedback and analytics. Sure, your early assumptions may be correct, but how do you know until you ship them and start evaluating them?

Nowadays, I like to tell others (and myself) to work from hypotheses instead of absolutes. Make an assertion, describe how you intend to test it, and then ship it. With that, you can gather relevant insights that you can use to get closer to perfection — whatever that is.

Strength In Recognizing Weakness

Let’s be real: Building a full application on your own is not an easy feat. I’d say it’s like trying to build a house by yourself; it seems doable, but the reality is that it takes a lot more hands than the ones you have to make it happen. And not only to make it happen but to make it happen well.

There’s only so much one person can do, and admitting your strengths and weaknesses up-front will serve you well by avoiding the trap that you can do it all alone.

I once attempted to build a project management app alone. I knew it might be difficult, but I was confident. Within a few days, this “simple” project grew legs and expanded with new features like team collaboration, analytics, time tracking, and custom reports being added, many of which I was super excited to make.

Building a full app takes a lot of time. Think about it; you’re doing the work of a team all alone without any help. There’s no one to provide you with design assets, content, or back-end development. No stakeholder to “swoop and poop” on your ideas (which might be a good thing). Every decision, every line of code, and every design element is 100% on you alone.

It is technically possible to build a full-featured app solo, but when you think about it, there’s a reason why the concept of MVP exists. Take Instagram, for example; it wasn’t launched with reels, stories, creator’s insights, and so on. It started with one simple thing: photo sharing.

All I’m trying to say is start small, launch, and let users guide the evolution of the product. And if you can recruit more hands to help, that would be even better. Just remember to leverage your strengths and reinforce your weaknesses by leaning on other people’s strengths.

Yes, Think Like an MVP

The concept of a minimum viable product (MVP) has always been fascinating to me. In its simplest form, it means building the basic version of your idea that technically works and getting it in front of users. Yes, this is such a straightforward and widely distributed tip, but it’s still one of the hardest principles for solo developers to follow, particularly for me.

I mentioned earlier that my “genius” app idea grew legs. And lots of them. I had more ideas than I knew what to do with, and I hadn’t even written a reasonable amount of code! Sure, this app could be enhanced to support face ID, dark mode, advanced security, real-time results, and a bunch of other features. But all these could take months of development for an app that you’re not even certain users want.

I’ve learned to ask myself: “What would this project look like if it was easy to build?”. It’s so surreal how the answer almost always aligns with what users want. If you can distill your grand idea into a single indispensable idea that does one or two things extremely well, I think you’ll find — as I have — that the final result is laser-focused on solving real user problems.

Ship the simplest version first. Dark mode can wait. All you need is a well-defined idea, a hypothesis to test, and a functional prototype to validate that hypothesis; anything else is probably noise.

Handle Imperfection Gracefully

You may have heard about the “Ship it Fast” approach to development and instantly recognize the parallels between it and what I’ve discussed so far. In a sense, “Ship it Fast” is ultimately another way of describing an MVP: get the idea out fast and iterate on it just as quickly.

Some might disagree with the ship-fast approach and consider it reckless and unprofessional, which is understandable because, as developers, we care deeply about the quality of our work. However,

The ship-fast mentality is not to ignore quality but to push something out ASAP and learn from real user experiences. Ship it now — perfect it later.

“

That’s why I like to tell other developers that shipping an MVP is the safest, most professional way to approach development. It forces you to stay in scope and on task without succumbing to your whimsies. I even go so far as to make myself swear an “Oath of Focus” at the start of every project.

I, Vayo, hereby solemnly swear (with one hand on this design blueprint) to make no changes, no additions, and no extra features until this app is fully built in all its MVP glory. I pledge to avoid the temptations of endless tweaking and the thoughts of “just one more feature.”

Only when a completed prototype is achieved will I consider any new features, enhancements, or tweaks.

Signed,
Vayo, Keeper of the MVP

Remember, there’s no one there to hold you accountable when you develop on your own. Taking a brief moment to pause and accepting that my first version won’t be flawless helps put me in the right headspace early in the project.

Prioritize What Matters

I have noticed that no matter what I build, there’s always going to be bugs. Always. If Google still has bugs in the Google Notes app, trust me, then it’s fine for a solo developer to accept that bugs will always be a part of any project.

Look at flaky tests. For instance, you could run a test over 1,000 times and get all greens, and then the next day, you run the same test, an error shows. It’s just the nature of software development. And for the case of endlessly adding features, it never ends either. There’s always going to be a new feature that you’re excited about. The challenge is to curb some of that enthusiasm and shelve it responsibly for a later time when it makes sense to work on it.

I’ve learned to categorize bugs and features into two types: intrusive and non-intrusive. Intrusive are those things that prevent projects from functioning properly until fixed, like crashes and serious errors. The non-intrusive items are silent ones. Sure, they should be fixed, but the product will work just fine and won’t prevent users from getting value if they aren’t addressed right away.

You may want to categorize your bugs and features in other ways, and I’ve seen plenty of other examples, including:

• High value, low value;
• High effort, low effort;
• High-cost, low-cost;
• Need to have, nice to have.

I’ve even seen developers and teams use these categorizations to create some fancy priority “score” that considers each category. Whatever it is that helps you stay focused and on-task is going to be the right approach for you more than what specific category you use.

Live With Your Stack

Here’s a classic conundrum in development circles:

Should I use React? Or NextJS? Or wait, how about Vue? I heard it’s more optimized. But hold on, I read that React Redux is dead and that Zustand is the new hot tool.

And just like that, you’ve spent an entire day thinking about nothing but the tech stack you’re using to build the darn thing.

We all know that an average user could care less about the tech stack under the hood. Go ahead and ask your mom what tech stack WhatsApp is built on, and let me know what she says. Most times, it’s just us who obsesses about tech stacks, and that usually only happens when we’re asked to check under the hood.

I have come to accept that there will always be new tech stacks released every single day with the promise of 50% performance and 10% less code. That new tool might scale better, but do I actually have a scaling problem with my current number of zero users? Probably not.

My advice:

Pick the tools you work with best and stick to those tools until they start working against you.

“

There’s no use fighting something early if something you already know and use gets the job done. Basically, don’t prematurely optimize or constantly chase the latest shiny object.

Do Design Before The First Line of Code

I know lots of solo developers out there suck at design, and I’m probably among the top 50. My design process has traditionally been to open VS Code, create a new project, and start building the idea in whatever way comes to mind. No design assets, comps, or wireframes to work with — just pure, unstructured improvisation. That’s not a good idea, and it’s a habit I’m actively trying to break.

These days, I make sure to have a blueprint of what I’m building before I start writing code. Once I have that, I make sure to follow through and not change anything to respect my “Oath of Focus.”

I like how many teams call comps and wireframes “project artifacts.” They are pieces of evidence that provide a source of truth for how something looks and works. You might be the sort of person who works better with sets of requirements, and that’s totally fine. But having some sort of documentation that you can point back to in your work is like having a turn-by-turn navigation on a long road trip — it’s indispensable for getting where you need to go.

And what if you’re like me and don’t pride yourself on being the best designer? That’s another opportunity to admit your weaknesses up-front and recruit help from someone with those strengths. That way, you can articulate the goal and focus on what you’re good at.

Give Yourself Timelines

Personally, without deadlines, I’m almost unstoppable at procrastinating. I’ve started setting time limits when building any project, as it helps with procrastination and makes sure something is pushed out at a specified time. Although this won’t work without accountability, I feel the two work hand in hand.

I set a 2–3 week deadline to build a project. And no matter what, as soon as that time is up, I must post or share the work in its current state on my socials. Because of this, I’m not in my comfort zone anymore because I won’t want to share a half-baked project with the public; I’m conditioned to work faster and get it all done. It’s interesting to see the length of time you can go if you can trick your brain.

I realize that this is an extreme constraint, and it may not work for you. I’m just the kind of person who needs to know what my boundaries are. Setting deadlines and respecting them makes me a more disciplined developer. More than that, it makes me work efficiently because I stop overthinking things when I know I have a fixed amount of time, and that leads to faster builds.

Conclusion

The best and worst thing about solo development is the “solo” part. There’s a lot of freedom in working alone, and that freedom can be inspiring. However, all that freedom can be intoxicating, and if left unchecked, it becomes a debilitating hindrance to productivity and progress. That’s a good reason why solo development isn’t for everyone. Some folks will respond a lot better to a team environment.

But if you are a solo developer, then I hope my personal experiences are helpful to you. I’ve had to look hard at myself in the mirror many days to come to realize that I am not a perfect developer who can build the “perfect” app alone. It takes planning, discipline, and humility to make anything, especially the right app that does exactly the right thing.

Ideas are cheap and easy, but stepping out of our freedom and adding our own constraints based on progress over perfection is the secret sauce that keeps us moving and spending our time on those essential things.

Further Reading On SmashingMag

• “What’s The Perfect Design Process?,” Vitaly Friedman
• “Design Under Constraints: Challenges, Opportunities, And Practical Strategies,” Paul Boag
• “Improving The Double Diamond Design Process,” Andy Budd
• “Unexpected Learnings From Coding Artwork Every Day For Five Years,” Saskia Freeke

(gg, yk)

Front-end development seemed simpler in the early 2000s, didn’t it? The standard website consisted mostly of static pages made of HTML and CSS seasoned with a pinch of JavaScript and jQuery. I mean, who doesn’t miss the cross-browser compatibility days, right?

Fast forward to today, and it looks like a parallel universe is taking place with an overwhelming number of choices. Which framework should you use for a new project? Perhaps more established ones like React, Angular, Vue, Svelte, or maybe the hot new one that came out last month? Each framework comes with its unique ecosystem. You also need to decide whether to use TypeScript over vanilla JavaScript and choose how to approach server-side rendering (or static site generation) with meta-frameworks like Next, Nuxt, or Gatsby. And we can’t forget about unit and end-to-end testing if you want a bug-free web app. And we’ve barely scratched the surface of the front-end ecosystem!

But has it really gotten more complex to build websites? A lot of the frameworks and tooling we reach for today were originally crafted for massive projects. As a newcomer, it can be frightening to have so many to consider, almost creating a fear of missing out that we see exploited to sell courses and tutorials on the new hot framework that you “cannot work without.”

All this gives the impression that web development has gotten perhaps too complex. But maybe that is just an exaggeration? In this article, I want to explore those claims and find out if web development really is that complex and, most importantly, how we can prevent it from getting even more difficult than we already perceive it to be.

How It Was Before

As someone who got into web development after 2010, I can’t testify to my own experience about how web development was from the late 1990s through the 2000s. However, even fifteen years ago, learning front-end development was infinitely simpler, at least to me. You could get a website started with static HTML pages, minimal CSS for styling, and a sprinkle of JavaScript (and perhaps a touch of jQuery) to add interactive features, from toggled sidebars to image carousels and other patterns. Not much else was expected from your average developer beyond that — everything else was considered “going the extra mile.” Of course, the awesome native CSS and JavaScript features we have today weren’t around back then, but they were also unnecessary for what was considered best practice in past years.

Large and dynamic web apps certainly existed back then — YouTube and Facebook, to name a couple — but they were developed by massive companies. No one was expected to re-create that sort of project on their own or even a small team. That would’ve been the exception rather than the norm.

I remember back then, tend to worry more about things like SEO and page optimization than how my IDE was configured, but only to the point of adding meta tags and keywords because best practices didn’t include minifying all your assets, three shaking your code, caching your site on edge CDNs, or rendering your content on the server (a problem created by modern frameworks along hydration). Other factors like accessibility, user experience, and responsive layouts were also largely overlooked in comparison to today’s standards. Now, they are deeply analyzed and used to boost Lighthouse scores and impress search engine algorithms.

The web and everything around it changed as more capabilities were added and more and more people grew to depend on it. We have created new solutions, new tools, new workflows, new features, and whatever else new that is needed to cater to a bigger web with even bigger needs.

The web has always had its problems in the past that were worthy of fixing: I absolutely don’t miss tables and float layouts, along with messy DOM manipulation. This post isn’t meant to throw shade on new advances while waxing nostalgic about the good days of the “old wild web.” At the same time, though, yesterday’s problems seem infinitely simpler than those we face today.

JavaScript Frameworks

JavaScript frameworks, like Angular and React, were created by Google and Facebook, respectively, to be used in their own projects and satisfy the needs that only huge web-based companies like them have. Therein lies the main problem with web complexity: JavaScript frameworks were originally created to sustain giant projects rather than smaller ones. Many developers vastly underestimate the amount of time it takes to build a codebase that is reliable and maintainable with a JavaScript framework. However, the alternative of using vanilla JavaScript was worse, and jQuery was short for the task. Vanilla JavaScript was also unable to evolve quickly enough to match our development needs, which changed from simple informative websites to dynamic apps. So, many of us have quickly adopted frameworks to avoid directly mingling with JavaScript and its messy DOM manipulation.

Back-end development is a completely different topic, subject to its own complexities. I only want to focus on front-end development because that is the discipline that has perhaps overstepped its boundaries the most by bleeding into traditional back-end concerns.

Stacks Getting Bigger

It was only logical for JavaScript frameworks to grow in size over time. The web is a big place, and no one framework can cover everything. But they try, and the complexity, in turn, increases. A framework’s size seems to have a one-to-one correlation with its complexity.

But the core framework is just one piece of a web app. Several other technologies make up what’s known as a tech “stack,” and with the web gaining more users and frameworks catering to their needs, tech stacks are getting bigger and bigger. You may have seen popular stacks such as MEAN (MongoDB, Express, Angular, and Node) or its React (MERN) and Vue (MEVN) variants. These stacks are marketed as mature, test-proofed foundations suitable for any front-end project. That means the advertised size of a core framework is grossly underestimated because they rely on other micro-frameworks to ensure highly reliable architectures, as you can see in stackshare.io. Besides, there isn’t a one-size-fits-all stack; the best tool has always depended — and will continue to depend — on the needs and goals of your particular project.

This means that each new project likely requires a unique architecture to fulfill its requirements. Giant tech companies need colossal architectures across all their projects, and their stacks are highly engineered accordingly to secure scalability and maintenance. They also have massive customer bases, so maintaining a large codebase will be easier with more revenue, more engineers, and a clearer picture of the problem. To minimize waste, the tech stacks of smaller companies and projects can and should be minimized not only to match the scale of their needs but to the abilities of the developers on the team as well.

The idea that web development is getting too complex comes from buying into the belief that we all have the same needs and resources as giant enterprises.

“

Trying to imitate their mega stacks is pointless. Some might argue that it’s a sacrifice we have to make for future scalability and maintenance, but we should focus first on building great sites for the user without worrying about features users might need in the future. If what we are building is worth pursuing, it will reach the point where we need those giant architectures in good time. Cross that bridge when we get there. Otherwise, it’s not unlike wearing Shaquille O’Neal-sized sneakers in hopes of growing into them. They might not even last until then if it happens at all!

We must remember that the end-user experience is the focus at the end of the day, and users neither care about nor know what stack we use in our apps. What they care about is a good-looking, useful website where they can accomplish what they came for, not the technology we use to achieve it. This is how I’ve come to believe that web development is not getting more complex. It’s developers like us who are perpetuating it by buying into solutions for problems that do not need to be solved at a certain scale.

Let me be really clear: I am not saying that today’s web development is all bad. Indeed, we’ve realized a lot of great features, and many of them are thanks to JavaScript frameworks that have pushed for certain features. jQuery had that same influence on JavaScript for many, many years.

We can still create minimum viable products today with minimal resources. No, those might not make people smash the Like button on your social posts, but they meet the requirements, nothing more and nothing less. We want bigger! Faster! Cheaper! But we can’t have all three.

If anything, front-end development has gotten way easier thanks to modern features that solve age-old development issues, like the way CSS Flexbox and Grid have trivialized layouts that used to require complex hacks involving floats and tables. It’s the same deal with JavaScript gaining new ways to build interactions that used to take clever workarounds or obtuse code, such as having the Intersection Observer API to trivialize things like lazy loading (although HTML has gained its own features in that area, too).

We live in this tension between the ease of new platform features and the complexity of our stacks.

“

Do We Need A JavaScript Framework For Everything?

Each project, regardless of its simplicity, desperately needs a JavaScript framework. A project without a complex framework is like serving caviar on a paper plate.

At least, that’s what everyone seems to think. But is that actually true? I’d argue on the contrary. JavaScript frameworks are best used on bigger applications. If you’re working on a smaller project, a component-based framework will only complicate matters, making you split your website into a component hierarchy that amounts to overkill for small projects.

The idea of needing a framework for everything has been massively oversold. Maybe not directly, but you unconsciously get that feeling whenever a framework’s name pops in, as Edge engineer Alex Russell eloquently expresses in his article, “The Market For Lemons”:

“These technologies were initially pitched on the back of “better user experiences” but have utterly failed to deliver on that promise outside of the high-management-maturity organisations in which they were born. Transplanted into the wider web, these new stacks have proven to be expensive duds.”

— Alex Russell

Remember, the purpose of a framework is to simplify your life and save time. If the project you’re working on is smaller, the time you supposedly save is likely overshadowed by the time you spend either setting up the framework or making it work with the rest of the project. A framework can help make bigger web apps more interactive and dynamic, but there are times when a framework is a heavy-handed solution that actually breeds inefficient workflows and introduces technical debt.

Step back and think about this: Are HTML, CSS, and a touch of JavaScript enough to build your website or web application? If so, then stick with those. What I am afraid of is adding complexity for complexity’s sake and inadvertently raising the barrier to entry for those coming into web development. We can still accomplish so much with HTML and CSS alone, thanks again to many advances in the last decade. But we give the impression that they are unsuitable for today’s web consumption and need to be enhanced.

Knowing Everything And Nothing At The Same Time

The perceived standard that teams must adopt framework-centered architectures puts a burden not only on the project itself but on a developer’s well-being, too. As mentioned earlier, most teams are unable to afford those architectures and only have a few developers to maintain them. If we undermine what can be achieved with HTML and CSS alone and set the expectations that any project — regardless of size — needs to have a bleeding edge stack, then the weight to meet those expectations falls on the developer’s shoulders, with the great responsibility of being proficient in all areas, from the server and database to front end, to design, to accessibility, to performance, to testing, and it doesn’t stop. It’s what has been driving “The Great Divide” in front-end development, which Chris Coyier explains like this:

“The divide is between people who self-identify as a (or have the job title of) front-end developer yet have divergent skill sets. On one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. On the other, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, and so on.”

— Chris Coyier

Under these expectations, developers who focus more on HTML, CSS, design, and accessibility rather than the latest technology will feel less valued in an industry that appears to praise those who are concerned with the stack. What exactly are we saying when we start dividing responsibilities in terms of “full-stack development” or absurd terms like “10x development”? A while back, Brad Frost began distinguishing these divisions as “front-of-the-front-end” and “back-of-the-front-end”.

Mandy Michael explains what impact the chase for “full-stack” has had on developers trying to keep up:

“The worst part about pushing the “know everything” mentality is that we end up creating an industry full of professionals suffering from burnout and mental illness. We have people speaking at conferences about well-being, imposter syndrome, and full-stack anxiety, yet despite that, we perpetuate this idea that people have to know everything and be amazing at it.”

— Mandy Michael

This isn’t the only symptom of adopting heavy-handed solutions for what “vanilla” HTML, CSS, and JavaScript already handle nicely. As the expectations for what we can do as front-end developers grow, the learning curve of front-end development grows as well. Again, we can’t learn and know everything in this vast discipline. But we tell ourselves we have to, and thanks to this mentality, it’s unfortunately common to witness developers who may be extremely proficient with a particular framework but actually know and understand little of the web platform itself, like HTML semantics and structure.

The fact that many budding developers tend to jump straight into frameworks at the expense of understanding the basics of HTML and CSS isn’t a new worry, as Rachel Andrew discussed back in 2019:

“That’s the real entry point here, and yes, in 2019, they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However, those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.”

— Rachel Andrew

And I want to clarify yet again that modern Javascript frameworks and libraries aren’t inherently bad; they just aren’t designed to replace the web platform and its standards. But we keep pushing them like we want them to!

The Consequences Of Vendor Lock-In

“Vendor lock-in” happens when we depend too deeply on proprietary products and services to the extent that switching to other products and services becomes a nearly impossible task. This often occurs when cloud services from a particular company are deeply integrated into a project. It’s an issue, especially in cloud computing, since moving databases once they are set up is expensive and lengthy.

Vendor lock-in in web development has traditionally been restricted to the back end, like with cloud services such as AWS or Firebase; the front-end framework, meanwhile, was a completely separate concern. That said, I have noticed a recent trend where vendor lock-in is reaching into meta-frameworks, too. With the companies behind certain meta-frameworks offering hosting services for their own products, swapping hosts is increasingly harder to do (whether the lock-in is designed intentionally or not). Of course, companies and developers will be more likely to choose the hosting service of the company that made a particular framework used on their projects — they’re the experts! — but that only increases the project’s dependency on those vendors and their services.

A clear example is the relationship between Next and Vercel, the parent cloud service for Next. With the launch of Next 13, it has become increasingly harder to set up a Next project outside of Vercel, leading to projects like Open Next, which says right on its website that “[w]hile Vercel is great, it’s not a good option if all your infrastructure is on AWS. Hosting it in your AWS account makes it easy to integrate with your backend [sic]. And it’s a lot cheaper than Vercel.” Fortunately, the developers’ concerns have been heard, and Next 14 brings clarity on how to self-host Next on a Node server.

Another example is Gatsby and Gatsby Cloud. Gatsby has always offered helpful guides and alternative hosting recommendations, but since the launch of Gatsby Cloud in 2019, the main framework has been optimized so that using Gatsby and Gatsby Cloud together requires no additional hosting configurations. That’s fantastic if you adopt both, but it’s not so great if all you need is one or the other because integrating the framework with other hosts — and vice versa — is simply harder. It’s as if you are penalized for exercising choice.

And let’s not forget that no team expected Netlify to acquire Gatsby Cloud in February 2023. This is a prime case where the vendor lock-in problem hits everybody because converting from one site to another comes at a cost. Some teams were charged 120% more after converting from Gatsby Cloud to Netlify — even with the same plan they had with Gatsby Cloud!

What’s the solution? The common answer I hear is to stop using paid cloud services in favor of open-sourced alternatives. While that’s great and indeed a viable option for some projects, it fails to consider that an open-source project may not meet the requirements needed for a given app.

And even then, open-source software depends on the community of developers that maintain and update the codebase with little to no remuneration in exchange. Further, open source is equally prone to locking you into certain solutions that are designed to solve a deficiency with the software.

There are frameworks and libraries, of course, that are in no danger of being abandoned. React is a great example because it has an actively engaged community behind it. But you can’t have the same assurance with each new dependency you add to a project. We can’t simply keep installing more packages and components each time we spot a weak spot in the dependency chain, especially when a project is perfectly suited for a less complex architecture that properly leverages the web platform.

Choosing technology for your stack is an exercise of picking your own poison. Either choose a paid service and be subject to vendor lock-in in the future, or choose an open-source one and pray that the community continues to maintain it.

“

Those are virtually the only two choices. Many of the teams I know or have worked on depend on third-party services because they cannot afford to develop them on their own; that’s a luxury that only massive companies can afford. It’s a problem we have to undergo when starting a new project, but one we can minimize by reducing the number of dependencies and choosing wisely when we have to.

Each Solution Introduces A New Problem

Why exactly have modern development stacks gotten so large and complex? We can point a finger at the “Development Paradox.” With each new framework or library, a new problem crops up, and time-starved developers spend months developing a new tool to solve that problem. And when there isn’t a problem, don’t worry — we will create one eventually. This is a feedback loop that creates amazing solutions and technologies but can lead to over-engineered websites if we don’t reign it in.

This reminds me of the famous quote:

“The plain fact is that if you don’t have a problem, you create one. If you don’t have a problem, you don’t feel that you are living.”

— U.G. Krishnamurti

Let’s look specifically at React. It was originally created by Facebook for Facebook to develop more dynamic features for users while improving Facebook’s developer experience.

Since React was open-sourced in 2013 (and nearly re-licensed in 2017, if it weren’t for the WordPress community), hundreds of new utilities have been created to address various React-specific problems. How do you start a React project? There’s Create React App and Vite. Do you need to enhance your state management? There is Redux, among other options. Need help creating forms? There is a React Hook Form. And perhaps the most important question: Do you need server-side rendering? There’s Next, Remix, or Gatsby for that. Each solution comes with its own caveats, and developers will create their own solutions for them.

It may be unfair to pick on React since it considers itself a library, not a framework. It’s inevitably prone to be extended by the community. Meanwhile, Angular and Vue are frameworks with their own community ecosystems. And this is the tip of the iceberg since there are many JavaScript frameworks in the wild, each with its own distinct ideology and dependencies.

Again, I don’t want you to get the wrong idea. I love that new technologies emerge and find it liberating to have so many options. But when building something as straightforward as a webpage or small website — which some have started referring to as “multi-page applications” — we have to draw a line that defines how many new technologies we use and how reliable they are. We’re quite literally mashing together third-party code written by various third-party developers. What could go wrong? Please don’t answer that.

Remember that our users don’t care what’s in our stacks. They only see the final product, so we can save ourselves from working on unnecessary architectures that aren’t appreciated outside of development circles. It may seem counterintuitive in the face of advancing technology, but knowing that the user doesn’t care about what goes behind the scenes and only sees the final product will significantly enhance our developer experience and free you from locked dependencies. Why fix something that isn’t broken?

How Can We Simplify Our Codebases?

We’ve covered several reasons why web development appears to be more complex today than in years past, but blaming developers for releasing new utilities isn’t an accurate portrayal of the real problem. After all, when developing a site, it’s not like we are forced to use each new technology that enters the market. In fact, many of us are often unaware of a particular library and only learn about it when developing a new feature. For example, if we want to add toast notifications to our web app, we will look for a library like react-toastify rather than some other way of building them because it “goes with” that specific library. It’s worth asking whether the app needs toast notifications at all if they introduce new dependencies.

Imagine you are developing an app that allows users to discover, review, and rate restaurants in their area. The app needs, at a bare minimum, information about each restaurant, a search tool to query them, and an account registration flow with authentication to securely access the account. It’s easy to make assumptions about what a future user might need in addition to these critical features. In many cases, a project ends up delayed because we add unnecessary features like SSR, notifications, offline mode, and fancy animations — sometimes before the app has even converted its first registered user!

I believe we can boil down the complexity problem to personal wishes and perceived needs rather than properly scoping a project based on user needs and experiences.

That level of scope creep can easily turn into an over-engineered product that will likely never see the light of launching.

What can we do to simplify our own projects? The following advice is relevant when you have control over your project, either because it’s a personal one, it’s a smaller one for a smaller team, or you have control over the decisions in whatever size organization you happen to be in.

The hardest and most important step is having a sense of detection when your codebase is getting unnecessarily complicated. I deem it the hardest step because there is no certainty of what the requirements are or what the user needs; we can only make assumptions. Some are obvious, like assuming the user will need a way to log into the app. Others might be unclear, like whether the app should have private messaging between users. Others are still far-fetched, like believing users need extremely low latency in an e-commerce page. Other features are in the “nice to have” territory.

That is regarding the user experience, but the same questions emerge on the development side:

• Should we be using a CSS preprocessor or a CSS framework, or can we achieve it using only CSS modules?
• Is vanilla JavaScript enough, or are we going to add TypeScript?
• Does the app need SSR, SSG, or a hybrid of the two?
• Should we implement Redis on the back end for faster database queries, or is that too much scope for the work?
• Should we be implementing end-to-end testing or unit tests?

These are valid questions that should be considered when developing a site, but they can distract us from our main focus: getting things done.

“Done is better than perfect.”

— Sheryl Sandberg

And, hey, even the largest and most sophisticated apps began as minimal offerings that iterated along the way.

We also ought to be asking ourselves what would happen if a particular feature or dependency isn’t added to the project. If the answer is “nothing,” then we should be shifting our attention to something else.

Another question worth asking: “Why are we choosing to add [X]?” Is it because that’s what is popular at the moment, or because it solves a problem affecting a core feature? Another aspect to take into consideration is how familiar we are with certain technologies and give preference to those we know and can start using them right away rather than having to stop and learn the ins and outs of a new framework.

Choose the right tool for the job, which is going to be the one that meets the requirements and fits your mental model. Focus less on a library’s popularity and scalability but rather on getting your app to the point where it needs to scale in the first place.

Conclusion

It’s incredibly difficult to not over-engineer web apps given current one-size-fits-all and fear-of-missing-out mentalities. But we can be more conscious of our project goals and exercise vigilance in guarding our work against scope creep. The same can be applied to the stack we use, making choices based on what is really needed rather than focusing purely on what everyone else is using for their particular work.

After reading the word “framework” exactly 48 times in this article, can we now say the web is getting too complex? It has been complex by nature since its origins, but complexity doesn’t translate to “over-engineered” web apps. The web isn’t intrinsically over-engineered, and we only have ourselves to blame for over-engineering our projects with overly-wrought solutions for perceived needs.

(gg, yk)

Ask just about any casual user to explain the difference between WordPress.org and WordPress.com, and you’re likely to get a shrug in response. I know this because it’s one of the first things I ask students in my WordPress development course each semester when introducing them to the content management system.

I love asking that question because it boggles my mind that a platform responsible for powering 43% of the internet can go largely unrecognized, the same sort way Taylor Swift can walk into a packed football stadium unnoticed.

But among the power users and developers among us, the difference between WordPress.org and WordPress.com is not only apparent but a divide that draws a sacred but blurry line between the lively open-source community that WordPress is known for, and the commercial efforts of Automattic, the company that uses WordPress to power its hosted CMS platform.

The difference is a sacred line because crossing it tarnishes the open-source-ness of WordPress as a decentralized project maintained by a community of largely unpaid contributors.

Keeping special interests out of the mix is what keeps WordPress for the people, by the people.

“

That sacred line is also blurry, at best, and a great example of that popped up this past week when WordPress.com published a clone of the WordPress.org Plugin Directory to its own site. As is usually the case with WordPress #HotDrama, one or two developers take notice of a change, post a tweet about it, and Automattic founder Matt Mullenweg splashes a little kerosene on it. In this particular case, plugin pages on WordPress.com appeared to outrank plugin pages on WordPress.org in web searches.

This is yet another example of a situation that pits the open-source community against Automattic’s commercial interests. We’ve been here plenty of times in the 20-plus years that WordPress has been with us. The debates are nuanced, of course, but I’ll loosely characterize each side’s point in broad strokes:

• WordPress.org: You are using the sweat equity of the open-source community to advance your own company.
• WordPres.com: Hey, we’re merely distributing your work to a larger audience in a way we both benefit.

The problem is that this is where the debate often moves from being productive to getting downright dirty. No one benefits in these conditions.

It’s possible for both sides of the debate to be true, even if they do not agree. It would be just as disingenuous for plugin developers to claim no benefit from WordPress.com’s exposure as it is for Automattic to claim that developers gain as much in rewards as they spend writing code.

And therein lies the rub. When the discussion veers towards labor concerns and hurt feelings, we get away from the real issue at heart: WordPress has a positioning problem, not a plugin problem.

Sure, that makes for a spicy headline, but there’s real substance to it. How different would it be if the debate was between WordPress and Automattic rather than WordPress against WordPress? I imagine it would be quite different.

It is no longer an issue of search rankings and blocked accounts but one that is truly about distribution and labor in the open-source community.

“

When we draw sharper lines between business and community, we can have clearer discussions without the blurry divisions getting in the way and throwing the conversation off-topic.

This is the absolute perfect time to reposition WordPress. Five years after Matt’s famous advice to “Learn JavaScript deeply,” WordPress has transformed into an entirely visual editing experience that has radically transformed how we interact with it, both as users and developers. The “Gutenberg” project — and the full-site editing capabilities it brought — has ushered in a new era of WordPress where everyone’s relationship with it has changed. It’s time to change the general perception of WordPress as far as what it is and what it’s used for while we are at it.

It’s possible that a product becomes so successful or changes so drastically that it no longer fits under its own umbrella. Facebook becomes Meta. Google becomes Alphabet. Twitter has become whatever it is today. Products and companies evolve over time like people. This is what has happened with WordPress.com and WordPress.org. Each is vying for their own identity and winds up battling each other rather than buttressing one another. A cloned version of the WordPress.org Plugin Directory on WordPress.com exacerbates the issue rather than solving it. We’ve really reached the point of diminishing returns with the “WordPress” brand equity.

The only way this is fixed is by shedding the “WordPress” label from Automattic’s commercial efforts. Matt is not wrong when he claims that shared branding has made it difficult for services like Typepad to compete in the CMS space. That was true for a long time. But with a 43.1% market share today, is there really an existential threat to WordPress that requires co-branding two different flavors of WordPress? The current threat to WordPress’ market dominance has more to do with its future as a product and how it competes in a world of low-code and no-code platforms. There’s no amount of co-branding that is capable of solving what is, in essence, a user interface and experience challenge.

In that same tweet, Matt also asks us to imagine what WordPress would look like without co-branding, pointing to Joomla as a case in point. Again, co-branding may indeed have helped get WordPress to where it is today. But to say that it always has and always will is a large leap in logic on a false premise. Co-branding may not always be the best or only way to maintain market share or beat the competition. To think so is errant and myopic in a way that assumes no other possibilities, ever, as if past successes always lead to new ones. Myopia often sows the seeds of failure.

I believe we’ve reached the point where we ought to at least question co-branding as a strategy and consider whether there are happier paths to follow. If I have to imagine what WordPress looks like without co-branding today instead of in the past, I see the possibility of a clear separation of concerns between business and community interests because, at this point, there is little to no difference between running a WordPress site on WordPress.com’s servers on its Business Plan and self-hosting the site on a managed host like WP Engine. You get the same access to the same files for the same underlying software that is used to power WordPress.com, the same as it is used to power any other website that chooses to download and self-host WordPress.

That said, I am not totally against co-branding. The problem could be as much about not going far enough with co-branding as it is having too much of it. As it currently stands, the similarities between WordPress.com and WordPress.org are too indistinguishable at first glance that perhaps sharing the same top-level domain name only muddies the perceived similarities — or differences — even more. Perhaps there’s a happy path that gives credit to both perspectives in the debate with more explicit names, such as WordPress Platform and WordPress CMS. Those are terrible names, but hopefully, you get what I am aiming at.

The bottom line is this: We have danced around WordPress’ positioning problem way too long, hiding behind its past successes while tension between commercial and community interests continues to boil over. Rather than allowing this to continue by sitting somewhere in the middle with a shared brand name, maybe we’ll see a day where we go all-in on a direction either by renaming WordPress.com to allow WordPress.org to be WordPress or leaning deeper into effective co-branding that properly distinguishes the two properties while leveraging the “WordPress” brand.

References And Resources

• “Developers Raise Concerns About WordPress.com Plugin Listings Outranking WordPress.org on Google Search,” Sarah Gooding (WP Tavern)
• “WordPress.com Plugin Pages Add Download Link for Using Plugins on Self-Hosted Sites,” Sarah Gooding (WP Tavern)
• “Developers Claim Damaged Trust Following Public Confrontations with WordPress Leadership,” Sarah Gooding (WP Tavern)
• “A Call for Accountability: Sharing My WordPress Code of Conduct Report,” Sé Reed
• “WordPress Full-Site Editing: A Deep Dive Into The New Feature,” Nick Schäferhoff
• “The Modern Way To Create And Host A WordPress Site,” Nick Babich
• “Implications Of WordPress Joining The Block Protocol,” Leonardo Losoviz

(yk, il)

At the start of the Coronavirus pandemic, I led the redesign of a tablet app used by sales representatives of the world’s largest food & beverage company. Never having been a sales representative, nor having ever played one on TV, I was curious about their typical workday. Adapting the first rule of design — Know Thy User — our lockdown approach was to conduct video interviews. As soon as company restrictions allowed, I met two sales representatives at a local Walmart.

Masked and socially distant, I walked a mile in their shoes through the dairy, pet food, and freezer aisles. This single visit uncovered many insights that had not come up in the video interviews and online walkthroughs. I shared this with the team, spread across the world, and everyone could empathize with the sales representatives: juggling multiple devices and printouts, struggling to make technology work in extreme conditions like a low-lit walk-in freezer, and trying to work without hindering harried shoppers. The sales reps would repeat these tasks between twenty and thirty times a day, five days a week, which sounds about as fun as it is.

Our team used these insights to experiment with different concepts, refine them based on feedback from sales representatives, and launch a redesigned app that received glowing feedback from the representatives and praise from the company stakeholders.

Curiosity, empathy, and collaboration were some of the designer-like or designerly behaviors we used to transform the sales representatives’ experience. These behaviors are a few of the behaviors and skills that designers use throughout the design process. Design researcher and educator Nigel Cross first used the word designerly to refer to underlying patterns of how designers think and act.

Designers spend years learning technical design skills, and as they use those hard skills to do their jobs, their designs are impactful when they actively use these non-technical designerly skills and behaviors. Designerly skills and behaviors make us creative and innovative and distinguish us from machines and technology like Artificial Intelligence (AI).

Yes, the same AI that you can’t avoid reading or hearing about on social media or in the news. Stories and posts about people being equally worried about layoffs and AI taking over their jobs, and some even suggesting that AI is why those jobs won’t come back. Creators and people traditionally considered creative, like artists, writers, and designers, seem especially concerned about AI making them redundant. Guesstimates of when AI will perform tasks better than humans just add to the frenzy.

The assumption that AI will replace people is based on the premise that both have the same qualities, abilities, and skills. But that’s just not true. Artificial intelligence is simply technology that is taught to mimic human intelligence to perform tasks. It is trained on large amounts of data — by some estimates, the equivalent of a quarter of the Library of Congress, the world’s largest library.

AI is better than humans in certain tasks that involve processing and analyzing large amounts of data quickly, accurately, rationally, and consistently. Artificial Intelligence may create, but it can’t be creative. It cannot match humans in areas that rely on skills and behaviors that are distinctly human, like intuition, emotional intelligence, cultural context, and changing situations.

Humans are conscious beings with a subconscious mind that can influence decisions and change those decisions based on experience, context, environment, wisdom, and understanding. This takes us years, decades, and even a lifetime to learn and apply, and it cannot be programmed in machines, no matter how sentient they may appear to be. Not for the foreseeable future.

Being designerly takes thinking, feeling, and acting like a designer. I’ve been thinking about and observing what it means to be designerly, and by using six such skills and behaviors, I will discuss how humans have an advantage over AI. I used the head, heart, and hands approach for transformative sustainability learning (Orr, Sipos, et al.) to organize these designerly skills related to thinking (head), feeling (heart), and doing (hands), and offer ways to practice them.

Using our head, heart, and hands together to make a transformative difference is what distinguishes us from AI and makes us human, creative, and innovative.

“

Head

The skills, behaviors, and habits to help you think like a designer and create a designerly mindset include curiosity and observation.

Cultivate Curiosity

Curiosity is the desire to know. It is a pleasure to ask, explore, experiment, discover, learn, and understand. We see this relentless curiosity in small children, who explore everything novel around them. As they grow up, that curiosity starts getting stifled in many, partly because they are taught to look for an answer instead of exploring questions.

This curiosity stifler of focusing on the answer is what AI is programmed to do. AI is also limited by its knowledge and understanding of the world, unable to explore beyond those boundaries. Also, without physical senses, AI cannot experience the world and be curious about things we see, hear, touch, taste, and smell around us.

This gives us a leg up on AI if we can overcome other curiosity-stiflers like self-consciousness, the shame of not knowing, and the fear of ridicule.

Let’s deconstruct curiosity to understand different types of curiosity we can nurture and build in ways AI cannot. In the 1950s, British-Canadian psychologist Daniel Berlyne presented a model distinguishing between two types of curiosity: perceptual, based on stimulation, and epistemic, driven by a genuine desire for knowledge. He also distinguished between two types of behaviors to address that curiosity: diversive exploration, motivated by a need for novel stimulation or a desire to explore, and specific exploration, motivated by curiosity and a search for new information.

This gives us four dimensions of curiosity, which have their time and place, but the quadrant we are discussing lies at the intersection of the desire to explore and the desire for knowledge. Diversive-Epistemic curiosity is where people use the desire to explore and apply it to learning new things. TED Talks are an example of knowledge exploration, where people can learn about just about any topic they care to explore.

You can cultivate curiosity by being intentional in developing the joy of exploration. Set some time aside every day to learn something new, and pick topics that interest you. Start small and gradually increase the time you spend learning something daily as well as for expanding the topics. I would suggest starting with just 10–20 minutes a day. That’s enough time to watch a TED talk, read a book summary, or start learning a new skill. Reading multiple book summaries on a topic is an easy way to identify the next book you should read cover to cover over a few days or weeks.

Curious exploration broadens the mind to new ideas, perspectives, and approaches, lays the foundation for the cross-pollination of ideas, and leads to creative and innovative solutions.

“

Advantage: People

Notice & Observe

While often used as synonyms, noticing is seeing something for the first time, while observing is paying close attention to something or someone. Being creative begins with noticing what others have overlooked, followed by closer, intentional observation when warranted.

In traditional ethnography, researchers observe people and cultures in an immersive manner. Design ethnography or digital ethnography is not as extreme; researchers and designers only spend days or weeks observing users, instead of years. The operative word is observing — watching and listening. The payoff is that ethnography can inform and improve design decisions. You don’t need to wait for your next project to observe people. Instead, make it an everyday habit, and you will not only hone your powers of observation, but it will also gradually become second nature.

AI cannot do this because it relies on the limited data it is trained with, unlike people who have an unlimited ability to notice and observe new things all the time. Even if it could overcome that hurdle, without emotions and context, AI would not be able to understand the feelings and emotions involved in the people or situation being observed. We can observe a situation and understand the context and meaning behind it as we process what we are noticing and observing.

We can build our power of observation by taking the time to pay attention to people and their behavior. You can do this anytime — while you are in a coffee shop or waiting in the grocery checkout line. Get your nose out of that glowing rectangle, remove your headphones, and look around. While you may end up seeing others captivated by their own glowing rectangles, start observing the details:

• What type of phones are they using?
• Are they passively consuming content or actively interacting with a game or person?
• What emotions do you notice?

When you start paying attention, you will be surprised by things you may have seen but not noticed or observed in the past. And the more you practice, the more natural it will become. Noticing and observing the world around you in new and different ways provides inspiration and helps reveal issues and patterns, leading to better ideas and solutions.

Advantage: People

Heart

The skills, behaviors, and habits to help you feel like a designer and create a designerly attitude include empathy and advocacy.

Be Empathetic

My favorite definition of empathy is by Roman Krznaric in his book, Empathy: Why It Matters, and How to Get It:

Empathy is the art of stepping imaginatively into the shoes of another person, understanding their feelings and perspectives, and using that understating to guide your actions.
— Roman Krznaric

There are three types of empathy, according to psychologists Daniel Goleman and Paul Ekman:

1. Cognitive,
2. Emotional,
3. Compassionate.

The empathy that results in thinking, feeling, and doing are all important and have their place in our lives, but the empathy that results in doing, compassionate empathy, goes beyond understanding others and sharing their feelings by driving us to do what we can to help them. This helps us make a difference in people’s lives. I am talking about genuinely employing empathy, not doing it as lip service or checking a box off in the process.

Successful designers routinely use empathy in human-centered design. They start with an understanding of the people they are designing for by observing them and immersing themselves in their users’ environments. Designers then apply that deep understanding to design products and experiences that work for those users.

While AI can measure people’s emotions from their expressions and is being trained to mimic human emotions, AI machines and tools don’t have consciousness and cannot understand or experience emotions. AI also lacks personal, shared experiences that allow us to show empathy to varying degrees.

Even if you are not empathetic by nature, try building it over the coming days with one or more interactions with others:

• Suspend judgment.
  It is difficult to be empathetic if you are mentally judging the other person. If you voice that judgment, you will not be able to be empathetic, and the other person may stop sharing with you.
• Listen attentively with your eyes and ears.
  Engage more than one sense to listen actively so that you can respond deeply. Pay attention to what the other person is saying, not how you need to respond. Be completely present with the other person, putting aside our modern distractions.

Being empathetic takes practice for most of us. Be empathetic.

Advantage: People

Advocate For Others

User advocacy is at the heart of designerly skills and behaviors. The skills and behaviors of curiosity, observance, and empathy create a deep understanding of users and their needs, but that is only the beginning. User advocacy brings all of the above to life and turns that respect for the user into action to address their needs. It also shares that understanding with others involved so they, too, can identify with users.

Being a user advocate means representing the interests of users in an ocean of competing interests. A user advocate represents the user throughout the design process, giving the user a voice, bringing them to life, and making the impersonal user personal.

Without curiosity, observation, and empathy, AI is unable to use those skills and behaviors to be an advocate. AI also lacks the creativity to come up with solutions to address the needs of others. AI can be programmed to follow rules and guidelines to protect people, an increasingly important area of ethical AI. If you’ve been following the news, this has led to mixed results, sometimes going off the deep end in some instances. No points for guessing that AI cannot make ethical judgment calls on its own.

However, people can do that. And we can manifest it in design by doing what’s right for users. I previously wrote about principles for designers; two of them summarized below:

• Do no harm.
  Your decisions may affect the minds, behavior, and lives of your users and others around them, so be alert and guard against misusing the influence of your designs. Ask yourself: Would you be comfortable with someone else using your design on you, your parents, or your child?
• Be aware of your responsibility to your intended users, unintended users, and society at large.
  Accept appropriate responsibility for the outcomes of your design. During design, follow up answers to “How might we…?” with “At what cost?”

Remind yourself that you are not the user and use your knowledge of the user to represent the user when they are absent. Advocate for them.

Advantage: People

Hands

The skills, behaviors, and habits to help you act like a designer are brought to life through visual communication and collaboration.

Communicate Visually

Storytelling is an important skill that vividly paints a picture in people’s minds, driving them to action. It converts words to a visual that people will remember, but even then, different people may all visualize the same thing differently. This happens whether you’re listening to your favorite inspirational speaker or reading your favorite fiction author. No matter how painstakingly a speaker or author describes a character or a situation, chances are high that two people sitting right next to each other both have different images in their minds. However, when there is an accompanying image or visual, people are literally on the same page (or slide, graph), which slashes the risk of them imagining different things. That’s the power of thinking and communicating visually.

Not all designers are artistic, but you don’t have to be artistic to be a visual thinker or communicator. Even a rough sketch on a whiteboard or a notepad can often communicate information faster than the written or verbal form. The aim is to make ideas tangible quickly, to get to the right idea faster. User researchers and designers commonly use visualizations to help them make sense of data and come up with new ideas.

Without physical senses, AI cannot think or communicate visually. Without emotions, the ability to understand context, and creativity, AI cannot ‘read the room’ or come up with ideas outside its dataset and communicate outside its current language abilities, making visual communication impossible. However, people can use AI as a tool to communicate visually, especially with tools that convert text prompts to images.

Next time you describe something, instead of writing a page of instructions or talking it out, use a quick sketch. Describing a process? Boxes and arrows are very powerful. Talking about a screen or two? A rough layout, highlighting the important parts, along with an arrow showing how you get from one to another, is more powerful. Or a quick screen recording. Sketching not your thing? Use images. I’ve been known to use LEGO photography in my articles and presentations. You can also mock up something without advanced design tools. For instance, I had a non-designer boss who communicated visually using PowerPoint. And if you are in the mood to explore and experiment, try one of the many AI text-to-image generators.

Show. Don’t only tell.

Advantage: People

Collaborate

We can achieve much more, much faster, working together. It is uncommon for a single person to come up with the best solution by themselves. Gone are the days of the lone designer working on a solution by themselves. No single person or discipline has the answer to all problems, design or otherwise. It usually takes a team from different disciplines and backgrounds to solve big problems.

A multi-disciplinary team working together toward a common goal is an example of collaboration. This brings different perspectives into the creation process, from idea generation to providing feedback and validation during the creation process.

Collaboration relies on understanding and navigating social dynamics. While some people struggle with that, AI fails. Ditto for the ability to negotiate or compromise. Some people struggle with that too, but AI cannot unless specifically programmed to. Collaboration also requires the ability to adapt based on live inputs, feedback, or the situation, which traditional AI has limited capability to do beyond its training phase.

That said, AI can support collaboration if you think about people collaborating with AI tools. We’ve seen how AI tools can generate designs, logos, layouts, code, write content, do homework, and generate legal documents. But there are enough examples of it being plain wrong, which is why we should use them as assistants in our workflow.

AI tools can support the efforts of designers and researchers by reducing manual human effort (e.g., transcribing), making people more efficient and saving time (e.g., text-based video editing), providing machine learning-based insight (e.g., attention prediction), and augmenting human effort (e.g., AI evaluation). Just remember that AI is not perfect, and there are plenty of mistakes and errors, as shown below (I’m not India-based, did not write The UX Book, and never taught at the schools mentioned).

Next time you are working on a project, get others involved. These could be different departments, different specialties, different backgrounds, and, where appropriate, even customers — maybe even AI.

Advantage: People

Conclusion

I’ll use an analogy from the restaurant industry of chefs and cooks to draw parallels between humans and AI. Chefs can cook meals by themselves, but they are more effective when they focus on the strategic work of planning the menu, overseeing the cooks who tactically follow recipes, sometimes improvising, and applying the finishing touches before the meal is served to customers. Robots have replaced parts of what cooks do and technology that may suggest recipes and meals, but it still needs the chef to make the final decisions.

Artificial Intelligence is changing the way we work and live, making us more efficient. As designers, we can use AI to support ideation, analyze data, generate variations, and predict behavior based on patterns. This will free us up to focus on more strategic aspects of design, using the designerly skills above which are impossible to duplicate, and for which people have the advantage over AI. We can use AI to make us more efficient and allow us to do what we do best — understand our users, stakeholders, and real-world constraints and then collaborate with others to design successful solutions. What we do won’t change as much as how we do it, with AI augmenting, instead of replacing us.

Advantage: People

AI cannot be trained to mimic these designerly skills the way we can practice and develop them because it is not conscious, cannot adapt, and does not have the experiences, emotions, or intuition that we have. AI can artificially mimic some but cannot match human abilities in these areas. Skills like curiosity, observation, empathy, advocacy, visual communication, and collaboration are key non-technical skills to help us use the head, heart, and hands together to be more designerly and thrive in a world of AI.

Resources:

Links

• “What Is ChatGPT Doing … and Why Does It Work?,” Stephen Wolfram
  Yes, AI is more than ChatGPT, but this is the AI tool that’s currently viral
• “Why Chatbots Sometimes Act Weird and Spout Nonsense,” Cade Metz
• “What Has Feelings?,” Kristin Andrews and Jonathan Birch
• “Achieving Transformative Sustainability Learning: Engaging Head, Hands And Heart,” Yona Sipos, Bryce Battisti, Kurt Grimm
• “The Ethics Of Persuasion,” Lyndon Cerejo
• “The Future Of Design: Human-Powered Or AI-Driven?,” Keima Kai
• “How AI Technology Will Transform Design,” Nick Babich & Gleb Kuznetsov

Books

• Designerly Ways Of Knowing, Nigel Cross
• Curious: The Desire To Know and Why Your Future Depends On It, Ian Leslie
• Empathy: Why It Matters, And How to Get It, Roman Krznaric

(cc, yk, il)

AI-generated art is everywhere on the web. If you are an active Instagram, Twitter, or Pinterest user, you likely saw interesting artworks created using text-based tools like DALLE, Midjourney, or Stable Diffusion. The magic of these tools is that to generate images, all you need to do is to provide a string of text that describes what the image is all about. Many AI-generated works look stunning, but it’s only the beginning. In the foreseeable future, AI tools will be so intuitive that everyone can express their ideas. The rise of tools that have AI at their core makes design practitioners wonder if AI will replace designers.

In this article, we will overview the current state of design, answer common questions designers have about AI tools and share practical tips on how designers can make the most of using AI tools.

Design Tools Learning Curve And Creativity

Mastering any skill takes time, and design is no exception. Designers have a lot of great tools in their arsenal, but the process of honing design talent takes years. You need to invest years of your life to get to the point when you can create decent artwork.

No matter how creative you are, you must spend time creating something using your hand. Most of the time, it’s impossible to go from idea to solution in a few minutes. As a result, sometimes it feels like design is 95% craft and only 5% art.

Much energy goes into the visualization of ideas, and it can be very frustrating to learn that your idea doesn’t resonate with the audience. Once you publish your work, you might learn that it’s not something your audience wants. An unsuccessful design pitch leads to a situation when your work goes straight to the garbage bin.

But in the near future, you will be able to use shortcuts and go from your idea to the final work in a minute rather than hours or days. You will be able to avoid the tedious process of physically making art and instead become a visioner who tells the computer what you want to build and lets the computer do the work for you. And you can experience the power of AI tools even today. Use Dalle.2 by OpenAI, Midjourney, or Stable Diffusion.

Let’s answer a few popular questions that designers have regarding AI.

Can I Take Credit For Artworks Created By AI?

The answer is yes, you can, but you shouldn’t. Many AI artwork generation tools available on the market don’t give designers much freedom to control the process of artwork creation. As a designer, you explain your intention to the AI system through plain words and let the tool do its magic. You have limited or no information on how the tool works.

Because modern AI tools don’t give you much freedom to impact the design direction, the final result misses the human touch. Right now, you cannot convey a lot of personality in works generated by AI tools. At the same time, it doesn’t mean this will be true in the future. We will likely see the tools that give designers more control over the process of creating visual assets.

Will AI Take My Job?

Many professional artists panic because they see how good artificial intelligence has become at creating artwork. AI-generated art fills the market and takes potential clients. Instead of hiring a human digital artist, many companies ‘hire’ AI to do the job because it can do design work for a fraction of the cost. This trend not only takes jobs but also lowers the market value of the art — the artworks become less valuable because people see how easy it is to generate artwork using AI.

What happens right now is a predictable situation. It’s just how business works. If a business can save money by following a more effective approach, it will do it. During the industrial revolution of the 19th century, some English textile workers intentionally destroyed textile machines because they were afraid that machines would replace them. Of course, machines replaced some of the roles (typically, roles where heavy lifting or monotonous work was required), but they didn’t replace humans. The same is true for AI tools. AI won’t completely replace human ingenuity; it will complement human potential.

The true power of AI is not about replacing humans but instead giving them a massive boost in productivity.

“

If you think about the primary reason why people invented new tools in the first place, it becomes evident that work efficiency was the number one reason — the same works for AI. AI will help us work more efficiently.

The quality of your ideas and your ability to understand user problems and create solutions that help people is critically important at any age of product design, including the age of AI design.

Will AI Tools Lead Us To Generic Design?

When designers use the same tools and data inputs, they could easily end up making a homogenized design that looks generic.

But the problem of homogenized design is not new. Dribbblisation of design was a massive topic in the design field for a few years. Many people in the industry worry about the situation when a vast majority of the product design work on Dribbble looks the same (the same styles are applied).

Will the problem become worse when AI tools are popularized? The answer is no. If you look closer at the artists who publish their work at Dribbble, you will notice that there aren’t many artists who set trends. Once a new trend emerges and it resonates with the audience, many designers start to follow it and designs that look trendy.

“Out in the sun, some painters are lined up. The first is copying nature; the second is copying the first; the third is copying the second.”
— Paul Gauguin

AI tools won’t replace all designers anytime soon because imagination and creativity will still be the powerful properties of the artist’s mind. Until AI technology becomes sophisticated enough to do creative thinking, we don’t have to worry about creating AI trends. The point is, soon, it will be possible to curate the data you will provide as an input to the system, and the AI system will learn from you, so the results will include a lot of your personality.

Can We Face Legal Troubles Using AI Tools?

Early in 2023, a group of artists filed a class-action lawsuit against Midjourney and Stability AI, claiming copyright infringement. Both Midjourney and Stability AI were trained using billions of internet images, and this suit alleges that the companies behind those tools “violated the rights of millions of artists” who created the original images. Whether or not AI art tools violate copyright law can be challenging to determine because the database used for training is massing (billions of images). But one thing is for sure — the AI tools create new images based on the knowledge they learned due to the training.

Can designers face legal troubles using AI tools in the future? So far, there is no single correct answer to this question, but the world is quickly embracing AI art (i.e., stock photo banks will start selling AI-generated stock imagery), and we will likely have more clear rules on how to use AI-generated images in the future.

The New Chapter In Design: Co-creation With AI

When Steve Jobs explained the power of computers, he said,

“What a computer is to me is it's the most remarkable tool that we've ever come up with, and it's the equivalent of a bicycle for our minds.”
— Steve Jobs

It’s possible to rephrase this quote in the context of AI, saying that AI is a bicycle for our creativity — our ability to create something new. Creativity is based on life experiences and ideas that creators have. AI cannot replace humans because it uses the work that humans create as an input to produce new designs. But AI can boost creativity greatly because it becomes a sort of ‘second brain’ that works with a creator and provides new inputs.

Of course, modern AI tools don’t give us much freedom to tweak the AI engine, but they still give us a lot of power. They can provide us with ideas we didn’t think of. It makes AI an excellent tool for discovery and exploration.

Here are just a few directions of how humans and machines can work together in the future:

Conduct Visual Exploration

AI tools capture the collective experience of millions of images from photo banks and give creators a unique opportunity to quickly explore the desired direction without spending too much energy. AI becomes your creative assistant during the process of visual exploration. You prompt the system with various directions you want to pursue and let the system generate various outcomes for you. You evaluate each direction and choose the best to pursue. The process of co-creation can be iterative. For example, once you see a particular design direction, you can tell the system to dive into it to explore it.

There are two ways you can approach visual exploration, either by following text-to-image or image-to-image scenarios.

In an image-to-text scenario, you provide a prompt and tweak some settings to produce an image. Let’s discuss the most important properties of this scenario:

• Prompt
  A prompt is a text string that we submit to the system so that it can create an image for you. Generally, the more specific details you provide, the better results the system will generate for you. You can use resources like Lexica to find a relevant prompt.
• Steps
  Think of steps as iterations of the image creation process. During the first steps, the image looks very noisy, and many elements in the image are blurry. The system refines it with every iteration by altering the visual details of the image. If you use Stable Diffusion, set steps to 60 or more.

• Seed
  You can use the Seed number to create a close copy of a specific picture. For example, if you want to generate a copy of the image you saw on Lexica, you need to specify the prompt and seed number of this image.

In the image-to-image (img2img) scenario, AI will use your image as a source and produce variations of the image based on it. For example, here is how we can use a famous painting, Under the Wave off Kanagawa, as a source for Stable Diffusion.

We can play with Image Strength by setting it close to 0 so that AI can have more freedom in the way it can interpret the image. As you can see below, the image that the system generated for us has only a few visual attributes of the original image.

Or set Image Strength up to 95% so that AI can only create a slightly different version of the original image.

Our experiment clearly proves that AI tools have an opportunity to replace mood boards. You no longer need to create mood boards (at least do it manually using tools like Pinterest) but rather tell the system to find ideas you want to explore.

Create A Complete Design For Your Product

AI can be an excellent tool to implement ideas quickly. Today we have a long and painful product design process. Going from idea to implementation takes weeks. But with AI, it can take minutes. You can create a storyboard with your product, specify the context of use for your future product, and let AI design a product.

Providing these details is important because AI should understand the nature of the problem you’re trying to solve with this design. For example, below are the visuals that you can create right now using a tool called Midjourney. All you need to do is to specify the text prompt “mobile app UI design, hotel booking, Dribbble, Behance –v 4 –q 2”.

I think that part “mobile app UI design, hotel booking, Dribbble, Behance” is self-explanatory. But you might wonder what –v and –q means.

• –v means a version of the Midjourney.
  On November 10, 2022, the alpha iteration of version 4 was released to users.
• –q means quality.
  This setting specifies how much rendering quality time you want to spend. The default number is 1. Creating the image in higher values takes more time and costs more.

It’s important to mention a couple of common issues that images generated by Midjourney have:

• Gibberish texts
  You likely noticed that the text on mobile app screens in the above example is not English.
• Extra fingers
  If you generate an image of a person, you will likely see extra fingers on their hands and legs.

In the foreseeable future, a design created by AI will automatically inherit all industry best practices, freeing designers from time-consuming activities like UI design audits. AI tools will significantly speed up the user research and design exploration phase because the tools analyze massive amounts of data and can easily provide relevant details for a particular product (i.e., create a user persona, draft a user journey, and so on). As a result, it will be possible to develop new products right during brainstorming sessions, so designers are no longer limited to low-fidelity wireframes or paper sketches. The product team members will be able to see how the product will look and work right during the session.

Create Virtual Worlds And Virtual People In It

No doubt that the metaverse will be the next big thing. It will be the most sophisticated digital platform humans have ever created, and content production will be an integral part of the platform design. Designers will have to find ways to speed up the creation of virtual environments and activities in them. At first, designers will likely try to recreate real-world places in the virtual world, but after that, they will rely on AI to do the rest. The role of designers in the metaverse will be more like a director (a person who will tailor the results) rather than a craftsman who does it with their hand. Imagine that you can create large virtual areas such as cities and get a sense of the scale of the city by experiencing it.

It’s Time To Open A New Chapter In Design

AI-powered design solutions have an opportunity to become much more than just tools designers use to create assets. They have the chance to become a natural extension of the team. I believe that the true power of AI tools will shine when tools will learn from a creator and will be able to reflect the creator’s personality in the final design. Next-gen AI will learn both about you and from you and create works that functionality and aesthetics meet your needs and taste. As a result, the output the tools will produce will have a more authentic human fingerprint.

The future of design is bright because technology will allow more people to express their creativity and make our world more interesting and richer.

Further Reading On SmashingMag

• “The Future Of Design: Human-Powered Or AI-Driven?”, Keima Kai
• “How AI Is Helping Solve Climate Change”, Nicholas Farmen
• “Building A Simple AI Chatbot With Web Speech API And Node.js”, Tomomi Imura
• “Algorithm-Driven Design: How Artificial Intelligence Is Changing Design”, Yury Vetrov

(yk, il)

Markdown is second nature for many of us. Looking back, I remember starting typing in Markdown not long after John Gruber released his first Perl-based parser back in 2004 after collaborating on the language with Aaron Swartz.

"Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web."

— John Gruber

That’s almost 20 years ago — yikes! What started as a more writer- and reader-friendly syntax for HTML has become a darling for how to write and store technical prose for programmers and tech-savvy people.

Markdown is a signifier for the developer and text-tinkerer culture. But since its introduction, the world of digital content has also changed. While Markdown is still fine for some things, I don’t believe it’s should be the go-to for content anymore.

There are two main reasons for this:

1. Markdown wasn’t designed to meet today’s needs of content.
2. Markdown holds editorial experience back.

Of course, this stance is influenced by working for a platform for structured content. At Sanity.io, we spend most of our days thinking about how content as data unlocks a lot of value, and we spend a lot of time thinking deeply about editor experiences, and how to save people time, and make working with digital content delightful. So, there’s skin in the game, but I hope I’m able to portray that even though I’ll argue against Markdown as the go-to format for content, I still have a deep appreciation for its significance, application, and legacy.

Before my current gig, I worked as a technology consultant at an agency where we had to literally fight CMSes that locked our client’s content down by embedding it in presentation and complex data models (yes, even the open-source ones). I have observed people struggle with Markdown syntax, and be demotivated in their jobs as editors and content creators. We have spent hours (and client’s money) on building custom tag-renderers that were never used because people don’t have time or motivation to use the syntax. Even I, when highly motivated, have given up contributing to open-source documentation because the component-based Markdown implementation introduced too much friction.

But I also see the other side of the coin. Markdown comes with an impressive ecosystem and from a developer’s standpoint, there is an elegant simplicity to plain-text files and easy-to-parse syntax for people who are used to reading code. I once spent days building an impressive MultiMarkdown->LaTeX->real-time-PDF-preview-pipeline in Sublime Text for my academic writing. And it makes sense that a README.md file can be opened and edited in a code editor and rendered nicely on GitHub. There’s little doubt that Markdown brings convenience for developers in some use cases.

That is also why I want to build my advice against Markdown by looking back on why it was introduced in the first place, and by going through some of the major developments of content on the web. For many of us, I suspect Markdown is something we just take for granted as a “thing that exists.” But all technology has a history and is a product of human interaction. This is important to remember when you, the reader, develop technology for others to use.

Flavors And Specifications

Markdown was designed to make it easier for web writers to work with articles in an age where web publishing required writing HTML. So, the intent was to make it simpler to interface with text formatting in HTML. It wasn’t the first simplified syntax on the planet, but it was the one that gained the most traction over the years. Today, the usage of Markdown has grown far beyond its design intent to be a simpler way to read and write HTML, to become an approach of marking up plain text in a lot of different contexts. Sure, technologies and ideas can evolve beyond their intent, but the tension in today’s use of Markdown can be traced to this origin and the constraints put into its design.

For those who aren’t familiar with the syntax, take the following HTML content:

<p>The <a href=”https://daringfireball.net/projects/markdown/syntax#philosophy”>Markdown syntax</a> is designed to be <em>easy-to-read</em> and <em>easy-to.write</em>.</p>

With Markdown, you can express the same formatting as:

The [Markdown syntax](https://daringfireball.net/projects/markdown/syntax#philosophy) is designed to be _easy-to-read_ and _easy-to-write_.

It’s like a law of nature that technology adoption comes with the pressure to evolve and add features to it. Markdown’s increasing popularity meant that people wanted to adapt it for their use cases. They wanted more features like support for footnotes and tables. The original implementation came with an opinionated stance, which at the time were reasonable for what the design intent was:

"For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags."

— John Gruber

In other words, if you want a table, then use <table></table>. You’ll find that this is still the case for the original implementation. One of Markdown’s spiritual successors, MDX, has taken the same principle but extended it to JSX, a JS-based templating language.

From Markdown To Markdown?

It can look like Markdown’s appeal for many wasn’t so much its tie-in to HTML, but the ergonomics of plaintext and simple syntax for formatting. Some content creators wanted to use Markdown for other use cases than simple articles on the web. Implementations like MultiMarkdown introduced affordances for academic writers who wanted to use plain text files but needed more features. Soon you would have a range of writing apps that accepted Markdown syntax, without necessarily turning it into HTML or even using the markdown syntax as a storage format.

In a lot of apps, you’ll find editors that give you a limited set of formatting options, and some of them are more “inspired” by the original syntax. In fact, one of the feedbacks I got on a draft of this article was that by now, “Markdown” should be lower-cased, since it has become so common, and to make it distinct from the original implementation. Because what we recognize as markdown has also become very diverse.

CommonMark: An Attempt To Tame Markdown

Like ice cream, Markdown comes in a lot of flavors, some more popular than others. When people started to fork the original implementation and add features to it, two things happened:

1. It became more unpredictable what you as a writer could and couldn’t do with Markdown.
2. Software developers had to make decisions of what implementation to adopt for their software. The original implementation also contained some inconsistencies that added friction for people who wanted to use it programmatically.

This started conversations about formalizing Markdown into a specification proper. Something that Gruber resisted, and still does, interestingly, because he recognized that people wanted to use Markdown for different purposes and “No one syntax would make all happy.” It’s an interesting stance considering that Markdown translates to HTML, which is a specification that evolves to accommodate different needs.

Even though the original implementation of Markdown is covered by a “BSD-like” license, it also reads “Neither the name Markdown nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.” We can safely assume that most products that use “Markdown” as part of their marketing materials haven’t acquired this written permission.

The most successful attempt to bring Markdown into a shared specification is what is today known as CommonMark. It was headed by Jeff Atwood (known for co-founding Stack Overflow and Discourse) and John McFarlane (a professor of philosophy at Berkely who’s behind Babelmark and pandoc). They initially launched it as “Standard Markdown,” but changed it to “CommonMark” after receiving criticism from Gruber. Whose stance was consistent, the intent of Markdown is to be a simple authoring syntax that translates to HTML:

@davewiner And that’s what’s flawed with CommonMark. They want to make things easier for programmers as a primary goal. They miss the point.

— John Gruber (@gruber) September 8, 2014

I think this also marked the point where Markdown had entered the public domain. Even though CommonMark isn’t branded as “Markdown,” (as per licensing) this specification is recognized and referred to as “markdown”. Today, you’ll find CommonMark as the underlying implementation for software like Discourse, GitHub, GitLab, Reddit, Qt, Stack Overflow, and Swift. Projects like unified.js bridges syntaxes by translating them into Abstract Syntax Trees, also rely on CommonMark for their markdown support.

CommonMark has brought a lot of unification around how markdown is implemented, and in a lot of ways has made it simpler for programmers to integrate markdown support in software. But it hasn’t brought the same unification to how markdown is written and used. Take GitHub Flavored Markdown (GFM). It’s based on CommonMark but extends it with more features (like tables, task lists, and strikethrough). Reddit describes its “Reddit Flavored Markdown” as “a variation of GFM,” and introduces features like syntax for marking up spoilers. I think we can safely conclude that both the group behind CommonMark and Gruber were right: it certainly helps with shared specifications, but yes, people want to use Markdown for different specific things.

Markdown As A Formatting Shortcut

Gruber resisted formalizing Markdown into a shared specification because he assumed it would make it less a tool for writers and more a tool for programmers. We have already seen that even with the broad adoption of a specification, we don’t automatically get a syntax that predictably works the same across different contexts. And specifications like CommonMark, popular as it is, also have limited success. An obvious example is Slack’s markdown implementation (called mrkdown) that translates *this* to strong/bold, and not emphasis/italic, and doesn’t support the [link](https://slack.com) syntax, but uses <link|https://slack.com> instead.

You’ll also find that you can use Markdown-like syntax to initialize formatting in rich text editors in software like Notion, Dropbox Paper, Craft, and to a degree, Google Docs (e.g. asterisk + space on a new line will transform to a bulleted list). What’s supported and what’s translated to what varies. So, you can’t necessarily take your muscle memory with you across these applications. For some people, this is fine, and they can adapt. For others, this is a papercut and it keeps them from using these features. Which asks the question, who was Markdown designed for, and who are its users today?

Who Are The Users Of Markdown Supposed To Be?

We have seen markdown exist in a tension between different use cases, audiences, and notions of whom its users are. What started as a markup language for HTML-proficient web writers specifically, became a darling for developer types.

In 2014, web writers started to move away from moving files through parsers in Perl and FTP. Content Management Systems (CMSs) like WordPress, Drupal, and Moveable Type (which I believe Gruber still uses) had steadily grown to become the go-to tools for web publishing. They offered affordances like rich text editors that web writers could use in their browsers.

These rich text editors still assumed HTML and Markdown as the underlying rich text syntax, but they took away some of the cognitive overhead by adding buttons to insert this syntax in the editor. And increasingly, writers weren’t and didn’t have to be versed in HTML. I bet if you did web development with CMSs in the 2010s, you probably had to deal with “junk HTML” that came through these editors when people pasted directly from Word.

Today, I will argue that Markdown’s primary users are developers and people who are interested in code. It’s not a coincidence that Slack made the WYSIWYG the default input mode once their software was used by more people outside of technical departments. And the fact that this was a controversial decision, so much that they had to bring it back as an option, shows how deep the love for markdown is in the developer community. There wasn’t much celebration of Slack trying to make it easier and more accessible for everyone. And this is the crux of the matter.

The Ideology Of Markdown

The fact that markdown has become the lingua franca writing style, and what most website frameworks cater to, is also the main reason I’ve been a bit skittish about publishing this. It’s often talked about as an inherent and undeniable good. Markdown has become a hallmark of being developer-friendly. Smart and skilled people have sunk a lot of collective hours in enabling markdown in all sorts of contexts. So, challenging its hegemony will surely annoy some. But hopefully, it can spawn some fruitful discussion about a thing that’s often taken for granted.

My impression is that the developer friendliness that people relate to Markdown has mostly to do with 3 factors:

1. The comfortable abstraction of a plain text file.
2. There is an ecosystem of tooling.
3. You can keep your content close to your development workflow.

I’m not saying that these stances are wrong, but I’ll suggest that they come with trade-offs and some unreasonable assumptions.

The Simple Mental Model Of A Plain Text File

Databases are amazing things. But they have also had an earned reputation of being hard and inaccessible for frontend developers. I’ve known a lot of great developers who shy away from backend code and databases, because they represent complexity they don’t want to spend time on. Even with WordPress, which does a lot out of the box to keep you from having to deal with its database after setup, it was overhead of getting up and running.

Plain text files, however, are more tangible and are fairly simple to reason about (as long as you’re used to file management that is). Especially compared to a system that will break your content into multiple tables in a relational database with some proprietary structure. For limited use cases, like blog posts of simple rich text with images and links, markdown will get the job done. You can copy the file and stick it in a folder or check it into git. The content feels yours because of the tangibility of files. Even if they’re hosted on GitHub, which is a for-profit Software as a Service owned by Microsoft, and thus covered by their terms of service.

In the era where you actually had to spin up a local database to get your local development going and deal with syncing it with remote, the appeal of plain text files is understandable. But that era is pretty much gone with the emergence of backends as a service. Services and tools like Fauna, Firestore, Hasura, Prisma, PlanetScale, and Sanity’s Content Lake, invest heavily in developer experience. Even operating traditional databases on local development has become less of a hassle compared to just 10 years ago.

If you think about it, do you own your content less if it’s hosted in a database? And hasn’t the developer experience of dealing with databases become significantly simpler with the advent of SaaS tools? And is it fair to say that proprietary database technology impinges on the portability of your content? Today you can launch what’s essentially a Postgres database with no sysadmin skills, make your tables and columns, put your content inside of it, and at any time export it as a .sql dump.

The portability of content has much more to do with how you structure that content in the first place. Take WordPress, it’s fully open-source, you can host your own DB. It even has a standardized export format in XML. But anyone who has tried to move out of a mature WordPress install knows how little this helps if you’re trying to get away from WordPress.

A Vast Ecosystem… For Developers

We already touched on the vast markdown ecosystem. If you look at contemporary website frameworks, most of them assume markdown as a primary content format, some of them, the only format. For example, Hugo, the static site generator used by Smashing Magazine, still requires markdown files for paginated publishing. Meaning that if Smashing Magazine wants to use a CMS to store articles, it has to interact with markdown files, or convert all the content to markdown files. If you look in the documentation for Next.js, Nuxt.js, VuePress, Gatsby.js, and so on, markdown will figure prominently. It’s also the default syntax for README-files on GitHub, which also uses it for formatting in Pull Request notes and comments.

There are some honorable mentions of initiatives to bring the ergonomics of markdown to the masses. Netlify CMS and TinaCMS (the spiritual descendant of Forestry) will give you user interfaces where the markdown syntax is mostly abstracted away for editors. You will commonly find that markdown-based editors in CMSes give you preview functionality for the formatting. Some editors, like Notion’s, will let you paste markdown syntax, and they will translate it to their native formatting. But I think it’s safe to say, that the energy that has gone to innovate for markdown hasn’t favored people who aren’t into writing its syntax. It hasn’t trickled up the stack, as it were.

Content Workflows Or Developer Workflows?

For a developer who makes their blog, using markdown files reduces some of the overhead of getting it up and running, since frameworks often come with built-in parsing or commonly offer it as part of starter code. And there is nothing extra to sign up for. You can use git to commit these files alongside your code. If you are comfortable with git diffs, you’ll even have revision control like you’re used to with programming. In other words, since markdown files are in plain text, they can be integrated with your developer workflow.

But beyond this, the developer experience soon gets more complex. And you end up compromising on your team’s user experience as content creators, and our own developer experience being stuck with markdown to solve problems that are way beyond its design intent.

Yes, it might be cool if you get your content team to use git and check in their changes, but at the same time, is this the best use of their time? Do you really want your editors to bump against merge conflicts or how to rebase branches? Git is hard enough for developers who use it every day. And does this setup really represent the best workflow for people who are primarily working with content? Isn’t this a case where developer experience has trumped editor experience, and isn’t the cost, the time and effort that could go into making something better for users?

Because the expectations and needs from content and editing environments have evolved, I don’t think markdown will do it for us. I don’t see how some of the developer ergonomics end up favoring non-developers, and I think even for developers, markdown is holding our own content creation and needs back. Because content on the web has significantly changed since the early 2000s.

From Paragraphs To Blocks

Markdown has always had the option of opting out to HTML if you wanted more complex things. This worked well when the author was also the webmaster, or at least knew HTML. It also worked well because websites usually were mostly HTML and CSS. The way you designed websites was mostly by creating whole page layouts. You could transform Markdown to the HTML markup and put it up alongside your style.css file. Of course, we had CMSes and static site generators in the 2000s too, but they mostly worked the same, by inserting the HTML content inside of templates without any passing of “props” between the components.

But most of us don’t really author HTML like in the old days anymore. Content on the web has evolved from mostly being articles with simple rich text formatting to composed multimedia and specialized components often with user interactivity (which is a fancy way of saying “newsletter signup call to actions”).

From Articles To Apps

In the early 2010s, Web 2.0 was in its heyday, and Software as a Service-companies began to use the web for data-heavy applications. HTML, CSS, and JavaScript were increasingly used to drive interactive UIs. Twitter open-sourced Bootstrap, their framework for building more consistent and resilient user interfaces. This drove what we can call the “componentization” of web design. It shifted the way we build for the web in a fundamental way.

The various CSS frameworks that emerged in this era (e.g. Bootstrap and Foundation) tended to use standardized class names and assumed specific HTML structures to make it less hard to make resilient and responsive user interfaces. With the web design philosophy of Atomic Design and class-name conventions like Block-Element-Modifier (BEM) the default was shifted from thinking page-layout first, to seeing pages as a collection of repeatable and compatible design elements.

Whatever content you have inside of markdown is not compatible with this. Unless you down the rabbit hole of interjecting the markdown parsers, and tweaked it to output the syntax you wanted (more on this later). No wonder, Markdown was designed to be simple rich text articles of native HTML elements that you would target with a stylesheet.

This is still an issue for people who use Markdown to drive content for their sites.

The Embeddable Web

But something also happened to our content as well. Not only could we start finding it outside of the semantic <article> HTML-tags, but it started to contain more… stuff. A lot of our content moved out from our LiveJournals and blogs and into social media: Facebook, Twitter, tumblr, YouTube. To get the snippets of content back into our articles, we needed to be able to embed them. The HTML convention started using the <iframe> tag to channel the video player from YouTube or even insert a tweet-box in between your paragraphs of text. Some systems started abstracting this into “short-codes”, most often brackets containing some keyword to identify what block of content it should represent, and some key-value attributes. For example, dev.to have enabled syntax from the templating language liquid to be inserted into their Markdown editor:

{% youtube dQw4w9WgXcQ %}

Of course, this requires you to use a customized Markdown parser, and have special logic to make sure the right HTML was inserted when the syntax was turned into HTML. And your content creators will have to remember these codes (unless there was some kind of toolbar to automatically insert them). And if a bracket gets deleted or messed up, that might break the site.

But What About MDX?

An attempt to solve the need for block content is MDX, presented with the tagline “Markdown for the component era.” MDX lets you use the JSX templating language, as well as JavaScript, interlaced in markdown syntax. There is a lot of impressive engineering in the community around MDX, including Unified.js, which specializes in parsing various syntaxes into Abstract Syntax Trees (ASTs), so that they are more accessible to be used programmatically. Note, that the standardization of markdown would make the work for the folks behind Unified.js and its users simpler, because there are fewer edge cases to cater for.

MDX certainly brings better developer experience in integrating components into Markdown. But it doesn’t bring better editor experience, because it adds a lot of cognitive overhead to content production and editing:

import {Chart} from './snowfall.js'
export const year = 2018

# Last Year’s Snowfall

In {year}, the snowfall was above average.
It was followed by a warm spring which caused
flood conditions in many of the nearby rivers.

<Chart year={year} color="#fcb32c" />

The amount of assumed knowledge just for this simple example is substantial. You need to know about ES6 modules, JavaScript variables, JSX templating syntax, and how to use props, hex codes, and data types, and you need to be familiar with what components you can use, and how to use them. And you need to type it correctly and in an environment that gives you some kind of feedback. I have no doubt that there will be more accessible authoring tools on top of MDX, it feels like solving for something that doesn’t need to be a problem in the first place.

Unless you are extremely diligent in how you compose and name your MDX components, it also ties your content to a specific presentation. Just take the example above brought from the MDX front page. You’ll find a hard-coded color hex for the chart. When you redesign your site, that color might not be compatible with your new design system. Of course, there’s nothing keeping you from abstracting this and using the prop color=”primary”, but there’s also nothing in the tool that nudges you to make wise decisions like this.

Embedding specific presentation concerns in your content has increasingly become a liability and something that will get in the way of adapting, iterating, and moving quickly with your content. It locks it down in ways that are much more subtle than having content in a database. You risk ending up in the same place as moving out of a mature WordPress install with plugins. It is cumbersome to unmix structure and presentation.

The Demand For Structured Content

With more complex sites and user journeys, we also see the need to present the same pieces of content throughout a website. If you’re running an e-commerce site, you want to embed product information in many places outside a single product page. If you run a modern marketing site, you want to be able to share the same copy across multiple personalized views.

To do this efficiently and reliable you will need to adapt structured content. That means your content needs to be embedded with metadata and chunked up in ways that make it possible to parse for intent. If a developer just sees “page” with “content,” that makes it very difficult to include the right things in the right places. If they can get to all “product descriptions” with an API or a query, that makes everything easier.

With markdown, you’re limited to expressing taxonomies and structured content either to some sort of folder organization (making it hard to put the same piece of content in multiple taxonomies) or you need to augment the syntax with something else.

Jekyll, an early Static Site Generator (SSG) built for markdown files, introduced “Front Matter” as a way to add metadata to posts using YAML (a simple key-value format that uses spaces to create scope) between three dashes at the top of the file. So, now you’ll have two syntaxes to deal with. YAML also has a reputation for being mischievous (especially if you’re from Norway). Nevertheless, other SSGs have adopted this convention, as well as git-based CMSes that use markdown as their content format.

When you have to add additional syntax to your plain files to get some of the affordances of structured content, you may start to wonder if it’s really worth it. And who the format is for and who it excludes.

If you think about it, a lot of what we do on the web is not only consuming content, we’re creating it! I’m currently writing this lengthy article in an advanced word processor in my browser.

There’s a growing expectation that you should also be able to author block content in modern content applications. People have started to get used to delightful user experiences that works and looks nice, and where you aren’t expected to have to learn specialized syntax. Medium popularized the notion that you could have delightful and intuitive content creation on the web. And speaking of “notion”, the popular note app has gone all in on block content, and lets users mix max from a wide range of different types. Most of these blocks goes beyond markdown, and the native elements of HTML.

It’s notable that Notion, describing their process to make their content accessible through their highly anticipated API, makes a point out of chosing their content format, that:

“Documents from one Markdown editor will often parse and render differently in another application. The inconsistency tends to be manageable for simple documents, but it’s a big problem for Notion’s rich library of blocks and inline formatting options, many of which are simply not supported in any widely-used Markdown implementation.”

Notion went with a JSON based format that let them express as structured data. Their argument is that it makes it easier and more predictable to interact with for developers who want to build their own presentation of the block content that comes out of Notion’s APIs.

If Not Markdown, Then What?

I suspect that the prominence of Markdown has held back innovation and progress for digital content. So, when I argue that we should stop choosing it as a primary way to store content, it’s hard to give a straight answer to what should replace it. What we do know, however, is what we should expect from modern content formats and authoring tools.

Let’s Invest In Accessible Authoring Experiences

Using markdown requires you to learn syntax, and often multiple syntaxes and bespoke tags to be practical with modern expectations. Today, that feels like a completely unnecessary expectation to put on most people. I wish we could direct more energy into making accessible and delightful editorial experiences that produces modern portable content formats.

Even though it’s notoriously difficult to build great block content editors, there are a couple of viable options out there that can be extended and customized for your use case (for example Slate.js, Quill.js, or Prosemirror). Then again, investing in the communities around these tools might also help their development further.

Increasingly, people will expect authoring tools to be accessible, real-time, and collaborative. Why should one have to push a save button on the web in 2021? Why shouldn’t it be possible to make a change in a document without risking a race condition, because your colleague happened to have the document open in a tab? Should we expect authors to have to deal with merge conflicts? And shouldn’t we make it easy for content creators to work with structured content with visual affordances that make sense?

To be a bit polemical: the last decade’s innovations in reactive JavaScript frameworks and UI components are perfect for creating awesome authoring tools. Instead of using them to transpile Markdown to HTML and into an abstract syntax tree to then integrate it in a JavaScript template language that outputs HTML.

Block Content Should Follow A Specification

I haven’t mentioned WYSIWYG editors for HTML. Because they are the wrong thing. Modern block content editors should preferably interoperate with a specified format. The aforementioned editors do at least have a sensible internal document model that can be transformed into something more portable. If you look at the content management system landscape, you start to see various JSON-based block content formats emerge. Some of them are still tied to HTML assumptions or overly concerned with character positions. And none of them aren’t really offered as a generic specification.

At Sanity.io, we decided early that the block content format should never assume HTML as neither input nor output, and that we could use algorithms to synchronize text strings. More importantly, was it that block content and rich text should be deeply typed and queryable. The result was the open specification Portable Text. Its structure not only makes it flexible enough to accommodate custom data structures as blocks and inline spans; it’s also fully queryable with open-source query languages like GROQ.

Portable Text isn’t design to be written or be easily readable in its raw form; it’s designed to be produced by an user interface, manipulated by code, and to be serialized and rendered where ever it needs to go. For example, you can use it to express content for voice assistants.

{
  "style": "normal",
  "_type": "block",
  "children": [
    {
      "_type": "span",
      "marks": ["a-key", "emphasis"],
      "text": "some text"
    }
  ],
  "markDefs": [
    {
      "_key": "a-key",
      "_type": "markType",
      "extraData": "some data"
    }
  ]
}

An interesting side-effect of turning block content into structured data is exactly that: It becomes data! And data can be queried and processed. That can be highly useful and practical, and it lets you ask your content repository questions that would be otherwise harder and more errorprone in formats like Markdown.

For example, if I for some reason wanted to know what programming languages we’ve covered in examples on Sanity’s blog, that’s within reach with a short query. You can imagine how trivial it is to build specialized tools and views on top of this that can be helpful for content editors:

distinct(
  *["code" in body[]._type]
      .body[_type == "code"]
      .language
)
// output
[
  "text",
  "javascript",
  "json",
  "html",
  "markdown",
  "sh",
  "groq",
  "jsx",
  "bash",
  "css",
  "typescript",
  "tsx",
  "scss"
]

Example: Get a distinct list of all programming languages that you have code blocks of.

Portable Text is also serializable, meaning that you can recursively loop through it, and make an API that exposes its nodes in callback functions mapped to block types, marked-up spans, and so on. We have spent the last years learning a lot about how it works and how it can be improved, and plan to take it to 1.0 in the near future. The next step is to offer an editor experience outside of Sanity Studio. As we have learned from Markdown, the design intent is important.

Of course, whatever the alternative to markdown is, it doesn’t need to be Portable Text, but it needs to be portable text. And it needs to share a lot of its characteristics. There have been a couple of other JSON-based block content format popping up the last few years, but a lot of them seem to bring with them a lot of “HTMLism.” The convenience is understandable, since a lot of content still ends up on the web serialized into HTML, but the convenience limits the portability and the potential for reuse.

You can disregard my short pitch for something we made at Sanity, as long as you embrace the idea of structured content and formats that let you move between systems in a fundamental manner. For example, a goal for Portable Text will be improved compatibility with Unified.js, so it’s easier to travel between formats.

Embracing The Legacy Of Markdown

Markdown in all its flavors, interpretations, and forks won’t go away. I suspect that plain text files will always have a place in developers’ note apps, blogs, docs, and digital gardens. As a writer who has used markdown for almost two decades, I’ve become accustomed to “markdown shortcuts” that are available in many rich text editors and am frequently stumped from Google Docs’ lack of markdownisms. But I’m not sure if the next generation of content creators and even developers will be as bought in on markdown, and nor should they have to be.

I also think that markdown captured a culture of savvy tinkerers who love text, markup, and automation. I’d love to see that creative energy expand and move into collectively figuring out how we can make better and more accessible block content editors, and building out an ecosystem around specifications that can express block content that’s agnostic to HTML. Structured data formats for block content might not have the same plain text ergonomics, but they are highly “tinkerable” and open for a lot of creativity of expression and authoring.

If you are a developer, product owner, or a decision-maker, I really want you to be circumspect of how you want to store and format your content going forward. If you’re going for markdown, at least consider the following trade-offs:

Markdown is not great for the developer experience in modern stacks:

• It can be a hassle to parse and validate, even with great tooling.
• Even if you adopt CommonMark, you aren’t guaranteed compatibility with tooling or people’s expectations.
• It’s not great for structured content, YAML frontmatter only takes you so far.

Markdown is not great for editorial experience:

• Most content creators don’t want to learn syntax, their time is better spent on other things.
• Most markdown systems are brittle, especially when people get syntax wrong (which they will).
• It’s hard to accommodate great collaborative user experiences for block content on top of markdown.

Markdown is not great in block content age, and shouldn’t be forced into it. Block content needs to:

• Be untangled from HTMLisms and presentation agnostic.
• Accommodate structured content, so it can be easily used wherever it needs to be used.
• Have stable specification(s), so it’s possible to build on.
• Support real-time collaborative systems.

What’s common for people like me who challenge the prevalence of markdown, and those who are really into the simple way of expressing text formating is an appreciation of how we transcribe intent into code. That’s where I think we can all meet. But I do think it’s time to look at the landscape and the emerging content formats that try to encompass modern needs, and ask how we can make sure that we build something that truly caters to editorial experience, and that can speak to developer experience as well.

I want to express my gratitude to Titus Wormer (@wooorm) for his insightful feedback on my first draft of this post, and for the great work he and the Unified.js team have done for the web community.

Further Reading

• Transitioning Top-Layer Entries And The Display Property In CSS
• Integrations: From Simple Data Transfer To Modern Composable Architectures
• The Digital Playbook: A Crucial Counterpart To Your Design System
• An Ode To Side Project Time

(vf, yk, il, mrn)

As is the case with many other developers, the reports over the last few years of the huge energy requirements of the web have prompted me to take a look at my own websites and see what I can do to minimize their impact. This piece will cover some of my experiences in doing this, as well as my current thoughts on optimizing websites for carbon emissions, and some practical examples of things you can do to improve your own pages.

But first, a confession: When I first heard about the environmental impact of websites, I didn’t quite believe it. After all, digital is supposed to be better for the planet, isn’t it?

I’ve been involved in various green and environmental groups for decades. In all of that time, I can’t consciously remember anyone ever discussing the possible environmental impacts of the web. The focus was always on reducing consumption and moving away from burning fossil fuels. The only time the Internet was mentioned was as a tool for communicating with one another without the need to chop down more trees, or for working without a commute.

So, when people first started talking about the Internet having similar carbon emissions to the airline industry, I was a bit skeptical.

Emissions

It can be hard to visualize the huge network of hardware that allows you to send a request for a page to a server and then receive a response back. Most of us don’t live in data centers, and the cables that carry the signals from one computer to another are often buried beneath our feet. When you can’t see a process in action, the whole thing can feel a little bit like magic — something that isn’t helped by the insistence of certain companies on adding words like “cloud” and “serverless” to their product names.

As a result of this, my view of the Internet for a long time was a little ephemeral, a sort of mirage. When I started writing this article, however, I performed a little thought experiment: How many pieces of hardware does a signal travel through from the computer I’m writing at to get outside of the house?

The answer was quite shocking: 3 cat cables, a switch, 2 powerline adapters, a router and modem, an RJ11 cable, and several meters of electrical wiring. Suddenly, that mirage was beginning to look rather more solid.

Of course, the web (any, by extension, the websites we make) does have a carbon footprint. All of the servers, routers, switches, modems, repeaters, telephone cabinets, optical-to-electrical converters, and satellite uplinks of the Internet must be built from metals extracted from the Earth, and from plastics refined from crude oil. To then provide data to the estimated 20 billion connected devices worldwide, they need to consume electricity, which also releases carbon when it is generated (even renewable electricity is not carbon neutral, although it is a lot better than fossil fuels).

Accurately measuring just what those emissions are is probably impossible — each device is different and the energy that powers them can vary over the course of a day — but we can get a rough idea by looking at typical figures for power consumption, user bases, and so on. One tool that uses this data to estimate the carbon emissions of a single page is the Website Carbon Calculator. According to it, the average page tested “produces 1.76 grams of CO2 per page view”.

If you’ve been used to thinking about the work you do as essentially harmless to the environment, this realization can be quite disheartening. The good news is that, as developers, we can do an awful lot about it.

Recommended reading: How Improving Website Performance Can Help Save The Planet

Performance And Emissions

If we remember that viewing websites uses electricity and that producing electricity releases carbon, then we’ll know that the emissions of a page must heavily depend on the amount of work that both the server and client have to perform in order to display the page. Also, the amount of data that is required for the page, and the complexity of the route it must travel through, will determine the amount of carbon released by the network itself.

For example, downloading and rendering example.com will likely consume far less electricity than Apple’s home page, and it will also be much quicker. In effect, what we are saying is that high emissions and slow page loads are just two symptoms of the same underlying causes.

It’s all very well to talk about this relationship in theory, of course, but having some real-world data to back it up would be nice. To do just that, I decided to conduct a little study. I wrote a simple command-line interface program to take a list of the 500 most popular websites on the Internet, according to MOZ, and check their home pages against both Google’s PageSpeed Insights and the Website Carbon Calculator.

Some of the checks timed out (often because the page in question simply took too long to load), but in total, I managed to collect results for over 400 pages on 14 July 2021. You can download the summary of results to examine yourself but to provide a visual indication, I have plotted them in the chart below:

As you can see, while the variation between individual websites is very high, there is a strong trend towards lower emissions from faster pages. The mean average emissions for websites with a PageSpeed score of 100 is about 1 gram of carbon, which rises to a projected almost 6 grams for websites with a score of 0. I find it slightly reassuring that, despite there being many websites with very low speeds and high emissions, most of the results are clustered in the bottom right of the chart.

Taking Action

Once we understand that much of a page’s emissions originate from poor performance, we can start taking steps to reduce them. Many of the things that contribute to a website’s emissions are beyond our control as developers. We can’t, for example, choose the devices that our users access our pages from or decide on the network infrastructure that their requests travel through, but we can take steps to improve our websites’ performance.

Performance optimization is a broad topic, and many of you reading this likely have more experience than I do, but I would like to briefly mention a few things that I have observed recently when optimizing various pages’ loading speed and carbon emissions.

Rendering Is Much Slower On Mobile

I recently reworked the design of my personal blog in order to make it a little more user-friendly. One of my hobbies is photography, and the website had previously featured a full-height header image.

While the design did a good job of showcasing my photographs, it was a complete pain to scroll past, especially when moving through pages of blog posts. I didn’t want to lose the feeling of having a photo in the header, however, and eventually settled on using it as a background for the page title.

The full-height header had been using srcset in order to make loading as fast as possible, but the images were still very big on high-resolution screens, and my longest contentful paint (LCP) time on mobile for the old design was almost 3 seconds. A big advantage of the new design was that it allowed me to make the images much smaller, which reduced the LCP time to about 1.5 seconds.

On laptops and desktops, people wouldn’t have noticed a difference, because both versions were well under a second, but on much less powerful mobile devices, it was quite dramatic. What was the effect of this change on carbon emissions? 0.31 grams per view before, 0.05 grams after. Decoding and rendering images is very resource-intensive, and this grows exponentially as the images get bigger.

The size of images isn’t the only thing that can have an impact on the time to decode; the format is important as well. Google’s Lighthouse often recommends serving images in next-generation formats to reduce the amount of data that needs to be downloaded, but new formats are often slower to decode, especially on mobile. Sending less data over the wire is better for the environment, but it is possible that consuming more energy to decode could offset that benefit. As with most things, testing is key here.

From my own testing in trying to add support for AVIF encoding to the Zola static site generator, I found that AVIF, which promises much smaller file sizes than JPG at the same quality, took orders of magnitude longer to encode; something that bunny.net’s observation that WebP outperforms AVIF by as much as 100 times supports. While doing this, the server will be consuming electricity, and I do wonder whether, for websites with low visitor counts, switching to the new format might actually end up increasing emissions and reducing performance.

Images, of course, are not the only component of modern web pages that take a long time to process. Small JavaScript files, depending on what they are doing, can take a long time to execute and the same potential pitfalls as images will apply.

Recommended reading: The Humble img Element And Core Web Vitals

Round-Trips Add Up

Another thing that can have a surprising impact on performance and emissions is where your data is coming from. Conventional wisdom has long said that serving assets such as frameworks from a central content delivery network (CDN) will improve performance because getting data from local nodes is generally faster for users than from a central server. jQuery, for example, has the option to be loaded from a CDN, and its maintainers say that this can improve performance, but real-world testing by Harry Roberts has shown that self-hosting assets is generally faster.

This has also been my experience. I recently helped a gaming website improve its performance. The website was using a fairly large CSS framework and loading all of its third-party assets via a CDN. We switched to self-hosting all assets and removed unused components from the framework.

None of the optimizations resulted in any visual changes to the website, but together they increased the Lighthouse score from 72 to 98 and reduced carbon emissions from 0.26 grams per view to 0.15.

Send Only What You Need

This leads nicely onto the subject of sending users only the data they actually need. I’ve worked on (and visited) many, many websites that are dominated by stock images of people in suits smiling at one another. There seems to be a mentality amongst certain organizations that what they do is really boring and that adding photos will somehow convince the general public otherwise.

I can sort of understand the thinking behind this because there are numerous pieces on how the amount of time people spend reading is declining. Text, we are repeatedly told, is going out of fashion; all people are interested in now are videos and interactive experiences.

From that point of view, stock photos could be seen as a useful tool to liven up pages, but eye-tracking studies show that people ignore images that aren’t relevant. When people aren’t looking at your images, the images might as well be empty space. And when every byte costs money, contributes to climate change, and slows down loading times, it would be better for everyone if they actually were.

Again, what can be said for images can be said for everything else that isn’t the page’s core content. If something isn’t contributing to a user’s experience in a meaningful way, it shouldn’t be there. I’m not for a moment advocating that we all start serving unstyled pages — some people, such as those with dyslexia, do find large blocks of text difficult to read, and other users almost certainly would find such pages boring and go elsewhere — but we should look critically at every part of our websites to consider whether they are earning their keep.

Accessibility And The Environment

Another area where performance and emissions converge is in the field of accessibility. There is a common misconception that making websites accessible involves adding aria attributes and JavaScript to a page, but often what you leave out is more important than what you put in, making an accessible website relatively lightweight and performant.

Using Standard Elements

MDN Web Docs has some very good tutorials on accessibility. In “HTML: A Good Basis for Accessibility”, they cover how the best foundation of an accessible website lies in using the correct HTML elements for the content. One of the most interesting sections of the article is where they try to recreate the functionality of a button element using a div and custom JavaScript.

This is obviously a minimal example, but I thought it would be interesting to compare the size of this button version to one using standard HTML elements. The fake button example in this case weighs around 1,403 bytes uncompressed, whereas an actual button with less JavaScript and no styling weighs 746 bytes. The div button will also be semantically meaningless and, therefore, much harder for people with screen readers to use and for bots to parse.

Recommended reading: Accessible SVGs: Perfect Patterns For Screen Reader Users

When scaled up, these sorts of things make a difference. Parsing minimal markup and JavaScript is easier for a browser, just as it is easier for developers.

On a larger scale, I was recently refactoring the HTML of a website that I work on — doing things like removing redundant title attributes and replacing divs with more semantic equivalents. The original page had a structure like the following (content removed for privacy and brevity):

<div class="container">
    <section>
        <div class="row">

            <div class="col-md-3">
                <aside>
                    <!-- Sidebar content here -->
                </aside>
            </div>

            <div class="col-md-9">
                <!-- Main content here -->
                <h4>Content piece heading</h4>
                <p>
                    Some items;<br>
                    Item 1 <br>
                    Item 2 <br>
                    Item 3 <br>
                <br>
                </p>
                <!-- More main content here -->
            </div>

        </div>
    </section>
</div>

With the full content, this weighed 34,168 bytes.

After refactoring, the structure resembled this:

<div class="container">
    <div class="row">

        <main class="col-md-9 col-md-push-3">
            <!-- Main content here -->
            <h3>Content piece heading</h3>
            <p>Some items;</p>
            <ul>
              <li>Item 1</li>
              <li>Item 2</li>
              <li>Item 3</li>
            </ul>
            <!-- More main content here -->
        </main>

        <aside class="col-md-3 col-md-pull-9">
            <!-- Sidebar content here -->
        </aside>

    </div>
</div>

It weighed 32,805 bytes.

The changes are currently ongoing, but already the markup is far more accessible according to WebAIM, Lighthouse, and manual testing. The file size has also gone down, and, when averaging the time from five profiles in Chrome, the time to parse the HTML has dropped by about 2 milliseconds.

These are obviously small changes and probably won’t make any perceptual difference to users. However, it is nice to know that every byte costs users and the environment — making a website accessible can also make it a little bit lighter as well.

Videos

Project Gutenberg’s HTML version of The Complete Works of William Shakespeare is approximately 7.4 MB uncompressed. According to Android Authority in “How Much Data Does YouTube Actually Use?”, a 360p YouTube video weighs about 5 to 7.5 MB per minute of footage and 1080p about 50 to 68. So, for the same amount of bandwidth as all of Shakespeare’s plays, you will get only about 7 seconds of high-definition video. Video is also very intensive to encode and decode, and this is probably a major contributing factor to estimates of Netflix’s carbon emissions being as high as 3.2 KG per hour.

Most videos rely on both visual and auditory components to communicate their message, and large files sizes require a certain level of connectivity. This obviously places limits on who can benefit from such content. Making video accessible is possible but far from simple, and many websites simply don’t bother.

If video was only ever treated as a form of progressive enhancement, this would perhaps not be a problem, but I have lost count of the number of times I have been searching for something on the web, and the only way to find the information I wanted was by watching a video. On YouTube, the average number of monthly users grew from 20 million in 2006 to 2 billion in 2020. Vimeo also has a continually growing user base.

Despite the huge number of visitors to video-sharing websites, many of the most popular ones do not seem to be fully compliant with accessibility legislation. In contrast to this, numerous types of assistive technologies are designed to make plain text accessible to as wide a variety of people as possible. Text is also easy to convert from one format to another, so it can be used in a number of different contexts.

As we can see from the example of Shakespeare, plain text is also incredibly space-efficient, and it has a far lower carbon footprint than any other form of human-friendly information transmitted on the web.

Video can be great, and many people learn best by watching a process in action, but it also leaves some people out and has an environmental cost. To keep our websites as lightweight and inclusive as possible, we should treat text as the primary form of communication wherever possible, and offer things such as audio and video as an extra.

Recommended Reading: Optimizing Video For Size And Quality

In Conclusion

Hopefully, this brief look at my experience in trying to make websites better for the environment has given you some ideas for things to try on your own websites. It can be quite disheartening to run a page through the Website Carbon Calculator and be told that it could be emitting hundreds of kilograms of CO2 a year. Fortunately, the sheer size of the web can amplify positive changes as well as negative ones, and even small improvements soon add up on websites with thousands of visitors a week.

Even though we are seeing things like a 25-year-old website increasing 39 times in size after a redesign, we are also seeing websites being made to use as little data as possible, and clever people are figuring out how to deliver WordPress in 7 KB. So, in order for us to reduce the carbon emissions of our websites, we need to make them faster — and that benefits everybody.

Other Resources

• World Wide Waste, Gerry McGovern
• “Is WebP Really Better Than JPEG?”, Johannes Siipola
• “Make Jamstack Slow? Challenge Accepted.”, Steve Keep, CSS-Tricks
• “Can the Internet Ever Be Green?”, The Climate Question, BBC
• “Could Your Data Center Not Just Power Your Website, But Also Grow Your Salad?”, Tom Greenwood, Wholegrain Digital
• The Better Web Alliance (my own project)
• Sustainable Web Manifesto

Further Reading

• Why Optimizing Your Lighthouse Score Is Not Enough For A Fast Website
• Scaling Success: Key Insights And Practical Takeaways
• How We Optimized Performance To Serve A Global Audience
• Web Development Is Getting Too Complex, And It May Be Our Fault

(vf, yk, il, al, mrn)

I have recently been interested in the difference of opinions between the different browser vendors about the future of the web — specifically in the various efforts to push web platform capabilities closer to native platforms, such as Chromium’s Project Fugu.

The main positions can be summarized as:

• Google (together with partners like Intel, Microsoft and Samsung) is aggressively pushing forward and innovating with a plethora of new APIs like the ones in Fugu, and ships them in Chromium;
• Apple is pushing back with a more conservative approach, marking many of the new APIs as raising security & privacy concerns;
• This (together with Apple’s restrictions on browser choice in iOS) has created a stance labeling Safari to be the new IE while claiming that Apple is slowing down the progress of the web;
• Mozilla seems closer to Apple than to Google on this.

My intention in this article is to look at claims identified with Google, specifically ones in the Platform Adjacency Theory by Project Fugu leader Alex Russell, look at the evidence presented in those claims, and perhaps reach my own conclusion.

Specifically, I intend to dive into WebUSB (a particular controversial API from Project Fugu), check whether the security claims against it have merit, and try to see if an alternative emerges.

The Platform Adjacency Theory

The aforementioned theory makes the following claims:

• Software is moving to the web because it is a better version of computing;
• The web is a meta-platform — a platform abstracted from its operating system;
• The success of a meta-platform is based on it accomplishing the things we expect most computers to do;
• Declining to add adjacent capabilities to the web meta-platform on security grounds, while ignoring the same security issues in native platforms, will eventually make the web less and less relevant;
• Apple & Mozilla are doing exactly that — declining to add adjacent computing capabilities to the web, thus “casting the web in amber”.

I relate with the author’s passion for keeping the open web relevant, and with the concern that going too slow with enhancing the web with new features will make it irrelevant. This is augmented by my dislike of app stores and other walled gardens. But as a user I can relate to the opposite perspective — I get dizzy sometimes when I don’t know what websites I’m browsing are capable or not capable of doing, and I find platform restrictions and auditing to be comforting.

Meta-Platforms

To understand the term “meta-platform”, I looked at what the theory uses that name for — Java and Flash, both products of the turn of the millennium.

I find it confusing to compare either Java or Flash to the web. Both Java and Flash, as mentioned in the theory, were widely distributed at the time through browser plug-ins, making them more of an alternative runtime riding on top of the browser platform. Today, Java is used mainly in the server and as part of the Android platform, and both do not share much in common, except the language.

Today server-side Java is perhaps a meta-platform, and node.js is also a good example of a server-side meta-platform. It’s a set of APIs, a cross-platform runtime, and a package ecosystem. Indeed node.js is always adding more capabilities, previously only possible as part of a platform.

On the client side, Qt, a C++-based cross-platform framework, does not come with a separate runtime, it’s merely a (good!) cross-platform library for UI development.

The same applies for Rust — it’s a language and a package manager, but does not depend on pre-installed runtimes.

The other ways to develop client-side applications are mainly platform-specific, but also include some cross-platform mobile solutions like Flutter and Xamarin.

Capabilities Vs. Time

The main graph in the theory, shows the relevance of meta-platforms on a 2D axis of capabilities vs. time:

I can see how the above graph makes sense when talking about cross-platform development frameworks mentioned above like Qt, Xamarin, Flutter and Rust, and also to server platforms like node.js and Java/Scala.

But all of the above have a key difference from the web.

The 3rd Dimension

The meta-platforms mentioned earlier are indeed competing against their host OSes in the race for capabilities, but unlike the web, they are not opinionated about trust and distribution — the 3rd dimension, that in my opinion is missing in the above graph.

Qt and Rust are good ways to create apps that are distributed via WebAssembly, downloaded and installed directly on the host OS, or administered through package managers like Cargo or Linux distributions like Ubuntu. React Native, Flutter and Xamarin are all decent ways to create apps that are distributed via app stores. node.js and Java services are usually distributed via a docker container, a virtual machine, or some other server mechanism.

Users are mostly unaware of what was used to develop their content, but are aware to some degree of how it is distributed. Users don’t know what Xamarin and node.js are, and if their Swift App was replaced one day by a Flutter App, most users wouldn’t and ideally shouldn’t care about it.

But users do know the web — they know that when they’re “browsing” in Chrome or Firefox, they are “online” and can access content they don’t necessarily trust. They know that downloading software and installing it is a possible hazard, and might be blocked by their IT administrator. In fact, it’s important for the web platform that users know that they’re currently “browsing the web”. That’s why, for example, switching to full-screen mode shows a clear prompt to the user, with instructions of how to get back from it.

The web has become successful because it’s not transparent — but clearly separated from its host OS. If I can’t trust my browser to keep random websites away from reading files on my hard-drive, I probably wouldn’t go to any website.

Users also know that their computer software is “Windows” or “Mac”, whether their phones are Android or iOS-based, and whether they’re currently using an app (when on iOS or Android, and on Mac OS to some degree). The OS and the distribution model are generally known to the user — the user trusts their OS and the web to do different things, and to different degrees of trust.

So, the web cannot be compared to cross-platform development frameworks, without taking its unique distribution model into account.

On the other hand, web technologies are also used for cross-platform development, with frameworks like Electron and Cordova. But those are not exactly “the web”. When compared to Java or node.js, The term “The web” needs to be substituted with “Web Technologies”. And “web technologies” used in this way don’t necessarily need to be standard-based or work on multiple browsers. The conversation about Fugu APIs is somewhat tangential to Electron and Cordova.

Native Apps

When adding capabilities to the web platform, the 3rd dimension — the trust and distribution model — cannot be ignored, or taken lightly. When the author claims that “Apple and Mozilla posturing about risks from new capabilities is belied by accepted extant native platform risks”, he is putting the web and native platforms in the same dimension in regards to trust.

Granted, native apps have their own security issues and challenges. But I don’t see how that’s an argument in favor of more web capabilities, like here. This is a fallacy — the conclusion should be fixing security issues with native apps, not relaxing security for web apps because they’re in a relevance catch-up game with OS capabilities.

Native and web cannot be compared in terms of capabilities, without taking the 3rd dimension of trust and distribution model into account.

App Store Limitations

One of the criticisms about native apps in the theory is about lack of browser engine choice on iOS. This is a common thread of criticism against Apple, but there is more than one perspective to this.

The criticism is specifically about Item 2.5.6 of Apple’s app store review guidelines:

“Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.”

This might seem anti-competitive, and I do have my own reservation about how restrictive iOS is. But item 2.5.6 cannot be read without the context of the rest of the app-store review guidelines, for example Item 2.3.12:

“Apps must clearly describe new features and product changes in their ‘What’s New’ text.”

If an app could receive device access permissions, and then included its own framework that could execute code from any web site out there, those items in the app store review guidelines would become meaningless. Unlike apps, web sites don’t have to describe their features and product changes with every revision.

This becomes an even bigger problem when browsers ship experimental features, like the ones in project Fugu, which are not yet considered a standard. Who defines what a browser is? By allowing apps to ship any web framework, the app store would essentially allow the “app” to run any unaudited code, or change the product completely, circumventing the store’s review process.

As a user of both web sites and apps, I think both of them have space in the computing world, although I hope as much as possible could move to the web. But when considering the current state of web standards, and how the dimension of trust and sandboxing around things like Bluetooth and USB is far from being solved, I don’t see how allowing apps to freely execute content from the web would be beneficial for users.

The Pursuit Of Appiness

In another related blog post, the same author addresses some of this, when speaking about native apps:

“Being ‘an app’ is merely meeting a set of arbitrary and changeable OS conventions.”

I agree with the notion that the definition of “app” is arbitrary, and that its definition relies on whoever defines the app store policies. But today, the same is true for browsers. The claim from the post that web applications are safe by default is also somewhat arbitrary. Who draws the line in the sand of “what is a browser”? Is the Facebook app with a built-in browser “a browser”?

The definition of an app is arbitrary, but also important. The fact that every revision of an application using low-level capabilities is audited by someone that I might trust, even if that someone is arbitrary, makes apps what they are. If that someone is the manufacturer of the hardware I’ve paid for, it makes it even less arbitrary — the company that I’ve bought my computer from is the one auditing software with lower capabilities to that computer.

Everything Can Be A Browser

Without drawing a line of “what’s a browser”, which is what the Apple app store essentially does, every app could ship its own web engine, lure the user to browse to any website using its in-app browser, and add whatever tracking code it wants, collapsing the 3rd dimension difference between apps and websites.

When I use an app on iOS, I know my actions are currently exposed to two players: Apple & the identified app manufacturer. When I use a website on Safari or in a Safari WebView, my actions are exposed to Apple & to the owner of the top-level domain of the web site I’m currently viewing. When I use an in-app browser with an unidentified engine, I am exposed to Apple, the manufacturer of the app, and to the owner of the top-level domain. This can create avoidable same-origin violations, such as the owner of the app tracking all of my clicks on foreign websites.

I agree that perhaps the line in the sand of “Only WebKit” is too harsh. What would be an alternative definition of a browser that wouldn’t create a backdoor for tracking user browsing?

Other Criticism About Apple

The theory claims that Apple’s decline to implement features is not limited to privacy/security concerns. It includes a link, which does indeed show a lot of features that are implemented in Chrome and not in Safari. However, when scrolling down, it also lists a sizable amount of other features that are implemented in Safari and not in Chrome.

Those two browser projects have different priorities, but it’s far from the categorical statement “The game becomes clear when zooming out” and from the harsh criticism about Apple trying to cast the web in amber.

Also, the links titled it’s hard and we don’t want to try lead to Apple’s statements that they would implement features if security/privacy concerns were met. I feel that putting these links with those titles is misleading.

I would agree with a more balanced statement, that Google is a lot more bullish than Apple about implementing features and advancing the web.

Permission Prompt

Google goes long innovative ways in the 3rd dimension, developing new ways to broker trust between the user, the developer and the platform, sometimes with great success, like in the case of Trusted Web Activities.

But still, most of the work in the 3rd dimension as it relates to device APIs is focused around permission prompts and making them more scary, or things like time-box permission grants, and block-listed domains.

“Scary” prompts, like the ones in this example we see from time to time, look like they are meant to discourage people from going to pages that seem potentially malicious. Because they’re so blatant, those warnings encourage developers to move to safer APIs and to renew their certificates.

I wish that for device-access capabilities we could come up with prompts that encourage engagement and ensure that the engagement is safe, rather than discourage it and transfer the liability to the user, with no remediation available for the web developer. More on that later.

I do agree with the argument that Mozilla & Apple should at least try to innovate in that space rather than “decline to implement”. But maybe they are? I think isLoggedIn from Apple, for example, is an interesting and relevant proposal in the 3rd dimension that future device APIs could build upon — for example, device APIs that are fingerprinting-prone can be made available when the current website already knows the identity of the user.

WebUSB

In the next section I will dive into WebUSB, check what it allows, and how it’s handled in the 3rd dimension — what is the trust and distribution model? Is it sufficient? What are the alternatives?

The Premise

The WebUSB API allows full access to the USB protocol for device-classes that are not block-listed.

It can achieve powerful things like connecting to an Arduino board or debugging an Android phone.

It’s exciting to see Suz Hinton’s videos on how this API can help achieve things that were very expensive to achieve before.

I truly wish platforms found ways to be more open and allow quick iterations on educational hardware/software projects, as an example.

Funny Feeling

But still, I get a funny feeling when I look at what WebUSB enables, and the existing security issues with USB in general.

USB feels too powerful as a protocol exposed to the web, even with permission prompts.

So I’ve researched further.

Mozilla’s Official View

I started by reading what David Baron had to say about why Mozilla ended up rejecting WebUSB, in Mozilla’s official standards position:

“Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they’re connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent.”

The Current Permission Prompt

This is what Chrome’s WebUSB permission prompt looks like at the time of publishing this post:

Particular domain Foo wants to connect to particular device Bar. To do what? and how can I know for sure?

When granting access to the printer, camera, microphone, GPS, or even to a few of the more contained WebBluetooth GATT profiles like heart rate monitoring, this question is relatively clear, and focuses on the content or action rather than on the device. There is a clear understanding of what information I want from the peripheral or what action I want to perform with it, and the user-agent mediates and makes sure that this particular action is handled.

USB Is Generic

Unlike the devices mentioned above that are exposed via special APIs, USB is not content-specific. As mentioned in the intro of the spec, WebUSB goes further and is intentionally designed for unknown or not-yet-invented types of devices, not for well-known device classes like keyboards or external drives.

So, unlike the cases of the printer, GPS and camera, I cannot think of a prompt that would inform the user of what granting a page permission to connect to a device with WebUSB would allow in the content realm, without a deep understanding of the particular device and auditing the code that’s accessing it.

The Yubikey Incident And Mitigation

A good example from not too long ago is the Yubikey incident, where Chrome’s WebUSB was used to phish data from a USB-powered authentication device.

Since this is a security issue that is said to be resolved, I was curious to dive into Chrome’s mitigation efforts in Chrome 67, which include blocking a specific set of devices and a specific set of classes.

Class/Device Block-List

So Chrome’s actual defense against WebUSB exploits that happened in the wild, in addition to the currently very general permission prompt, was to block specific devices and device classes.

This may be a straightforward solution for a new technology or experiment, but will become harder and harder to accomplish when (and if) WebUSB becomes more popular.

I’m afraid that the people innovating on educational devices via WebUSB might reach a difficult situation. By the time they’re done prototyping, they could be facing a set of ever-changing non-standard block lists, that only update together with browser versions, based on security issues that have nothing to do with them.

I think that standardizing this API without addressing this will end up being counterproductive to the developers relying on it. For example, someone could spend cycles developing a WebUSB application for motion detectors, only to find out later that motion detectors become a blocked class, either due to security reasons or because the OS decides to handle them, causing their entire WebUSB effort to go to waste.

Security Vs. Features

The platform adjacency theory, in some ways, considers capabilities and security to be a zero-sum game, and that being too conservative on security & privacy concerns would cause platforms to lose their relevance.

Let’s take Arduino as an example. Arduino communication is possible with WebUSB and is a major use case. Someone developing an Arduino device will now have to consider a new threat scenario, where a site tries to access their device using WebUSB (with some user permission). As per the spec, this device manufacturer now has to “design their devices to only accept signed firmware”. This can add burden to firmware developers, and increase development costs, while the whole purpose of the spec is to do the opposite.

What Makes WebUSB Different From Other Peripherals

In browsers, there is a clear distinction between user interactions and synthetic interactions (interactions instantiated by the web page).

For example, a web page can’t decide on its own to click a link on or wake up the CPU/display. But external devices can — for example, a mouse device can click a link on behalf of the user and almost any USB device can wake up the CPU, depending on the OS.

So even with the current WebUSB specification, devices can choose to implement several interfaces, e.g. debug for adb and HID for pointer input, and using malicious code that takes advantage of ADB, become a keylogger and browse websites on behalf of the user, given the right exploitable firmware flashing mechanism.

Adding that device to a blocklist would be too late for devices with firmware that was compromised using ADB or other allowed forms of flashing, and would make device manufacturers even more reliant than before on browser versions for security fixes associated with their devices.

Informed Consent & Content

The problem with informed consent and USB, as mentioned before, is that USB (specifically in the extra-generic WebUSB use-cases) is not content-specific. Users know what a printer is, what a camera is, but “USB” for most users is merely a cable (or a socket) — a means to an end — very few users know that USB is a protocol and what enabling it between websites and devices means.

One suggestion was to have a “scary” prompt, something along the lines of “Allow this web page to take over the device” (which is an improvement over the seemingly harmless “wants to connect”).

But as scary as prompts get, they cannot explain the breadth of possible things that can be done with raw access to a USB peripheral that the browser doesn’t know intimately, and if they did, no user in their right mind would click “Yes”, unless it’s a device that they fully trust to be bug-free and a website they truly trust to be up-to-date and not malicious.

A possible prompt like that would read “Allow this web page to potentially take over your computer”. I don’t think that a scary prompt like this one would be beneficial for the WebUSB community, and constant changes to these dialogs will leave the community confused.

Prototyping Vs. Product

I can see a possible exception to this. If the premise of WebUSB and the other project Fugu APIs was to support prototyping rather than product-grade devices, all-encompassing generic prompts could make sense.

In order to make that viable, though, I think the following must happen:

1. Use language in the specs that set expectations about this being for prototyping;
2. Have these APIs available only after some opt-in gesture, like having the user enable them manually in the browser settings;
3. Have “scary” permission prompts, like the ones for invalid SSL certificates.

Not having the above makes me think that these APIs are for real products rather than for prototypes, and as such, the feedback holds.

An Alternative Proposal

One of the parts in the original blog post that I agree with is that it’s not enough to say “no” — major players in the web world who decline certain APIs for being harmful should also play offense and propose ways in which these capabilities that matter to users and developers can be safely exposed. I don’t represent any major player, but I’m going to give it a humble go.

I believe that the answer to this lies in the 3rd dimension of trust and relationship, and that it’s outside the box of permission prompts and block-lists.

Straightforward And Verified Prompt

The main case I’m going to make is that the prompt should be about the content or action, and not about the peripheral, and that informed consent can be granted for a specific straightforward action with a specific set of verified parameters, not for a general action like “taking over” or “connecting to” a device.

The 3D Printer Example

In the WebUSB spec, 3D printers are brought as an example, so I’m going to use it here.

When developing a WebUSB application for a 3D printer, I want the browser/OS prompt to ask me something along the lines of Allow AutoDesk 3ds-mask to print a model to your CreatBot 3D printer?, be shown a browser/OS dialog with some print parameters, like refinement, thickness and output dimensions, and with a preview of what’s going to be printed. All of these parameters should be verified by a trusted user agent, not by a drive-by web page.

Currently, the browser doesn’t know the printer, and it can verify only some of the claims in the prompt:

• The requesting domain has a certificate registered to AutoDesk, so there is some certainty that this is AutoDesk Inc;
• The requested peripheral calls itself “CreatBot 3d printer”;
• This device, device class and domain are not found in the browser’s block-lists;
• The user responded “Yes” or “No” to a general question they were asked.

But in order to show a truthful prompt and dialog with the above details, the browser would also have to verify the following:

• When permission is granted, the action performed will be printing a 3D model, and nothing but that;
• The selected parameters (refinement/thickness/dimensions etc.) are going to be respected;
• A verified preview of what is going to be printed was shown to the user;
• In certain sensitive cases, an additional verification that this is in fact AutoDesk, maybe with something like a revokable short-lived token.

Without verifying the above, a website that was granted permission to “connect to” or “take over” a 3D printer can start printing huge 3D models due to a bug (or malicious code in one of its dependencies).

Also, an imagined full-blown web 3D printing capability would do a lot more than what WebUSB can provide — for example, spooling and queuing different print requests. How would that be handled if the browser window is closed? I haven’t researched all the possible WebUSB peripheral use-cases, but I’m guessing that when looking at them from a content/action perspective, most will need more than USB access.

Because of the above, using WebUSB for 3D printing will probably be hacky and short-lived, and developers relying on it will have to provide a “real” driver for their printer at some point. For example, if OS vendors decide to add built-in support for 3D printers, all sites using that printer with WebUSB would stop working.

Proposal: Driver Auditing Authority

So, overarching permissions like “take over the peripheral” are problematic, we don’t have enough information in order to show a full-fledged parameter dialog and verify that its results are going to be respected, and we don’t want to send the user on an unsafe trip to download a random executable from the web.

But what if there was an audited piece of code, a driver, that used the WebUSB API internally and did the following:

• Implemented the “print” command;
• Displayed an out-of-page print dialog;
• Connected to a particular set of USB devices;
• Performed some of its actions when the page is in the background (e.g. in a service worker), or even when the browser is closed.

An auditing of a driver like this can make sure that what it does amounts to “printing”, that it respects the parameters, and that it shows the print preview.

I see this as being similar to certificate authorities, an important piece in the web ecosystem that is somewhat disconnected from the browser vendors.

Driver Syndication

The drivers don’t have to be audited by Google/Apple, though the browser/OS vendor can choose to audit drivers on its own. It can work like SSL certificate authorities — the issuer is a highly trusted organization; for example, the manufacturer of the particular peripheral or an organization that certifies many drivers, or a platform like Arduino. (I imagine organizations popping up similar to Let’s Encrypt.)

It might be enough to say to users: “Arduino trusts that this code is going to flash your Uno with this firmware” (with a preview of the firmware).

Caveats

This is of course not free of potential problems:

• The driver itself can be buggy or malicious. But at least it’s audited;
• It’s less “webby” and generates an additional development burden;
• It doesn’t exist today, and cannot be solved by internal innovation in browser engines.

Other Alternatives

Other alternatives could be to somehow standardize and improve the cross-browser Web Extensions API, and make the existing browser add-on stores like Chrome Web Store into somewhat of a driver auditing authority, mediating between user requests and peripheral access.

Summary Of Opinion

The author, Google and partners’ bold efforts to keep the open web relevant by enhancing its capabilities are inspirational.

When I get down to the details, I see Apple and Mozilla’s more conservative view of the web, and their defensive approach to new device capabilities, as carrying technical merit. Core issues with informed consent around open-ended hardware capabilities are far from being solved.

Apple could be more forthcoming in the discussion to find new ways to enable device capabilities, but I believe this comes from a different perspective about computing, a standpoint that was part of Apple’s identity for decades, not from an anti-competitive standpoint.

In order to support things like the somewhat open-ended hardware capabilities in project Fugu, and specifically WebUSB, the trust model of the web needs to evolve beyond permission prompts and domain/device block-lists, drawing inspiration from trust ecosystems like certificate authorities and package distributions.

Further Reading

• How Improving Website Performance Can Help Save The Planet
• Towards An Ad-Free Web: Diversifying The Online Economy
• Is There A Future Beyond Writing Great Code?
• Using Ethics In Web Design

(ra, yk, il, mrn)

Money talks, and there is an awful lot of money on the web these days. That is not necessarily a bad thing in and of itself, but it does seem to have hamstrung how websites are designed and financed. The pandemic — and the consequent collapse of an already warped online ad ecosystem — makes it all the clearer that the web needs to diversify the way it makes money, and who it ultimately serves.

State Of The Web

The Internet is not in the best shape right now. Back in 2017, the founder of the World Wide Web, Sir Tim Berners-Lee, said:

“The system is failing. The way ad revenue works with clickbait is not fulfilling the goal of helping humanity promote truth and democracy.”

I think it’s safe to say things have largely gotten worse since then. Ads everywhere, tracking run amok, clickbait, misinformation, net neutrality under siege… engagement is king — more important than nuance, ethics, or truth — because that’s where the money is. The average user sees thousands of ads per day. The World Wide Web isn’t exactly humanity’s shining light right now, at a time when a whole lot of things are compounding our general sense of inescapable doom.

In the midst of this dog-track-dog online culture, the common website has been browbeaten into meek, insipid husks of what they could be. Can we get another ad in there? What about a few more pop-ups? Maybe a few affiliate links. We’ve all experienced the insidiousness of the modern web, we’ve all seen the pop-ups saying ‘We care about your privacy’ before asking us to sign away our privacy. One tires of being lied to so often, and so casually.

Still, I’m not here to complain. At least, I’m not just here to complain. There are flickers of light in the darkness. There are other ways to pay for websites. It’s just as well too because legislation will catch up with the wild wild World Wide Web eventually and then ads will be worth even less.

That’s what this piece is about: alternatives, and why they’re worth embracing. There will always be ads, and up to a point that’s fine, but there shouldn’t only be ads.

Other Resources

• “The High Privacy Cost of a “Free” Website,” Matt Chase
• 10 States Accuse Google of Abusing Monopoly in Online Ads, David McCabe & Daisuke Wakabayashi

Exploring Alternatives

Not every website needs to make money. Let’s get that out of the way. Making money is not the measure of a thing. Not every website needs to care about cost. Hobbies, blogs, forums, digital art… plenty of things are worth doing for their own sake.

This article is directed at sites or web apps that offer some kind of service, with operational costs and long-term financial factors that extend beyond a few dollars on a domain name. This article is about widening the horizon of the online economy beyond ads, ads, and more ads.

Subscriptions

This is probably the most obvious alternative to ads, and trickier than you might think to implement. The principle of it is simple: a website does something of value and asks users to pay for it.

A major advantage of subscriptions is their simplicity. Want X? Pay for X. More and more people are wising up to the fact that few things online are truly free. More often than not when an online service is ‘free’ its users are the product. A valuable service reasonably priced is a welcome antidote to that.

A high profile example of this is Medium. Signing up for a few dollars a month gives members access to articles. It’s an increasingly popular approach in editorial circles. Some publications, like The Guardian, make their content accessible to everyone, while the likes of The New York Times use a paywall. In either case, the pitch is the same: help make what we do possible by subscribing.

Smashing itself does this well, having pivoted away from ads during the big site redesign a few years back. Ads still play a big part, yes, but they’re not the only part. Sustainability online isn’t about moving all your eggs from one basket to another — it’s about variety, about escaping the tunnel vision of advertising.

There are examples of subscriptions and donations working away from editorial contexts. Lynda charges for its courses. Wikipedia, mercifully, is ad-free, sustained by intermittent donation drives to its parent organization, the Wikimedia Foundation.

The subscription approach isn’t for everyone. The above examples all happen to be household names, after all. Strange that. Trust is such a big factor, and if you’re new on the block how many people are likely to give you their moola?

And, of course, there is also the Catch-22 situation of paywalls making a site inaccessible to most of the Internet. It’s bad for growing an audience and at odds with the web’s founding spirit of openness and transparency. That doesn’t sit well with a lot of people — including myself.

I think the saving grace here is that the ‘subscription model’ is much more of a spectrum than it was even five years ago. You can have everything from paywalls to ‘buy me a coffee’ buttons depending on what a website does.

If you provide a service — be it quality editorial content, useful tools, open access to data, or whatever else — don’t be shy about asking for support. And don’t be shy about incorporating those requests into the website’s design. A variety of tools and platforms can be integrated into existing sites with relative ease. Patreon, Ko-fi, and plenty more.

This is not about making people feel guilty. Not everyone can afford to support the sites they visit, and not everyone will think you’re worth supporting. It’s on you to make a positive case for yourself. Crowdfunding platforms like Open Collective and Chuffed are especially good reference points for this, modeling behavior such as:

• Not making visitors feel guilty;
• Telling stories people want to be part of and support;
• Transparency about where the money’s going.

There is also the question of integration. Buttons, pop-ups, prudently placed CTAs. It all adds up, having started and pushed a reader patron scheme at a previous job.

Other Resources & Resources

• Monetising With Buy Me a Coffee, Does it Work?, Michael Brockbank
• Open Collective, a platform for transparent financing

Micropayments

It’s early days for this one, but something to keep an eye on. Web Monetization is a concept whereby Internet users have a kind of fund they top up regularly — let’s say $5 every month. When time is spent on a site, a fraction of the fund is transferred to that site.

The Brave web browser is a major example of this. Another is Web Monetization, which is being proposed as a W3C standard. Or Scroll, a kind of catch-all ad-free web package.

This approach seems to have struck a nerve, I think because it hits a balance between a Wild West Internet and a corporate one. The more people believe in it, the better it works. Three billion people use the web. If 10% signed up for three bucks a month that would still be a cool ten billion dollars up for grabs.

For the time being results are closer to pennies. But hey, nothing worth having comes easy. Supporting this approach is a two-way street. Depending on the system, implementation can be as simple as adding a line of code to the <head> of your website. It’s also a case of walking the walk.

Will this approach alone save the Internet? Probably not, but again, moving away from ads is about diversification, not finding a silver bullet.

Free, Non-Corporate Platforms

Now obviously, free platforms are not the answer to large-scale applications and web experiences. They are, however, often a perfect way to have an online presence without being sucked into the engagement black hole of modern social media.

Places like Neocities — a homage of sorts to GeoCities — still have a lot of life in them. I know, I’m on it. Independent, playful non-corporate platforms feel like something from another time, but they’re still perfectly good ways of planting your flag online.

It seems marketing has hammered into people that the only website worth having is one you’re paying through the nose for. Not so. The DIY weird web is alive and well.

With the likes of Netlify and GitHub pages about it’s perfectly possible to piggyback along without paying for anything more than a domain name, and even that is optional.

Of course, there is a limit to this kind of approach, but that doesn’t make it any less viable. By the time a website is bringing in enough traffic to warrant a dedicated hosting plan, it’s likely well placed to be asking for support.

Other Resources

• Autonomy Online: A Case For The IndieWeb, Ana Rodrigues

Taking Control Of Your Data

All this talk of diversification and sustainability ties into a broader discussion going on right now about privacy. Half the battle is messaging. Although awareness is growing, a lot of people still don’t know about the costs of ‘free’ online experiences. That’s not an accident. Take the time to explain that if someone subscribes to a website’s service, they’re not just receiving the service. They’re receiving priority, respect, and privacy.

Advocating for a less ad-centric web means taking an honest look at who our masters are online. When you make a site, who is the site for? Is it for advertisers? Affiliates? Clients? Or is it for the people visiting the site? How lovely would it be to have robust, ethical income strategies that made websites beholden first and foremost to the people who use them.

The Role Of Developers

In a line of work where projects are increasingly fragmented, it’s easy to remove oneself from the moral failings of any given project. Edward Snowden said the same was true of the NSA spying programs he leaked in 2013. Just this year he identified social networks and apps as carrying similar risks.

Incorporate sustainability into your designs. Communicate what you do and how you survive and what people can do to help. Progress does not happen on its own. It never has and it never will. We have to be the change we want to see.

Further Reading

• Thoughts On Markdown
• How To Build Custom Data Visualizations Using Luzmo Flex
• The Mythical Mythical Man-Month
• How To Improve Your Microcopy: UX Writing Tips For Non-UX Writers

(ra, il, mrn)

As a product leader at a tech company, I am a bottomless pit of need. My job as the Chief Product Officer at Mailchimp is to bring the product to market that’s going to win in a very competitive space. Mailchimp’s aspirations are high, and to realize them we need to deliver a substantial amount of product to the market. Oftentimes to many at the company, it feels like we are doing too much. We’re always at the edge of the wheels coming off.

And when you’re doing too much and you decide to do more than even that, you will inevitably begin to hear The Mythical Man-Month referenced. It’s like one of those stress-relief balls where if you squeeze one end, then out pops the Mythical Man-Month at the other end.

Published by Frederick Brooks back in 1975 (you remember 1975, right? When software development 100% resembled software development in 2020?), this book is rather famous amongst software engineers. Specifically, there’s one point in the entire book that’s famous (I’m not convinced people read anything but this point if they’ve read the book at all):

“...adding more men lengthens, not shortens, the schedule.”

Easy fix. I’ll just staff women to projects from now on (see the Return of the King and the fight against the Witch King of Angmar).

But let’s assume that Brooks’ point holds regardless of the gender identification of the software engineers in question. Here’s the point: software is difficult to build with lots of complex interdependencies. And everyone needs to work together to get it done.

As I add people to a team, they need to be onboarded and grafted into the project. Someone’s gotta carve off the right work for them. The team has to communicate to make sure their stuff all works together, and each additional person increases that communication complexity geometrically. And at some point, adding people becomes a burden to the project — not a benefit.

Here’s the graph from the book illustrating that point:

This is absolutely a fair point. That’s why I hear it so much at work. Exhausted individual contributors and exhausted leaders alike will toss it out — we can’t go faster, we can’t do more, stop the hiring, read The Mythical Man-Month and despair! The only solution is apparently to stop growing and kill some projects.

When I as CPO say, “we’re going to do this thing!” the reply then is often, “OK, so then what are we going to kill?” The Mythical Man-Month turns product development into a zero-sum game. If we want one thing, we must stop another. Now, that’s an actual myth, and I call hogwash.

And taken to its pathologically misinterpreted (we’ll get to this) conclusion, the book apparently says that the fastest tech company is one that employs all of four people — four men, apparently. Anything more just slows it all down. Someone should send Amazon, Apple, and Google copies of the book, so they can fix their obviously bloated orgs.

The only problem with this approach is that in a space where the competition is growing and iterating and executing — merely tamping organizational growth — editing and focusing the workload to match can be a recipe for extinction. You’ll be more sane and less stressed — right until you’re out of a job.

And as the owner of product management for my company, I’m not unsympathetic with this need to slow down and focus. We must ruthlessly prioritize! No doubt. But running a product is an exercise in contradiction. I must prioritize what I’ve got while simultaneously scheming to get more done. But what am I to do in the face of the Mythical Man-Month?

Surprisingly, the answer to this question comes from Brooks’ same book. Here’s another graph in the same chapter:

There is a battle in scaling product development. If the work you’re trying to accomplish is purely partitionable, then go ahead and add people! If your work is all connected, then at some point adding people is just wrong.

If someone says that I absolutely have to kill a project in order to start another one, that’s just not the case. If the two projects require very little communication and coordination, then we can scale away.

This is why adding cores to a CPU can increase the experienced speed of your computer or phone up to a point — something engineers should know all about. Sure, adding cores won’t help me complete a complex single-threaded computation. But it may help me run a bunch of independent tasks.

The conflict for a product executive then between scaling and ruthless prioritization can be managed.

1. You ruthlessly prioritize in places that are single-threaded (the backlog for a product team let’s say).
2. You scale by adding more cores to handle independent work.

Very rarely, however, is anything fully-independent of all else at a company. At the bare minimum, your company is going to centralize supporting functions (global IT, legal, HR, etc.) leading to bottlenecks.

It’s All About Dependency Management

The job of a product executive then becomes not only creating a strategy, but executing in a way that maximizes value for the customer and the business by ensuring throughput and reducing interdependency risk as much as possible. “As much as possible” being key here. That way you can make the company look as much like the latter graph rather than the former. Interdependency is a disease with no cure, but its symptoms can be managed with many treatments.

One solution is to assemble a strategic direction for the company that minimizes or limits dependency through a carefully-selected portfolio of initiatives. The funny thing here is that many folks will push back on this. Let’s say I have two options, one where I can execute projects A, B, and C that have very little coordination (let’s say they impact different products), and another option with projects D1, D2, and D3 that have tons of interdependencies (let’s say they all impact the same product). It’s often the case that the Mythical Man-Month will be invoked against the former plan rather than the latter. Because on paper it looks like more.

Indeed, it’s less “focused.” But, it’s actually less difficult from a dependency perspective and hence fairs better with added personnel.

Keep in mind, I’m not saying to choose a bunch of work for the company that’s not related. Mailchimp will not be building a microwave oven anytime soon. All work should drive in the same long-term direction. This approach can increase customer experience risk (which we’ll discuss later) as well as the burden on global functions such as customer research. Keep an eye out for that.

Another treatment is to create a product and program management process that facilitates dependency coordination and communication where necessary without over-burdening teams with coordination if not required. Sometimes in attempting to manage coordination so we can do more we end up creating such onerous processes that we end up doing less. It’s a balance between doing too little coordination causing the pieces to not inter-operate and doing too much coordination causing the pieces to never get built because we’re all in stand-ups for eternity.

The contention in the Mythical Man-Month is that as you add folks to a software project, the communication needs to increase geometrically. For example, if you have 3 people on the project, that’s 3 lines of communication. But if you have 4, that’s 6 lines of communication. One extra person, in this case, leads to double the communication! Fun. (This is, of course, an over-simplification of communication on software development projects.)

Different people have different roles and hence receive different amounts of autonomy. Perhaps the project manager needs to communicate with everyone on the team. But does an engineer working on the API need to communicate with the product marketer? Or can the marketer just go through the product manager? A good process and meeting cadence can then eliminate unnecessary communication and meetings. The point is that Brooks’ intercommunication formula is an upper bound on coordination, not a death sentence.

Finally, use tools, principles, and frameworks combined with independent work over actual collaboration to combat interdependency symptoms. For example, if I can coordinate two teams’ key performance indicators (KPIs, i.e. measurements of success) to incentivize movement in more-or-less the same direction, then their independent work is more likely to end up “closer together” than if their KPIs incentivize orthogonal movement. This won’t ensure things fit together perfectly, only that the work I need to do to make them fit together in the future is less than it might otherwise be. Other examples might include using “even-over” statements, design systems, and automated testing.

So there’s a start. But interdependencies take on lots of forms beyond code. Let me give an example from Mailchimp.

Customer Experience Risk: The Hidden (But Acceptable?) Cost Of Firewalling Work

Since Mailchimp’s customer is often a small business owner who’s a marketing novice (and there are millions of small business owners turned marketers worldwide), we must deliver an experience that is seamless and immediately understandable end-to-end. We’re not afforded the luxury of assembling a Frankenstein’s monster of clouds via acquisition the way that enterprise players can. We can’t paper over poorly-integrated software with consultants and account managers.

As a consumer product (think Instagram or a Nintendo Switch or a Roomba), we have to be usable out of the box. For an all-in-one marketing platform meant to power your business, that’s hard! And that means each thing Mailchimp builds must be seamlessly connected from an experience perspective.

But, perfectly partitioning projects then introduces experience risk. It’s not that the code can’t be written independently. That can be achieved, but there’s still a risk that the products will look like they’ve been built by different teams, and that experience can be really damn confusing for the user. We bump up against Conway’s law — our customers can tell where one team’s work ends and the other team’s work begins.

So you try to connect everyone’s work together — not just on the back-end but on the front-end, too. In the ecosystem era, dominated by CX excellence from players like Apple, this has become almost table stakes in the consumer space. But this is a Mythical Man-Month nightmare, though not from an engineering perspective this time. It’s from a service design perspective. As we add more people to all of this “end-to-end” connected work, everything slows to a collaborative crawl.

Other than the third fix I noted above, using tools and frameworks rather than over-watchers and stage-gates, there is another release valve: make some deliberate customer experience trade-offs. Specifically, where are we comfortable releasing an experience that’s disconnected from the rest (i.e. that’s sub-par)? Accepting risk and moving forward is the product leader’s job. And so you use some criteria to sort it out (perhaps it’s not holding new, low-traffic areas of the app to the same experience standards as your “cash cows”), and make a decision (e.g. iteration and learning over polish on adjacent innovations). This, of course, extends beyond design.

You can always short-circuit Brooks’ law by choosing to firewall efforts, including efforts that, in a perfect world, shouldn’t be firewalled!

“

I’ll caveat this by saying the software I build doesn’t kill anyone. I wouldn’t advocate this approach if I were building a medical device. But at a marketing software company, I can deliberately isolate teams knowing that I’ve increased the odds of incompatibility as a trade-off for scaling up personnel and moving faster.

I’m sad to admit that the Mythical Man-Month is a reality at my company, and I suspect at yours as well. But it’s manageable — that’s the bottom line. Parallelization and dependency mitigation offer us a way out that limits the near-mythical status of the Mythical Man-Month. So the next time the stark dichotomy is raised at your company (scale to go slower or give up your aspirations) remember that if you’re smart about how you line up the work, you can still grow big.

Don’t Forget About The Softer Side Of Scaling

Keep in mind that managing the Mythical Man-Month will not stop engineers from invoking it like dark magic. They’re invoking the principle not only because there’s some truth in it, but because scaling just sucks (always) from an emotional and cognitive perspective. If I think I’m paid to write code and solve customer problems, the last thing I wanna do is change up my routine and figure out how to work with new people and a larger team.

As you scale your company, remember to empathize with the pain of scaling and change. A team that adds even a single member becomes a whole new team from a trust and cultural perspective. People are tired of this change. That means that while you go about managing and mitigating the Mythical Man-Month, you’ll need to manage the emotions surrounding growth. That’s perhaps the most critical task of all.

Strong belief in the Mythical Man-Month by a team in and of itself can bring its conclusions into reality. It’s basically the equivalent of the belief in flying in Peter Pan. If the team believes that scaling will slow them and they don’t buy into the change, they will indeed slow down.

So as you work to manage dependencies and introduce tools to help scale, make sure you clearly communicate the why behind the practices. Get folks involved in selecting the work and processes that mitigate man-month issues, because when they’re part of the change and their outlook changes, suddenly scaling becomes at least culturally possible.

Further Reading

• Lessons Learned After Selling My Startup
• How To Improve Your Microcopy: UX Writing Tips For Non-UX Writers
• Building A User Segmentation Matrix To Foster Cross-Org Alignment
• How AI Technology Will Transform Design

(ra, il, mrn)

Let’s do a quick exercise. Say you’ve been working professionally as a developer for more than five years. You’ve gained hands-on experience through dozens of projects and kept your skillset sharp by learning about new techniques, tools, and frameworks. You contribute to different libraries, routinely refactor the code you write, and periodically exchange code reviews with your colleagues.

But then someone comes up and asks you that one question you haven’t had the chance to figure out: Where do you see yourself, ten years from now?

You might be worried about the idea that if you continue down the same road, you’ll simply be an older developer who codes a bit better and a bit faster. Some developers are happy with this thought and simply can’t wait to continue down that road. But others might realize that this rollercoaster of lessons and growth you’ve been through is quickly shifting to cruise-control mode.

Once you feel you’re in complete control of your role as a developer, you start feeling the itch to do more. Not more of the same, but more personal growth instead. Maybe something different.

During the past few years of my career, I’ve been looking for answers. I got the chance to work with (and learn from) many successful developers who managed to transition into highly influential roles in which they make the most out of their technical background. Each of them explored a different path in which they were able to make an organic transition, based on a balance between their core skills and their complementary skills.

Where Can We Go From Here?

There are some new paths we can explore, that can force us to grow beyond our comfort zones and at the same time benefit from the skillset we’ve worked so hard to cultivate.

As developers, most of the articles we read, the programming books, and even the advice from our peers, are all tailored to help us to only focus on writing better code. Other than that, we’re not really taught how to work better or, to put it in a more philosophical perspective, how to evolve.

We usually have no clue about what comes after achieving the goals we set out for ourselves when we started our careers or if there’s even something we want to do other than coding eight hours a day, for the rest of our lives. It’s common to even underestimate our possible contribution to the team if we were to be doing something other than writing code in the near future. We’re not sure how we can make a bigger impact, even though our perspective and skills are definitely needed in more influencing positions.

Listen To The Industry

Back in 2008, when I started my career as a frontend developer, there wasn’t a person in the world who hadn’t heard of Mark Zuckerberg, the young programmer that became a millionaire while changing the way people communicate. Millennials began to romanticize the idea of legally getting rich while wearing a hoodie. Suddenly, almost every person from my generation wanted to become a developer.

Now, over a decade later, we’re starting to feel the true impact of this boom of coders. Through this year’s Stack Overflow Survey, we learned that more than two-thirds of respondents have less than ten years of professional coding experience.

We can clearly see that experienced developers with leadership skills are scarce, so now companies have to find creative ways to book their best talent in a way that they can oversee more junior developers and maintain the quality of work. This creates an organic leadership structure within growing teams.

The industry continues to grow at a rapid pace and so are our roles as developers. It has become more common to find directors and managers that started out as programmers, and companies are now opening up more leadership positions that require development backgrounds.

It’s safe to say that, even though programming was considered as the next blue-collar job, the role of the developer is growing into highly influential positions within organizations. But there is no written roadmap or proven formula to guide us through that transition.

What Are Some Of Our Options?

There came a point in my career in which I was asked the dreaded question about the future I envision for myself. I had no answer. In fact, it triggered even more questions that hadn’t crossed my mind.

I was already working as frontend lead so I had been given more and more responsibilities apart from writing code, which made me think of a possible future in which I probably wouldn’t be programming. The possibility of having more impact across different projects was definitely appealing.

So I set out to research what options could be interesting for my future. I looked at the path that some colleagues had taken in which they had successfully transitioned from the role of developers to important positions within the company. Most of the cases consisted of taking small steps and being in the right place at the right time. But overall, they all ended up involving themselves in these three main groups of activities:

1. Managing teams and projects
   Leading a group of people into greatness sounds exciting, but it’s not easy. As seasoned developers, there are many options of growth that involve either managing a group of fellow developers as a team or managing projects across multi-disciplinary teams. Although it’s a highly rewarding option, it requires stepping away from the keyboard and learning to delegate, which can be very tricky for developers that are used to personally solving all of their problems.
   
   Moving on to a position in which we are in more control of the process and the team involved around it will most likely lead for the need of sacrificing the control we’re used to having when it comes to code.
2. Mentoring and developing talent
   How many bosses have fantasized about cloning their top developers? In the real world, this is still not likely to happen, so smart bosses do the next best thing: they set up processes in which the savviest coders can actively pass along their knowledge to their peers.
   
   We have to keep in mind that even though some developers do this naturally in their day-to-day, it’s always more effective if senior developers are given a more formal role in which they can routinely allocate their time to work on the growth of their teams. This can be done with code reviews, workshops, and individual assessments with some colleagues.
3. Being in the business of technology
   It’s very common to hear developers complain about how projects were pitched or defined when they were sold to clients. And, in most cases, it’s usually too late to complain.
   
   In my experience, I found myself happier working on projects in which developers had been involved during the sale. It’s always great to have a logical-minded ally flagging potential technical issues in a room where nobody else had a clue.
   
   The roles of consultants and technical directors are crucial in large digital projects. The involvement of developers in client workshops and drafting technical documentation at the start of any project can potentially be game-changers for the lifecycle of a project.

Working On A New Set Of Tools

Let’s say we want to continue to grow and want to embark on a future where we want to do more than just writing code. Once we have an idea about where we’re headed, it’s very likely that we may not yet be prepared for the leap. After all, we’ve just been focusing on acquiring skills that make us better developers.

Once we realize we have a lot to learn, we need to start working on the right set of skills. This time it will be different: we won’t be learning new languages, frameworks, or libraries. We’re going to need to stock up on skills that might have not felt important in the past, but are crucial for taking the next steps in these uncertain territories.

Communication

For anybody who has a job at any company, this would be a no-brainer. Communication is known to be the core of collaboration within any type of organization. Unfortunately, programmers have been given a free pass in this area for many years. The need to find logical-minded, hard-working, passionate individuals has allowed us to thrive without the need to really have great communication skills and even be a very socially awkward bunch.

If we have any aspirations to work with different teams and clients, it’s very clear that we will have to work on improving all aspects of our communication. One-on-one meetings, presentations, and important emails will all need to be carefully polished from now on.

Ownership

Having logical mindsets has impacted on the way we organize our work. As developers, we usually have a black-and-white sense of where our work begins and where it ends. This is positive when it allows us to have a clear understanding of the work that needs to be done by us, but sometimes prevents us from pushing our boundaries and working outside of our comfort zones.

The first order of business is to start taking ownership of all aspects of the work we’re involved in. By blurring the line that defines where a developer’s work ends, we’re able to take on new responsibilities and eventually transition into different roles.

Leadership

Wherever we’re headed in our careers, we’re going to need for our teammates to trust us. We’ll need them to know we’re headed in the right direction, even if for a moment it’s not totally clear.

In order to achieve this, we’ll need to be able to prove our knowledge, we’ll need to be confident in our decisions, and we will definitely need to be able to acknowledge our mistakes and quickly learn from them.

This is not a simple task and it’s not something you will be able to check off a list. It’s going to require our dedication for as long as we wish to continue growing outside the development bubble.

Get To Work

Once we’re sure we want to take a leap in our career, we have to start moving in the right direction. The first step would be to explore the options, decide which path you want to pursue, and see how that path aligns with your current role.

Does your company offer a space in which you could be a mentor or a manager? Do you think that there’s a chance of making it happen there or do you think you will need to continue your growth elsewhere? These are just some of the questions you have to ask yourself and will also lead to a conversation with some of your teammates and managers.

Taking a step in a new direction will require putting in the hard work, having an open mind, and being resilient enough to fail and try again, as many times as it takes.

Further Reading

• The Problem With WordPress Is Positioning, Not Plugins
• How Developers Can Strengthen Their Mental Health Amidst High-Pressure Projects
• Designing Web Design Documentation
• Should The Web Expose Hardware Capabilities?

(dm, il, mrn)

You may not think about it often, but the Internet uses a colossal amount of electricity. This electricity needs to be produced somewhere. In most countries, this means the burning of fossil fuels. This, in turn, means that the Internet’s carbon footprint has grown to the point where it may have eclipsed global air travel, and this makes the Internet the largest coal-fired machine on Earth.

The Mozilla Internet Health Report 2018 states that — especially as the Internet expands into new territory — “sustainability should be a bigger priority.” But as it stands, websites are growing ever more obese, which means that the energy demand of the Internet is continuing to grow exponentially.

All the while, the impacts of climate change grow worse and more numerous with each passing year. The vast majority of climate scientists attribute the increasing ferocity and frequency of extreme weather events around the world to climate change, which they largely attribute to human activity. While some question the science, even the world’s largest oil companies now accept it, and concede that their business models need to change.

Every country on Earth (with the exception of the US), is signed up to the Paris Climate Agreement. Although the US controversially pulled out, many of America’s most influential individuals, cities, states, and companies — representing more than half the US population and economy — have retained their commitment to the agreement by way of the America’s Pledge initiative.

As web developers, it’s understandable to feel that this is not an issue over which we have any influence, but this isn’t true. Many efforts are afoot to improve the situation on the web. The Green Web Foundation maintains an ever-growing database of web hosts who are either wholly powered by renewable energy or are at least committed to being carbon neutral. In 2013, A List Apart published Sustainable Web Design by James Christie. For the last three years, the SustainableUX conference has seen experts in web sustainability sharing their knowledge across an array of web-based disciplines.

Since 2009, Greenpeace has been putting pressure on big Internet companies to clean up their energy mix by way of their Clicking Clean campaign. Partly as a result of this campaign, Google announced last year that for the first time it had purchased enough renewable energy to match 100% of its global consumption for operations.

So, apart from powering servers with renewable energy, what else can web developers do about climate change?

“You Can’t Manage What You Can’t Measure”

Perhaps the biggest win when it comes to making websites more sustainable is that performance, user experience and sustainability are all neatly intertwined. The key metric for measuring the sustainability of a digital product is its energy usage. This includes the work done by the server, the client and the intermediary communications networks that transmit data between the two.

With that in mind, perhaps the first thing to consider is how do we measure the energy usage of our website? This is actually a trickier undertaking than you might imagine, and it’s difficult to get precise data here. There are, however, some good fallbacks which we can use that demonstrate energy usage. These include data transfer (i.e. how much data does the browser have to download to display your website) and resource usage of the hardware serving and receiving the website. An obvious metric here is CPU usage, but memory usage and other forms of data storage also play their part.

Data transfer is one thing that we can measure quite easily. All of the major browsers provide developer tools that allow us to measure network activity. In this screenshot below, for example, we can see that loading the Smashing Magazine website for the first time incurs just under a megabyte of data transfer. Firefox’s developer tools actually provide us with two numbers: the first is the uncompressed size of the files that have been transferred, and the latter is the compressed size.

The most common tool for compressing assets as they travel across the network is gzip, so the difference between those two numbers is typically a result of gzip’s work. This latter number represents how much data has actually been transmitted and is the one to keep an eye on.

Note: There are plenty of other tools that provide us with a metric for data transfer including the much revered WebPagetest.

For measuring CPU usage, Chrome provides us with a granular Task Manager that shows the memory footprint, CPU usage and network activity of individual tabs. For the more adventurous/technical, the top (table of processes) command provides similar metrics on most Unix-like operating systems such as macOS and Ubuntu. Generally speaking, we can also run the top command on any server to which we have shell access.

Fortunately, there are efforts such as WebsiteCarbon and Ecograder that seek to translate these metrics into a specific CO2 figure (in the case of WebsiteCarbon) or a score (in the case of Ecograder).

Sustainable Web Design

Now we know how to measure the impact of our site, it’s time to think about how we can optimize things to make it more sustainable, more performant, and generally a better experience to use.

There are some existing works we can draw on to help us here. In 2016, O’Reilly published “Designing For Sustainability” by Tim Frick. In this book, Tim takes us on a tour of the whys and hows of sustainable design. But we can also draw on a wealth of existing ideas, conference talks and articles which — while not having an explicit focus on sustainability — have a huge overlap with the philosophy of sustainable web design. Particularly good examples here are Brad Frost’s side-project, “Death To Bullshit”, Heydon Pickering’s articles and talks about writing less damn code, and Adam Silver’s blog post, “Designing For Actual Performance.”

If we’re doing a complete redesign of a website, or starting a new one from scratch, we can start with some really high-level questions here. For example, what actually deserves or needs to be on a homepage? And more specifically, what value does each element on a homepage bring? As Heydon Pickering puts it:

“The most performant, accessible and easily maintainable feature of a website is the one that you don’t make in the first place.”

I work on the WordPress.com VIP team, so in this vein, I decided to challenge myself by putting together a minimalist WordPress theme to see how far I could take the techniques of sustainable web design. The result is a theme called Susty, and it can be seen in action on the accompanying website I put together: sustywp.com. In that particular example, the website is delivered in just over 6KB of data transfer, which feels good given that the median website is about 1.5MB.

So, what did I do? Well, I’ll tell you.

Reduce Network Requests

As I have outlined above, network requests are something we can easily measure, so they make for a good starting point. In putting Susty together, I noticed there were a number of HTTP requests going on that didn’t appear to be necessary. For example, WordPress bundles some CSS and JavaScript that detects the usage of emojis and makes sure they don’t appear as illegal characters. There’s nothing inherently wrong with this, but if you aren’t planning to use emojis, or you’re happy and confident that the various system defaults will have you covered, you can prevent these from loading.

This represents a relatively meager saving, but by establishing a philosophy of pruning unwanted code and requests from our pages, we can make much more significant performance improvements. For example:

• Are we loading the whole of jQuery for some basic DOM operations?
  Could we achieve the same ends with pure JavaScript? You can read about more advanced dead code elimination (aka tree shaking) in this post for Google by Jeremy Wagner.
• Do we have a carousel of images?
  Do we really need all those images? Are they significantly enhancing the user experience? Or could we reduce it to just one, strong image? Or even randomly show one of a selection of images, to give a sense of dynamism to returning users? By the way, the research that has been done here shows that most users neither like nor engage with carousels.
• If we are using a lot of images, would we benefit from providing our images using the WebP format for those browsers that support it?
  For the longest time, WebP’s support has been frustratingly limited. But with Firefox due to begin support for it in version 65 (due in January 2019), it’s only a matter of time before remaining stragglers like Safari catch up.
• Are we loading hundreds of kilobytes of web fonts?
  Are we using all of the web fonts that we’re loading? Do we even need web fonts? Most devices these days have a stack of half-decent fonts, could we just specify a list of fonts we’d like to see arranged by preference? If we must use web fonts, we should make sure our fonts are as performant as is reasonably possible.
• Are we embedding YouTube videos?
  An embedded YouTube video typically adds about a megabyte of data transfer before anyone even interacts with it. If only a fraction of our users are actually going to sit and watch the embedded video on our website, could we just link to it instead?

Scrutinise Everything

In this vein, we can also interrogate every aspect of our pages. What really deserves to be there? Does our sidebar add any real value, or have we just put one there because convention dictates that websites have sidebars? So, we’ve added one and filled it with crap.

With Susty, I’ve experimented with the somewhat unorthodox approach of relegating the navigation to its own page. This allows me to have pages that are stripped down to literally the bare essentials, with additional content only being loaded at the user’s explicit request. Susty is so lightweight and so fast that I realized through some user research (aka my partner) that the loading of the menu didn’t really feel like a new page, so I decided to make it look like an overlay, with a cross to dismiss that actually just takes you back to the previous page.

As well as helping me to create pleasingly lightweight pages, the relegated navigation also removes the need for any fancy hide/reveal code for showing it. At this point, I’d like to make it clear that Susty is an example of taking sustainable web design techniques to an extreme (I’m not suggesting it’s an archetype of a good website).

Write CSS Like Your Grandmother

When it comes to serious performance enhancement, we should bear in mind that literally every character of code counts. Every character represents a byte, and even after they’ve been compressed by gzip, they’re still taking up weight. CSS is a domain where we often see a lot of bloat. Fortunately, there are a growing number of increasingly complex tools that can help you weed out unused CSS. This fantastic post by Sarah Dayan outlines how she reduced her CSS bundle from 259KB to 9KB!

If we’re starting from scratch, perhaps we should think more deeply about how we write CSS in the first place. Heydon Pickering wrote an excellent post about how we can write CSS in a way that plays to the strengths of how the syntax was designed, and how this can help developers prevent repetition. Heydon also points out how much wastage goes on with excessive usage of divs and classes — both in HTML and CSS.

What Are You Analyzing?

It seems to have become more-or-less ubiquitous on the web for everyone to analyze what their website’s visitors do via tools like Google Analytics, KISSmetrics, Piwik, etc. While I have no doubt that there are legitimate use cases, do we really need analytics on every website? I, for one, have typically added Google Analytics to every site I manage as a matter of course. But it dawned on me relatively recently that for most of the websites in question, this has been an almost completely pointless endeavor: “Oh, six people came to this post via Facebook today.” Who cares?

Unless you really need it, and you’re going to analyze and act upon the data, just ditch analytics and find a better way to spend your time than gawping at the mundanity of how many people visited website X today.

As well as adding to your page weight, usage of something like Google Analytics raises ethical questions around the data you’re collecting on your users on Google’s behalf, i.e. there’s a reason Google provides you with Analytics for free.

Let’s Not Forget The Basics

There’s so much information around these days about the following, but we should never get complacent and forget about them. Alongside everything above, we absolutely should always minify HTML, CSS, and JavaScript, and concatenate where appropriate. We should also compress all images to ensure they are as small as possible, use the right formats in the right settings, and use progressive rendering.

Server-Side Performance

So far, our focus has been almost entirely on the front-end, but a lot of this is made irrelevant if we don’t also optimize things on the server-side. I’ve already mentioned it a couple of times, but we should absolutely enable gzip compression at all times.

We should make serving our website as easy for our server as possible. I predominantly use Nginx, and I have a particular fondness for FastCGI cache and have found it to be especially efficient. If you have shell access to your own server, here’s a post that explains how to configure it. There are less technical options if you don’t have (or don’t want) as much control over your server. A particular favorite in the WordPress space is WP Super Cache.

We should use HTTP2 over HTTPS. Using HTTPS opens up a world of new web technologies like service workers that allow us to treat the network itself as a nice-to-have. If you want to learn more about this, I highly recommend Jeremy Keith’s new book, “Going Offline.”

Note: You also may want to investigate Google’s PageSpeed Module, available for both Apache and Nginx.

Finally, the biggest impact we can have here is to host our websites in data centers powered by renewable energy. In the UK, I can highly recommend Krystal and Kualo in terms of companies with which I directly host my sites. (For a full directory of green web hosts, check out The Green Web Foundation.)

In Conclusion

I hope I have convinced you that it’s worth putting in the effort to make our websites more sustainable. Especially given that in the process we also make our websites:

• More performant,
• More user-friendly,
• More accessible,
• More server-friendly,
• Better optimized for search engines.

A response that some people have to the idea of sustainable web design — which is not unreasonable — is that it seems to be a very small concession to the environmental cause. Of course, how much of an impact you can have depends on how busy the websites are that you work on. But as well as helping the web become a bit more environmentally friendly, sustainable web design is fundamentally best practice web design.

It’s also worth thinking about offsetting the carbon emissions that you can’t avoid. Carbon offsetting is sometimes derided, and with good cause. The main problem with offsetting is that typically the term over which carbon will be offset is quite long. For example, with tree planting, the figure given for an amount of carbon sequestering is typically based over a 100-year period. So, in terms of reducing carbon emissions now, it’s not really a solution. But it is better than nothing.

The motto of myclimate is to do your best, and offset the rest. I highly recommend the 1% For The Planet initiative. Finally, if you are a business owner and would like to join an alliance of companies that want to see better social, environmental and economic justice, check out the Certified B Corporation scheme.

Further Reading

• Modern Methods For Improving Drupal’s Largest Contentful Paint Core Web Vital
• How To Monitor And Optimize Google Core Web Vitals
• Reporting Core Web Vitals With The Performance API
• Thoughts On Markdown

(ra, il, mrn)