Jeremy Keith's Blog, page 27

The first four speakers for UX London 2023

Please put your fingers on the desk in front of you and move them up and down rapidly in the manner of a snare drum���

I���m very happy to announce the first four speakers for UX London 2023:

Imran Afzal, Principal Designer at Co-op Digital,Vimla Appadoo, Head of Experience at Culture Shift,Daniel Burka, Director of Design at Resolve to Save Lives, and Mansi Gupta, Founder of Unconform.

This is shaping up nicely! You can expect some more speaker announcements before too long.

But don���t wait too long to get your ticket���early-bird pricing ends this month on Friday, February 24th. Then the price goes up by ��200. If you need to convince your boss, here are some reasons to attend.

I very much look forward to seeing you at Tobacco Dock on June 22nd and 23rd this year!

You can call me AI

I���ve mentioned before that I���m not a fan of initialisms and acronyms. They can be exclusionary.

It bothers me doubly when everyone is talking about AI.

First of all, the term is so vague as to be meaningless. Sometimes���though rarely���AI refers to general artificial intelligence. Sometimes AI refers to machine learning. Sometimes AI refers to large language models. Sometimes AI refers to a series of if/else statements. That���s quite a spectrum of meaning.

Secondly, there���s the assumption that everyone understands the abbreviation. I guess that���s generally a safe assumption, but sometimes AI could refer to something other than artificial intelligence.

In countries with plenty of pastoral agriculture, if someone works in AI, it usually means they���re going from farm to farm either extracting or injecting animal semen. AI stands for artificial insemination.

I think that abbreviation might work better for the kind of things currently described as using AI.

We were discussing this hot topic at work recently. Is AI coming for our jobs? The consensus was maybe, but only the parts of our jobs that we���re more than happy to have automated. Like summarising some some findings. Or perhaps as a kind of lorem ipsum generator. Or for just getting the ball rolling with a design direction. As Terence puts it:

Midjourney is great for a first draft. If, like me, you struggle to give shape to your ideas then it is nothing short of magic. It gets you through the first 90% of the hard work. It’s then up to you to refine things.

That���s pretty much the conclusion we came to in our discussion at Clearleft. There���s no way that we���d use this technology to generate outputs for clients, but we certainly might use it to generate inputs. It���s like how we���d do a quick round of sketching to get a bunch of different ideas out into the open. Terence is spot on when he says:

Midjourney lets me quickly be wrong in an interesting direction.

To put it another way, using a large language model could be a way of artificially injecting some seeds of ideas. Artificial insemination.

So now when I hear people talk about using AI to create images or articles, I don���t get frustrated. Instead I think, ���Using artificial insemination to create images or articles? Yes, that sounds about right.���

Home stream

Ben wrote a post a little while back about maybe organising his home page differently. It���s currently a stream.

That prompted Om to ask is ���stream��� as a design paradigm over? Mind you, he���s not talking about personal websites:

Across the web, one can see ���streams��� losing their preeminence. Social networks are increasingly algorithmically organized, so their stream isn���t really a free-flowing stream. It is more like a river that has been heavily dammed. It is organized around what the machine thinks we need to see based on what we have seen in the past.

Funnily enough, I���ve some recent examples of personal homepages become more like social networks, at least in terms of visual design. A lot of people I know are liking the recent redesigns from Adam and Jhey.

Here on my site, my home page is kind of a stream. I���ve got notes, links, and blog posts one after another in chronological order. The other sections of my site are ways of focusing in on the specific types of content links, short notes, blog posts in my journal.

Behind the scenes, entries those separate sections of my site are all stored in the same database table. In some ways, the separation into different sections of the site is more like tagging. So the home page is actually the simplest bit to implement: grab the latest 20 entries out of that database table.

I don���t make too much visual distinction between the different kinds of posts. My links and my notes look quite similar. And if I post a lot of commentary with a link, it looks a lot like a blog post.

Maybe I should make them more distinct, visually. Because I actually like the higgedly-piggedly nature of a stream of different kinds of stuff. I want the vibe to be less like a pristine Apple store, and more like a chaotic second-hand bookstore.

Going back to what Ben wrote about his site:

As of right now, the homepage is a mix of long-form posts, short thoughts, and links I consider interesting, presented as a stream. It���s a genuine representation of what I���m reading and thinking about, and each post���s permalink page looks fine to me, but it doesn���t quite hold together as a whole. If you look at my homepage with fresh eyes, my stream is a hodgepodge. There���s no through line.

