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.
There is currently no way to fit more information on the page or provide a better hierarchy for it without moving away from a table for visualizing environment information.
Based on results from the recent problem validation survey on the page, this issue will focus improving usability for these needs, that users declared as some of the main reasons they visit the page today:
When I am planning deployments or changes to production I want to make sure all my teams are informed and know what changes will be made so I can ensure our customers have a positive experience with our code/product.
Currently blocked by ongoing problem validation — we'll use the results to find entry-points into this problem space, and potentially work on a set of smaller issues that will solve this issue.
@afontaine Good point, I haven't actually explored folders in this context yet! I would likely keep iterating the proposal on #332445 (closed) to clean up the folders layout.
Just thinking that there might be an arbitrary number of environments in each folder - Thoughts on duplicating the table headers for each folder and making the header sticky?
@dfosco Based on the discussions in #35412 (closed), I think that issue will be ready for development soon. Part of the redesign overlaps with this issue.
Is the Environment page redesign portion something that we can break down now so that @afontaine can tackle it in 14.4?
@kbychu this really needs to be properly broken down, evaluated and weighted. @afontaine will be OOO for half of the 14.4 milestone. I suggest we add this to the 14.4 needs weight issue. If we have time we can pull it in, but ideally we should aim for implementation 14.5.
@kbychu@nicolewilliams This issue and #35412 (closed) have some overlap, but I expect this one to be a further iteration of it. And agree with Nicole, it needs to be further broken down and likely will be scheduled for implementation on 14.5.
I'd treat the front-end implementation of #35412 (closed) separately from this issue – @afontaine does it makes sense to break down the FE parts of that issue?
@afontaine does it makes sense to break down the FE parts of that issue?
I don't think so. This issue is mostly just rearranging existing data,
and would likely look a little strange "half completed". At the same
time, it isn't risky enough to really deserve a feature flag either.
As the button changes are already captured in a separate issue and MR,
this can be one whole issue.
Daniel Foscochanged title from Design new component to replace environments table to Make deployment & status information easier to read on environments page
changed title from Design new component to replace environments table to Make deployment & status information easier to read on environments page
Daniel Foscochanged the descriptionCompare with previous version
@shinya.maeda@afontaine One question that came up based on the discussion in the mockups: what determines the ordering of folders and environments on the page today?
@shinya.maeda@dfosco The comment in
app/assets/javascripts/environments/components/environments_table.vue
says it all:
/* * The sorting algorithm should sort in the following priorities: * * 1. folders first, * 2. last updated descending, * 3. by name ascending, * ... */
I'm thinking this should be busted up into a few issues and rolled out via a feature flag.
There's a lot of hairy ~"technical debt" on the frontend, and I suspect it might be easier as this is a fresh design to salvage the components we can and rely on new, fresh stuff for what we can't.
The verify team had a very successful go at this with their new pipelines graph, and while our end result isn't nearly as complicated, detangling all the debt while making progress on the deliverables might be.
in that case I would probably recommend doing #342180 (closed) first if we can get some solid backend prioritization on things. without any backend to make it a working feature, I'd rather start on this, as I believe it would have less of an impact on the backend side of things (I am pretty sure most of the data shown is already present one way or another)
As for weighting, I know design things aren't quite yet finalized, but I will definitely want to break this down further (perhaps even further than the 3 listed steps).
4 is a pretty safe start though:
fetching data
folders
environments
deployments
I might want a couple more MRs as a polishing effort once things are in a working state though.
@cbalane Since this issue is about reorganizing the information that already being sent from backend, I don't think that backend work is needed or very small. However, if frontend wants to re-design the fundamental communication process with backend, that'd be a different story, for example:
Currently, frontend polls the information via an internal Restful API, but they want to switch it to GraphQL
Some data in the UX proposal has not been exposed yet, thus backend engineer has to extend the API models.
Some data must be sorted in a complex order that depends on expensive database queries, thus backend engineers has to optimize the queries.
I think @afontaine can elaborate what's necessary for frontend. Later, backend can measure the weights.
@cbalane@afontaine Folks, I aggregated all the feedbacks and finalized the designs! You can see updated mockups above, and a clickable prototype here. I moved this issue to workflowsolution validation, and next steps are:
Running usability testing (see issue), to see if there are any red flags from users. I'm starting the run today, ETA to have it finished is next week. Hopefully we won't need any major changes, and we can move straight into implementation!
Break down the design into components for FE implementation. Will create an issue for this discussion & breakdown and link it here later today
Both of these steps will happen parallel, and unless there are major setbacks from user feedback, we should be right on track to schedule this implementation for 14.6😄
This is probably fine, but I suspect multiple issues might be better so
we can close them as we finish things, especially as this is a pretty
big effort (potentially more than one milestone).
...
--
Andrew Fontaine
Senior Frontend Engineer, Release @ GitLab
@afontaine I think Daniel meant in terms of having a separate issue for the designs. I'm working on breaking this issue into separate FE implementation issues that we can weight. I'll report back here and also tag you on those other ones.