Simplified integration settings page

@mydigitalself @sarrahvesselov I could use some eyes on this

I'm unsure about some of the suggestions in the description.

Webhooks are just another "integration" and shouldn't be treated separately - this may mean you have multiple webhook integrations and perhaps we can group them

I believe webhooks definitely should be grouped separately as the info we need to present is very different. I did try to put them together (but separate) in the mockup below but it feels a little weird. It almost feels like they should remain as separate sections but let me know your thoughts.

We should show all active integrations first, for example, if you have four webhooks, jenkins and trello integrations, show them first and allow you to edit/delete/deactivate them.

I think we should add functionality for sorting and include Name, Last Updated, and Status as options.

This is another reason why putting Webhooks and the project integrations together is a little weird, though. Name doesn't really apply, nor does status, for the webhooks. And the same sort option would be sorting the two individual lists.

Have a separate section/action to add an integration

Definitely agree with this. This will depend on if/how we separate webhooks from other integrations. The mockup below shows the New button in the same place we have it for a new list/issue on boards.

Look to use company/product logos

I started by working on a mockup that used the square layout but I found it much harder to scan and see what was active and what was not. It was much easier in a table format. Another reason for a table format is that it could potentially allow us to change the design further to allow for editing the integration directly on the page instead of navigating away.

We can still use company logos but it was taking me a very long time to try to gather them so I think this should be a separate step if we choose to do it and I can keep working on getting logos as we nail down the design here.

Call the integrations "Integrations" not "Project Services"

Sounds good to me.

I think instead of putting webhooks and integrations together, it would make more sense to put webhooks first, then the search/filter functionality below for the project integrations. I'd like to hear your guys' thoughts though

@tauriedavis I still don't see why we can't show Active integrations first and make webhooks part of those.

Is it really necessary to present all of the information we currently present for a webhook? Can we not present similar information such that you have:

Integration	Description	Actions
Webhook	https://somehook.com	Edit / Delete (icons?)
Jenkins	Integratin with Jenkins CI	Edit / Disable(delete?)
Webhook	https://anotherhook.com	Edit / Delete (icons?)

Add an integration

Choose from list.

I still don't see why we can't show Active integrations first and make webhooks part of those.

I had that as part of the sort options. The reason I made it a sort and not a default is so that when you turn something on and go back to the list, the item is in the same place and it doesn't jump around on you unless you've switched to sorting by active state. Maybe this isn't so necessary but I do think having sort options could be nice.

I'm honestly unsure how important it is to show the triggers on the table. Who would be more familiar with webhooks that we could ask for feedback? I default to asking @DouweM and @rspeicher these things.

I like the way you have the table set up there. I can see that working, will play around with that.

I have always seen webhooks separated from other integrations (GitHub, BB, etc.). NOT saying that is correct or necessary, just my general experience. If not displaying the triggers for webhooks is acceptable, I can see the integrated list working.

If we combine the list to contain webhooks/integrations and incorporate logos, how are we planning on handling the lack of logos for webhooks? I assume we would have a default icon that displays in the place a logo would have been.

I like having the sort options as well @tauriedavis.

If we combine the list to contain webhooks/integrations and incorporate logos, how are we planning on handling the lack of logos for webhooks? I assume we would have a default icon that displays in the place a logo would have been.

Webhooks has a logo.

I'm honestly unsure how important it is to show the triggers on the table. Who would be more familiar with webhooks that we could ask for feedback

Not important, but not unimportant. If you have room, great, if not, not a big deal. Most people will have some idea of which hook does what based on the URL.

I have always seen webhooks separated from other integrations (GitHub, BB, etc.). NOT saying that is correct or necessary, just my general experience.

Same.

If we combine the list to contain webhooks/integrations and incorporate logos, how are we planning on handling the lack of logos for webhooks? I assume we would have a default icon that displays in the place a logo would have been.

Yes, I came across this even on my hunt for integration logos. Some of our integrations are not other companies, such as "Custom issue tracker" "Pipeline emails" "External wiki" etc. We could just use text for those instances or something fancier. But I think we should make a separate issue to look at that directly because it was taking too much time to find all the logos.

Here is an updated mockup assuming that we are okay combining webhooks with integrations. For the sake of finalizing a design, I didn't include every integration we have in this mockup.

Active could be the default sort option, so they would be at the top. One reason for this is because all webhooks would always appear at the bottom if sorted by Name.

You can select "New webhook" and the form would expand to add a new one.

I'm not sure what Choose from list. means in your comment above @mydigitalself

cc @sarrahvesselov

@tauriedavis Looking at those mockups, an argument for separating webhooks jumped out at me: it's the only thing that can be configured multiple times/have multiple entries, so it makes at least a little sense to me to split them.

I think there are a few things confusing the issue here.

Firstly, I don't think it's necessary to list active & inactive integrations together.

Let's think about the use cases for this page.

I want to add an integration to my project
I want to manage (edit/delete) and integration on my project
I just want to explore this a bit and see what GitLab can connect with