For me, that���s a feature, not a bug. There���s no through line on my home page either. I like that.

Change

I���ve spent the last few days in San Francisco where I was hosting Leading Design.

It was excellent. Rebecca did an absolutley amazing job with the curation, and the Clearleft delivered a terrific event, as always. I���m continually amazed by the way such a relatively small agency can punch above its weight when it comes to putting on world-class events and delivering client work.

I won���t go into much detail on what was shared at Leading Design. There���s an understanding that it���s a safe space for people to speak freely and share their experiences in an open and honest way. I can tell you that there were some tough topics. Given the recent rounds of layoffs in this neck of the woods, this was bound to happen.

I was chatting with Peter at breakfast on the second day and he was saying that maybe there was too much emphasis on the negative, like we were in danger of wallowing in our own misery. It���s a fair point, but I offered a counterpoint that I also heard other people express: when else do these people get a chance to let their guard down and have a good ol��� moan? These are design leaders who need to project an air of calm reassurance when they���re at work. Leading Design is a welcome opportunity to just let it all out.

When we did Leading Design in New York in March of 2022, it was an intimate gathering and the overwhelming theme was togetherness. After two years of screen-based interactions, it was cathartic to get together in the same location to swap stories and be reminded you are not alone.

Leading Design San Francisco was equally cathartic, but the theme this time was change. Change can be scary. But it can also be enervating.

After two days of introducing and listening to fascinating talks on the topic of change, I closed out my duties by quoting the late great Octavia Butler. I spoke the mantra of the secular Earthseed religion founded in Parable Of The Sower:

All that you touch
You Change.

All that you Change
Changes you.

The only lasting truth
Is Change.

God
Is Change.

In between

I was chatting with my new colleague Alex yesterday about a link she had shared in Slack. It was the Nielsen Norman Group���s annual State of Mobile User Experience report.

There���s nothing too surprising in there, other than the mention of Apple���s app clips and Google���s instant apps.

Remember those?

Me neither.

Perhaps I lead a sheltered existence, but as an iPhone user, I don���t think I���ve come across a single app clip in the wild.

I remember when they were announced. I was quite worried about them.

See, the one thing that the web can (theoretically) offer that native can���t is instant access to a resource. Go to this URL���that���s it. Whereas for a native app, the flow is: go to this app store, find the app, download the app.

(I say that the benefit is theoretical because the website found at the URL should download quickly���the reality is that the bloat of ���modern��� web development imperils that advantage.)

App clips���and instant apps���looked like a way to route around the convoluted install process of native apps. That���s why I was nervous when they were announced. They sounded like a threat to the web.

In reality, the potential was never fulfilled (if my own experience is anything to go by). I wonder why people didn���t jump on app clips and instant apps?

Perhaps it���s because what they promise isn���t desirable from a business perspective: ���here���s a way for users to accomplish their tasks without downloading your app.��� Even though app clips can in theory be a stepping stone to installing the full app, from a user���s perspective, their appeal is the exact opposite.

Or maybe they���re just too confusing to understand. I think there���s an another technology that suffers from the same problem: progressive web apps.

Hear me out. Progressive web apps are���if done well���absolutely amazing. You get all of the benefits of native apps in terms of UX���they even work offline!���but you retain the web���s frictionless access model: go to a URL; that���s it.

So what are they? Are they websites? Yes, sorta. Are they apps? Yes, sorta.

That���s confusing, right? I can see how app clips and instant apps sound equally confusing: ���you can use them straight away, like going to a web page, but they���re not web pages; they���re little bits of apps.���

I���m mostly glad that app clips never took off. But I���m sad that progressive web apps haven���t taken off more. I suspect that their fates are intertwined. Neither suffer from technical limitations. The problem they both face is inertia:

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That���s the hard part.

True of progressive web apps. Equally true of app clips.

But when I was chatting to Alex, she made me look at app clips in a different way. She described a situation where somebody might need to interact with some kind of NFC beacon from their phone. Web NFC isn���t supported in many browsers yet, so you can���t rely on that. But you don���t want to make people download a native app just to have a quick interaction. In theory, an app clip���or instant app���could do the job.

In that situation, app clips aren���t a danger to the web���they���re polyfills for hardware APIs that the web doesn���t yet support!

I love having my perspective shifted like that.

