Tags: lang

296

sparkline

Friday, May 6th, 2022

wrong side of write

An opinionated blog about writing. I’ve subscribed in my feed reader.

Monday, April 25th, 2022

UI Pattern: Natural Language Form

I only just found this article about those “mad libs” style forms that I started with Huffduffer.

Sunday, March 27th, 2022

Artifice and Intelligence

Whatever the merit of the scientific aspirations originally encompassed by the term “artificial intelligence,” it’s a phrase that now functions in the vernacular primarily to obfuscate, alienate, and glamorize.

Do “cloud” next!

Monday, March 7th, 2022

Is HTML A Programming Language? (Webbed Briefs)

I’m glad that Heydon has answered this question once and for all.

I’m sure that’ll be the end of it now.

Thursday, February 3rd, 2022

When Women Make Headlines

This is a great combination of rigorous research and great data visualisation.

Friday, November 5th, 2021

Memories of Ajax

I just finished watching The Billion Dollar Code, a German language miniseries on Netflix. It’s no Halt and Catch Fire, but it combines ’90s nostalgia, early web tech, and an opportunity for me to exercise my German comprehension.

It’s based on a true story, but with amalgamated characters. The plot, which centres around the preparation for a court case, inevitably invites comparison to The Social Network, although this time the viewpoint is from that of the underdogs trying to take on the incumbent. The incumbent is Google. The underdogs are ART+COM, artist-hackers who created the technology later used by Google Earth.

Early on, one of the characters says something about creating a one-to-one model of the whole world. That phrase struck me as familiar…

I remember being at the inaugural Future Of Web Apps conference in London back in 2006. Discussing the talks with friends afterwards, we all got a kick out of the speaker from Google, who happened to be German. His content and delivery was like a wonderfully Stranglovesque mad scientist. I’m sure I remember him saying something like “vee made a vun-to-vun model of the vurld.”

His name was Steffen Meschkat. I liveblogged the talk at the time. Turns out he was indeed on the team at ART+COM when they created Terravision, the technology later appropriated by Google (he ended up working at Google, which doesn’t make for as exciting a story as the TV show).

His 2006 talk was all about Ajax, something he was very familiar with, being on the Google Maps team. The Internet Archive even has a copy of the original audio!

It’s easy to forget now just how much hype there was around Ajax back then. It prompted me to write a book about combining Ajax and progressive enhancement.

These days, no one talks about Ajax. But that’s not because the technology went away. Quite the opposite. The technology became so ubiquituous that it no longer even needs a label.

A web developer today might ask “what’s Ajax?” in the same way that a fish might ask “what’s water?”

Tuesday, October 26th, 2021

The impoverished language of business | Clearleft

A good post by Andy on “the language of business,” which is most cases turns out to be numbers, numbers, numbers.

While it seems reasonable and fair to expect a modicum of self-awareness of why you’re employed and what business value you drive in the the context of the work you do, sometimes the incessant self-flagellation required to justify and explain this to those who hired you may be a clue to a much deeper and more troubling question at the heart of the organisation you work for.

This pairs nicely with the Clearleft podcast episode on measuring design.

Wednesday, June 23rd, 2021

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.

Tuesday, June 8th, 2021

Deceptive dark patterns

When I was braindumping my thoughts prompted by last week’s UX Fest conference, I wrote about dark patterns.

Well, actually I wrote about deceptive dark patterns. That was a deliberate choice.

The phrase “dark pattern” is …problematic. We really don’t need to be associating darkness with negativity any more than we already do in our language and culture.

This is something I discussed with Melissa Smith after her talk on this topic. The consensus in general seems to be that the terminology is far from ideal, but it’s a bit late to change it now (I’m sure if Harry were coining the term today, he would choose a different phrase).

The defining characteristic of a “dark” pattern is that intentionally deceptive. How about we shift the terminology to talk about deceptive patterns?

Now, I get that inertia is a powerful force and it would be confusing to try do to a find-and-replace on all the resources that already exist on documenting “dark” patterns. So here’s a compromise:

From here on out, let’s start using the adjective “deceptive” in addition to the existing adjective “dark.” That’s what I did in my blog post. I only used the phrase “deceptive dark patterns.”

If we do that consistently, then after a while we’ll be able to drop one of those adjectives—“dark”—and refer to “deceptive patterns.”

Personally I’d love it if we could change the terminology overnight—and I’m quite heartened by the speed at which we changed our Github branches from “master” to “main”—but being pragmatic, I think this approach stands a greater chance of success.

Who’s with me?

Friday, June 4th, 2021

Beginner JavaScript Notes - Wes Bos

A very handy collection of organised notes on all things JavaScript.

Saturday, May 15th, 2021

Data isn’t oil, so what is it? - How To Measure Ghosts

The discussions around data policy still feel like they are framing data as oil - as a vast, passive resource that either needs to be exploited or protected. But this data isn’t dead fish from millions of years ago - it’s the thoughts, emotions and behaviours of over a third of the world’s population, the largest record of human thought and activity ever collected. It’s not oil, it’s history. It’s people. It’s us.