For 1. for me there needs to be an explicit "add something" action. At the moment in the mockups we have two separate ways of doing this. One is the Add webhook button, which is also confusingly placed next to the search area and seems to be related to it. The other is by clicking on one of the inactive things (note, you CAN'T click on the little power icon in the same way you can't click on the power icon in the admin panel for certain capabilities, which seems odd).

I think we're mushing up all the use cases together with a solution that isn't necessarily task orientated. This is why I was trying to look at an approach where there's an obvious list of things I have, and I can manage them, and a way to list and add things I don't have. I think we also have terminology issues here between activating and adding an integration.

I take @rspeicher point about webhooks being a special butterfly in that you can add multiple of them. Slack effectively does this by giving you the ability to add "Webhooks" as an integration and then they have multiple "configurations".

You can solve this in other ways, for instance when you add an integration, with the exception of webhooks (or perhaps in the future other integrations that can have multiple configurations) you don't show it in the list of things you can add, or when you try to add it, you tell the user that the configuration cannot be added more than once.

cc @tauriedavis

Thanks for answering my questions @rspeicher!

This is why I was trying to look at an approach where there's an obvious list of things I have, and I can manage them, and a way to list and add things I don't have. I think we also have terminology issues here between activating and adding an integration.

I understand where you are coming from @mydigitalself. Rather than be presented with a long list of integrations, you are looking to focus users in on choosing a task, then being presented with the flow to complete it.

I want to add an integration to my project

I want to manage (edit/delete) and integration on my project

I just want to explore this a bit and see what GitLab can connect with

This immediately made me think of a design proposal @pedroms made here https://gitlab.com/gitlab-org/gitlab-ce/issues/32420#note_35263502. This is extreme but I think we could do something similar in breaking down the sections and only showing what is necessary for the task @tauriedavis.

I'm not sure what Choose from list. means in your comment above @mydigitalself

Sorry, I missed that @tauriedavis

For example, and I'm not saying this is the pinnacle of design - far from it - but this is how we did it at Gitter

There's a list of the integrations you've added, and then you can add one by choosing from the list of available integrations.

I have always seen webhooks separated from other integrations (GitHub, BB, etc.). NOT saying that is correct or necessary, just my general experience.

Slack treat them all as just integrations, and each integration has a configuration and many can have multiple configurations.

marked this issue as related to #28451 (moved)

Thanks @mydigitalself - All the above makes sense to me. I actually like how you guys did it at Gitter, looks clear and is easy to scan.

If we are going to treat webhooks the same as other integrations, we could just add a section for webhooks under the Add integration section, rather than having it separate. Clicking on it would take you to the page to add one. You could add multiple configurations, like you showed with Slack.

I still have some logos to dig up for the above mockup but wanted to post this version to get feedback quicker.

@tauriedavis cool, that looks great!

So I guess we just need to add the Webhook item and logo to the list as you say, and then have a webhooks Edit screen which shows all the hooks and the ability to add a new one?

Yeah, I was thinking that if it already has a configuration, it wouldn't show in the list because you can just add another through the edit screen by hiting edit on the active service. But it doesn't hurt to include it in the list if you can have multiple configurations of a service.

And yep, I'll get the edit screen added to the description today.

Here is the flow:

One downside of this change is that it takes an extra click to view your webhooks.

changed the description

added UX ready and removed UX labels

@tauriedavis good job on this, it's much better than what we have today The strong points in your design: search, categories, making webhooks an “integration”, and listing the active integrations first/separated from the others. However, I'm not that confident about:

Displaying the inactive integrations in a grid: this introduces a new way of scanning the same type of items in the same screen, and it's not as efficient (as you mentioned)
Not showing icons/logos for active integrations: it again clashes with the grid design below and makes it (slightly) harder to scan
Having the edit and delete buttons: clicking the edit button is the same as clicking the name of the integration so no need to duplicate this action. And do we really, really, need to give users such a lightning fast way to delete an integration? Is it such a usual action? Not only that, but it makes sense to keep the integration data intact if users want to re-enable it in the future, and having this button here kind of gives the impression that everything will be deleted.

With this in mind, I think Slack's approach is very simple and effective. In Slack, the name of the integration is the single point of interaction (no extra buttons) and they still manage to show the icons/logos in an alphabetical list. Pairing their approach with your designs strong points would be awesome.

Also, I don't mind having a separate screen for managing webhooks. Maybe you can even remove the “Configurations” column in the table/list view and just have a badge next to the “Webhooks” label with the total amount (do we have any other integration with multiple configs?)

Of course, I completely understand if you don't change anything, as you own the UX on this issue and it's already marked UX ready. I just had to give my opinion Keep up the awesome work.

Great points @pedroms! Thank you for reviewing! I will provide an updated mockup with your points in mind.

@mydigitalself Will this be for 10.0 or is it being pushed to backlog?

added UX and removed UX ready labels

@tauriedavis no problem, that's why we're here. I'm glad that you're willing to take another look