The specific situations that Alex and I were discussing were in the context of museums. Musuems offer such interesting opportunities for the physical and the digital to intersect.

Remember the pen from Cooper Hewitt? Aaron spoke about it at dConstruct 2014���a terrific presentation that���s well worth revisiting and absorbing.

The other dConstruct talk that���s very relevant to this liminal space between the web and native apps is the 2012 talk from Scott Jenson. I always thought the physical web initiative had a lot of promise, but it may have been ahead of its time.

I loved the thinking behind the physical web beacons. They were deliberately dumb, much like the internet itself. All they did was broadcast a URL. That���s it. All the smarts were to be found at the URL itself. That meant a service could get smarter over time. It���s a lot easier to update a website than swap out a piece of hardware.

But any kind of technology that uses Bluetooth, NFC, or other wireless technology has to get over the discovery problem. They���re invisible technologies, so by default, people don���t know they���re even there. But if you make them too discoverable��� intrusively announcing themselves like one of the commercials in Minority Report���then they���re indistinguishable from spam. There���s a sweet spot of discoverability right in the middle that���s hard to get right.

Over the past couple of years���accelerated by the physical distancing necessitated by The Situation���QR codes stepped up to the plate.

They still suffer from some discoverability issues. They���re not human-readable, so you can���t be entirely sure that the URL you���re going to go to isn���t going to be a Rick Astley video. But they are visible, which gives them an advantage over hidden wireless technologies.

They���re cheaper too. Printing a QR code sticker costs less than getting a plastic beacon shipped from China.

QR codes turned out to be just good enough to bridge the gap between the physical and digital for those one-off interactions like dining outdoors during a pandemic:

I can see why they chose the web over a native app. Online ordering is the only way to place your order at this place. Telling people ���You have to go to this website��� ���that seems reasonable. But telling people ���You have to download this app��� ���that���s too much friction.

Ironically, the nail in the coffin for app clips and instant apps might���ve been hammered in by Apple and Google when they built QR-code recognition into their camera software.

One morning in the future

I had a video call this morning with someone who was in India. The call went great, except for a few moments when the video stalled.

���Sorry about that���, said the person I was talking to. ���It���s the monkeys. They like messing with the cable.���

There���s something charming about an intercontinental internet-enabled meeting being slightly disrupted by some fellow primates being unruly.

It also made me stop and think about how amazing it was that we were having the call in the first place. I remembered Arthur C. Clarke���s predictions from 1964:

I���m thinking of the incredible breakthrough which has been possible by developments in communications, particularly the transistor and, above all, the communications satellite.

These things will make possible a world in which we can be in instant contact with each other wherever we may be, where we can contact our friends anywhere on Earth even if we don���t know their actual physical location.

It will be possible in that age���perhaps only 50 years from now���for a man to conduct his business from Tahiti or Bali just as well as he could from London.

The casual sexism of assuming that it would be a ���man��� conducting business hasn���t aged well. And it���s not the communications satellite that enabled my video call, but old-fashioned undersea cables, many in the same locations as their telegraphic antecedents. But still; not bad, Arthur.

After my call, I caught up on some email. There was a new newsletter from Ariel who���s currently in Antarctica.

Just thinking about the fact that I know someone who���s in Antarctica���who sent me a postcard from Antarctica���gave me another rush of feeling like I was living in the future. As I started to read the contents of the latest newsletter, that feeling became even more specific. Doesn���t this sound exactly like something straight out of a late ���80s/early ���90s cyberpunk novel?

Four of my teammates head off hiking towards the mountains to dig holes in the soil in hopes of finding microscopic animals contained within them. I hang back near the survival bags with the remaining teammate and begin unfolding my drone to get a closer look at the glaciers. After filming the textures of the land and ice from multiple angles for 90 minutes, my batteries are spent, my hands are cold and my stomach is growling. I land the drone, fold it up into my bright yellow Pelican case, and pull out an expired granola bar to keep my hunger pangs at bay.

Culture and style

Ever get the urge to style a good document?

No? Just me, then.

Well, the urge came over me recently so I started styling this single-page site:

A Few Notes On The Culture by Iain M Banks

I���ve followed this document across multiple locations over the years. It started life as a newsgroup post on rec.arts.sf.written in 1994. Ken McLeod published it there on Iain M Banks���s behalf.

The post complements the epic series of space opera books that Iain M Banks set in the anarcho-utopian society of The Culture. It���s a fascinating piece of world building, as well as an insight into the author���s mind.

