Menu

Posts tagged “technology”

Is it a bug or a feature?

Nicholas Carr chases down the origin of the phrase ”It’s Not a Bug, It’s a Feature.” This bit stuck with me:

INABIAF—the initialism has earned a place in the venerable Acronym Finder—is for programmers as much a cri de coeur 1 as an excuse. For the rest of us, the saying has taken on a sinister tone. It wasn’t long ago that we found software ­dazzling, all magic and light. But our perception of the programmer’s art has darkened. The friendly-seeming apps and chatbots on our phones can, we’ve learned, harbor ill intentions. They can manipulate us or violate our trust or make us act like jerks. It’s the features now that turn out to be bugs.

It seems that more and more, we simply don’t trust our software any more. And I don’t think that’s a bad thing.


  1. I googled this so you don’t have to. It means “passionate appeal, complaint, or protest.” 

A pragmatic approach to digital ethics

Cal Newport has some thoughts on the “digital ethics” movement. In his post Beyond Digital Ethics he argues that large companies will never turn their backs on revenue just because it’s “the right thing to do”:

Instead of quixotically convincing some of the most valuable business enterprises in the history of the world to behave against their interests, we should convince individuals to adopt a much more skeptical and minimalist approach to the digital junk these companies peddle.

We don’t need to convince YouTube to artificially constrain the effectiveness of its AutoPlay algorithm, we should instead convince users of the life-draining inanity of idly browsing YouTube.

This approach will be challenging too, because we are up against some really strong brain psychology. As Don Norman notes in Why bad technology dominates our lives:

Curiosity is, on the whole, a virtue. We have evolved to be curious. Our nervous system is especially sensitive to change, and changes in the environment attract attention. But the technology-centered view labels this natural, creative trait as a liability: Curiosity is renamed as distraction. A human virtue is now turned into a liability.

Worse, many businesses have learned to exploit our curiosity. The continual bombardment of tantalizing tidbits of information deliberately designed to grab our attention away from other, potentially more valuable activities are distractions that can lead to accidents, injury, and interpersonal problems.

We are in uncharted territory and there are no easy solutions.

How businesses have learned to exploit our curiosity

Don Norman attempts to explain Why bad technology dominates our lives:

Curiosity is, on the whole, a virtue. We have evolved to be curious. Our nervous system is especially sensitive to change, and changes in the environment attract attention. But the technology-centered view labels this natural, creative trait as a liability: Curiosity is renamed as distraction. A human virtue is now turned into a liability.

Worse, many businesses have learned to exploit our curiosity. The continual bombardment of tantalizing tidbits of information deliberately designed to grab our attention away from other, potentially more valuable activities are distractions that can lead to accidents, injury, and interpersonal problems. What kind of business exploits curiosity for its own ends? Almost any business that discovers there are profits to be made by continually engaging people’s curiosity, hopes, and interests. For example gambling, computer games, social networks, and even television series that can go on and on, week after week, year after year, trapping their viewers into addiction.

We talk a lot about “personal responsibility” and how it’s up to each person to make good choices about how they spend their time. That is true as far as it goes, but it brushes over the incredibly strong forces of persuasion theory and how easily humans are manipulated. “Personal responsibility” doesn’t give us a hall pass to exploit the human brain’s weaknesses.

The stress of interacting with voice UIs

This bit from Raluca Budiu and Page Laubheimer’s user study of digital assistants like Alexa, Google Assistant, and Siri echoes my thoughts exactly on why I don’t like interacting with them:

Many participants started speaking before formulating the query completely (as you would normally do with a human), and occasionally paused searching for the best word. Such pauses are natural in conversation, but assistants did not interpret them correctly and often rushed to respond. Of course, answers to such incomplete queries were incorrect most of the time, and the overall effect was unpleasant: participants complained that they were interrupted, that the assistant “talked over them”, or that the assistant was “rude.” Some even went as far as to explicitly scold the assistant for it (“Alexa, that’s rude!”).

Yep. When I interact with voice UIs I spend way more time and energy planning the exact sentence construction and pronunciation than when I simply type and swipe and figure it out as I go. And then, if one word is out of place, the whole thing falls apart. It’s just too stressful. I can’t.

Platforms and serendipity on the internet

In Filter Failures Ethan Chiel asks if platforms are sucking the joy out of the internet, and he makes a pretty compelling argument:

The internet as we use it now is, for the most part, what the large platforms want it to be: an engine for serving us what their various systems think we want, or what we wanted before, or what our demographics want en masse.

Here’s the problem:

What’s lost in the process is whatever you might have found that neither you nor an algorithm might guess is interesting. Some song in a forum thread you idly clicked on, a news item about something you’ve never expressed interest in or heard of that you read because you had 5 minutes to kill and it caught your eye.

This reminds me of how we used to browse music stores. We idly flipped through CDs, and picked a few to try out in the listening booth based on the cover, the song titles, and some undefined ¯_(ツ)_/¯ factor. Now we just see and hear what we’ve seen and heard before, and the cycle continues…

“One Laptop Per Child”: a great solution to the wrong problem

