General UI/UX improvements

[canerakdas]

• On mobile layouts, headings are getting cut off. The design could be updated to better match Figma.

Figma;

https://www.figma.com/design/a10cjjw3MzvRQMPT9FP3xz/Node.js?node-id=696-19108&t=1LYJN1JiPyrfM4Ie-0

• I think the tab titles are not very clear. They actually indicate the type of code shown and are essentially examples. Renaming them to something like Example [CJS], Example [MJS], and displaying the type separately could be more intuitive.

For example;

• The colors of tables and code boxes don’t match. Using similar border colors would improve visual consistency.

• Meta description tags are missing on the pages; we could add them (possibly reusing the ones from the website).

• Adding a simple footer could be useful, including important links for us (even if they’re not things like Latest LTS or Latest Release).

• We could reuse the OG image from the website here as well, to ensure a more consistent look when shared on social media.

[avivkeller]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was the original plan, but it was noted to me that removing the column may seem inconsistent (cc @ovflowd)

[avivkeller]

In the documentation, the second select in the root directory shows up empty. Adding a label or placeholder would make it clearer even when nothing is selected.

That's a known bug (@ovflowd and I were just talking about it) with core's old tooling.

It requires that the index page have no title. Once @flakey5's migration PR lands, this requirement will no longer be needed, and thus, we will be able to add a title.

[ovflowd]

On mobile layouts, headings are getting cut off. The design could be updated to better match Figma.

I feel that the current way is better, not gonna lie. On Desktop of course we could use hovers, but IMO the best fix here is simply what @avivkeller is kinda incrementally doing which is "reformatting how these method names" display on headers. So the actual signature is part of the signature codebox and we have the method itself simplified (only method name) on the header. This will also merge different signatures tho.

[ovflowd]

I think the tab titles are not very clear. They actually indicate the type of code shown and are essentially examples. Renaming them to something like Example [CJS], Example [MJS], and displaying the type separately could be more intuitive.

I think this is just a known bug of 2+ codetabs being merged altogether, when kinda they shouldn't? But I agree that an alternative fix is better naming, I like the proposed idea.

[ovflowd]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was a me requirement. Keeping the columns creates visual consistency.

[ovflowd]

The logo in the header should link to the Node.js website, as it does in the legacy version. Currently, there’s no redirect to the website.

I think it does redirect to "/", it's just that on our preview branch domains that's the API docs themselves. But once ported to nodejs.org, that click will actually lead to the website. (@avivkeller correct me if I'm wrong).

[ovflowd]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was the original plan, but it was noted to me that removing the column may seem inconsistent (cc @ovflowd)

Yeah, I wanted to leave consistency here, hence keeping these columns.

[canerakdas]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was a me requirement. Keeping the columns creates visual consistency.

At the very least, IMO we can provide a better visual treatment for sections where only the type is indicated. For example, you can compare the rest of this document with the legacy version;

https://api-docs-tooling-mv07kw6is-openjs.vercel.app/errors.html#errorstacktracelimit

https://nodejs.org/docs/latest/api/errors.html#errorstacktracelimit

[ovflowd]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was a me requirement. Keeping the columns creates visual consistency.

At the very least, IMO we can provide a better visual treatment for sections where only the type is indicated. For example, you can compare the rest of this document with the legacy version;

api-docs-tooling-mv07kw6is-openjs.vercel.app/errors.html#errorstacktracelimit

nodejs.org/docs/latest/api/errors.html#errorstacktracelimit

Could you better explain/give an example of what you mean with your sentence above? 👀

[canerakdas]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was a me requirement. Keeping the columns creates visual consistency.

At the very least, IMO we can provide a better visual treatment for sections where only the type is indicated. For example, you can compare the rest of this document with the legacy version;
api-docs-tooling-mv07kw6is-openjs.vercel.app/errors.html#errorstacktracelimit
nodejs.org/docs/latest/api/errors.html#errorstacktracelimit

Could you better explain/give an example of what you mean with your sentence above? 👀

Looking back at the legacy version, IMO it feels more compact and tableless, and it directly meets developers needs.

That said, these are completely different solutions. Rather than implementing a separate solution for a specific group (as mentioned above), I’ll try to work on a solution that I believe is better overall. I also agree that this is the best approach for now

[ovflowd]

For missing values in tables, we currently use “-”. If a column doesn’t have values at all, removing that column entirely might result in a mobile/desktop cleaner appearance.

This was a me requirement. Keeping the columns creates visual consistency.

At the very least, IMO we can provide a better visual treatment for sections where only the type is indicated. For example, you can compare the rest of this document with the legacy version;
api-docs-tooling-mv07kw6is-openjs.vercel.app/errors.html#errorstacktracelimit
nodejs.org/docs/latest/api/errors.html#errorstacktracelimit

Could you better explain/give an example of what you mean with your sentence above? 👀

Looking back at the legacy version, IMO it feels more compact and tableless, and it directly meets developers needs.

That said, these are completely different solutions. Rather than implementing a separate solution for a specific group (as mentioned above), I’ll try to work on a solution that I believe is better overall. I also agree that this is the best approach for now

I'm not sure what you're trying to imply here 🤔