I first became aware of it many few years later, after a copy had been posted to the web. That URL died, but Adrian Hon kept a copy on his site. Lots of copies keep stuff safe, so after contemplating linkrot, I made a copy on this site too.

But I recently thought that maybe it deserved a bit of art direction, so I rolled up my sleeves and started messing around, designing in the browser and following happy little accidents.

The finished result is still fairly sparse. It���s still entirely text, except for a background image that shows up if your screen is wide enough. That image of a planet originally started as an infra-red snapshot of Jupiter by the James Webb Space Telescope that I worked over until it was unrecognisable.

The text itself is the main focus of the design though. I knew I wanted to play around with a variable font. Mona Sans from Github was one of the first ones I tried and I found it instantly suitable. I had a lot of fun playing with different weights and widths.

After a bit of messing around, I realised that the heading styles were reminding me of some later reissues of The Culture novels, so I leant into that, deliberately styling the byline to resemble the treatment of the author���s name on those book covers.

There isn���t all that much CSS. I���ve embedded it in the head of the HTML rather than linking to a separate style sheet, so feel free to view source and poke around in there. You���ll see that I���m making liberal use of custom properties, the clamp function, and logical properties.

Originally I had a light mode and dark mode but I found that the dark mode was much more effective so I ditched the lighter option.

I did make sure to include some judicious styles for print, so if you fancy reading on paper, it should print out nicely.

Oh, and of course it���s a progressive web app that works offline.

I didn���t want to mess with the original document other than making some typographic tweaks to punctuation, but I wanted to break up the single wall of text. I wasn���t about to start using pull quotes on the web so in the end I decided to introduce some headings that weren���t in the original document:

GovernmentEconomicsTechnologyPhilosophyLifestyleTravelHabitatLegal SystemPoliticsIdentityNomenclatureCosmology

If your browser viewport is tall enough, the heading for the current section you���re reading will remain sticky as you scroll. No JavaScript required.

I���m pretty pleased with how this little project turned out. It was certainly fun to experiment with fluid type and a nice variable font.

I can add this to my little collection of single-page websites I���ve whittled over the years:

A Few Notes On The CultureThe G��si��wka StoryDesign PrinciplesBrighton SF

Three attributes for better web forms

Forms on the web are an opportunity to make big improvements to the user experience with very little effort. The effort can be as little as sprinkling in a smattering of humble HTML attributes. But the result can be a turbo-charged experience for the user, allowing them to sail through their task.

This is particularly true on mobile devices where people have to fill in forms using a virtual keyboard. Any improvement you can make to their flow is worth investigating. But don���t worry: you don���t need to add a complex JavaScript library or write convoluted code. Well-written HTML will get you very far.

If you���re using the right input type value, you���re most of the way there. Browsers on mobile devices can use this value to infer which version of the virtual keyboard is best. So think beyond the plain text value, and use search, email, url, tel, or number when they���re appropriate.

But you can offer more hints to those browsers. Here are three attributes you can add to input elements. All three are enumerated values, which means they have a constrained vocabulary. You don���t need to have these vocabularies memorised. You can look them when you need to.

inputmode

The inputmode attribute is the most direct hint you can give about the virtual keyboard you want. Some of the values are redundant if you���re already using an input type of search, email, tel, or url.

But there might be occasions where you want a keyboard optimised for numbers but the input should also accept other characters. In that case you can use an input type of text with an inputmode value of numeric. This also means you don���t get the spinner controls on desktop browsers that you���d normally get with an input type of number. It can be quite useful to supress the spinner controls for numbers that aren���t meant to be incremented.

If you combine inputmode="numeric" with pattern="[0-9]", you���ll get a numeric keypad with no other characters.

The list of possible values for inputmode is text, numeric, decimal, search, email, tel, and url.

enterkeyhint

Whereas the inputmode attribute provides a hint about which virtual keyboard to show, the enterkeyhint attribute provides an additional hint about one specific key on that virtual keyboard: the enter key.

For search forms, you���ve got an enterkeyhint option of search, and for contact forms, you���ve got send.

The enterkeyhint only changes the labelling of the enter key. On some browsers that label is text. On others it���s an icon. But the attribute by itself doesn���t change the functionality. Even though there are enterkeyhint values of previous and next, by default the enter key will still submit the form. So those two values are less useful on long forms where the user is going from field to field, and more suitable for a series of short forms.

