Add existing issues to issue board

changed title from Add issues to issue board to Add existing issues to issue board

changed milestone to %Backlog

added ~874211 label

added ~579196 label

I took Chris' design of the modal and put up the issue here. Can you please take a look and see if it makes sense? I would like to ship something for 8.17, and this seems like a pretty safe one that's small enough and at the same time a significant step in the right direction that Chris has established. If you folks like it, I'll let Chris clean up the designs and fill in the details and then we can go from there with engineering.

mentioned in issue #23917 (closed)

added ~19492 label

@victorwu This is a nice step forward. There are a few points that I want to think about a little more, but for now I have a question about the Backlog list. What if we kept it as an optional list? In practice it would be very similar to offering a default "To Do" or "Pending" regular list, but I wonder if there is any benefit in allowing users to have issues on the board without an assigned stage.

You could turn it on and off from a "Manage board" dropdown that would go where the "Add list" button is now.

@cperessini : What's the benefit of showing the Backlog list if you can access the same issues in the modal? I guess if the Backlog turns out to be a small set of issues, then it would be helpful? Is that what you're thinking about?

Then I would be concerned that you would have two ways of "adding" issues. Dragging from the Backlog list, and also the modal. How could we harmonize these better so as not to be confusing?

@victorwu Yeah, the idea is that the Backlog remains empty until you manually add some issues. It would behave the same way as other lists after we push this update.

I just wanted to offer the possibility to keep the Backlog list if we found it added any value. For example, if we end up showing an issue's stage in the issuable sidebar, you might want to keep an issue stage-less but still have it show up on a board.

Maybe that sounds forced, I just wanted to see if it made sense.

I kind of feel like something like To do or Not started captures better what you are saying. It is a stage, but a stage that doesn't imply that work has been completed yet?

