His solution was to separate thinking from doing, cleanly and completely. Management would plan the work – the optimal method, the optimal pace, the correct tool for each task. Workers would execute it. He called it scientific management, and over the following decades, it became the template for how industrial organisations structured almost everything they did.

Nobody planned for it to also become the template for digital product teams. But when the first agencies and studios needed a process, they borrowed from what existed. And what existed was the industrial model. Plan. Design. Produce. One phase hands off to the next. The designers design; then the engineers build. A specification travels one way, downstream, and something is produced at the other end.

The only problem is that building complex digital products is nothing like shovelling pig iron more efficiently at Bethlehem Steel. Yet over a hundred and twenty years later, most of us are still running product teams on a model that was designed for a problem we don’t have.

Two Lenses

I’ve been in the meeting where this model starts to show its seams more times than I can count – on the design side, the engineering side, and also in the middle where you can see exactly what both people mean and why they still can’t hear each other.

A designer walks the team through a carefully designed flow. The layouts are balanced, the visual language holds together, and all the interactions make sense. About four screens in, however, an engineer leans back and says: “That’s going to be complicated.”

The designer asks why. What follows is one of those conversations where both people are clearly smart, clearly well-intentioned, yet somehow still unable to land in the same place. The engineer explains the constraint. The designer reframes the intent. The engineer nods. But not quite in agreement – more in the way people nod when they’ve decided to resolve something later, “offline.” The meeting ends.

Two weeks later, when the feature ships, it works. Technically. But something got lost between what was designed and what was built. It isn’t wrong, exactly. But it also isn’t quite right.

If you’ve seen this pattern enough times, you might be tempted to call it a communication problem. I used to think that, too. Better specs, more detailed annotations, clearer handoff documentation – and the gap would close. But the gap never closed. Because it isn’t only a communication problem. It’s a mental model problem. And the distinction matters, because the fix for one is a better process, and the fix for the other is something fundamentally deeper.

Designers and engineers are not only trained differently. They think about the same product through genuinely different lenses – each one invaluable, but also incomplete on its own.

A designer looks at a screen and sees composition, hierarchy, and intention. They’re thinking about what a user needs to feel and understand at a particular moment. They hold the whole experience in their head as a kind of narrative: the user arrives here, notices this, does that, and feels – ideally – how the product understands them. Design is about managing perception and guiding attention through space and time.

An engineer looks at the same screen and sees structure, state, logic, and constraints. They’re thinking about what happens when the data doesn’t arrive, when the user does something unexpected, when the component needs to work in a dozen different contexts simultaneously. Engineering is about managing complexity and building things that hold up under the pressure of reality.

Neither lens is wrong. Both are necessary. But they produce different vocabularies, different intuitions, and – crucially – different instincts about what the right question even is.

When a designer says “make it feel lighter,” they have something precise in mind: less visual weight, more breathing room, perhaps a subtle change in transition timing. When an engineer hears “make it feel lighter,” they hear an instruction with no acceptance criteria. What does done look like? The designer isn’t being vague. The engineer isn’t being obstructive. They’re speaking different native languages and assuming, very often incorrectly, that they share one.

Productive Friction

Here’s the thing, though: this tension, by itself, is not the problem. In the right conditions, it’s actually one of the most valuable assets a team has.

Because designers and engineers don’t have the same blind spots. They have complementary ones. A designer optimising for perception and narrative can miss structural fragility – the interaction that feels wonderful but buckles under real-world data. An engineer optimising for robustness can miss experiential quality – the error state that handles every edge case correctly but leaves the user feeling abandoned. When those two lenses collide early enough, each one catches what the other would miss. Quality goes up because the team is running two different threat-detection systems at once.

But it goes further than that. When both disciplines stay in dialogue, constraints from one domain become creative inputs for the other. Take the “make it feel lighter” conversation again: if the designer and the engineer actually sit down together, the engineer might say, “I can’t reduce the weight of that component without breaking the layout in three other places – but what if we changed the transition timing instead?” And suddenly there’s a solution that is both structurally sound and perceptually better than what the designer originally had in mind. The constraint didn’t limit the design. It redirected it somewhere more interesting. This is what working with a material feels like: the material pushes back, and the pushback makes the work better.

And the negotiation itself has value. When a designer has to explain why something should feel lighter – not in aesthetic terms but in terms of what the user needs to experience at that moment – the thinking gets sharper. When an engineer has to explain why something is complicated – not in jargon but in terms of what the system is actually doing – the architecture gets clearer. The friction is a forcing function for clarity on both sides. As Dave Rupert recently put it, people are not friction – but friction is where good work gets its shape.

Two incomplete lenses, brought together early enough and often enough, produce something richer than either would alone. A designer who learns to anticipate structural constraints starts making better decisions. An engineer who learns to see compositional intent starts building with more sensitivity. Given enough shared time and enough feedback loops, the two perspectives don’t merely coexist. They teach each other.

The question is whether the process gives them that chance.

The Fault Line

In most teams, it doesn’t. And this is where Taylor’s inheritance does its real damage.

A sequential process – where design finishes before engineering begins, and a specification is the primary bridge between them – does something that is quietly destructive: it takes a manageable cognitive difference and makes it catastrophic. Not by creating the tension between the two lenses, but by removing every mechanism that could make that tension productive. In a sequential process, there’s no shared material to point at. No immediate feedback when a design decision collides with a technical constraint. No moment where the engineer’s question reshapes the designer’s thinking in real time, or where the designer’s intent becomes visible to the engineer before it’s cast into a deliverable.

What remains is translation. And translation always loses something.

And so, every time a decision falls into the space between design and engineering, it gets made by whoever happens to be closest to it at that moment. An engineer makes a spacing decision because the specification wasn’t precise enough. A designer overrides a component behaviour in a mockup without realising that it is load-bearing elsewhere in the system. A product manager resolves the disagreement by picking whichever option is faster to ship this sprint.

These small, local decisions accumulate. The built product drifts from the design intent. The codebase drifts from the design system. And eventually, the team is looking at something that technically works but feels like it was assembled from parts that weren’t quite designed to fit together. Because, in a very real sense, it was.

The problem isn’t that people are making bad decisions. (Although we also do that at times.) It’s that the decisions are happening in the wrong place, by people working without full context, in territory they don’t feel entirely responsible for or comfortable in. Nobody put them there deliberately. It’s just what happens naturally when two disciplines work in sequence, each doing their best with what they’ve been handed.

And the conventional response – better tooling – doesn’t change this. Zeplin, Figma’s developer mode, Storybook, design tokens, and other tooling around design systems: these are genuinely useful things and I’m glad they exist. They reduce friction at the moment of transfer and provide helpful guardrails. But they make translation more efficient without questioning whether translation is the right model in the first place. The constraints that engineers understand deeply – what the browser actually does, how a component degrades at unexpected viewport sizes, what happens to the layout when real content is three times longer than the copy in the mockup, or what is now possible with the new CSS – these things still don’t flow back upstream until it’s too expensive to act on them.

What teams need isn’t a better handoff process. They need fewer handoffs. And they need to address both sides of the problem: the structural process gap and the cognitive perception gap.

Working in the Material

The structural gap – the one Taylor’s model created – needs a structural fix. And the most effective one I know is also the most direct: bring design decisions into contact with the actual material as early as possible.

In 2015, Frank Chimero gave a talk at Webstock called The Web’s Grain and asked a question that I’ve returned to many times since:

When design decisions are made in tools that have no concept of state, of time, of viewport, of the real unpredictability of content, you stop designing for the Web. You design a fiction of the Web. And then you hand that fiction to engineers, who absorb in the process all the compromises and assumptions that were hidden inside the original fiction.

Prototyping in the browser changes this – something I’ve written about at length before and which I’m more convinced of than ever. The browser isn’t only where the product ends up. It’s a place to explore ideas and test them. It’s a place to discover edge cases before they become engineering surprises. It’s a place to shape your design directly with the real material: the web platform with all its inherent flexibility and unpredictability. When design decisions are made in the medium where they’ll live, you encounter immediately what the platform supports and what it doesn’t. This is what Jeremy Keith calls declarative design – designing with the grain of the medium rather than imposing control over it. And the products that come out of this process are better for it. They’re more resilient, more accessible, more performant, because the constraints that shape those qualities were present from the start, not discovered after the fact.

But here’s what prototyping alone doesn’t solve: it addresses the process gap – the lack of a shared material, the absence of feedback loops – but not fully the perception gap. You can put a designer and an engineer in front of the same browser window and they will learn from each other’s perspectives. But they will still, to some extent, see different things. The lenses don’t merge all of a sudden just because the medium is shared.

For that, you need something more.

The Artist Who Builds

In 1919, twenty-one years after Taylor arrived at Bethlehem Steel, an architect named Walter Gropius founded a school in Weimar, Germany, that was built on a deliberate refusal of everything Taylor stood for.

The Bauhaus didn’t separate the person who designed something from the person who knew how to make it. There were no handoffs. Artists and craftspeople learned together, thought together, built together, each one expected to understand both the vision and the material. Gropius wrote:

That ideal was largely lost in the industrialised world. We got Taylor’s model instead, because we craved efficiency, and separating planning from execution looked efficient – at least on a stopwatch. But Gropius understood something Taylor didn’t: the best work happens not when thinking and doing are separated, but when they can’t be pulled apart. When the person shaping the vision also feels the resistance of the material. When understanding how something is made changes your idea of what it should be.

I’ve felt this in my own work for years. When I design a layout, I’m already thinking about how the CSS will behave when the viewport narrows and what happens to the rhythm when real content replaces the placeholder text. When I write CSS, I’m not transcribing someone else’s vision – I’m making design decisions in real time, adjusting spacing and proportion and timing based on what the browser is actually showing me. These aren’t two separate activities that I switch between. They’re the same activity seen from two angles simultaneously. And the decisions I make as a result are different – and better – than the ones I’d make if I only held one lens.

But it’s not only that the work gets more coherent. Working at the intersection of both disciplines also lets you see possibilities that neither one would reveal on its own. A designer who understands what CSS Grid and container queries can do will imagine layouts that a designer working only in Figma would never conceive of. An engineer who feels compositional intent will reach for a scroll-driven animation or a view transition that a pure engineering mindset wouldn’t prioritise. These aren’t better compromises. They’re ideas that couldn’t have existed without both perspectives being present at once.

This is what the design engineering role actually is, at its best. Not a designer who codes or an engineer who has taste, but someone who holds both lenses at once and can think compositionally and structurally in the same moment. Someone who doesn’t translate between design and engineering for the Web because there’s nothing to translate – the understanding is native to both.

When that person, a web design engineer, exists on a team, something shifts. The gap between design intent and built reality doesn’t need to be managed with better specifications or smoother handoff tools. It doesn’t form in the same way, because the decisions that would normally fall into that gap are being made by someone with context on both sides. The cognitive difference between the two disciplines – the one that’s real and valuable and never going away – finally has a place where it’s held together rather than split apart.

The web design engineer is, in a very real sense, Gropius’s ideal brought to the Web. The artist who builds. The thinker who makes. The person for whom design and engineering are not sequential phases but a single, continuous act of judgment.

And judgment, more than anything, is what we need.

In a world where AI can increasingly handle execution – writing the boilerplate, generating the component scaffolding, shovelling the pig iron, if you will – what matters most is exactly what the sequential model suppresses: the ability to see both the composition and the constraint simultaneously, to make decisions that are aesthetically sensitive and structurally sound, to develop the kind of cross-disciplinary taste that no specification can encode and no amount of tooling can automate. The interdisciplinary mind isn’t a nice-to-have anymore. It’s the capability that matters most, precisely because it’s the one machines can’t replicate.

Who Owns This Space?

I don’t want to make this sound like a problem with a simple solution. It isn’t. Otherwise it wouldn’t persist. Organisations are complex, teams have histories, and the design-engineering relationship often carries a lot of accumulated tension.

But it’s worth being honest about where that tension comes from. It comes from a structural assumption – that design and engineering are sequential activities, that one finishes before the other begins, and that what passes between them is a specification rather than a conversation. And it’s amplified by a cognitive reality – that the two disciplines are trained and see differently, and that without shared time, shared material, and shared language, those differences compound into drift.

The structural problem needs a structural fix: work in the real material, prototype in the browser, make design decisions where they’ll actually live. The cognitive problem needs a different kind of fix: build shared vocabulary, learn from each other, invest in people who carry context across both worlds, create roles where design and engineering aren’t phases but perspectives held by the same mind. Ideally, you address both.

The question worth asking is: in your team, who owns the space between design intent and built reality? Who is responsible for making sure that what gets designed is what gets built – and that it’s built for the actual Web, with all its variability, its real content, its real constraints, and its real humans?

When you have a real answer to that – a name, a role, a shared commitment – you see the difference in the product. Fewer bugs. Better performance. Stronger accessibility. Less money wasted on rework that shouldn’t have been necessary in the first place. And, most importantly, better experiences for the people who use what you build.

Taylor separated thinking from doing because he believed the separation made the work better. Gropius reunited them because he understood it made the work whole. On the Web, we get to choose which model we build on. The material is right there and the distance between an idea and a working thing has never been smaller. The person shaping the vision can also be the person feeling the resistance of the material. The one who imagines the layout can be the one who writes the CSS. Maybe that’s how building things for the Web was always meant to be.