The list of possible values is enter, done, next, previous, go, search, and send.

autocomplete

The autocomplete attribute doesn���t have anything to do with the virtual keyboard. Instead it provides a hint to the browser about values that could pre-filled from the user���s browser profile.

Most browsers try to guess when they can they do this, but they don���t always get it right, which can be annoying. If you explicitly provide an autocomplete hint, browsers can confidently prefill the appropriate value.

Just think about how much time this can save your users!

There���s a name value you can use to get full names pre-filled. But if you have form fields for different parts of names���which ���you���ve also got:

given-name,additional-name,family-name,nickname,honorific-prefix, andhonorific-suffix.

You might be tempted to use the nickname field for usernames, but no need; there���s a separate username value.

As with names, there���s a single tel value for telephone numbers, but also an array of sub-values if you���ve split telephone numbers up into separate fields:

tel-country-code,tel-national,tel-area-code,tel-local, andtel-extension.

There���s a whole host of address-related values too:

street-address,address-line1,address-line2, andaddress-line3, but alsoaddress-level1,address-level2,address-level3, andaddress-level4.

If you have an international audience, addresses can get very messy if you���re trying to split them into separate parts like this.

There���s also postal-code (that���s a ZIP code for Americans), but again, if you have an international audience, please don���t make this a required field. Not every country has postal codes.

Speaking of countries, you���ve got a country-name value, but also a country value for the country���s ISO code.

Remember, the autocomplete value is specifically for the details of the current user. If someone is filling in their own address, use autocomplete. But if someone has specified that, say, a billing address and a shipping address are different, that shipping address might not be the address associated with that person.

On the subject of billing, if your form accepts credit card details, definitely use autocomplete. The values you���ll probably need are:

cc-name for the cardholder,cc-number for the credit card number itself,cc-exp for the expiry date, andcc-csc for the security again.

Again, some of these values can be broken down further if you need them: cc-exp-month and cc-exp-year for the month and year of the expiry date, for example.

The autocomplete attribute is really handy for log-in forms. Definitely use the values of email or username as appropriate.

If you���re using two-factor authentication, be sure to add an autocomplete value of one-time-code to your form field. That way, the browser can offer to prefill a value from a text message. That saves the user a lot of fiddly copying and pasting. Phil Nash has more details on the Twilio blog.

Not every mobile browser offers this functionality, but that���s okay. This is classic progressive enhancement. Adding an autocomplete value won���t do any harm to a browser that doesn���t yet understand the value.

Use an autocomplete value of current-password for password fields in log-in forms. This is especially useful for password managers.

But if a user has logged in and is editing their profile to change their password, use a value of new-password. This will prevent the browser from pre-filling that field with the existing password.

That goes for sign-up forms too: use new-password. With this hint, password managers can offer to automatically generate a secure password.

There you have it. Three little HTML attributes that can help users interact with your forms. All you have to do was type a few more characters in your input elements, and users automatically get a better experience.

This is a classic example of letting the browser do the hard work for you. As Andy puts it, be the browser���s mentor, not its micromanager:

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities.

Chain of tools

I shared this link in Slack with my co-workers today:

Cultivating depth and stillness in research by Andy Matuschak.

I wasn���t sure whether it belonged in the #research or the #design channel. While it���s ostensibly about research, I think it applies to design more broadly. Heck, it probably applies to most fields. I should have put it in the Slack channel I created called #iiiiinteresting.

The article is all about that feeling of frustration when things aren���t progressing quickly, even when you know intellectually that not everything should always progress quickly.

The article is filled with advice for battling this feeling, including this observation on curiosity:

Curiosity can also totally change my relationship to setbacks. Say I���ve run an experiment, collected the data, done the analysis, and now I���m writing an essay about what I���ve found. Except, halfway through, I notice that one column of the data really doesn���t support the conclusion I���d drawn. Oops. It���s tempting to treat this development as a frustrating impediment���something to be overcome expediently. Of course, that���s exactly the wrong approach, both emotionally and epistemically. Everything becomes much better when I react from curiosity instead: ���Oh, wait, wow! Fascinating! What is happening here? What can this teach me? How might this change what I try next?���

But what really resonated with me was this footnote attached to that paragraph:

I notice that I really struggle to generate curiosity about problems in programming. Maybe it���s because I���ve been doing it so long, but I think it���s because my problems are usually with ephemeral ideas, incidental to what I actually care about. When I���m fighting some godforsaken Javascript build system, I don���t feel even slightly curious to ���really��� understand those parochial machinations. I know they���re just going to be replaced by some new tool next year.

I feel seen.

I know I���m not alone. I know people who were driven out of front-end development because they felt the unspoken ultimatum was to either become a ���full stack��� developer or see yourself out.

Remember Chris���s excellent post, The Great Divide? Zach referenced it recently. He wrote:

The question I keep asking though: is the divide borne from a healthy specialization of skills or a symptom of unnecessary tooling complexity?

Mostly I feel sad about the talented people we���ve lost because they felt their front-of-the-front-end work wasn���t valued.

But wait! Can I turn my frown upside down? Can I take Andy Matuschak���s advice and say, ���Oh, wait, wow! Fascinating! What is happening here? What can this teach me?���

Here���s one way of squinting at the situation…

There���s an opportunity here. If many people���myself included���feel disheartened and ground down by the amount of time they need to spend dealing with toolchains and build systems, what kind of system would allow us to get on with making websites without having to deal with that stuff?

I���m not proposing that we get rid of these complex toolchains, but I am wondering if there���s a way to make it someone else���s job.

I guess this job is DevOps. In theory it���s a specialised field. In practice everyone adding anything to a codebase partakes in continual partial DevOps because they must understand the toolchains and build processes in order to change one line of HTML.

I���m not saying ���Don���t Make Me Think��� when it comes to the tooling. I totally get that some working knowledge is probably required. But the ratio has gotten out of whack. You need a lot of working knowledge of the toolchains and build processes.

In fact, that���s mostly what companies hire for these days. If you���re well versed in HTML, CSS, and vanilla JavaScript, but you���re not up to speed on pipelines and frameworks, you���re going to have a hard time.

That doesn���t seem right. We should change it.

Mars distracts

A few years ago, I wrote about how much I enjoyed the book Aurora by Kim Stanley Robinson.

Not everyone liked that book. A lot of people were put off by its structure, in which the dream of interstellar colonisation meets the harsh truth of reality and the book follows where that leads. It pours cold water over the very idea of humanity becoming interplanetary.

But our own solar system is doable, right? I mean, Kim Stanley Robinson is the guy who wrote the Mars trilogy and 2312, both of which depict solar system colonisation in just a few centuries.

I wonder if the author might regret the way that some have taken his Mars trilogy as a sort of manual, Torment Nexus style. Kim Stanley Robinson is very much concerned with this planet in this time period, but others use his work to do the opposite.

But the backlash to Mars has begun.

Maciej wrote Why Not Mars:

The goal of this essay is to persuade you that we shouldn���t send human beings to Mars, at least not anytime soon. Landing on Mars with existing technology would be a destructive, wasteful stunt whose only legacy would be to ruin the greatest natural history experiment in the Solar System. It would no more open a new era of spaceflight than a Phoenician sailor crossing the Atlantic in 500 B.C. would have opened up the New World. And it wouldn���t even be that much fun.

Manu Saadia is writing a book about humanity in space, and he has a corresponding newsletter called Against Mars: Space Colonization and its Discontents:

What if space colonization was merely science-fiction, a narrative, or rather a meta-narrative, a myth, an ideology like any other? And therefore, how and why did it catch on? What is so special and so urgent about space colonization that countless scientists, engineers, government officials, billionaire oligarchs and indeed, entire nations, have committed work, ingenuity and treasure to make it a reality.

What if, and hear me out, space colonization was all bullshit?

I mean that quite literally. No hyperbole. Once you peer under the hood, or the nose, of the rocket ship, you encounter a seemingly inexhaustible supply of ghoulish garbage.

Two years ago, Shannon Stirone went into the details of why Mars Is a Hellhole

The central thing about Mars is that it is not Earth, not even close. In fact, the only things our planet and Mars really have in common is that both are rocky planets with some water ice and both have robots (and Mars doesn���t even have that many).

Perhaps the most damning indictment of the case for Mars colonisation is that its most ardent advocate turns out to be an idiotic small-minded eugenicist who can���t even run a social media company, much less a crewed expedition to another planet.

But let���s be clear: we���re talking here about the proposition of sending humans to Mars���ugly bags of mostly water that probably wouldn���t survive. Robots and other uncrewed missions in our solar system ���more of that, please!