The component used for list views at various different places in GitLab has a very brittle layout that could easily break when a substantial change to the table content is rolled out. This is now becoming a blocker in delivering solutions that could provide GitLab users more value from certain features. A couple of areas that have been facing issues while a number of changes are still in works are:
That apart, there's a glaring visual and interaction inconsistency in the implementation of table views across various pages in the product – especially with the fact that tables and list views can be used in very similar scenarios.
✨ Tentative proposal
To deal with the above-mentioned problems, and to make the table component more robust and behave consistently, it is important to understand the different limitations with the component, keeping all the usability and technical challenges in sight.
Below is a high-level plan to approach the redesign process:
📝 Plan
🎢 1. Audit existing table views
Perform an audit of existing pages within GitLab that uses the table view, and possibly the list view. Focus more on the pages within the CI/CD areas.
Identify usability pain-points and what works well on the current component
Identify the types of content and actions most commonly used in table views
Understand how users use table views today
Understand how tables vs list views are being applied in the product
🎯 3. Define addressable problems
Create a list of problems to be addressed in the component, and an issue (or list of issues) to tackle them
Next Steps
After we understand the context and identify & break down the problems, we will propose patterns to fix them and work with Foundations to turn those patterns into new components & guidelines, or or iterations to the existing ones.
@rayana@dfosco here's a high-level tentative plan for the table component redesign. Before creating the individual issues, I wanted to have a discussion with you around the suggested steps.
Veethika Mishrachanged the descriptionCompare with previous version
Thanks for the tag @DarrenEastman ! I'm joining the discussion around the proposal here @v_mishra since we'll also need this for the new default Runner view #299509 (closed). I was proposing a similar view to that of the list view we use today for issues and I think we would have similar types of data as you do for pipelines and maybe even for environments @dfosco
Sure @gdoyle the more use-cases we cover, the more useful the changes would be for the larger team.
Will make sure to keep you posted on the steps to follow 💜
Thanks for creating this proposal @v_mishra - Geo UI also has a card component for list views (only on the secondary instance in the Self-managed GitLab).
Even though we're using the card component, I'm very interested in your planned UX research for this.
I am bringing this old issue so that you could go through my exploration and also view the current design here #211396 (closed)
This is a great proposal @v_mishra! I'm currently analyzing the results of the environments survey which will tell us a lot about how users interact with the data table over there. Will share results here once I've wrapped them.
In the ideal world, we should have a single modular data table * component that fits lots of complex data without breaking horizontally. It can be tricky to meet different needs for every area, but the more consistent we get between product areas, the better.
* Not necessarily a table, @sunjungp card example is also a viable pattern!
@v_mishra@dfosco - The term "redesign" is misleading. As per sync discussion: please consider renaming this issue to reflect the actual goal of the effort. This is not a redesign of the table component, but an investigation on current patterns and improvement of the component usage/guidelines in context with complex data views.
@v_mishra@rayana Updated the title and description of the issue to focus on the problem exploration, and defining clear addressable issues before moving to a (possible) component re-design.
I also removed the mentions to personas and jobs to the component on this process, since components should be agnostic enough to work all across the product. Let me know if you think they could be involved from the start, though!
I also removed the mentions to personas and jobs to the component on this process, since components should be agnostic enough to work all across the product. Let me know if you think they could be involved from the start, though!
@dfosco the reference to personas here would be task/page specific. Going forward if we validate or investigate the table view on a particular page, we have to be mindful of personas while recruiting and framing the research question. But for the overall effort, as you mentioned the design should be persona agnostics. Practically, looking at the screenshots you've added to the Figma file, it appears every single one of the listed persona is affected 🙂
@v_mishra@rayana Created a Figma File with a comprehensive overview of table views and... wow! I opened every single link on the left nav for the GitLab project, and the smashing majority of them are table views, or something resembling a table 😧
I'll go over them looking for problems / opportunities, and add to this issue the ones that are worth discussing!
@dfosco based on my last discussion with @rayana I made a small edit to the description to focus on the scope within CI/CD related stages to avoid expanding the scope to unmanageable size, as you had also suggested 🙂
@dfosco@v_mishra YES! I love that your team is putting energy into this!!!
A while ago, I started down a path to update our tables to be more...enterprise-y... Here is that issue: gitlab-design#1444 (closed). Figured this could help populate some of the needs for the table component. We also have this UX theme issue: Threat Insights UX Theme: Enterprise Vulnerability Management that focuses on improvements to /Security/Vulnerability report.
This is amazing. Thanks @andyvolpe for sharing your prior work in this area 🙌
I see there are a bunch of issues in works in the &5266 epic. The discussions provide so much of insight that we're looking for at this stage. This will make part of our job easier.
Yay! great to hear @v_mishra. Feel free to take over that epic and any related issues as part of this initiative, if applicable. Happy to help in any way.
@andyvolpe Thanks for sharing this work Andy, it's very much relevant to our current work!
I guess one of my action points with @v_mishra is now to figure out the best way to align/merge these two initiatives, since there's so much overlapping opportunities 😄
@dfosco my advice would be to consider the work started in &5266 as additional evidence of the need for those capabilities. For now, continue with the process you and @v_mishra have started as that is likely to surface more needs and gaps as you progress. When it's time to begin thinking about solutions, then you can refer back to that epic but don't hesitate to take a different direction from what was started.
The number of identifiers associated with a given resource(pipelines, jobs, deployment, release, package, etc) can be very high in number. Adding a column for each can possibly harm the performance of the page where the table layout is hosted and also make the layout very busy. To avoid this, we can consider semantically grouping primary and secondary identifiers(as learnt from researches) and display them as a block on the layout. While doing this, it is important that the hierarchy in the layout is validated by users and it does not harm their workflows or slow them down while searching for a particular resource(in row or columns). An example from what we had tried in the pipeline execution team is below. The number of columns in the table was causing performance issue and there was a lot of data to have as individual columns.
When adapting to smaller screen size, the information in columns should drop from the right to left. Grouping content should help with responsive behaviour as there would be lesser columns to accommodate in the resized list view.
An attempt to explore responsive behaviour in list views:
@v_mishra Follow up from our recent sync, this thread on card component seems like a very equivalent effort to this one, and I think the suggestions for different types of cards also fall under the definition of “Pattern” we were discussing 😄
@v_mishra and @dfosco as I was reviewing this issue a few things stand out to me.
I don't believe the GlTable component is what's being referred to in most cases.
I think tabular layout is a more accurate framing than table component.
A semantic table (<table>) should be for presenting and comparing data, not for layout, so I think most or the examples referenced would be better served by abstracting this out into a conversation about "tabular layout" where we can more generally address things like responsive behavior, reflow, and accessibility, etc., that can be applied to other layout concepts too.
@v_mishra@dfosco The proposal says patterns would be proposed or iterated in Pajamas but this issue appear to have stalled in the last month or so.
Since this is not being prioritized, you need to move this issue to the backlog and add a status update for it. This is a large topic that needs to be iterated upon - if we take smaller steps and ship smaller, simpler features, we get feedback sooner. There are also parallel conversations and initiatives around tables and list layouts that related to this effort and that you can continue to contribute to.
If you are working on planning to deliver results in the near feature, I recommend you paying attention to the following:
Set a due date.
We always try to set a due date. If needed, we cut scope. If we have something planned for a specific date, we make that date.
MVC. We encourage MVCs to be as small as possible. Always look to make the quickest change possible to improve the user's outcome.
Be deliberate about scale. First, optimize for speed and results (and be deliberate about how your change affects other processes/functionality); when it is a success, figure out how to scale it.
Make small merge requests. When you are submitting a merge request or a process change, keep it as small as possible.
Please let us know what your next step is. Thanks!
We discussed with Foundation in the office hours and the previous approach that we had taken with Adding a list viewmerge request to the Pajamas guidelines did not appear to be aligned with the Foundation's approach, so we later created a new merge request. The discussion there is already progressing. There was a long delay in between due to the holidays with team members being unavailable, but there's are good chances we'll have the MVC up within %14.8.