Design and engineering, as one.

❦

“Hey, hope you’re doing well!

I was going to link to something of yours for an article I’m writing for Piccalilli, but I keep getting a “This site can’t be reached” error in Chrome. I tried in Firefox, and it’s saying it can’t establish a secure connection... Andy just left a comment saying it’s working for him, so it might be a regional thing? I have no idea.”

Wait. My site is down?

I switch into the browser and load the site. It’s fine. I hit refresh. Still fine. I pick up my phone and load the site there. Also fine. I feel a little lift of relief, followed immediately by confusion: If my site is down for Kevin but not for me, something’s definitely not right. Maybe it really is a regional thing?

So, I do what any legitimate web person does when confronted with a problem: I throw technology at it. VPN time! I connect through Canada, because that’s where Kevin is based, and sure enough – my website doesn’t load. And I get the same results checking availability through check-host.net from a bunch of other locations: Brazil, Czechia, Hong Kong, India, Japan, and the Netherlands all fail to load the site, for instance.

After a few emails back and forth with my shared hosting provider all-inkl.com the issue is identified: they’ve indeed installed a filter that blocks entire countries from accessing my site. Without telling me. They just decided on their own that the best solution to whatever was happening was geographic surgery. “Your website is being accessed permanently and en masse. This is presumably a DDoS attack,” they wrote. “We have installed a filter that only allows access from certain countries so that we can protect the server from overload.”

An Alien Invasion

A DDoS attack? A botnet trying to hammer my server into submission? Really? I look at the access logs. No, this is something different. This is methodical. Millions (!) of requests over a couple of days from things with User-Agent strings reading GPTBot, OAI-Searchbot, Claude-SearchBot, or Meta-ExternalAgent, plus a whole bunch of IP addresses from Singapore, Shenzhen, and other parts of Asia scanning my articles and notes sections. That’s not a botnet DDoS attack. That’s an LLM bot “attack” by OpenAI, Meta, Anthropic, and many others.

In their hunger for data to train their large language models, companies from all over the world are systematically harvesting every word I’ve ever published, feeding it into their language models to keep them fresh – and the side effect, the collateral damage, is that Kevin in Montreal now can’t read my articles because my hosting provider decided the solution was to block Canada and half the rest of the world.

I sat there staring at those logs for a while. The irony wasn’t lost on me. This is my little corner of the web. My writing. With my weird little style mixer up there in the top right. And now it is simultaneously being strip-mined by AI companies and effectively made inaccessible to actual humans around the world who might want to read it.

This is where we are in 2026. There’s something happening on the Web at the moment that almost feels like watching that old arcade game Space Invaders play out across our servers. Bots and scrapers marching in formation, attacking our servers wave after wave, systematically requesting page after page, relentlessly filling their data stores while we watch our access logs fill up.

The webspace invaders have arrived.

And the numbers are staggering. About 50 percent of web traffic is now coming from non-humans. Bots, crawlers, and agents are constantly moving across our servers in search for new pieces of content to absorb and while search engine crawlers are still the highest traffic bot category, AI/LLM bot traffic is constantly surging, with AI training being the main crawl purpose. According to Cloudflare’s 2025 Year in Review report, AI bots originated 4.2 % of HTML requests. But this number excludes Googlebot, which crawls for both search indexing and AI training, and averaged at 4.5 % of requests. Yes, according to Cloudflare, Google’s crawl volume is still bigger than all other AI crawlers combined. And in some months of 2025, the numbers were even more extreme. Take April 26, 2025, for example: on that day, human traffic only accounted for 34.5 % of HTTP requests worldwide. AI bots came in at 4.1 %. A number that is already high on its own but is being dwarfed by Googlebot with a whopping 11 % of HTTP requests. I repeat: 11 % of HTTP requests worldwide coming from Googlebot alone. The rest of “Non-AI” bots averaged at 50.1 % of requests that day. And this number might still include a fair amount of LLM training bots that hide behind fake User-Agent strings.

The Open Web Subsidizing Big AI?

Here’s the thing about running a personal site on modest hosting, the kind of hosting most of us are on: you notice when things change. The big platforms, they can absorb all this additional traffic without blinking. They have CDNs and server farms and maybe even entire teams of people thinking about handling bot traffic.

But me? I’m running a simple setup. A Craft CMS site on shared hosting, some static files here and there, nothing fancy. Just like the majority of people with a personal site or a blog. And suddenly, I’m getting hammered with enough traffic that my hosting provider is implementing emergency measures. And I’m not the only one. Just recently, Remy did not only notice unusual spikes of traffic on his blog, but his project JS Bin was hit so hard by massive spikes in network inbound traffic that he was struggling to keep the site online. As Jeremy mentioned, The Wikimedia Foundation is also seeing unprecedented amounts of traffic generated by scraper bots. While humans tend to browse with intention, those AI crawlers “binge read” indiscriminately and visit also the less popular pages. 65 % of this resource-consuming traffic they get for Wikipedia is now coming from bots.

And when I asked on Mastodon and Bluesky, plenty of people chimed in. Turns out I’m really not alone. People are seeing the same pattern on their own sites – often serious enough that they’ve had to take action. There’s even a classic tell at the moment: waves of “users” visiting from Singapore with suspiciously old Chrome User-Agent strings.

There’s a power imbalance at work here that’s hard to ignore. Large “AI” companies, the ones with billions in venture capital, send their bots to harvest free content. Not only from big publishers or Wikipedia, but from small, independent websites, too. But we, the people running these sites – often as passion projects, as ways to freely share what we’ve learned, as digital gardens we tend in our spare time – we’re the ones paying for the bandwidth and server resources to handle all those additional requests while those companies profit from the training data they extract. It’s an asymmetric battle: small systems absorbing the demands generated at an entirely different, industrial scale.

These companies might not be plotting evil, but they’re externalizing their costs and aren’t particularly concerned about the collateral damage. Sure, some still provide robots.txt compliance. They’ve published documentation about their crawlers, albeit often incomplete. But even compliance and documentation won’t change the fundamental math: when you have dozens – no hundreds, soon thousands of companies (just look at the download counts on Hugging Face for any popular model), each running their own scrapers, each one binge-reading your site not once every two weeks like earlier versions of Googlebot used to do, but several times a day, the aggregate effect can quickly overwhelm a small site. And as long as the training data keeps flowing and the models keep improving, why would they change anything?

Good Bot, Bad Bot

Alright, it’s bad, obviously. But things get even messier. In Space Invaders, the aliens followed predictable patterns. You could learn their behavior, anticipate their movements, and develop strategies to play the game longer and score higher. The game we’re playing on the Web now? It’s unpredictable.

Because on the Web, we’re now playing against adaptable opponents. Scrapers from Singapore that hide behind spoofed User-Agent strings, in an attempt to appear as though they are a real browser, instead of identifying themselves honestly. Scrapers that change their IP addresses regularly. Scrapers that obviously don’t give a penny about your cute robots.txt. Scrapers that obviously don’t care about the gentleman’s agreement that the web was built upon.

And we’re just entering the next phase. Agentic AI. Systems that can autonomously explore websites, adapt their scraping strategies based on what defenses they encounter, rotate IP addresses, work around rate limiting. The bots are getting smarter by the minute. More persistent. More capable of treating every attempt to protect our sites as a new puzzle to solve.

This isn’t Space Invaders anymore. Those aliens invading our webspaces are locking on and firing relentlessly, constantly adapting, learning, and getting stronger. And here I am – one human with a keyboard – trying to keep my site accessible to other real humans while it is being harvested and under fire from all directions.

And to cap it all, all of this is happening against a backdrop of genuine geopolitical competition where training data for large language models is being seen as strategic infrastructure. The countries and companies that control the best AI models are said to have real future advantages – economically, militarily, politically. This transforms web scraping from an annoyance into something that’s part of a much larger power struggle. Chinese AI companies might not be that concerned about conventions around robots.txt or polite crawling. But honestly, American AI companies are under pressure to maintain their lead, and when prioritizing growth over everyone else in your path is the business model, they’re perfectly willing to cut corners, too. Everyone’s racing, and the open web looks like free resources up for grabs. The result is that my personal blog – your personal blog – becomes collateral damage in this competition. The scrapers don’t care that you’re not Facebook or the New York Times. Your content is data. Data is valuable. And in this race, the externality of overwhelming small site owners is just the cost of doing business.

“Just Use Cloudflare”

So naturally, there’s a corporate solution being offered. Cloudflare, with its massive network infrastructure, provides (free) AI bot protection now. You add some DNS entries, flip a switch in the Cloudflare dashboard, and let their systems handle the AI crawler traffic for you.

And from what I hear, it works fairly well. Cloudflare can identify and block malicious scrapers at a scale that individual site owners simply cannot. They can distinguish between real browsers and bots masquerading as browsers. They have the data, the machine learning models, the infrastructure, and the threat intelligence.

But I keep coming back to this question: should we all need to route our traffic through Cloudflare? Is that really the sustainable solution to the webspace invaders problem? Is that really the open, independent web we want?

Because here’s the thing: Cloudflare already sees an enormous percentage of web traffic. They’re a neutral actor now. But power structures change. Companies change. Countries and their governments change. Obviously. Every time we centralize infrastructure in response to a threat, we make the web a little less distributed, a little less resilient, and a little less ours. And we all saw last year what happens when half of the web relies on just one single point of failure. Within just one month, Cloudflare experienced two major outages: a global outage on November 18, 2025 took down roughly one in five webpages globally at the height of the incident, and one-third of the world’s 10,000 most popular websites, apps, and services, according to some estimates. Another significant incident occured on December 5 while Cloudflare attempted to detect and mitigate an industry-wide vulnerability in React Server Components.

I sat with all this for a while, trying to figure out how I felt about it and what to do with it. On one hand, I don’t have the time or expertise to run sophisticated bot detection on my own. I have a day job. I have a life and a family. The idea of spending weekends maintaining IP blocklists and analyzing traffic patterns is exhausting just to think about.

On the other hand, every small site owner routing through Cloudflare means more consolidation, more centralization, more of the web’s infrastructure dependent on a single company’s good intentions and continued solvency.

I don’t have a good answer here. I really don’t. It’s one of those problems where all the solutions feel inadequate, somehow.

Still, I decided to give it one last try. And so, I spent the last few weeks moving my site from my shared hosting plan over to a virtual private server (VPS) where I have more control over the protection layers of my site and where nobody can add a country filter without my knowledge. I’ll write more about other aspects of the setup in future posts.

Activating Your Site Shields

But for now, let’s look at a few practical ways to fight back against those webspace invaders. Because although the bots and agents are getting smarter by the minute, there is still a lot we can do to better protect our sites and hosting bills.

You, Robot?

The first step (still) is to start with robots.txt, even though this won’t stop them all. Create a robots.txt file in your web root if you don’t have one yet, and then explicitly disallow known AI scrapers of your choice:

If you want to go further, you can block wide whole range of known LLM bots with a list like the one at ai.robots.txt or even serve a robots.txt that continuously updates via Known Agents (formerly known as Dark Visitors – interesting name change, by the way). It’s not a complete solution, but it’s a starting point that takes a few minutes to set up.

However, using robots.txt will only work for the actors that actually honour this convention. If a crawler decides to ignore your robots.txt, nothing will stop it. That’s why a lot of people, just like Ethan, have also started blocking bots via .htaccess.

For my new VPS setup, I now use nginx to serve my site. And so, instead of using .htaccess, which does only exist on Apache, I added a user agent check to the nginx config instead, similar to the one you can find in the ai.robots.txt repo:

If the User-Agent string matches that of one of the bots on the list, the server now returns a 403 Forbidden status code and blocks the request. In case you're running an Eleventy blog on nginx, Robb has written about a similar approach he is using to block bots on his site.

One important note, though: if you want to still allow the Internet Archive to archive your site, which you should, make sure to not block their archive-org_bot – like I did at first. ;)

Rate Limiting

If you control your server configuration, rate limiting also becomes essential. Real humans very rarely request fifty pages per second. But aggressive scrapers definitely do. Therefore, putting a cap on how often someone can repeat an action within a certain timeframe can help stop malicious bot activity and reduce strain on your server. If you’re on nginx, look into limit_req_zone and limit_req, as explained in this post on the nginx blog. Apache has mod_ratelimit.

The tricky part is setting the right thresholds. Too strict and you risk blocking legitimate users or search engines. Too loose and the scrapers slip through easily. I’ve been experimenting with this, and honestly, it’s been a lot of trial and error and I’m still not 100 % sure if my settings are ideal. The general advice is to conservative – maybe 5 to 10 requests per second per IP – and adjust based on what you see in your logs.

My own setup, which complements the nginx config setup above, now distinguishes between three tiers of visitors based on User-Agent strings: the most aggressive bots and crawlers are blocked immediately, less aggressive crawlers – those that respect robots.txt – and user-initiated AI searches are moderately throttled, while everyone else (presumably humans, I hope, I’m still very hopeful, I guess) falls into the least restrictive tier. Using IP addresses would strengthen this approach even further, since, as we know, malicious actors will spoof their User-Agent strings. But for now, this additional rate limiting layer should help catch another significant number of aggressive invaders and cut off the peaks.

Monitoring Your Access Logs

