Deprecate Link Buttons.

[cogwizzle]

We should deprecate link buttons because the design language is confusing for our customers. While our vision impaired users don't see a difference based on the element type our non vision impaired users see a link, and have an expectation of link behavior, but instead they get button behavior. Let's keep the web working like the web.

Examples of this component on the Paste site.

My proposed behavior is to deprecate the functionality in the next major version. We can do this by removing the documentation, and then adding a deprecated JSDoc comment in order to prevent future users from using that variant.

This was pointed out before, but we sort of punted a solution to this problem. #3759

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Sorry, I don't know how to help with that.

I did do a search though, and I managed to find these other Discussions that might be similar or related to your question. Give them a read to see if they answer your question. If they do, head back here and update this discussion and mark it as answered, pointing others to the related discussion:

• Button as Link doesn't work as intended - Answer (updated: 07/27/2022, similarity score: 85%)
• Button as Link doesn't work as intended (updated: 07/27/2022, similarity score: 85%)
• Button disabling vs hiding (updated: 01/10/2024, similarity score: 85%)

[cogwizzle]

This is not what I'm looking for.

[serifluous]

Hey @cogwizzle

the design language is confusing for our customers.

Can you share any research/evidence you have pointing to this? Would love to learn more, and add the insights to our guidelines.

fwiw our team has always theoretically agreed with you about this: Links should look and work like links. Buttons should look and work like buttons. We resisted adding link-style buttons early on, until we had overwhelming requests from feature teams & design leads. It's also why we tell people not to use it until they've exhausted all other solutions: https://paste.twilio.design/patterns/button-vs-anchor#link-style-button-tertiary

Right now, we don't expect to be able to deprecate it without facing major pushback from feature teams. If you can help out, and encourage folks to avoid link-style buttons as you see them, we'd definitely appreciate that.

[cogwizzle]

Oh and one more thing. I've done both of these things in the past at other jobs. I'm trying to repent for my previous sins by not letting others make the same mistake.

[TheSisb]

The (albeit minor) difference between Anchors and Link style buttons is that Anchors have an underline that dissapears on hover, and the Link style buttons have no underline, but one appears on hover.

As Sarah said, people were doing worse things when we didn't have this and that's the compromise we could take. As we discussed in the other thread about people deviating from the guidance, this was one of those things. It's not ideal, and we warn against it, but implementing it with that warning was the least worst option. This way, we could at least tell designers why it was a bad choice and that it wasn't recommended.

[cogwizzle]

Thanks for the response again. I think Twilio has a responsibility to build a design system that enhances the web experience. This fundamentally feels like we're disagreeing with the platform and the combined wisdom of 30 years of history.

The minor differences between the two experiences is really hard to spot. Honestly had you not told me the difference I wouldn't have noticed it. Maybe just removing the underline makes sense since it gives the appearance of link. Then we could use font-weight on hover so that it appears more button like. Further differentiation might be a path to a reasonable solution.

I don't think Twilio should bend our design systems to compromises that go against the web platform. As you've said previously we need the guardrails to protect the overall experience for our users. This is a circumstance where we're bending the rules in a way that is harmful and counter intuitive.

I think based on the conversation with @serifluous it sounds like the Paste engineers largely agree that link style buttons are a bad idea.

On one of our other threads we spoke about not being able to guide engineers to use the semantic elements of the web in a correct manner. Is there confidence that a warning message in the Paste documentation will be any better? I doubt it would be referred to in a certain capacity because to my knowledge our design tools wouldn't show that message. I know based on the typescript files we don't get any guidance from the LSP servers to not do this from a developer perspective. Should Paste add JSDoc comments to ensure the message is viewable during the implementation?

I have a few follow up questions. Maybe you'll be able to answer them.

1. What were the worse solutions?
2. What guardrails do designers and engineers have in place to prevent them from ignoring the design system?
3. Is this a people process?
4. Do we have a review process when we deviate from the design system?
5. What responsibility does Paste own to ensure that the design system is communicated directly in the tools they're used in?

[TheSisb]

I value your commitment to Paste and your dedication to ensuring its success. However, I've noticed an increasing number of inquiries about our system, which can sometimes border on undermining our efforts. While seeking clarity is essential, it's crucial to maintain a constructive dialogue.

We've provided explanations for our decisions, and I understand if they may not fully align with your expectations. Please know that our choices are influenced by various factors, including the dynamics within our company. This variant should seldom be used; since you're in agreement, please promote its non-use in your respective product experience.

It's important to acknowledge that revisiting past decisions can be time-consuming. I trust in your understanding of our experience and expertise. Our commitment to promoting accessibility underscores our thorough consideration of all options.

[cogwizzle]

@TheSisb, firstly I'd like to apologize if my messages are coming across in a way in which you feel is undermining your efforts. This is not my intent. The very dynamic of discussions like these can at times be adversarial. I certainly understand that the Paste team has positive intentions as do I.

My persistence on this topic is to try and be as detailed and verbose as possible. I am trying to leave nothing unsaid with my perspective. As I am seeking to influence the future direction of our design system I felt like this was the best possible chance I had at achieving my desired outcome. I am by no means a perfect communicator, and generally my approach is to be heard and back off when I meet resistance. However, in this circumstance I felt that the message was worth extended effort as the potential positive impact I saw an opportunity for was very wide reaching. There are very few things that can change and have such as large an impact as a design system.

I acknowledge your time is valuable, and it can be time consuming to revisit old decisions. What other forum would a person in my shoes have to influence the direction? My understanding is that discussions is that forum? My hope was that this would be a forum where I could find like minded individuals that would both bolster my perspective, and individuals that might challenge it so that Paste could end up in the best possible position.

If you have any specific constructive criticism you can give me about my communication style I would be happy to hear you out.