Tags: labels

What we talk about when we talk about AI — Careful Industries

Technically, AI is a field of computer science that uses advanced methods of computing.

Socially, AI is a set of extractive tools used to concentrate power and wealth.

Petition · Defend the Internet Archive - United States · Change.org

Signed!

We, the undersigned, call on the record labels and members of the Recording Industry Association of America (RIAA)—including UMG, Capitol Records, Concord Bicycle Assets, CMGI Recorded Music Assets, Sony Music Entertainment, and Arista Music—to drop your lawsuit against the Internet Archive.

Prescriptive and Descriptive Information Architectures | Jorge Arango

Interesting—this is exactly the same framing I used to talk about design systems a few years ago.

There are different kinds of buzzwords.

Some buzzwords are useful. They take a concept that would otherwise require a sentence of explanation and package it up into a single word or phrase. Back in the day, “ajax” was a pretty good buzzword.

Some buzzwords are worse than useless. This is when a word or phrase lacks definition. You could say this buzzword in a meeting with five people, and they’d all understand five different meanings. Back in the day, “web 2.0” was a classic example of a bad buzzword—for some people it meant a business model; for others it meant rounded corners and gradients.

The worst kind of buzzwords are the ones that actively set out to obfuscate any actual meaning. “The cloud” is a classic example. It sounds cooler than saying “a server in Virginia”, but it also sounds like the exact opposite of what it actually is. Great for marketing. Terrible for understanding.

“AI” is definitely not a good buzzword. But I can’t quite decide if it’s merely a bad buzzword like “web 2.0” or a truly terrible buzzword like “the cloud”.

The biggest problem with the phrase “AI” is that there’s a name collision.

For years, the term “AI” has been used in science-fiction. HAL 9000. Skynet. Examples of artificial general intelligence.

Now the term “AI” is also used to describe large language models. But there is no connection between this use of the term “AI” and the science fictional usage.

This leads to the ludicrous situation of otherwise-rational people wanted to discuss the dangers of “AI”, but instead of talking about the rampant exploitation and energy usage endemic to current large language models, they want to spend the time talking about the sci-fi scenarios of runaway “AI”.

To understand how ridiculous this is, I’d like you to imagine if we had started using a different buzzword in another setting…

Suppose that when ride-sharing companies like Uber and Lyft were starting out, they had decided to label their services as Time Travel. From a marketing point of view, it even makes sense—they get you from point A to point B lickety-split.

Now imagine if otherwise-sensible people began to sound the alarm about the potential harms of Time Travel. Given the explosive growth we’ve seen in this sector, sooner or later they’ll be able to get you to point B before you’ve even left point A. There could be terrible consequences from that—we’ve all seen the sci-fi scenarios where this happens.

Meanwhile the actual present-day harms of ride-sharing services around worker exploitation would be relegated to the sidelines. Clearly that isn’t as important as the existential threat posed by Time Travel.

It sounds ludicrous, right? It defies common sense. Just because a vehicle can get you somewhere fast today doesn’t mean it’s inevitably going to be able to break the laws of physics any day now, simply because it’s called Time Travel.

And yet that is exactly the nonsense we’re being fed about large language models. We call them “AI”, we look at how much they can do today, and we draw a straight line to what we know of “AI” in our science fiction.

This ridiculous situation could’ve been avoided if we had settled on a more accurate buzzword like “applied statistics” instead of “AI”.

It’s almost as if the labelling of the current technologies was more about marketing than accuracy.

I love libraries. I think they’re one of humanity’s greatest inventions.

My local library here in Brighton is terrific. It’s well-stocked, it’s got a welcoming atmosphere, and it’s in a great location.

But it has an information architecture problem.

Like most libraries, it’s using the Dewey Decimal system. It’s not a great system, but every classification system is going to have flaws—wherever you draw boundaries, there will be disagreement.

The Dewey Decimal class of 900 is for history and geography. Within that class, those 100 numbers (900 to 999) are further subdivded in groups of 10. For example, everything from 940 to 949 is for the history of Europe.

Dewey Decimal number 941 is for the history of the British Isles. The term “British Isles” is a geographical designation. It’s not a good geographical designation, but technically it’s not a political term. So it’s actually pretty smart to use a geographical rather than a political term for categorisation: geology moves a lot slower than politics.

But the Brighton Library is using the wrong label for their shelves. Everything under 941 is labelled “British History.”

The island of Ireland is part of the British Isles.

The Republic of Ireland is most definitely not part of Britain.

Seeing books about the history of Ireland, including post-colonial history, on a shelf labelled “British History” is …not good. Frankly, it’s offensive.