I know, it sounds tedious. And it is. But you need to know what’s actually hitting your site. And means looking into the access logs of your server or webspace, not just your analytics dashboard. Because tools like Fathom or Plausible will only tell you half of the story. They apply their own filters to keep your analytics clean and bot-free, which is great for understanding human visitors. But that also means that there is no way around looking at your raw logs.

I recently spent hours going through mine, identifying the IPs with the most traffic and blocking them manually as a first, probably a bit unsustainable counter-measure. But it helped me to understand the problem better – and also to check whether my actions actually had an effect.

Tools like GoAccess can be super helpful for this, because they give you real-time insights and even let you set up alerts for unusual traffic spikes. Because ideally, you want to know when something weird is happening, not discover it three days later when your hosting provider has already implemented their own “solution.” This goes double for client sites.

Using IP Blocklists

IP blocklists are part of any solid firewall setup, but you need to be thoughtful about it. There are well‑established resources that publish lists of IP addresses of known scraping networks, exploiters, spam sources, and other malicious actors – data centers that legitimate traffic would never come from. Useful resources include AbuseIPDB, Spamhaus’s Don’t Route Or Peer Lists (DROP), blocklist.de, or All Cybercrime IP Feeds by FireHOL.

You can then block those IPs with a firewall like Linux’s iptables via ipset. This, however, requires ongoing maintenance because those lists need updating. There are ways to configure your server so that the lists get updated automatically. In my case, I am now using Hestia Control Panel on my server, which makes configuring iptables a bit more comfortable when blocking individual IPs or whole blacklists. But you should still be very careful to not block legitimate traffic or even yourself. It is all about finding the most trustworthy lists and not being overly aggressive. And again, watching your logs.

Poisoning Well

For the really aggressive invaders, especially if you’re concerned about LLM scrapers harvesting your content without consent, effectively violating your copyright, there’s another approach: serve different content to suspected bots, or as Heydon put it, poison the well, actually. Feed them garbage data. It won’t stop the bandwidth drain, but it does something about the copyright violation.

WAFs: Blocking the Baddest Baddies

The final layer of protection would be to install a web application firewall (WAF) that includes bot protection. Open-source tools like BunkerWeb, SafeLine, or the really interesting Anubis provide multi-layered defense against bot attacks through CAPTCHA verification or other challenges, dynamic protection, and anti-replay protection. They are basically an additional layer (a reverse-proxy) between your app or website and the internet that only lets the good traffic through.

But the bigger you make the concrete walls around your digital garden, the more likely it might also have negative consequences. You might block legitimate crawlers. You might hurt your accessibility and block real humans. And you might spend hours installing and maintaining systems that break in weird ways. To me personally, tools that put a challenge in front of real humans still feel a bit like admitting defeat.

So I haven’t yet tried Anubis, for example – although it might well be the best way to really get rid of the crawlers. But I’ll definitely keep exploring this space and try out this and other tools, now that I have my own virtual private personal website server.

The Web We Wanted

We built the web on optimistic assumptions. We assumed good faith. We assumed people would respect robots.txt because we all understood we were building something great together. We created these protocols and conventions because we believed in mutual respect and shared purpose. The Web was supposed to be for everyone.

But when training data becomes worth billions of dollars, when AI capabilities determine who wins and loses in global economic competition, when scraping is a strategic commercial activity, then those assumptions break down.

Part of me wants to believe that we can still maintain an open web without surrendering to corporate infrastructure or turning every website into a defensive fortress shooting webspace invaders. Part of me wants to believe that international cooperation could establish better norms over time and that the companies building these AI systems will take responsibility for the externalities they’re creating. (Haha.)

But I’m now also old enough to be an optimistic realist. I’m watching my access logs, I’m watching the arms race escalate, and I’m wondering how long places like mine can hold out. How long before every personal website needs enterprise-level protection just to function? How long before the cost of publishing your thoughts online becomes prohibitive for regular people? For some, it might be already.

It feels like we might soon be forced to choose between accessibility and survival. Between openness and sustainability. Between our ideals about what the web should be and the practical reality of keeping our sites online.

An Infinite Game

Stories like mine are now probably happening to more small site owners everywhere. Many of them might not even know why their hosting bills are climbing or why their sites are suddenly down in certain countries. And once they find out, many of them might not be able or willing to set up a VPS and spend hours fiddling with server logs, firewalls, blocklists, and nginx config files.

Yes, the AI companies need to do better. They actually should throttle their scraping to reasonable levels. They actually should respect the limited resources of small sites. They actually should develop industry standards that don’t externalize costs onto individuals who are just trying to share their work. This might even be in their best interest, because ultimately, they also risk destroying the very ecosystem they depend on – after all, what will their LLMs learn from when the independent web has been scraped into extinction? But I’m also not holding my breath for voluntary restraint when there are billions of dollars at stake. In the end, it is also on us to adapt to this new reality – clear-eyed and pragmatic.

So what do we do? We document what’s happening. We block scrapers. We move to better, more capable servers. We share our approaches and learn from each other. We push for better standards and regulations where we can. We make noise about the problem instead of suffering silently. Because this is the Open Web and and the Web was designed so that we can still do all that. That’s the magic of it.

I for one am not giving up my little corner on the Web, of course. I'll continue to document and write about that journey that is my personal website. Over the coming weeks, I will share my experiences with my new VPS setup – how I configured the server, how I set up my continuous deployment pipeline for Craft CMS (yes, I have that now, Manuel! 😉), how I configured caching and other performance improvements, and I’ll also finally write more about the redesign and CSS of my site. Because that’s what our little corners on the Web are all about. That’s what the personal website verse is all about. And that’s what we are trying to protect here.

So, if you’re running a website, check your logs. Set up some basic protections. Share what you find. Be part of this conversation. Write about the future you want. Because the alternative is watching the independent web getting scraped into oblivion while we all wonder what happened to the Web we loved.

Here’s the thing about Space Invaders, the game: it didn’t end when the aliens reached the bottom. It just started over, harder and faster. Maybe that’s where we are now. It’s not game over. Not yet. Just the next level. And we need to get better at playing it.

👾👾👾

What has your experience been with AI scrapers? Have you found approaches that work? Have you “given up” or moved to Cloudflare? I’m genuinely curious what’s happening in your corner of the Web, because I suspect we’re all dealing with variations of the same problem. So let me know via Webmention, Mastodon, Bluesky, email, or maybe even in a response blog post.

What started out as the most promising development in the history of the Web – the participation of users in the creation of content and online dialogue at scale – has turned into a swamp of sensation, lies, hate speech, harassment, and noise.

Your Unfriendly Neighborhood

Craving for attention and engagement, our timelines have changed. Algorithms now prioritize content from people with a huge following and everything that is loud and outrageous. It’s all about what the masses and the bots “want”, what they will like, share, and click. This strategy might be driving sales of ads because traditional online marketers are obsessed with quantity and it is – besides selling user data – the only answer they found for venture capital constantly demanding a bang for the buck. Yet it leads to an experience that is so often just more of the same and at the same time much less predictable, less organic, and less adjustable to your own preferences. As Craig Mod writes, “social networks seem more and more to say: You don’t know what you want, but we do.”

Consequently, it has become substantially harder for people with a small to medium following to get their voices heard and find a practical and creative use for services like Twitter or Medium. Twitter, for example, used to be that place where you would meet nice and brilliant people from the web community and make new friends, where you could find and share ideas and inspiration. But Twitter has changed so drastically and I’ve seen so many people turning quiet or leaving completely, that I don’t know how long this journey will continue. As with so many technologies before, the initial hopeful enthusiasm that accompanied the rise of social media has given way to disillusionment.

One day, Twitter and other publishing platforms like Facebook, Instagram, or Medium will indeed die, like so many sites before them. And every time this happens, we lose most of the content we created and with it a fair amount of our collective cultural history.

Data loss isn’t our only problem, though. If you decide to publish your work on a platform like Medium, you’re giving away control over it. What if Medium suddenly decided to extend the already existing paywall to all articles? There’s not much you could do about it. Simply because you don’t own your content anymore.

Maybe this wouldn’t be a big issue if owning your content today wasn’t more important than ever. Especially, but not only, if you are working as an independent or freelancer, your content is not just something you happen to have created – and for which you own the copyright of, by the way – but it is also part of your identity. It is part of who you are, what you’re thinking about, what you believe in, and what you’re up to. It is part of the story you are about to tell. It is part of the change you seek to make. Your content is one of your most valuable assets and thus owning it is invaluable.

So it comes as no surprise that more and more people are looking for alternatives. Not only for alternatives to Twitter or Medium per se but to the way social media currently works in general. Many are craving for more control, less noise, and for having more real and meaningful conversations again.

Homecoming

There is one alternative to social media sites and publishing platforms that has been around since the early, innocent days of the web. It is an alternative that provides immense freedom and control: The personal website. It’s a place to write, create, and share whatever you like, without the need to ask for anyone’s permission. It is also the perfect place to explore and try new things, because, as Seth Godin likes to say, we now live in a world of “unlimited bowling”. It is totally up to you what you create and because you have unlimited shots on the Web, you can try out different formats, different styles, different topics. Regardless of what other people might think and although it might not work. Creation is free.

A personal website is also a powerful playground to tinker with new technologies and discover your powers. Take Rachel Andrew’s and Sara Soueidan’s word for it:

- My first #CSS Grid implementation was on my own site
- My first service worker implementation was on my own site
- My first real-world CSS Variables implementation was/is on my own site (WIP)
- My first Variable Fonts implementation will be on my own site
- ...

— Sara Soueidan (@SaraSoueidan) February 8, 2019

I couldn’t agree more. Building things for your own site is so worthwhile because you are allowed to make mistakes and learn without pressure. If it doesn’t work today, well, maybe it’ll work tomorrow. It doesn’t matter. And so it was on my own site that I, too, wrote my first service worker, that I first tried out CSS Grid, that I designed and implemented a custom syntax highlighting theme, that I set up an RSS/Atom and JSON feed, that I wrote three plugins for Craft CMS in PHP/Yii, and Twig, with one of those plugins adding Webmention support to my site. I also learned a ton about accessibility, performance optimization, or web font loading. All of which I then could put to use in my day-to-day work as a designer and developer.

But maybe the most compelling reason why a personal website and also learning how to build one is incredibly valuable is this: community. Since the days of “guest books”, personal websites have been a place to receive feedback and discuss ideas and concepts with others. Often by the means of comments, sometimes even by writing a series of follow-up articles back and forth.

Now imagine, for a moment, an environment where a decentralized fabric of connected personal sites allows everyone to publish their own content but also enables each individual to engage in an open discussion – answering, challenging, and acknowledging the ideas of others through this universe of personal sites.

As idealistic as this vision of the Web might seem these days, it isn’t that far out of reach. Much of what’s needed, especially the publishing part, is already there. It’s also not as if our sites weren’t already connected in one way or another. Yet much of the discussions and establishment of connections, of that social glue that holds our community together – besides community events in real life, of course –, mostly happens on social media platforms at the moment. But: this is a choice. If we would make the conscious decision to find better ways to connect our personal sites and to enable more social interaction again, and if we would then persistently work on this idea, then we could, bit by bit, influence the development of Web technologies into this direction. What we would end up with is not only a bunch of personal websites but a whole interconnected personal-website-verse.

Weaving Our Web

It’s, of course, safe to assume that a web of personal websites will never be an equivalent substitute for a social network like Twitter. But that’s also not the goal. Personal websites are called personal websites because they are just that: personal. Thus, the primary objective still is to have a place to express ourselves, to explore ourselves, a place that lasts while the daily storms pass by. A place of consideration, and yes, a place of proudly sharing what we do, what we think, and what we care about. A place to contribute your voice and help others. A home on the internet. A place to tell your story.

But on top of that, we have the chance to (re-)establish personal websites also as central elements of online discourse and as entry points for people who are new to the web community. For this, we need to find ways to create an ecosystem that lives up to the diversity of the personal-website-verse. Consequently, what will hold our sites together, is most possibly not one technology to rule them all, but a multitude of different and ever-evolving technologies. Things like hyperlinks, comments, Webmentions, and RSS, of course, but also other technologies that have yet to be invented. Not only would this leave enough room for individual preferences, but it would also make the whole construct more resilient while still being flexible enough to evolve over time.

The first step of this is to explore more ways to establish new and strengthen existing connections – and also to improve findability. We don’t have to reinvent everything from scratch but can build on so much that already exists. Some things that can serve as good starting points are:

Quote people and link to other sites.

Whenever you stumble upon an interesting thought on another site, write about it and link to it. Not only is it respectful to link to the person you quoted, but hyperlinks are also the magic force holding the Web together. They are both helpful and powerful. You can also add a links section to your site, where you collect interesting links you found on the web and over time build an archive for yourself and others.

By the way: What happened to the blogroll? Remember? That little box in the sidebar of blogs that would link to the websites of friends and fellow bloggers. The blogroll isn’t dead yet – some people still use it. So how about adding a little section or page to your site that does exactly the same? Link to the personal websites of people you respect and appreciate, maybe with a little description? While we’re on it, we could also bring webrings back. Charlie Owen recently also wrote about them and Max Böck was so inspired he built a starter kit for hosting your own webring.

Use RSS feeds and readers.

