-- Leo's gemini proxy

-- Connecting to gem.acdw.net:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini; charset=UTF-8

2020-07-13-Way-too-much-UX-UI

Waaaayy too much UX (UI?)

a polemic


I just read this article titled,

"The Trouble with mailto Links" (careful, HTTP!)

that was linked from some other article, probably on lobste.rs or whatever.

(I do a lot of clicking around lobste.rs and hn and stuff at work.)


And basically, this guy, Adam Silver, talks about how they didn't want to just use a mailto link because it doesn't do the right thing on some people's computers (I've been burned by this before -- I try to open a mailto link in Firefox and it pulls up, like, Outlook and starts doing that whole thing, it's frustrating), so they just put the email in plaintext.


Email us at whatever@example.com.

*BUT*! There are good things about mailto links, they say -- if properly configured, users can just click on them and their mail composers will just open up and it'll be so easy! So they add in a mailto link with the "Email us" text, and still include the plaintext email.


<a href="mailto:whatever@example.com">Email us</a> at whatever@example.com.

**BUT**!

Sometimes users don't know about copying and pasting! So we need a big fancy *copy* button *after* the text, too, just in case someone is dumb and doesn't know what their doing.


<a href="mailto:whatever@example.com">Email us</a> at whatever@example.com. <a onclick='random-shit.js'>Copy</a>

What the F!

Here's the thing -- I work with people who are computer-illiterate all the time. People who don't know what copying and pasting is, or don't have an email address, or don't really know how to use a mouse. *Those* people aren't going to be helped by having a little "Copy!" button next to the email thing -- they don't really grok the mental model of a clipboard. So that "Copy!" button isn't for them.

And people who do know what email, and copy-pasting is, and all that -- they know they can *select* arbitrary text and copy-paste it to the Subject: field in their mail writer, so the "Copy!" button isn't for them either.

And of course, sane (not Edge, sadly) browsers have a convenient "Copy Email Address" item in the context menu for mailto links. So it's trivial for people who *know* what they're doing to copy the email -- or shit, select the text with your mouse and hit C-c, or right-click, or whatever. Shit ain't hard. Worst-case, open the mail writer side-by-side and manually type out the email address in the To: field. It's probably not too long: it would behoove companies to use short, easily-typeable email addresses, right?


So who. is. all. this. for!?!?!


I have a theory. I think it's for the designer, because they just thought and thought and thought and decided they needed to hold their users' hands through the whole thing. It just seems like too much UX, or UI, or whatever. I don't actually know the differences between those terms.


The greatest thing about all of this is at the bottom of the article, there's a "What we'd really like" section. I'll just quote it here, it's short:


> This is such a common problem and it feels like something browsers and operating systems should fix.

>

> We think the ideal solution would be for users who click or tap on the mailto link to see a menu with choices like:

>

> Send an email from Gmail

> Email from another account

> Copy email address

> Share email address via…

>

> This would answer the most common needs, and gives most users a way forward.

>

> And that’s our little story about mailto links. What do you think?


Every single thing they mention in this list is a client problem. There's literally nothing they should be able to do about it, in my opinion -- just provide us the link in a consumable format and let the client do what it does. While that can be a simple text that's copy-pastable, the mailto: protocol is the actual thing that makes an email machine-readable too.


I guess what I'm saying is, poor Adam Silver thinks that they need to create every aspect of the user's experience for them, when their users are using vastly different technologies to access their websites. (Well maybe not *vastly different*, but different enough.) Their worry is a symptom of the modern web, where users pin everything on site owners, and site owners try to lock down as much as they can the user experience -- hijacking scrolling, using DRM to track users (!!), locking text in images, or whatever. I actually can't think of a good list right now, sue me. I'm tired and hungry.


And that brings me to this little protocol, gemini. (You knew this would come around to gemini, right?) One thing I really like about gemini is how *easy* it is to make a client, and how that means that servers kind of have to stay in-spec, or rather that content-authors don't have an incentive to hand-hold their users. Maybe that's because we're all still kind of nerds, actually that's probably it. But I *like* how gemini encourages simple interactions between servers and clients, and gives clients the leeway to be user-agents, where the *user* decides how things are displayed and decided and run through. I *know* what I want to do with mailto links, and gemini lets me do it. It's nice.



~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Copyright (c) 2019-2020 Case Duckworth. CC-BY-SA.

History

Raw

HTML

-- Response ended

-- Page fetched on Thu May 2 16:55:04 2024