But sometimes links look like buttons (and buttons look like links)
Adam Silver

Thanks for writing this. I really appreciate it, because I really disagree with this:

> Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

Here’s my take:

Obscuring *technical implementation* from users is not dishonest. We do not visually differentiate data sent over TCP from data sent over UDP. No one considers this a moral issue, because it serves no user purpose to surface the technical implementation of the transport layer. The distinction between buttons and links, even in the examples cited here, are usually not things that users need to think about. If they are important, we can make that choice as designers and differentiate them.

But in the context of a web application, most users aren’t aware of the difference between a single-page app which routes people with async JS and a traditional app which routes people with HTTP requests. The users shouldn’t have to care because it’s the wrong level of abstraction. But changing that architecture would, if I’m understanding your position correctly, would mean changing all the visual affordances on buttons. Let’s not?

Buttons, links, menus and nav are all levels of visual hierarchy for “do a thing.” It’s not quite as well defined as H1, H2, H3, but in a well designed app, users seem to get it.

If I’m misunderstanding your position, I’d love to learn more. Again, thanks for writing.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.