Summary
Add a clear Details action to every pending-update row/card in the Batch Update page.
The action should appear immediately to the left of Update:
Details · Update · Ignore
Its purpose is to make the existing “open this script’s update details” behavior discoverable, so users can intentionally review the detailed changes before deciding whether to update.
Today, users can open the detailed update view by clicking the script name, but that interaction is not obvious. A script name primarily reads as identification, not as an action.
This should be treated as an explicit review action in the row, while keeping the script name clickable as a convenient shortcut.
Related broader Batch Update UX review: #1775.
Background
The current Batch Update page already gives users useful summary information in each row:
- current version → new version;
- code-change risk;
- new
@connect warning;
- source;
- enabled/disabled state;
- Update / Ignore actions.
The script name is also clickable. Clicking it invokes the current “open update page” flow, which can show the full update/install view.
That capability is useful, but it is hidden behind a weak affordance.
A user looking at a row naturally sees:
script information → risk information → Update / Ignore
There is no explicit action telling them:
“You can inspect the detailed changes before updating.”
This makes the safest review path less discoverable than the destructive/committing action.
Problem
1. Clicking the script name is not an obvious action
The script name looks like content.
Even with hover styling, users should not need to discover by experimentation that the name opens another page.
This is especially easy to miss for:
- first-time users;
- touch users, where hover cues do not exist;
- keyboard users scanning the action column;
- users focused on the right side of the row where Update and Ignore are located.
2. The action hierarchy currently jumps directly to Update
The row exposes Update as the main positive action, but the explicit review step is hidden elsewhere.
For updates with:
- a major code change;
- new
@connect domains;
- an unfamiliar source;
- a large version jump;
users may reasonably want to inspect the detailed change before committing.
The UI should make that path obvious.
3. “Details” communicates intent better than relying on the script title
An explicit action makes the interaction self-documenting:
| Action |
User intent |
| Details |
Review the update before making a decision |
| Update |
Apply the update |
| Ignore |
Ignore this version |
That is easier to understand than assigning both “identify this script” and “open review page” to the script name alone.
Proposed UI
Desktop
Current:
Update · Ignore
Proposed:
Details · Update · Ignore
Details should be immediately to the left of Update.
The visual hierarchy should still make Update the primary action. Details can use a neutral/secondary text treatment.
For example:
- Details — neutral/secondary
- Update — primary
- Ignore — muted
The exact styling should follow the existing design system rather than introducing a new button style.
Mobile
The same action should be available in each pending-update card.
Suggested order:
Details · Update · Ignore
Because mobile space is limited, the implementation should preserve adequate touch targets and spacing. This should be considered together with the mobile touch-target improvements described in #1775.
Interaction behavior
Details
Clicking Details should open the same detailed update/review experience that users currently reach by clicking the script name.
The existing script-name interaction should remain available as a shortcut.
Both entry points should share the same loading and duplicate-click protection so that opening Details repeatedly cannot create multiple update tabs.
Update
No behavior change is requested.
Ignore
No behavior change is requested.
Important semantic consideration: “Details” must be a review action
There is one existing behavior that should be reviewed as part of this feature.
Current Batch Update logic calls requestOpenUpdatePageByUUID() when the script name is clicked. That call can return "silent", and the current UI then treats the script as successfully updated.
In other words, under silent-update configuration, the current “open details” path can itself perform an update instead of opening a review page.
That behavior is potentially confusing if we expose it using a button explicitly labeled Details.
A button called Details creates a strong expectation that the action is non-committing:
“Show me more information before I decide.”
It should not unexpectedly install the update.
Desired semantic contract
Details should open a review/detail view and should not itself apply the update.
If the existing script-name path cannot guarantee this, implementation may need to separate:
- review/open details, and
- update/install
instead of wiring the new button blindly to the existing onOpen behavior.
If the product intentionally wants script-name clicking to retain silent-update behavior, then the new explicit review action still needs a read-only/review-safe path.
This distinction is important because the main purpose of this feature is to encourage users to inspect changes before clicking Update.
Loading and error states
The page already has useful state handling for opening the detailed view. The new action should reuse those principles.
While Details is opening:
- show an inline loading state on the Details action;
- prevent repeated Details clicks;
- prevent a simultaneous script-name click from opening another copy;
- keep the row otherwise stable.
If opening fails:
- keep the row in place;
- show the existing actionable error feedback;
- allow the user to retry.
The loading state should not cause the action column to resize significantly.
Accessibility
The new action should follow the repository's existing accessibility rules.
In particular:
- use a real
button or shared Button primitive;
- provide a visible
focus-visible indicator;
- keep the label available to screen readers;
- do not make hover the only indication that the action exists;
- provide an adequate mobile hit area.
Keyboard order should follow the visual order:
Details → Update → Ignore
Internationalization
Add a dedicated translation key for the action label rather than hardcoding the English text.
Suggested English label:
Details
“Review changes” is another possible wording, but Details is shorter and fits naturally beside Update / Ignore.
The final wording should remain consistent across desktop and mobile.
Scope
In scope
- Add an explicit Details action to each pending-update row/card.
- Place it immediately left of Update.
- Keep script-name clicking as an alternate shortcut.
- Share opening/loading/error/deduplication state between both entry points.
- Ensure the Details action is review-safe and does not unexpectedly install an update.
- Support desktop and mobile.
- Add/update i18n strings and tests.
Not required by this issue
- Redesigning the detailed update/install page itself.
- Changing Update or Ignore semantics.
- Reworking the complete Batch Update layout.
- Removing script-name click behavior.
- Restoring the old Batch Update UI.
Acceptance criteria
Design intent
The key idea is simple:
Review should be an explicit action, not a hidden property of the script name.
The Batch Update page already contains good summary-level risk information. Adding a visible Details action gives users a clear next step when that summary tells them an update deserves closer inspection.
It makes the safer workflow obvious:
See update → inspect details → decide → update
rather than relying on users to discover that the script name happens to be clickable.
Summary
Add a clear Details action to every pending-update row/card in the Batch Update page.
The action should appear immediately to the left of Update:
Its purpose is to make the existing “open this script’s update details” behavior discoverable, so users can intentionally review the detailed changes before deciding whether to update.
Today, users can open the detailed update view by clicking the script name, but that interaction is not obvious. A script name primarily reads as identification, not as an action.
This should be treated as an explicit review action in the row, while keeping the script name clickable as a convenient shortcut.
Related broader Batch Update UX review: #1775.
Background
The current Batch Update page already gives users useful summary information in each row:
@connectwarning;The script name is also clickable. Clicking it invokes the current “open update page” flow, which can show the full update/install view.
That capability is useful, but it is hidden behind a weak affordance.
A user looking at a row naturally sees:
There is no explicit action telling them:
This makes the safest review path less discoverable than the destructive/committing action.
Problem
1. Clicking the script name is not an obvious action
The script name looks like content.
Even with hover styling, users should not need to discover by experimentation that the name opens another page.
This is especially easy to miss for:
2. The action hierarchy currently jumps directly to Update
The row exposes Update as the main positive action, but the explicit review step is hidden elsewhere.
For updates with:
@connectdomains;users may reasonably want to inspect the detailed change before committing.
The UI should make that path obvious.
3. “Details” communicates intent better than relying on the script title
An explicit action makes the interaction self-documenting:
That is easier to understand than assigning both “identify this script” and “open review page” to the script name alone.
Proposed UI
Desktop
Current:
Proposed:
Details should be immediately to the left of Update.
The visual hierarchy should still make Update the primary action. Details can use a neutral/secondary text treatment.
For example:
The exact styling should follow the existing design system rather than introducing a new button style.
Mobile
The same action should be available in each pending-update card.
Suggested order:
Because mobile space is limited, the implementation should preserve adequate touch targets and spacing. This should be considered together with the mobile touch-target improvements described in #1775.
Interaction behavior
Details
Clicking Details should open the same detailed update/review experience that users currently reach by clicking the script name.
The existing script-name interaction should remain available as a shortcut.
Both entry points should share the same loading and duplicate-click protection so that opening Details repeatedly cannot create multiple update tabs.
Update
No behavior change is requested.
Ignore
No behavior change is requested.
Important semantic consideration: “Details” must be a review action
There is one existing behavior that should be reviewed as part of this feature.
Current Batch Update logic calls
requestOpenUpdatePageByUUID()when the script name is clicked. That call can return"silent", and the current UI then treats the script as successfully updated.In other words, under silent-update configuration, the current “open details” path can itself perform an update instead of opening a review page.
That behavior is potentially confusing if we expose it using a button explicitly labeled Details.
A button called Details creates a strong expectation that the action is non-committing:
It should not unexpectedly install the update.
Desired semantic contract
Details should open a review/detail view and should not itself apply the update.
If the existing script-name path cannot guarantee this, implementation may need to separate:
instead of wiring the new button blindly to the existing
onOpenbehavior.If the product intentionally wants script-name clicking to retain silent-update behavior, then the new explicit review action still needs a read-only/review-safe path.
This distinction is important because the main purpose of this feature is to encourage users to inspect changes before clicking Update.
Loading and error states
The page already has useful state handling for opening the detailed view. The new action should reuse those principles.
While Details is opening:
If opening fails:
The loading state should not cause the action column to resize significantly.
Accessibility
The new action should follow the repository's existing accessibility rules.
In particular:
buttonor shared Button primitive;focus-visibleindicator;Keyboard order should follow the visual order:
Internationalization
Add a dedicated translation key for the action label rather than hardcoding the English text.
Suggested English label:
“Review changes” is another possible wording, but Details is shorter and fits naturally beside Update / Ignore.
The final wording should remain consistent across desktop and mobile.
Scope
In scope
Not required by this issue
Acceptance criteria
Design intent
The key idea is simple:
The Batch Update page already contains good summary-level risk information. Adding a visible Details action gives users a clear next step when that summary tells them an update deserves closer inspection.
It makes the safer workflow obvious:
rather than relying on users to discover that the script name happens to be clickable.