RSS has been pronounced dead over and over again, yet it is still not dead and I doubt that it ever will be. In fact, it is witnessing a little comeback from time to time. Personally, I have started to use it more regularly again and others have, too. RSS is a great way to follow the people whose posts, ideas, and opinions matter to you. So if you write or put any kind of content on your site, also make sure to add an RSS feed. And then go and add some sites to a feed reader like Feedbin, Feedly, or Michael Scharnagl’s Feediary. If you use a Mac or iOS device, also have a look at Reeder.

Use website directories.

There are a few really helpful directories that list RSS feeds or personal sites and that can help you find interesting content. For example, Andy Bell’s personalsit.es, Dave Winer’s feedbase, the IndieWeb Directory, or RSS lists like the ones of Sime Vidas or Stuart Robson.

Use Webmentions and Microformats – and join the IndieWeb.

Another powerful technology which can glue our sites together is Webmention. Webmention is a W3C recommendation that describes a simple protocol to notify any URL when a website links to it, and for web pages to request notifications when somebody links to them. The mentioned site can then grab a snippet of the HTML of the website that links to it and, if it is enriched with Microformats, display the mention somewhere, for example under a blog post like this one. Aside from all questions of data protection, Webmentions are a powerful tool and one of the many technologies that originated in the IndieWeb community. If you don’t know about the IndieWeb yet, take a look at my article on reclaiming control over your content, or head over to indieweb.org. Built around the basic idea that you should own your content, the IndieWeb community is the birthplace of a few powerful technologies that all have the goal to make your personal website the center of a more open, decentralized web.

Webmentions are a great way to connect and intertwine two sites and thus, two ideas. You could even build something like a commenting system around Webmention – if only it still wasn’t a bit complicated for mere mortals to implement them. Luckily, there are plugins available for content management systems like Wordpress, ProcessWire, or Perch. I will update my own Webmention plugin for Craft CMS over the coming weeks so that it supports the latest version 3 of Craft CMS.

Go to meetups and conferences and spread the word.

There are meetups for everything and they are a great place to meet like-minded people, exchange, connect, and tell others about how great having a personal website is. So look up if there’s maybe a meetup about blogging in your city. Also, meetups on topics like WordPress, writing, or publishing in general could be worth a visit. Then there are more and more Homebrew Website Clubs emerging. Homebrew Website Clubs, which are also an IndieWeb idea, are a great opportunity to work with others on your personal sites once or twice a month. And if you don’t find an appropriate meetup or event near you, how about starting one?

“Don’t do it like me. Do it like you.”

As you can see, there are many ways and many good reasons to start building your site today. But whatever you start, keep in mind that you don’t have to build something from start to finish to show it to the world. To the contrary, it can be a great idea to start as simple and rudimentary as possible, to get the fundamentals right before diving too deep into over-complicated solutions. Take your time to think about how to build a site that’s truly tailored to you and your work. What are you really trying to achieve? What content do you want to create? Who is your audience? And how does a website look like that reflects all that in terms of structure, hierarchy, complexity, visual design, and scope?

Kylie Timpani, for example, who recently worked as the lead designer on v17 of CSS-Tricks, is now doing an open redesign of her website. So she is building the website out in the open, starting with some blank and raw HTML, and will be documenting what she’s learning along the way. This, by the way, is generally a great thing to do on your site: Document your process and share all the things you learn. Amber Wilson is doing this on her site, too. Since she decided to become a web developer, she regularly writes about her experience and what she learned. Not only is this a great way to help others find their way, but it also shows that we all have to learn and we all have things we don't know. Don’t let that stop you.

Also, don’t hesitate to write about little ideas and observations that might seem too small or unimportant to share. We all have our unique perspectives and even the smallest experience is worth sharing. Someone else might be in a similar situation as you or also in a completely different situation. They both might learn something new from reading about your experiences. Each contribution to the community, even the smallest one, is useful and will make a change. So just write. By the way: If you are struggling to find something to write about and feel blocked, remember that there is no such thing as writer‘s block. The more you write and create, the easier it will get.

To Begin, Begin

When I studied design back in the early 2000s, my digital media professor, Tom Duscher, held the view that every designer should have their own blog. It was still the early days of blogging but he already saw the potential and power of writing about your craft and reflecting on your experiences. At the time, I thought I understood what he meant, but it took me over 10 years to finally overcome (or simply ignore) the fear of being wrong and start to publish on my site. I won’t ever look back.

Building and maintaining your personal website is an investment that is challenging and can feel laborious at times. Be prepared for that. But what you will learn along the way does easily make up for all the effort and makes the journey more than worthwhile. But most importantly, having a website makes you part of an amazing community of creators, forming new friendships, new connections, and new opportunities. This is invaluable.

Personal websites are the backbone of the independent Web of creators. Even after all those years, they remain a vital part of what makes the web the most remarkable and open medium to date. We shouldn’t take this for granted, though. If we don’t pay enough attention and care about the open web enough, we might lose this valuable asset. So let us protect the Web as a source of inspiration, diversity, creativity, and community. Let us maintain what we have and work together to make this little part of the magic of the Web sparkle even brighter. Let us help new members of the community to start their journey. Let us build, prototype, publish, and connect.

Let’s start today.

If you start a new personal site or already have one, you are welcome to share it below. There are three ways to do that: If your site supports that, just send a Webmention via your personal website. You can also use the form below this article to send a Webmention. Then, you can reply to this tweet – all replies are automatically added to this article as a Webmention. Or, write me a quick email and I’m happy to manually add your site below.

–

The header image illustration is based on photographs of the Apple Lisa by Victor R. Ruiz and the Apple Lisa mouse by Marcin Wichary, both released under a Creative Commons license (Attribution 2.0 Generic, CC BY 2.0).

Prototyping.news: For a monthly update on the latest articles, tools, and other resources about prototyping for the Web, sign up for my new newsletter prototyping.news.

The Illusion of Control

We have a problem. And I fear that many of us still don't see it. And those who do see it are still not completely sure what to do about it. The problem is this: The traditional tools and workflows we used for years to build things for the Web don't work anymore for today's Web.

Most of our tools and processes originated in a time when designing for the Web basically meant designing with only a few colors and pixelated type for screens that had relatively clear and small dimensions. The obvious constraints of “new media” – with the pixel as the omnipresent smallest visual building block – were defining its character and made it stand out against print media. Over time, in search of control and with growing professionalization, agencies and design studios established processes that allowed them to build and sell websites professionally. And because every new medium first borrows from its predecessors, the answer to the question of how to approach the web design process seemed obvious. Let’s do it like we do printed products, like we design all products in classical industrialized workflows: Plan. Design. Produce.

And it worked.

Planning websites grew to a domain of great expertise. Specialized disciplines like Information Architecture, Content Strategy, or User Experience Design evolved. Sitemaps and wireframes got created so that the structure and hierarchy of a website would be clear before starting with the design phase. The designers then built beautiful layouts out of those wireframes so that clients could approve how the website would look like. And finally, the developers took those Photoshop layouts and magically transformed static designs into interactive pages. Everything was plannable. Everything was predictable. Everything was under control.

Until everything changed.

It was the Web itself that changed. Because change is in its nature. Maybe the most striking example of this change is that instead of a clearly defined canvas (of 640 x 480 800 x 600 1024 x 768 pixels) we now have to design for this:

What you see here is a – by no means complete – visualization of currently available screen sizes, ranging from tiny smartwatches up to huge 4K screens. Apparently, the differences between the individual screen sizes become more and more blurred. Where do we draw the line between “mobile” and “tablet”? Where does “large desktop” start? The idea of a fixed canvas and the control we thought we had over it is definitely a thing of the past. And this doesn’t only apply to screen sizes, it also applies to the Web as a whole.

The Web has evolved at an unimaginable speed and we are now witnessing an unprecedented diversity of not only screen sizes, pixel densities, and color spaces, but also devices with most different capabilities, sensors, input types, browsers, APIs, accessibility features, security issues, connection speeds – the list is endless and it won’t ever be complete.

All those technologies and contexts are things that we can and often even must take into account when we build something for the web because all those things can inform our products and shape the experiences of the people who use those products. A website is not a static artifact. It’s a flexible, living thing that can assume the most different forms and can even evolve over time. And if you consider all the things that are yet to come, for example in the fields of the physical interfaces, AI and machine learning, or also with additions to existing technologies like JavaScript Web APIs or CSS Houdini which will let you create your own custom properties, custom functions, and custom @-rules – how can one possibly think of the Web as something homogeneous in this age of extreme computing?

The Web isn’t uniform. It never was. If we thought we were in control, it was only because we hadn’t yet imagined what the web would look like when unfolded to its true nature. The Web of today is complex, flexible, blurry, chaotic, unpredictable, extendable, immediate, omnipresent. And this complexity of the Web leads to the major problem regarding our processes: When every project is different, when conditions, tools, and technologies change with every project, static and linear processes are less and less repeatable and planning for success beforehand becomes basically impossible. There are simply too many factors with too many unknowns to consider. So if we want to build lasting, appropriate, performant, accessible, consistent, secure, and unique experiences for everyone on the Web, we need to find ways to cope with this multiplicity.

To some extent, we already started. In the year 2000, John Allsopp wrote his renowned article A Dao of Web Design in which he suggested that “we should embrace the fact that the web doesn’t have the same constraints [as print], and design for this flexibility.” But his call remained unheard for years and it wasn’t until the mobile revolution that we actually started to change the ways we design for this flexibility.

First, we indeed ditched the notion of a fixed-sized canvas and got our heads around the idea of responsive web design. Ethan Marcotte, who coined the term responsive web design back in 2010, recently pointed out that we also “have started to break our interfaces down into tiny, reusable modules, and began using those patterns to build products, features, and interfaces more quickly than ever before.” We also questioned Photoshop, the “damn liar”, and started to fall in love with tools like Sketch or Figma, that promised to be more suitable for designing user interfaces. Instead of designing static pages we are now building modular systems of components. At least that’s what we do in theory.

In reality, many of us are still struggling with the permanent shifts and rapid change of the medium. In reality, the new agile and lean processes we love to talk about in front of our clients are seldom more than high-frequency waterfall. In reality, I still hear project managers, designers, and developers regularly talk about screen widths in device-specific categories like mobile, tablet, and desktop. In reality, I still get to see my fair share of static Photoshop layouts and, to be honest, breaking up our static designs into components and modules in Sketch may be a step in the right direction but it doesn’t necessarily make our designs less static. To some degree, we only switched one static design tool for another. To some degree, Sketch is a liar, too.

We are still drawing pictures of websites – although, as Paul Robert Lloyd noted, the true web aesthetic is hardly visual at all. We are still tackling a flexible medium with the static tools and linear waterfall processes of the past, that can’t represent the inherent nature of the Webs ingredients because we are always creating static abstractions of the final medium. This leads to tedious, inefficient, and highly ineffective tasks, wrong features being built, and most importantly: because we spend most of our time doing the wrong things, the quality of the experiences we offer our users suffers. So it is about time for us to change that.

A Material to Build With

At Webstock 2015, Frank Chimero gave an outstanding talk in which he discussed the true nature of the web – he called it The Web’s Grain – and suggested that if we want to come up with appropriate design solutions for today's Web, we need to recognize the things that are implicit to the medium and work with them accordingly. And he asked:

If we look at the Web as a material or even as a multitude of different materials to build with, using tools like Photoshop that ignore fundamental attributes of those materials – like interactivity or movement – suddenly appears even more inappropriate. At the same time, finding ways to appropriately build things out of those materials becomes an imperative. But how can we approach this? How can we find tools and processes that let us work with the Web as a material? To answer this question it is worth looking at the history of some disciplines that have always been working with materials.

In architecture and industrial design, but also in engineering, materiality has always been a crucial element. Building for the Web combines properties from all of those disciplines, but maybe we missed to realize and consider the materiality of the Web because of its virtual nature, because it lacks physicality. At least, you can’t feel the weight of a website or smell it (yet).

In architecture and industrial design, there exist the concept of material honesty. Material honesty means that a material should be used in accordance with its true nature and its properties and that those properties should influence the form the material is used for. The origins of this idea can be traced back to the Bauhaus, the German art and design school that laid the foundation of modernist industrial design and architecture. The Bauhaus was founded with the objective of finding a new aesthetic that was appropriate to the standardized production methods of the industrial age. In contrast to the Art Deco movement, the Bauhaus wanted to forgo the romanticizing, ornamental decoration of industrially produced objects. In his ‘Principles of Bauhaus Production’, architect and Bauhaus founder Walter Gropius wrote:

Consequently, material studies were a central element of the Bauhaus teachings. Timeless and for their time revolutionary designs like Marcel Breuer’s “Wassily Chair” or the Bauhaus Buildings itself, by Walter Gropius, combined materials in a new, materially honest way: Instead of hiding materials like steel and concrete those materials defined character, form, and function of the designed objects.

The guiding principle of finding a materially honest form and function is one of the major legacies of the Bauhaus. Many designers and architects were deeply influenced by the ideas of the Bauhaus, for example, Charles and Ray Eames. For them too, selecting and working with the right materials and taking their qualities into account was pivotal to designing objects like the Eames Plastic Armchair that masterfully combined molded wood, aluminum, steel, and high-performance plastics, using each material to its full potential. In the Eames workshop, the couple experimented with different materials like molded wood, for which they used a machine they had crafted to pressure-treat wood. The resulting prototypes were honest and pure expressions of the molding process, not upholstered and straightforward. But Charles and Ray Eames also considered another aspect of product design, that is, that eventually all products are used by humans and the usefulness of a product also highly depends on the human factor. This is why they built prototypes like an adjustable chair design tool to understand how people sit. Charles Eames: “We’ve always been aware of not even attempting to solve the problem of how people should sit, but of rather arbitrarily accepting the way people do sit and of operating within that framework.”

