Hacker News Reader

The UI is bad period. 85% navigation on a normal laptop display (1080). There are layers and layers of menus and submenus which could easily be combined and make little sense. And i'm not even someone with a 'design aesthetic'.

The 'review-app' pattern is interesting but doesn't scale for more complicated apps. You'd need to create a 'review cluster' for every branch which quickly becomes untenable. It's usually not lack of automation but cost driving down the number of non-prod environments.

I'm actually a big fan of Gitlab but they should probably focus on user experience and Git hosting and let the other sizable number of products/projects which already exist focus on deployment. Spinnaker, for example, is probably what I'd recommend companies adopt for CD if they're looking to go in that direction.

I don't agree with your point on the 'review-app' pattern. While I agree it would be more work to create a 'review cluster' (I assume you mean app + related services + some test data), this is the kind of effort I think quickly makes you do something a smarter way once you've felt the pain.

Also, companies I've worked at in the past (when sufficiently big) have had "playground" AWS accounts that had a fixed cost for daily all-you-can-use resources. I'd like to think that if you're big enough to think you need >2/3 supporting services to come up with your app, maybe you already have enough traction for that kind of cloud playground account?

I can only speak definitively for myself, but most apps I have built are generally 1 app instance, 1 DB and _maybe_ 1 service for caching. Thinking about how to make these easier to spin up (which includes making sure it's easy for me to make a close-to-production environment as quick as possible), has benefited me, despite initial pain.

Also, if cost is the angle, there are tens of things companies could do, but don't that could bring down cost. Outside of "have more performance-minded developers", "add more computers" is often the cheapest option a company has as far as increasing performance (hence the whole rise of horizontal scalability right?).

I agree that Gitlab should focus on user experience (I'm not sure what you were referring to by "Git hosting"), but I am happy that they've decided to add this CI/CD (and issue boards, and CI), in ONE place.

Sorry to hear you're displeased with our UI. We're always looking to improve our UI and UX as much as we can. There's currently a navigation overhaul planned [1]. If you have any other specific suggestions complaints about the UI we'd love to hear about it, you can even open an issue about it yourself [2]

[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794

[2] - https://gitlab.com/gitlab-org/gitlab-ce/issues

Reporting UI issues is a bad experience on GitLab in and of itself.

The move to a hamburger menu saw significant outcry, and was followed by one of the more popular tickets I've ever seen on GitLab asking for the ability to restore the menu pin feature. Every complaint and criticism was basically replied with "Nah, we're keeping it.", because the new hamburger menu had gone through "design testing".

If you're looking to improve UI/UX, the design team should look through those tickets and learn how to listen when so many users are speaking up against a redesign.

Hi, I am from the GitLab UX team. You may be happy to hear that since and even before the implementation you described we have been busy on a real upgrade for navigation across the whole of GitLab.

Rest assured, that we are hard at work at this (see for more information https://gitlab.com/gitlab-org/gitlab-ce/issues/32794). Even better, if I am correct, there will be a new navigation concept (first alpha iteration) released in 9.4! This will be hidden in a feature flag, which will be accessible from your personal settings.

In the coming months (and thus releases, every 22nd!) we will continue to improve upon this concept, to eventually enable it by default for everyone to enjoy.

We know that the shortcomings of the hamburger icon are suboptimal, but also know that reverting is not always the correct choice. With the new navigation concept we focus on getting a clear distinction between global and contextual navigation. We did proper UX testing to be able to clear out multiple bumps in the road/implementation and are pretty stoked about finally getting it in!

Again check for more information this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/32794. The scope of revising navigation is pretty far reaching and has been on the minds of almost everyone on gitlab!

Note that colors, functionality and any specifics can change throughout the process of implementing over the coming months :)

Gitlab's UI is absolutely awful and incredibly slow. Would you say the same for other tools, like email, or your IDE or editor? They literally copied every functionality and UI of GitHub when they started out, and the only difference at the time was that Gitlab was a slower version of Github.

I'm glad you can self-host it, and that they're open source, they've got that going. But if GitHub would ever open source their tool, it's over.

A few things:

I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough software and truly seen what bad UI looks like. I'm not saying UI doesn't matter, I'm just saying what they have is workable (and can get better, and they've expressed that they care to improve it).

Email, IDE, Editors are not the same as your code hosting, testing, deployment tool, that's a false equivalency. Maybe I must be the only one that is OK waiting 20 seconds for a merge request to complete.

I don't think it is reasonable to hold the fact that they copied/mimiced Github's functionality or UI when they started out against them. Society couldn't move forward if people didn't recycle and improve ideas.

As far as the differences go, while what you said might have been true, it's not these days. Also, you haven't addressed the point that Gitlab offers a shorter path to Doing It Right (tm) (albeit a pretty subjective definition of "right") than Github does.

> Email, IDE, Editors are not the same as your code hosting, testing, deployment tool

Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?

That's a good question -- and of course, the answer is it depends. Having small focused tools is great, but that's only when the substrate/platform that lets you combine them is suuuuper good/standardized/well-designed.

`cat file.txt | sort | uniq` is excellent, but I think a lot of the ergonomics of that kind of small/focused tool reusability is due to the super low friction of using pipe, and how well STDIN, STDOUT, and STDERR work behind the scenes. This kind of falls apart when you try and string together web services.

In my opinion, Gitlab's inclusion of so many parts of the process is good because it saves you from having to manage all the other tools, and it gives you answers for the complete process (where it's possible you could get painted into a corner depending on which focused tools you picked to do some pieces of the process, and have to write your own glue or go on a long search).

Sorry to hear you think our UI is awful. We're constantly trying to improve every part of the product, including our UX. There's a couple of ongoing initiatives currently, like the navigation overhaul [1]. You can list all current UX issues in [2]. We're also very appreciative of any and all community feedback. You can create an issue about anything specific you find bad in our UI (or any other part of the product) in [3].

We also like to think that we bring a couple of novel features to the game. You can check out a list of all our features in [4]

[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794

[2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

[3] - https://gitlab.com/gitlab-org/gitlab-ce/issues

[4] - https://about.gitlab.com/features/

I work with self-hosted Gitlab daily and I’ve never thought the UI was bad or slow. In fact, I think it works pretty well.

To the other commenters: Do you have any examples?

Also, I’m excited about auto deployment. The less tools one needs to get software shipped, the better.

To see that the UI design is bad at times, take the design of merge requests and issues for example.

On Github you can easily see what happens, comments are surrounded by a black border, the name of the comment author and the date are clearly visible and have a different background color from the comment text. Actions like closing and re-opening are distinctly different from comments and are color coded (green -> re-opened, red -> closed, purple -> merged). Emoticons are part of the comment box and don't visually drift into the next one.

Gitlab on the other hand separates comments by a thin (1px) light-grey line that is hardly visible on low contrast monitors like TN displays. Closing and re-opening is also displayed as a light-grey icon on a white background. The author's name has the same color as the comment text, with the date being, again, light-grey. Nothing keeps the contents of a comment together, it's all just text on a white background. The emoticons are just floating around the comments, with the same margin to the next comment as to the comment they are belonging to. So you have to know that emoticons are always below a comment.

Github's design is far, far superior to Gitlab's design because it allows skimming instead of concentrating on finding where each comment begins and ends.

We're working on lots of UX improvements. There's a navigation overhaul planned [1], you can also check out a list of all current UX issues with [2]. As always, community feedback is something we always welcome wholeheartedly [3]

[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794

[2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

[3] - https://gitlab.com/gitlab-org/gitlab-ce/issues

I appreciate the thoughtful and specific feedback. We are working hard to make merge requests and issues intuitive and easy to work with. Many of your observations regarding merge requests are being worked on as part of this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/33095

I'm really sorry that I cannot help by posting this on your issue tracker but I don't have the time right now to sift through all relevant issues on Gitlab to find out where to post and what already has been posted.

My biggest gripe is just that the issue elements (comments, actions, label changes, description edits) are looking too similar for a quick glance. The light-grey font on a white background makes it pretty hard. My suggestion would be to do it a bit like Gihub and to add a black border around stuff, take another background color for actions, and get rid of the grey font and replace it with black throughout.

This comment reminded me to create issues for reducing clutter on the MR page [0], and expanding multiple resolved discussions [1]

[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34814

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/34813

I've used Gitlab for personal projects on a small homelab server. I ran the VM with about 1GB of Memory and 1 vCPU (a Core i3 if I recall correctly).

Loading a page could load almost instantly but most of the time it did load after 2 or 3 seconds.

Gitlab does not work well when resources are scarce, it does require a bit of a beefy server to get fast and reactive, atleast in my experience.

I've found Gitea/Gogs to be a product more focused on running something like Gitlab with much less resources.

I think Gitlab recommends a 4GB of memory and suspect this helps with caching and thus page loads. In an organizational context it should not be too hard to throw hardware at the problem. In my organization we run a Gitlab instance with at least 20 active users (70 users total) and quite a lot of repositories and usually it runs quite fast. This is on 8GB of memory and 2 cores.

For personal and home use Gitea/Gogs is probably a better choice indeed. As you point out it runs with much fewer resources and as an added bonus it runs as a single go binary which simplifies hosting it tremendously. You could literally just download the binary and run "$ ./gitea web". Gitlab is another beast in that respect, especially if you do not opt for their Omnibus install.

Part of this is due to Gitlab's being a Rails app. Large Rails applications are many things, but resource efficient isn't one of them. It's just the nature of the language.

I wish they would rewrite it to something else. Yes, the app is very likely not CPU bound, but I just can't find myself believing in ruby+rails to ever be "fast". However, I'm also very biased against rails so I generally try to ignore the fact that it's a rails app.

I agree. I too work with a self-hosted Gitlab instance daily, and the UI is neither horribly bad nor horrendously slow. The interaction design and user experience could absolutely use some work, but I feel Gitlab has been moving in the right direction with this.

The navigation is still a bit convoluted, but has gotten better. There are still some issues of nested navigation menus and difficult to find pages. As far as page speed goes it has gotten better and they are actively working on this.

As long as the rate of improvement is as good as it is I see no reason to switch to another solution. Especially seeing how the community edition is free and satisfies basic developer needs.

Gitlab is also the only code repository service which integrates CI jobs and statuses as well as a front-end for a self-hosted docker registry. Absolutely a killer feature!

Bad-ish? Try horrible. GitHub has raised the bar too high for Gitlab to spout the tired developer rhetoric that UI/UX doesn't matter.

Gitlab doesn't spout that rhetoric, and neither am I. What I intended was a little more nuanced, I will restate, this time (hopefully) more clearly:

Bad UI on your git hosting tool is very likely not what's holding back your org from delivering faster. It's more likely things like not automating your builds/pipelines/deployment.

Maybe you're at a company that's already doing this properly, you've got Github/Bitbucket Server/whatever set up, with Jenkins Integration, Spinnaker, Quay.io, and you're humming along. While I could make a case for why Gitlab might still benefit you in that environment, it's more likely that at that point, you don't even need it. For every org that is NOT there yet, I think Gitlab offers a benefit -- not thinking about how to get all those other things working.

Maybe where I am on this trade-off is just not the right side, but I see it like this: I prefer a tool that hosts code, automatically tests and deploys a testing instance of the application to host my code than a tool that hosts code but requires more setup to offer that kind of value, even if that second tool has better UI and is seconds or even minutes faster.

The best GUI is the one I don't even have to use -- and I think Gitlab is doing it's best to head towards that, by automate more of the development process for me -- I don't see Github doing this (though they're obviously not against it, they just don't seem to be innovating in this area)

The issue for them is those who don't care about UI are the type who can setup and run there own version of a similiar product.

The crowd that would benefit the most has a modern saas mindset.. simple, fast ui. less clutter..

Sorry to hear you think it's horrible.

We're working very hard on making it a pleasant and enjoyable experience. We're currently planning a navigation overhaul [1]. You can also check out a list of all current UX issues in [2]. And, any specific feedback is greatly appreciated, you can open an issue about anything at [3].

[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794

[2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

[3] - https://gitlab.com/gitlab-org/gitlab-ce/issues

> Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that)

If you'd asked me a year ago, I would've said some very harsh things at this point. But I just went to find examples of the issues I had a year ago (and we still have on our own internal GitLab instances), and it looks like most of them have been resolved. There's still weird duplication (why is there still a "Repository" tab when you can see the repo on the front page) but that's all just small warts that don't matter as much.

I think GitLab still suffers from a weird workflow, but it's much better now than it was in the past.

> Gitlab is slow.

The reason why this is an issue is not the fault of the technology imo, but rather a fault of the marketing and community. GitLab is not meant to usurp https://github.com. It's meant to be a viable alternative to GitHub EE.

Unfortunately, there appears to be a split-brain in the community. GitLab themselves are saying that https://gitlab.com has scaling issues that they are working on resolving, but that self-hosting will not have these issues unless you're planning on running at the same scale as them. But the community appears to want more people to swap away from https://github.com to https://gitlab.com (that's the impression I get).

By doing that, you've now said "any comparisons between https://github.com and https://gitlab.com are entirely valid because we're advertising them in the same capacity". That's selling yourselves short.

If GitLab had decided to go for a federated model, then this sort of marketing problem wouldn't be nearly as much of an issue (you would run into the Mastodon effect, where everyone joins the "official server" -- but if you made it possible to migrate the users, permissions, issues and state of the repo then it wouldn't be a long-term concern). They didn't, and that's fine, but that means that marketing https://gitlab.com as a replacement for https://github.com is going to just cause problems.