In the roadmap view, you can currently view epics.
But to view the details of epics in an epic (sub-epics), you have to click through.
As a User of Roadmaps,
I need to be able to see the sub-epics under an Epic,
So I can get a detailed, view of the work involved over a timeline
Proposal
Child epics are now nested under parent epics in the left column. There is also an indication of how many child epics are tied to a parent epic as a count next to the epic icon in the parent epic's row. Parent epics are solid colored while child epics inherit the parent epic's color but have an outlined styling. A user can collapse a parent epic row and the child epics will be hidden from view.
- In the mockup below, you can just mouse over (or click) on an epic in a roadmap, and view the associated sub-epics.
- The sub-epics also show their respective start and end dates based on their assigned milestones.
- Further designs required for all the cases. (Milestone doesn't have start/end dates).
- Related to #7076 (closed) and #6802 (closed) and should be designed together.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
We could do something similar to issue boards, where we have a sidebar that slides from the right when you click on a roadmap. It could list start/end dates, sub issues, tree, etc. Because there's not much horizontal space, we would probably only go one level deep on the descendants.
If we do the slide-in, then we lose the timeline right? I think the compelling part of this (that sets it apart from the design you have already on an epic page, is the timeline aspect right?)
If we wanted to go with a popup like in your mockup, I think we'd have to limit the descendants again to just 1 or 2 levels deep. Since issues/epics are draggable (and space in the popup is limited), it would list 4 or 5 issues and then say +8 more or something.
The mockup in the description wasn't supposed to denote a mockup. (Have to improve my wire-framing skills.)
It's supposed to be like an in-place expand.
In particular, one of the scenarios which I think would be super compelling is that you are viewing an epic with say, 3 or 4 levels down of descendent epics/issues. In my mockup you see the gitlab.org&12 epic and you see it's start and end date. And then you click on it, and it expands to 4 children epics. And you see their respective start and end dates there. So that would be super useful for me. I know right away the decomposition and their respective dates. And this would work perfectly if the user is using inheriting dates for children epics, i.e. &318.
So I think this case is well-defined and works really well for the timeline because everything is self-contained. The problem is when you have a parent epic, and the child epics have dates that are outside the dates of the parent epics. How would that be visualized?
@victorwu here are a couple of initial concept of what we could do
A
B
User clicks on an epic, the row expands to show all descendant epics/issues (so far only immediate descendants; haven't thought that through yet)
Epic name column displays total counts of all descendants. If that's not particularly useful, we could list every issue/sub-epic name there instead.
I added a different color to differentiate between epics and issues. I think the separate colors is a good idea to help get an a quick visual overview of all epics/issues, but it doesn't need to be purple
If there is no milestone assigned to an issue, or the milestone doesn't have a start/end date we could just omit it from the roadmap, or have the issue take up the exact same amount of space as the parent epic
I'm thinking of the use case of where you would want multiple epics expanded. Say you have three epics that are parents of really tall trees. And you wanted to visualize all three and their decedents all at once. So that you can have a really high-level executive view of everything, but still be able to drill-down visually immediately.
So from that perspective, I think expanding is great, but without the shadowing. (So your left mockup). That way we can expand multiple epics at the same time if we wanted to.
Another thing to consider is how the descendent would work. Suppose you have epics A, B, C all in the same group. But they are related such that A -> B -> C in terms of parent-child relationships. So I think in default mode, all three epics would show up on the roadmap. But the moment you expand A, you would also see B as it's child, and then you expand further, and you'd see C. So in the same screen, multiple epics would be repeated. I don't think that would be weird. But just wanted to make sure you thought of that already and you also intentionally don't think it's weird. Alternatively, you don't show B and C at all when the roadmap view is loaded. But I think that's a bad design.
Yet in another case, again we have A -> B -> C, but B and C belongs to another group. I'm not sure if we want to allow this or not. But in this case, B and C would not appear on the roadmap view when first loaded, but it would appear if you expanded?
I propose this design that would be general enough to solve both problems:
When an epic doesn't have any date edges, never show a bar on the timeline part of the roadmap. Because any time you show a bar on the timeline part of the roadmap, immediately it implies it has some time boundaries, which it doesn't.
You can still show the epic on the roadmap though. Just put the epic name right in the first column, where all the epic names are, but leave the bar area just blank.
So in your mockup, we could just have clickable epic names in precisely the white-space to the lower-left of the expanded area you have. We could just list them there.
You might have already thought of this, with:
we could list every issue/sub-epic name there instead.
@annabeldunstone : Regarding issues, issues also have milestones/dates, everything we design could apply to issues too. But I think in your mockup you have at least collapsed them by default. I think that definitely makes sense. Not sure if it's a good idea to allow people to expand issues as well, because then if an epic say has 10 issues, it would very quickly take up a lot of vertical space. But then again, that's exactly what a lot of roadmapping/Gantt tools allow.
So in the same screen, multiple epics would be repeated. I don't think that would be weird. But just wanted to make sure you thought of that already and you also intentionally don't think it's weird.
I hadn't thought of that. I don't know... something is weird about that. For now, let's go with showing all epics on the default view and duplicated when an epic is expanded, like you suggested. We'll come up with something better later.
Yet in another case, again we have A -> B -> C, but B and C belongs to another group. I'm not sure if we want to allow this or not. But in this case, B and C would not appear on the roadmap view when first loaded, but it would appear if you expanded?
We can't add issues from Group A into an epic in Group B, so we shouldn't have epic relationships spanning groups either. Unless I'm missing something here- is that intended functionality?
Essentially how do you display an epic on the roadmap if it doesn't have any date edges?
Yep, that's what I was thinking with listing the epic names in the space to the left. If we're going to list an epic that doesn't start/end dates and therefore no blue bar, it needs to be really obvious that the epic does exist, and it's not a bug that it's not showing up. Maybe we could do a light gray bar with no start/end to show it exists.
(Pretend the issue/epic names in the left column line up with the bars)
@annabeldunstone : My proposal is just to have nothing in the timeline area. I didn't consider that that could be mis-interpreted as a bug. Despite that, I still prefer it being blank. I think we can move this discussion to https://gitlab.com/gitlab-org/gitlab-ee/issues/7735 where we address it for all general cases.
Not sure if it's a good idea to allow people to expand issues as well, because then if an epic say has 10 issues, it would very quickly take up a lot of vertical space.
Do you mean expand an issue to see all sub-issues? At the moment I'm thinking we would only go one level deep here. So when you see the default view, you can click on an epic and see all of its direct children, but you can't go further. Do you think we need to?
Yes I think step by step expanding (like just seeing direct children) makes sense. And you have to keep clicking to see additional descendents. This will be consistent with your designs in https://gitlab.com/gitlab-org/gitlab-ee/issues/7327.
After looking at this some more, I'm not sure I like having duplicate epics shown. I think it would be confusing and seem buggy. What if we just always showed all epics? No expanding epics, just show them in their correct location, nested under the top-level epic.
For issues, maybe a toggle/dropdown at the top to choose whether or not you want to see all issues & sub-issues as well.
@annabeldunstone : how do you think filtering should work? If you filter on a label, does it filter on the top level objects only? Or the whole tree or objects?
The complexity I see is that some children of an epic could be in the same group as the parent, whereas others could be in children groups. And should we treat them differently in any way.
I think this gets complicated fast. Sorry I don’t have good feedback for you yet.
We have nesting of objects. (Child epics and child issues in the future). Those objects are themselves in groups and projects which form a parallel nesting relationship. You have attributes labels and milestones which live in those groups and labels. And there’s list views at groups and projects and there’s this relatively new roadmap view. All these need to be intentionally designed.
@victorwu I think it should filter the whole tree.
The complexity I see is that some children of an epic could be in the same group as the parent, whereas others could be in children groups. And should we treat them differently in any way
I don't think the parent-child relationship is as vital to see in this view. In the mockup you've got the top level epic with every single descendant, which serves as a way to broadly group the epics. Do you really need to see exactly how every epic is related? The epic detail page should be serving that purpose.
What is the purpose of the roadmap view? I thought it was used to get a broad overview of what's currently being worked on and what's coming up on the horizon. Showing all epics at once will give you that idea much more quickly than collapsing and expanding over and over. It would get really frustrating to have to click multiple times to see a deeply nested epic. Plus the already mentioned confusion over having an epic listed twice.
@annabeldunstone : The roadmap view is also to quickly get a drilldown. As a senior director sitting with the CEO, I see a top-level epic (a strategic initiative) that I am ultimately responsible go from Jan 1 to April 13. The CEO says that April 13 is too far away. The CEO wants it to be done by March 14. The CEO asks if they cut anything. So the senior director expands on the top-level epic, drilling down multiple levels to see which epics are contributing to the end date that stretches out to April 13th. They can see which epics are the limiting ones since they can see it on the roadmap view together with the top-level epic.
All that to say having everything expanded by default could be a good first iteration. The only concern I have is that would mean if you wanted to see a lot of top-level epics at once, you couldn't, and you'd have to vertically scroll a lot. So having the ability to expand all desecendents and collapse all desecendents at any epic/issue I think would be a good second iteration.
I have three top-level epics all labeled ~Plan . But all those top-level epics have downward trees full of epics that are not labeled ~Plan . So if I filter on ~Plan in the roadmap view, does that mean I only see the three top-level epics and not the children? As a user, I don't think I should be required to label every single epic in the tree just to use the roadmap view. So this is where I'm concerned the complexity could get bad very quickly.
@victorwu Yeah that could be tricky. It seems a bit like a problem with labels themselves though. Shouldn't all children of an epic inherit the parent's labels?
It should be possible, we'd need to do two things in that case;
Move GraphQL call that Tree tab does on load to a level above, where the page itself would make that call on load.
Ensure that query includes fields required for Roadmap (startDate & endDate), this is where backend would need to ensure that those fields are exposed in GraphQL.
Reuse the data received in above call for both Tree and Roadmap tab so we only have to render apps on Tab click.
Ensure that query includes fields required for Roadmap (startDate & endDate), this is where backend would need to ensure that those fields are exposed in GraphQL.
@annabeldunstone just wanted to bring your attention to this. Haven't talked about it in awhile but we have it slotted in for %12.1. Do you think we'll be able to get it to ~"UX ready" by then?
Ah, thanks for the ping @donaldcook. Since I'm still working on the beautifying-ui epic, I don't see this being in a ready-state for 12.1. I'll definitely be able to work on the UX in the next milestone so I think we should probably move this to 12.2
Unfortunately, Matt is no longer with SFP. Please send any work related requests to Robert Theodorow at rob@sfp.net and we will be sure to handle the request in a timely manner. Thank you.
Unfortunately, Matt is no longer with SFP. Please send any work related requests to Robert Theodorow at rob@sfp.net and we will be sure to handle the request in a timely manner. Thank you.
@annabeldunstone@uhlexsis thanks for pushing back. I'd love to ensure this gets UX cycles so we are ready to deliver in 12.3. What is the best way to record the fact that it should be looked at this month in UX?
Hey @ebrinkman I believe that applying UX is the best way so that the assigned UXer can work on getting the issue UX Ready by the intended implementation milestone. I believe Annabel has done some work here, so I will leave her assigned for now. There is also UX Research attached to this, so I can get a research issue started there to ramp this up.
@annabeldunstone I'd love to explore whether or not we can create a common primitive between this and the epic "tree view" + roadmap on an epic (&644 (comment 199001349)).
Do we have any UX Research / customer interviews notes on this feature anywhere?
As for roadmaps, I wasn't involved in the original work, so I'll check to see if we have any research. In any case, I'd like to go over all of our open roadmap issues to re-prioritize and drill down into exactly we want the roadmaps feature to be.
@donaldcook This is pretty critical imo, I'd like to keep in 12.4 if possible. If after validation the effort would span passed that, we can move it or find ways to limit an MVC.
@kokeefe The current issue title is Expand epics in roadmap to view hierarchy
Is that exact proposal something you view as critical? Or should we re-frame this issue, given the other ideas proposed. For example, do you need to see a hierarchy or should we just show all epics all the time? Should we look into answering other questions first- for example, should child epics inherit labels from parents? Also, some concerns have been brought up about duplicate epics if we go with this expand option.
@annabeldunstone I'm reviewing this again. Im gonna get some thoughts on paper on this and where I think we need to go and grab some time to chat. Thanks!
This was Milestone %12.5 and is now backlog -- is this because we are covering the functionality in other issues? If so, can we link to those so it is clear where this work is being done? If not, I don't think we can push this out indefinitely and I'd prefer to see a specific milestone set rather than %Backlog
Hey @kchasse, new PM for Plan here!
I am actively working on mapping out how we can accomplish this and lock in a cohesive design that isn't to complex or cluttered. There is a large list of related items attached to this above, but the primary items atm are:
As we look at providing roadmaps for multiple levels/views (Portfolio, Group, Sub-Group, Project) we need to holistically design and map out the best way to support it. The issues that have passed workflowsolution validation are being scheduled and pushed though in 12.4, as we work on solidifying direction for the others.
This issue in particular can get crowded as you need to reflect multiple hierarchy levels, but we are moving it forward. I think %Backlog wasn't the best reflection of current state, so apologies there. I'll move it to %"Next 3-4 releases" until @uhlexsis and I finalize workflowsolution validation.