Link tags: communication

Stay alert - DEV Community 👩‍💻👨‍💻

It’s not just a story about unloved APIs, it’s a story about power, standards design, and who owns the platform — and it makes me afraid for the future of the web.

A thoughtful, considered post by Rich Harris on the whole ballyhoo with alert and its ilk:

For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.

Choice Words about the Upcoming Deprecation of JavaScript Dialogs | CSS-Tricks

Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.

Google vs. the web | Go Make Things

With any changes to the platform, but especially breaking ones, communication and feedback on how this will impact people who actually build things with the web is super important, and that was not done here.

Chris has written a thoughtful reflection on last week’s brouhaha around confirm, prompt, and alert being deprecated in Chrome. The way that the “developer relations” folks at Google handled feedback was less than ideal.

I reached out to one of the Google Chrome developer advocates I know to see if I could learn more. It did not go well.

Sans Bullshit Sans — Leveraging the synergy of ligatures

As part of my content buddying process, I am henceforth going to typeset all drafts in this font. I just tested it with this sentence:

We can leverage the synergy of a rich immersive user paradigm shift.

Words To Avoid in Educational Writing | CSS-Tricks

This old article from Chris is evergreen. There’s been some recent discussion of calling these words “downplayers”, which I kind of like. Whatever they are, try not to use them in documentation.

Let’s Not Dumb Down the History of Computer Science | Opinion | Communications of the ACM

I don’t think I agree with Don Knuth’s argument here from a 2014 lecture, but I do like how he sets out his table:

Why do I, as a scientist, get so much out of reading the history of science? Let me count the ways:

1. To understand the process of discovery—not so much what was discovered, but how it was discovered.
2. To understand the process of failure.
3. To celebrate the contributions of many cultures.
4. Telling historical stories is the best way to teach.
5. To learn how to cope with life.
6. To become more familiar with the world, and to know how science fits into the overall history of mankind.

A Wire Across the Ocean | American Scientist

Ainissa Ramirez recounts the story of the transatlantic telegraph cable, the Apollo project of its day.

How to be clear – gilest.org

Good advice for writing:

• Think about what your readers might already know
• Write shorter sentences, with simpler words
• Constantly think about audiences
• Communicate with purpose
• Clear communication helps teams solve problems

How Claude Shannon’s Information Theory Invented the Future | Quanta Magazine

Shannon is not exactly a household name. He never won a Nobel Prize, and he wasn’t a celebrity like Albert Einstein or Richard Feynman, either before or after his death in 2001. But more than 70 years ago, in a single groundbreaking paper, he laid the foundation for the entire communication infrastructure underlying the modern information age.

People Problems | CSS-Tricks

I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.

Why Do We Interface?

A short web book on the past, present and future of interfaces, written in a snappy, chatty style.

From oral communication and storytelling 500,000 years ago to virtual reality today, the purpose of information interfaces has always been to communicate more quickly, more deeply, to foster relationships, to explore, to measure, to learn, to build knowledge, to entertain, and to create.

We interface precisely because we are human. Because we are intelligent, because we are social, because we are inquisitive and creative.

We design our interfaces and they in turn redefine what it means to be human.

The Curse of Knowledge · Matthias Ott – User Experience Designer

A great explanation of the curse of knowledge …with science!

(This, by the way, is the first of 100 blog posts that Matthias is writing in 100 days.)

Why does writing matter in remote work? — Tim Casasola

Some good writing advice in here:

• Spell out your acronyms.
• Use active voice, not passive voice.
• Fewer commas. More periods.

Is it time for a Web Performance rebrand? – Simon Hearne

I think Simon is onto something here. While the word “performance” means something amongst devs, it’s too vague to be useful when communicating with other disciplines. I like the idea of using the more descriptive “page speed” or “site speed” in those situations.

Web Performance and Web Performance Optimization are still valid and descriptive terms for our industry, but we might benefit from a change to our language when working with others. The language we use could be critical to the success of making the web a faster and more accessible place.

Through a design system, darkly. — Ethan Marcotte

1. Design systems haven’t “solved” inconsistency. Rather, they’ve shifted how and when it manifests.
2. Many design systems have introduced another, deeper issue: a problem of visibility.

Ethan makes the case that it’s time we stopped taking a pattern-led approach to design systems and start taking a process-led approach. I agree. I think there’s often more emphasis on the “design” than the “system”.

s08e05: There’s only one rule that I know of, babies - Things That Have Caught My Attention

A global communications network now exists that’s cheap enough or in some cases even free to access, offering a pseudonymous way for people to feel safe enough to share a private experience with complete strangers? I give Facebook and Twitter a bunch of shit for their rhetoric about a global community (no, Facebook’s billions of users are no more a community than the television-watching global community) and creating authentic connection, but I will very happily admit that this, this particular example with people sharing what it is like to be me and learning what is it like to be you is the good.

This is the thing that makes free, open, networked communication brilliant. This is the thing that brings down silos and creates common understanding and humanizes us all, that creates empathy and the first steps towards compassion.

That someone can read about this insight and have a way to react to it and share their perspective and not even know who else might read it, but feel safe in doing so and maybe even with the expectation that this sharing is a net good? That is good. That is what we should strive for.

Guide to Internal Communication, the Basecamp Way

Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.

This one feels like it should be Somebody’s Law:

If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.

Level of Effort | Brad Frost

Brad gets ranty …with good reason.

Design APIs: The Evolution of Design Systems by Matthew Ström

This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.

Frank Chimero Redesign Blog: The Popeye Moment

Frank is redesigning in the open. Watch this space:

By writing about it, it may help both of us. I can further develop my methods by navigating the friction of explaining them. I’ve been looking for a way to clarify and share my thoughts about typography and layout on screens, and this seems like a good chance to do so. And you? Well, perhaps the site can offer a clearly explained way of working that’s worth considering. That seems to be a rare thing on the web these days.