Update breadcrumbs on "Edit Release" page to include links to main and dedicated Release pages
Problem to solve
As a user, when I'm editing a Release entry, I want to be able to easily navigate back to the release overview or detail pages.
Intended users
User experience goal
The user should be able to use the breadcrumb component to trace the path back to their original landing point when editing a Release item.
Proposal
Update the breadcrumbs to include an entry for the project's main Releases page (/-/releases
) and the Release's dedicated page (/-/releases/<release name here>
).
Example:
Nathan Friend > My Project > Releases > Version 16.5 > Edit
Further details
When editing a Release, there is no way to get back to the Release's dedicated page (/-/releases/<tag name here>
) or the main Releases page (/-/releases
) using the page's breadcrumbs. The only previous entries in the breadcrumb are the project and the project's owner:
The user can click the cancel
button in the form, but that is not entirely intuitive.
Interestingly, the current behavior is consistent with other pages in our product (i.e. merge requests). I think it would make sense to update these pages with the new pattern I'm proposing above as well (in separate MRs).
It may also make sense to update these to use the GlBreadcrumb
component from @gitlab/ui
while we're at it. (As shown in the Pajamas documentation on breadcrumbs: https://design.gitlab.com/components/breadcrumb.)
Permissions and Security
-
Add expected impact to members with no access (0) -
Add expected impact to Guest (10) members -
Add expected impact to Reporter (20) members -
Add expected impact to Developer (30) members -
Add expected impact to Maintainer (40) members -
Add expected impact to Owner (50) members
Documentation
Documentation updates are not required. We could potentially update the releases documentation page, but this change does not add a new feature to the capability, but breadcrumbs are a native navigation pattern used across GitLab.
Availability & Testing
- Unit test changes
- Integration test changes
- End-to-end test change
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
No.
Links / references
UX DoD
Click this to collapse/fold the UX DoD 🔽
Entry Criteria for Design
-
Problem has been validated -
Has UX effort accounted for in long term cycle, we know unknowns
Criteria for UX DoD
-
UX label is added to the issue -
User stories and acceptance criteria have been created -
Edge cases were considered
-
-
Cross-team dependencies have been identified, if applicable -
Prototype or mock for each user story have been created -
Empty states -
Responsiveness
-
-
If changes involve copy, UI text label has been added -
Pajamas: UI Component design have been identified -
Pajamas issue is created (new workflow)
-
-
Marked as Ready for engineering evaluation per user story moved into workflowplanning breakdown & needs weight
Entry Criteria for Ready for Development
-
Scope has been defined and reviewed with engineering -
User stories have been weighed and are less than 5 MRs -
Create new issues for follow up user stories
in addition to defined process)
Criteria for Engineering DOD (-
UX review for MRs that include user experience changes - mandatory for frontend that has impact to UI/UX -
Update SSOT in issues: -
Update prototypes of deliverables -
Add link to documentation
-
-
Create new issues for follow up and open scope