Tuesday, April 6th, 2021

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.

Saturday, April 3rd, 2021

Principles and the English language

I work with words. Sometimes they’re my words. Sometimes they’re words that my colleagues have written:

One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.

I also work with web technologies, usually front-of-the-front-end stuff. HTML, CSS, and JavaScript. The technologies that users experience directly in web browsers.

I think a lot about design principles for the web. The two principles I keep coming back to are the robustness principle and the principle of least power.

When it comes to words, the guide that I return to again and again is George Orwell, specifically his short essay, Politics and the English Language.

Towards the end, he offers some rules for writing.

  1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  2. Never use a long word where a short one will do.
  3. If it is possible to cut a word out, always cut it out.
  4. Never use the passive where you can use the active.
  5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  6. Break any of these rules sooner than say anything outright barbarous.

These look a lot like design principles. Not only that, but some of them look like specific design principles. Take the robustness principle:

Be conservative in what you send, be liberal in what you accept.

That first part applies to Orwell’s third rule:

If it is possible to cut a word out, always cut it out.

Be conservative in what words you send.

Then there’s the principle of least power:

Choose the least powerful language suitable for a given purpose.

Compare that to Orwell’s second rule:

Never use a long word where a short one will do.

That could be rephrased as:

Choose the shortest word suitable for a given purpose.

Or, going in the other direction, the principle of least power could be rephrased in Orwell’s terms as:

Never use a powerful language where a simple language will do.

Oh, I like that! I like that a lot.

Wednesday, March 31st, 2021

esoteric.codes

Languages, platforms, and systems that break from the norms of computing.

Tuesday, March 9th, 2021

Content buddy

One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.

Sometimes a colleague will send a link to a Google Doc where they’ve written an article. I can then go through it and suggest changes. Using the “suggest” mode rather than the “edit” mode in Google Docs means that they can accept or reject each suggestion later.

But what works better—and is far more fun—is if we arrange to have a video call while we both have the Google Doc open in our browsers. That way, instead of just getting the suggestions, we can talk through the reasoning behind each one. It feels more like teaching them to fish instead of giving them a grammatically correct fish.

Some of the suggestions are very minor; punctuation, capitalisation, stuff like that. Where it gets really interesting is trying to figure out and explain why some sentence constructions feel better than others.

A fairly straightforward example is long sentences. Not all long sentences are bad, but the longer a sentence gets, the more it runs the risk of overwhelming the reader. So if there’s an opportunity to split one long sentence into two shorter sentences, I’ll usually recommend that.

Here’s an example from Chris’s post, Delivering training remotely – the same yet different. The original sentence read:

I recently had the privilege of running some training sessions on product design and research techniques with the design team at Duck Duck Go.

There’s nothing wrong with that. But maybe this is a little easier to digest:

I recently had the privilege of running some training sessions with the design team at Duck Duck Go. We covered product design and research techniques.

Perhaps this is kind of like the single responsibility principle in programming. Whereas the initial version was one sentence that conveyed two pieces of information (who the training was with and what the training covered), the final version has a separate sentence for each piece of information.

I wouldn’t take that idea too far though. Otherwise you’d end up with something quite stilted and robotic.

Speaking of sounding robotic, I’ve noticed that people sometimes avoid using contractions when they’re writing online: “there is” instead of “there’s” or “I am” instead of “I’m.” Avoiding contractions seems to be more professional, but actually it makes the writing a bit too formal. There’s a danger of sounding like a legal contract. Or a Vulcan.

Sometimes a long sentence can’t be broken down into shorter sentences. In that case, I watch out for how much cognitive load the sentence is doling out to the reader.

Here’s an example from Maite’s post, How to engage the right people when recruiting in house for research. One sentence initially read:

The relevance of the people you invite to participate in a study and the information they provide have a great impact on the quality of the insights that you get.

The verb comes quite late there. As a reader, until I get to “have a great impact”, I have to keep track of everything up to that point. Here’s a rephrased version:

The quality of the insights that you get depends on the relevance of the people you invite to participate in a study and the information they provide.

Okay, there are two changes there. First of all, the verb is now “depends on” instead of “have a great impact on.” I think that’s a bit clearer. Secondly, the verb comes sooner. Now I only have to keep track of the words up until “depends on”. After that, I can flush my memory buffer.

Here’s another changed sentence from the same article. The initial sentence read:

You will have to communicate at different times and for different reasons with your research participants.

I suggested changing that to:

You will have to communicate with your research participants at different times and for different reasons.

To be honest, I find it hard to explain why that second version flows better. I think it’s related to the idea of reducing dependencies. The subject “your research participants” is dependent on the verb “to communicate with.” So it makes more sense to keep them together instead of putting a subclause between them. The subclause can go afterwards instead: “at different times and for different reasons.”

Here’s one final example from Katie’s post, Service Designers don’t design services, we all do. One sentence initially read:

Understanding the relationships between these moments, digital and non-digital, and designing across and between these moments is key to creating a compelling user experience.

