Excessive padding and whitespace in table rows

When I looked at this repo today on GitLab, I was shocked at how much padding the table rows have. I'm sitting here in front of a big monitor with a keyboard and mouse, but the rows are as tall as my thumb is wide. It's a problem for several reasons:

1. It forces lots of scrolling to see the rest of the content. It wastes valuable screen space. There's room for, easily, two more files between each file in this list.
2. Depending on the number of files and the window size, it may be that not all the files fit on one screen.
3. Reading the list requires much more eye movement, taking more time and exerting more effort. The human eye and brain can easily scan a compact list of words and find one, but when they are spread out like this, it defeats this ability.
4. Accessing the files with the mouse requires more mouse movement.

I looked at the CSS in the browser inspector and made some adjustments. Here's how it looks by default:

Here's how it looks after adjusting the CSS:

Suddenly, I feel like I can breathe again. I mean, look at GitHub:

See how the files all fit on one screen, and I can even see some of the readme?

Or look at Dolphin viewing the same repo:

Do you have trouble reading that list? Can you imagine if each row were as large as the ones here on GitLab?

Or look at a simple directory listing in a terminal:

This site is for programmers. Programmers use UIs like this all the time. Why would they want an enormously padded UI when they come to GitLab?

If you want to have a tablet-suitable stylesheet, that's fine. But don't force it on all of us. What I seek in UIs is clarity and efficiency, and this excessive padding and whitespace defeats both.

As long as GitLab looks like this, I'll stick with GitHub.

mentioned in merge request !1669 (merged)

Came here to report the same thing - the whitespace in 8.1 is horrendous. The whitespace amount from 8.0.x was fine, but I'm not sure if that's what you're changing it back to in !1669 (merged) or not - the comparison screenshots barely look any different.

In the second screenshot from @alphapapa, it's a little too narrow for my tastes, but a few px on top of that would be ideal. Perhaps this would be best as a configurable option?

What is even the justification for having so much padding? What's the point? Look at GitHub. Is anyone complaining that their file list is too compact? Is anyone complaining that they can see too many files at once? Is anyone complaining that they don't have to scroll more? :/

@alphapapa Thank you for raising issue. I respect your opinion but I do find your comment unfriendly. This is open source project with friendly community. We all want to make project better. I think adding negative emotions here is not necessary.

According to this issue: GitLab is a tool that is used by people of different professions. It is not only hardcode developers but also managers, designers etc. We want to make UI friendly for all of them. For this reason we try best UI practices and see if it works or not. Thanks to this issue we see that vertical height of items in list may be too big and we are working on way how we can make it more compact but still good looking. Thank you.

I'm sorry that you found my comment unfriendly. I'm not trying to be unfriendly, I'm just asking what the reason for the padding is. The only purpose it could serve is to imitate tablet UIs, but this is not a tablet UI.

I'm also concerned that these sizes and heights and paddings are being expressed in pixels. This is 2015, and people are already using 4K monitors. These pixel-based layouts will not scale with the user's default font size.

mentioned in issue #3867 (closed)

Hi @alphapapa,

First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time. To establish order in the GitLab-CE Issue Tracker, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 4 months
• Unlabelled
• Unassigned
• It's not associated with a particular milestone

We'd like to ask you to help us out and determine whether this issue should be reopened.

If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.

If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks for your help

Status changed to closed

Status changed to reopened

If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.

If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Bug/feature-request/design-flaw, whatever you want to call it, there's still too much padding and whitespace. You may not notice it, but I do, and I'm sure I'm not the only one.

To further illustrate how utterly broken the UI is, observe this:

1. Go to any repository you own.
2. Resize your browser to a width of 960 pixels. Note that this is half of a standard-size 1920x1080 monitor.
3. Look for the search box. Look for the settings menu (the little square with a gear in it).
4. You will not find them. They are not visible.
5. Resize the browser to a width of 992 pixels--only 32 pixels wider.
6. Observe the search box and settings button appear out of nowhere.

Now, you tell me, is this not broken? I just spent 10 minutes trying to figure out how to access my repo settings, because the help pages and forum posts I found on google said "Use the settings menu" but it wasn't visible. Only by pure accident did I discover that they were not rendered because of some stupid CSS rule, despite there being plenty of space left on the page!

This is a site for programmers, no? Do programmers not often have two windows side-by-side, one of documentation/browser and one of editor? Does no one test this?!

I can't take GitLab seriously with issues like this. I don't like where GitHub is headed or how they're headed there, but this is simply ridiculous. At least GitHub doesn't have invisible page elements!

Added ~19492 label

I think Adam Porter has a point and I would like to thank him for this post and the screenshots. I like GitLab but the layout overall wastes a gigantic amount of screen real estate. Gigantic buttons. White empty spaces. Gargantuan space between elements. For example if I go to any of my repos there is this letter in a colored circle which is somehow supposed to represent my repo but serves no actual purpose, yet takes away ~10% of screen height. Couldn't that letter-in-a-circle be somewhere on the left side where it doesn't consume all this space? Compare this to the amount of text and information which you can display in any sane terminal emulator. I think it would be great if there were a more compact layout. Compare to Google Gmail which has three settings for padding.

moved to gitlab#3877

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

mentioned in merge request !14785