@cperessini + @awhildy : I wanted to clarify what your proposed design is for the Backlog list. (We can change the naming to whatever we want. That's obviously not a problem.)

In the existing implementation, the Backlog is a special list that just contains all issues that don't have a label/list from the board itself. Are you proposing we change this design in the first place?

I was thinking 'yes'. If we truly go down the stages model, backlog is no different then a 'To do' stage. So why does the list need to have any special properties or be unique? It could just be the first list which is the first stage. All issues added to the board would automatically be added to the first list. Does that make sense?

@awhildy : Yes that makes a lot of sense and in this scenario, and so we wouldn't need what @cperessini described earlier with the dropdown option of showing / hiding the "Backlog" list, since there's no such list at all.

The first list of the board would be whatever the user sets it up to be. (And of course the first list could be changed at any time.) Furthermore, we are already offering to create two new lists for the user for a new board currently. So in this scenario, the first list would be "To Do" if the user chooses what we provide them as the starters.

So I wanted to clarify that if we go with this design, we are purposely taking away existing functionality, namely that we no longer show any special list that displays issues without a stage/list. And to compensate, users only see that pool of stage-less issues when they select them in the new modal.

Basically as specified in the description. Feel free to update if you disagree.

Here are a few designs to illustrate the current state of this feature.

Default state

The default state of an issue board is empty, with no issues automatically added

Adding issues

In the top right corner there is a button to add issues to the board

I'm thinking users may not understand they need to add issues manually, so we could highlight this button, maybe with an illustration in the style of our empty states.

The modal

After clicking the button, a modal pops up with a list of all the issues in the project. The elements in the modal are:

Tab bar separating "All issues" and "Selected issues". This will help you confirm you made the right selection.
Filters. The issue list can be filtered, either with the new filters if we can implement it here or the current version.
"Select all" button. If you have filtered down the issue list, clicking the button only selects the issues that match your filters.
Issue list. The issues are supposed to be read from left to right. We may need to do some testing or gather some feedback to see if this layout makes finding issues difficult.
"Add issues" and "Cancel" buttons

Selecting issues

Selected issues are marked by a blue background and a checkmark.

Issues were added

Issues are added to the leftmost list

Thanks @cperessini. I like the general flow of the buttons and the modal.

For the button placement, they look weird to me, since the Select all, Add 3 issues, and Cancel buttons are in three opposite corners of the modal. But is that intended? It looks like it matches the other web forms in GitLab. Any intentional design on where they are located?
I understand that showing all the issues in multiple columns is helpful to see more issues at one glance. But I'm worried it may cause some confusion and difficulty. What do you think?

2a. Do you just scroll down and see more issues? How would the issue placement in the modal behave in that scenario?

2b. The FE implementation may be difficult. And do you have 3 columns for certain screen sizes? 5 for larger, and 2 for smaller? That adds to the FE complexity.

2c. If you have multiple columns in the modal, I'm afraid it may confuse the user because they also see multiple columns in the regular view. So would they get confused that columns in one view may be associated with columns in another view?

2d. The Selected issues tab seems helpful. Though I'm not confident that it's totally necessary for an MVP here. Similarly the search probably we don't need in a first iteration.

2e. The most obvious design is just a vertical list of features, and you just scroll through them and select them. Would that be horrible? That seems painful as well, but I'm worried a multi-column design adds more problems than it solves.

@victorwu, the multiple column layout shows "so many" issues, making it pie easy to fast slide around and select what you want even with a lot of them. Don't you think it would be impracticable to scroll over a few hundred vertical issues?

@victorwu:

I was following our convention in button placement. In my original mockup the Add button wasn't in a very good position, since it was placed before the actual issues you're going to be adding. That's why I wanted to put the Add issues and Cancel buttons at the bottom of the modal. Add is on the left and Cancel is on the right because of our convention, but that might be changing with #26248 (moved). Finally, Select all is an action that affects the content of the issue list, so I placed it in line with the filters, which also affect the list. Do you think it would make more sense to you if Select all were aligned with Add issues on the right hand side?
I'm worried about it being confusing / hard to read too. When I talked with @awhildy we decided to go ahead with the design and gather some feedback once we put it out there. It could also be beneficial to conduct some testing with a basic prototype and see how hard it is to use.

2a. Issues flow from left to right and then from top to bottom, filling up whatever space is available. Take this Tumblr archive as an example

2b. We should establish a limit for the number of columns. I think anything above 3 or 4 will make it quite difficult to find anything. If you make your window narrower it'll go down to 2 and then to 1.

2c. Good point on this one. May I suggest testing again?

2d. Agree they're not MVP, but I'd definitely include them as stretch goals for the first iteration

2e. Yep, we also talked about that with @awhildy. We could just make this similar to the traditional issue list. We may have to go for that option if we find the multiple columns are as problematic as we fear they may be. There may be some intermediate solution, like showing two rows and making each card fixed in height, we can explore something like that too.

@victorwu Oh, and as @GCSBOSS mentioned, if we made this modal just a single vertical list, isn't that as impractical as the current Backlog list? We could probably fit more cards in vertically, but it wouldn't be that different really.

added frontend label

Thanks @cperessini . I'm backed up this week with non-work stuff. But will able to participate more next week. Let's finalize some of these awesome designs for next steps to implement. I'll comment more then. There's more than enough here to get started.

The reason I'm leaning toward just one vertical list in the modal is that it's likely the easiest to build. And furthermore, do we have a testing framework set up to validate / invalidate certain designs? If not, would it not be safer to implement the easiest version and then build from there? I agree the experience is not that great. But from a scalability perspective, you don't actually gain much more if you spread over 3 or 4 columns. Instead of scrolling through 99 issues, with three columns, you scroll through 33 x 3 issues essentially. You are only getting linear gains. But with a small number of issues (i.e. say 30), the difference would definitely be great and thus, beneficial. Let's leave this as an open question and get FE input. @jschatz1 : Could we get some FE input here?

In terms of testing, do you mean we have resources / capacity / some execution plan for doing non-code low-fidelity prototype testing before we implement this design? If that is the case, @awhildy , can you comment on how we can do that here, can the UX team pull off something quickly so that it can feed into whatever we scope in for 8.17 as a target? I don't doubt that this is a valid UX design for displaying content horizontally, with the Tumblr example, and a common design paradigm for parsing rich content with a mix of media and text (Pinterest, blog/magazine sites, etc.) But it would be great to validate that it makes sense in the context of GitLab, where it might be different.

@cperessini : Let's chat about the better design in parallel, but shoot for the simplest design for this iteration. We can expand on better designs if we have a good baseline. Could you create a mockups for:

Clicking the Add issues button based on our existing menu bar.
The Add issues modal with just a single vertical list, where you have your select mechanism. But without the filtering and select tab.

So similar to:

@victorwu Let me know what you think about this design:

Restored the Add list button

Only one column of issues is shown. I made the pop-up wider than a normal list so we can show one or two extra issues.

Selected issues

I think the buttons in the footer would make more sense if they were inverted, but we should wait for #26248 (moved) to do that

Thanks @cperessini . I updated the issue description with these designs. They look great!

Only comment is the Add all button. I know you originally designed Select all and I like that design and it solves a potential use case. (But not necessarily clear people will need it just yet!) And that should be a subsequent issue (but out of scope for this issue).

So is it even worth it to have an Add all button for this issue? I'm worried that it might even be dangerous because if a person clicks on it by mistake, then they have a whole bunch of issues on their board now. So wouldn't it be better to simplify and leave that out for now?

All issues added to the board would automatically be added to the first list.

In agility the backlog is the list of ordered tasks, it doesn't correspond to the tasks to do. Moreover it is not intuitive that the addition of an issue to a board causes the addition of a label to it. I think that a backlog list to the unplanned issue makes sense.

I add that imo the list of all issues is not synonymous with backlog.

@cperessini:

@JobV brought up the very good point that with this MVP modal design, we lose the ability to quickly search for issues when "adding" them to our board. With the existing implementation, a person can use the search/filters to quickly limit the issues in the Backlog column, and then drag them into the first column easily. We lose that ability now with this modal design.

Obviously your original modal design already considers this with searching and filtering. So I'm thinking of two possibilities:

Expand the scope of this issue so that we put the search/filter features back into the modal.
A different design. @JobV came up with what I think is pretty clever. Instead of popping up a modal, just slide in a list of all issues when you click Add issues. And that slide-in list would be subject to the same filtering/searching as usual already on the page.

I still think that long-term, a modal is the right design, because it re-inforces that this is part of board set up. And so list management should occur in the modal. And adding issues may or may not happen in the modal. If we go with 1. above, then we are committing to including adding issues from the modal.

@cperessini: Any thoughts? We don't have to finalize the details. When we schedule it, let's get engineering to also chime in on feasibility and what would be a good small iteration.

Thanks @victorwu. To clarify, my idea was to just rename the backlog list we have now and make it invisible by default. When clicking 'add issues' it just slides in from the left.

I'm not sure I understand. For me by default the board doesn't contain any issue even if issues have a label that matches a list. When an issue is added to the board, the issue appears in the corresponding lists. This is what I understood at the beginning, but I get the impression that this feature only concerns a redesign of the backlog column.

This is unclear for me :

When you hit add, the modal clears and the issues are added to the board.

mentioned in issue #26259 (closed)

added Deliverable label

changed milestone to %8.17

@cperessini + @iamphill : Update the description with brief points per our discussion today. Let's add more details to the description when Chris has updated mocks and Phil starts digging into it to hash out the details / edge cases.

removed to schedule label

mentioned in issue #27093 (closed)

@victorwu are you moving forward with the slide-in backlog replacement as I proposed?

@JobV : No, we are going with the modal, but with the full search / filter capability, similar to the what @cperessini has here: https://gitlab.com/gitlab-org/gitlab-ce/issues/26205#note_20826521. So you can still search for issues quickly when "adding" to the board. UX+engineering+product chatted earlier today. Updated mockups pending.

mentioned in commit 5505a3b5

mentioned in merge request !8737 (merged)

@victorwu sounds good. What is the motivation behind the choice of presenting a modal?

Looking forward to see the mockups.

mentioned in issue #27154 (closed)

@JobV : With the modal you get:

You don't have the persistent Backlog column in the UI. (This advantage being the same as your design.)
You have much more room in a modal to browse and search through issues instead of a single column in the existing Backlog. Our use cases are that you want to add maybe on the order of at most 50 ~ 70 issues per issue board. So this is manageable to be searched / browsed in a larger modal where you can see more issues.
You have a dedicated search bar for finding issues. Right now we also have a search bar in the main view. But this clearly differentiates it from main view usage versus adding issues usage.
It presents to the user explicitly that we are modifying the issue board by adding issues. Adding issues is something you do at the beginning of a milestone. And this action is a rare occurrence during the milestone. So it makes sense that the UI is separate form the main view.
This modal design lets us expand on further list management features in the future. Where you can configure more powerful lists with multiple labels per label. It might not be in the same modal. But we would leverage a modal design nonetheless. So this emphasizes board management + adding issues to a board is separate from during-the-milestone/iteration usage, namely moving issues through the stages.

@cperessini : Please add any additional thoughts.

Thanks for the elaboration @victorwu. Sounds good to me.

@victorwu @iamphill @awhildy here are the latest mockups. Let me know what you think:

All issues

At the bottom of the modal there is a dropdown to choose the destination list

All issues - selection

Just as before, selected issues are highlighted with a blue background and a checkmark

Selected issues

This tab only shows the selected issues. Deselecting one should turn it white and remove the checkmark, as well as decrease the count in the badge and the Add issues button, but there's no need to remove the card until the user switches tabs.

Empty state - no issues in the project

If there are no issues in the project, we can show an empty state similar to the one @hazelyang designed for the Issue Tracker. Alternatively, we can disable the Add issues button in the board (the one you use to enter the modal).

Empty state - selected tab

For this case it is important to have an empty state, although a MVP probably doesn't need anything this fancy. Just a line telling the user to go back to the All issues tab.

@cperessini looks great

As a first iteration we might have to just have a search bar instead of the full filters. But i'll see what I can do!

@victorwu What do you think about adding a button to the sidebar for removing issues from the board? It's out of the way for normal use and it shows up when you're focusing on an issue. If we add multi-select in the future, it would also work well there.

@iamphill Makes sense! Do you need a mockup for that version?

@iamphill + @cperessini : I think we need to put all the drop down filters in for this to be released, since we agreed that it would be a regression from the existing functionality of using the drop down filters to narrow down the issues in the Backlog column. Since 8.17 is really short now, no problem if we can't make it. We can make this a big splash in 9.0 if that works. Hopefully we would be able to do the milestone persist issue too. If not, getting this one in for 9.0 would be a great goal.

Let's stick with the mockups here with the drop down filters.

@cperessini : When we get to the persisting milestone issue in EE, we might have to come back and lock down the milestone filter in the modal here. We can think about that further later. But since we are working on this issue first, we don't have to worry about that now. But let's remember that.

@cperessini : I like that idea of just adding a button to the sidebar since it's out of normal use. It's a bit far away from the issue. But I guess that's the whole point of the sidebar. When you are editing an issue or removing it, it's a rarer occurrence in the board workflow, so that's okay and even intended with the additional friction.

Let me throw out this crazy idea and it might depend on how technically feasible it is. But let's talk UX first: Currently you can drag an issue between lists. And in the future you can re-order, and likely the design will essentially be the same: Drag and drop. How about when you drag an issue on the board, a "remove" area dynamically shows up on the page, and when you drop the issue to the "remove" area, it's removed from the board. This is similar to I think some of the (old?) Android versions where you can long tap and drag an app icon to a dynamic trash icon to uninstall it. And obviously you can drag objects to trash/recycle on desktop UIs. Besides being fun eye-candy, is this overkill? Could this be a good idea?

@victorwu please, check out https://gitlab.com/gitlab-org/gitlab-ce/issues/25698#note_20737051.

@victorwu

About the filters

Isn't there a chance that the new filters will be the standard by 9.0? Would it not make sense by then to have the smart filters here instead of the dropdowns? Just raising that point to prevent @iamphill from having to do that work twice.

About the milestone

We should think further about this, but I had an idea that you could see all issues in the modal, even if the board has an assigned milestone. When you add an issue to the board, its milestone gets changed to the board's milestone.

About removing issues

It's not that crazy! I talked with @awhildy about introducing a shortcut bar to move issues between lists without having to scroll through all the lists. It's very raw, but think of something like this:

We could leverage that and add the option to remove an issue from the board:

If that's too crazy, @GCSBOSS proposed an idea that I also think could work!

@cperessini I love the idea of a shortcut bar, could be especially useful if the board has a lot of lists & you want to add the issue to the last list.

Thanks @cperessini and @GCSBOSS. I knew I saw something like that before. I'm pretty sure I saw that from you previously and it just persisted in my brain.

How about we stick with just the sidebar remove button for this ticket, since already the modal is a big change. And then we can consider the shortcut bar (together with remove) after we've nailed down at least re-ordering. The only problem I have with the shortcut bar is that you can't drag and reorder an issue in one shot. However it does have other benefits like dragging multiple issues all at once, such as bulk skipping interemediate stages into the done list

@cperessini regarding milestones, that's a great idea. Let's save it for that next issue!!

@iamphill : Let's target this whole feature for 9.0 to be realistic.

We definitely need the use case to search and filter in the modal. Given that the team is still scrambling to beef up the new design for the issues list, should we bring that here now? Perhaps we can delay that decision until a bit later when you are further in dev? We just absolutely have to ship this Kodak feature in 9.0. So whatever is the lowest risk to achieve that let's go with.

@victorwu the basic functionality is in ie. the modal opens up, loads issue, issues can be selected & then added into a list that you choose (defaulting to the first list). Just needs a little backend work to fully remove the backlog column.

The best course of action (as it is pretty big right now), is to merge it in (once fully ready) with the search bar & then add the filters in a separate merge request straight after. We can either have that as the new filter bar or the old filter dropdowns depending on where the filter bar is up to.

Design wise, it is using the same CSS classes as the issue list anyway, so if things change there it should actually change here. Maybe a little bit of tweaking, but not much.

Here's a mockup for removing an issue from the board. Is this a good solution? I was struggling to find better placement for the button.

Also it probably doesn't need to be red, since the issue is not being deleted, just removed from this view

Yea - let's keep the 'Remove from board' button grey. Looks great @cperessini!

Are we confident the remove button in the sidebar makes sense? It will be changing the behaviour of dragging an issue to remove which people are used to, to putting the button in a hidden place. How do we tell users that is where it has moved to?

mentioned in commit e37ad076

@iamphill @awhildy @victorwu will the modal be friendly to mobile users?

@JobV I don't feel like the current board experience is mobile friendly. The 4 different scroll regions (page horizontal, page vertical, list vertical, sidebar vertical), and overlapping UI make navigating the page challenging, not to mention moving cards. Given that our current state isn't strong from a mobile perspective, it hasn't been part of our top priority for this iteration.

Adding the modal will help make the experience mobile friendly as when the modal is up, you will have a single vertical scroll region, and an easy tap to select. To ensure it is perfectly mobile friendly we would have to make sure it is fully responsive (goes down to 1 column of cards in the mobile on small screens), and that it lays out on small screens well. There might be a few other details that come up if we explore it more.

These mobile tweaks haven't been a priority in this first iteration, but if you think it is valuable, and makes sense with @victorwu prioritization of work, we can look into it.

Mobile isn't a priority for this feature (or boards itself) as @awhildy alluded to.

@iamphill did a great job and the modal goes from 1 column to 3 depending on screen size. The problem is that the filter bar disappears on smaller resolutions (I imagine so as to save vertical space for the board), so there's no way to access the modal on mobile. I obviously think that's not ideal and we should improve on this, but I meant to say that the modal is kind of a non-problem for now.

Yeah mobile just goes down to 1 column, iPad (or around that size) will be 2 columns.

But like @cperessini mentions, the button isn't visible on mobile because the filters aren't. This behaviour just copies what the filters used to be like on mobile.

mentioned in commit b1a3e9bd

mentioned in issue #22933 (moved)

mentioned in issue #27531 (moved)

mentioned in commit 86d0f499

mentioned in commit a132b7d8

mentioned in commit bc35a4d2

closed

reopened

assigned to @iamphill

closed via merge request !8737 (merged)

mentioned in merge request !8903 (merged)

mentioned in issue #24215 (closed)

Reopening this. When https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8903 is merged, will close.

reopened

closed via merge request !8903 (merged)

added ~122770 label

mentioned in issue #27872 (closed)

mentioned in issue #30547 (moved)

mentioned in issue gitlab#7447

mentioned in issue gitlab#8625

Add existing issues to issue board

Resources

Part of

Problem

Solution and design

Mockups

Resting state for a new board

Add issues - All issues

All issues - selection

Selected issues

Empty state - no issues in the project

Empty state - selected tab

Designs

Child items ...