Do you remember the “One Laptop Per Child” project? The PR event made a huge splash back in 2005, and I remember being really impressed and inspired. As it turns out, OLPC is a textbook example of what happens when an organization has a sincere desire to solve a problem that they simply don’t understand.

Adi Robertson, writing for The Verge, has an excellent history of the project called OLPC’s $100 laptop was going to change the world — then it all went wrong. It starts with this anecdote:

Then, Negroponte and Annan rose for a photo-op with two OLPC laptops, and reporters urged them to demonstrate the machines’ distinctive cranks. Annan’s crank handle fell off almost immediately. As he quietly reattached it, Negroponte managed half a turn before hitting the flat surface of the table. He awkwardly raised the laptop a few inches, trying to make space for a full rotation. “Maybe afterwards…” he trailed off, before sitting back down to field questions from the crowd. […]

If you remember the OLPC at all, you probably remember the hand crank. It was OLPC’s most striking technological innovation — and it was pure vaporware. Designers dropped the feature almost immediately after Negroponte’s announcement, because the winding process put stress on the laptop’s body and demanded energy that kids in very poor areas couldn’t spare. Every OLPC computer shipped with a standard power adapter.

As you read deeper, it becomes clear that they were working on a solution that didn’t take local issues into account at all:

Bender thinks OLPC might have struck more deals if it had focused less on technical efficiency. “Every conversation we ever had with any head of state — every time — they said, ‘Can we build the laptop in our country?’” he says. “We knew that by making the laptop in Shanghai, we could build the laptop [to be] much less expensive. And what we didn’t realize was that the price wasn’t what they were asking us about. They were asking us about pride, not price. They were asking us about control and ownership of the project.”

To put it another way:

OLPC had created a computer that could withstand dust and drops, but it hadn’t accounted for political messiness.

There are many lessons to learn from this story, but most important is almost certainly that a desire to do something good isn’t enough to make a product successful. If you don’t fully understand the problem you’re solving and the people you’re solving it for, your chances of success are incredibly low.

Social internet, social media, and the move to smaller networks

I should stop reading (and writing) about Facebook at some point, but there’s been some really interesting thinking around the social internet in general recently. I especially enjoyed Benedict Evans’s The death of the newsfeed, because it puts into words a lot of things I’ve been thinking about. On the social implications of algorithmic feeds:

One basic problem here is that if the feed is focused on ‘what do I want to see?’, then it cannot be focused on ‘what do my friends want (or need) me to see?’ Sometimes this is the same thing - my friend and I both want me to see that they’re throwing a party tonight. But if every feed is a sample, then a user has no way to know who will see their post. Indeed, conceptually one might suggest that they have no way to know if anyone will see this post.

This is one of the major flaws of algorithmic feeds. People share things so that those things can be seen. But if you can’t tell who will see the things you share, that’s frustrating, and more than a little nerve-wracking. Hence the move back to smaller networks:

I think one could suggest that this is some of what’s behind the suggestions of systemically lower engagement on Facebook newsfeeds, and behind the obvious growth of person-to person chat (most obviously WhatsApp, iMessage, FB Messenger and Instagram - three of which Facebook of course owns). The social dynamics of a 1:1 chat work much more strongly against overload, and even if one person does overshare they’re in a separate box, that you can mute if you like. […]

Messaging can be more private, have less social pressure, and be more fun. A Snapchat story isn’t a permanent record and has less pressure to show off your perfection. Stickers and filters are more fun and spontaneous than Facebook’s rigid blue boxes (and the days of throwing sheep at people are gone alone with Facebooks’ platform). And some of these offer light-weight ways to interact without obligation, which was also a feature of Facebook’s model, but deliver that piece of Maslow in different ways.


On that note, I think the distinction Cal Newport draws in On Social Media and Its Discontents is really important:

There’s a distinction between the social internet and social media.

The social internet describes the general ways in which the global communication network and open protocols known as “the internet” enable good things like connecting people, spreading information, and supporting expression and activism.

Social media, by contrast, describes the attempt to privatize these capabilities by large companies within the newly emerged algorithmic attention economy, a particularly virulent strain of the attention sector that leverages personal data and sophisticated algorithms to ruthlessly siphon users’ cognitive capital.
>

In the final analysis, I agree with Cal:

I support the social internet. I’m incredibly wary of social media.

Why you should (usually) choose boring technology

This is a fairly old post, but I only recently came across Dan McKinley’s Choose Boring Technology. It is so good.

What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

He goes on to explain the process you should go through before you try out a new technology.

More evidence of the ways technology can be bad for our health

Stories about how technology can be bad for our health is not new, of course. But two articles in this particular genre caught my attention this week. The first is some HBR research showing that Having Your Smartphone Nearby Takes a Toll on Your Thinking (Even When It’s Silent and Facedown):

The mere presence of our smartphones is like the sound of our names or a crying baby — something that automatically exerts a gravitational pull on our attention. Resisting that pull takes a cognitive toll.

A bit more about that “gravitational pull”:

Research in cognitive psychology shows that humans learn to automatically pay attention to things that are habitually relevant to them, even when they are focused on a different task. For example, even if we are actively engaged in a conversation, we will turn our heads when someone says our name across the room. Similarly, parents automatically attend to the sight or sound of a baby’s cry.