So to design resilient and adaptable systems in accordance with the true nature of the Web, we should do the same: We should explore the materials of the Web to work out their characteristics which then shape the design patterns of our system, while always considering the usability of our solutions. For physical products, certain technical and aesthetic qualities like structure, surface, flexibility, or durability characterize the nature of a material. For digital products, similar qualities can be explored: How flexible is a solution? How robust is it? How well does a solution work in different contexts? How much interactivity does it have? Does it allow growth? How performant is a certain framework, how flexible a CSS methodology and so on. To assess all those qualities we need a tool that is just as approachable, just as flexible, and just as extendable as the Web itself.

This tool is prototyping.

A Prototyping Mindset

All design is the result of a series of decisions. Along the way, all of those decisions influence how the result will look like. And so, depending on which paths we decide to take, there are endless possible futures. Many of those decisions can only be made thoroughly when you have arrived at the point where the decision has to be made. If you try to plan beforehand, you run the risk of following the wrong strategy and ultimately building the wrong product. Neither a linear waterfall process nor static visual designs are suited to reveal the true cost and effort it takes to build something for real, whether a certain feature is really what your users need, or if an implementation will work in production. So you need to work iteratively, being flexible enough to change course if a road proves to be the wrong one and being there when a feature evolves that needs more attention.

Prototyping supports you in making informed decisions in iterative workflows. It allows you to explore the characteristics of materials, quickly combine them into new constellations, and come up with something original. In this way, prototyping actively supports the generative and constructive nature of design. It lets you validate your assumptions and test ideas and new solution approaches early and in different contexts so that you know what will work and what you are building. Prototyping is a tool and a process, a way of working. But most importantly, prototyping is a way of thinking, a mindset.

A prototyping mindset means that you include prototypes in every phase of your process. This also implies that you understand prototyping as the flexible tool it really is. When someone mentions prototyping, many people either think of interactive wireframes or rapid prototyping techniques. But this definition is far too narrow. Prototyping is much more. A prototype can be anything: A quick sketch, a short animation, a markdown file outlining a structure, or an interactive HTML application. Anytime you start to explore a problem, begin to try something out, and start to render an intent you are basically building a prototype. It is not the form of the prototype that counts, or how fast you build it, or if it is a deliverable – it is what you want to achieve with it and what you learn from it.

A prototyping mindset also means embracing the complexity of the Web and getting comfortable with uncertainty. It means starting with the most basic solution to a problem and then exploring and iterating from there, using real materials like code and real devices as early as possible.

A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.

Moving away from static processes doesn’t come for free and requires a lot of patience and effort. Convincing colleagues and clients to use a prototyping-driven workflow can be tedious. It implies that people let go of old habits and get comfortable with a process that seemingly offers less control. But in the end, introducing iterative, flexible workflows makes the difference between average and great digital solutions.

Prototyping is an essential, powerful element of those iterative workflows and especially prototyping with code will enable you to develop solutions that matter, solutions that are appropriate, robust, performant, accessible, and secure. Honest to the nature of the Web and thus honest to your users. But most importantly: It will feel like you are building the right thing. Finally. So if you haven’t started prototyping yet, do it today.

–

Header artwork based on a photo of a rare, clear case prototype of the Macintosh SE by Jim Abeles

A New Kid on the Block

The new layout module is a great achievement for all people involved in the process and also the fast implementation by browser makers is worth mentioning: It is the first time that such a significant new module has found its way into all major browsers within only a few months time. So a lot of effort went into CSS Grid until it finally became a reality. Rachel Andrew and Jen Simmons, for example, were not only actively involved in the standardization process but also raised awareness within the community with numerous talks and projects like Grid by Example or The Experimental Layout Lab.

Indeed, CSS Grid completely changes the way we approach layout, both for developers and designers. Whereas before we had to use hacky CSS to carve our layouts out of a resistive document flow, we can now act more freely and place elements in a predefined grid without using a separate grid system – as Rachel Andrew points out, CSS Grid already is a grid system. At the same time, CSS Grid acknowledges the fluid nature of the medium and allows for brilliant layout solutions like this technique by Tyler Sticka, where he creates a fluid responsive layout container with only a few lines of CSS. Or this:

A fully responsive grid with no media queries in three lines of code is actually pretty awesome: https://t.co/9zdV2t0CBe pic.twitter.com/ju2H3deJhx

— Stefan Baumgartner (@ddprrt) May 12, 2017

This is amazing stuff! And we can expect more of such smart layout tricks once people start using CSS Grid in production. And here's the good news: you can use it TODAY!

But wait a minute.

Wicked or Weakness?

For all the well-justified euphoria, there is still one important thing to consider when using CSS Grid today: Although all major browsers now support CSS Grid (with Microsoft Edge coming soon), the overall support naturally isn't very good yet. Caniuse.com puts browser support for Grid at 69.3 % (prefixed) and depending on the distribution of browser shares in your audience, it could be even lower. So if we want to use Grid in production, we will definitely have to provide a fallback for older browsers. One often-heard suggestion to solve this is to use a really simple float or Flexbox layout as a fallback. The argument: Instead of trying to make a design look the same across all browsers, let's use CSS Grid to its full potential and provide a minimum viable layout that still cuts the mustard (read: displays content) for browsers that don't support it yet.

The basic approach of applying the principle of progressive enhancement – or, like in this case, graceful degradation – is absolutely the right way to go, but one huge problem remains: If we definitely need a layout that works without grid, a super simple one column layout often just won't be sufficient. Neither for the client who would need to be fine with the idea that a large percentage of users get to see a minimum viable design nor for the users themselves who will be left with a subpar solution. So we will have to put some more effort into the fallback layout and before we know it, we are effectively building two layouts after all. Even worse: We would also have to think twice how a certain layout could be done in CSS because the layout techniques differ so much. And if using floats and Flexbox will also still work in newest browsers why are we building a layout with CSS Grid anyway?

Rachel Andrew addressed exactly this question in her recent, excellent post “Is it really safe to start using CSS Grid Layout?”. She answered it aptly:

I couldn’t agree more: Exploring and using newest technologies, which requires that we cope with incomplete support, is crucial to successful projects and has always been a huge part of what makes the Web great. But still: We have to be careful that we don't set our expectations regarding an immediate adoption of CSS Grid too high. Just because people can use CSS Grid theoretically doesn’t mean they will actually use it in practice, especially if this involves writing layout code twice and with an already established method out there. Humans are allergic to change. So if we really want CSS Grid to succeed outside of the closed space of innovators and evangelists, the story has to be not only “Grid is so awesome, use it now!” but also: “Here's how to use CSS Grid in production in a responsible way – it's possible.”

So What is This Thing Called CSS Grid?

If we don’t want to use Grid just for Grid’s sake, we have to understand what Grid really is and start asking the right questions like:

• What problems does Grid solve that float-based solutions can't?
• How can Grid be used responsibly to really enhance a design?
• And ultimately: how does the use of Grid benefit the user?

To find answers to those questions, we – both designers and developers – will now need to learn about the strengths and weaknesses of CSS Grid. We need to learn how to play this new instrument because the shift really is this fundamental: At the moment it seems we are all designing with the same 12 column grid – if we are reckless, we try 16 columns. CSS Grid will allow us to resolve this gridlock, once we fully understand the radicality of the new flexibility it brings. Grid allows for greater flexibility for developers, because defining custom grids will be as easy as setting a font-size. And it gives greater flexibility to designers: It could allow us to reach the graphical richness we see in editorial design and graphic design in general.

Prototyping Our Way out of Gridlock

So the shift in thinking and the realization of the possibilities Grid offers has to happen on both sides of the spectrum, in design and development. Naturally, this is a hard thing to do when you still stick to the old waterfall workflow that many agencies still haven't left behind. To fully leverage grids potential, a frequent exchange between the disciplines is needed, ideally in a multi-disciplinary team that consists of UX and visual designers, front-end engineers, and developers. It's another manifestation of the huge shift we see in contemporary web design: the decision making largely happens in development, at the end of the good old waterfall and working with code is crucial for finding appropriate and outstanding design solutions.

That's why prototyping has become an essential tool for teams building modular responsive web designs today. It allows for testing ideas and hypotheses with real code even at early project stages, which is invaluable in crafting responsive designs. Prototyping also reveals the weak spots of a design and by that opens up new possibilities for innovative solutions. So get your team together, prototype, try out what CSS Grid can do that conventional layout methods can't and how you can use it effectively in your project. Then use Grid specifically for that purpose.

CSS Grid in Modular Systems

Whether you go full throttle with CSS Grid or choose a moderate approach and use it only sparingly as an enhancement totally depends on your project setting and requirements. But following a modular design approach can facilitate the adoption of new web technologies like Grid. Splitting up your interface into components – for example with a pattern library tool like Fractal – will make it easier to use Grid, because you can apply it in an isolated scope. This makes the code more manageable and also allows you to easily optimize single components for older browsers. And most importantly, you can try out new layout solutions quickly without breaking the whole system. This makes a pattern library also a great tool for prototyping with new technologies, but that's another story.

Summary

Dealing with incomplete support has always been one of the challenges of creating things on the Web. Not so long ago, we had to be careful with using structural pseudo-classes like nth-child, the calc() function, or even display: inline-block. With CSS Grid it might be a little bit more difficult to find a way to use it responsibly because it is such a large module that fundamentally changes the way we do layout on the Web. To make the best use of it, we, therefore, need to learn how to play this new instrument and prototyping in code can be vital to explore the possibilities that CSS Grid offers. Until we have broader browser support it can also be a good strategy to use Grid only as an enhancement and on the component level. But whatever way you decide to explore CSS Grid, the most important thing is: Start using it now and help resolve CSS gridlock.

Further resources

CSS Tricks' Complete Guide to CSS Grid

Rachel Andrew: Start Using CSS Grid Layouts Today (Video)

Shop Talk Show 262 – CSS Grid with Rachel Andrew and Jen Simmons

CSS Grid Garden – A game for learning CSS Grid layout

Grid layout, grid layout everywhere!, by Stefan Baumgartner (@ddprrt)

CSS Grid and Grid Inspector in Firefox

Rachel Andrew's Grid by Example

The Experimental Layout Lab of Jen Simmons

Realizing Common Layouts Using CSS Grid Layout

Practical CSS Grid: Adding Grid to an Existing Design, by Eric Meyer

CSS Grid Layout and Progressive Enhancement

A Collection of Interesting Facts about CSS Grid Layout, by Manuel Matuzović

Enhancing CSS Layout: From Floats To Flexbox To Grid, also by Manuel Matuzović

–

The header image is based on a photograph by Thomas Hawk licensed under CC BY 2.0, slightly cropped and edited.

So it is important to remember that leaving your comfort zone and trying out new ways of doing things is vitally important. There are many ways to broaden your horizons if you are looking for inspiration: You could do some research, read a book or an article, or visit a new city. But one of the best ways surely is the experience of a conference, because it provides you with many new concepts and ideas. Moreover, ideas that were floating around in your head for a while are affirmed.

So let’s look at three basic ideas on how you could depart from the beaten track that also surfaced at beyond tellerrand Düsseldorf, Marc Thiele’s pleasant and inspiring conference that always excels at bringing together a wide variety of speakers.

Rediscovering Originality

There are many voices critizising the trend towards standardization in web design. “All websites look the same”, is an often-heard claim these days. And there clearly is a trend towards standardizing not only user experiences, but also the process of designing those experiences. While this standardization surely has positive effects, it also leads to an obvious lack of originality.

To Espen Brunborg, creative director and co-founder of the web design company Primate, telling compelling stories on the web comprises two key aspects. For one, good design meets the users’ expectations. Espen compares this to music: Just like rhythm provides a reliable structure and leads to familiarity, doing your homework regarding the information architecture, element hierarchy, typographical rhythm, all the UI patterns, and also performance and accessibility will make your site easier and more efficient to use.

But there is another side to the coin, which is often neglected these days yet is so powerful: comedy. While music meets our expectations, comedy breaks them. This is when surprise, emotion, and joy of use occur. It is what makes your site stand out and gives it personality – and in the end also makes it more successful.

So Espen encourages us all to make “the good shit”. Great work that does meet user expectations with regards to consistency, usability, and performance, but also deliberately breaks expectations to become more memorable and surprising, and to tell stories that create a true connection with our audience.

Watch Espen's talk on Vimeo.

Storytelling with Code

Telling compelling stories with personality was also a central theme of Sarah Drasner's talk at beyond tellerrand. Sarah is a designer, developer, consultant, and speaker who wrote a highly recommended book on SVG animations and also regularly writes for CSS-Tricks. Her talk covered lots of useful insights and techniques for animating user interfaces effectively, but it was furthermore special in that it highlighted the immense power of animating directly with code. Code is Sarah’s tool of choice for creating animations and rightly so: Creating web animations with tools like AfterEffects or even Photoshop will always be a half-baked workaround and eventually also cost more because more effort has to be spent to achieve great results, especially if details get lost along the way from design to development.

