For a given project, combine the existing Runners, Variables, Triggers and CI/CD Pipelines pages into a single page.
Call this single page the CI/CD Pipelines page.
Update the gear/cog navigation. Combine the Runners, Variables, Triggers and CI/CD Pipelines navigation menu items into one menu item called CI/CD Pipelines.
We were originally called this section Automation / CI. If we can shorten it to just Automations that would great but I'm not sure it encompasses all the sections. Maybe @markpundsack can give some input on what would be appropriate for a section that contains all of these parts.
I however am worried about the discoverability of these settings if we hide it all behind "Automation". I don't know how much "automation" is associated with CI/CD in the community...
Go ahead and update this issue and https://gitlab.com/gitlab-org/gitlab-ce/issues/23007 when you have a better idea on the navigation and how to combine whichever pages. We can work on cleaning up the navigation of other pages in the before just in case you folks end up deciding we should not combine in the way specified currently in #23007 (closed).
I've updated the description. I think we can go with Automation / CI and if another option comes up that is better or makes more sense, we can change it then. But this is ready to be worked on whenever it is scheduled. Thanks!
Why Automation at all? I assume that's because we already have a page for CI/CD Pipelines, and so the Runners, Variables, and Triggers look like other automation, but really they are all about CI/CD as well. There is no automation in that list that is not CI/CD. If you included Webhooks and Services, then maybe. But as is, all of these are just CI/CD, so how about just calling it CI/CD Pipelines? Automation does not mean much to users.
Now, with all this content, I wonder how it's all going to fit into one page cleanly, but that's a design challenge. :)
Great! Thanks for the info @markpundsack. It definitely may be a design challenge to fit all of these in one page for sure! When regrouping the settings, we looked at how we can combine different section in order to keep the number of tabs under control while still managing the amount of content on a single page. If it does become too much, we will definitely revisit to make improvements and keep iterating. This is just the first step :)
One question, is the final name for the menu entry going to be called CI/CD Pipelines?
I say this because there's a small conflict with a route that already exists that is called pipelines and even though this is going to be a new controller there's the thing about a dispatcher class in javascript that might get confused if we have two routes with the same name.
it's a rather simple thing but I don't want a name holding us out for long
We change the title back to Automations or Automations / CI as the menu entry so the dispatcher doesn't get two routes thinking is the same thing
I just create the Automations Controller with the respective views and such and just call the menu entry Pipelines but this might probably make contributing a little bit harder because of the semantics, the controllers being one thing and the menu entry having another title.
@jivanvl : Can we stick with CI/CD Pipelines for the menu item navigation? What's the technical impact? Is it that the url maybe a little weird? And that the various names in the code might not match exactly that? I imagine it would be something like CiCdPipelines depending if the convention is camel case, snake case, whatever. But are you saying that's a major problem? Sorry I don't understand to deeper technical issues you're mentioning here.
@victorwu It's because we already have a PipelinesSettings controller, making routes a little tad confusing for one of our javascript classes, let me see if there's any way to solve this without changing names and such
@ayufan The main idea was to have this merged and then @dimitrieh will work on the UX to improve on how the view looks, you can check out the issue #24141 (moved), I'd say his design looks pretty cool
@ayufan : For this issue and the linked one (https://gitlab.com/gitlab-org/gitlab-ce/issues/23007), UX, Product, and a few engineers have outlined how we want to structure the new navigation. In particular, the plan is to combine the pages as mentioned in #23007 (closed), and in the future issues, we will improve the design of each individual combined page. In particular, this is important so that we can get the new navigation of project settings integrated with the tabbed navigation. So let's proceed with this effort unless you see something major that's a problem. Please comment here so that everyone can see. Thanks!
It makes sense, but the important thing here is that by combining them now the way that it is done, we make it harder later to split them. And the proposal from @dimitrieh shows a view or runners, where it's a clear that it will not be a part of CiCdController, but RunnersController. Right now we do changes that simply move parts of RunnersController to CiCdController. The @dimitrieh changes also don't mention anything about pushing all other settings and variables and triggers into the single view.
I agree with hiding them under the same link under settings, but I'm not sure about merging them into single view as this seems to me like a usability problem that we introduce and make it then harder for ~Frontend to resolve.
@ayufan I think we could solve the usability problem by tackling the issues bit by bit, instead of trying to fix everything from the get go we could focus on merging the views onto a single one and then with the help of the UX team we can fix some of the usability problems.
@ayufan : As @jivanvl mentioned, the strategy we are following is exactly to solve the usability problems. The first step is to combine, and then subsequent steps are to re-design in other issues. This is the strategy that @awhildy said makes sense and @jivanvl and team have already worked through a few of these issues and we are close to wrapping it up.
Is the plan to merge this and then tweak for 8.17? Or are we going to hold this MR and continue iterating on design until we get it into a good place to put in a release?
I'm still concerned that the way how it is now implemented as it introduces a single uber controller. Currently, our uber controller is responsible for index where our sibling controllers are responsible for rest of actions. Which makes the way how it is done kind of strange, and unexpected. Thus introduces a lot of ~"technical debt" that will have to be paid when we try to "improve" that, or split, or refactor. There is an issue created by @grzesiek which starts the discussion on that problem: https://gitlab.com/gitlab-org/gitlab-ce/issues/26255. So I'm not exactly happy about engineering part is done now. The engineering part is always our concern and we need to be comfortable with, as this affects the how quickly we can later iterate. I believe that we have to spend a little more on how the implementation part does look like. I would probably try to pursue what has proposed already: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8281#note_20571630 as this is a very interesting approach to solving this problem.
I do understand the UX reasons. It would also be nice to see the next steps at least for CI/CD settings as we do merge 4 different controllers into one and @dimitrieh proposal only shows how it would look like for the runners when they are a standalone page.
@grzesiek@smcgivern@jivanvl What do you think? Is this something that could be applied for the CI/CD related MR at this stage?
If i could offer my (unsolicited) opinion as a user, I've many times stumbled through various settings pages trying to find some CI/CD Setting or another. I can vividly remember once, as I was attempting to sell my teammates on the usefulness of GitLab and GitLab flow, clicking through every single UI view until I found the setting I was after.
My vote, as a user, is for a monolithic settings page, just one with tabs or a table of contents to help get to settings faster.
I want to make sure we are grouping things appropriately and not making things more difficult for engineering or users. Does it make more sense for the interim step to have Runners be it's own tab and solely group triggers and variables together? I voiced concerns in https://gitlab.com/gitlab-org/gitlab-ce/issues/24141 about the design not allowing for multiple sections (runners, triggers, and variables). @dimitrieh do you feel that the runners page will be able to be combined with these others sections or do we need to keep them separate?
@ayufan, @grzesiek Wants to introduce presenters to help alleviate the concerns over the single uber controller, at the moment this controller only responds to the show action and the rest of the controllers for each of the sections perform the remaining actions. So far the work of introducing presenters has been documented and merged as seen in this MR !8480 (merged).
What was the original course of action, was the following
Merge the different views with a corresponding settings controller that controls the action show and create tests for that new controller (including the spec/features/security/projects ones). So far these two MR's have been merged in the past two releases !8380 (merged) and !8281 (merged).
Have the gear settings button changed to a tab.
Improve the UX in separate issues for each of the new sections Integrations, Members, Repository and CI/CD Pipelines (This is not the order on how things might be tackled but you get the idea)
Introduce presenters for each of the sections
Points 3. and 4. can be switched (I think) if we want to tackle the ~"technical debt" that accrued due to the introduction of this new way to navigate the project settings.
Personally I'd love to help implementing presenters for these issues, if someone from the backend team could give me a (quick maybe? ) coaching session I can definitely help with all of the technical debt issues.
Not sure if I helped clearing any of your concerns or not @ayufan but let me know what you think
@ayufan@joshlambert@tauriedavis it is to my knowledge that could be combined if required ;) we just have adjust the design slighty, but that could be doable
Ok. Thanks, @jivanvl, @grzesiek and @dimitrieh for making me a little less concerned :) I'm fine for time being how we are doing that now as we also have a defined path for the improvement. But we should expect that refactor/split will take a little longer time than actual merge.
This change has made the page even less usable. When I say less, I mean unusable. If the page is fully populated like I have it in the omnibus repository, it becomes a frustrating experience to find the info you need. Are there are some immediate plans to reduce clutter on the page now that MR is merged?
@dimitrieh I believe you were working on improvements to this view, correct? Do you have an updated mockup that includes your runners design with the other info? We should work on getting that implemented soon as the current flow is burdensome.
@tauriedavis could you specify in what way the current flow is burdensome? Is it because its in consistent with the design of title on the left etc?
This is how it currently looks:
Also I think we should perhaps look at how slack handles long pages with lots of settings (with expand and shrinking... in order to solve the now problem we got with not knowing what is on the page at one glance, as we combined a lot):
@dimitrieh Populate that page with ~20 secret variables. Add some 20 runners (15 shared and 5 dedicated). Then check the usability of that page.
What is a notice providing additional info, what is generated info and what is user populated info on that page?