(I mentioned this situation to an English friend of mine, who said “Well, Ireland was once part of the British Empire”, to which I responded that all the books in the library about India should also be filed under “British History” by that logic.)

Just to be clear, I’m not saying there’s a problem with the library using the Dewey Decimal system. I’m saying they’re technically not using the system. They’ve deviated from the system’s labels by treating “History of the British Isles” and “British History” as synonymous.

I spoke to the library manager. They told me to write an email. I’ve written an email. We’ll see what happens.

You might think I’m being overly pedantic. That’s fair. But the fact this is happening in a library in England adds to the problem. It’s not just technically incorrect, it’s culturally clueless.

Mind you, I have noticed that quite a few English people have a somewhat fuzzy idea about the Republic of Ireland. Like, they understand it’s a different country, but they think it’s a different country in the way that Scotland is a different country, or Wales is a different country. They don’t seem to grasp that Ireland is a different country like France is a different country or Germany is a different country.

It would be charming if not for, y’know, those centuries of subjugation, exploitation, and forced starvation.

British history.

Update: They fixed it!

I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?

That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.

This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.

Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:

• /things
• /things/new
• /things/search

And then an idividual item can be found at:

• things/ID

That’s all nice and predictable and the naming of the URLs matches what you’d expect to find:

• tunes
• tunes/new
• tunes/search?q=Ireland
• tunes/320

Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:

/recordings

When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.

Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.

So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.

Here’s my dilemma: if I update the label, should I also update the URL structure?

Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.

If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.

Is that okay? Am I the only one that would be bothered by that?

I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:

• /discography
• /discography/new
• /discography/search
• /discography/ID

It doesn’t seem as tidy as:

• /recordings
• /recordings/new
• /recordings/search
• /recordings/ID

But if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.

I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.

Improving the information architecture of the Smart Pension member app | Design and tech | Smart – retirement, savings and financial wellbeing

Here’s a really excellent, clearly-written case study that unfortunately includes this accurate observation:

In recent years the practice of information architecture has fallen out of fashion, which is a shame as you can’t design something successfully without it. If a user can’t find a feature, it’s game over - the feature may as well not exist as far as they’re concerned.

I also like this insight:

Burger menus are effective… at hiding things.

Design Titles

Keep refreshing until you find your next job title.

How-to: Create accessible forms - The A11Y Project

Another five pieces of sweet, sweet low-hanging fruit:

• Always label your inputs.
• Highlight input element on focus.
• Break long forms into smaller sections.
• Provide error messages.
• Avoid horizontal layout forms unless necessary.

5 most annoying website features I face as a blind person every single day by Holly Tuke

Five pieces of low-hanging fruit:

• Unlabelled links and buttons
• No image descriptions
• Poor use of headings
• Inaccessible web forms
• Auto-playing audio and video

The difference between aria-label and aria-labelledby - Tink - Léonie Watson

A handy reminder from Léonie (though remember that the best solution is to avoid the problem in the first place—if you avoid using ARIA, do that).

Naming things to improve accessibility

Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.

The ineffectiveness of lonely icons | Matt Wilcox, Web Developer & Tinkerer

When in doubt, label your icons.

When not in doubt, you probably should be.

I’m a Web Designer - Andy Bell

Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.

I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.

Don’t Use The Placeholder Attribute — Smashing Magazine

A lot of the issues here are with abuses of the placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).

Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.

UX In Contact Forms: Essentials To Turn Leads Into Conversions — Smashing Magazine

The answers to these questions about forms are useful for just about any website:

1. Is It OK To Place A Form In Two Columns?
2. Where Should Labels Be Placed?
3. Can We Use Placeholder Text Instead Of A Label?
4. How To Lessen The Cognitive Load Of A Form?
5. Are Buttons Considered Part Of A Form’s UX?
6. Is It Possible To Ease The Process Of Filling A Form?
7. Does The User’s Location Influence A Form’s UX?

Revisiting the Float Label pattern with CSS — That Emil is Emil Björklund

A clever technique by Emil to implement the “float label” pattern using CSS. It all hinges on browsers supporting the :placeholder-shown pseudo-class which, alas, is not universal.

I was hoping that maybe @supports could come to the rescue (so that a better fallback could be crafted), but that tests for properties and values, not selectors. Damn!

Thomas Byttebier - The best icon is a text label

A look at the risks of relying on a purely graphical icon for interface actions. When in doubt, label it.

Labelmask | Brad Frost Web

I really like this interface idea from Brad that provides the utility of input masks but without the accessibility problems.

41Latitude - Google Maps & Label Readability

An examination into the legibility of labels on online mapping services.