Crafting meaningful, functional animations directly in the final output medium though, results in another way of thinking. Instead of just “adding some animation” to an interface, you start to think and work with animation in a more direct and precise way. Working directly with code allows for considering (device) performance as well as technical implications of front-end frameworks or certain animation libraries.

To create your stories directly in code, you will of course need either a designer and a developer in the same room working closely together or a – drumroll – designer who codes. You also might need to change the way you work, but it's not as hard as it sounds. We are not talking about production code here. When working with my students on HTML prototypes, many of them have never written a single line of HTML before. Yet even after one day, they manage to get their head around basic CSS animations. Add a little practice and you will drastically improve the quality of your user interfaces. You can start with little Codepen prototypes and also use tools like Framer or JavaScript libraries like Greensock – but jump into code as soon as possible to work directly with the material.

Sarah's talk is also on Vimeo.

Adopting New Technologies

Trying out new things and by that constantly evolving your toolset and adjusting your workflow is eminently important, especially on the web, because it changes so fast. But humans are allergic to change and given all the endless possibilities out there, it happens easily that we stick to the tried and true instead of risking to invest time and money into some new and unproven technology. And how could we possibly tell if a new technology is worth the effort of learning about it and incorporating it into our workflow? How can we evaluate technology?

This is the question that Jeremy Keith tried to answer in his talk that also was a little journey into the history of technology. He suggests: When evaluating a new technology, one of the most important questions is not „How well does it work?“ but rather „How well does it fail?“. Because even the most outlandish web technology is still safe to use if – and only if – a fallback is provided in the not so unlikely event of failure. By providing those fallbacks, a technology is not only more likely to be adopted by change-allergic humans but it also directly benefits users, because the product remains usable. And users should always come first when considering the use of a certain tool.

Another question to ask yourself when considering the use of a tool is: What are the assumptions? All software is opinionated and was created to solve a very specific problem. But your problems might be completely different, so you will need to check if the assumptions baked into a certain tool match your own philosophy and the situation you are in. Otherwise, you will always work against the tool, not with it.

You can watch Jeremy's talk here.

Leaving the beaten track

As professionals we don't need to defend ourselves for using unconventional methods or new technologies. That's a huge part of making successful projects. Also, good design isn't about being right. It happens off the beaten track. Good design is about finding useful, accessible, memorable, entertaining, and appropriate solutions to real problems. Problems for which classical solutions often don't work anymore, because we are facing new realities everyday. Solving those problems demands that we leave the safe harbors of what seems to be true and trusted and learn to embrace the unknown. Only then will we make outstanding, meaningful ideas a reality.

–

Beyond tellerrand is a conference on design, development, creativity, and all things web. It is run by Marc Thiele twice a year in Düsseldorf (coverage and wrap-up here) and Berlin (06 – 08 Nov 2017, Admiralspalast) and it is really worth a visit. You can find videos and transcripts of the talks as well as tickets for the event on the conference website.

“I need your clothes, your boots and your [data].”

If you're being pessimistic (some even would say: realistic), the struggle of forces with the data economy and multi-billion dollar companies like Google and Facebook is already lost:

Quintillions of bytes of personal data are created every day on the internet and the larger part of this content is uploaded onto the servers of social media sites, publishing platforms, and cloud services like Facebook, YouTube, Instagram, Twitter, Medium, Snapchat, Dropbox, and many more. For most of those platforms, your content also provides the context for their ads, so they made sure it is as easy and convenient as possible to sign up and upload and create new content. But this convenience comes at a price: The very moment you hit ‘publish’ on one of those data silos, you give away control over your data. And it even goes far beyond that. Just to give you an example: Ever drafted a Facebook status message but then decided to delete it before publishing it? Maybe because you felt the content was too private to share with the network? What you might not know is that Facebook collected your keystrokes and saved your text anyway in the background. Facebook then uses those drafted messages to analyze why users decide not to publish certain information. Besides that, you never know if your audience really will see your content, because Facebook heavily manipulates what users see in their timeline. We are willingly giving away control over our most personal stories and thoughts. Why is it that we give away this precious good so lightly?

You might say that of course, we have to pay for for the convenience and reach of a huge network like Facebook or the accuracy and helpfulness of Google's services. But: It's not that most users would have a choice. We don't use those services because we are rational decision makers and we indeed prefer this solution over several alternatives. We use data silos in spite of that because there simply isn't an open, convenient, trustworthy alternative – yet.

But even if you're fine with strangers using family photos for the progress of face recognition software, there is another imminent danger in giving away your data: It can also lead to complete data loss if a service ultimately shuts down. This happened in the past, with MySpace and Yahoo’s Geocities being the most famous examples of site death, and one day, it will happen to sites like Twitter or Facebook, too. And even if we are able to export our data from a site – which is still the exception rather than the rule –, more than often, we end up with some unusable file format. Not only are we losing precious memories and lifetime that went into the creation of those personal artifacts. With every service that shuts down unarchived, we as a society also loose large amounts of data that is part of our culture. We must not lose what gets created.

So the bottom line is this: When you post something on the web, it should belong to you, not a corporation. You should be in control.

Redecentralizing the Open Web

It really is about time for us to redefine what being a citizen of the web means. Our digital identities are digital representations of our lives, so we need to take back control over our content, reclaim our digital future, and reshape the web as independent as possible.

But condemning the status quo while at the same time trying to replace a monopoly with another centralized solution surely won’t work. If we want to build a true alternative to the corporate web, it has to be build from the ground up with tools that are crafted in the spirit of what makes the web strong: Community, collaboration, debate, consensus, open standards, continuous improvement. Only then, the resulting solutions will be accepted, robust, and long-lasting. Additionally, as Tantek Çelik emphasizes, we should be able to openly access and use the content and code we create and publish on the web.

The basic building blocks to accomplish all of this are right in front of us. They have been here since Tim Berners-Lee first imagined what would become the World Wide Web. For example, anyone can set up a website like it’s 1999 – still today, all it takes is a computer and a text editor. And anyone can create a hyperlink and connect their pieces of information to related sources. All it takes is a one letter tag: <A>. Collectively, hyperlinks form the superpower that is holding the world wide web together. A network of information that is, in its most ideal form, both decentralized and distributed and thus resilient.

Both openness and decentralization are essential to rebuilding an independent web, because they protect it from manipulation and regulation, and they can be achieved in many different ways. But in the collaborative effort to redecentralize the open web and regain control over our content, one element plays a particularly decisive role: the personal website.

Your Website: A Declaration of Independence

Besides forming a distributed network of information, personal websites provide us with so much freedom on so many levels: On your website, you can publish anything you want, in any imaginable form, without the need to ask for anyone’s permission. You can make it your playground to experiment with new technologies and try out new ideas. The content you create stays online as long as you want under a permanent URL which you are free to set. And if you want to, you can notify the Internet Archive to grab a snapshot if the content of your site changes. You are in control. It is your home on the web. It is your voice as a web citizen.

Of course, setting up your own website takes a certain set of skills and a little more effort than joining Facebook. You need to register your own domain. You need to set up a system that serves your content. You need to find your preferred way of creating and presenting content. Sometimes it needs discipline. But what you will get is a personal representation of yourself, an archive of thoughts that will outlast all turmoil on the web – and so much joy!

Having your own website surely is a wonderful thing, but to be relevant, useful, and satisfactory, it needs to be connected to other sites and services. Because ultimately, human interactions are what fuels social life online and most of your friends will still be on social networks, for now.

The Reinvention of Social: Joining the IndieWeb

This is what the IndieWeb movement is about: Creating tools that enable a decentralized, people-focused alternative to the corporate web, putting you back in control, and building an active community around this idea of independence.

At its heart, the IndieWeb is all about your personal website. You can use your website's domain name to sign in to websites and services via IndieAuth. Then, you start building connections between your website and other sites and services. These connections can work both ways: You can publish on your own site and then send a copy (“syndicate”) to Facebook, Twitter, Medium et al. Or, you publish elsewhere and send posts and even reactions like mentions or likes back to your own site. If this incoming data is marked up with semantic microformats, it can be parsed and displayed on your site anyway you like.

The IndieWeb approach to collecting reactions to your posts are the so-called Webmentions. A Webmention is basically a way to notify a website that you link to it from your own site. Let’s say I write a post in which I cite one of your posts. My server then sends a request to your website’s Webmention endpoint saying: “Hey, you were mentioned under this URL here.” Your website checks back if the URL is valid and after that fetches some information to display the Webmention on your site. With the help of Bridgy, this also works for likes, retweets and other interactions on several social media platforms. Webmention is a W3C Recommendation since January 12, 2017 and there are many implementations out there already, including hosted services like Bridgy, Webmention.io, A Webmention Endpoint, the “IndieWeb CMS” Known, and plugins for WordPress, ProcessWire, Typo3 and – the one I wrote myself – for Craft CMS.

There are many more interesting IndieWeb tools, but equally important are the main principles of community and participation: The IndieWeb movement is open to anyone who wants to join. Brainstorming and building events like IndieWebCamps and Homebrew Website Club Meetups are held regularly all around the world and are a fantastic opportunity to work on your own site and shape the future of the independent web. I attended the last IndieWebCamps in Berlin and Düsseldorf and enjoyed it a lot – as did others. So come and join us on one of the next events.

First We Shape Our Tools

All the tools that have been created out of the IndieWeb movement, open source projects like Solid, or the distributed Twitter alternative Mastodon already are a great foundation to build upon, but they can only be the beginning. More tools will be needed to be able to explore ever more robust solutions and progressively reinvent the core technologies that underpin the web. And over time, all those tools will also need to become easier to implement and use to appeal to a broader user base, so that they unlock their full potential.

If we are able to achieve this, if we are able to shape tools that have the power to change the web as an environment, the fight for an independent web is not lost, because as Tim Berners-Lee put it at the Decentralized Web Summit: “You can make the walled garden very very sweet. But the jungle outside is always more appealing in the long term.” So let us make the jungle of the independent, open web shine. Let us start coding, start designing, start building these tools.

It Takes a Nation of Millions to Hold Us Back

At the beyond tellerrand conference in Berlin, Tim Kadlec reminded us of the underlying promise of the web:

This short sentence comprises the promise of a world without the borders of the physical world, a promise of equal access to information and freedom of speech. This freedom is at stake and we need to protect it. Not because we, the people who create the web, are idealists, rebels, or revolutionist. We are ordinary people, just like the teenagers who use social media every day and just like the 83-year-old grandmother who loves to read the news on her iPad. But we happen to be the ones who know how to change the workings of the web. We are a worldwide community of creators and this brings with it a huge responsibility. Taking this responsibility seriously means becoming an active member of a community that helps to keep the promise of an independent and open web alive, and by this sustaining an active counterbalance to global mass surveillance and the corporate web. This may seem idealistic at times. But even the smallest changes can be transformative and if we don’t fix the web, one small step at a time, nobody will.

It is in our hands to shape the future of the web, or as Wilson Miner put it in his 2011 Build conference talk:

“The things that we choose to surround ourselves will shape what we become. We’re actually in the process of building an environment, where we’ll spend most of our time, for the rest of our lives.”

–

Header image shows Jon Postel and colleagues working in room 3420 at UCLA's Boelter Hall campus – the birthplace of the internet. Image retrieved via Kleinrock Center for Internet Studies at UCLA

Invasion of the Data Snatchers

Global surveillance is real and it’s not going anywhere.

On January 20th, 2017, we all witnessed one of the most worrying political events in recent history. A nationalist authoritarian became the 45th president of the United States of America and is now in charge of the most comprehensive, most aggressive, and most intrusive mass surveillance apparatus ever created (sorry, Stasi). The new U.S. administration is presumably going to further strengthen the power of their intelligence agencies and broaden its mass surveillance activities. The “law and order candidate” also heavily attacked the free press and already suspended the protections of the Privacy Act “for persons who are not United States citizens”, which many see as a first step to undermine the data transfer framework of the EU–US Privacy Shield. And today, US congress voted to overturn privacy rules from late last year, which effectively means cellphone providers are now allowed to sell people’s browsing and app activity without asking their permission.

But also across Europe, privacy rights and freedom of speech are increasingly under attack: A recent report by Amnesty International documents a dangerously disproportionate, ever-expanding security state. The UK, France, Germany and many other states have widened the power of their intelligence services to collect and store phone and internet connection data – often even without judicial authorization. May it be for fear of terrorism, for fear of economic backlash – or simply for fear of losing control: Everywhere around the world, democratic governments as well as authoritarian regimes prepare for cyber warfare and start collecting every bit of data they can grasp with increasingly sophisticated tools.

What’s so deeply worrying about this development is that the idea of a fundamental right to privacy is slowly eroded. With every new leak, we accept ever more that there seems to be nothing we can do about it, anyway. And if we have nothing to hide, surveillance will only be a threat to those who deserve to be observed, right? But who decides which individuals are to become a target? Who sets the moral standards which define what is wrong and what is right? What happens if a new government that adheres to racist ideologies or simply doesn't care about anything else than their own wealth, gets handed over the keys to the surveillance kingdom?

But it is not only governments – a whole industry is collecting user data at a scale beyond imagination. And while some of us may be fine with paying for services with personal data, I doubt that most users realize just how much freedom and control is taken away from them and how far-reaching the measures taken by the data economy already are.

