Improve inline blame viewer UX
Summary
Some concerns were identified in the inline blame viewer, particularly around performance, and user experience. Some users still prefer the old blame viewer, and there are issues with data loading, particularly for large files, that affect trust and usability.
- Lack of Loading Indicator: When users click to view the blame information, there is no clear indication that the data is being loaded. A loading indicator is needed to improve the user experience during data retrieval.
- Trust Issues with Data Loading: later lines may render before earlier lines are fetched, leading to confusion about whether all the data has been correctly loaded. This causes users to wait extra time (5-10 seconds) to ensure completeness. Perhaps we can add a loading indicator above the loaded lines to indicate that the lines before it is still being loaded. Alternatively, do not render later lines if earlier lines are still being loaded.
-
Page Jumping Issue (layout shift):~~ The inline blame viewer causes the page to "jump" as new blame data is rendered. For example, if a user scrolls to line 500, and new blame information is loaded for lines 400-500, the UI expands, and the user is pushed back to line 470, disrupting the flow and user experience.~~ Will be handled in #441970 (closed)
Potential solution for Page Jumping Issue (layout shift)
The layout between the source code viewer and the blame view differs. More space is required between lines when displaying blame information, and since we’re loading blame information asynchronously in chunks as the user scrolls it will cause the page to jump around when data from the backend is retrieved and rendered in the source code viewer. This is especially noticeable when viewing large blame files because the endpoint is quite slow.Solution 1: Improve the performance of the endpoint (backend)
Improving the performance of the endpoint would be the ideal solution if we want to keep the UX consistent with the full blame page because that would allow us to query all the blame data and adjust the frontend layout upfront. We have an issue for improving the blame API, but from what I understand it is inherently slow.
Solution 2: Try to preserve Scroll Position Manually (frontend)
- Calculate the height difference that new data will introduce and adjust the scroll position after the new data is rendered to ensure the user’s view stays in the same position relative to the content they were looking at.
- Alternatively, track the top-most visible line number and then scrolling back to its position after new data is loaded/rendered.
Solution 3: Change the UX (UX)
Perhaps we can come up with a way to display blame information without having to change the layout of the source code viewer, or without having to dynamically query and render as the user scrolls.
Design recommendation
See #500037 (comment 2617910508)
1. Add a button loading stage for when the Blame button is clicked
2. Add a skeleton loader for the chunks loading.
See #500037 (comment 2617910508). Examples of skeleton loaders:
| Repository loading | Issues loading |
|---|---|
 |
 |