That sentence could be broken into shorter sentences, but it might lose some impact. Still, it can be rephrased so the reader doesn’t have to do as much work. As it stands, until the reader gets to “is key to creating”, they have to keep track of everything before that. It’s like the feeling of copying and pasting. If you copy something to the clipboard, you want to paste it as soon as possible. The longer you have to hold onto it, the more uncomfortable it feels.

So here’s the reworked version:

The key to creating a compelling user experience is understanding the relationships between these moments, digital and non-digital, and designing across and between these moments.

As a reader, I can digest and discard each of these pieces in turn:

  1. The key to creating a compelling user experience is…
  2. understanding the relationships between these moments…
  3. digital and non-digital…
  4. and…
  5. designing across and between these moments.

Maybe I should’ve suggested “between these digital and non-digital moments” instead of “between these moments, digital and non-digital”. But then I worry that I’m intruding on the author’s style too much. With the finished sentence, it still feels like a rousing rallying cry in Katie’s voice, but slightly adjusted to flow a little easier.

I must say, I really, really enjoy being a content buddy. I know the word “editor” would be the usual descriptor, but I like how unintimidating “content buddy” sounds.

I am almost certainly a terrible content buddy to myself. Just as I ignore my own advice about preparing conference talks, I’m sure I go against my own editorial advice every time I blurt out a blog post here. But there’s one piece I’ve given to others that I try to stick to: write like you speak.

Sunday, March 7th, 2021

This Word Does Not Exist

This is easily my favourite use of a machine learning algorithm.

Tuesday, February 16th, 2021

Front-of-the-front-end and back-of-the-front-end web development | Brad Frost

These definitions work for me:

A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.

A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.

Thursday, January 28th, 2021

Historical Dictionary of Science Fiction

A fascinating crowdsourced project. You can read the backstory in this article in Wired magazine.

Thursday, January 21st, 2021

Letters of exclusion

I think my co-workers are getting annoyed with me. Any time they use an acronym or initialism—either in a video call or Slack—I ask them what it stands for. I’m sure they think I’m being contrarian.

The truth is that most of the time I genuinely don’t know what the letters stand for. And I’ve got to that age where I don’t feel any inhibition about asking “stupid” questions.

But it’s also true that I really, really dislike acronyms, initialisms, and other kinds of jargon. They’re manifestations of gatekeeping. They demarcate in-groups from outsiders.

Of course if you’re in a conversation with an in-group that has the same background and context as you, then sure, you can use acronyms and initialisms with the confidence that there’s a shared understanding. But how often can you be that sure? The more likely situation—and this scales exponentially with group size—is that people have differing levels of inside knowledge and experience.

I feel sorry for anyone trying to get into the field of web performance. Not only are there complex browser behaviours to understand, there’s also a veritable alphabet soup of initialisms to memorise. Here’s a really good post on web performance by Harry, but notice how the initialisms multiply like tribbles as the post progresses until we’re talking about using CWV metrics like LCP, FID, and CLS—alongside TTFB and SI—to look at PLPs, PDPs, and SRPs. And fair play to Harry; he expands each initialism the first time he introduces it.

But are we really saving any time by saying FID instead of first input delay? I suspect that the only reason why the word “cumulative” precedes “layout shift” is just to make it into the three-letter initialism CLS.

Still, I get why initialisms run rampant in technical discussions. You can be sure that most discussions of particle physics would be incomprehensible to outsiders, not necessarily because of the concepts, but because of the terminology.

Again, if you’re certain that you’re speaking to peers, that’s fine. But if you’re trying to communicate even a little more widely, then initialisms and abbreviations are obstacles to overcome. And once you’re in the habit of using the short forms, it gets harder and harder to apply context-shifting in your language. So the safest habit to form is to generally avoid using acronyms and initialisms.

Unnecessary initialisms are exclusionary.

Think about on-boarding someone new to your organisation. They’ve already got a lot to wrap their heads around without making them figure out what a TAM is. That’s a real example from Clearleft. We have a regular Thursday afternoon meeting. I call it the Thursday afternoon meeting. Other people …don’t.

I’m trying—as gently as possible—to ensure we’re not being exclusionary in our language. My co-workers indulge me, even it’s just to shut me up.

But here’s the thing. I remember many years back when a job ad went out on the Clearleft website that included the phrase “culture fit”. I winced and explained why I thought that was a really bad phrase to use—one that is used as code for “more people like us”. At the time my concerns were met with eye-rolls and chuckles. Now, as knowledge about diversity and inclusion has become more widespread, everyone understands that using a phrase like “culture fit” can be exclusionary.

But when I ask people to expand their acronyms and initialisms today, I get the same kind of chuckles. My aversion to abbreviations is an eccentric foible to be tolerated.

But this isn’t about me.

Saturday, December 26th, 2020

Talking out loud to yourself is a technology for thinking | Psyche Ideas

This explains rubber ducking.

Speaking out loud is not only a medium of communication, but a technology of thinking: it encourages the formation and processing of thoughts.