<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> This issue has been opened ~2 years ago and many things may have changed since then. My goal is to revisit this issue and assess whether the latest designs are still "UX ready". After reading through this issue, I see that a lot of great thinking and design work has been done. Overall, after looking at the [latest design mockups](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/ce%2334059-spec-previews/#artboard0) I would like to recommend some updates and propose how we can break down the final design into smaller MRs. ## Updated proposal As a first step into improving this page. I would like to reduce the amount of elements and calls to action on this page. One fundamental change in the newly proposed design is that the assume that Webhooks have their own view. Which is in conflict with the originally proposed design: > Webhooks are just another "integration" and shouldn't be treated separately I have proposed to decouple webhooks from integrations, more on that in issue [119429](https://gitlab.com/gitlab-org/gitlab/issues/119429) ### This original Issue was moved into an Epic and has been broken down into the following smaller issues: 1. Decouple Webhooks from Integrations within Project > Settings [119429](https://gitlab.com/gitlab-org/gitlab/issues/119429) 2. Update the page flow, copy and layout on Integrations page [195889](https://gitlab.com/gitlab-org/gitlab/issues/195889) 3. Add a logo for each integration [195893](https://gitlab.com/gitlab-org/gitlab/issues/195893) 4. Add a way to search/filter integrations [195894](https://gitlab.com/gitlab-org/gitlab/issues/195894) ## Historical Record ### Description As part of [Screen_Shot_2017-06-21_at_12.16.38](/uploads/3e96f6629be3435b7899d47eece9adbf/Screen_Shot_2017-06-21_at_12.16.38.png)). Some inspiration: [Screen_Shot_2017-06-21_at_12.20.22](/uploads/aef72235ecd6995c0768737fa359c5ed/Screen_Shot_2017-06-21_at_12.20.22.png), [Screen_Shot_2017-06-21_at_12.21.08](/uploads/5699b9acd44bdd66deb2e22f7043fa79/Screen_Shot_2017-06-21_at_12.21.08.png) ### Proposal - “Project services” are simply called “Integrations” (gitlab-ce#37911 will rename them everywhere else outside of the “Integrations” page) - Two lists of integrations using company/product logos: one for active integrations and another to add an integration - As integrations are configured, they move from the “Add an integration” list to the “Active integrations” list. - Webhooks are just another "integration" and shouldn't be treated separately - You can have multiple webhooks, and for that, a counter badge is shown next to the “Webhook” list item indicating how many configurations there are - Have a separate page for listing webhooks - Have a separate page for creating webhooks (the same model we already have for editing webhooks) - If there are no Webhooks, the “Webhooks” entry should be in the “Add an integration” list. - When in the “Add an integration” list, clicking “Webhooks” should direct the user to the “New webhook” page. - When in the “Active integrations” list, clicking “Webhooks” should direct the user to the “Webhooks” list page. #### Design [Check the design specs (for implementation notes, spacing, sizes, colors, text copying, and exported assets)](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/ce%2334059-spec-previews/) - Hide notes in the top-right corner - [image](/uploads/6d49c80b5e8272099cfbdb17e14ba46d/image.png) Mobile webhooks design should match our design for mobile tables:  ### Links / references ### Documentation blurb (Write the start of the documentation of this feature here, include: 1. Why should someone use it; what's the underlying problem. 2. What is the solution. 3. How does someone use this During implementation, this can then be copied and used as a starter for the documentation.)