Make debugging pipeline job log easier with calls to action
Background
This issue relates to the UX scorecard recommendations issue.
This problem relates to the FY22-Q3 KR to improve learnability as discussed in the FY22-Q1 UX Research interviews.
Problem
Note: this problem needs more exploration, such as problem validation to define it more concretely. This issue is meant to be a starting point of a discussion.
A new user investigating a failed pipeline needs to read and understand the complex job log or job failure to understand how to fix the problem. Comprehension of the job log requires prior knowledge of the source code, dependencies, and technical set up of the project.
**Problem: in the context of this UX scorecard:**
When I'm debugging a failed job by investigating a package dependency in the package registry, it's hard for me to understand that a package was the reason for the pipeline failure.
Example: in the screenshot below the user needs to understand that the failure happens when the app is run via node app.js. Requires prior knowledge of npm, packages, that the packages are pulled from a GitLab registry. The user will need to know which lines to pay attention to and which lines to ignore
Example: in the screenshot below there is not enough information for me to debug the failure
Heuristic evaluated against
| Heuristic | Description | Heuristic not met because: |
|---|---|---|
| Features/workflows have clear calls to action. | A call to action should make it clear what is to be done to move the task forward. At the very least, there should be links to documentation for assistance. At best, guided setup. | * There is no clear call to action * There is no link to documentation |
| Tasks are easy to learn, or if highly complex, have setup support in the form of in-app guidance, defaults, templates or wizards. | Tasks should be intuitive first and foremost, and when they are complex, they must provide tools to enable learning. | * Task is not intuitive * Task does not provide tools to enable learning |
Relevant links
Assumptions
- It's not technically possible or not pragmatic to create calls to action out of a job log, otherwise it would already be done
- This problem is currently not being worked on
- Debugging a pipeline failure would be challenging to a novice user or inexperienced software engineer
Questions
- Is this actually problem?
- Do learnability heuristics apply here? Or is this a typical software engineer process that does not need a UI layer on top of it? (such as using git through the command line)
- What information or calls to action would be possible to surface?
- If it were possible to surface information or calls to action in a more "friendly" format, would that change be a hindrance for users of the current flow?
Potential improvements
Note: these improvements are kept vague as the problem is not well defined and would need more exploration
- Create calls to action from the job log, for example, link to an area in GitLab where the user should look to debug
- When user navigates via call to action to another part of GitLab, the pipeline failure is referenced or displayed in the UI. (Following guidance in usability heuristic: Recognize, diagnose, recover from errors