The data you produce every day, may it be by browsing the web or actively participating on social media platforms, already tells so much about who you are as an individual. It really is not only some data, it is you – just like the furnishings, books, pictures, and little mementos in your apartment tell a story about your life. Even more so: Based on Facebook Likes, modern algorithms already can predict personality traits more accurately than close friends and family members. Facebook is also routinely running all your personal photos through artificial intelligence algorithms to identify faces and automatically adds tags. While this definitely improves accessibility for blind people, it is also quite useful for user profiling and thus: ad targeting. If you want to get an idea of the sheer scale of Facebook’s tracking efforts and what it does with the data, this article by Vicki Boykis is a must-read: What should you think about when using Facebook?

Billions of internet-connected devices upload our most personal data into the cloud where it can be accessed by corporations and governmental services. We have lost control. So the need to act is as real and urgent as ever. Not only if you are part of a minority, if you care about free speech, or simply want to keep things like your health records private, you need to take action.

Protect Ya Neck

Protecting your privacy is not a crime and does not make you suspicious, especially if more and more people start to protect themselves. Privacy is a universal right that needs to be protected because it protects you from suffering injustice. That’s why it is also part of the Universal Declaration of Human Rights:

So how can we – as global web citizens – protect our privacy?

Encryption is the only effective way to protect your communications and browsing data at the moment and actually works quite well. So a good starting point would be to install an end-to-end encrypted messaging app like Signal or Wire on your smartphone to keep your private messaging and phone or video calls secure.

Next up is email. Remember: Email was not really designed with any privacy or security in mind, so basically all unencrypted messages can be read. The NSA, for example, is able to “listen to whatever emails they want” through tapping into central network points. (And they might also not be very impressed by that cute confidentiality notice in your signature.) Email can be encrypted with PGP [1 / 2 / 3] or S/MIME. Alternatively, you can create an account at an encrypted email service like Proton (based in Switzerland) or Tutanota (from Germany). If you’re running your own email server, consider delivering mail over Tor’s hidden onion services.

Another promising tool is Keybase. Keybase is a public directory of people and also offers a command line client including Tor support and a free, open source security app. With the app, you can connect and chat with other Keybase users and even exchange files through public and private folders – and everything is encrypted.

For safer browsing, especially when you access the internet via public or hotel WiFi, consider the use of Tor and its Tor Browser (a modified version of Firefox) or a VPN service like Mullvad. If they are used in the right ways, both Tor and using a VPN provide good protection against traffic analysis and prevent the sites you visit from learning your physical location. Tor Browser even helps to protect you from browser fingerprinting, a technique where available features and certain properties of your browser like installed plugins or a list of system fonts are used to create a unique fingerprint of your system.

The Electronic Frontier Foundation offers further useful guidance and tools for safer online communications on their surveillance self-defense website, for example Privacy Badger, a browser plugin that blocks spying ads and invisible trackers.

What measures you take to protect your privacy is totally up to you, of course. It also depends on the level of security you need: Journalists, lawyers, activists, scientists will all surely need more protection to operate freely than “normal” users who just want to buy some clothes online. But still, we must not go on like nothing happened. Changing some of your habits and protecting yourself will have a small impact, but it has an impact. First on you, then on others. So get involved but also make sure to talk to friends and relatives about the topic. You'll be surprised how less they really know – and thus care.

Change Is the Law of the Web

The way the web works in the future will be influenced by forces of all kinds. If some of those forces want to undermine privacy and other basic civil rights, it is up to us to act as a counterbalance. It is up to us in which direction the web evolves and which forces are being emphasized. If we want to protect everything we have come to love about the free, independent web, we need to act now. In fact, we will need to develop the web further, but in the right direction. This includes that we understand, that we as web citizens are part of something that is far bigger than us, yet it still can be influenced and shaped in a positive way. As Tim Berners-Lee points out, “it has taken all of us to build the web we have, and now it is up to all of us to build the web we want.”

And while protecting our communications data is a good first step towards a more secure and independent online experience, taking back control over our data eventually means reconsidering the way we create and consume content online. So the second part of this series will highlight concepts and ideas about how we can build and promote a new set of tools which enable an open, independent, and resilient web. A web for everyone.

–

Header image shows a distorted version of John Trumbull's painting “Declaration of Independence” that depicts the presentation of the draft of the Declaration of Independence to Congress. Original image is in the public domain, retrieved via Wikimedia Commons

This observation is as true as it is often neglected. If you ever have created or worked with style guides and pattern libraries, the following process might sound familiar: Quite a few elements of a design, like buttons or typographic elements are defined beforehand, without much or even no context at all. Other elements though are indeed created to solve very specific problems in very specific contexts. But as soon as they become part of a pattern library, all those patterns suddenly are treated as immutable rules, absolute truths carved in stone. Ultimately, they are used to solve totally different problems, problems for which they might not be the best solution because the context is different now.

For design patterns, context really is crucial. Context is crucial if you want to establish a visual hierarchy. Context is crucial, if you want to balance out the elements of your design system against each other. Context is crucial with regards to responsive design: What happens to a component at different screen sizes? Context is crucial in terms of progressive enhancement: What happens to a component if the network fails or an advanced feature is available on a specific device?

This is also why Ethan suggests that our pattern libraries could be more than just interface snippets and that we should instead “discuss and document patterns in the context of how and why they were made.” This includes that we should go further than just describing how something looks and how it can be implemented, but also “describe the compromises we make — the forces we resolve — when we design (and use) our patterns.” What a worthwhile goal.

While I pondered over how one could be more mindful of context when creating pattern libraries, I remembered John Maeda’s three C’s of design. They are:

Content: There needs to be a message or meaning. Everything needs a reason to exist, otherwise it shouldn’t.

Context: Content doesn’t live in a vacuum. A Chanel bag sitting on a shelf at Wal-Mart will only confuse.

Contrast: An element is made stronger when a counterelement is offered. Salt tastes saltier after one has had some sugar.

Those three core principles of design – content, context, and contrast – provide a foundation for practical and purposeful design solutions. And because patterns are not simply rules but “represent our shared understanding of design solutions”, why not take the idea of considering context even further and use those three C’s to better describe our patterns?

For a specific component, we could for example check how it is defined and shaped by the three C’s:

Content: Why does this component exist? How does possible content look like? Is the content allowed to change and, if yes, how? If the content changes, how does this affect the component?

Context: How does the component look in different contexts? Does it maybe change and adapt depending on where it is used (pages, header, footer, etc.)? Does it have improved accessibility features? Is it influenced by other components? Does the component depend on or react to certain device capabilities? Does it work offline or only under certain conditions?

Contrast: What makes the component distinct, what makes it stand out against other elements of the system? Are there interdependencies with other components that change the perception of the element so that the appearance needs to be adjusted to (still) achieve the desired outcome?

These are all just some first quick thoughts, but I really like the idea of thinking about patterns on this qualitative level. Also because the success of a pattern library – or a style guide – depends on two main characteristics: For one, it should be accurate, deliberate, and comprehensive enough to provide guidance and a solid framework to work with. At the same time, it needs to be flexible enough to allow for innovative, diverse applications and thus practical solutions to a multitude of problems – which also includes that it is allowed to grow and change over time.

Both accuracy and flexibility can only be achieved if we are able to judge if an element is the right solution to a specific problem, and for this, we need a clear understanding of its purpose and its qualities. If we describe patterns also in terms of content, context, and contrast, we are able to define more precisely what a specific pattern is all about, what its role within a design system is, and how it is defined and shaped by its environment. And this will certainly make our pattern libraries better. Because a pattern never exists in isolation.

–

Header image shows Nakagin Capsule Tower, Tokyo, the world's first example of capsule architecture, photo by Dick Thomas Johnson licensed under CC BY 2.0, slightly edited and color corrected.

Mike Monteiro – Let Us Now Praise Ordinary People

Mike Monteiro is a designer. Together with Erika Hall he founded Mule Design, an interactive design studio based in San Francisco. He shared his experiences with the community in two books, Design Is a Job and You're My Favorite Client and never gets tired of calling for designers to take responsibility for the work they put into the world – most famously in his .net Talk of the Year 2014 How Designers Destroyed the World.

Whether or not you like his upfront style, Mike surely is a force of nature. His talk left the audience greatly impressed and some even deeply moved. In times where young white boys design services that obviously fail to address the needs of women and minorities for the sake of venture capital, where guns that are built so simple that a child can use them are sold on Facebook, where huge masses of refugees are winding their way through Europe, and a bigot and racist is elected U.S. president, Mike acts as a voice of conscience. If we really want to change the way the world is designed, we need to change who gets to design it. Just being empathic with the people we design for isn’t enough, because this doesn't solve the real world problem of exclusion. Instead what we need is real inclusion. But what is real inclusion then? Mike puts it bluntly: “Don’t assume how a woman would behave in a situation. Hire a woman to design it.”

Ultimately, designers need to take on the responsibility that comes with having the power to create things. A responsibility that also arises not from being special, but from being just as ordinary as anyone else on this planet. We just don't get to opt out. I cannot recommend this talk enough: It is a clarion call to action for our community that can provide an answer to the question of how to cope with a reality that seems to be out of joint.

Watch Mike's talk on Vimeo.

Tim Kadlec – Unseen

In his elaborate and entertaining talk, Tim reminded us that the web is meant to be for everyone, so we need to find ways to guarantee equal access and great experiences not only for users with huge data plans and fast devices. It is inherent in the web that it is less-than-ideal and often unpredictable, which is why we need to first get rid of our assumptions if we want to build resilient systems and instead focus on the fundamental pillars of a good web experience: Performance, accessibility, and security. The problem is that they are mostly hidden from sight for the average user and only become visible, when a system fails. So it is important to make those unseen features visible as early as possible for everybody involved in a project and by that making it the responsibility of everyone.

Tim Kadlec is a web performance advocate and head of developer relations at Snyk. He has written a book about Implementing Responsive Design and embracing the inherent flexibility of the web. Tim regularly publishes articles on his site that are really worth reading, for example the one in which he invites us to Blame the Implementation, Not the Technique or when he writes about Setting a Performance Budget or Chasing Tools.

Watch Tim's talk on Vimeo.

Heydon Pickering – Writing Less Damn(ed) Code

Ever since Heydon invented the “lobotomized owl selector” ( + ) and wrote about it on A List Apart, he has been known as someone who thinks outside the box. Moreover, he is a renowned advocate for accessible and inclusive design, working with The Paciello Group and Smashing Magazine. Just recently he published his wonderful book Inclusive Design Patterns, which I highly recommend.

Heydon took us on a wildly entertaining adventure that was a mixture of thought experiments on code (and responsibly writing less of it) and also quite useful advice. For example, he shared a well-rounded exit strategy if someone mentions the word “carousel” in a meeting. Besides the monumental breakthrough discovery that less is actually less and not more, as the inspirational designers are trying to make us believe, Heydon even introduced many revolutionary concepts like, for example, “unprogressive non-enhancement” or his own super-awesome progressively enhanced 93 bytes (minified) fits-in-a-tweet grid framework: FUKOL. Thanks for a glorious performance, Heydon!

.fukol-grid{display:flex;flex-wrap:wrap;margin:-.5em}.fukol-grid>*{flex:1 0 5em;margin:.5em}

— Heydon (@heydonworks) 4. Oktober 2016

You can watch Heydon's talk here.

… and many more

As I said before, the overall quality of the talks was excellent. Videos for all talks from beyond tellerrand Berlin are already on Vimeo and YouTube, so please make sure you also have a look at some more and see for yourself what your favorites are. It’s really worth it. Also have a look at Marc Thiele's coverage post, in which he lists all blog posts, photos, videos, and much more interesting facts about the conference. We drank a total of 256 liters of coffee, for example…

Since that time, the web has grown up and with it, making websites has become increasingly complex. I am not only talking here about the wealth of development tools like APIs, libraries, frameworks, linters, pre- and post-processors, build tools, boilerplates, and generators that our industry uses today and which continue to grow in number and depth at tremendous speed. Increased complexity is not a development issue alone. Increased complexity is a phenomenon that affects all areas of creating for the web. Let me take web typography as an example.

A Few Good Friends

Back in the 1990s, web designers only had a really limited number of fonts to choose from: Web-safe fonts, this smallest subset of system fonts that is most likely to be installed on most of the users’ machines. So the decision process usually went something like this:

Serif?
Use Times New Roman or Georgia.

Sans-serif?
Pick Arial / Helvetica, Verdana, or Tahoma.

Monospace?
Courier New.

And because the overall on-screen readability of fonts was pretty bad back then, there was another vastly popular option: Pixelfonts.

From a typographical perspective, working with such limited options was often challenging, because you had to stick to the few fonts available. But you could easily learn the constraints of the medium within no time and then get used to it.

An Explosion of Possibilities

Today however, we have hundreds of thousands of typefaces to choose from and dozens of different techniques for getting the fonts onto our websites. We can either host them on our own servers or use free or paid services like Google Fonts, Typekit or Webtype. We need to address (rendering) performance issues and find ourselves struggling with things like FOIT, FOUT, and FOFT, which is why we should be aware of the many different and ever evolving webfont loading strategies. We are able to use powerful OpenType features like ligatures and alternates, and we even enjoy proper kerning! If we want to provide the best possible user experience for all the different device types out there – which is of course always what we want to do –, we also have to consider the responsive behaviour of typography. And even the important conclusion that we need to embrace the uncertainty of the medium and the fragility of web typography as a feature – as exciting as this challenge may be – doesn’t make things easier, to be honest.

