New issue boards should have the default lists automatically

Currently if you visit a new issue board GitLab will prompt you to add the 'default lists' (I think TODO and DONE)

I propose that these default lists are created automatically. This has the following advantages:

1. It saves a step in our I2P demo
2. It doesn't confront the user with a choice they don't have sufficient context on to make a good decision.
3. It will make it more obvious you can use GitLab Issue Boards for Kanban (users are frequently not aware of this).

/cc @sarrahvesselov @JobV @timzallmann

added UX in GitLab FOSS label

The only value I see in having the ability to make the choice, is the knowledge that there is a choice. The option, 'Nevermind, I'll use my own' is a queue to the user that the issue board is something they control.

If we remove this step, I do believe we should have some way for users to learn more about how they can use Issue boards to manage their projects. Something akin to the on-boarding we have discussed for releases @JobV. It could be something as simple as a link that takes them to documentation.

@sarrahvesselov @sytses I'm not convinced that the current solution is very helpful, and removing the choice doesn't help with onboarding either.

We either make the existing solution something powerful, e.g. giving you the option to choose from some templates (scrum board, a board with a milestone, a board to organise your team).

Or we do as Sid suggests and work on a way to onboard. I don't think we can call this onboarding.

If we were to build an on boarding experience from zero, would we use this method? I think that we would just show you the default and tell you in some way that you can create lists.

I don't like that with this default, we're creating two labels the user might never want to use plus going from zero to a solution that is custom (which is almost always the case with issue boards) is more work.

mentioned in issue gitlab-foss#33892 (closed)

I agree, the status quo is not very helpful and to @sytses point, can be confusing to new users and annoying to experienced ones.

I spent a lot of time interacting with the Issue boards to try and understand why I myself was not clear on what I could do with them from the start. Here are some observations:

1. The first time I created an issue board, I chose 'Nevermind, I'll use my own'. I then looked for the option to add a Board and was confused because I did not see the option. It was only in clicking around that I realized that I needed to click Add List. While it makes perfect sense now, it was difficult to understand that I was on Issue Boards but needed to add a List. Since I am building boards, I expected the terminology to match.

2. The first time I created a new board, I expected to be able to define the lists on the board. This caused some confusion as to what I could and couldn't do with boards. Once I created the board, I had to then go and add lists to that board in a second step. Again, simple to understand now but not necessarily intuitive for users the first or even second time around depending on how often they use issues. @dimitrieh has created an issue related to this https://gitlab.com/gitlab-org/gitlab-ce/issues/32001

3. Once I had lists on the board, I expected to be able to directly edit the name of the list. I think this will be fixed with the implementation of this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/24685

We either make the existing solution something powerful, e.g. giving you the option to choose from some templates (scrum board, a board with a milestone, a board to organise your team).

I put together a quick example (in the browser) of giving users options. Kanban and Scrum are the most common paradigms without getting into custom board types so I chose to make those a default option. I added a link to Learn More about Issue boards. This quick link is unobtrusive to experienced users but can provide much needed context for new users interested in a quick start guide to using issues. It could be linked here https://docs.gitlab.com/ee/user/project/issue_board.html

If we were to implement this I believe the board should start empty with only the backlog and closed lists present.

added feature proposal in GitLab FOSS label

assigned to @sarrahvesselov

• We should have board templates (i.e. Scrum, Agile, etc.). I think that makes sense. That should be a future issue. Let's focus on something small here to makes a big impact.
• The current design of generating "To Do" and "Doing" for you automatically is not that helpful. The main reason is that every board already has two static lists, namely "Backlog" and "Closed". So people could actually use their boards with only those two lists. So generating those two lists does not do much more. And also, it adds those two labels behinds the scenes. This is tricky. Because we are overloading labels as lists. So that might be okay. But the fact we are doing it automatically does nothing to educate the user.
• If the user wanted a simple Kanban board, we should help them be able to add one additional list, namely, "Doing".

I think this would be a good idea:

• I have a simple message telling you that there are two static, default lists, and point to them.
• I have a simple message telling you that you can always add lists by clicking the Add list button, and I point to that button.
• I have a call-to-action button right there in the middle panel. Once you click the button, it activates the Add list button, so your eyes are drawn to that button. And you see the messaging in that Add list UI. And you complete the flow of adding a list. So the UI has guided you exactly and educated you on how to add lists, and even informed you that lists are backed by labels.
• Once you click the call-to-action button, that middle panel disappears. It never has to appear again because now you understand.
• If you truly want to use the board with only the Backlog and Closed lists, you would click Dismiss. The panel never appears again.
• The panel appears for a given board only if the following two conditions are true:
  • No user has ever clicked Dismiss in the middle panel for that board.
  • There are no additional lists in the board (beyond the static Backlog and Closed lists).

Addressing @sytses 's concerns:

• It saves a step in our I2P demo

You would now click the Add list button (either in the panel or the persistent button). You don't get the free lists for free. But the benefit is that you get the education you need. Future issues should address generating pre-configured boards like Kanban, Scrum, etc, similar to @sarrahvesselov 's design in https://gitlab.com/gitlab-org/gitlab-ce/issues/34919#note_35183482.

For the I2P demo, I would recommend that we simply add one list, called "Doing", and that's accomplished by simply clicking the button and adding that label/list.

• It doesn't confront the user with a choice they don't have sufficient context on to make a good decision.

This is solved because we focus on guiding the user to add their very first list and educating them. Indeed this proposal doesn't confront the user with a choice without education.

• It will make it more obvious you can use GitLab Issue Boards for Kanban (users are frequently not aware of this).

Simple Kanban has three lists, i.e. To Do, Doing, and Done. Our board comes with two lists by default, i.e. Backlog and Closed, which map to the first and last stages. A Kanban user should instantly recognize they just need to add the Doing stage by adding one list. Our panel now has a simple call to action to achieve this.

Thanks @victorwu. I think this could work. I would love for @hazelyang to take a look and see if we could do something to make it more eye catching. Even though the intent is different, it doesn't feel much different from the existing solution at first blush.

Once you click the call-to-action button, that middle panel disappears. It never has to appear again because now you understand.

This would be per user, correct? When they create a new project and a new issue board, this will not appear?

changed milestone to %Next 2-3 months in gitlab-foss

@sarrahvesselov : Whether the panel appears or not I'm proposing depends on whether there are lists and if any person has ever clicked Dismiss. The assumption is if a person has clicked Dismiss, they want to use it as a simple board with just the two default lists. Open to other ideas on the conditions.

The panel appears for a given board only if the following two conditions are true:

• No user has ever clicked Dismiss in the middle panel for that board.

• There are no additional lists in the board (beyond the static Backlog and Closed lists).

The assumption is if a person has clicked Dismiss, they want to use it as a simple board with just the two default lists. Open to other ideas on the conditions.

I disagree with this assumption. The intention of the message is to let people know that they can quickly create a Kanban board or add any other types of lists they need. My assumption would be that if they have clicked dismiss, they understand how to use boards and do not want to be bothered with that message again. Under this assumption, the following would be true:

The panel appears for a given board only if the following condition is true:

• No user has ever clicked Dismiss in the middle panel for that board.

@victorwu I think your proposal is too small a step. I also don't think the backlog/done version is one anyone will actually use. I think we can be a little more bold here. Be that by immediately offering those templated lists (not very hard to build) or something else.

cc @sarrahvesselov

moved from gitlab-foss#34919 (moved)