Try: make the "primary colum" clickable

[oandregal]

Related conversation: QOBjujZah0UlGDDdLKZhzi-fi#1247411599

Proposed Changes

This PR makes the primary column of the DataViews table clickable and removes the other clickable target in the same cell (external link to site).

Before:

Screen.Recording.2025-05-09.at.12.18.05.mov

After:

Screen.Recording.2025-05-09.at.12.17.38.mov

Why are these changes being made?

Having two clickable targets is the same cell is prone to errors — they are small targets. Additionally, it was brought up in a few places that the "clicking the title field" to trigger an action was not very discoverable. This PR addresses it by making the whole cell clickable, without changing anything else.

TODO

Test/Verify other flows (layouts, with/without title field, etc.).

Testing Instructions

In the v2 dashboard, go to sites and click on the "primary column".

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-143556

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-143556&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-143556&env=a8c-for-agencies

[oandregal]

@StevenDufresne @jasmussen @ntsekouras @matt-west this PR is an attempt to address what was discussed in QOBjujZah0UlGDDdLKZhzi-fi-1059_63137#1247411599

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• help-center
• notifications
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug try/primary-field-click on your sandbox.

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~8 bytes added 📈 [gzipped])

name                parsed_size           gzip_size
staging-site              +37 B  (+0.0%)       +8 B  (+0.0%)
sites-dashboard           +37 B  (+0.0%)       +8 B  (+0.0%)
site-settings             +37 B  (+0.0%)       +8 B  (+0.0%)
site-performance          +37 B  (+0.0%)       +8 B  (+0.0%)
site-monitoring           +37 B  (+0.0%)       +8 B  (+0.0%)
site-logs                 +37 B  (+0.0%)       +8 B  (+0.0%)
plans                     +37 B  (+0.0%)       +8 B  (+0.0%)
overview                  +37 B  (+0.0%)       +8 B  (+0.0%)
hosting                   +37 B  (+0.0%)       +8 B  (+0.0%)
github-deployments        +37 B  (+0.0%)       +8 B  (+0.0%)
domains                   +37 B  (+0.0%)       +8 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[jasmussen]

Let me know if I'm testing right, I'm seeing the following:

Note here the curious focus style, it should just be the standard one.

We have mixins for it in base-styles.

The main change here is making the whole left area clickable to open the site. This feels valid to me. I do wonder if we should remove the hover style from the entire row, if that doesn't do anything. 🤔

[ntsekouras]

I think the approach makes sense, though we should do it for every layout, if we end up moving on with this.

We should consider what this means for this specific usage in sites and what it means in general.

Someone could argue that a description field should be more 'descriptive' and it would be fine not to have extra links(click behavior) and I personally agree with this. But then we need to consider why we had the link of the site there in the first place? Is it the best place to have it there or it could work just fine by replacing it with another field or probably a primary action (view site)?

Another thing we should consider is how this experience feels when multi selection is enabled, because in the sites list is not. Would it feel weird that clicking on other cells the item is selected and on the primary is not? 🤔

[oandregal]

Another thing we should consider is how this experience feels when multi selection is enabled, because in the sites list is not. Would it feel weird that clicking on other cells the item is selected and on the primary is not? 🤔

I think this is the key knot to untie. It's something @jameskoster also brought up in p1746786699361669-slack-C05QAFZSFTL. I don't think the two experiences mix well as it stands.

There's been so many instances of this being an issue or brought up by people that it's leading me to think the current behavior is not working as intended. Happy to hear ideas of how to address it.

[oandregal]

Let me know if I'm testing right, I'm seeing the following:

Yeah, that's right.

In terms of styles, there's probably things to do if we wanted to explore this path in depth (just prepared the micro-interaction for us to get a sense of how would it work with other things).

[matt-west]

we need to consider why we had the link of the site there in the first place? Is it the best place to have it there or it could work just fine by replacing it with another field or probably a primary action (view site)?

We had explored having the domain in a dedicated column, but moved it under the site title to save space. It’s useful to have the domain visible to distinguish between sites with similar names, but it doesn’t need to be clickable.

[matt-west]

The main change here is making the whole left area clickable to open the site. This feels valid to me.

+1. Dotcom has this behaviour in the sites table today, but I assume it was implemented in a non-standardised way.

I do wonder if we should remove the hover style from the entire row, if that doesn't do anything. 🤔

The hover style can still be useful for visually identifying the hovered row when you have a lot of items in the table.