@tauriedavis 10.0 is pretty packed now wrapping up nav, so going to try to get this done in 10.1

added Deliverable label

assigned to @kushalpandya

@pedroms is this what you had in mind?

(didnt add all integrations, it takes a long time).

One thing to note is that not all of them have logos (or I wasnt able to find svgs for them). So there are blank spots. What are your thoughts on that? We could probably use pngs for the ones I couldnt find svgs for. But services such as "Custom issue tracker" doesnt have anything.

Also, would you mind picking up / keeping an eye on this issue while I am out of town next week @pedroms? Ill be back before you take leave. I've committed my versions to the design repo

assigned to @pedroms

@tauriedavis sure, no problem, I'll pick this up

About the logos, I think it's fine to use PNGs if we can't find SVGs. For custom integrations, we can use our icons that correspond to their categories (e.g. our issues icon for “Custom Issue Tracker”).

I haven't seen any reference to how the search would work. As a user, my impression is that it would filter both active and inactive integrations. In that sense, I feel like the relationship between the two lists could be better (I'll look into this).

@mydigitalself I've found that we use the terms “integration” and “service” interchangeably. Reading the screen description on the mockup, it seems like integrations are the umbrella for services and webhooks — is this interpretation correct? However, the active integrations list has an “Active service” header and contains Webhooks, which contradicts this interpretation.

@mydigitalself lastly, do we have any other integration/service with multiple configs, besides webhooks? In my previous comment I suggested removing the “Configurations” column and add a badge next to the “Webhooks” label with the total amount (if webhooks is the only one with multiple).

I'll also try to gather PNGs for all of the remaining integrations that are missing their logo.

@pedroms I think we should move to use the word "Integration" above "services" so please change where appropriate.

I'm not convinced we need search off the bat and can leave it out of scope.

None of the other integrations currently support multiple configurations, that's not to say we couldn't add that in the future - you could do as you suggested and have something more specific just for webhooks for now, so leave the column blank and have 3 webhooks - I'd be explicit and say what it is not just a badge.

added services settings webhooks labels

mentioned in commit gitlab-design@d42a21c3

changed the description

Cleaned up the description and added a link to the design spec.

@kushalpandya as we discussed, you can save the exported logos (svg/png) by using the slices menu or selecting an image layer. Let me know if you have any questions!

mentioned in issue #37911

@mydigitalself renaming “Project services” to “Integrations” touches on a lot of different pieces, so I created #37911 to discuss and focus this effort, instead of increasing the scope of this issue.

changed the description

added UX ready and removed UX labels

@pedroms

https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/ce%2334059-spec-previews/#artboard1

How would you get that page? If you have no webhooks wouldn't the list of integrations NOT have Webhooks under Active Integrations, but it should appear at the end of Add an Integration?

@mydigitalself yep, that's correct, if you don't have any webhooks the “Webhooks” integration would appear in the “Add an integration” list. I've already synced with @kushalpandya about this.

@pedroms ok, so the only way you'd get that artboard1 mockup is if you visited that URL manually?

@mydigitalself no need to type the URL manually. The empty state of the “Webhooks” integration is available if you click on “Webhooks” in the “Add an integration” list. When a webhook has been added, the integration is deemed “active” and so the “Webhooks” entry moves from the “Add an integration” list to the “Active integrations”. Let me know if it's not clear enough.

@pedroms why wouldn't it take you straight into adding a webhook rather than the webhooks page and you have to click Add again?

mentioned in commit gitlab-design@9cda1232

changed the description

@mydigitalself oh, you're totally right! I was still attached to the older model of list -> object and didn't look at it from that angle. I've updated the description and specs with that behavior.

Thanks so much @pedroms for finishing this up while I was away! Looks great

@tauriedavis no problemo I changed a few things as you might have read from the discussion Everything is committed to the design repo so you can improve it, if necessary. I'll be off so… back to you

@tauriedavis I've put together the integrations page and realized that a few integrations are missing from design specs, and thus, I need logos for them. Here's the screenshot of which they are and how they look currently;

As you can see that I've re-used some of the existing icons for them but not sure if they fit contextually.

added In dev label

I think the icons you have there work well for those three :) Lets use them!

@kushalpandya asked in slack about the mobile design for webhooks. Mobile tables should match other tables that use our mobile design (ex. environments).

In this case, it would result in:

changed the description

mentioned in merge request !14548

Frontend for this issue is completed in !14548 but is blocked as the MR requires some backend cleanup. I'm removing milestone at the moment until backend dependency on related MR is cleared.

added blocked and removed In dev labels

removed milestone

changed milestone to %10.3

Thanks @kushalpandya for the update. Excited to get this in, hopefully in 10.3!

moved to gitlab#10575

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Simplified integration settings page

Description

Proposal

Design

Links / references

Documentation blurb

Designs

Child items ...

Activity

Frequently Asked Questions

Admin message

Admin message

Simplified integration settings page

Description

Proposal

Design

Links / references

Documentation blurb

Relates to

Activity

Frequently Asked Questions