[Public Catalog] external links in the quickstarts markdown should be highlighted with the external link icon

[jpvajda]

When external links are used in quickstart descriptions we should be highlighted those links with the external link icon so the user knows they'll be taking out of the New Relic experience.

Design Questions

• is this the preferred approach? will be confirmed at our next design <> deven sync, but it's assume this is an OK approach

Acceptance Criteria

• all links that exist in the description of a quickstart that point to URL outside of the devsite within the I/O expeirence (eg; quickstart descriptions) should show the external link icon.
• Share this change with DevEx to see if they also want to take the same approach in the product.

Screenshot

[aswanson-nr]

@jpvajda

1. Can we split this up into 2 tickets? One for the quickstart descriptions and one for the rest of the I/O experience.
2. Does "external" mean that docs.newrelic.com is external to developer.newrelic.com?

Approach idea: Look into parsing for links, then replacing them with the link component. Look into how the docs site parses and displays links. - @aswanson-nr

[aswanson-nr]

The ReactMarkdown library, which we are using, allows you to specify react components that replace the normal HTML. So we can specify a custom React component for the a tag. Documentation

[jpvajda]

1 Sure. 2 tickets is fine with me.

2 Good question. We would follow the same pattern we use today for links in the related resources component, all links that are external of the primary domain get the external link icon.

[rudouglas]

Just waiting for the theme to be updated until this can be done

[nr-opensource-bot]

🎉 This issue has been resolved in version 1.67.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[legnaleama]

Here's the design research on this: https://www.figma.com/file/0jsTPLtwz6Bljndkbr1COn/?node-id=339%3A9078

TLTR:
SOLUTION

A - Quick fix
Add ”new tab/external” icon to all external links in both developer.newrelic.com and docs.newrelic.com

B - Medium fix
Stop loading pages that share the navbar on a new tab to avoid creating the experience of being in a new site.

By allowing users to perceive each of the links on the navbar as sections of the same website we'll remove the need to indicate links pointing to docs.newrelic.com as external when used in the Developers site and vice versa.

This would reduce the cognitive strain and simplify the experience but it won't solve the current content maze.

C - Large fix
Merge Developers and Docs content and re-structure content in a way that makes it accessible and easy to find (when the user needs it).

By merging both sites and creating a robust and intuitive content structure we'll reduce significantly the amount of ”external” links and we'll streamline access to troubleshooting to those users who are looking for answers.

External links will stop being the majority (in the case of Developers) and therefore indicating those that are actually really external we'll make the whole UX more robust and user friendly.

[jpvajda]

Thanks @legnaleama

I like B in the short term, here is some more context on C happy to talk through this more as it's been a topic for a long while. 😄

C is something we've been discussing for sometime, and there are arguments on both sides to keep them seperate properties or merge them together. My major concern with merging Dev content into Docs are:

1. Docs is a huge set of content, with multiple contributors and daily releases. The build times are very slow and overall contributor process is fairly robust. As we look to localize content this will get even more complex. So if we want to keep dev site content nimble and more agile, we may want to keep it a seperate property

2. Dev Site has an SDK bundle that populates the Component documentation, it's integrated with the Dev Site to generate our external SDK documentation. That doesn't exist on Docs

3. Docs content is more verbose in nature, it's also thousands of pages. the Dev Site is focused on very specific user and the style of content is optomized for developers.

4. Docs content is produced by the Docs Team, Developer content is product by developer advocacy, they are different teams focused on slightly different use cases, but there of course is overlap.

5. It be a decent size project to merge the 2 together that would need prioritization.

For merging them, you could argue that

1. one source of truth for all product docs is a logical way to go
2. we'd reduce our gatsby site count by 1 total site.
3. Also if the tech docs team then owned the developer content more, we'd have better coverage for that content production.

[jpvajda]

@roadlittledawn may have thoughts on this as well. 👋