Currently, the pipeline graph is overloaded with unnecessary styling. This styling also prevents us from adding useful data and useful styling to the graph nodes (With this we can think of removing the job list and try to depend purely on the graph, this though can be done in a separate iteration as it would need some additional data to be represented). Additionally, this new design is able to support mobile viewports.
Scoped off from https://gitlab.com/gitlab-org/gitlab-ee/issues/2122 we need to solve the jarring experience when expanding upstream/downstream pipelines (EE) by making it possible to dictate the graphs horizontal position. This refactor is needed in order to be able to do that.
Dimitrie Hoekstrachanged title from Make pipeline graph visually more simple and add mobile support to Recursive expansion of upstream/downstream pipelines including automatic positioning + making pipeline graphs visually more simple and add mobile support
changed title from Make pipeline graph visually more simple and add mobile support to Recursive expansion of upstream/downstream pipelines including automatic positioning + making pipeline graphs visually more simple and add mobile support
Positioning of expanded/collapsed pipelines into view to create a less jarring/context switching experience
@filipa I think this might a bit more detail to be made clear. Let me know what you think! The functionality as intended can best be perceived in the prototype in the description.
@dimitrieh this is too much to do in one single issue. And both things are not related.
Can you please create a new one for the recursive expansion? We need smaller iterations.
Dimitrie Hoekstrachanged title from Recursive expansion of upstream/downstream pipelines including automatic positioning + making pipeline graphs visually more simple and add mobile support to automatic positioning + making pipeline graphs visually more simple and add mobile support
changed title from Recursive expansion of upstream/downstream pipelines including automatic positioning + making pipeline graphs visually more simple and add mobile support to automatic positioning + making pipeline graphs visually more simple and add mobile support
Dimitrie Hoekstrachanged title from automatic positioning + making pipeline graphs visually more simple and add mobile support to Updating pipeline graph looks including mobile support + support for automatic positioning to reduce context switching
changed title from automatic positioning + making pipeline graphs visually more simple and add mobile support to Updating pipeline graph looks including mobile support + support for automatic positioning to reduce context switching
@jlenny Was using the feature as of recent and do think we are falling short on ease of use currently. Would love to see this get in sooner rather than later.
A shift in 3 milestones later is quite the push back
A shift in 3 milestones later is quite the push back
The reality is that we lost almost 3 milestones to gitlab-ce2779335 issues, so this push back seems fair to me. I agree that ease of use is very much in need of help, but unless we get a lot more capacity, I don't see this ahead of other gitlab-ce2771176 items we want to get done in 11.x
I am going to add it to &295 (closed) that we should probably go through together @dimitrieh and prioritize the most impactful UX changes to make first.
@vkarnes@dimitrieh@mnichols1 this is one I'd love us to look at and finalize sooner than later. This is a key page for ~Verify that probably has a LOT of UX love needed...
@brendan. The current design provides an initial step towards better information hierarchy on the page without changing anything towards IA.
My suggestion here is to implement this as a first step and simultaneously work on a more holistic vision for what the pipeline page will potentially become. We'd need to see what current functionality is there, what is missing, and what will be added in the future.
I created &1194 (closed) to track this effort, plus this will be discussed in the verify UX/pm meeting
clarification: I don't see tooltips in the mockups/specs/prototype here (aside from "Play all") - should we make any changes to them?
No tooltips should be left unchanged (all necessary tooltips should already exist).
If any needs changing (perhaps a change of target element for example because of the refactor) we can fix them in the functional review. Let me know if that is alright!
@mfluharty If this is an 8, does that mean FE + BE = 8? I only see the FE label but if it's 8 we can def break this down a little more. What do you think?
I agree that this could/should be broken down, but all of the work here is still frontend. It's big enough that it should at least be split into desktop view and mobile view, and I believe that's why it got a weight of 8 in the first place. My approach at the time was to break one issue into many merge requests, but splitting on the issue side of things is probably a clearer and better strategy
Hi @mfluharty, I'm trying to catch up on the status of this issue. Is there an MR related to this somewhere? The comments make it seem that way, but I don't see it linked anywhere.
There is an MR, but it's been on the back burner: !15004 (closed)
Trying to do the overhaul in one MR is intimidating but it's hard to break down into merge-able pieces too. I meant to circle back, feature flag it, and get some changes merged but I haven't had the capacity.
On why this got so out of sync: the MR probably got disconnected from the issue since it was started so long ago that the issue was only linked to the CE MR that got auto-closed in the CE/EE merge, leaving the EE MR floating out there.
@thaoyeager This issue hasn't been active for a while, so I'm going to move this issue to the %Backlog for now. We should review priority and scoping as part of %13.1
Just a note that the CSS changes related to #276949 (closed) should help with this as well, in terms of reducing nested CSS as part of the layout adjustments.