### Problem to solve <!-- What problem do we solve? --> The templates picker UI is confusing and has usability problems due to double terminology used for example .GitLab-ci.yml templates. See https://gitlab.com/gitlab-org/gitlab/uploads/5a5228d8850278508b9678898d7c3702/image__34_.png ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> This problem has been surfaced through the baseline experience recommendations effort of 2019 Q2: https://gitlab.com/gitlab-org/gitlab-design/issues/518 User thoughts: > There is a template option with the same name which I can apply. It is not clear if it has been applied already yes or no. Though the file seems empty. > Apparently this is for choosing different template types... Are those immediately related to setting up gitlab-ci? ### UX Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> **💎 See the prototypes in the [Designs section](https://gitlab.com/gitlab-org/gitlab/issues/30807/designs) of this issue.** * Move the dropdown for choosing a template `Choose type` next to the file name input field. * Update the button labels, dropdown, and interaction as per acceptance criteria below: #### Scenario 1: Acceptance criteria 1. User leaves the input field blank, and clicks the dropdown button. A dropdown displays a list of template types available. * The dropdown button should have the label updated from `Choose a type` to `Select a type`. [Select means to carefully choose](https://wikidiff.com/choose/select), so let's adapt the language here. * Remove the `close` button from the dropdown. We don't have this dropdown variation in Pajamas, and the fact that the user triggers a dropdown and a `close` option is available is odd. The default behavior of the dropdown is to be dismissed upon click anywhere outside the dropdown body. * Remove the `Choose a template type` dropdown header. * Once the user selects an option in the dropdown, the dropdown should close. The button label should remain `Select a type`. The input field should be populated with the template type selected. For example: `.gitignore` * Once the user triggers the dropdown again, the latest selection should be identified with a `check` icon placed in front of the item name. 2. After a type is selected, a new button should be displayed. The button label should read `Apply a template`. * Clicking the button should trigger a dropdown. * Remove the `close` button from the dropdown. * Remove the `Apply a template` dropdown header. * Fix the dropdown section header. Right now it is displayed in a small grey text, but we should display it in a bold, dark text. [See Pajamas guidelines](https://design.gitlab.com/components/dropdowns/#section-headers). * Once the user selects an option in the dropdown, the dropdown should close. The button label should remain `Select a template`. * Once the user triggers the dropdown again, the latest selection should be identified with a `check` icon placed in front of the item name. 3. After making the final selection, a TOAST component is shown to display the system message, replacing the inline message. #### Scenario 2: Acceptance criteria 1. User enters *.gitignore* in the input field, before choosing a template type. 2. *gitignore* should be then selected in the first dropdown menu (choose type). The Apply a template button is shown. 3. The *Apply a template* dropdown is filtered by the templates that match the previous type selected. 4. After making the final selection, a TOAST component is shown to display the system message, replacing the inline message. <details> <summary>Click me to collapse/fold the first proposal.</summary> - Move closer to the [2019-08-30_00.15.55](/uploads/d129f3da9296190fb6761c950b7ddc12/2019-08-30_00.15.55.gif) and consolidate towards one button for template picking. - It should be positioned next to the file name input like so: . - This will make the template picker UI always available regardless of the file name. - The dropdown search will be prefilled with the file name, so the search immediately filters the dropdown results to what is most interesting. - The default dropdown results will now be named for example `.GitLab-ci.yml - Docker` - [image](/uploads/35109f66c3ab39efcdc91315a7838bdf/image.png) should be retained but can be made a default tertiary button instead of an info button similar to the Web IDE. </details> ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references