In another article, Virginia Heffernan explores the question What Are Screens Doing to Our Eyes—And Our Ability to See?:

Having recently, in my forties, gotten reading glasses, I now find myself having to choose between reading and being, since I can’t read without them and I can’t see the world with them. The glasses date from a time when reading was much rarer a pastime than being; you’d grope for them to see a book, while relying on your naked eyes for driving, talking, walking.

There is no “solution” to this, but as someone who also has reading glasses, I do like her approach to make this weird feeling a little better:

When I pull away from the screen to stare into the middle distance for a spell, I take off my glasses. I try to find a tree. If I’m inside, I open a window; if I’m outside, I will even approach a tree. I don’t want mediation or glass. The trees are still strangers; I hardly know their names yet, but I’m testing myself on leaf shapes and shades of green. All I know so far is that trees are very unlike screens. They’re a prodigious interface. Very buggy. When my eyes settle after a minute or two, I—what’s that expression, “the scales fell from my eyes”? It’s almost, at times, like that.

Easier blog post image management with Dropshare and Amazon S3

I’m always on the lookout for faster ways to upload and insert images into blog posts. It’s the part of the blogging workflow that I dislike the most. Up to now I’ve used a pretty convoluted combination of Amazon S3 buckets and Transmit. But over the weekend, while moving hosting providers1, I finally came up with a really simple image upload workflow that I thought I’d share in case it helps anyone else.

This workflow lets you drag and drop an image to a menu bar icon on your Mac, and then immediately paste a secure, custom domain URL for that image wherever you need it.


Step 1 - Create S3 bucket

Create an Amazon S3 bucket for your image uploads. It doesn’t matter what you name the bucket, but do not add a . to the name. This creates some weird SSL certificate errors later in the process that you don’t want to deal with.

Also make sure you set the bucket to be publicly accessible via the Permissions tab, otherwise you’ll get read errors for your files.

Step 2 - Create CloudFront distribution

Create an Amazon CloudFront distribution for the S3 bucket you just created, so that you can use a custom URL for your images, and make use of Amazon’s Content Delivery Network (CDN) capabilities.

When you go through the flow of adding a distribution for your S3 bucket, leave the “Distribution Settings” section blank at first — we’ll come back to that.

CloudFront settings

Step 3 - Add custom domain for your images

Back on the main Distributions screen, note the CloudFront domain name that was created for your bucket. It’s going to be in the format ***************.cloudfront.net. Go to your DNS provider and add a CNAME for the custom domain you want to use for your images.

In my case, cdn.elezea.com points to my CloudFront distribution at d26fqxuc6*****.cloudfront.net, which in turn links to the S3 bucket I set up earlier.

Step 4 - Add SSL certificate to CloudFront distribution

Now go back to your Distribution Settings in CloudFront. Add your CNAME information, and then click the button to “Request or Import a Certificate with ACM”.

This will take you through the process of generating a free SSL cert to be used with your CloudFront distribution. This is essential if you serve your site over https. If you don’t do this, your images will be served over http and you will get “mixed content” warnings when you embed images in your site.

Change your settings to “Custom SSL Certificate”, and you’re good to go.

CloudFront settings

Interlude - take a breath

If you’ve successfully completed these steps, here’s where you’ll be. Whenever you upload an image to your S3 bucket, you will be able to serve that image via your custom URL over https, and as an added bonus, you’ll be using Amazon’s CDN for super fast delivery.

Now we need to figure out the fastest way to get images into that bucket of yours.


Step 5 - Download and set up Dropshare

There are many sophisticated ways to manage your S3 buckets. But when it comes to uploading an image and getting a URL for it, I haven’t found anything that’s simpler than Dropshare.

In short, Dropshare allows you to establish connections to all your S3 buckets. It lets you upload files by dragging them to the Dropshare menu bar icon, and then the URL for that image is automatically copied to your clipboard. So to add an image to this blog post, for example, I just drag the image to the menu bar icon, then come back to where I’m writing and ⌘-V to insert the link. It couldn’t be easier.

I have a bunch of S3 buckets linked up in Dropshare:

Dropshare

In the case of the bucket I use for this site, note that I entered the bucket name, the domain alias (the CNAME you added earlier), and that I have the “Use SSL” box checked:

Drophsare

This makes the workflow for adding images an absolute breeze. Drag and paste. That’s it.

When you upload an image, Dropshare lets you choose the bucket you want to upload to, as well as if you want to add a landing page and/or use a URL shortener (which I usually don’t, but it’s nice to have the option).

Drophsare

Dropshare is useful for other things too. I have a keyboard shortcut that takes a screen shot, automatically uploads it to an S3 bucket, and copies the URL to the clipboard. That’s great for sharing screen shots in Slack, for example.


I’m not sure how many people have this need to shave a few minutes off their image workflow. But I hope this post is useful for the few of you who do obsess about things like this, like I do. And please let me know if you think this flow can be improved even more!


  1. I’m now with DreamHost and much happier.