What technical constraints could you foresee us encountering?
General feedback
Questions I asked during this video:
What would you expect the Epic board breadcrumbs to be?
How would you expect to access an Epic board? Where would they "live"?
Where would you expect to be able to add lists?
As it is currently?
Within the Create or Edit board experience?
Somewhere else?
Where you create a new board, what lists would you expect to see as default for Epic boards (currently it is todo and doing? If you wouldn't expect this type of experience at all- what would you expect?
What would you expect as default when creating an epic within an epic list?
How do you use the bulk adding experience (currently the Add issues button)? Do you?
Where would you expect to see board scope within the board itself?
Feedback
Leave feedback anywhere that works for you! This issue would probably be the most helpful as it is consolidated, but you can also leave feedback on Figma, the Loom video, or within an issues in this epic.
You can always chat with me! Schedule time on my calendar or on Calendly . If you don't see a time that works just reach out.
I'd love to hear any feedback from y'all here- especially around any constraints. This is something we have planned to work on after our Swimlanes iterations.
1
Alexis Ginsbergchanged the descriptionCompare with previous version
Thanks so much for leaving such thoughtful feedback @jprovaznik ! I really appreciate it! The feedback around discovery and breadcrumbs is especially helpful.
If I understand you correctly- it sounds like you'd expect Epic Boards to be fairly consistent to Issue Boards- at least for the first iteration.
I would think about Epics and Issues both living in the same "planning" area that you described
Maybe filters could be hidden and accessed by a full-screen dropdown (like Sisense) to improve space for boards... the filter component in general needs a bit of updating on things like (OR statements, quicker keyboard-only input)
The WIP-limit indicator column when fully red felt a little overwhelming - Maybe the saturation could be reduced slightly.
Consider having different "modes" to reduce UI clutter. For example, you could potentially hide the add list dropdown button when using boards normally, but reveal it when in "Edit" mode.
I've started using a popover with labels to provide quick access to labels whilst removing clutter... I don't know whether this is appropriate in this context, but thought I would share...
Maybe filters could be hidden and accessed by a full-screen dropdown (like Sisense)
So you are seeing an indicator of how many filters are applied, that will be displayed on click like:
I think that makes sense if I am understanding the Sisense reference! I was playing around with something similarish (very rough right now), so I am happy that you were envisioning something similar!
The WIP-limit indicator column when fully red felt a little overwhelming - Maybe the saturation could be reduced slightly.
Good feedback! I had similar feedback from users which is why the current implementation in boards is more.. pink. I think the idea of WIP is that breaking it is supposed to look overwhelming as it is something a user is urged to resolve- but I agree the super saturation is a bit much.
Consider having different "modes" to reduce UI clutter. For example, you could potentially hide the add list dropdown button when using boards normally, but reveal it when in "Edit" mode.
Love it! We have the full screen board mode that sort of mimics this but could be pushed every further. It actually doesn't hide a whole lot at the moment. I think the idea of an edit mode could be amazing in many experience in GitLab.
I've started using a popover with labels to provide quick access to labels whilst removing clutter... I don't know whether this is appropriate in this context, but thought I would share...
Ohh, this may be nice to test out in the Hide labels view on boards. If users aren't toggling labels back on, perhaps it could become default.
Great suggestion @annabeldunstone@espadav8 !! I waffled on this one a bit. Something about having only these options "preselected" by default during the creation flow of Boards felt a bit strange to me. This is a fairly common pattern though, even in our own settings- so I am not sure why I was uncomfortable!
If we went this direction we would just want to make sure we were clear with copy. Probably Show the Open list or Enable the Open list - then think through the next iteration of this experience which could be a bit more contextual or templatized perhaps.
This is a fairly common pattern though, even in our own settings- so I am not sure why I was uncomfortable!
I agree, pre-selected options can be weird if they're something more intrusive or important. But in this case it's just a view of something that already exists and is viewable elsewhere, so I don't think users should have an issue with that. Plus it's super easy to toggle them on/off at any time, right?
You can have epics from a subgroup on the board, can you also have epics from the parent group? This might create some interesting side-effects in that a direct member of the subgroup sees a different board from someone with inherited access, as they can't see parent group epics. (Well, they won't be able to when we fix #242247 (closed) :))
Just a comment that showing health status of the whole epic on the epic card on the board seems like a really powerful feature, and one that shouldn't be too hard to implement when the board itself is done.
You can have epics from a subgroup on the board, can you also have epics from the parent group?
Hmm good question @johnhope ! I would assume that no, I would only see the epics from the group/subgroup I am in/created the board in and below. This just due to the structure of these objects and the permissions like you pointed out. Do you think that makes sense? What do you think @kokeefe ?
Just a comment that showing health status of the whole epic on the epic card on the board seems like a really powerful feature, and one that shouldn't be too hard to implement when the board itself is done.
Awesome!! I am glad to hear that! At some point maybe we could even think of displaying the health of everything on the board as a roll up- if we validate that is useful though.
Just a comment that showing health status of the whole epic on the epic card on the board seems like a really powerful feature, and one that shouldn't be too hard to implement when the board itself is done.
Thanks so much for taking the time to leave amazing feedback in Loom @nadia_sotnikova !
For the options for creating a board I feel like it'd be nice to provide either a bit more context around the options (what they mean exactly?), OR maybe even better, I'd keep it very simple and not surface too many options at creation stage to reduce cognitive load, and instead make those actions more discoverable within the UI once the board has been created to make it easy to customize the board.
More context around the options such as Board scope, hiding lists, etc? Or just make it more discoverable that a user can do such things once their board has been created? That makes a lot of sense- and is something I can research with users!
One thing that is a bit of a struggle that I didn't touch on in this video- not scoping the board "properly" or in some cases (swimlanes for example) hiding those open/closed lists- can cause performance issues and cause the board to struggle in loading. I am sure there are ways we can better structure the experience though beyond a large creation flow, especially as we iterate. Let me know if you have any ideas!
My comments are probably out of scope for this specific effort, but thought I'd throw it out there. I think it's odd that the "Add list' button is at the top with all the other buttons (that area with many buttons feels quite overwhelming). Maybe it could be somehow positioned in the context of the lists? For example, a sticky floating button on the far right of the screen that adds a new list?
Great insight! Get out of my head! I starting thinking about this very roughly. It ties back to your last feedback of if workflows (lists) should be set up in a creation flow upfront vs contextual within the board itself.
The numbers that represent issues in the epic are difficult to understand just based on color. Plus, relying only on color to say "open issues" or "closed issues" etc. is unaccessible. Maybe icons could be used together with the numbers + color. I know there's not much space there, so I'm guessing that's why we opted for just numbers. :)
This is representing the health status of different issues in the epic. It def is a space issue across the board, but I agree that colorblind users for example- would have a hard time differentiating these. In the epic tree this is "okayish" because there is a legend of sorts. Within the epic cards though it really highlights the issue. We decided not to implement icons here for MVC of the epic tree work, but I still think that is a great idea and will start exploring it again, thank you!
Does the red highlight for the list need to be that visible? I think it could be a bit more subtle, like a red border or some type of more subtle red highlight that will be visible not not so intrusive.
Nick gave similar feedback- as well as users! I toned it down a bit when we implemented this for issue boards for that reason. This is supposed to be intrusive.. but I agree. I think keeping it the same as it is currently is fine for our first iteration.
Or just make it more discoverable that a user can do such things once their board has been created?
Yes, exactly! Basically, make it easy to very quickly create a board and customize all these options once the board is created. That way we progressively disclose the options, they only need to make one choice at a time. And to make such experience smooth we need to make sure the extra options are well discoverable in the UI. Perhaps an initial guided onboarding through the features of the board for first time users would help this as well.
It ties back to your last feedback of if workflows (lists) should be set up in a creation flow upfront vs contextual within the board itself.
I'm into the "let's get the user invested early and quickly" kinds of flows. So, making the first steps as simple as possible, reducing the steps to create your board, your list, your cards, etc. And then make it super intuitive to do all the extra fancy things with the objects you created.
Nick gave similar feedback- as well as users! I toned it down a bit when we implemented this for issue boards for that reason. This is supposed to be intrusive.. but I agree. I think keeping it the same as it is currently is fine for our first iteration.
Thanks for the comments in Loom @aregnery , you always leave such great feedback!
I assume when I am in a Group (GitLab.org), then I am only creating Epics for that group but I can create Issues for any project that is a child within that Group. Perhaps a sub group might make sense here instead of group.
Similar to how when I am in a Project (GitLab) all I can specify is Title and cannot specific another project.
So would you expect the default state to basically be Select a subgroup (optional) ? And if the user does not select a subgroup it defaults to the current group/subgroup that they are in? Or something else?
The projects reference is a bit tough since projects are children of group/subgroups but are usually... siblings? .. of each other meaning perhaps a user may have access to Project A but not Project B. This is why selecting another project doesn't always work unless (since the user is already in project A for example and can't zoom back up).
You're welcome! That's some high praise coming from you.
I wasn't understanding how the logic of this Group Dropdown would work
Let's say you are in the GitLab.org Group. What other groups would appear in the list? When I am looking at the Issues Board, I can only associate with the projects that are children of that group either directly or through a subgroup.
Perhaps its just the label of the field that I was misinterpreting. Is it supposed to representing Subgroup instead of Group?
Has there been any progress on this epic? Or any cards I can subscribe to? Really keen to see this implemented and would really like to test it out when it's available.
Thanks for your interest @espadav8 ! The team is working on epic swimlanes and backend updates to Boards to make swimlanes and epic boards possible first - then we are shifting priority to epic boards and adding in more swimlane types.