Problem
The connections strip currently uses the workspace container name as its visible label:
- the database name for database-oriented engines
- the schema name for schema-oriented engines
- the connection name only when no container name is available
This keeps the strip compact and makes the active database or schema visible. However, it does not provide enough visible context to identify which connection a workspace belongs to.
The problem becomes especially noticeable when multiple connections contain a database or schema with the same name.
For example:
| Connection |
Database |
| Production |
app |
| Staging |
app |
Both entries are rendered as app. If they use the same database engine and do not have custom connection colors, the rows can appear visually identical.
The full connection name and host are available in the tooltip and accessibility label, but users must hover over each entry to determine which environment or connection it belongs to. This makes the strip difficult to scan and increases the risk of selecting the wrong workspace.
Goal
Make every workspace in the connections strip identifiable at a glance by showing both its connection identity and its database or schema context.
The information hierarchy should be:
- connection name
- database or schema name
For example:
Production · appStaging · appProduction · analytics
The connection name should come first because it usually carries the most important distinguishing context, such as the environment, server, project, or account. The database or schema name should remain visible as the specific workspace within that connection.
The design should preserve:
- the compact width of the connections strip
- support for one connection having multiple open databases or schemas
- the existing connection color, tooltip, accessibility, and status indicators
- stable labels that do not change when another workspace is opened or closed
Connection colors should remain a helpful secondary cue, but they should not be required to distinguish workspaces.
Expected behavior
A workspace entry should expose its connection name and database or schema name without requiring hover.
When both values are available, the connection name should appear first.
Examples:
Production · appProduction · analyticsStaging · app
The exact presentation may vary depending on the available width. Possible presentations include:
- a single-line
Connection · Container label
- the connection name as the primary label with the database or schema as smaller secondary text
- another compact layout that preserves the same information hierarchy
If the database engine does not provide a distinct database or schema container, the entry may continue to display only the connection name.
Labels should remain stable. Opening another workspace with the same container name should not cause an existing label to change from app to Production · app.
The final presentation should account for long connection and container names, the narrow rail width, and the existing middle-truncation behavior.
Why connection comes first
The connection name is generally the safety-critical part of the workspace identity.
For example, Production, Staging, and Development identify environments, while each environment may contain a database with the same name, such as app.
Displaying the connection first:
- makes environments distinguishable from the beginning of the label
- improves scanning when multiple rows share the same database or schema name
- groups multiple workspaces from the same connection naturally
- reduces the risk of selecting the wrong environment
- keeps the label stable regardless of which other workspaces are currently open
For example:
Production · app
Production · analytics
Staging · app
Development · app_dev
This is easier to scan by connection than:
app · Production
analytics · Production
app · Staging
app_dev · Development
Acceptance criteria
- Every workspace with both a connection name and a database or schema name exposes both values without requiring hover.
- When both values are displayed, the connection name appears before the database or schema name.
- Two workspaces with the same database name on different connections are distinguishable at a glance.
- Two workspaces with the same schema name on different connections are distinguishable at a glance.
- Multiple databases or schemas opened from the same connection remain distinguishable.
- Workspace labels remain stable when other workspaces are opened or closed.
- Identification does not depend on users assigning custom connection colors.
- Long connection and container names remain readable through an appropriate truncation or layout strategy.
- The tooltip continues to expose the full connection name, host, and database or schema name.
- VoiceOver continues to announce the full connection identity, container, and connection state.
- Connected, connecting, disconnected, and failed states remain visually distinguishable.
- Engines without a distinct switchable database or schema continue to show a meaningful connection label.
- Automated tests cover duplicate container names across different connection IDs.
- Automated tests cover multiple containers belonging to the same connection.
- Existing workspace switching, selection, reordering, closing, and keyboard navigation behavior remains unchanged.
Example scenario
Given these open workspaces:
| Connection |
Container |
| Production |
app |
| Staging |
app |
| Development |
app_dev |
| Production |
analytics |
The connections strip should display enough information to distinguish all four workspaces without requiring hover.
A valid presentation would be:
Production · app
Staging · app
Development · app_dev
Production · analytics
The two workspaces using the app database are distinguishable by their connection names, and the two workspaces belonging to Production remain distinguishable by their container names.
Problem
The connections strip currently uses the workspace container name as its visible label:
This keeps the strip compact and makes the active database or schema visible. However, it does not provide enough visible context to identify which connection a workspace belongs to.
The problem becomes especially noticeable when multiple connections contain a database or schema with the same name.
For example:
Both entries are rendered as
app. If they use the same database engine and do not have custom connection colors, the rows can appear visually identical.The full connection name and host are available in the tooltip and accessibility label, but users must hover over each entry to determine which environment or connection it belongs to. This makes the strip difficult to scan and increases the risk of selecting the wrong workspace.
Goal
Make every workspace in the connections strip identifiable at a glance by showing both its connection identity and its database or schema context.
The information hierarchy should be:
For example:
Production · appStaging · appProduction · analyticsThe connection name should come first because it usually carries the most important distinguishing context, such as the environment, server, project, or account. The database or schema name should remain visible as the specific workspace within that connection.
The design should preserve:
Connection colors should remain a helpful secondary cue, but they should not be required to distinguish workspaces.
Expected behavior
A workspace entry should expose its connection name and database or schema name without requiring hover.
When both values are available, the connection name should appear first.
Examples:
Production · appProduction · analyticsStaging · appThe exact presentation may vary depending on the available width. Possible presentations include:
Connection · ContainerlabelIf the database engine does not provide a distinct database or schema container, the entry may continue to display only the connection name.
Labels should remain stable. Opening another workspace with the same container name should not cause an existing label to change from
apptoProduction · app.The final presentation should account for long connection and container names, the narrow rail width, and the existing middle-truncation behavior.
Why connection comes first
The connection name is generally the safety-critical part of the workspace identity.
For example,
Production,Staging, andDevelopmentidentify environments, while each environment may contain a database with the same name, such asapp.Displaying the connection first:
For example:
This is easier to scan by connection than:
Acceptance criteria
Example scenario
Given these open workspaces:
The connections strip should display enough information to distinguish all four workspaces without requiring hover.
A valid presentation would be:
The two workspaces using the
appdatabase are distinguishable by their connection names, and the two workspaces belonging toProductionremain distinguishable by their container names.