Ethan Marcotte:

I’ve been in this industry long enough to know that predicted futures have a pretty short lifespan.

It’s ironic: in an industry proud of being “data-driven”, the data on failed, predicted futures has as much influence on people’s perceptions going forward as a fart in the wind.

This line resonates:

design applications have made it much easier for designers to work together; development applications have made it easier for developers to work together.

But...the gap between each discipline’s workspace hasn’t changed significantly.

At the end of February, WebAIM published an accessibility analysis of the top one million home pages. The results are, in a word, abysmal...And we failed. I say we quite deliberately. This is on us: on you, and on me. And, look, I realize it may sting to read that.

But this piece isn’t just a criticism. I like Ethan’s resolution towards building a more-accessible web. It’s a practice I think I could incorporate into anything I want to learn.

The only way this work gets done is if we start small, and if we work together. Instead of focusing on “accessibility” writ large...aim to do one thing this week to broaden your understanding of how people use the web, and adapt your design or development practice to incorporate what you’ve learned.

Or at least, that’s what I’m going to do. Maybe you’d like to join me.

I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Later:

the visual languages we formalize—they’re artifacts that ultimately live in a broader organizational context. (And in a context that’s even broader than that.) A successful design project understands that context before settling on a solution

I totally agree with Ethan’s assessment here. People are always saying “the web is slow, here’s how to make it fast” and they solve the problem from a technology perspective. But the mainstream web isn’t primarily slow because of an ignorance in how to make it fast. It’s slow because at the core of the web’s essence (and this is something that I think just happened organically over time) people expect everything on it to be free. So money has to be made somewhere, and it gets made by the boatloads of tracking/analytics JavaScript and other bloated bandwidth that ends up on websites.

ultimately, the web’s performance problem is a problem of profitability. If we’re going to talk about bloated pages, we should do so in context: in the context of a web where digital advertising revenue is cratering for publishers, but is positively flourishing for Facebook and Google. We should look at the underlying structural issues that incentivize a company to include heavy advertising scripts and pesky overlays, or examine the market challenges that force a publisher to adopt something like AMP.

Let’s stop kidding ourselves. This is the core issue.

His wording was specific to CSS grid (which I’m also in the process of learning) but was a good articulation of how I also learn new technology:

1. “I’m going to learn how to use NEW TECHNOLOGY X to produce something I’m already familiar with.”
2. “Huh, I can produce this thing I’m familiar with using NEW TECHNOLOGY X way more efficiently than I ever could before.”
3. “—okay, now I’ll try making something with NEW TECHNOLOGY X I’ve never even considered.”

Ethan commenting on the design exercise he often does at conferences and workshops of printing webpages then cutting up the UI into pieces in order to find patterns. An exercise in designing language before any exercise in designing UIs can be critical to success. Words have meaning.

the primary benefit to creating a pattern library isn’t the patterns themselves...But rather...the language used to name, organize, and find patterns is what allows [us] to use those patterns effectively—and that is what creates more consistent designs...the words we use to talk about our design are, well, valuable design tools themselves.

Going along with another great post from Jeremy Keith, Ethan comments on the on-going controversy around Google’s continuing attempts to promote proprietary technologies (over open ones) with the AMP project. He draws an interesting parallel with the political climate today in America:

[the] trend of corporations-as-activists is the result of an ongoing politicization of the public sphere, which is itself the result of a government that’s unable (or unwilling) to serve its citizens

Then concludes:

the creation of AMP isn’t just Google’s failure, but our failure...of governance of our little industry. Absent a shared, collective vision for what we want the web to be—and with decent regulatory mechanisms to defend that vision—it’s unsurprising that corporate actors would step into that vacuum, and address the issues they find.

And once they do, the solutions they design will inevitably benefit the corporation first, and the rest of us second. If at all.