While this richness provides us with great flexibility and a variety of ways to express ourselves, it also makes it harder for beginners to learn what it takes to build a thing for the web. Compared the 1990s, the multitude of options to choose from and new things to learn is so enormous that it can be really overwhelming for the next generation of designers and developers.

But not only newcomers are having a hard time catching up with all the different techniques. Many designers and developers with decent experience see similar problems regarding their own daily work: Keeping up with the current pace of innovation is not impossible, but still a major challenge. It requires constant research while staying curious, combined with the ability to reflect on current developments to be able to pick the right tools for new projects. It’s almost a full-time job. What makes it even harder, is that many agencies and studios still don’t reserve dedicated time for the necessary research and advanced training and expect it to happen, well, magically. Which is to say: in your spare time. And ain’t nobody got time for that, right?

Web designers and developers! How much effort is needed today to keep up with the latest trends & tools? Please RT!

— Matthias Ott (@m_ott) 15. Juli 2016

So for the majority of beginners and seasoned professionals we can observe growing knowledge gaps compared to the industry leaders and a relatively small percentage that somehow manages to keep up with the pace of innovation. For the sake of the further development of the web, we need to find a way to close these gaps. On the one hand, we need to make sure that the next generation of designers and developers is ignited in the way we were, so that we continue to see the best aspiring talent choosing the web as their profession. On the other hand, in order to further raise the quality of what gets created, it is equally important that seasoned professionals don’t lose confidence in the power of the web and keep pushing at the edges of what is possible.

But how?

Education: Laying a Solid Foundation

When we think of ways to bridge those knowledge gaps with the help of the educational system, we soon realize that trying to always teach students the newest tools would be a Sisyphean task: As soon as students are ready to use a tool in the wild, chances are that it will soon be gone. This is exactly what happened to me: I created my diploma project with Flash, for which I learned how to code in ActionScript – just to see Flash being wiped away shortly thereafter. Remember Macromedia FreeHand? It used to be our favorite tool for vector illustration works, until Adobe bought Macromedia and decided to discontinue FreeHand. Others were using Director in their projects, or Fireworks. Both discontinued. I think you get the point: Tools come and go. Tools are temporary.

But this doesn’t mean that we should jump to the conclusion that learning new tools is unnecessary. Because tools might be out of date one day, but one thing won’t: Basic concepts. Flash might be gone, but through it I learned how to code in an object-oriented programming language, I read a book about ActionScript design patterns and by this developed a basic understanding of, for example, the model-view-controller pattern. FreeHand might be a thing of the past, but through it I mastered the skill of drawing vectors which would later help me draw a font, logos, icons, and other graphics.

Almost every tool you learn shapes a basic understanding of some underlying core principle. And while tools are only the vehicle, those basic concepts are the road that guides your way. They are the foundation you will always be able to refer to when in doubt. The same is true for the basics of typography, for example. Concepts like balancing contrast, rhythm, and proportion(s), defining font sizes, line height, leading, kerning, and measure will become constant and reliable companions throughout your professional life. Because fundamental knowledge like this forms the foundation of what we create, often developed by others over the course of centuries and therefore here to stay. Basics are permanent.

So whether you are a student or a professional: Don’t hesitate to jump right into the hottest tool that the cool kids are using right now. Try to soak up as much of it as you can. But also try not to concentrate on the peculiarities and quirks of the tool too much. Instead, focus on the core functionalities and the underlying concepts. Try to extract the essence.

Practice: Creating a Learning Environment

As mentioned earlier, the rapid advancement of our industry leads to a high need for on-the-job training for professionals as well. The times where you could learn the most necessary things for a job – also known as „to finish your studies“ – and then go out and practice your craft for the next 40 years are long gone. Yet still many agencies, especially if their roots are in advertising or editorial design, still haven’t changed their culture accordingly. It used to be that they would look for well-trained and talented young people and then let them work on different jobs just as they came along. And there was nothing wrong with that as long as the only things that changed were brought to you by the guy from the paper company with the newest coated paper products, the printer who introduced you to a new finishing technique, or the type foundry that sent you a beautiful specimen of a new typeface you could then use in one of your next projects. That is not to say that everything was easy and that there was less craftsmanship involved. To the contrary: Maybe we also lost a bit of the creative power and virtuosity of those days. But things surely were different – more predictable, more reliable, steady. And so there was less need for training your staff.

Our fast-moving times call for new approaches to how we combine working with learning. Establishing such a culture of learning is key to remaining successful when the only constant is change. In agencies, this could mean to foster the exchange of knowledge between employees and between project teams. And by that, I don’t mean setting up a Wiki and hoping for the best. A culture of knowledge exchange starts with the realization that there is no such thing as a stupid question and that sharing your knowledge, even the smallest bit, is basically a good thing. Although it might sometimes seem like a waste of time compared to other tasks – an organization where everybody has a solid understanding of the problems that are being solved, will in the end be more efficient and effective in every respect, because teams will find solutions that are more creative in nature by combining existing knowledge in unexpected ways and which tap the potential of current possibilities to a greater extent. So the primary goal should be to create an environment where information can flow freely from one person to another and thus constantly learning new things in your job becomes the norm.

The ways to achieve this will of course vary from organization to organization and they also need to fit into organizational structures and habits. For example, it can be a great idea to set up a Slack channel to collect the most valuable links and new resources. You could also schedule weekly learning meetings, where everybody contributes something valuable and explains it to the team. Collaborative design or code reviews can help bridge knowledge gaps between team members and thus be really worthwhile. All of those measures can facilitate knowledge exchange and are a first step towards a workplace where research and knowledge exchange are integral elements of the organizational culture. But to really get learning – and teaching – baked in into your organization, it needs to gain center stage.

Apprenticeships

Daniel Mall recently gave a talk at 99u about an interesting concept that could provide just that combination of on-the-job learning and teaching: apprenticeships. An apprenticeship can basically be thought of as a replacement for the good old internship. The main idea is, that instead of just using the work power of an untrained intern as needed, an apprenticeship opens up the opportunity to teach young talent on-the-job, let them test their hypotheses, and guide them through the multitude of available options. Ultimately, an apprenticeship can be the starting point to create well-rounded professionals. It is also a way to take the responsibility seriously that comes with being part of a much larger community and, as Ivana McConnell writes in her great essay on apprenticeships in the creative industry, means to “value learning, our craft, and each other.”

So there is a lot organizations can do already to create a culture of learning that will make ideas thrive and help close the knowledge gaps in the professional field. And I am sure that we will continue to see really exciting approaches in the future. But in the end, the most important factor is the individual.

Individuals: Learning to Explore

When it comes to how individuals keep themselves up to date, one thing certainly is a prerequisite: curiosity. Without curiosity and the spark resulting from it, nobody will walk the extra mile that is sometimes required to finish a book, explore a new technique, or acquire a new skill. But beyond that, everybody has to find a way that fits to personal habits and preferences.

Jonathan Snook, for example, shared his learning process in his post How do I learn?. He identified three phases in his process:

1. Reading
2. Building
3. Writing

In the reading phase, he will read a lot and by that acquire an overview of what is new out there. The second phase is where he explores how something works by building something with it. The last step is to write about a thing which deepens the understanding even further. I experienced the same with teaching: The need to communicate how something works requires a deeper understanding and broader exploration of the edges of a topic.

Slowly but Surely

Combining working with learning and finding a routine for exploring new ground as an individual won’t happen overnight, but it is certainly worth it. So go talk to your colleagues about how you could improve the current situation. And then learn, explore, and share your knowledge and experiences, may it be through mentoring, teaching, or writing. But also ask yourself: What are the basics that I want to build upon? Which tools do I really want to learn? What are the tools you feel the most comfortable with? Because as Bastian Allgeier put it: “If we stop moving, we die. But we don’t have to jump all the time.”

I for myself will start by sharing in my next posts what I do to stay up to date and what I hope can be a good starting point for you. But in the meantime: What do you do to stay informed? How do you learn new stuff? Does your employer offer anything that facilitates on-the-job learning? Do you have an idea that you would like to share? I’d love to hear from you – via Twitter, email, or through a follow-up post.

Let us close those gaps together.

–

Header image shows the Manhattan Bridge under construction, 1909.

Here's to the curious

First of all, there is the great variety of topics. Conference organizer Marc Thiele repeatedly manages to get speakers from the most diverse fields of work to his events, so the name (“beyond tellerrand” loosely translates to “beyond one's own nose”) really says it all. Beyond tellerrand allows you to hear talks about user experience design, image performance optimization, time and creativity, game design, typography, the reinvention of normal, the security issues of AngularJS, CSS animation, great advice to young (and not so young) designers, the internet of things, type design of a coding font, progressive enhancement, and the work of Mr. Bingo – all on the same track. The diversity of the topics of the talks at beyond tellerrand is maybe unparalleled and each one of the talks was interesting and entertaining but most importantly: highly relevant in covering current topics. The only topic that I missed a little this time was accessibility, but Heydon Pickering will surely tackle that at the next beyond tellerrand in Berlin (07–09 Nov 2016).

What happens if you have such a diverse mixture of speakers and topics is this: You are continuously confronted with new things, with new thoughts, new concepts, and new ways of approaching problems. And not only do you learn something new by that, you also challenge your assumptions, you start thinking in new ways, you sometimes even rewire your brain.

But hey: You could just as well stay at home and watch most of the talks on Vimeo. So why go there after all?

Here's to the people

The answer is: people. The web community is a vibrant community that to a great extent exists in the digital space. However, the real-world experience of a conference is something that is hardly reproduced in a purely virtual space. The atmosphere at beyond tellerrand is really relaxed, open, and welcoming, so you will surely have a lot of nice and inspiring conversations between the talks – and in the evenings too, of course. ;)

During the four days at the IndieWebCamp and beyond tellerand, I got to know so many nice and interesting people, and enjoyed the most diverse and inspiring talks, so that I left Düsseldorf deeply satisfied and full of new ideas (although they are only new combinations of old ones…). Thanks to everyone I had the chance to meet!

See you in Berlin!

Proper planning? 

To some extent, this analogy totally makes sense. Setting up a timeline and having a clear goal to aim at, and be it only a red-letter day, can indeed have a positive impact on the intensity and progress of work. And it can also be argued that there is some importance in making a good first impression, especially if your work is targeting a bigger audience. Setting a launch date has therefore been a valid strategy in many projects, and it surely will continue to be valuable.

But there is a downside in approaching a digital project like a rocket launch: Websites aren't rockets. Rockets are built for a specific mission and after serving their purpose, they end up as space debris. End of story. Websites are different, though. The moment you launch them, their story has only just begun. 

Time is change. Friend or foe.

This story needs to be part of your planning. Because as sophisticated your strategy and thoroughly crafted your design might be, the only thing that's certain is change: Your users will change, their device preferences will change, their usage behavior will change. Technology will continue to change at lightning speed, making things look outdated in the blink of an eye and requiring new solutions, but at the same time opening up new, boundless possibilities. And also your competitors might change – but so might you, your brand, your product, your content.

Not being able to flexibly react to those changes can be harmful. In the best case, you will have to invest most of the money, resources, and effort that went into the launch once again in five years, because your product is not up-to-date anymore. But maybe you realize that you invested a lot into features that turned out to be not as beneficial as expected. And if you did not prepare for adjustments upfront, making changes to your product will now be much more expensive and tedious when existing structures have to be broken up again and everybody is already working on the next project. In the end, your customers might even go to your competitors who get it right. So you better be prepared for change.

Plan for change

While most physical products can't be improved much once the customer carried it home from the mall, a digital(ly enhanced) product is not only able to change, most of the time this is where digital really shines: You are able to react to your user's behavior and feedback. You are able to improve features like accessibility and performance. Planning for change is not that hard, but it has to be done early to really get everybody on track and because it can impact decisions right from the beginning. That’s also why simply including a support budget for „all those changes“ is definitely not enough. You need to approach your project like an ever changing product from day one, because that's exactly what it is going to be.

Depending on your project, you then might ask yourself some interesting questions like:

• Does our workflow facilitate continual improvement?
• Do we have a strategy for failure?
• Does our content strategy include a flexible solution for content management?
• Is our design flexible enough to easily make changes?
• New devices occur every day: Is our design robust and responsive enough?
• Are we independent enough from technological trends? For example, do we really need that fancy third-party framework? What happens if the framework changes?
• How about progressive enhancement?
• Who will monitor the success of the product once it is up and running?
• Who will be responsible for changes? Do we need a team that takes care of the product? Do we maybe need a team that does this 24/7?

Restart on repeat

We are living in most exciting times, with disruption at every corner and huge economic and social challenges ahead. In order to master the future, embracing change is crucial.

Both we as web professionals as well as our clients have to overcome the idea that the success of digital products can be planned beforehand. If we acknowledge the fact that change is inevitable and that in a lot of cases our educated guesses are only guesses, we will change how we approach projects. This is not to say that we should stop planning. But we should instead start planning for continuous change and come to love the flexibility that is inherent to the medium we are designing for. We should learn to restart on repeat.