Widget showing changed pages for Visual Reviews
Problem to solve
Review apps are great and visual reviews has added a quick and easy way to provide feedback directly in the MR.
For Parker and Presley this is great, but it takes them too long to navigate to the page that has been changed from the review app. Instead they are more likely to just ask Sasha to show them on their computer or send a screenshot to validate a change. This is less than ideal and leads to lower quality features shipping to customers.
Intended users
Further details
Use Cases
- When I (a Gitlab Product manager) am reviewing handbook changes from other PMs, I want to leave comments back on the MR but view the change as it would appear on the handbook. Instead of bouncing back and forth between tabs or devices doing that natively in the Review App / Visual Review tool would save me time.
- When a designer is reviewing multiple pages that have changed and need to validate the front end changes, I want to quickly navigate page by page and leave comments back on the MR.
Proposal
With https://gitlab.com/gitlab-org/gitlab-ce/issues/53390 we provided the ability for users to manually review the visual and application changes within a review app. As a follow up to that, we should port the "which pages have changed" widget from the Merge Request into the Visual Review function. This widget is already smart about what it knows about the MR and the changes, and thus that logic will be the same in the Visual Review function. This replicates that dropdown onto the Visual Review button.
STRETCH: include a tooltip or something about route maps so users of generated sites can more easily make use of this feature.
That way, I can quickly navigate to only / all of the parts of the application that have changed.
Permissions and Security
No changes to permissions from the existing Visual Reviews.
Documentation
The existing documentation should be updated to reflect how route maps need to be in place to utilize this feature for sites like gitlab.
Testing
Ideas
- Let's see how a very large change set looks
- Should work cross browser
- Ideally we test mobile views
Test Areas
- Unit
- New unit testing required
- Integration
- New integration testing required
- End-to-end
- No end-to-end testing required
- package-and-qa not required
What does success look like, and how can we measure that?
- We will know this feature was successful by seeing additional usage of the visual review tool after launch.
- The users will be successful when they are closing MRs faster because Designers and Product Managers are finishing User Acceptance Testing sooner.
What is the type of buyer?
The buyer for this is the manager of the team who is already utilizing Visual Reviews.